Mehrschichtige Vernetzung für Azure IoT-Betrieb

In vielen industriellen Umgebungen trennen segmentierte Netzwerkarchitekturen (z. B. die Purdue-Netzwerkarchitektur) Objekte, Steuerungssysteme und Geschäftsanwendungen in unterschiedliche Netzwerkebenen. Niedrigere Ebenen können in der Regel keine direkte Verbindung mit dem Internet herstellen und können nur mit angrenzenden Ebenen kommunizieren. Azure IoT Einsatz unterstützt die Bereitstellung über diese geschichteten Netzwerke und nutzt Envoy-Proxy-Chaining, CoreDNS sowie eine auf Kubernetes basierende Konfiguration, um den Datenverkehr zwischen den Ebenen zu routen.

Das folgende Diagramm zeigt, wie Azure IoT Einsatz in mehreren Clustern in verschiedenen Netzwerksegmenten bereitgestellt wird. In der Purdue-Netzwerkarchitektur ist Ebene 4 das Unternehmensnetzwerk, Ebene 3 ist die Betriebs- und Kontrollebene, und Ebene 2 ist die Controllersystemebene. Nur Ebene 4 verfügt über direkten Internetzugang, und die anderen Ebenen können nur mit ihren angrenzenden Ebenen kommunizieren.

In diesem Beispiel wird Azure IoT Einsatz auf Ebene 2 bis 4 bereitgestellt. Jede Ebene verwendet die folgenden Komponenten, um den Datenverkehr auf die nächste Ebene weiterzuleiten:

• Envoy Proxy (Ebenen 3 und 4) dient als Reverseproxy, der Datenverkehr von untergeordneten Ebenen in Richtung Azure weiterleitet.
• CoreDNS (Level 2 und 3) – löst genehmigte URIs in den Envoy-Proxy des übergeordneten Clusters auf, sodass niedrigere Ebenen Azure Dienste über angrenzende Ebenen erreichen können.

Mit diesem Setup können Sie Arc-fähige Cluster auf jeder Ebene aktivieren und ohne direkten Internetzugang verbunden bleiben.

Sie können Azure IoT Einsatz Komponenten auf Ebenen basierend auf Ihren Architektur- und Datenflussanforderungen bereitstellen:

• Connector für OPC UA – platzieren Sie sich auf der unteren Ebene, näher an Ihren Ressourcen und OPC UA-Servern.
• MQTT-Broker – stellen Sie auf jeder Ebene bereit, um Daten nach oben in die Cloud zu übertragen.
• Datenflüsse – platzieren Sie Knoten mit ausreichend Rechenressourcen, da diese Komponente in der Regel mehr Compute verwendet. Mit zusätzlicher Konfiguration können Datenflüsse den Datenverkehr auch ost-west zwischen Komponenten auf derselben oder oberer Ebene weiterleiten.

Wie Telemetrie über Ebenen fließt

In einem schichtbasierten Netzwerk wird die Asset-Telemetrie nicht direkt von der untersten Ebene bis zur Cloud weitergeleitet. Stattdessen endet und beginnt die Telemetrie auf jeder Ebene erneut. Dieses Hop-by-Hop-Muster ist ein wichtiger Unterschied zu einer Flachnetzwerkbereitstellung.

Der Fluss funktioniert wie folgt:

1. Ebene 2 (Asset Layer): Der Connector für OPC UA liest Daten von OPC UA-Servern und veröffentlicht sie im lokalen MQTT-Broker (z. B. in einem Thema wie clusterl2/data/oven1). Ein Datenfluss diese Nachrichten abnimmt, optional transformiert oder anreichert sie (z. B. Produktkontext hinzufügen), und leitet sie auf Ebene 3 an den MQTT-Broker weiter.
2. Ebene 3 (Betriebsschicht): Der MQTT-Broker der Ebene 3 empfängt die Nachrichten von Ebene 2. Eine Datenfluss auf dieser Ebene kann weiteren Kontext (z. B. Produktionsliniendetails) hinzufügen und die angereicherten Nachrichten an den MQTT-Broker auf Ebene 4 weiterleiten.
3. Ebene 4 (Enterprise-Ebene): Der MQTT-Broker der Ebene 4 empfängt die Nachrichten von Ebene 3. Ein endgültiger Datenfluss fügt den gesamten verbleibenden Kontext (z. B. Fabrik-IDs) hinzu und sendet die Nachrichten an ein Cloudziel, z. B. Azure Event Hubs oder Azure Event Grid über den privaten oder öffentlichen Netzwerkpfad.

Auf jeder Ebene werden die Daten vollständig auf dem lokalen MQTT-Broker verarbeitet; sie werden nicht weitergeleitet oder durchgeschleust. Dadurch haben Sie folgende Möglichkeiten:

• Anreichern von Daten auf jeder Ebene – Fügen Sie Kontextmetadaten (Produkt, Linie, Fabrik) hinzu, über die Ressourcen mit niedrigerer Ebene nicht informiert sind.
• Filtern oder aggregieren – Verringern Sie die Datenmenge, oder legen Sie irrelevante Nachrichten ab, bevor Sie nach oben weiterleiten.
• Lokal nutzen – andere Anwendungen auf derselben Ebene können den lokalen MQTT-Broker für Abteilungsworkloads abonnieren, ohne auf Daten zum Roundtrip in die Cloud warten zu müssen.

Eine praktische Anleitung für dieses Muster finden Sie in Schritt 5 in der exemplarischen Vorgehensweise.

Beispiel einer Anleitung

Ein Schicht-Netzwerkanleitungsbeispiel ist im Beispiel-Repository für Azure IoT Einsatz verfügbar. Das Beispiel-Repository enthält die Infrastrukturkonfigurationsdateien (Envoy-Proxykonfigurationen, CoreDNS Corefiles und Kubernetes-Manifeste), die auf jeder Netzwerkebene verwendet werden. Der Tutorial bietet den vollständigen End-to-End-Bereitstellungsleitfaden, einschließlich der Azure-Ressourceneinrichtung, der Private-Link- und DNS-Konfiguration, der Arc-Aktivierung, der RBAC-Zuordnungen und der Überprüfung nach der Bereitstellung und verweist auf das Beispiel für layerspezifische Konfigurationsdateien.

Das Beispiel und die Anleitungen zeigen, wie:

• Verwenden Sie Kubernetes-basierte Konfigurations- und Netzwerkgrundtypen für mehrschichtige Umgebungen.
• Verbinden Sie Geräte in isolierten Netzwerken im großen Stil mit Azure Arc, um Zugriff auf das Application Lifecycle Management und auf die Remotekonfiguration zu erhalten.
• Erzwingen Sie Sicherheit und Governance auf allen Netzwerkebenen mit URL-/IP-Zulassungslisten und Verbindungsüberwachung.
• Stellen Sie die Kompatibilität mit allen Azure IoT Einsatz Diensten sicher.

Weitere Informationen zum Vorbereiten einer produktionsbereiten Bereitstellung von Azure IoT Einsatz finden Sie in den Azure IoT Einsatz Produktionsrichtlinien.

Um das Beispiel in einer Testumgebung auszuprobieren, folgen Sie der Schritt-für-Schritt-Anleitung:

1. Wie Azure IoT Einsatz in einem schichtigen Netzwerk funktioniert
2. Konfigurieren Sie die Infrastruktur
3. K3s-Cluster Arc-fähig machen
4. Azure IoT Einsatz bereitstellen
5. Flow-Asset-Telemetrie

Plattformkompatibilität

Der hier beschriebene Layered Networking-Ansatz gilt für Arc-fähige Kubernetes-Cluster. Wenn Sie andere Arc-fähige Plattformen in Ihrer mehrschichtigen Umgebung verwenden, beachten Sie Folgendes:

• Azure Arc-enabled servers: Die Envoy-Proxykette wurde nur mit Arc-fähigen Kubernetes-Clustern überprüft. Arc-fähige Server verwenden einen anderen Agent (Azure Connected Machine Agent) mit unterschiedlichen Endpunktanforderungen. Wenn Sie Arc-Enable-Server in einem Layer-Netzwerk benötigen, überprüfen Sie, ob die erforderlichen Endpunkte in Ihrer Envoy-Proxy- und CoreDNS-Konfiguration enthalten sind. Azure IoT Einsatz Komponenten (MQTT-Broker, Data Flows, Connector für OPC UA) erfordern Kubernetes und können nicht direkt auf Arc-fähigen Servern ausgeführt werden.
• Azure Local (ehemals Azure Stack HCI): Azure Local Knoten, die Kubernetes-Cluster hosten (z. B. AKS, die von Azure Arc aktiviert sind), sind vollständig mit diesem Layered Networking-Ansatz kompatibel. Der Kubernetes-Cluster, der auf Azure Local ausgeführt wird, folgt der oben beschriebenen Arc-Aktivierungs- und Envoy-Proxykette.

Verwandte Inhalte

• Azure IoT Einsatz Networking
• Deploy Azure IoT Einsatz mit privater Konnektivität
• Tutorial: Bereitstellen von Azure IoT Einsatz in einem mehrschichtigen Netzwerk mit privater Konnektivität