Freigeben über

Beispiele für die Produktionsbereitstellung

In diesem Artikel werden zwei Beispielbereitstellungen für Azure IoT Einsatz beschrieben, die Daten am Edge sammeln und in die Cloud übertragen. Diese Beispiele basieren auf realen Szenarien, die Hardwarefunktionen und Datenvolumes berücksichtigen. Anhand dieser Beispiele können Sie besser verstehen, welche Datenvolumes Azure IoT Einsatz mit bestimmter Hardware verarbeiten kann.

Microsoft hat ähnliche Konfigurationen und Datenvolumes verwendet, um Azure IoT Einsatz zu überprüfen und die Leistung zu messen.

Einzelknotencluster

Dieses Beispiel zeigt die Funktionen von Azure IoT Einsatz bei Ausführung auf einem Host mit relativ geringer Hardwarespezifikation. In diesem Beispiel wird Azure IoT Einsatz in einem einzelnen Knotencluster bereitgestellt. Aus Ressourcen generierte Daten werden zuerst mit einer SPS aggregiert und dann an den Connector von „Azure IoT Einsatz“ für OPC UA gesendet.

Konfiguration

Beispielhardwarespezifikationen:

  • K3s auf Azure-VM (Standard_D4ds_v5 mit Intel Setting Platinum 8370C), 4 Kerne (4 vCPU), 16 GB Arbeitsspeicher, 30 GB Speicher.

  • AKS-EE auf P3 Tiny Workstation (Intel® Core™ i7-13700 vPro®-Prozessor der 13. Generation), 16 Kerne (24 Threads), 32 GB Arbeitsspeicher, 1 TB Speicher.

Wichtig

Derzeit sind K3s auf Ubuntu 24.04 und Tanzu Kubernetes die einzigen Plattformen für die Bereitstellung von Azure IoT Operations in der Produktion. Weitere Informationen finden Sie unter Unterstützte Umgebungen.

Die folgende Tabelle zeigt die MQTT-Brokerkonfiguration für das Beispiel für einen einzelnen Knoten:

Parameter Wert
frontendReplicas 1
Frontend-Mitarbeiter 1
Backend-Redundanzfaktor 2
Backend-Arbeiter 1
backendPartitions 1
Speicherprofil niedrig

Der End-to-End-Datenfluss im Beispiel sieht wie folgt aus:

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

Die Datenvolumes im Beispiel sind:

  • 125 Ressourcen, die von einem einzelnen OPC UA-Server aggregiert werden.
  • 6.250 Tags basierend auf 50 Tags für jede Ressource. Jedes Tag wird 2 Mal pro Sekunde aktualisiert und hat eine durchschnittliche Größe von 20 Byte.
  • Der Connector für OPC UA sendet 125 Nachrichten pro Sekunde an den MQTT-Broker.
  • Eine Datenflusspipeline pusht 6.250 Tags an einen Event Hubs-Endpunkt.

In diesem Beispiel empfiehlt Microsoft die Verwendung von Event Hubs, da Sie nur eine Datenflussinstanz mit einer CPU mit 4 Kernen erstellen können. Wenn Sie Event Grid auswählen, können nur 100 Nachrichten pro Sekunde verarbeitet werden.

Leistung

Die wichtigsten Leistungsmetriken für dieses Beispiel umfassen:

  • Azure IoT Einsatz und die Abhängigkeiten verbrauchen zwischen 6 GB und 8 GB RAM.
  • Azure IoT Einsatz und die Abhängigkeiten verbrauchen durchschnittlich 2.400 bis 2.600 Millicores.
  • 100 % der Daten werden an Event Hubs gepusht.
  • Die End-to-End-Datenprozesslatenz beträgt bei idealen Netzwerkbedingungen weniger als 10 Sekunden.

Cluster mit mehreren Knoten

Wenn Azure IoT Einsatz in Cluster mit mehreren Knoten ausgeführt wird, kann die Lösung mehr Daten verarbeiten und die Hochverfügbarkeitsfunktionen von Kubernetes nutzen. In diesem Beispiel wird Azure IoT Einsatz in einem Cluster mit 5 Knoten gehostet und verarbeitet ca. 50.000 Datenpunkte pro Sekunde aus zwei verschiedenen Datenquellen.

Konfiguration

Beispielhardwarespezifikationen:

  • K3s mit 5 Knoten auf Azure-VMs (Standard_D8d_v5 mit Intel Setting Platinum 8370C), 8 Kerne (8 vCPU), 32 GB Arbeitsspeicher, 30 GB Speicher.

  • K3S mit 5 Knoten auf P3 Tiny Workstations (Intel® Core™ i7-13700 vPro® der 13. Generation), 16 Kerne (24 Threads), 32 GB Arbeitsspeicher, 1 TB Speicher.

Wichtig

Derzeit sind K3s auf Ubuntu 24.04 und Tanzu Kubernetes die einzigen Plattformen für die Bereitstellung von Azure IoT Operations in der Produktion. Weitere Informationen finden Sie unter Unterstützte Umgebungen.

Die folgende Tabelle zeigt die MQTT-Brokerkonfiguration für das Beispiel für mehrere Knoten:

Parameter Wert
frontendReplicas 5
Frontend-Mitarbeiter 8
Backend-Redundanzfaktor 2
Backend-Arbeiter 4
backendPartitions 5
Speicherprofil High

In diesem Beispiel gibt es zwei Arten von Datenquellen. Eine stellt eine Verbindung über den Connector für OPC UA her und die andere eine Verbindung über den MQTT-Broker.

In diesem Beispiel stellt eine Ressource kein echtes Gerät dar, sondern ist eine logische Gruppierung, die Datenpunkte aggregiert und Nachrichten sendet.

Der erste End-to-End-Datenfluss im Beispiel sieht wie folgt aus:

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

Die Datenvolumes im ersten Datenfluss im Beispiel sind:

  • 85 Ressourcen, die von fünf OPC UA-Server aggregiert werden.
  • 85.000 Tags basierend auf 1.000 Tags für jede Ressource. Jedes Tag wird 1 Mal pro Sekunde aktualisiert und hat eine durchschnittliche Größe von 8 Byte. Ungefähr 50 % der Tagwerte ändern sich in jedem Zyklus. Die Aktualisierungsrate für Datenpunkte beträgt 45.000 pro Sekunde.
  • Der Connector für OPC UA sendet 85 Nachrichten pro Sekunde an den MQTT-Broker.
  • Eine Datenflusspipeline pusht 85.000 Tags an einen Event Hubs-Endpunkt.

Der zweite End-to-End-Datenfluss im Beispiel sieht wie folgt aus:

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

Die Datenvolumes im zweiten Datenfluss im Beispiel sind:

  • Zwei direkt mit dem MQTT-Broker verbundene MQTT-Clients.
  • Jeder Client veröffentlicht 10.000 Werte pro Sekunde.
    • Ungefähr ein Drittel der Tagwerte ändern sich in jedem Zyklus.
    • Codiert im JSON-Format. Jedes Element (Wert) mit einer ungefähren Größe von 180 Byte.

Leistung

Die wichtigsten Leistungsmetriken für dieses Beispiel umfassen:

  • Azure IoT Einsatz und die Abhängigkeiten verbrauchen zwischen 25 GB und 30 GB RAM.
  • Azure IoT Einsatz und die Abhängigkeiten verbrauchen durchschnittlich 2.500 bis 3.000 Millicores.
  • 100 % der Daten werden an Event Hubs gepusht.
  • Die End-to-End-Datenprozesslatenz beträgt bei idealen Netzwerkbedingungen weniger als 10 Sekunden.