Ejemplos de implementación de producción

En este artículo se describen dos implementaciones de ejemplo de Operaciones de IoT de Azure que recopilan datos desde el edge y los transfieren a la nube. Estos ejemplos se basan en escenarios reales que tienen en cuenta la funcionalidad de hardware y los volúmenes de datos. Use estos ejemplos para comprender mejor la cantidad de datos que Operaciones de IoT de Azure pueden controlar con cierto hardware.

Microsoft usaron configuraciones y volúmenes de datos similares para validar Operaciones de IoT de Azure y medir su rendimiento.

Clúster de un solo nodo

En este ejemplo se muestran las funcionalidades de Operaciones de IoT de Azure cuando se ejecuta en un host con una especificación de hardware relativamente baja. En este ejemplo, Operaciones de IoT de Azure se implementa en un clúster de nodo único. Los datos generados por activos se agregan primero con un PLC y luego se envían al conector de Operaciones de IoT de Azure para OPC UA.

Configuración

Especificaciones de hardware de ejemplo:

  • K3s en Azure máquina virtual (Standard_D4ds_v5 con Intel Xeon Platinum 8370C), 4 núcleos (4 vCPU), memoria de 16 GB y almacenamiento de 30 GB.

  • AKS-EE en P3 Tiny Workstation (procesador Intel® Core™ i7-13700 vPro® de 13.ª generación), 16 núcleos (24 subprocesos), 32 GB de memoria y 1 TB de almacenamiento.

Importante

Actualmente, K3s en Ubuntu 24.04 y vSphere Kubernetes Service son las únicas plataformas para implementar operaciones de Azure IoT en producción. Para obtener más información, consulte Entornos admitidos.

En la tabla siguiente se muestra la configuración del corredor MQTT para el ejemplo de nodo único:

Parámetro Valor
frontendReplicas 1
trabajadores de frontend 2
backendRedundancyFactor 2
backendWorkers 1
backendPartitions 1
perfil de memoria low

El flujo de datos de un extremo a otro del ejemplo tiene el siguiente aspecto:

Assets -> PLC -> Connector for OPC UA -> MQTT broker -> Data flows -> Event Hubs

Los volúmenes de datos del ejemplo son los siguientes:

  • 125 recursos agregados por un único servidor de OPC UA.
  • 6250 etiquetas basadas en 50 etiquetas para cada recurso. Cada etiqueta se actualiza 2 veces por segundo y tiene un tamaño medio de 20 bytes.
  • El conector de OPC UA envía 125 mensajes por segundo al agente MQTT.
  • Una canalización de flujo de datos inserta 6250 etiquetas en un punto de conexión de Event Hubs.

En este ejemplo, Microsoft recomienda usar Event Hubs porque solo puede crear una instancia de flujo de datos con una CPU de 4 núcleos. Si elige Event Grid, solo puede controlar 100 mensajes por segundo.

Rendimiento

Entre las métricas clave de rendimiento de este ejemplo, se incluyen las siguientes:

  • Operaciones de IoT de Azure y sus dependencias consumen entre 6 GB y 8 GB de RAM.
  • Operaciones de IoT de Azure y sus dependencias consumen un promedio de 2.400-2.600 millicores.
  • El 100 % de los datos se insertan en Event Hubs.
  • La latencia del proceso de datos de un extremo a otro es inferior a 10 segundos, dadas las condiciones de red ideales.

Clúster con varios nodos

Cuando Operaciones de IoT de Azure se ejecuta en un clúster de varios nodos, puede procesar más datos y aprovechar las funcionalidades de alta disponibilidad de Kubernetes. En este ejemplo, Operaciones de IoT de Azure se hospeda en un clúster de 5 nodos y procesa aproximadamente 50 000 puntos de datos por segundo desde dos orígenes de datos diferentes.

Configuración

Especificaciones de hardware de ejemplo:

  • K3 de 5 nodos con máquinas virtuales de Azure (Standard_D8d_v5 con Intel Xeon Platinum 8370C), 8 núcleos (8 vCPU), 32 GB de memoria, 30 GB.

  • K3S de 5 nodos con estaciones de trabajo P3 Tiny (procesador Intel® Core™ de 13ª generación i7-13700 vPro®), 16 núcleos (24 subprocesos), 32 GB de memoria y almacenamiento de 1 TB.

Importante

Actualmente, K3s en Ubuntu 24.04 y vSphere Kubernetes Service son las únicas plataformas para implementar operaciones de Azure IoT en producción. Para obtener más información, consulte Entornos admitidos.

En la tabla siguiente se muestra la configuración del corredor MQTT para el ejemplo de varios nodos:

Parámetro Valor
frontendReplicas 5
trabajadores de frontend 4
backendRedundancyFactor 2
backendWorkers 4
backendPartitions 5
perfil de memoria Alto

En este ejemplo, hay dos tipos de origen de datos. Uno se conecta a través del conector para OPC UA y uno se conecta a través del agente MQTT.

En este ejemplo, un recurso no representa un equipo real, pero es una agrupación lógica que agrega puntos de datos y envía mensajes.

El primer flujo de datos de un extremo a otro del ejemplo tiene este aspecto:

Assets -> PLC -> Connector for OPC UA -> MQTT broker -> Data flows -> Event Hubs

Los volúmenes de datos del primer flujo de datos del ejemplo son lo siguientes:

  • 85 recursos, agregados por cinco servidores de OPC UA.
  • 85 000 etiquetas basadas en 1000 etiquetas para cada recurso. Cada etiqueta se actualiza 1 vez por segundo y tiene un tamaño promedio de 8 bytes. Aproximadamente el 50 % de los valores de etiqueta cambian cada ciclo. La velocidad de actualización del punto de datos es de 45 000 por segundos.
  • El conector de OPC UA envía 85 mensajes por segundo al agente MQTT.
  • Una canalización de flujo de datos inserta 85 000 etiquetas en un punto de conexión de Event Hubs.

El segundo flujo de datos de un extremo a otro del ejemplo tiene este aspecto:

MQTT client (Paho) -> MQTT Broker -> Data flows -> Event Hubs

Los volúmenes de datos del segundo flujo de datos del ejemplo son los siguientes:

  • Dos clientes de MQTT conectados directamente al corredor MQTT.
  • Cada cliente publica 10 000 valores por segundo.
    • Aproximadamente 1/3 de los valores de etiqueta cambian cada ciclo.
    • Codificado con formato JSON. Cada elemento (valor) con un tamaño aproximado de 180 bytes.

Rendimiento

Entre las métricas clave de rendimiento de este ejemplo, se incluyen las siguientes:

  • Operaciones de IoT de Azure y sus dependencias consumen entre 25 GB y 30 GB de RAM.
  • Operaciones de IoT de Azure y sus dependencias consumen un promedio de 2.500-3000 millicores.
  • El 100 % de los datos se insertan en Event Hubs.
  • La latencia del proceso de datos de un extremo a otro es inferior a 10 segundos, dadas las condiciones de red ideales.