Compartir vía


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.

Operaciones de IoT de Azure incluye un corredor MQTT que es de nivel empresarial y cumple con los estándares. El corredor MQTT es escalable, de alta disponibilidad y nativo de Kubernetes. Proporciona el plano de mensajería para las Operaciones de 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

MQTT ha surgido como el lenguaje común que se usa entre los protocolos en el 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. Las puertas de enlace de traducción de bajada racionalizan la cola larga de los protocolos de IoT en MQTT.

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 un id. 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 rendimiento 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 corredor MQTT se compone de varios recursos personalizados de Kubernetes que definen distintos aspectos del comportamiento y la funcionalidad del corredor:

  • 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 uno a varios. La relación entre BrokerListener y BrokerAuthentication/BrokerAuthorization es de varios a varios. 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 interrupciones involuntarias con la comunicación entre los componentes internos de las Operaciones de IoT, se recomienda no modificar la configuración predeterminada.

Para personalizar la implementación del corredor MQTT, agregue nuevos recursos, como BrokerListeners, BrokerAuthentication y BrokerAuthorization, al corredor 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:

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

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

Diagrama que muestra una implementación completa del corredor 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 solo puede tener un corredor y debe denominarse default. El recurso de Broker 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 Broker 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 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.

Puede personalizar el corredor predeterminado solo durante el tiempo de 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, 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.
  2. En Componentes, seleccione MQTT Broker.
  3. En detalles del Agente, seleccione vista JSON.