Planeación de la implementación para Operaciones de IoT de Azure

Muchas configuraciones de Operaciones de IoT de Azure se establecen en el momento de la implementación y solo se pueden cambiar volviendo a implementar. Antes de implementarlo, planee la topología del clúster, la cardinalidad del agente, el perfil de memoria y la configuración de agente opcional que necesita. En este artículo se resumen las decisiones que debe tomar.

Descripción de la arquitectura

Operaciones de IoT de Azure es un conjunto de servicios modulares nativos de Kubernetes implementados en un clúster habilitado para Azure Arc. Los componentes clave incluyen:

Se usan dos términos en toda la documentación:

• Implementación : la instancia, las extensiones de Arc, las ubicaciones personalizadas y todos los recursos configurables (recursos, dispositivos, flujos de datos).
• Instancia : el recurso primario que agrupa los servicios.

Elección de la topología del clúster

Antes de realizar la implementación, decida si necesita un clúster de un solo nodo o de varios nodos. Esta decisión determina los requisitos de hardware y la configuración de cardinalidad del broker.

Comprender la cardinalidad del bróker

La cardinalidad es el número de réplicas del front-end, trabajos del front-end, particiones del back-end y trabajos del back-end en el despliegue del broker. La cardinalidad controla cómo el broker puede escalar horizontalmente y su resiliencia frente a fallos de pods o nodos.

El agente MQTT tiene una arquitectura de dos niveles: los pods de front-end controlan las conexiones de cliente y el procesamiento de protocolos, mientras que los pods back-end controlan el almacenamiento y la entrega de mensajes. Comprender cómo se escala cada nivel es importante para el planeamiento de la capacidad.

Frontend

Los pods de front-end aceptan conexiones de cliente MQTT y reenván mensajes al back-end. Los pods de front-end no almacenan los mensajes por sí mismos. Hay dos configuraciones principales para el nivel de front-end:

• Réplicas: número de pods del front-end que se van a implementar. Agregar más réplicas del front-end aumenta el número de conexiones simultáneas de clientes que el broker puede controlar y proporciona alta disponibilidad si falla uno de los pods del front-end.
• Trabajos: número de trabajos lógicos por pod del front-end. Agregar más trabajos permite al pod del front-end usar más núcleos de CPU. Cada trabajador puede consumir hasta un núcleo de CPU.

Cadena de back-end

Los pods de backend se encargan del almacenamiento y la entrega de mensajes. Hay tres configuraciones principales para el nivel de back-end:

• Particiones: el número de particiones que se van a implementar. Las particiones son la unidad de escalado horizontal para el rendimiento del mensaje. A través de un proceso denominado particionamiento, cada partición controla una parte de los mensajes, particionados por tema y sesión. Los pods de front-end distribuyen el tráfico de mensajes entre las particiones. Añadir más particiones aumenta el rendimiento total de mensajes que el broker puede gestionar.
• Factor de redundancia: El número de pods de backend que se deben desplegar por partición. Aumentar el factor de redundancia aumenta el número de copias de datos para proporcionar resistencia frente a errores de nodo en el clúster.
• Trabajos: número de trabajos por pod del back-end. Los trabajos son la unidad de escalado vertical dentro de una partición: agregar más trabajos permite que el pod del back-end use más núcleos de CPU en el mismo nodo. Cada proceso de trabajo puede consumir hasta dos núcleos de CPU, así que tenga cuidado al aumentar el número de procesos de trabajo por réplica para no superar el número de núcleos de CPU del clúster.

Estimación del rendimiento

El rendimiento de una partición individual depende en gran medida de las características de CPU del nodo en el que se ejecuta. Como regla general, se espera aproximadamente de 5000 a 6000 mensajes QoS 1 por segundo por partición con cargas de 8 KB en una CPU de 2 GHz (~4 GHz turbo). El rendimiento real depende de muchos factores, por lo que usa este número solo como punto de partida para el planeamiento de la capacidad.

Para obtener datos de pruebas comparativas detalladas, consulte Pruebas comparativas de rendimiento de MQTT Broker.

Recomendaciones de nodo único

• Réplicas de la interfaz: Ajústelo a 1.
• Trabajos de front-end: se establece en la mitad del número de núcleos de CPU por nodo.
• Réplicas del backend (factor de redundancia): establézcalas en al menos 2 para que el broker pueda realizar actualizaciones continuas.

Ejemplo: nodo único, 4 núcleos de CPU

Recomendaciones de varios nodos

Se recomiendan los siguientes valores para obtener un rendimiento óptimo. En el caso de clústeres de gran tamaño con tráfico bajo, estos valores se pueden establecer más bajos que las recomendaciones sin causar problemas. En las secciones siguientes se describen más consideraciones, como la memoria (RAM) y las características de rendimiento. Pruebe siempre la configuración con la carga de trabajo esperada para confirmar el rendimiento.

• Réplicas de frontend: establézcalo en un valor igual al número de nodos del clúster.
• Trabajos de front-end: se establece en la mitad del número de núcleos de CPU por nodo.
• Réplicas de backend (factor de redundancia): Establézcalo en 2 para la redundancia y para admitir actualizaciones graduales.
• Particiones de servidor: Establézcalas en un valor igual al número de nodos del clúster.
• Trabajos de back-end: se establece en la mitad del número de núcleos de CPU por nodo.

Ejemplo: clúster de 3 nodos, 8 núcleos de CPU por nodo

Ejemplo: clúster de 5 nodos, 16 núcleos de CPU por nodo

Límites de recursos de CPU

Para evitar el agotamiento de recursos en el clúster, el agente se puede configurar para solicitar límites de recursos de CPU de Kubernetes en función de la configuración de cardinalidad. Cuando se habilita, el escalado del número de réplicas o trabajos aumenta proporcionalmente los recursos de CPU necesarios.

El valor predeterminado para las plantillas de API REST, Bicep y ARM se define en la especificación de la API de Broker.

El broker de MQTT solicita recursos de CPU por pod en función del número de trabajadores configurados:

• Pods de front-end: 1,0 CPU por trabajador
• Pods de back-end: 2,0 CPU por trabajo

Use las fórmulas siguientes para calcular los requisitos totales de CPU:

Ejemplo: clúster pequeño

Considere un clúster de 2 nodos con 4 núcleos de CPU por nodo (8 núcleos totales) con la cardinalidad siguiente:

{
  "cardinality": {
    "frontend": {
      "replicas": 2,
      "workers": 2
    },
    "backendChain": {
      "partitions": 1,
      "redundancyFactor": 2,
      "workers": 1
    }
  }
}

El agente solicita:

• CPU de front-end: 2 réplicas × 2 trabajos × 1,0 = 4,0 CPU
• CPU de back-end: 1 partición × 2 RF × 1 trabajo × 2,0 = 4,0 CPU
• CPU total del broker: 8,0 CPU

Esta configuración solicita 8,0 CPU en un clúster de solo 8 núcleos, sin dejar nada para otros componentes de Operaciones de IoT de Azure (200-300m) ni para los pods del sistema de Kubernetes. Los pods del broker permanecen en estado Pending con errores Insufficient cpu.

Para resolverlo, agregue más nodos, aumente los núcleos por nodo o reduzca la cardinalidad del intermediario.

Ejemplo: despliegue más grande

La cardinalidad siguiente solicita significativamente más recursos de CPU:

{
  "cardinality": {
    "frontend": {
      "replicas": 3,
      "workers": 2
    },
    "backendChain": {
      "partitions": 3,
      "redundancyFactor": 2,
      "workers": 2
    }
  }
}

• CPU de front-end: 3 réplicas × 2 trabajos × 1,0 = 6,0 CPU
• CPU de back-end: 3 particiones × 2 RF × 2 trabajos × 2,0 = 24,0 CPU
• CPU total del broker: 30,0 CPU

Un clúster necesita al menos 30 núcleos de CPU disponibles solamente para los pods del broker, además de capacidad adicional para otros componentes de Operaciones de IoT de Azure y los pods del sistema de Kubernetes.

Configuración del límite de recursos de CPU

Los límites de recursos de CPU están controlados por el campo generateResourceLimits.cpu del recurso Broker. Esta configuración solo se admite mediante el uso de la --broker-config-file marca al implementar Operaciones de IoT de Azure mediante el az iot ops create comando . Para obtener más información, consulte la sección sobre la compatibilidad del CLI de Azure con la configuración avanzada del agente MQTT.

Prepare un archivo de configuración de Broker siguiendo la referencia de la API GenerateResourceLimits . En los ejemplos siguientes se muestran los dos valores posibles:

{
  "generateResourceLimits": {
    "cpu": "Enabled"
  }
}

O

{
  "generateResourceLimits": {
    "cpu": "Disabled"
  }
}

Elección del perfil de memoria

El perfil de memoria controla el tamaño máximo de los mensajes MQTT que acepta el bróker, el uso de memoria inactiva y el uso máximo de memoria de cada pod. Decida el perfil de memoria adecuado antes de la implementación en función de los tamaños de mensaje esperados y el rendimiento.

Búfer entrante y represión inversa

Cada perfil de memoria define un tamaño máximo de búfer de entrada para los datos de PUBLISH por cada proceso de trabajo del backend. Cuando el búfer alcanza la capacidad de 75%, el agente activa mecanismos de contrapresión y comienza a rechazar los mensajes entrantes. Los paquetes rechazados reciben una respuesta PUBACK con un código de error Cuota superada.

La siguiente tabla muestra los tamaños de búfer de entrada por trabajador para cada perfil:

Al elegir un perfil de memoria, tenga en cuenta lo siguiente:

• Tiny: solo se debe usar un front-end. Enviar solo paquetes menores de 4 MiB.
• Bajo: solo se deben usar uno o dos front-end. Enviar solo paquetes menores de 16 MiB.
• Medio: adecuado para la mayoría de las cargas de trabajo de producción con tamaños de mensaje moderados.
• Alto: Úselo cuando necesite procesar mensajes grandes o un rendimiento elevado con búferes grandes.

La memoria total del broker depende de ambos: el perfil de memoria y la cardinalidad (número de réplicas del front-end, particiones del back-end y factor de redundancia). Más pods significan más memoria total. Para medir el consumo de recursos de línea base en distintas configuraciones, consulte Perfiles de recursos de línea base.

Cálculo del uso total de memoria

Puede calcular el uso total de memoria con esta fórmula:

M_total = (R_fe × M_fe) + (P_be × RF_be × M_be × W_be)

Where:

Por ejemplo, si elige el perfil de memoria media , el perfil tiene un uso de memoria de front-end de 1,9 GiB y un uso de memoria de back-end de 1,5 GiB. Supongamos que la configuración del agente es 2 réplicas de front-end, 2 particiones de back-end y un factor de redundancia de back-end de 2. El uso total de memoria es:

M_total = (2 × 1.9 GiB) + (2 × 2 × 1.5 GiB × 2)
        = 15.8 GiB

En comparación, el perfil de memoria Tiny tiene un uso de memoria de front-end de 99 MiB y un uso de memoria de back-end de 102 MiB. Con la misma configuración del agente, el uso total de memoria es:

M_total = (2 × 99 MiB) + (2 × 2 × 102 MiB × 2)
        = 198 MiB + 816 MiB
        = 1014 MiB (≈ 1.0 GiB)

Configuración del perfil de memoria

Al implementar operaciones de IoT mediante el az iot ops create comando , el --broker-mem-profile parámetro especifica la configuración del perfil de memoria.

Por ejemplo, el siguiente comando establece el perfil de memoria en Tiny (se omiten otros parámetros por brevedad):

az iot ops create ... --broker-mem-profile Tiny

Para más información, consulte Parámetros opcionales az iot ops create.

Configuración opcional del broker

Las siguientes opciones de agente también se configuran en el momento de la implementación y no se pueden cambiar después. Revise estos si se aplican a su escenario:

• Búfer de mensajes con respaldo en disco — Almacena los mensajes en disco cuando las colas de los suscriptores superan la memoria disponible. Resulta útil para las sesiones persistentes y los desafíos de conectividad.
• Persistencia: escriba datos críticos del broker en disco para conservarlos tras los reinicios.
• Diagnóstico — Configurar métricas, registros y sondeos de autocomprobación para el broker MQTT.
• Opciones avanzadas de MQTT : personalice la expiración de la sesión, la expiración de mensajes, los límites de la cola de suscriptores y la configuración de mantenimiento activo.
• Cifrado del tráfico interno — Configura el cifrado del tráfico interno entre el frontend del bróker y los pods de backend (activado de forma predeterminada).

Pasos siguientes

• Preparación del clúster
• Implementación en un clúster de producción
• Configuración de la observabilidad
• Asegura tu implementación