Freigeben über

Konfigurationsmuster für Edgeworkloads

Die breite Palette von Systemen und Geräten auf der Ladenfläche kann die Arbeitsauslastungskonfiguration zu einem schwierigen Problem machen. Dieser Artikel enthält Ansätze zur Lösung.

Kontext und Problem

Fertigungsunternehmen konzentrieren sich im Rahmen ihrer digitalen Transformationsreise zunehmend auf das Erstellen von Softwarelösungen, die als gemeinsame Funktionen wiederverwendet werden können. Aufgrund der breiten Palette von Geräten und Systemen auf der Ladenfläche sind die modularen Arbeitslasten so konfiguriert, dass unterschiedliche Protokolle, Treiber und Datenformate unterstützt werden. Manchmal werden sogar mehrere Instanzen einer Workload mit unterschiedlichen Konfigurationen am gleichen Edge-Standort ausgeführt. Bei einigen Workloads werden die Konfigurationen mehr als einmal pro Tag aktualisiert. Daher ist die Konfigurationsverwaltung für die Skalierung von Edgelösungen immer wichtiger.

Lösung

Es gibt einige allgemeine Merkmale der Konfigurationsverwaltung für Edgeworkloads:

  • Es gibt mehrere Konfigurationspunkte, die in unterschiedlichen Ebenen gruppiert werden können, z. B. Softwarequelle, CI/CD-Pipeline, Cloudmandant und Edgestandort: Diagramm der Ebenen, die Workloadkonfigurationen charakterisieren: Softwarequelle, C I/C D-Pipelines, Cloudmandant und Edgestandort.
  • Die verschiedenen Ebenen können von verschiedenen Personen aktualisiert werden.
  • Unabhängig davon, wie die Konfigurationen aktualisiert werden, müssen sie sorgfältig nachverfolgt und überwacht werden.
  • Für die Geschäftskontinuität ist es erforderlich, dass auf Konfigurationen offline am Edge zugegriffen werden kann.
  • Es ist auch erforderlich, dass es eine globale Ansicht der Konfigurationen gibt, die in der Cloud verfügbar sind.

Probleme und Überlegungen

Berücksichtigen Sie die folgenden Punkte, wenn Sie entscheiden, wie sie dieses Muster implementieren:

  • Das Zulassen von Bearbeitungen, wenn der Edge nicht mit der Cloud verbunden ist, erhöht die Komplexität der Konfigurationsverwaltung erheblich. Es ist möglich, Änderungen in der Cloud zu replizieren, aber es gibt Herausforderungen mit:
    • Benutzerauthentifizierung, da sie auf einem Clouddienst wie Microsoft Entra ID basiert.
    • Konfliktauflösung nach der erneuten Verbindung, wenn Workloads unerwartete Konfigurationen erhalten, die manuelle Eingriffe erfordern.
  • Die Edgeumgebung kann netzwerkbezogene Einschränkungen aufweisen, wenn die Topologie den ISA-95-Anforderungen entspricht. Sie können solche Einschränkungen überwinden, indem Sie eine Technologie auswählen, die Konnektivität über Ebenen bietet, z. B. Gerätehierarchien in Azure IoT Edge.
  • Wenn die Laufzeitkonfiguration von Softwareversionen entkoppelt wird, müssen Konfigurationsänderungen separat behandelt werden. Um Verlaufs- und Rollbackfunktionen anzubieten, müssen Sie frühere Konfigurationen in einem Datenspeicher in der Cloud speichern.
  • Ein Fehler in einer Konfiguration, z. B. eine Konnektivitätskomponente, die auf einen nicht vorhandenen Endpunkt konfiguriert ist, kann die Arbeitsauslastung unterbrechen. Daher ist es wichtig, Konfigurationsänderungen beim Behandeln anderer Bereitstellungslebenszyklusereignisse in der Observability-Lösung zu behandeln, damit die Observability-Dashboards Systemfehler mit Konfigurationsänderungen korrelieren können. Weitere Informationen zur Observierbarkeit finden Sie im Leitfaden zur Cloudüberwachung: Observability.
  • Verstehen Sie die Rollen, die Cloud- und Edgedatenspeicher für die Betriebskontinuität spielen. Wenn der Cloud-Datenspeicher die einzige Wahrheitsquelle ist, sollten die Edgeworkloads in der Lage sein, beabsichtigte Zustände mithilfe automatisierter Prozesse wiederherzustellen.
  • Zur Ausfallsicherheit sollte der Edgedatenspeicher als Offlinecache fungieren. Dies hat Vorrang vor Latenzaspekten.

Wann dieses Muster verwendet werden soll

Verwenden Sie dieses Muster in folgenden Fällen:

  • Es gibt eine Anforderung, Workloads außerhalb des Softwareveröffentlichungszyklus zu konfigurieren.
  • Unterschiedliche Personen müssen konfigurationen lesen und aktualisieren können.
  • Konfigurationen müssen auch dann verfügbar sein, wenn keine Verbindung mit der Cloud besteht.

Beispielarbeitslasten:

  • 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, die in Echtzeit auf Qualität in der Fertigungslinie prüfen

Beispiele

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

Variation des externen Konfigurationscontrollers

Diagramm der Architektur für die Variation des externen Konfigurationscontrollers.

Diese Variation verfügt über einen Konfigurationscontroller, der sich außerhalb der Workload befindet. Die Rolle der Cloudkonfigurationscontroller-Komponente besteht darin, Bearbeitungen vom Clouddatenspeicher über den Edgekonfigurationscontroller an die Workload zu übertragen. Der Edge enthält auch einen Datenspeicher, sodass das System auch dann funktioniert, wenn die Verbindung mit der Cloud getrennt wird.

Mit IoT Edge kann der Edgekonfigurationscontroller als Modul implementiert werden, und die Konfigurationen können mithilfe von Modulzwillingen angewendet werden. Das Modul-Twin hat eine Größenbeschränkung; Wenn die Konfiguration den Grenzwert überschreitet, kann die Lösung mit Azure Blob Storage oder durch Zerteilen größerer Nutzlasten in Blöcken über direkte Methoden erweitert werden.

Die Vorteile dieser Variante sind:

  • Die Workload selbst muss über keine Informationen zum Konfigurationssystem verfügen. Diese Funktion ist eine Anforderung, wenn der Quellcode der Workload nicht bearbeitet werden kann, z. B. wenn Sie ein Modul aus dem Azure IoT Edge Marketplace verwenden.
  • Es ist möglich, die Konfiguration mehrerer Workloads gleichzeitig zu ändern, indem die Änderungen über den Cloudkonfigurationscontroller koordiniert werden.
  • Eine zusätzliche Überprüfung kann als Teil der Pushpipeline implementiert werden, z. B. um das Vorhandensein von Endpunkten am Edge zu überprüfen, bevor die Konfiguration an die Workload übertragen wird.

Variation des internen Konfigurationsanbieters

Diagramm der Architektur für die Variation des internen Konfigurationsanbieters.

Bei der Variante des internen Konfigurationsanbieters zieht die Workload Konfigurationen von einem Konfigurationsanbieter. Ein Implementierungsbeispiel finden Sie unter Implementieren eines benutzerdefinierten Konfigurationsanbieters in .NET. In diesem Beispiel wird C# verwendet, andere Sprachen können jedoch verwendet werden.

In dieser Variante weisen die Workloads eindeutige Bezeichner auf, sodass der gleiche Quellcode, der in verschiedenen Umgebungen ausgeführt wird, unterschiedliche Konfigurationen aufweisen kann. Eine Möglichkeit, einen Bezeichner zu erstellen, besteht darin, die hierarchische Beziehung der Workload mit einer Gruppierung auf oberster Ebene, wie etwa einem Mandanten, zu verknüpfen. Bei IoT Edge kann es sich um eine Kombination aus Azure-Ressourcengruppe, IoT-Hubnamen, IoT Edge-Gerätenamen und Modulbezeichner handeln. Diese Werte bilden zusammen einen eindeutigen Bezeichner, der als Schlüssel in den Datenspeichern funktioniert.

Obwohl die Modulversion dem eindeutigen Bezeichner hinzugefügt werden kann, ist es eine häufige Anforderung, Konfigurationen über Softwareupdates hinweg beizubehalten. Wenn die Version Teil des Bezeichners ist, sollte die alte Version der Konfiguration mit einer zusätzlichen Implementierung vorwärts migriert werden.

Die Vorteile dieser Variante sind:

  • Abgesehen von den Datenspeichern erfordert die Lösung keine Komponenten, wodurch die Komplexität reduziert wird.
  • Migrationslogik aus inkompatiblen alten Versionen kann innerhalb der Workloadimplementierung behandelt werden.

Lösungen, die auf IoT Edge basieren

Diagramm der Architektur für die IoT-Edge-basierte Variation.

Die Cloudkomponente der IoT Edge-Referenzimplementierung besteht aus einem IoT-Hub, der als Cloudkonfigurationscontroller fungiert. Die Twin-Funktionalität des Azure IoT Hub-Moduls verteilt Konfigurationsänderungen und Informationen zur aktuell angewendeten Konfiguration mithilfe der gewünschten und gemeldeten Eigenschaften des Moduls Twin. Der Konfigurationsverwaltungsdienst fungiert als Quelle der Konfigurationen. Es kann auch eine Benutzeroberfläche für die Verwaltung von Konfigurationen, ein Buildsystem und andere Tools sein, die zum Erstellen von Workloadkonfigurationen verwendet werden.

Eine Azure Cosmos DB-Datenbank speichert alle Konfigurationen. Sie kann mit mehreren IoT-Hubs interagieren und stellt den Konfigurationsverlauf bereit.

Nachdem ein Edgegerät über gemeldete Eigenschaften angegeben hat, dass eine Konfiguration angewendet wurde, notiert der Konfigurationsstatusdienst das Ereignis in der Datenbankinstanz.

Wenn eine neue Konfiguration im Konfigurationsverwaltungsdienst erstellt wird, wird sie in Azure Cosmos DB gespeichert, und die gewünschten Eigenschaften des Edgemoduls werden im IoT-Hub geändert, in dem sich das Gerät befindet. Die Konfiguration wird dann vom IoT Hub an das Edgegerät übertragen. Das Edgemodul muss daraufhin die Konfiguration anwenden und den Status der Konfiguration über den Modulzwilling melden. Der Konfigurationsstatusdienst lauscht dann auf Twin Change-Ereignisse und zeichnet nach dem Erkennen, dass ein Modul eine Konfigurationsstatusänderung meldet, die entsprechende Änderung in der Azure Cosmos DB-Datenbank auf.

Die Edgekomponente kann entweder den externen Konfigurationscontroller oder internen Konfigurationsanbieter verwenden. In beiden Szenarien überträgt der Controller die Konfiguration in den gewünschten Eigenschaften des Modultwins. Bei großen Konfigurationen enthalten die gewünschten Eigenschaften des Moduldoppelgängers eine URL zu Azure Blob Storage oder zu einem anderen Dienst zum Abrufen der Konfiguration. 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 verwaltet. Sie wurde ursprünglich von den folgenden Mitwirkenden verfasst.

Hauptautor:

Um nicht öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte

  • Last updated on