Planeamiento de la implementación: búfer de mensajes con respaldo en disco

El búfer de mensajes con respaldo en disco es una característica que permite al agente MQTT desbordar las colas de mensajes del suscriptor al disco cuando superan la memoria disponible. Decida antes del despliegue si necesita almacenamiento en búfer en disco para los mensajes de su broker MQTT.

Importante

Esta configuración exige la modificación del recurso de Broker. Solo se configura en la implementación inicial mediante la CLI de Azure o Azure Portal. Se requiere una nueva implementación si se necesitan cambios de configuración de agente. Para obtener más información, consulte Personalizar el agente predeterminado.

La característica de búfer de mensajes con respaldo en disco se usa para administrar eficazmente las colas de mensajes dentro del agente MQTT distribuido. Las ventajas incluyen:

  • Administración eficaz de colas: en un agente MQTT, cada suscriptor está asociado a una cola de mensajes. La velocidad de procesamiento de mensajes de un suscriptor afecta directamente al tamaño de la cola. Si un suscriptor procesa los mensajes lentamente o si se desconectan, pero solicitan una sesión persistente de MQTT, la cola puede aumentar más que la memoria disponible.
  • Conservación de datos para sesiones persistentes: la característica de búfer de mensajes respaldados por disco garantiza que cuando una cola supere la memoria disponible, se almacene en búfer sin problemas en el disco. Esta característica evita la pérdida de datos y admite sesiones persistentes de MQTT, lo que permite a los suscriptores reanudar sus sesiones con sus colas de mensajes intactas cuando se vuelven a conectar. El disco se utiliza como almacenamiento temporal y sirve como extensión de la memoria. Los datos escritos en el disco no son duraderos y se pierden cuando se cierra el pod. Si al menos un pod de cada cadena de backend sigue funcionando, el bróker en su conjunto no pierde ningún dato.
  • Control de los desafíos de conectividad: los conectores en la nube se tratan como suscriptores con sesiones persistentes que pueden enfrentar desafíos de conectividad cuando no pueden comunicarse con sistemas externos como un agente MQTT de Azure Event Grid debido a la desconexión de red. En estos escenarios, los mensajes (PUBLISHes) se acumulan. El agente MQTT almacena estos mensajes en búfer inteligentemente en memoria o disco hasta que se restaura la conectividad, lo que garantiza la integridad del mensaje.

De forma predeterminada, la característica de búfer de mensajes con respaldo en disco está deshabilitada. En este caso, los mensajes permanecen en memoria y la presión inversa se aplica a los clientes a medida que el uso de memoria alcanza el límite definido por el límite de cola de suscriptores.

Note

El broker MQTT escribe los datos en disco exactamente tal como los recibe de los clientes, sin añadir cifrado. Asegurar el disco es esencial para proteger los datos que almacena el broker.

Configuración del búfer de mensajes respaldados por disco

Para configurar el búfer de mensajes con respaldo en disco, edite la diskBackedMessageBuffer sección del recurso Broker. Actualmente, esta configuración solo se admite mediante el uso de la --broker-config-file marca al implementar Operaciones de IoT de Azure mediante el az iot ops create comando . Para obtener más información, consulte la sección sobre la compatibilidad del CLI de Azure con la configuración avanzada del agente MQTT.

Esta configuración no se puede cambiar después de la implementación. Para cambiar la configuración del búfer de mensajes con respaldo en disco, vuelva a implementar la instancia de operaciones de IoT.

Para empezar, prepare un archivo de configuración de Broker siguiendo la referencia de la API DiskBackedMessageBuffer .

A continuación, implemente Operaciones de IoT con la --broker-config-file marca (se omiten otros parámetros para mayor brevedad):

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

Por ejemplo, la configuración más sencilla implica especificar solo el tamaño máximo. En este caso, se monta un volumen emptyDir. El maxSize valor se usa como límite de tamaño del emptyDir volumen. Pero esta opción es la opción menos preferida debido a las limitaciones del emptyDir volumen.

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G"
  }
}

Para obtener una mejor configuración del búfer de mensajes respaldado por disco, especifique un volumen efímero o una solicitud de volumen persistente para montar un volumen de almacenamiento dedicado para su búfer de mensajes. Por ejemplo:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "persistentVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

Adapte las opciones del búfer de mensajes del agente ajustando la siguiente configuración:

  • Configurar el volumen: especifique una plantilla de solicitud de volumen para montar un volumen de almacenamiento dedicado para su búfer de mensajes.
  • Seleccione una clase de almacenamiento: defina la clase de almacenamiento deseada mediante la storageClassName propiedad .
  • Defina los modos de acceso: determine los modos de acceso que necesita para su volumen. Para obtener más información, consulte Modos de acceso al volumen persistente.

Volumen efímero

El volumen efímero es la opción preferida para el búfer de mensajes.

Para el volumen efímero, siga los consejos de la sección Consideraciones para proveedores de almacenamiento .

El valor de la propiedad ephemeralVolumeClaimSpec se utiliza como propiedad ephemeral.volumeClaimTemplate.spec del volumen en las especificaciones StatefulSet de las cadenas del back-end.

Por ejemplo, para usar un volumen efímero con una capacidad de 1 gigabyte, especifique los parámetros siguientes en el recurso de Broker:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

Volumen persistente

El volumen persistente es la siguiente opción preferida para el búfer de mensajes después del volumen efímero.

Para el volumen persistente, siga los consejos de la sección Consideraciones para proveedores de almacenamiento .

El valor de la propiedad persistentVolumeClaimSpec se utiliza como propiedad volumeClaimTemplates.spec de las especificaciones StatefulSet de las cadenas del back-end.

Por ejemplo, para usar un volumen persistente con una capacidad de 1 gigabyte, especifique los parámetros siguientes en el recurso de Broker:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "persistentVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

volumen emptyDir

Un volumen emptyDir es la opción menos preferida después del volumen persistente.

Utilice un volumen emptyDir solo cuando utilice un clúster con cuotas del sistema de archivos. Para obtener más información, consulte la pestaña de cuota de proyecto del sistema de archivos. Si la característica no está habilitada, el clúster realiza un análisis periódico que no impone límites y permite que el nodo del host llene el espacio en disco y marca el nodo del host completo como incorrecto.

Por ejemplo, para usar un emptyDir volumen con una capacidad de 1 gigabyte, especifique los parámetros siguientes en el recurso de Broker:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G"
  }
}

Consideraciones para proveedores de almacenamiento

Considere el comportamiento del proveedor de almacenamiento elegido, por ejemplo, cuando use proveedores como rancher.io/local-path. Si el proveedor no admite límites, rellenar el volumen consume el espacio en disco del nodo. Este comportamiento podría provocar que Kubernetes marque el nodo y todos los pods asociados como no saludables. Es fundamental comprender cómo se comporta el proveedor de almacenamiento en estos escenarios.

Tip

Al especificar una plantilla de notificación de volumen efímero (EVC) o notificación de volumen persistente (PVC), puede usar una clase de almacenamiento de su elección, lo que aumenta la flexibilidad para algunos escenarios de implementación. Por ejemplo, los volúmenes persistentes aprovisionados mediante una plantilla de PVC aparecen en comandos como kubectl get pv, lo que resulta útil para inspeccionar el estado del clúster.

Si los nodos de Kubernetes carecen de suficiente espacio en disco local para el búfer de mensajes, use una clase de almacenamiento que proporcione almacenamiento de red como Azure Blob Storage. Es mejor usar un disco local con un valor más pequeño maxSize porque el búfer de mensajes se beneficia del acceso rápido y no requiere durabilidad.

Disabled

Si no desea usar el búfer de mensajes almacenado en disco, no incluya la propiedad diskBackedMessageBufferSettings en su recurso Broker. Este comportamiento también es el valor predeterminado.

Búfer de disco frente a persistencia

El búfer de mensajes basado en disco y la persistencia del broker escriben datos en disco, pero cumplen funciones diferentes:

Feature Búfer de mensajes respaldados por disco Persistencia
propósito Desbordar colas de suscriptores de memoria a disco cuando crecen demasiado Conservar el estado crítico del broker (mensajes retenidos, sesiones y suscripciones) tras reinicios del pod
Durability Efímero: los datos se pierden cuando se cierra el pod Duradero: los datos sobreviven a los reinicios del pod
Cuándo se deben usar Suscriptores lentos, sesiones persistentes sin conexión, interrupciones de conectividad en la nube Es necesario que los mensajes retenidos o el estado de la sesión se conserven tras los reinicios del broker.
Ámbito de datos PUBLICAR mensajes en colas de suscriptores Mensajes retenidos, metadatos de la cola de suscriptores, datos del almacén de estado
Configuración diskBackedMessageBuffer en el recurso Broker Configuración de persistencia en tiempo de ejecución o implementación

Note

El búfer de disco y la persistencia se pueden usar juntos. La persistencia garantiza que el estado sobrevive a los reinicios, mientras que el búfer de disco evita condiciones de memoria insuficiente durante el funcionamiento normal.

Pasos siguientes

  • Last updated on