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

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 almacenar en búfer mensajes con respaldo en disco se usa para administrar eficazmente las colas de mensajes dentro del corredor MQTT distribuido. 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 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 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 cuando se reconectan. 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. Si al menos un pod de cada cadena de back-end permanece funcional, el corredor en su conjunto no pierde ningún dato.
• Manejar 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 corredor MQTT de Azure Event Grid debido a la desconexión de la red. En estos escenarios, los mensajes (PUBLISHes) se acumulan. El corredor 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 corredor.

Opciones de configuración

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

Para empezar, prepare un archivo de configuración de Corredor 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 opción es la menos preferida debido a las limitaciones del volumenemptyDir.

{
  "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 la Clase de almacenamiento 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:

• El volumen efímero es la opción preferida.
• Volumen persistente es la siguiente opción preferida.
• Volumen emptyDir es la opción menos preferida.

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

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 puede ser útil para inspeccionar el estado del clúster.

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

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

Para usar el almacenamiento en búfer de mensajes con respaldo en disco, implemente Operaciones de IoT mediante el comando az iot ops create con la marca --broker-config-file. Consulte el comando siguiente. (en aras de la concisión se omiten otros parámetros).

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 almacenamiento en búfer de mensajes con respaldo en disco, vuelva a implementar la instancia de Operaciones de IoT.

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 almacenamiento en búfer de mensajes después de volumen efímero.

Para volumen persistente, siga los consejos de la sección Consideraciones para 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 un volumen emptyDir solo cuando use un clúster con cuotas del filesystem. Para obtener más información, consulte los detalles en la pestaña Cuota de proyecto del filesystem. 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 incorrecto.

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

{
  "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. 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 comportamiento también es el valor 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. 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.