Настройка параметров брокера для обеспечения высокой доступности, масштабирования и использования памяти

Ресурс брокера — это основной ресурс, определяющий общие параметры для брокера MQTT. Он также определяет количество и тип модулей pod, которые выполняют конфигурацию брокера, например интерфейсы и серверные части. Вы также можете использовать ресурс Брокера для настройки профиля памяти. Механизмы самовосстановления встроены в брокер и часто могут автоматически восстанавливаться после сбоев компонентов. Например, если узел завершается сбоем в кластере Kubernetes, настроенном для обеспечения высокой доступности.

Вы можете горизонтально масштабировать брокер MQTT, добавив дополнительные интерфейсные реплики и внутренние секции. Интерфейсные реплики отвечают за прием подключений MQTT от клиентов и перенаправление их в внутренние секции. Внутренние секции отвечают за хранение и доставку сообщений клиентам. Интерфейсные модули pod распределяют трафик сообщений между внутренними модулями pod. Серверный фактор избыточности определяет количество копий данных для обеспечения устойчивости к сбоям узлов в кластере.

Список доступных параметров см. в справочнике по API брокера.

Настройка параметров масштабирования

Чтобы настроить параметры масштабирования брокера MQTT, укажите поля кратности в спецификации ресурса Брокера во время развертывания Операций Интернета вещей Azure.

Кратность автоматического развертывания

Чтобы автоматически определить начальное кратность во время развертывания, опустите поле кратности в ресурсе Брокера.

{
  "memoryProfile": "<MEMORY_PROFILE>"
}

az iot ops create ... --broker-config-file <FILE>.json

Оператор брокера MQTT автоматически развертывает соответствующее количество модулей pod на основе количества доступных узлов во время развертывания. Эта возможность полезна для непроизводственных сценариев, в которых не требуется высокий уровень доступности или масштабирование.

Эта возможность не является автомасштабированием. Оператор не масштабирует количество модулей pod на основе нагрузки. Оператор определяет начальное количество модулей pod для развертывания только на основе оборудования кластера. Как отмечалось ранее, кратность устанавливается только во время первоначального развертывания. Новое развертывание требуется, если необходимо изменить параметры кратности.

Настройка кратности напрямую

Чтобы настроить параметры кратности напрямую, укажите все поля кратности.

az iot ops create ... --broker-frontend-replicas 1 --broker-frontend-workers 1  --broker-backend-part 1  --broker-backend-workers 1 --broker-backend-rf 2

{
  "cardinality": {
    "frontend": {
      "replicas": 1,
      "workers": 1
    },
    "backendChain": {
      "partitions": 1,
      "redundancyFactor": 2,
      "workers": 1
    }
  }
}

az iot ops create ... --broker-config-file <FILE>.json

Общие сведения о кратности

Кратность означает количество экземпляров определенной сущности в наборе. В контексте брокера MQTT кратность относится к количеству интерфейсных реплик, внутренних секций и рабочих ролей серверной части для развертывания. Параметры кратности используются для горизонтального масштабирования брокера и повышения уровня доступности при сбоях модуля pod или узла.

Поле кратности — это вложенное поле с подполями для внешнего интерфейса и внутренней цепочки. Каждый из этих подфилдов имеет собственные параметры.

Внешний интерфейс

Подфилд внешнего интерфейса определяет параметры интерфейсных модулей pod. Ниже приведены два основных параметра:

• Реплики: количество интерфейсных реплик (pod) для развертывания. Увеличение числа интерфейсных реплик обеспечивает высокий уровень доступности в случае сбоя одного из интерфейсных модулей pod.
• Рабочие роли: количество рабочих логического интерфейса на каждую реплику. Каждая рабочая роль может использовать до одного ядра ЦП в большинстве случаев.

Серверная цепочка

Подфилд цепочки серверной цепочки определяет параметры внутренних секций. Ниже приведены три основных параметра:

• Секции: количество секций для развертывания. В процессе, называемом сегментированием, каждая секция отвечает за часть сообщений, разделенную идентификатором раздела и идентификатором сеанса. Интерфейсные модули pod распределяют трафик сообщений по секциям. Увеличение числа секций увеличивает количество сообщений, которые может обрабатывать брокер.
• Фактор избыточности: количество внутренних реплик (pod) для развертывания на каждую секцию. Увеличение коэффициента избыточности увеличивает количество копий данных, чтобы обеспечить устойчивость к сбоям узлов в кластере.
• Рабочие роли: количество рабочих ролей для развертывания на каждую серверную реплику. Увеличение числа рабочих реплик на серверную реплику может увеличить количество сообщений, которые может обрабатывать серверный модуль pod. Каждая рабочая роль может использовать не более двух ядер ЦП, поэтому будьте осторожны при увеличении числа рабочих реплик на реплику, чтобы не превышать количество ядер ЦП в кластере.

Рекомендации

При увеличении значений кратности емкость брокера для обработки дополнительных подключений и сообщений, как правило, улучшается, а также повышает высокий уровень доступности при сбое модуля pod или узла. Это увеличение емкости также приводит к увеличению потребления ресурсов. Поэтому при настройке значений кратности учитывайте параметры профиля памяти и запросы ресурсов ЦП брокера. Увеличение числа рабочих реплик на интерфейсную реплику может помочь увеличить использование ядра ЦП, если обнаружено, что использование ЦП интерфейсной части является узким местом. Увеличение числа рабочих ролей серверной части может помочь с пропускной способностью сообщения, если использование внутреннего ЦП является узким местом.

Например, если в кластере есть три узла, каждый из которых содержит восемь ядер ЦП, установите количество интерфейсных реплик, чтобы соответствовать количеству узлов (3) и задать число рабочих ролей равным 1. Задайте количество внутренних секций, чтобы соответствовать количеству узлов (3) и задать для внутренних рабочих ролей значение 1. Задайте необходимый коэффициент избыточности (2 или 3). Увеличьте количество рабочих ролей внешнего интерфейса, если обнаружено, что использование внешнего ЦП является узким местом. Помните, что внутренние и интерфейсные рабочие роли могут конкурировать за ресурсы ЦП друг с другом и другими модулями pod.

Настройка профиля памяти

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

Чтобы настроить параметры профиля памяти брокера MQTT, укажите поля профиля памяти в спецификации ресурса Брокера во время развертывания Операций Интернета вещей.

az iot ops create ... --broker-mem-profile Tiny

Существуют предопределенные профили памяти с различными характеристиками использования памяти для публикации сообщений. Количество сеансов или подписок, которые может обрабатывать брокер, не ограничено. Профиль памяти управляет только использованием памяти для трафика PUBLISH.

Маленький

Используйте этот профиль, если у вас есть ограниченные ресурсы памяти и трафик публикации клиента является низким.

При использовании этого профиля:

• Максимальное использование памяти каждой интерфейсной реплики составляет примерно 99 МиБ, но фактическое максимальное использование памяти может быть выше.
• Максимальное использование памяти каждой серверной реплики составляет примерно 102 МиБ, умноженное на число внутренних рабочих ролей, но фактическое максимальное использование памяти может быть выше.
• Максимальный размер сообщения составляет 4 МБ.
• Максимальный размер входящего буфера для данных PUBLISH составляет примерно 16 МиБ на одного рабочего серверной части. Однако эффективный размер может быть ниже из-за механизмов обратного давления, которые активируются, когда буфер достигает 75% емкости, в результате чего размер буфера составляет примерно 12 МиБ. Отклоненные пакеты имеют ответ PUBACK с кодом ошибки превышение квоты.

Рекомендации при использовании этого профиля:

• Следует использовать только один интерфейс.
• Клиенты не должны отправлять большие пакеты. Вы должны отправлять только пакеты меньше 4 МиБ.

Низкая

Используйте этот профиль, если у вас есть ограниченные ресурсы памяти и клиенты публикуют небольшие пакеты.

При использовании этого профиля:

• Максимальное использование памяти каждой интерфейсной реплики составляет примерно 387 МиБ, но фактическое максимальное использование памяти может быть выше.
• Максимальное использование памяти каждой серверной реплики составляет приблизительно 390 МиБ, умноженное на число внутренних рабочих ролей, но фактическое максимальное использование памяти может быть выше.
• Максимальный размер сообщения составляет 16 МБ.
• Максимальный размер входящего буфера для данных PUBLISH составляет примерно 64 МиБ на рабочий процесс на серверной части. Однако эффективный размер может быть ниже из-за механизмов обратной подачи, которые активируются, когда буфер достигает 75% емкости, что приводит к размеру буфера примерно 48 МиБ. Отклоненные пакеты имеют ответ PUBACK с кодом ошибки превышение квоты.

Рекомендации при использовании этого профиля:

• Следует использовать только один или два интерфейса.
• Клиенты не должны отправлять большие пакеты. Вы должны отправлять только пакеты меньше 16 МиБ.

Средняя

Используйте этот профиль, если необходимо обрабатывать умеренное количество клиентских сообщений.

Средний — это профиль по умолчанию.

• Максимальное использование памяти каждой интерфейсной реплики составляет примерно 1,9 ГиБ, но фактическое максимальное использование памяти может быть выше.
• Максимальное использование памяти каждой серверной реплики составляет примерно 1,5 ГиБ, умноженное на число внутренних рабочих ролей, но фактическое максимальное использование памяти может быть выше.
• Максимальный размер сообщения составляет 64 МБ.
• Максимальный размер входящего буфера для данных PUBLISH составляет примерно 576 МиБ на один рабочий процесс бэкэнда. Однако эффективный размер может быть меньше из-за механизмов обратного давления, которые активируются, когда заполнение буфера достигает 75%, что приводит к размеру буфера примерно 432 МиБ. Отклоненные пакеты имеют ответ PUBACK с кодом ошибки превышение квоты.

Высокая

Используйте этот профиль, если необходимо обрабатывать большое количество клиентских сообщений.

• Максимальное использование памяти каждой интерфейсной реплики составляет примерно 4,9 ГиБ, но фактическое максимальное использование памяти может быть выше.
• Максимальное использование памяти каждой серверной реплики составляет примерно 5,8 ГиБ, умноженное на число внутренних рабочих ролей, но фактическое максимальное использование памяти может быть выше.
• Максимальный размер сообщения составляет 256 МБ.
• Максимальный размер входящего буфера для данных PUBLISH составляет примерно 2 ГиБ на одного бекенд-работника. Однако действующий размер может быть ниже из-за механизмов обратного выражения, которые активируются, когда буфер достигает 75% емкости, что приводит к размеру буфера примерно 1,5 ГиБ. Отклоненные пакеты имеют ответ PUBACK с кодом ошибки превышение квоты.

Вычисление общего использования памяти

Параметр профиля памяти определяет использование памяти для каждой интерфейсной и серверной реплики и взаимодействует с параметрами кратности. Вы можете вычислить общее использование памяти с помощью формулы:

M_total = R_fe * M_fe + (P_be * RF_be) * M_be * W_be

Где:

Например, если выбрать профиль средней памяти, профиль имеет внешний объем памяти размером 1,9 ГБ и использование серверной памяти размером 1,5 ГБ. Предположим, что конфигурация брокера состоит из 2 интерфейсных реплик, 2 внутренних секций и коэффициента избыточности серверной части 2. Общее использование памяти:

2 * 1,9 ГБ + (2 * 2) * 1,5 ГБ * 2 = 15,8 ГБ

В сравнении, профиль Tiny памяти имеет использование памяти на передней части 99 MiB и использование памяти в задней части 102 MiB. Если вы предполагаете ту же конфигурацию брокера, общее использование памяти составляет:

2 * 99 МБ + (2 * 2) * 102 МБ * 2 = 198 МБ + 816 МБ = 1,014 ГБ.

Ограничения ресурсов Kubernetes и кратности

Чтобы предотвратить нехватку ресурсов в кластере, брокер по умолчанию настраивается для запроса ограничений ресурсов ЦП Kubernetes. Масштабирование числа реплик или рабочих ролей пропорционально увеличивает необходимые ресурсы ЦП. Ошибка развертывания возникает, если в кластере недостаточно ресурсов ЦП. Это уведомление помогает избежать ситуаций, когда запрошенная кратность брокера не хватает ресурсов для оптимального выполнения. Это также помогает избежать потенциальных конфликтов ЦП и вытеснений pod.

Брокер MQTT в настоящее время запрашивает одну единицу ЦП (1.0) для каждой рабочей роли внешнего интерфейса и две единицы ЦП (2.0) для каждой серверной рабочей роли. Дополнительные сведения см. в разделе единиц ресурсов ЦП Kubernetes.

Например, следующая кратность запрашивает следующие ресурсы ЦП:

• Для интерфейсов: 2 единицы ЦП на интерфейсный модуль pod, в общей сложности 6 единиц ЦП.
• Для серверных частей: 4 единицы ЦП на серверный модуль pod (для двух рабочих ролей серверной части), раз 2 (коэффициент избыточности), раз 3 (число секций), в общей сложности 24 единиц ЦП.

{
  "cardinality": {
    "frontend": {
      "replicas": 3,
      "workers": 2
    },
    "backendChain": {
      "partitions": 3,
      "redundancyFactor": 2,
      "workers": 2
    }
  }
}

Чтобы отключить этот параметр, задайте generateResourceLimits.cpu поле Disabled в ресурсе Брокера.

{
  "generateResourceLimits": {
    "cpu": "Disabled"
  }
}

az iot ops create ... --broker-config-file <FILE>.json

Развертывание с несколькими узлами

Чтобы обеспечить высокую доступность и устойчивость при развертывании с несколькими узлами, брокер операций Интернета вещей MQTT автоматически устанавливает правила защиты от сопоставления для серверных модулей pod.

Эти правила предопределяются и не могут быть изменены.

Назначение правил защиты от сходства

Правила защиты от сопоставления гарантируют, что серверные модули pod из одной секции не выполняются на одном узле. Эта возможность помогает распределять нагрузку и обеспечивает устойчивость к сбоям узлов. В частности, серверные модули pod из одной секции имеют анти-сходство друг с другом.

Проверка параметров защиты от сопоставления

Чтобы проверить параметры защиты от сопоставления для серверного модуля pod, выполните следующую команду:

kubectl get pod aio-broker-backend-1-0 -n azure-iot-operations -o yaml | grep affinity -A 15

В выходных данных показана конфигурация защиты от сходства, аналогичная следующему примеру:

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: chain-number
            operator: In
            values:
            - "1"
        topologyKey: kubernetes.io/hostname
      weight: 100

Эти правила являются единственными правилами защиты от сходства, установленными для брокера.

Связанный контент

• Настройка прослушивателей для брокера MQTT