Compartir a través de

Configuración del comportamiento del búfer de mensajes con respaldo en disco

  • Artículo

Importante

Esta configuración requiere modificar el recurso de Broker y solo se puede configurar en el momento de 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 más información, consulte Personalización del agente predeterminado.

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

  • Administración eficaz de colas: en un agente MQTT, cada suscriptor está asociado a una cola de mensajes. La velocidad a la que un suscriptor procesa los mensajes 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 búfer de mensajes con respaldo en disco garantiza que cuando una cola supera la memoria disponible, se almacena 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 tras la reconexión. El disco se usa como almacenamiento efímero y actúa como desbordamiento de memoria. Los datos escritos en el disco no son duraderos y se pierden cuando se cierra el pod, pero siempre que al menos un pod de cada cadena de back-end permanezca funcional, el agente en su conjunto no pierde ningún dato.

  • Controlar 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 se pueden comunicar con sistemas externos, como el agente MQTT de Event Grid debido a la desconexión de la 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 de los mensajes.

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

La configuración del búfer de mensajes con respaldo en disco es esencial para mantener un sistema de puesta en cola de mensajes sólido y confiable, especialmente en escenarios en los que la velocidad de procesamiento de mensajes y la conectividad son críticas.

Nota:

El corredor MQTT escribe datos en el disco exactamente como se recibe de los clientes, sin cifrado adicional. Proteger el disco es esencial para proteger los datos almacenados por el agente.

Opciones de configuración

Para configurar el búfer de mensajes con respaldo en disco, edite la sección diskBackedMessageBuffer del recurso Broker. Actualmente, esto solo se admite con la marca --broker-config-file al implementar las Operaciones de IoT de Azure mediante el comando az iot ops create.

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

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 valor maxSize se usa como límite de tamaño del volumen de emptyDir. Pero esta es la opción menos preferida que proporciona las limitaciones del volumen emptyDir.

{
  "diskBackedMessageBuffer": {
    "maxSize": "<SIZE>"
  }
}

Para obtener una mejor configuración del búfer de mensajes con respaldo en disco, especifique una notificación de volumen efímero o de volumen persistente para montar un volumen de almacenamiento dedicado para el búfer de mensajes. Por ejemplo:

{
  "diskBackedMessageBuffer": {
    "maxSize": "<SIZE>",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "<NAME>",
      "accessModes": [
        "<MODE>"
      ]
    }
  }
}

{
  "persistentVolumeClaimSpec": {
    "maxSize": "<SIZE>",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "<NAME>",
      "accessModes": [
        "<MODE>"
      ]
    }
  }
}

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

  • Configurar el volumen: especifique una plantilla de notificación de volumen para montar un volumen de almacenamiento dedicado para el búfer de mensajes.

  • Seleccione una clase de almacenamiento: defina StorageClass deseada mediante la propiedad storageClassName.

  • Definir modos de acceso: determine los modos de acceso que necesita para el volumen. Para obtener más información, consulte modos de acceso al volumen persistente.

Use las secciones siguientes para comprender los distintos modos de volumen:

Por lo general, las mismas clases de almacenamiento proporcionan tanto el volumen persistente como el volumen efímero. Si ambas opciones están disponibles, elija efímero. Tenga en cuenta que los volúmenes efímeros requieren Kubernetes 1.23 o posterior.

Sugerencia

Especificar una plantilla de notificación de volumen efímero (EVC) o notificación de volumen persistente (PVC) le permite 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 (PVs) aprovisionados mediante una plantilla de PVC aparecen en comandos como kubectl get pv, lo que puede ser ú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 Blobs de Azure. Sin embargo, generalmente es mejor usar el disco local con un valor maxSize más pequeño, ya que el búfer de mensajes se beneficia del acceso rápido y no requiere durabilidad.

Implementación de Operaciones de IoT de Azure con búfer de mensajes con copia de seguridad en disco

Para usar el búfer de mensajes con respaldo en disco, implemente Operaciones de IoT de Azure mediante el comando az iot ops create con la marca --broker-config-file. Consulte el siguiente comando (se omiten otros parámetros para mayor brevedad):

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

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 de Azure.

Volumen efímero

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

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

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

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

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

El volumen-persistente.

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

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

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

Por ejemplo, para usar un volumen persistente con una capacidad de 1 gigabyte, especifique los parámetros siguientes en el recurso 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.

Use solo el volumen emptyDir cuando se usa un clúster con cuotas del sistema de archivos. Para obtener más información, consulte los detalles en la pestaña Cuota de proyecto del sistema de archivos. Si la característica no está habilitada, el clúster realiza una exploración periódica que no impone ningún límite y permite que el nodo anfitrión llene el espacio del disco y marque todo el nodo anfitrión como no saludable.

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

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

Consideraciones para proveedores de almacenamiento

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

Deshabilitado

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

Persistencia

Es importante comprender que la característica de búfer de mensajes con respaldo en disco no es sinónimo de persistencia. En este contexto, persistencia hace referencia a los datos que sobrevive en los reinicios del pod. Sin embargo, esta característica proporciona espacio de almacenamiento temporal para que los datos se guarden en el disco, lo que evita los desbordamientos de memoria y la pérdida de datos durante los reinicios del pod.