Freigeben über

Konfigurationsmuster für Edgeworkloads

  • Artikel

Die große Vielfalt von Systemen und Geräten im Fertigungsbereich kann die Workloadkonfiguration zu einer schwierigen Aufgabe machen. Dieser Artikel enthält Ansätze zur Lösung dieses Problems.

Kontext und Problem

Fertigungsunternehmen konzentrieren sich im Zuge ihrer digitalen Transformation zunehmend auf die Erstellung von Softwarelösungen, die als gemeinsam genutzte Funktionen wiederverwendet werden können. Aufgrund der vielfältigen Geräte und Systeme im Fertigungsbereich werden die modularen Workloads für die Unterstützung verschiedener Protokolle, Treiber und Datenformate konfiguriert. Manchmal werden sogar mehrere Instanzen einer Workload mit unterschiedlichen Konfigurationen am gleichen Edgestandort ausgeführt. Bei einigen Workloads werden die Konfigurationen mehrmals täglich aktualisiert. Daher wird die Konfigurationsverwaltung für die horizontale Skalierung von Edgelösungen immer wichtiger.

Lösung

Die Konfigurationsverwaltung für Edgeworkloads weist einige allgemeine Merkmale auf:

  • Es gibt mehrere Konfigurationspunkte, die zu individuellen Ebenen wie Softwarequelle, CI/CD-Pipeline, Cloudmandant und Edgestandort gruppiert werden können: Diagramm der Ebenen von Workloadkonfigurationen: Softwarequelle, CI/CD-Pipeline, Cloudmandant und Edgestandort
  • Die verschiedenen Ebenen können von unterschiedlichen Personen aktualisiert werden.
  • Die Konfiguration müssen sorgfältig nachverfolgt und überwacht werden – unabhängig davon, wie sie aktualisiert werden.
  • Zur Gewährleistung der Geschäftskontinuität muss es möglich sein, im Edgebereich offline auf Konfigurationen zuzugreifen.
  • Außerdem muss in der Cloud eine globale Ansicht der Konfigurationen verfügbar sein.

Probleme und Überlegungen

Beachten Sie die folgenden Punkte bei der Entscheidung, wie dieses Muster implementiert werden soll:

  • Das Zulassen von Bearbeitungen, wenn der Edge nicht mit der Cloud verbunden ist, erhöht die Komplexität der Konfigurationsverwaltung erheblich. Änderungen können zwar in der Cloud repliziert werden, es gibt jedoch Herausforderungen in folgenden Bereichen:
    • Benutzerauthentifizierung, da sie auf einem Clouddienst wie Microsoft Entra ID basiert.
    • Konfliktlösung nach erneuter Verbindungsherstellung, wenn Workloads unerwartete Konfigurationen erhalten, die einen manuellen Eingriff erfordern
  • In der Edgeumgebung können netzwerkbezogene Einschränkungen vorhanden sein, wenn die Topologie den ISA-95-Anforderungen entspricht. Solche Einschränkungen lassen sich durch die Verwendung einer Technologie mit ebenenübergreifender Konnektivität überwinden (beispielsweise Gerätehierarchien in Azure IoT Edge).
  • Wenn die Laufzeitkonfiguration von Softwarereleases entkoppelt ist, müssen Konfigurationsänderungen separat behandelt werden. Um Verlaufs- und Rollbackfunktionen bereitstellen zu können, müssen frühere Konfigurationen in einem Datenspeicher in der Cloud gespeichert werden.
  • Ein Fehler in einer Konfiguration (etwa eine Konnektivitätskomponente, die für einen nicht vorhandenen Endpunkt konfiguriert ist) kann die Workload unterbrechen. Daher ist es wichtig, Konfigurationsänderungen wie andere Ereignisse des Bereitstellungslebenszyklus in der Lösung zur Gewinnung von Einblicken zu behandeln, damit die Einblickdashboards dabei helfen können, Systemfehler mit Konfigurationsänderungen zu korrelieren. Weitere Informationen zu Einblicken finden Sie unter Leitfaden zur Cloudüberwachung: Einblick.
  • Machen Sie sich mit der Rolle vertraut, die Cloud- und Edgedatenspeicher für die Geschäftskontinuität spielen. Wenn der Clouddatenspeicher als Single Source of Truth (einzige Quelle der Wahrheit) fungiert, müssen die Edgeworkloads beabsichtigte Zustände mithilfe automatisierter Prozesse wiederherstellen können.
  • Aus Resilienzgründen sollte der Edgedatenspeicher als Offlinecache fungieren. Dies hat Vorrang vor Überlegungen zur Wartezeit.

Verwendung dieses Musters

Verwenden Sie dieses Muster in folgenden Fällen:

  • Workloads müssen außerhalb des Softwarereleasezyklus konfiguriert werden.
  • Konfigurationen müssen von verschiedenen Personen gelesen und aktualisiert werden können.
  • Konfigurationen müssen auch dann verfügbar sein, wenn keine Verbindung mit der Cloud besteht.

Beispielworkloads:

  • Lösungen, die eine Verbindung mit Ressourcen im Fertigungsbereich herstellen, um Daten zu erfassen (beispielsweise OPC Publisher) und Befehle und Steuerungsoptionen zu verwenden
  • Machine Learning-Workloads für Predictive Maintenance
  • Machine Learning-Workloads zur Prüfung der Fertigungsqualität in Echtzeit

Beispiele

Die Lösung zum Konfigurieren von Edgeworkloads während der Laufzeit kann auf einem externen Konfigurationscontroller oder auf einem internen Konfigurationsanbieter basieren.

Variante mit externem Konfigurationscontroller

Diagramm: Architektur für die Variante mit externem Konfigurationscontroller

Bei dieser Variante wird ein Konfigurationscontroller verwendet, der sich außerhalb der Workload befindet. Der Cloudkonfigurationscontroller hat die Aufgabe, Bearbeitungen aus dem Clouddatenspeicher über den Edgekonfigurationscontroller an die Workload zu pushen. Im Edgebereich befindet sich ebenfalls ein Datenspeicher, sodass das System auch dann funktioniert, wenn es nicht mit der Cloud verbunden ist.

Mit IoT Edge kann der Edgekonfigurationscontroller als Modul implementiert werden, und die Konfigurationen können mithilfe von Modulzwillingen angewendet werden. Für den Modulzwilling gilt eine Größenbeschränkung. Ist die Konfiguration zu groß, können Sie die Lösung mit Azure Blob Storage erweitern oder größere Nutzdaten über direkte Methoden segmentieren.

Diese Variante hat folgende Vorteile:

  • Die Workload selbst muss über keine Informationen zum Konfigurationssystem verfügen. Dies ist eine Voraussetzung, wenn der Quellcode der Workload nicht bearbeitet werden kann – etwa bei der Verwendung eines Moduls aus dem Azure IoT Edge Marketplace.
  • Änderungen können über den Cloudkonfigurationscontroller koordiniert werden, um die Konfiguration mehrerer Workloads gleichzeitig zu ändern.
  • Im Rahmen der Pushpipeline kann eine zusätzliche Überprüfung implementiert werden, um beispielsweise die Existenz von Endpunkten am Edge zu überprüfen, bevor die Konfiguration an die Workload gepusht wird.

Variante mit internem Konfigurationsanbieter

Diagramm: Architektur für die Variante mit internem Konfigurationscontroller

Bei der Variante mit internem Konfigurationsanbieter pullt die Workload Konfigurationen von einem Konfigurationsanbieter. Ein Implementierungsbeispiel finden Sie unter Implementieren eines benutzerdefinierten Konfigurationsanbieters in .NET. In diesem Beispiel wird C# verwendet. Es können aber auch andere Programmiersprachen verwendet werden.

Bei dieser Variante verfügen die Workloads über eindeutige Bezeichner. Dadurch kann in verschiedenen Umgebungen der gleiche Quellcode mit unterschiedlichen Konfigurationen ausgeführt werden. Zur Erstellung eines Bezeichners kann beispielsweise die hierarchische Beziehung der Workload mit einer Gruppierung der obersten Ebene (etwa einem Mandanten) verkettet werden. Für IoT Edge kann dazu beispielsweise eine Kombination aus Azure-Ressourcengruppe, IoT Hub-Name, IoT Edge-Gerätename und Modulbezeichner verwendet werden. Diese Werte bilden zusammen einen eindeutigen Bezeichner, der als Schlüssel in den Datenspeichern fungiert.

Es ist zwar möglich, dem eindeutigen Bezeichner die Modulversion hinzuzufügen, in der Regel sollen Konfigurationen jedoch über Softwareupdates hinweg erhalten bleiben. Wenn die Version Teil des Bezeichners ist, sollte die alte Version der Konfiguration mit einer zusätzlichen Implementierung migriert werden.

Diese Variante hat folgende Vorteile:

  • Abgesehen von den Datenspeichern sind für die Lösung keine weiteren Komponenten erforderlich, was die Komplexität verringert.
  • Migrationslogik aus inkompatiblen alten Versionen kann innerhalb der Workloadimplementierungen behandelt werden.

IoT Edge-basierte Lösungen

Diagramm: Architektur für die IoT Edge-basierte Variante

Die Cloudkomponente der IoT Edge-Referenzimplementierung besteht aus einem IoT-Hub, der als Cloudkonfigurationscontroller fungiert. Die Modulzwillingsfunktion von Azure IoT Hub gibt Konfigurationsänderungen und Informationen zur aktuell angewendeten Konfiguration unter Verwendung der gewünschten und gemeldeten Eigenschaften des Modulzwillings weiter. Der Konfigurationsverwaltungsdienst fungiert als Quelle der Konfigurationen. Er kann auch als Benutzeroberfläche für die Konfigurationsverwaltung, als Buildsystem und als andere Tools für die Erstellung von Workloadkonfigurationen verwendet werden.

Alle Konfigurationen werden in einer Azure Cosmos DB-Datenbank gespeichert. Sie kann mit mehreren IoT-Hubs interagieren und stellt den Konfigurationsverlauf bereit.

Nachdem ein Edgegerät über gemeldete Eigenschaften angibt, dass eine Konfiguration angewendet wurde, wird das Ereignis vom Konfigurationsstatusdienst in der Datenbankinstanz vermerkt.

Wenn im Konfigurationsverwaltungsdienst eine neue Konfiguration erstellt wird, wird sie in Azure Cosmos DB gespeichert, und die gewünschten Eigenschaften des Edgemoduls werden in dem IoT-Hub geändert, in dem sich das Gerät befindet. Die Konfiguration wird dann von IoT Hub an das Edgegerät übertragen. Das Edgemodul muss daraufhin die Konfiguration anwenden und den Status der Konfiguration über den Modulzwilling melden. Anschließend lauscht der Konfigurationsstatusdienst auf Zwillingsänderungsereignisse. Wird von einem Modul eine Änderung des Konfigurationsstatus gemeldet, wird die entsprechende Änderung in der Azure Cosmos DB-Datenbank erfasst.

Von der Edgekomponente kann entweder der externe Konfigurationscontroller oder der internen Konfigurationsanbieter verwendet werden. In beiden Implementierungen wird die Konfiguration in den gewünschten Eigenschaften des Modulzwillings übertragen. Falls große Konfigurationen übertragen werden müssen, enthalten die gewünschten Eigenschaften des Modulzwillings eine URL zu Azure Blob Storage oder zu einem anderen Dienst, der zum Abrufen der Konfiguration verwendet werden kann. Das Modul signalisiert dann in den gemeldeten Eigenschaften des Modulzwillings, ob die neue Konfiguration erfolgreich angewendet wurde und welche Konfiguration derzeit verwendet wird.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte