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

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

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

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

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

Внимание

Для этого параметра требуется изменить ресурс брокера. Он настраивается только при первоначальном развертывании с помощью Azure CLI или портал Azure. Новое развертывание требуется, если необходимы изменения конфигурации брокера. Дополнительные сведения см. в разделе "Настройка брокера по умолчанию".

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

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

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

Портал

Автоматическое кратность пока не поддерживается при развертывании операций Интернета вещей с помощью портал Azure. Можно вручную указать режим развертывания кластера в виде одного узла или нескольких узлов. Дополнительные сведения см. в статье Развертывание операций Интернета вещей Azure.

Azure CLI

Подготовьте файл конфигурации брокера в формате JSON, который включает требуемые свойства ресурса Azure Resource Managermicrosoft.iotoperations/instances/brokers. Не забудьте опустить cardinality поле. Например, задайте только профиль памяти:

{
  "memoryProfile": "<MEMORY_PROFILE>"
}

Затем разверните операции Интернета вещей с помощью az iot ops create команды с флагом --broker-config-file , например следующую команду (другие параметры опущены для краткости):

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

Дополнительные сведения см. в статье о поддержке Azure CLI для расширенной конфигурации брокера MQTT.

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

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

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

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

Портал

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

Azure CLI

При развертывании операций Интернета вещей с помощью az iot ops create команды используйте --broker-frontend-replicasпараметры , --broker-backend-part--broker-frontend-workers--broker-backend-rfи --broker-backend-workers параметры для указания параметров кратности.

Например, чтобы указать одну интерфейсную реплику, одну рабочую роль внешнего интерфейса, одну серверную секцию, две внутренние реплики на секцию и одну рабочую роль серверной части на реплику, см. следующую команду (другие параметры не указаны для краткости):

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

Кроме того, используйте --broker-config-file флаг для указания JSON-файла, включающего параметры кратности. Ниже приведен пример JSON-файла для одинаковых параметров:

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

Затем разверните операции Интернета вещей с помощью az iot ops create команды с флагом --broker-config-file , например следующую команду (другие параметры опущены для краткости):

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.

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

Внимание

Для этого параметра требуется изменить ресурс брокера. Он настраивается только при первоначальном развертывании с помощью Azure CLI или портал Azure. Новое развертывание требуется, если необходимы изменения конфигурации брокера. Дополнительные сведения см. в разделе "Настройка брокера по умолчанию".

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

Портал

При использовании следующего руководства для развертывания операций Интернета вещей в разделе "Конфигурация" просмотрите конфигурацию брокера MQTT и найдите параметр профиля памяти. Здесь можно выбрать из доступных профилей памяти в раскрывающемся списке.

Azure CLI

При развертывании операций Интернета вещей с помощью az iot ops create команды используйте --broker-mem-profile параметр для указания параметров профиля памяти.

Например, чтобы указать профиль памяти следующим Tinyобразом, см. следующую команду (другие параметры опущены для краткости):

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

Дополнительные сведения см. в дополнительных az iot ops create параметрах.

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

Маленький

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

• Максимальное использование памяти каждой интерфейсной реплики составляет примерно 99 МиБ, но фактическое максимальное использование памяти может быть выше.
• Максимальное использование памяти каждой серверной реплики составляет примерно 102 МиБ, умноженное на число внутренних рабочих ролей, но фактическое максимальное использование памяти может быть выше.

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

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

Низкая

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

• Максимальное использование памяти каждой интерфейсной реплики составляет примерно 387 МиБ, но фактическое максимальное использование памяти может быть выше.
• Максимальное использование памяти каждой серверной реплики составляет приблизительно 390 МиБ, умноженное на число внутренних рабочих ролей, но фактическое максимальное использование памяти может быть выше.

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

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

Средняя

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

• Максимальное использование памяти каждой интерфейсной реплики составляет примерно 1,9 ГиБ, но фактическое максимальное использование памяти может быть выше.
• Максимальное использование памяти каждой серверной реплики составляет примерно 1,5 ГиБ, умноженное на число внутренних рабочих ролей, но фактическое максимальное использование памяти может быть выше.

Высокая

• Максимальное использование памяти каждой интерфейсной реплики составляет примерно 4,9 ГиБ, но фактическое максимальное использование памяти может быть выше.
• Максимальное использование памяти каждой серверной реплики составляет примерно 5,8 ГиБ, умноженное на число внутренних рабочих ролей, но фактическое максимальное использование памяти может быть выше.

Ограничения ресурсов 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 Изменение поля не поддерживается в портал Azure. Чтобы отключить этот параметр, используйте Azure CLI.

Azure CLI

Подготовьте файл конфигурации брокера в формате JSON, который включает требуемые свойства ресурса Resource Manager microsoft.iotoperations/instances/brokers и задайте generateResourceLimits.cpu для поля значение Disabled. Например:

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

Затем разверните операции Интернета вещей с помощью az iot ops create команды с флагом --broker-config-file , например следующую команду (другие параметры опущены для краткости):

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

Дополнительные сведения см. в статье о поддержке Azure CLI для расширенной конфигурации брокера MQTT.

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

Чтобы обеспечить высокую доступность и устойчивость при развертывании с несколькими узлами, брокер операций Интернета вещей 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