Compartir a través de

Agente MQTT local integrado de operaciones de IoT de Azure

Importante

En esta página se incluyen instrucciones para administrar componentes de Operaciones de IoT de Azure mediante manifiestos de implementación de Kubernetes, que se encuentra en versión preliminar. Esta característica se proporciona con varias limitacionesy no se debe usar para cargas de trabajo de producción.

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.

Azure IoT Operations incluye un agente MQTT que cumple con los estándares y es de nivel empresarial. El agente MQTT es escalable, de alta disponibilidad y nativo de Kubernetes. Proporciona el plano de mensajería para operaciones de IoT, permite la comunicación perimetral bidireccional a la nube y admite aplicaciones controladas por eventos en el perímetro.

Cumplimiento de MQTT

MQTT es un protocolo común en el espacio de IoT. Su diseño sencillo permite que un único agente sirva a miles de clientes simultáneamente con la creación y administración ligeras de temas de publicación y suscripción. Muchos dispositivos IoT admiten MQTT de forma nativa. Las puertas de enlace descendentes convierten varios protocolos de IoT a MQTT.

El agente MQTT admite la capa de mensajería en operaciones de IoT y es compatible con MQTT v3.1.1 y MQTT v5. Para obtener más información acerca de las características MQTT compatibles, consulte Compatibilidad de características MQTT en Corredor MQTT.

Arquitectura

El agente MQTT tiene dos capas principales:

  • Capa de front-end sin estado
  • Capa de back-end con estado y particionada

La capa de front-end controla las conexiones de cliente y las solicitudes, y las enruta al back-end. La capa de back-end divide los datos por claves, como un identificador de cliente para las sesiones de cliente y un nombre de tema para los mensajes de tema. La capa de back-end usa la replicación en cadena para copiar datos dentro de cada partición.

Los objetivos de esta arquitectura son:

  • Tolerancia a errores y aislamiento: la publicación de mensajes continúa si se produce un error en los pods de back-end y los errores no se propagan al resto del sistema.
  • Recuperación de errores: recuperación automática de errores sin intervención del operador.
  • Sin pérdida de mensajes: los mensajes se entregan si se ejecutan al menos un pod de front-end y un pod back-end en una partición.
  • Escalado elástico: el escalado horizontal del rendimiento de publicación y suscripción admite implementaciones perimetrales y en la nube.
  • Rendimiento coherente a escala: limita la sobrecarga de latencia de mensajes debido a la replicación en cadena.
  • Simplicidad operativa: reduce la dependencia de los componentes externos para simplificar el mantenimiento y la complejidad.

Configuración

Para la configuración, el agente MQTT usa varios recursos personalizados de Kubernetes para definir distintos aspectos del comportamiento y la funcionalidad del agente:

  • El recurso principal es Broker, que define la configuración global, como cardinalidad, perfil de uso de memoria y configuración de diagnóstico.
  • Un recurso de corredor puede tener hasta tres BrokerListeners, cada uno de los cuales escucha las conexiones MQTT entrantes en el tipo de servicio especificado (NodePort, LoadBalancer o ClusterIP). Cada BrokerListener puede tener varios puertos.
  • Cada puerto dentro de un recurso de BrokerListener se puede asociar a un recurso de BrokerAuthentication y a un recurso de BrokerAuthorization. Estas directivas de autenticación y autorización determinan qué clientes pueden conectarse al puerto y qué acciones pueden realizar en el corredor.

La relación entre Broker y BrokerListener es de una a muchas, mientras que la relación entre BrokerListener y BrokerAuthentication/BrokerAuthorization es de muchas a muchas. El diagrama de relación de entidades para estos recursos es el siguiente:

Diagrama que muestra el modelo de recursos del corredor.

Por defecto, las Operaciones de IoT implementan un Broker predeterminado, un BrokerListener predeterminado y un BrokerAuthentication predeterminado. Todos estos recursos se denominan valor predeterminado. Juntos, estos recursos proporcionan una configuración básica del corredor MQTT necesaria para que las Operaciones de IoT funcionen. La configuración predeterminada es la siguiente:

Diagrama que muestra los recursos de corredor predeterminados y las relaciones entre ellos.

Importante

Para evitar interrumpir la comunicación entre los componentes internos de IoT Operations, no modifique ninguna configuración predeterminada.

Para personalizar la implementación del agente MQTT, agregue nuevos recursos como BrokerListeners, BrokerAuthentication y BrokerAuthorization al agente predeterminado.

El recurso broker es inmutable y no se puede modificar después de la implementación, pero solo requiere personalización en escenarios avanzados. Para obtener más información sobre cómo personalizar el recurso de Broker, consulte Personalizar el agente predeterminado.

En una implementación completa, podría tener varios BrokerListeners, cada uno con varios puertos y cada puerto podría tener distintos recursos BrokerAuthentication y BrokerAuthorization asociados.

Por ejemplo, a partir de la configuración predeterminada, agregue:

  • Un LoadBalancer BrokerListener denominado example-lb-listener con los dos puertos 1883 y 8883.
  • Un NodePort BrokerListener denominado example-nodeport-listener con un único puerto 1884 (nodePort 31884).
  • Un recurso BrokerAuthentication denominado example-authn, con un método de autenticación personalizado.
  • Un recurso BrokerAuthorization denominado example-authz, con la configuración de autorización personalizada.

Si configura todos los puertos nuevos con los mismos recursos BrokerAuthentication y BrokerAuthorization, la configuración tiene este aspecto:

Diagrama que muestra una implementación completa del corredor personalizado y las relaciones entre cada uno.

Este enfoque mantiene intacta la configuración predeterminada y le permite agregar nuevos recursos para personalizar la implementación del agente MQTT.

Recurso de Broker predeterminado

Cada despliegue de operaciones IoT solo puede tener un único broker, y debe tener el nombre predeterminado. El recurso de agente predeterminado es necesario para que las operaciones de IoT funcionen. Es inmutable y no se puede modificar después de la implementación.

Precaución

No elimine el recurso de bróker predeterminado. Al hacerlo, se interrumpe la comunicación entre los componentes internos de Operaciones de IoT y la implementación deja de funcionar.

Personalización del agente predeterminado

La personalización del recurso de agente predeterminado no es necesaria para la mayoría de las configuraciones. La configuración que requiere personalización incluye:

  • Cardinalidad: determina la capacidad del agente para controlar más conexiones y mensajes, y mejora la alta disponibilidad si hay errores de pod o nodo.
  • Perfil de memoria: establece el uso máximo de memoria del agente y cómo controlar el uso de memoria a medida que el agente se escala verticalmente.
  • Búfer de mensajes con copia de seguridad en disco: configuración para almacenar en búfer los mensajes en el disco a medida que la RAM se rellena.
  • Configuración de diagnóstico: configuración para la configuración de diagnóstico, como el nivel de registro y el punto de conexión de métricas.
  • Opciones avanzadas de cliente MQTT: configuración para opciones avanzadas de cliente MQTT, como la expiración de la sesión, la expiración de mensajes y la configuración de mantenimiento activo.
  • Cifrado del tráfico interno: configuración para cifrar el tráfico interno entre el front-end del agente y los pods de back-end.

Puede personalizar el agente predeterminado solo durante la implementación inicial mediante la CLI de Azure o Azure Portal. Se requiere una nueva implementación si necesita diferentes opciones de configuración del broker.

Para personalizar el agente predeterminado durante la implementación:

Cuando siga la guía para implementar Operaciones de IoT, en la sección Configuración, busque en Configuración del corredor MQTT. Aquí puede personalizar la cardinalidad y la configuración del perfil de memoria. Para configurar otras opciones, incluido el búfer de mensajes respaldados por disco y las opciones avanzadas de cliente MQTT, use la CLI de Azure.

Importante

No se puede actualizar el recurso de agente después de la implementación inicial. Los cambios de configuración en la cardinalidad, el perfil de memoria o el búfer de disco no se permiten después de la implementación.

Como solución alternativa, al implementar operaciones de Azure IoT con el comando az iot ops init, puede incluir el parámetro --broker-config-file con un archivo de configuración JSON para el agente MQTT. Para obtener más información, vea Configuración avanzada del agente MQTT y Configuración de la configuración básica del agente MQTT.

Ver la configuración predeterminada del Agente

Para ver la configuración del agente predeterminado:

  1. En Azure Portal, vaya a la instancia de operaciones de IoT.
  2. En Componentes, seleccione MQTT Broker.
  3. En detalles del Agente, seleccione vista JSON.

Contenido relacionado