Compartir a través de

Agente MQTT local integrado de operaciones de IoT de Azure

  • Artículo

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.

Operations de IoT de Azure cuenta con un MQTT broker de grado empresarial conforme con los estándares, que es escalable, de alta disponibilidad y nativo de Kubernetes. Proporciona el plano de mensajería para las operaciones de Azure IoT, habilita la comunicación bidireccional en el perímetro o la nube y potencia las aplicaciones controladas por eventos en el perímetro.

Cumplimiento de MQTT

El Transporte de telemetría de cola de mensajes (MQTT) ha surgido como la lengua franca entre los protocolos del espacio de IoT. El diseño sencillo de MQTT permite que un único broker atienda a decenas de miles de clientes simultáneamente, con una creación y administración ligera de temas de publicación-suscripción. Muchos dispositivos IoT admiten MQTT de forma nativa sin necesidad de configuración, con la larga cola de protocolos de IoT que se racionalizan en MQTT mediante puertas de enlace de traducción posteriores.

El MQTT broker forma la base de la capa de mensajería en Operaciones de IoT y admite 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 diferentes, como el identificador de cliente para las sesiones de cliente y el nombre del tema para los mensajes de tema. Usa la replicación en cadena para replicar los datos en 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 del back-end e impide que los errores se propaguen al resto del sistema.
  • Recuperación de errores: recuperación automática de errores sin intervención del operador.
  • No se pierde ningún mensaje: entrega de mensajes si se ejecuta al menos un pod de front-end y un pod back-end en una partición.
  • Escalado flexible: escalado horizontal del procesamiento de publicación y suscripción para sustentar implementaciones perimetrales y en la nube.
  • Rendimiento coherente a gran escala: limitar la sobrecarga de latencia de los mensajes debido a la replicación en cadena.
  • Simplicidad operativa: dependencia mínima de los componentes externos para simplificar el mantenimiento y la complejidad.

Configuración

Para la configuración, el agente MQTT se compone de varios recursos personalizados de Kubernetes que definen 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 agente 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 instancia de BrokerListener puede tener varios puertos.
  • Cada puerto dentro de BrokerListener se puede asociar a un recurso de BrokerAuthentication y un recurso BrokerAuthorization. Estas son las directivas de autenticación y autorización que determinan qué clientes pueden conectarse al puerto y qué acciones pueden realizar en el agente.

Así, la relación entre Broker y BrokerListener es de una a muchas, y la relación entre BrokerListener y BrokerAuthentication/BrokerAuthorization es de muchas a muchas. El diagrama de relaciones de entidad (ERD) para estos recursos es el siguiente:

Diagrama que muestra el modelo de recursos del agente.

Por defecto, las Operaciones de IoT de Azure 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 agente MQTT necesaria para que las Operaciones de IoT de Azure funcionen. La configuración predeterminada es la siguiente:

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

Importante

Para evitar interrupciones involuntarias con la comunicación entre los componentes internos de las Operaciones de IoT de Azure, se recomienda no modificar ninguna configuración predeterminada.

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

El propio recurso broker es inmutable y no se puede modificar después de la implementación, pero solo necesita 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:

  • LoadBalancer BrokerListener denominado example-lb-listener con dos puertos 1883 y 8883
  • 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 ejemplo-authz, con la configuración de autorización personalizada

A continuación, si configura todos los puertos nuevos, use los mismos recursos BrokerAuthentication y BrokerAuthorization, el programa de instalación tendría el siguiente aspecto:

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

De este modo, mantendrá intacta la configuración predeterminada y agregará nuevos recursos para personalizar la implementación del agente MQTT a sus necesidades.

Recurso de Broker predeterminado

Cada implementación de Operaciones de IoT de Azure solo puede tener un agente y debe denominarse valor predeterminado. El recurso de Broker predeterminado es necesario para que las Operaciones de IoT de Azure funcionen. Es inmutable y no se puede modificar después de la implementación.

Precaución

No elimine el recurso de Broker predeterminado. Si lo hace, interrumpirá la comunicación entre los componentes internos de Operaciones de IoT de Azure y la implementación dejará de funcionar.

Personalización del agente predeterminado

La personalización del recurso de Broker 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.

La personalización del agente predeterminado debe realizarse durante el tiempo de implementación inicial mediante la CLI de Azure o Azure Portal. Se requiere una nueva implementación si se necesitan diferentes opciones de configuración de Broker.

Para personalizar el agente predeterminado durante la implementación:

Cuando siga la guía para implementar Operaciones de IoT de Azure, 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, como el búfer de mensajes respaldados por disco y las opciones avanzadas del cliente MQTT, use la CLI de Azure.

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 de Azure.
  2. En Componentes, seleccione MQTT Broker.
  3. En detalles del Agente, seleccione vista JSON.

Pasos siguientes

Implementación de las Operaciones de IoT de Azure en un clúster de Kubernetes habilitado para Arc