Compartir por

Configuración de los valores principales del agente MQTT

  • Artigo

Importante

Versión preliminar de operaciones de Azure IoT: habilitada por Azure Arc está actualmente en versión preliminar. No se debería usar este software en versión preliminar en entornos de producción.

Deberá implementar una nueva instalación de Azure IoT Operations cuando esté disponible una versión general. No podrá actualizar una instalación de versión preliminar.

Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.

El recurso Broker es el recurso principal que define la configuración general del agente MQTT. También determina el número y el tipo de pods que ejecutan la configuración de Agente, como los front-end y los back-end. También puede usar el recurso Agente para configurar su perfil de memoria. Los mecanismos de recuperación automática están integrados en el agente y suelen recuperarse automáticamente de los errores de los componentes. Por ejemplo, se produce un error en un nodo en un clúster de Kubernetes configurado para alta disponibilidad.

Puede escalar horizontalmente el agente MQTT agregando más réplicas de front-end y cadenas de back-end. Las réplicas de front-end son responsables de aceptar conexiones MQTT de clientes y reenviarlas a las cadenas de back-end. Las cadenas de back-end son responsables de almacenar y entregar mensajes a los clientes. Los pods de front-end distribuyen el tráfico de mensajes entre los pods de back-end y el factor de redundancia de back-end determina el número de copias de datos para proporcionar resistencia frente a errores de nodo en el clúster.

Para obtener una lista de la configuración disponible, consulte la referencia de la API de Broker.

Configuración de las opciones de escalado

Importante

En este momento, el recurso agente solo se puede configurar en tiempo de implementación inicial mediante la CLI de Azure, el Portal o la acción de GitHub. Se requiere una nueva implementación si se necesitan cambios de configuración de agente.

Para configurar la configuración de escalado del agente MQTT, debe especificar los campos de cardinality en la especificación del Broker recurso personalizado. Para más información sobre cómo establecer el modo y la configuración de cardinalidad mediante la CLI de Azure, consulte az iot ops init.

El campo cardinality es un campo anidado que tiene estos subcampos:

  • frontend: este subcampo define la configuración de los pods de front-end, como:
    • replicas: número de pods de front-end que se van a implementar. Este subcampo es necesario si el campo mode está establecido en distributed.
    • workers: número de trabajos que se implementará por front-end, Actualmente, debe establecerse en 1. Este subcampo es necesario si el campo mode está establecido en distributed.
  • backendChain: este subcampo define la configuración de las cadenas de back-end, como:
    • redundancyFactor: número de copias de datos en cada cadena de back-end. Este subcampo es necesario si el campo mode está establecido en distributed.
    • partitions: número de particiones que se van a implementar. Este subcampo es necesario si el campo mode está establecido en distributed.
    • workers: número de trabajos que se implementará por back-end, Actualmente, debe establecerse en 1. Este subcampo es necesario si el campo mode está establecido en distributed.

Si cardinality se omite el campo, el operador de agente MQTT determina automáticamente la cardinalidad que implementa automáticamente el número adecuado de pods en función del hardware del clúster.

Para configurar la configuración de escalado del agente MQTT, debe especificar los campos mode y cardinality en la especificación del Broker recurso personalizado. Para más información sobre cómo establecer el modo y la configuración de cardinalidad mediante la CLI de Azure, consulte az iot ops init.

Configuración del perfil de memoria

Importante

En este momento, el recurso agente solo se puede configurar en tiempo de implementación inicial mediante la CLI de Azure, el Portal o la acción de GitHub. Se requiere una nueva implementación si se necesitan cambios de configuración de agente.

Para configurar la configuración del perfil de memoria MQTT broker, especifique los campos memoryProfile en la especificación del Agente recurso personalizado. Para más información sobre cómo establecer la configuración del perfil de memoria mediante la CLI de Azure, consulte az iot ops init.

memoryProfile: este subcampo define la configuración del perfil de memoria. Hay algunos perfiles para el uso de memoria que puede elegir:

Pequeño

Al usar este perfil:

  • El uso máximo de memoria de cada réplica de front-end es aproximadamente 99 MiB, pero el uso de memoria máximo real podría ser mayor.
  • El uso máximo de memoria de cada réplica de back-end es aproximadamente 102 MiB, pero el uso máximo real de memoria podría ser mayor.

Recomendaciones al usar este perfil:

  • Solo se debe usar un front-end.
  • Los clientes no deben enviar paquetes grandes. Solo debe enviar paquetes menores de 4 MiB.

Bajo

Al usar este perfil:

  • El uso máximo de memoria de cada réplica de front-end es aproximadamente 387 MiB, pero el uso máximo real de memoria podría ser mayor.
  • El uso máximo de memoria de cada réplica de back-end es aproximadamente 390 MiB multiplicado por el número de trabajos de back-end, pero el uso máximo real de memoria podría ser mayor.

Recomendaciones al usar este perfil:

  • Solo se deben usar uno o dos front-end.
  • Los clientes no deben enviar paquetes grandes. Solo debe enviar paquetes menores de 10 MiB.

Media

El medio es el perfil predeterminado.

  • El uso máximo de memoria de cada réplica de front-end es de aproximadamente 1,9 GiB, pero el uso máximo real de memoria podría ser mayor.
  • El uso máximo de memoria de cada réplica de back-end es aproximadamente de 1,5 GiB multiplicado por el número de trabajos back-end, pero el uso de memoria máximo real podría ser mayor.

Alto

  • El uso máximo de memoria de cada réplica de front-end es de aproximadamente 4,9 GiB, pero el uso de memoria máximo real podría ser mayor.
  • El uso máximo de memoria de cada réplica de back-end es de aproximadamente 5,8 GiB multiplicado por el número de trabajos back-end, pero el uso máximo real de memoria podría ser mayor.

Agente predeterminado

De forma predeterminada, la versión preliminar de Operaciones de IoT de Azure implementa un recurso de agente predeterminado denominado broker. Se implementa en el espacio de nombres azure-iot-operations con la cardinalidad y la configuración del perfil de memoria tal como se configura durante la implementación inicial con Azure Portal o la CLI de Azure. Para ver la configuración, ejecute el siguiente comando:

kubectl get broker broker -n azure-iot-operations -o yaml

Modificación del agente predeterminado mediante la reimplementación

Solo cardinalidad y perfil de memoria son configurables con el portal de Azure o Azure CLI durante la implementación inicial. Otras opciones y solo se pueden configurar modificando el archivo YAML y reimplementando el agente.

Para eliminar el agente predeterminado, ejecute el siguiente comando:

kubectl delete broker broker -n azure-iot-operations

A continuación, cree un archivo YAML con la configuración deseada. Por ejemplo, el siguiente archivo YAML configura el agente con el nombre broker en el espacio de nombres azure-iot-operations con perfil de memoria medium y modo distributed con dos réplicas de front-end y dos cadenas de back-end con dos particiones y dos trabajos cada uno. Además, el cifrado de la opción de tráfico interno está deshabilitado.

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: Broker
metadata:
  name: broker
  namespace: azure-iot-operations
spec:
  memoryProfile: medium
  cardinality:
    backendChain:
      partitions: 2
      redundancyFactor: 2
      workers: 2
    frontend:
      replicas: 2
      workers: 2
  encryptInternalTraffic: false

A continuación, ejecute el siguiente comando para implementar el agente:

kubectl apply -f <path-to-yaml-file>

Configuración avanzada del agente MQTT

La configuración avanzada del agente incluye configuraciones de cliente, cifrado del tráfico interno y rotaciones de certificados. Para obtener más información sobre la configuración avanzada, consulte la referencia de la API de Broker.

Este es un ejemplo de un Agente con la configuración avanzada:

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: Broker
metadata:
  name: broker
  namespace: azure-iot-operations
spec:
  advanced:
    clients:
        maxSessionExpirySeconds: 282277
        maxMessageExpirySeconds: 1622
        subscriberQueueLimit:
          length: 1000
          strategy: DropOldest
        maxReceiveMaximum: 15000
        maxKeepAliveSeconds: 300
    encryptInternalTraffic: Enabled
    internalCerts:
      duration: 240h
      renewBefore: 45m
      privateKey:
        algorithm: Rsa2048
        rotationPolicy: Always

Configuración de los valores de diagnóstico del agente MQTT

La configuración de diagnóstico le permite habilitar las métricas y el seguimiento para el agente MQTT.

  • Las métricas proporcionan información sobre el uso de recursos y el rendimiento del agente MQTT.
  • El seguimiento proporciona información detallada sobre las solicitudes y respuestas controladas por el agente MQTT.

Para invalidar la configuración de diagnóstico predeterminada para el agente MQTT, actualice la sección spec.diagnostics del recurso Broker. Ajuste el nivel de registro para controlar la cantidad y los detalles de la información registrada. El nivel de registro se puede establecer para distintos componentes del agente MQTT. El nivel de registro predeterminado es info.

Puede configurar diagnósticos mediante Broker definición de recursos personalizados (CRD). Para obtener más información sobre la configuración de diagnóstico, consulte la referencia de la API del Broker.

Este es un ejemplo de un Broker recurso personalizado con métricas y seguimiento habilitado y autoprotección deshabilitado:

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: Broker
metadata:
  name: broker
  namespace: azure-iot-operations
spec:
  diagnostics:
    logs:
      level: "debug"
      opentelemetryExportConfig:
        otlpGrpcEndpoint: "endpoint"
    metrics:
      opentelemetryExportConfig:
        otlpGrpcEndpoint: "endpoint"
        intervalSeconds: 60
    selfCheck:
      mode: Enabled
      intervalSeconds: 120
      timeoutSeconds: 60
    traces:
      cacheSizeMegabytes: 32
      mode: Enabled
      opentelemetryExportConfig:
        otlpGrpcEndpoint: "endpoint"
      selfTracing:
        mode: Enabled
        intervalSeconds: 120
      spanChannelCapacity: 1000

Configuración del cifrado del tráfico interno

Importante

En este momento, esta característica no se puede configurar mediante la CLI de Azure ni Azure Portal durante la implementación inicial. Para modificar esta configuración, debe modificar el archivo YAML y volver a implementar el agente.

La característica encryptInternalTraffic se usa para cifrar el tráfico interno entre los pods de front-end y back-end. Para usar esta característica, cert-manager debe instalarse en el clúster, que se instala de forma predeterminada cuando se usa Azure IoT Operations.

Entre las ventajas se encuentran las siguientes:

  • Proteger el tráfico interno: todo el tráfico interno entre el front-end y los pods back-end se cifra.

  • Proteger datos en reposo: todos los datos en reposo se cifran.

  • Proteger datos en tránsito: todos los datos en tránsito se cifran.

  • Proteger datos en memoria: todos los datos en memoria están cifrados.

  • Proteger datos en el búfer de mensajes: todos los datos del búfer de mensajes se cifran.

  • Proteger datos en el búfer de mensajes en el disco: todos los datos del búfer de mensajes en el disco están cifrados.

De forma predeterminada, la característica encryptInternalTraffic está habilitada. Para desactivar la función, establezca el campo encryptInternalTraffic en false en la especificación del recurso personalizado Agente al volver a implementar el agente.

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

Importante

En este momento, esta característica no se puede configurar mediante la CLI de Azure ni Azure Portal durante la implementación inicial. Para modificar esta configuración, debe modificar el archivo YAML y volver a implementar el agente.

La característica diskBackedMessageBufferSettings 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 diskBackedMessageBufferSettings 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.

Comprender y configurar la característica diskBackedMessageBufferSettings mantiene un sistema de puesta en cola de mensajes sólido y confiable. La configuración adecuada es importante en escenarios en los que la velocidad de procesamiento de mensajes y la conectividad son factores críticos.

Opciones de configuración

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 persistente 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.

El volumen efímero es la opción preferida. Se prefiere el volumen Persistente después del volumen emptyDir. Por lo general, las mismas clases de almacenamiento proporcionan tanto el volumen persistente como el volumen efímero. Si tiene ambas opciones, elija efímero. Sin embargo, efímero requiere Kubernetes 1.23 o posterior.

Deshabilitado

Si no desea usar el búfer de mensajes respaldado por disco, no incluya la propiedad diskBackedMessageBufferSettings en el Agente CRD.

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 efímeroVolumeClaimSpec se usa como efímero. La propiedad 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 CRD:

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 back-end.

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

diskBackedMessageBuffer:
  maxSize: "1G"
  persistentVolumeClaimSpec:
    storageClassName: "foo"
    accessModes:
    - "ReadWriteOnce"

Volumen emptyDir

Use un volumen emptyDir. Un volumen emptyDir es la siguiente opción 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 agente CRD:

      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.

Persistencia

Es importante comprender que la característica de diskBackedMessageBufferSettings 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.