Azure IoT Operations mit Azure Arc – Ein umfassender Überblick
Einleitung
Die Verwaltung und Skalierung von IoT-Geräten stellt viele Unternehmen vor große Herausforderungen. Besonders in hybriden und verteilten Umgebungen kann es schwierig sein, IoT-Geräte und Edge-Deployments effizient zu steuern. Azure IoT Operations (AIO) bietet hier eine umfassende Lösung, indem es eine einheitliche Verwaltungsplattform für vernetzte IoT-Umgebungen bereitstellt.
Wer von Azure IoT Operations noch nichts gehört hat und sich fragt was das ist möchte ich einen schnellen Einstieg anbieten. Vereinfacht gesagt werden verschiedene Workloads und Tools auf einen Kubernetes Cluster ausgerollt um industrielle Anwendungen und Szenarien zu realisieren. Als Beispiel gibt es einen Connector für OPC UA (Open Platform Communications Unified Architecture) der eine Anbindung an industrielle Assets ermöglicht. Der universelle MQTT Broker ermöglicht eine flexible Anbindung an eine Vielzahl von Systemen und Assets. Der Einstieg ist ziemlich leichtgewichtig, denn es wird nur ein MQTT Client benötigt. Dies sind nur ein paar Beispiele von vielen, lass uns gemeinsam das Potenzial entdecken.
In diesem Blogpost gehe ich detailliert darauf ein, wie Azure IoT Operations funktioniert, was es dir anbieten kann und wie du verschiedene Komponenten wie z.B. den MQTT-Broker oder eine OPC UA Anbindung realisierst. Außerdem möchte ich dabei helfen, einen ganzheitlichen Überblick über diese Lösung zu schaffen – eine Herausforderung, da sie zahlreiche unterschiedliche Themenbereiche umfasst. Darüber hinaus gehe ich auf eine häufig gestellte Frage ein: Wie steht es um Azure IoT Edge und dem IoT Hub?
Was du in diesem Blogpost findest:
- Azure IoT Edge oder doch IoT Operations?
- Wann es sich lohnt auf Azure IoT Operations und Kubernetes zu setzen
- Azure IoT Operations Architekturübersicht
- Verwaltung des Clusters mit der Operations Experience
- Einstieg mit dem integrierten MQTT Broker
- Einstieg zur Integration mit OPC UA
- Ausblick
- Fazit
Falls du Basisthemen nachlesen möchtest:
Tim Steiner
Tim Steiner
Das Ziel dieses Blogposts ist es, dir einen umfassenden Einblick in die IoT-Lösungen von Microsoft zu geben und deren Anwendungsbereiche sowie Potenziale verständlich zu machen.
Azure IoT Edge oder doch IoT Operations ? Eine Einordnung für deine Anforderungen
Wenn du bereits eine Lösung mit Azure IoT Edge und IoT Hub verwendest, bleibt dieser Ansatz eine ausgezeichnete Wahl, besonders wenn der Fokus auf Sensortechnologien liegt und kein komplexer Kubernetes-Cluster benötigt wird. Azure IoT Edge ermöglicht es, Daten direkt am Edge zu verarbeiten, was Bandbreite spart und schnellere Reaktionszeiten bietet.
Mit der Einführung von Azure IoT Operations sind jedoch auch die Systemanforderungen gestiegen. Für einen reibungslosen Betrieb wird nun ein leistungsfähigeres Edge Device benötigt, das ausreichend Rechenleistung und Speicher bietet, um erweiterte Funktionen und mehr Ausfallsicherheit zu ermöglichen. Dies bringt zwangsläufig auch höhere Hardwarekosten mit sich.
Dank der Integration mit anderen Azure-Diensten wie Azure Machine Learning und Azure Stream Analytics können komplexe Analysen direkt am Edge durchgeführt werden, was die Effizienz und Reaktionsgeschwindigkeit weiter erhöht. Insgesamt bleibt Azure IoT Edge eine flexible und skalierbare Lösung für IoT-Infrastrukturen, besonders wenn eine zentrale Cloud-Verarbeitung vermieden werden soll.
Warum Azure IoT Operations und Kubernetes?
Die Wahl zwischen einem leichtgewichtigen IoT Edge und einem Kubernetes-Cluster hängt vor allem von der Komplexität und Skalierbarkeit der IoT-Lösung ab. Azure IoT Edge eignet sich hervorragend für kleinere oder weniger komplexe IoT-Umgebungen, bei denen Edge-Devices und lokale Datenverarbeitung im Vordergrund stehen. Es ist ideal, wenn du keine umfangreiche Infrastruktur aufbauen möchtest und eine einfache, aber leistungsfähige Lösung für Geräte und Sensoren benötigst.
Im Gegensatz dazu bietet der Einsatz von Kubernetes zusammen mit Azure IoT Operations eine skalierbare, dynamische und hochverfügbare Plattform, die für große IoT-Implementierungen und komplexe Anwendungen sinnvoll sein kann. Wenn du mit einer Vielzahl von Geräten arbeitest, mehrere Microservices integrieren musst oder in einer Cloud-Umgebung eine hohe Verfügbarkeit und Automatisierung benötigst, ist Kubernetes eine ausgezeichnete Wahl. Azure IoT Operations hilft dabei, die Verwaltung der Devices in einem solchen Kubernetes-Cluster zu optimieren, da es zusätzliche Funktionen wie z.B. Monitoring, Fehlerbehebung und Sicherheitsmanagement bietet.
Wann ist der Kubernetes-Cluster sinnvoll?
Ein Kubernetes-Cluster macht dann Sinn, wenn du:
- Skalierbarkeit benötigst: Wenn die Anzahl der Geräte und Anwendungen wächst und du eine flexible Infrastruktur brauchst, die auf Nachfrage skaliert werden kann.
- Komplexe Anwendungen betreibst: Wenn du mehrere Microservices oder Anwendungen betreiben musst, die auf unterschiedliche Ressourcen und Services zugreifen oder verschiedene Industrieprotokolle anbinden musst.
- Hohe Verfügbarkeit und Redundanz benötigst: Kubernetes sorgt durch seine Orchestrierung dafür, dass deine Anwendungen immer verfügbar bleiben, selbst wenn einzelne Komponenten ausfallen.
- Automatisierung und DevOps in deinem Workflow nutzen möchtest: Mit Kubernetes und Azure IoT Operations kannst du eine CI/CD-Pipeline für deine IoT-Anwendungen einrichten und regelmäßig Updates und Patches vornehmen und ausrollen.
Technische Herausforderungen in der IoT-Verwaltung:
- Dezentrale Infrastruktur: IoT-Geräte laufen oft auf Edge-Systemen, entfernt von zentralen Rechenzentren.
- Unterschiedliche Betriebssysteme und Hardware: Viele Geräte basieren auf Linux, Windows IoT oder proprietären Embedded-Systemen.
- Sicherheit und Compliance: Geräte müssen regelmäßig gepatcht, verwaltet und abgesichert werden.
- Konnektivität und Datenverarbeitung: Nicht alle Geräte haben kontinuierliche Internetverbindungen, sodass lokale Verarbeitung notwendig wird.
- Standardisierung von Kommunikationsprotokollen: Unterschiedliche Geräte sprechen verschiedene Protokolle wie MQTT, OPC UA oder HTTP.
Wann bleibt IoT Edge die bessere Wahl?
Für kleinere IoT-Anwendungen, bei denen du Edge-Devices mit begrenzten Ressourcen und geringerem Verwaltungsaufwand betreiben möchtest, ist Azure IoT Edge die bessere Wahl. Wenn du also keine komplexen Infrastruktur- und Orchestrierungsanforderungen hast, sondern vor allem auf einfache Integration, geringere Latenz und geringe Hardwareanforderungen setzt, dann ist IoT Edge weiterhin eine hervorragende Lösung.
Azure IoT Operations Architekturübersicht
Azure IoT Operations ist eine skalierbare und cloudintegrierte Lösung für industrielle IoT-Szenarien, die auf Azure Arc basiert. Die Architektur gliedert sich in mehrere Hauptbereiche:
1. Edge-Integration in der Fabrik
- Datenquellen:
- ONVIF- und IP-Kameras zur Videoüberwachung und Analyse
- Industrielle Assets (Sensoren, Maschinen) senden Daten über OPC UA-Server
- Benutzerdefinierte Kubernetes-Workloads können direkt am Edge ausgeführt werden
- Edge-Management:
- Azure IoT Operations (Azure Arc-Enabled) ermöglicht eine vernetzte Steuerung der IoT-Geräte
- Connectors (OPC UA, ONVIF, Media) sammeln und normalisieren die Daten
- MQTT-Broker dient als zentrales Messaging-Framework
- Dataflows transformiert und leitet die Daten weiter
2. Cloud-Integration & Verwaltung
- Azure IoT Operations Experience Portal
- Verwaltung von IoT-Devices und industriellen Pipelines
- Bereitstellung von Sicherheitsrichtlinien durch Azure Policy & Microsoft Defender for Cloud
- Datenverarbeitung & Analyse
- Azure Event Grid & Event Hubs für Echtzeit-Datenströme
- Azure Storage & Data Explorer für langfristige Datenhaltung
- Microsoft Fabric & Power BI für Datenvisualisierung und -analyse
3. IT & OT Rollenmanagement
- IT-Administratoren verwalten Edge- und Cloud-Ressourcen
- OT-Administratoren (Operational Technology) überwachen und optimieren die Produktionsprozesse
Diese Architektur ermöglicht eine nahtlose Integration von IoT, Edge Computing und Cloud-Services für eine sichere, skalierbare und verwaltbare IoT-Infrastruktur.
Verwaltung des Azure IoT Operations Cluster
Falls es dir bis jetzt noch keiner Verraten hat, es gibt eine Operations Experience für deine Azure IoT Operations Instanz 😅
https://iotoperations.azure.com/
Nach Login und Auswahl der entsprechenden Instanz sieht das Dashboard dann wie folgt aus:
💡 Diese Seite wird später für die OPC UA Anbindung nochmal relevant 😄
Nutzung des integrierten MQTT-Brokers in Azure IoT Operations
Warum MQTT?
Das Message Queuing Telemetry Transport (MQTT)-Protokoll ist ein leichtgewichtiges, publish-subscribe-basiertes Nachrichtenprotokoll, das ideal für IoT-Geräte mit eingeschränkter Bandbreite oder begrenzten Ressourcen ist. Der Broker bildet gleichzeitig die Möglichkeiten zur Realisierung von Event-Driven Architekturen
Es ermöglicht:
- Effiziente Datenübertragung über langsame oder unzuverlässige Netzwerke.
- Geringe Latenz für Echtzeitkommunikation zwischen IoT-Geräten.
- Skalierbare Architektur, da viele Geräte gleichzeitig Nachrichten senden und empfangen können.
- Unterstützung vieler IoT Geräte durch native Integration via MQTT
- Nachgeschaltete Übersetzungsgateways ermöglichen eine Anbindung von Geräten die keine native Integration besitzen.
Überblick MQTT-Broker auf Azure IoT Operations
Azure IoT Operations (AIO) bietet einen integrierten MQTT-Broker, der es IoT-Geräten ermöglicht, Daten direkt an die Cloud oder an andere Geräte zu senden.
Aufbau
Der MQTT Broker hat zwei verschiedene Ebenen:
- Statusfreie Frontend-Ebene
- Zustandsbehaftete Backend-Ebene mit Sharding
Sharding ist eine Technik, bei der große Datenmengen oder Lasten auf mehrere kleinere Einheiten aufgeteilt werden, um die Skalierbarkeit und Leistung zu verbessern. Im Kontext des MQTT-Brokers bedeutet dies, dass Daten oder Verbindungen auf verschiedene Instanzen verteilt werden, sodass jede Instanz nur einen Teil der Gesamtlast übernimmt. Dadurch können Systeme effizienter mit höheren Nutzerzahlen und größerem Datenvolumen umgehen, ohne dass die Performance leidet.
Diese Architektur hat folgende Ziele:
- Fehlertoleranz und Isolation: Die Veröffentlichung von Nachrichten wird fortgesetzt, wenn Backend-Pods ausfallen, und verhindert, dass Fehler an den Rest des Systems weitergegeben werden.
- Wiederherstellung nach Fehlern: Automatische Wiederherstellung nach Fehlern
- Kein Nachrichtenverlust: Übermittlung von Nachrichten, wenn mindestens ein Frontend-Pod und ein Backend-Pod in einer Partition ausgeführt werden
- Flexible Skalierung: Horizontale Skalierung der Veröffentlichung und Abonnieren des Durchsatzes zur Unterstützung von Edge- und Cloudbereitstellungen
- Konsistente Leistung im großen Stil: Beschränkung des Latenzaufwands für Nachrichten aufgrund der Kettenreplikation
- Betriebliche Einfachheit: Minimale Abhängigkeit von externen Komponenten zur Vereinfachung der Wartung und Komplexität
Zugriffsmöglichkeiten
Für den Zugriff auf den MQTT-Broker gibt es grundsätzlich drei Möglichkeiten – dieselben Optionen, die auch für die Bereitstellung von Services oder Apps in einem Kubernetes-Cluster verwendet werden können.
- ClusterIP
- NodePort
- LoadBalancer
Standardmäßig wird der MQTT-Broker mit der ClusterIP-Konfiguration eingerichtet. Das bedeutet, dass der Broker eine interne IP-Adresse erhält, die nur innerhalb des Clusters von anderen Pods erreichbar ist.
Wenn der Broker mit NodePort konfiguriert wird, ist der Service auch von außen zugänglich. Hierbei wird ein bestimmter Port auf allen Nodes des Clusters geöffnet, und der eingehende Verkehr wird an den entsprechenden Pod weitergeleitet.
Für den öffentlichen Zugriff über das Internet kann der LoadBalancer-Service verwendet werden. Dieser stellt eine öffentliche IP-Adresse bereit und leitet den Datenverkehr über diese IP an die richtigen Pods im Cluster weiter. Dieser ist allerdings extern einzurichten und zu konfigurieren.
Ich habe meinen Cluster für dieses Beispiel auf einer Azure Virtual Machine eingerichtet und einen öffentlichen Zugriff via Load Balancer eingerichtet.
Testen der MQTT-Kommunikation via MQTTX:
💡 Hinweis: Natürlich könnt ihr jeden anderen MQTT Client verwenden
Folgende Anwendungsfälle sind oft typischerweise über MQTT Verbindungen gelöst:
- Maschinenüberwachung in Produktionsanlagen mit niedriger Latenz.
- Datenaggregation aus Sensornetzwerken, um Bandbreitenkosten zu minimieren.
- Edge-zu-Edge-Kommunikation, um IoT-Geräte in einem Netzwerk direkt zu verknüpfen.
OPC UA für industrielle Kommunikation
Azure IoT Operations unterstützt OPC UA (Open Platform Communications Unified Architecture), ein offener Industriestandard für die nahtlose und sichere Kommunikation zwischen Maschinen.
Vorteile der OPC UA-Integration in Azure IoT Operations:
- Echtzeit-Datenabruf von industriellen Maschinen: Ermöglicht den kontinuierlichen Zugriff auf aktuelle Betriebsdaten, was für die Überwachung und Optimierung von Produktionsprozessen unerlässlich ist.
- Sicherer Zugriff durch rollenbasierte Berechtigungen (RBAC): Stellt sicher, dass nur autorisierte Personen auf spezifische Daten und Funktionen zugreifen können, wodurch die Sicherheit und Integrität des Systems gewährleistet wird.
- Veröffentlichung von JSON-codierten Telemetriedaten im OPC UA PubSub-Format: Durch die Nutzung standardisierter Datenformate wird die Interoperabilität zwischen verschiedenen Systemen verbessert und zukünftige Kompatibilitätsprobleme werden minimiert.
- Automatische Wiederverbindung zu OPC UA-Servern: Sorgt für eine stabile und zuverlässige Datenkommunikation, selbst bei temporären Netzwerkunterbrechungen oder Serverausfällen.
- Unterstützung von Nutzlastkompression wie gzip und brotli: Reduziert die Bandbreitennutzung und verbessert die Effizienz der Datenübertragung, insbesondere in Umgebungen mit begrenzter Netzwerkleistung.
Die Integration von OPC UA in Azure IoT Operations ermöglicht es Unternehmen, ihre industriellen Anlagen effizient mit modernen Cloud-Diensten zu vernetzen, wodurch eine verbesserte Datenanalyse und -nutzung realisiert werden kann.
OPC UA Server an Azure IoT Operations anbinden
Wenn ihr mit OPC UA Servern noch keine Erfahrung gesammelt habt, kann es sinnvoll sein das Szenario lokal nachzustellen. Falls ihr nur wissen möchtet, wie ein OPC UA Server an Azure IoT Operations angebunden wird, könnt ihr diesen Teil einfach überspringen.
Das Szenario lokal nachstellen
MSshujia
Der Sample OPC UA Server kann dazu verwendet werden. Diesen können wir mit folgendem Befehl auch lokal ausführen:
docker run -d --rm -p 51200:51200 -e SERVER_PORT=51200 mcr.microsoft.com/iot/opc-ua-test-server:latest💡 Hinweis: Docker muss auf eurem System installiert sein
Die URL für den OPC UA Server lautet:
opc.tcp://<Your_Network_IP>:51200/UA/SampleServer
Für eine erste Exploration verwende ich den UAExpert und lese die Werte von Boiler #1 aus:
Azure IoT Operations Anbindung
Das folgende Tutorial zeigt alles was es braucht, um Daten aus einem OPC UA Server an Azure IoT Operations anzubinden. Deshalb fällt dieser Abschnitt entsprechend kürzer aus.
dominicbetts
Beim Durchführen des Tutorials ist mir aufgefallen, wie aufwändig eine korrekte Anbindung und Konfiguration sein kann. Deshalb möchte ich einige Kernpunkte genauer aufschlüsseln.
kubectl apply -f https://raw.githubusercontent.com/Azure-Samples/explore-iot-operations/main/samples/quickstarts/opc-plc-deployment.yamlDeployment Befehl aus Tutorial
Hier ist eine detaillierte Aufschlüsselung der Schritte:
- Kubernetes Deployment des Container Images
- Einrichtung eines Deployments (
opc-plc-000000) für das OPC UA Container Image. - Volume Mount für OPC UA Zertifikate, die für die sichere Kommunikation benötigt werden.
- Einrichtung eines Deployments (
- Kubernetes Service zur Bereitstellung des OPC UA Servers
- Konfiguration eines internen Kubernetes Services (
opcplc-000000) mit ClusterIP für den Zugriff innerhalb des Clusters.
- Konfiguration eines internen Kubernetes Services (
- Self-signed Issuer Zertifikat
- Einrichtung eines selbstsignierten Issuers (
opc-plc-self-signed-issuer) für die Ausstellung von Zertifikaten im Namespace.
- Einrichtung eines selbstsignierten Issuers (
- Zertifikat für Anwendungen
- Erstellung eines Zertifikats (
opc-plc-default-application-cert) für die sichere Kommunikation der OPC PLC Anwendung. - Konfiguration von DNS-Namen und Nutzungsszenarien für das Zertifikat.
- Erstellung eines Zertifikats (
- Kubernetes Job
- Einrichtung eines Kubernetes Jobs (
opcplc-000000-execute-mutual-trust) zur Ausführung von Befehlen nach der Bereitstellung.
- Einrichtung eines Kubernetes Jobs (
- Kubernetes ConfigMap
- Bereitstellung einer ConfigMap (
opcplc-000000-execute-commands-script) mit Skripten zur Verwaltung von Zertifikaten und anderen Ressourcen.
- Bereitstellung einer ConfigMap (
- Kubernetes Role Binding
- Zuweisung von Berechtigungen durch Role Binding (
opc-plc-000000-secret-access-rolebinding) für den Zugriff auf Secrets im Namespace.
- Zuweisung von Berechtigungen durch Role Binding (
💡 Hinweis: Wenn ihr euren eigenen OPC UA Server anbinden wollt, müsst ihr diese Schritte und die sichere Authentifizierung zum Server berücksichtigen.
Schritte in der Operation Experience:
- Asset endpoint anlegen
- Asset anlegen
Nun prüfe ich auf dem Cluster via SSH, ob der Pod läuft
Schaue mir die logs des MQTT Brokers an, um zu prüfen, ob Nachrichten übermittelt werden
Die Logausgabe schaut gut aus 😄
Abschließend verbinde ich mich mit einem MQTT Client (MQTTX) mit dem MQTT Broker von Azure IoT Operations und subscribe auf das entsprechende MQTT Topic:
azure-iot-operations/data/thermostat
Wir sehen, dass Nachrichten ankommen, also war die Anbindung erfolgreich.
Ausblick
Bisher haben wir dennoch eher an der Oberfläche von Azure IoT Operations gekratzt und lediglich Grundlagenthemen bearbeitet. Meiner Meinung nach gibt es an der ein oder anderen Stelle auch noch Optimierungspotenzial, um eine Anbindung zu vereinfachen, da alles doch schnell sehr komplex werden kann und umfassendes Wissen im Bereich MQTT, OPC UA, Cloud, Linux Betriebssysteme, Kubernetes Cluster, Security, Zertifikatsmanagement und vielen anderen Themen benötigt.
Ich habe mich auf zwei Möglichkeiten in diesem Blogpost fokussiert, jedoch gibt es noch weiteres zu entdecken wenn du in die Architekturübersicht schaust. In weiteren Posts kann ich mir vorstellen etwa auf Themen wie z.B. Dataflows & Datenintegration mit Fabric genauer einzugehen, um so die Brücke zu Use-Cases schlagen zu können.
Ein spannender Trend ist die stärkere Verzahnung mit KI-gestützter Analyse und Automatisierung. Durch die Kombination von Azure IoT Operations mit Azure Machine Learning und Microsoft Fabric lassen sich Vorhersagemodelle trainieren, um beispielsweise Anomalien in Produktionsanlagen frühzeitig zu erkennen oder Wartungsintervalle präziser zu steuern (Predictive Maintenance).
Auch die Integration von IoT Security wird ein wichtiges Thema bleiben. Der Schutz verteilter Edge-Geräte vor Cyberangriffen und der sichere Austausch von Zertifikaten zwischen OPC UA-Servern und Azure IoT Operations erfordert robuste Sicherheitsmechanismen.
Für Unternehmen bedeutet dies: Wer frühzeitig auf Azure IoT Operations setzt, profitiert von einer zukunftssicheren und skalierbaren Plattform, die sich mit den neuesten Technologien weiterentwickelt. Jetzt ist der richtige Zeitpunkt, um erste Pilotprojekte zu starten und die Vorteile dieser modernen IoT-Architektur auszuschöpfen. 🚀
Fazit
Es ist entscheidend, den Fokus auf das eigentliche Problem nicht aus den Augen zu verlieren. Wenn die Potenziale von Azure IoT Operations nicht voll ausgeschöpft werden können, lohnt es sich, alternative, leichtgewichtigere Lösungen wie Azure IoT Edge in Betracht zu ziehen.
Azure IoT Operations bringt eine völlig neue Dimension in die Art und Weise, wie Unternehmen ihre IoT-Infrastrukturen verwalten und optimieren können. Besonders, wenn im Unternehmen bereits auf Container gesetzt wird. Durch die Kombination von Azure Arc, leistungsstarken Datenflüssen und Echtzeit-Analysen entsteht eine hochflexible, skalierbare Architektur, die sich sowohl in der Cloud als auch am Edge nahtlos integrieren lässt.
Besonders wertvoll ist die Brücke zwischen IT und OT, die es ermöglicht, industrielle Anlagen, Sensoren und IoT-Geräte intelligent zu vernetzen und zu überwachen. Daten aus verschiedenen Quellen – sei es von OPC UA-Servern, ONVIF-Kameras oder anderen industriellen Assets – werden gesammelt, verarbeitet und über standardisierte Protokolle wie MQTT weitergeleitet. Dank leistungsstarker Datenvisualisierungstools wie Power BI erhalten Entscheidungsträger tiefere Einblicke in ihre Prozesse und können schneller und fundierter handeln.
Darüber hinaus sorgt die enge Verzahnung mit Azure Arc für ein zentrales Management von Kubernetes-Workloads, Sicherheitsrichtlinien und Cloud-Services – egal ob on-premises oder in hybriden Umgebungen. Unternehmen profitieren von besseren Sicherheitsmechanismen, vereinfachter Verwaltung und höherer Automatisierung, wodurch sowohl Betriebskosten gesenkt als auch Innovationspotenziale freigesetzt werden.
Letztendlich geht es nicht nur um eine technologische Lösung, sondern um eine echte Transformation: Mehr Effizienz, mehr Sicherheit und mehr Agilität für die Zukunft der industriellen Digitalisierung.
