Преминете към основното съдържание

Мащабиране

Повече бекенди​

Бекендите не пазят състояние и не се нуждаят от „лепкави“ сесии (sticky sessions):

docker compose -f docker-compose.prod.yml --env-file .env up -d --scale backend=2
  • Caddy открива репликите чрез DNS и разпределя натоварването по метода на най-малко връзки (least-connections).
  • Задачите за агент, свързан с друга реплика, се предават чрез PostgreSQL LISTEN/NOTIFY (канал agent_dispatch).
  • Периодичните задачи (почистване по срок на съхранение, проверка за офлайн устройства, индекс на winget, поетапни пускания, оценка на алармите) се изпълняват само на избрания лидер.
  • Ограниченията за влизане се отчитат в базата данни, така че N реплики не дават N пъти повече опити.
  • Отнеманията на достъп и спиранията на тенанти достигат до всяка реплика.
  • Потоците на отдалечения работен плот са твърде големи за NOTIFY. Когато прозорецът за наблюдение на техника достигне различна реплика от тази на потока на устройството, репликата на наблюдаващия се свързва директно с репликата на устройството на нейния RMM_NODE_URL (по подразбиране http://<container hostname>:8080, който се разрешава в compose мрежата) и препредава през нея. Caddy отказва достъп до този вътрешен път отвън.
Реплики на няколко хоста

URL адресът на възела по подразбиране е обикновен http://: тогава препредаването между репликите пренася съдържанието на екрана некриптирано по мрежата между тях. Това е приемливо в рамките на един Docker хост (compose мрежата), но когато репликите работят на различни хостове, задайте RMM_NODE_URL на https:// адрес, достъпен за другите реплики (със сертификат, на който те се доверяват), или дръжте репликите в частна, криптирана мрежа.

Връзки към базата данни​

Броят реплики × RMM_DATABASE_MAX_CONNS трябва да остава под max_connections (200) минус около 20 за поддръжка. Увеличете PG_MAX_CONNECTIONS заедно с необходимата за това памет или добавете PgBouncer в режим на сесия. Режимът на транзакция не се поддържа: обхватът на тенанта се пренася в настройките на сесията.

Срок на съхранение и дялове​

  • Почистването по срок на съхранение се изпълнява ежедневно на партиди от 10 000 реда; напредъкът се вижда в rmm_retention_rows_deleted_total.
  • device_metrics е разделена на дялове по месеци. Дяловете се създават два месеца предварително и се изтриват при почистването по срок на съхранение.
  • Сроковете за задачите и одита за всеки тенант са описани в Настройки на тенанта.

Референтен тест за натоварване​

5 000 агента на един хост: внедряване на 1 000 устройства приключи за 28 s, а порталът отговаряше с p95 127 ms при 50 заявки в секунда. Сигналите за активност (heartbeat) се групират в едно обновяване в секунда, непроменените секции от инвентаризацията се пропускат, а едновременната обработка на входящите данни е ограничена до една четвърт от пула. Подробности: Производителност.