Configuración de las opciones de agente para la alta disponibilidad, el escalado y el uso de memoria

El recurso Corredor es el recurso principal que define la configuración general del corredor 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 corredor y suelen recuperarse automáticamente de los errores de los componentes. Por ejemplo, si 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 particiones de back-end. Las réplicas de front-end son responsables de aceptar conexiones MQTT de clientes y reenviarlas a las particiones de back-end. Las particiones 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. Aumentar 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

Para configurar las opciones de escalado del corredor MQTT, especifique los campos de cardinalidad en la especificación del recurso Corredor durante la implementación de Operaciones de IoT de Azure.

Cardinalidad de implementación automática

Para determinar automáticamente la cardinalidad inicial durante la implementación, omita el campo de cardinalidad en el recurso Broker.

{
  "memoryProfile": "<MEMORY_PROFILE>"
}

az iot ops create ... --broker-config-file <FILE>.json

El operador de agente MQTT implementa automáticamente el número adecuado de pods en función del número de nodos disponibles en el momento de la implementación. Esta capacidad resulta útil para escenarios que no son de producción en los que no se necesita alta disponibilidad ni escala.

Esta capacidad no es el escalado automático. El operador no escala automáticamente el número de pods en función de la carga. El operador solo determina el número inicial de pods que se van a implementar en función del hardware del clúster. Como se indicó anteriormente, la cardinalidad solo se establece en el momento de la implementación inicial. Se requiere una nueva implementación si es necesario cambiar la configuración de cardinalidad.

Configurar la cardinalidad directamente

Para configurar los valores de cardinalidad directamente, especifique cada uno de los campos de cardinalidad.

az iot ops create ... --broker-frontend-replicas 1 --broker-frontend-workers 1  --broker-backend-part 1  --broker-backend-workers 1 --broker-backend-rf 2

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

az iot ops create ... --broker-config-file <FILE>.json

Comprender la cardinalidad

La cardinalidad significa el número de instancias de una entidad determinada en un conjunto. En el contexto del agente MQTT, la cardinalidad hace referencia al número de réplicas de front-end, particiones de back-end y trabajos de back-end que se van a implementar. La configuración de cardinalidad se usa para escalar horizontalmente el agente y mejorar la alta disponibilidad si hay errores de pod o nodo.

El campo de cardinalidad es un campo anidado, con subcampos para la cadena de front-end y back-end. Cada uno de estos subcampos tiene su propia configuración.

Front-end

El subcampo front-end define la configuración de los pods de front-end. Los dos valores principales son:

• Réplicas: número de réplicas de front-end (pods) que se van a implementar. Aumentar el número de réplicas de front-end proporciona alta disponibilidad en caso de que se produzca un error en uno de los pods de front-end.
• Trabajador: el número de trabajadores de front-end lógicos por réplica. Cada trabajador puede consumir hasta un núcleo de CPU como máximo.

Cadena de back-end

El subcampo de la cadena de back-end define la configuración de las particiones de back-end. Las tres configuraciones principales son:

• Particiones: el número de particiones que se van a implementar. A través de un proceso denominado particionamiento, cada partición es responsable de una parte de los mensajes, divididos por identificador de tema e identificador de sesión. Los pods de front-end distribuyen el tráfico de mensajes entre las particiones. Aumentar el número de particiones aumenta el número de mensajes que el agente puede controlar.
• Factor de redundancia: el número de réplicas de back-end (pods) que se van a implementar 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.
• Trabajadores: el número de trabajos que se van a implementar por réplica de back-end. Aumentar el número de trabajos por réplica de back-end podría aumentar el número de mensajes que puede controlar el pod de back-end. Cada trabajo puede consumir hasta dos núcleos de CPU como máximo, por lo que, debe tener cuidado al aumentar el número de trabajos por réplica para no superar el número de núcleos de CPU en el clúster.

Consideraciones

Al aumentar los valores de cardinalidad, la capacidad del agente para controlar más conexiones y mensajes generalmente mejora y mejora la alta disponibilidad si hay errores de pod o nodo. Esta mayor capacidad también conduce a un mayor consumo de recursos. Por lo tanto, al ajustar los valores de cardinalidad, tenga en cuenta la configuración del perfil de memoria y las solicitudes de recursos de CPU del corredor. Aumentar el número de trabajos por réplica de front-end puede ayudar a aumentar el uso del núcleo de CPU si detecta que el uso de la CPU de front-end es un cuello de botella. Aumentar el número de trabajos de back-end puede ayudar con el rendimiento de los mensajes si la utilización de CPU del back-end es un cuello de botella.

Por ejemplo, si el clúster tiene tres nodos, cada uno con ocho núcleos de CPU, establezca el número de réplicas de front-end para que coincidan con el número de nodos (3) y establezca el número de trabajos en 1. Establezca el número de particiones de back-end para que coincidan con el número de nodos (3) y los trabajos de back-end en 1. Establezca el factor de redundancia como desee (2 o 3). Aumente el número de trabajos de front-end si detecta que la utilización de CPU de front-end es un cuello de botella. Recuerde que los trabajos de back-end y front-end pueden competir por los recursos de CPU entre sí y otros pods.

Configuración del perfil de memoria

El perfil de memoria especifica el uso de memoria del broker para entornos con limitaciones de recursos. Puede elegir entre perfiles de memoria predefinidos que tienen diferentes características de uso de memoria. La configuración del perfil de memoria se usa para configurar el uso de memoria de las réplicas de front-end y back-end. El perfil de memoria interactúa con la configuración de cardinalidad para determinar el uso total de memoria del intermediario.

Para configurar la configuración del perfil de memoria el corredor MQTT, especifique los campos de perfil de memoria en la especificación del recurso Corredor durante la implementación de Operaciones de IoT.

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

Hay perfiles de memoria predefinidos con diferentes características de uso de memoria para publicar mensajes. No hay un límite en el número de sesiones o suscripciones que el agente puede controlar. El perfil de memoria controla solo el uso de memoria para el tráfico PUBLISH.

Pequeño

Use este perfil cuando tenga recursos de memoria limitados y el tráfico de publicación de cliente sea bajo.

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 multiplicado por el número de trabajos de back-end, pero el uso máximo real de memoria podría ser mayor.
• El tamaño máximo del mensaje es de 4 MB.
• El tamaño máximo del búfer entrante para los datos PUBLISH es de aproximadamente 16 MiB por trabajador de backend. Sin embargo, el tamaño efectivo puede ser menor debido a mecanismos de contrapresión, que se activan cuando el búfer alcanza 75% capacidad, lo que da como resultado un tamaño de búfer de aproximadamente 12 MiB. Los paquetes rechazados tienen una respuesta PUBACK con un código de error Cuota superada.

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

Use este perfil cuando tenga recursos de memoria limitados y los clientes publiquen paquetes pequeños.

Al usar este perfil:

• El uso máximo de memoria de cada réplica de front-end es, aproximadamente, 387 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 390 MiB multiplicado por el número de trabajos de back-end, pero el uso máximo real de memoria podría ser mayor.
• El tamaño máximo del mensaje es de 16 MB.
• El tamaño máximo del búfer entrante para los datos PUBLISH es de aproximadamente 64 MiB por trabajador de backend. Sin embargo, el tamaño efectivo puede ser menor debido a mecanismos de contrapresión, que se activan cuando el búfer alcanza 75% capacidad, lo que da lugar a un tamaño de búfer de aproximadamente 48 MiB. Los paquetes rechazados tienen una respuesta PUBACK con un código de error Cuota superada.

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 inferiores a 16 MiB.

Media

Use este perfil cuando necesite controlar un número moderado de mensajes de cliente.

El medio es el perfil predeterminado.

• El uso máximo de memoria de cada réplica de front-end es, aproximadamente, 1,9 GiB, pero el uso memoria máximo real 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.
• El tamaño máximo del mensaje es de 64 MB.
• El tamaño máximo del búfer entrante para datos de PUBLISH es de aproximadamente 576 MiB por trabajador de backend. Sin embargo, el tamaño efectivo puede ser menor debido a mecanismos de contrapresión, que se activan cuando el búfer alcanza 75% capacidad, lo que da lugar a un tamaño de búfer de aproximadamente 432 MiB. Los paquetes rechazados tienen una respuesta PUBACK con un código de error Cuota superada.

Alto

Use este perfil cuando necesite controlar un gran número de mensajes de cliente.

• El uso máximo de memoria de cada réplica de front-end es, 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.
• El tamaño máximo del mensaje es de 256 MB.
• El tamaño máximo del búfer entrante para los datos PUBLISH es de aproximadamente 2 GiB por trabajador de back-end. Sin embargo, el tamaño efectivo puede ser menor debido a mecanismos de contrapresión, que se activan cuando el búfer alcanza 75% capacidad, lo que da como resultado un tamaño de búfer de aproximadamente 1,5 GiB. Los paquetes rechazados tienen una respuesta PUBACK con un código de error Cuota superada.

Cálculo del uso total de memoria

La configuración del perfil de memoria especifica el uso de memoria para cada réplica de frontend y backend y se relaciona con los ajustes de cardinalidad. Puede calcular el uso total de memoria mediante la fórmula:

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

Donde:

Por ejemplo, si elige el perfil de memoria media , el perfil tiene un uso de memoria de front-end de 1,9 GB y el uso de memoria de back-end de 1,5 GB. 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:

2 * 1,9 GB + (2 * 2) * 1,5 GB * 2 = 15,8 GB

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

2 * 99 MB + (2 * 2) * 102 MB * 2 = 198 MB + 816 MB = 1,014 GB.

Límites de recursos de Cardinalidad y Kubernetes

Para evitar el colapso de recursos en el clúster, el agente se configura de forma predeterminada para solicitar límites de recursos de CPU de Kubernetes. El escalado del número de réplicas o trabajos aumenta proporcionalmente los recursos de CPU necesarios. Se genera un error de implementación si no hay suficientes recursos de CPU disponibles en el clúster. Esta notificación ayuda a evitar situaciones en las que la cardinalidad del corredor solicitada carece de suficientes recursos para ejecutarse de forma óptima. También ayuda a evitar posibles contenciones de CPU y expulsión de pods.

El corredor MQTT actualmente solicita una unidad de CPU (1) por trabajo de front-end y dos (2) unidades de CPU por trabajo de back-end. Para más información, consulte Unidades de recursos de CPU de Kubernetes.

Por ejemplo, la cardinalidad siguiente solicitaría estos recursos de CPU:

• Para front-end: 2 unidades de CPU por pod de front-end, lo que suma 6 unidades de CPU.
• Para back-end: 4 unidades de CPU por pod de back-end (para dos trabajos de back-end), por 2 (factor de redundancia), por 3 (número de particiones), lo que suma 24 unidades de CPU.

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

Para deshabilitar esta configuración, establezca el campo generateResourceLimits.cpu en Disabled en el recurso Broker.

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

az iot ops create ... --broker-config-file <FILE>.json

Implementación de varios nodos

Para garantizar una alta disponibilidad y resistencia con implementaciones de varios nodos, el corredor MQTT de Operaciones de IoT establece automáticamente reglas de antiafinidad para pods de back-end.

Estas reglas están predefinidas y no se pueden modificar.

Propósito de las reglas de antiafinidad

Las reglas de antiafinidad garantizan que los pods de back-end de la misma partición no se ejecuten en el mismo nodo. Esta capacidad ayuda a distribuir la carga y proporciona resistencia frente a errores de nodo. En concreto, los pods de back-end de la misma partición tienen afinidad entre sí.

Compruebe la configuración de antiafinidad

Para comprobar la configuración de antiafinidad de un pod de back-end, use el siguiente comando:

kubectl get pod aio-broker-backend-1-0 -n azure-iot-operations -o yaml | grep affinity -A 15

La salida mostrará la configuración de antiafinidad, similar al siguiente ejemplo:

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: chain-number
            operator: In
            values:
            - "1"
        topologyKey: kubernetes.io/hostname
      weight: 100

Estas son las únicas reglas antiafinidad establecidas para el corredor.

Contenido relacionado

• Configuración de agentes de escucha para el corredor MQTT