Масштабирование

В разделе рассматривается горизонтальное масштабирование (добавление экземпляров сервисов) при невозможности вертикального масштабирования (увеличения ресурсов).

Масштабирование БД, Kafka и S3-совместимого хранилища не рассматривается, так как они не являются частью продукта и масштабируются согласно своей документации.

Необходимость масштабирования

В таблице аппаратных требований к продукту указано примерное количество экземпляров в зависимости от числа обслуживаемых устройств и пользователей (см. колонку «Комментарии»).

Однако реальная нагрузка может варьироваться в зависимости от использования продукта (количество коллекций, конфигураций, частота их применения). Наилучший способ определить необходимость добавления реплик — анализ данных мониторинга компонентов продукта. Если потребление процессора или памяти часто превышает 90%, это может сигнализировать о необходимости масштабирования сервисов.

Добавление экземпляров сервисов

Добавление экземпляра сервера управления (salt-master)

  1. Установите из дистрибутива пакеты salt-common, salt-master, salt-api.

  2. Настройте сервер управления (master). Настройки должны быть идентичными для всех серверов.

  3. Скопируйте на новый сервер управления (master) ключи с работающего(их) мастера(ов). Ключи должны быть идентичными для всех серверов.

  4. Если автоприем агентов (minions) выключен (auto_accept: false), новый сервер управления (master) не сможет принимать существующих агентов (minions). В этом случае необходимо принять их вручную или скопировать ключи принятых агентов (minions) с работающего сервера управления (master) на новый (содержимое директории /etc/salt/pki/master/minions/). После этого все агенты (minions) будут рассматриваться как принятые новым сервером управления (master).

  5. Запустите службы salt-master и salt-api.

Регистрация нового сервера управления (master) в модуле osmax-core не требуется. Информация о новом сервере будет получена автоматически после начала поступления сообщений от него в Kafka.

Для доступа модуля osmax-core к API нового сервера управления (master) должна быть правильно настроена аутентификация (идентично на всех мастерах).

При использовании LDAP-аутентификации дополнительных настроек на новом сервере управления (master) не требуется. При использовании PAM-аутентификации на новом сервере управления (master) необходимо создать пользователя, аналогичного другим серверам, с соответствующими правами.

Настройка агентов для использования нового сервера управления

После добавления нового сервера управления (master) необходимо в конфигурации каждого агента (minion) добавить новый сервер в список серверов управления (master).

Это можно сделать с помощью создания новой формулы (конфигурации).

Добавление экземпляров модулей osmax-core и osmax-provisioner

Количество экземпляров osmax-core и osmax-provisioner определяется в зависимости от нагрузки на соответствующий API.

Процесс добавления экземпляра:

  1. Установите пакет c модулем из дистрибутива.

  2. Выполните настройку модуля.

  3. Запустите службу.

Все необходимые инструкции см. в разделе «Установка и конфигурация модулей бэкенда».

После запуска нового экземпляра osmax-core он будет выполнять задачи совместно с другими экземплярами, кроме обслуживания запросов из интерфейсов «Кабинет администратора» и «Магазин приложений», такие как:

  • запуск внутренних расписаний (импорт данных из LDAP, сбор информации об инвентаризации ПО, и другие);

  • обработку заказов на установку ПО из пользовательского интерфейса «Магазин приложений».

  • обработку сообщений от сервера управления (master) из Kafka.

Так как модули osmax-core и osmax-provisioner содержат в себе потребителей сообщений из Kafka, при добавлении экземпляров нужно учитывать специфику масштабирования Kafka (см. ниже).

Настройка Nginx для балансировки нагрузки между экземплярами

Чтобы обслуживать запросы от пользовательского интерфейса параллельно с другими экземплярами osmax-core, необходимо настроить балансировку нагрузки в Nginx.

Оптимизация обработки сообщений Kafka

Kafka используется для передачи сообщений между компонентами продукта: master, osmax-core и osmax-provisioner (см. раздел «Интеграция с брокером сообщений Kafka».

Наиболее нагруженный топик — salt-topic, служащий для передачи сообщений от сервера управления (master) в модуль osmax-core. На других топиках не ожидается значительного объема информации.

Для каждого экземпляра osmax-core количество потребителей внутри группы потребителей можно настроить с помощью свойства mp.messaging.incoming.salt-events-kafka.concurrency. Разделы (partition) топика будут разделены между потребителями.

При увеличении числа экземпляров osmax-core возрастает и количество потребителей сообщений из топика. Однако следует учитывать, что в Kafka не может быть более одного экземпляра потребителя, подключенного к одному разделу (partition). Если количество потребителей превышает количество разделов, избыточные потребители останутся бездействующими. Для повышения скорости обработки сообщений необходимо также увеличить количество разделов (partition) в топике.

Формула для вычисления числа разделов (partition) топика:

Число разделов = max(NP, NC), где:

  • NP — количество требуемых производителей (producers), определяемое как: TT/TP;

  • NC — количество требуемых потребителей, определяемое как: TT/TC;

  • TT — общая ожидаемая пропускная способность системы;

  • TP — максимальная пропускная способность одного производителя для одного раздела;

  • TC — максимальная пропускная способность одного потребителя из одного раздела.

Если вы хотите достигать 1000 МБ/сек, а ваш потребитель обрабатывает только 50 МБ/сек, потребуется минимум 20 разделов и 20 потребителей. Для производителей, если один может писать со скоростью 100 МБ/сек, нужно 10 разделов. С 20 разделами можно поддерживать 1 ГБ/сек как для записи, так и для чтения. Настройте количество разделов в соответствии с числом потребителей и производителей, чтобы достичь целевой пропускной способности.

Рекомендуется использовать реальные показатели из промышленного окружения для определения необходимого числа разделов, так как производительность зависит от конкретных сценариев использования. Для получения точных данных проведите нагрузочные тесты и сформулируйте задачу для нагрузочного тестирования.

Количество разделов для существующего топика можно увеличить с помощью команды kafka-topics.sh, например:

bin/kafka-topics.sh --bootstrap-server <broker:port> --topic <topic-name> --alter --partitions <number>