Настройка поведения буфера сообщений с поддержкой диска
Внимание
Этот параметр требует изменения ресурса брокера и может быть настроен только во время первоначального развертывания с помощью Azure CLI или портала Azure. Новое развертывание требуется, если необходимы изменения конфигурации брокера. Дополнительные сведения см. в разделе "Настройка брокера по умолчанию".
Функция буфера сообщений с поддержкой диска используется для эффективного управления очередями сообщений в брокере MQTT, распределенном брокере MQTT. К преимуществам относятся:
Эффективное управление очередями: в брокере MQTT каждый подписчик связан с очередью сообщений. Скорость обработки сообщений подписчика непосредственно влияет на размер очереди. Если подписчик медленно обрабатывает сообщения или если они отключаются, но запрашивают постоянный сеанс MQTT, очередь может увеличиться больше доступной памяти.
Сохранение данных для постоянных сеансов: функция буфера сообщений с поддержкой диска гарантирует, что при превышении очереди доступной памяти она легко буферизуется на диск. Эта функция предотвращает потерю данных и поддерживает постоянные сеансы MQTT, позволяя подписчикам возобновлять сеансы с очередями сообщений без изменений при повторном подключении. Диск используется в качестве эфемерного хранилища и выступает в качестве разлива из памяти. Данные, записанные на диск, не являются устойчивыми и теряются при выходе pod, но если хотя бы один модуль pod в каждой цепочке серверной части остается функциональным, брокер в целом не теряет никаких данных.
Обработка проблем с подключением: облачные соединители рассматриваются как подписчики с постоянными сеансами, которые могут столкнуться с проблемами подключения, если не удается взаимодействовать с внешними системами, такими как брокер MQTT Сетки событий из-за отключения сети. В таких сценариях сообщения (PUBLISHes) накапливаются. Брокер MQTT интеллектуально буферизирует эти сообщения в память или диск, пока не будет восстановлено подключение, обеспечивая целостность сообщений.
По умолчанию функция буфера сообщений с поддержкой диска отключена. В этом случае сообщения остаются в памяти, а обратное давление применяется к клиентам, так как пул чтения или пул царапин достигает предела, определенного ограничением очереди подписчика.
Настройка буфера сообщений с поддержкой диска необходима для поддержания надежной и надежной системы очереди сообщений, особенно в сценариях, когда скорость обработки сообщений и подключение критически важны.
Примечание.
Брокер MQTT записывает данные на диск точно так же, как получено от клиентов, без дополнительного шифрования. Защита диска необходима для защиты данных, хранящихся брокером.
Варианты конфигурации
Чтобы настроить буфер сообщения с поддержкой диска, измените diskBackedMessageBuffer
раздел в ресурсе Брокера. В настоящее время это поддерживается только с помощью флага --broker-config-file
при развертывании операций Интернета вещей Azure с помощью az iot ops create
команды.
Чтобы приступить к работе, подготовьте файл конфигурации брокера после справочника по API DiskBackedMessageBuffer .
Например, самая простая конфигурация включает только указание максимального размера. В этом случае emptyDir
том подключен. Значение maxSize
используется в качестве ограничения размера тома emptyDir
. Но это наименее предпочтительный вариант, предоставляющий ограничения тома emptyDir
.
{
"diskBackedMessageBuffer": {
"maxSize": "<SIZE>"
}
}
Чтобы получить лучшую конфигурацию буфера сообщений с поддержкой диска, укажите временный том или утверждение постоянного тома для подключения выделенного тома хранилища для буфера сообщений. Например:
{
"diskBackedMessageBuffer": {
"maxSize": "<SIZE>",
"ephemeralVolumeClaimSpec": {
"storageClassName": "<NAME>",
"accessModes": [
"<MODE>"
]
}
}
}
{
"persistentVolumeClaimSpec": {
"maxSize": "<SIZE>",
"ephemeralVolumeClaimSpec": {
"storageClassName": "<NAME>",
"accessModes": [
"<MODE>"
]
}
}
}
Настройте параметры буфера сообщений брокера, изменив следующие параметры:
Настройте том: укажите шаблон утверждения тома для подключения выделенного тома хранилища для буфера сообщений.
Выберите класс хранилища: определите требуемый класс StorageClass с помощью
storageClassName
свойства.Определение режимов доступа. Определите режимы доступа, необходимые для тома. Дополнительные сведения см. в режимах постоянного доступа к томам.
Используйте следующие разделы, чтобы понять различные режимы тома:
- Эфемерный том является предпочтительным вариантом,
- Постоянный том предпочтителен далее и
emptyDir
том наименее предпочтителен.
Постоянные и временные тома обычно предоставляются одинаковыми классами хранилища. Если оба варианта доступны, выберите эфемерный вариант. Обратите внимание, что временные тома требуют Kubernetes 1.23 или более поздней версии.
Совет
Указание эфемерного утверждения тома (EVC) или шаблона утверждения постоянного тома (ПВХ) позволяет использовать выбранный класс хранилища, повышая гибкость для некоторых сценариев развертывания. Например, подготовленные с помощью шаблона ПВМ, отображаются в таких kubectl get pv
командах, как проверка состояния кластера.
Если для узлов Kubernetes недостаточно места на локальном диске для буфера сообщений, используйте класс хранилища, предоставляющий сетевое хранилище, например BLOB-объекты Azure. Однако обычно лучше использовать локальный диск с меньшим maxSize
значением, так как буфер сообщений получает преимущества быстрого доступа и не требует устойчивости.
Развертывание операций Интернета вещей Azure с буфером сообщений с поддержкой диска
Чтобы использовать буфер сообщений с поддержкой диска, разверните операции Интернета вещей Azure с помощью az iot ops create
команды с флагом --broker-config-file
. См. следующую команду (другие параметры, пропущенные для краткости):
az iot ops create ... --broker-config-file <FILE>.json
Этот параметр нельзя изменить после развертывания. Чтобы изменить конфигурацию буфера сообщений с поддержкой диска, повторно разверните экземпляр операций Интернета вещей Azure.
Эфемерный том
Временный том является предпочтительным вариантом буфера сообщений.
Для временных объемов следуйте рекомендациям в разделе "Рекомендации для поставщиков хранилища".
Значение ephemeralVolumeClaimSpec
свойства используется в качестве ephemeral.volumeClaimTemplate.spec
свойства тома в спецификациях StatefulSet внутренних цепей.
Например, чтобы использовать временный том с емкостью 1 гигабайт, укажите следующие параметры в ресурсе Брокера:
{
"diskBackedMessageBuffer": {
"maxSize": "1G",
"ephemeralVolumeClaimSpec": {
"storageClassName": "foo",
"accessModes": [
"ReadWriteOnce"
]
}
}
}
Постоянный том
Постоянный том является следующим предпочтительным вариантом для буфера сообщений после временного тома .
Для постоянного тома следуйте рекомендациям в разделе "Рекомендации для поставщиков хранилища".
Значение persistentVolumeClaimSpec
свойства используется в качестве volumeClaimTemplates.spec
свойства спецификаций StatefulSet внутренних цепей.
Например, чтобы использовать постоянный том с емкостью 1 гигабайт, укажите следующие параметры в ресурсе Брокера:
{
"diskBackedMessageBuffer": {
"maxSize": "1G",
"persistentVolumeClaimSpec": {
"storageClassName": "foo",
"accessModes": [
"ReadWriteOnce"
]
}
}
}
emptyDir
том
Том emptyDir является наименее предпочтительным вариантом после постоянного тома.
Используйте только том emptyDir при использовании кластера с квотами файловой системы. Дополнительные сведения см. на вкладке квоты проекта файловой системы. Если функция не включена, кластер выполняет периодическое сканирование, которое не применяет никаких ограничений и позволяет узлу узла заполнить место на диске и пометить весь узел узла как неработоспособный.
Например, чтобы использовать том emptyDir с емкостью 1 гигабайт, укажите следующие параметры в ресурсе Брокера:
{
"diskBackedMessageBuffer": {
"maxSize": "1G"
}
}
Рекомендации для поставщиков хранилища
Рассмотрим поведение выбранного поставщика хранилища. Например, при использовании таких поставщиков rancher.io/local-path
. Если поставщик не поддерживает ограничения, заполнение тома потребляет место на диске узла. Это может привести к тому, что Kubernetes помечает узел и все связанные модули pod как неработоспособные. Важно понять, как работает поставщик хранилища в таких сценариях.
Выключено
Если вы не хотите использовать буфер сообщений с поддержкой диска, не включайте diskBackedMessageBufferSettings
свойство в ресурс Брокера. Это также поведение по умолчанию.
Сохраняемость
Важно понимать, что функция буфера сообщений с поддержкой диска не является синонимом сохраняемости. В этом контексте сохраняемость относится к данным, которые сохраняются при перезапуске pod. Однако эта функция предоставляет временное хранилище для сохранения данных на диске, предотвращая переполнение памяти и потерю данных во время перезапуска pod.