Teilen über

Skalieren einer Azure IoT Hub-Lösung zur Unterstützung von Millionen von Geräten

  • Artikel

In diesem Artikel wird beschrieben, wie Sie eine IoT-Lösung (Internet of Things) mit einem Skalierungsmuster auf der Azure IoT Hub-Plattform skalieren. Das Muster für horizontale Skalierung löst Skalierungsprobleme, indem Instanzen zu einer Bereitstellung hinzugefügt werden, anstatt die Instanzgröße zu erhöhen. Der Implementierungsleitfaden hier zeigt Ihnen, wie Sie eine IoT-Lösung mit Millionen von Geräten und Konten für die Grenzwerte für Dienste und Abonnements in Azure skalieren. Der Artikel beschreibt die Low-Touch- und Zero-Touch-Bereitstellungsmodelle des Musters für horizontale Skalierung, die Sie je nach Bedarf anwenden können. Weitere Informationen finden Sie in folgenden Artikeln:

Ein Diagramm mit den wichtigsten Schritten, die Sie beim Skalieren Ihrer Azure IoT-Lösung befolgen

Hinweis

Dieses Dokument behandelt nicht die Azure IoT Operations-Plattform , die basierend auf der Hostkonfiguration der Kubernetes-Plattform skaliert wird.

Erfassen von Anforderungen

Sie sollten immer Anforderungen sammeln, bevor Sie eine neue IoT-Lösung implementieren. Ausgehend von den Anforderungen können Sie sicherstellen, dass die Implementierung Ihren Geschäftszielen entspricht. Die Geschäftsziele und die betriebliche Umgebung sollten die Anforderungen bestimmen, die Sie sammeln müssen. Zumindest sollten Sie die folgenden Anforderungen kennen:

Die Gerätetypen, die Sie bereitstellen möchten. Das Internet der Dinge umfasst eine breite Palette von Lösungen, von einfachen Mikrocontrollern (MCUs) über mittelgroße System-on-Chip(SOC)- und Mikroprozessor(MPU)-Lösungen bis hin zu vollständigen Designs auf PC-Ebene. Die geräteseitigen Softwarefunktionen haben direkten Einfluss auf das Design der Lösung.

Die Anzahl der bereitzustellenden Geräte. Einige der Grundprinzipien der Implementierung von IoT-Lösungen gelten für alle Staffelungen. Die Kenntnis der Staffelung hilft dabei, eine Lösung zu vermeiden, die komplizierter ist als nötig. Eine Lösung für 1.000 Geräte wird sich in einigen Punkten grundlegend von einer Lösung für 1 Million Geräte unterscheiden. Eine Proof-of-Concept(PoC)-Lösung für 10.000 Geräte lässt sich möglicherweise nicht angemessen auf 10 Millionen Geräte skalieren, wenn die Zielstaffelung zu Beginn des Lösungsdesigns nicht berücksichtigt wurde.

Wenn Sie wissen, wie viele Geräte Sie bereitstellen müssen, können Sie den richtigen Azure IoT-Dienst auswählen. Die Skalierung für IoT Hub und für IoT Hub Device Provisioning Service (DPS) ist unterschiedlich. Eine einzelne DPS-Instanz kann standardmäßig an mehrere IoT Hub-Instanzen weitergeleitet werden. Daher muss die Skalierung jedes Diensts in Bezug auf die Anzahl der Geräte individuell berücksichtigt werden. In einem Vakuum gibt es jedoch keine Grenzwerte. Wenn Grenzwerte bei einem Dienst ein Problem darstellen, sind sie in der Regel auch bei anderen ein Problem. Daher sollten Dienstgrenzwerte als unterschiedliche, aber verwandte Kontingente betrachtet werden.

Dokumentation der erwarteten Gerätestandorte. Dazu gehören nicht nur der physische Standort, sondern auch die Verfügbarkeit von Strom und Internetanschlüssen. Eine Lösung, die an einem einzelnen geografischen Standort (z. B. nur in Nordamerika) bereitgestellt wird, ist anders konzipiert als eine globale Lösung. Ebenso unterscheidet sich eine industrielle IoT-Lösung, die in Fabriken mit ganztägiger Stromversorgung eingesetzt wird, von einer Flottenmanagementlösung, die in Kraftfahrzeugen mit variabler Stromversorgung und Standort eingesetzt wird. Auch das verwendete Protokoll und die Bandbreite, die für die Kommunikation der Geräte mit einem Gateway oder direkt mit Clouddiensten zur Verfügung steht, beeinflussen die Skalierbarkeit des Designs auf jeder Ebene. Verborgen in diesem Aspekt ist die Verfügbarkeit der Konnektivität. Wird erwartet, dass die Geräte mit Azure verbunden bleiben, oder werden sie über einen längeren Zeitraum in einem getrennten Modus ausgeführt?

Untersuchung der Anforderungen an die Datenlokalität. Möglicherweise gibt es rechtliche, Compliance- oder Kundenanforderungen in Bezug auf den Ort, an dem Sie Daten (z. B. Telemetrie) oder Metadaten (Daten über die Daten, z. B. welche Geräte vorhanden sind) für die Lösung speichern können. Wenn es solche Einschränkungen gibt, sind sie ein wichtiger Faktor für das geografische Design der Lösung.

Bestimmen der Anforderungen für den Datenaustausch. Eine Lösung, die grundlegende Telemetriedaten wie „aktuelle Temperatur“ einmal pro Stunde sendet, unterscheidet sich von einer Lösung, die alle 10 Minuten 1 MB an Stichprobendateien hochlädt. Eine Lösung, die in erster Linie eine unidirektionale Lösung von Gerät zu Cloud (D2C) ist, unterscheidet sich von einer bidirektionalen Lösung von Gerät zu Cloud und Cloud zu Gerät (C2D). Auch die Einschränkungen der Produktskalierbarkeit behandeln Nachrichtengröße und Nachrichtenmenge als unterschiedliche Dimensionen.

Dokumentieren der erwarteten Anforderungen an Hochverfügbarkeit und Notfallwiederherstellung. Wie bei jeder Produktionslösung umfassen auch die Designs für vollständige IoT-Lösungen Anforderungen an die Verfügbarkeit (Uptime). Das Design muss sowohl geplante Wartungsszenarien als auch ungeplante Ausfallzeiten abdecken, einschließlich Benutzerfehlern, Umgebungsfaktoren und Lösungsfehlern. Solche Designs müssen auch ein dokumentiertes Wiederherstellungspunktziel (RPO) und Wiederherstellungszeitziel (Recovery Time Objective, RTO) aufweisen, wenn ein Notfall auftritt, z. B. ein dauerhafter Verlust der Region oder böswillige Akteure. Da sich dieser Artikel auf die Skalierung von Geräten konzentriert, enthält er nur eine begrenzte Menge an Informationen zu den Themen Hochverfügbarkeit und Notfallwiederherstellung (HA/DR).

Entscheidung für ein Kundenmandantenmodell (falls zutreffend). Bei einer mehrinstanzenfähigen Lösung eines unabhängigen Softwareanbieters (Independent Software Vendor, ISV), bei der der Lösungsentwickler eine Lösung für externe Kund*innen erstellt, muss beim Design berücksichtigt werden, wie die Kundendaten getrennt und verwaltet werden. Das Azure Architecture Center erläutert allgemeine Muster und enthält IoT-spezifische Leitfäden.

Grundlegendes zu Azure IoT-Konzepten

Zur Erstellung der Lösung gehört auch die Auswahl der Azure IoT-Komponenten (und möglicherweise anderer unterstützender Azure-Dienste), die Sie als Teil der Lösung verwenden, einschließlich der unterstützenden Dienste. Ein großer Teil Ihres Aufwands entfällt auf die Architektur, die im Mittelpunkt dieses Dokuments steht. Wenn Sie Azure IoT Hub und die Azure IoT Hub DPS-Dienste richtig einsetzen, können Sie Ihre Lösungen auf Millionen von Geräten skalieren.

Azure IoT Hub

Azure IoT Hub ist ein verwalteter Dienst, der in der Cloud gehostet wird und als zentraler Nachrichten-Hub für die Kommunikation zwischen einer IoT-Anwendung und deren angeschlossenen Geräten fungiert. Der Dienst kann allein oder mit Azure IoT Hub DPS verwendet werden.

Azure IoT Hub wird anhand der Kombination aus gewünschter Funktionalität und der Anzahl der gewünschten Nachrichten pro Tag oder Daten pro Tag skaliert. Für die Auswahl der Skalierung einer Instanz werden drei Eingaben verwendet:

  • Die Dienstebene – „Free“, „Basic“ oder „Standard“ – bestimmt, welche Funktionen verfügbar sind. Eine Produktionsinstanz verwendet nicht die Dienstebene „Free“, da sie in der Skalierung begrenzt und nur für Einführungsentwicklungsszenarien vorgesehen ist. Die meisten Lösungen verwenden die Standardebene, um die vollen Funktionen von IoT Hub zu erhalten.
  • Die Größe bestimmt die Basiseinheit des Nachrichten- und Datendurchsatzes für Gerät-zu-Cloud-Nachrichten für IoT Hub. Die maximale Größe für eine Instanz von IoT Hub ist Größe 3, die 300 Millionen Nachrichten pro Tag und 1.114,4 GB an Daten pro Tag pro Einheit unterstützt.
  • Die Anzahl der Einheiten bestimmt den Multiplikator für die Skalierung der Größe. Zum Beispiel unterstützen drei Einheiten die dreifache Größe einer Einheit. Der Grenzwert für Hubinstanzen der Größe 1 oder 2 beträgt 200 Einheiten, und der Grenzwert für Hubinstanzen der Größe 3 beträgt 10 Einheiten.

Neben den täglichen Grenzwerten, die an die Größe und die Anzahl der Geräte gebunden sind, und den allgemeinen Funktionsbeschränkungen, die an die Stufe gebunden sind, gibt es Grenzwerte für den Durchsatz pro Sekunde. Und es gibt einen Grenzwert von 1 Million Geräten pro IoT Hub-Instanz als weichen Grenzwert. Obwohl es sich um einen weichen Grenzwert handelt, gibt es auch einen harten Grenzwert. Selbst wenn Sie eine Grenzwerterhöhung anfordern möchten, sollten Sie den weichen Grenzwert als Designgrenzwert verwenden, um Probleme in der Zukunft zu vermeiden. Die Anforderungen an den Datenaustausch helfen Ihnen bei der Lösung dieses Problems. Weitere Informationen finden Sie unter Andere Limits.

Die Anforderungen an Ihre Lösung bestimmen die erforderliche Größe und Anzahl der IoT-Hubs als Startpunkt. Wenn Sie IoT Hub DPS verwenden, unterstützt Azure Sie bei der Verteilung Ihrer Workloads auf mehrere IoT Hub Instanzen.

Azure IoT Hub Device Provisioning Service

Azure IoT Hub Device Provisioning Service (DPS) ist ein Hilfsdienst für IoT Hub und ermöglicht eine unbeaufsichtigte Just-In-Time-Bereitstellung im richtigen IoT-Hub ganz ohne Benutzereingriff. Außerdem gilt ein fester Grenzwert von 10 DPS-Instanzen pro Azure-Abonnement. Der Dienst hat auch einen festen Grenzwert von 1 Million Registrierungen pro Dienstinstanz. Sie müssen Dienstgrenzwerte in Ihrem Workloadentwurfslimit adressieren, um Probleme in Zukunft zu vermeiden.

Dienstinstanzen für DPS sind zwar geografisch lokal, verfügen jedoch standardmäßig über einen globalen öffentlichen Endpunkt. Auf bestimmte Instanzen wird über den ID-Gültigkeitsbereich zugegriffen. Da sich Instanzen in bestimmten Regionen befinden und jede Instanz über einen eigenen ID-Bereich verfügt, sollten Sie in der Lage sein, den ID-Bereich für Ihre Geräte zu konfigurieren.

Grundlegendes zu gemeinsam genutzten Resilienzkonzepten

Einige wichtige gemeinsame Resilienzkonzepte, die Sie berücksichtigen müssen, sind die Behandlung vorübergehender Fehler, die Auswirkungen auf den Gerätestandort und – für ISVs – die Datenresilienz von Software-as-a-Service (SaaS).

Grundlegendes zur Behandlung vorübergehender Fehler. Jede produktionsseitig verteilte Lösung, ob lokal oder in der Cloud, muss in der Lage sein, nach vorübergehenden Fehlern wiederherzustellen. Vorübergehende Fehler werden in einer Cloudlösung gelegentlich als wahrscheinlicher betrachtet, weil:

  • Auf einen externen Anbieter vertraut wird.
  • Auf die Netzwerkkonnektivität zwischen dem Gerät und den Clouddiensten vertraut wird.
  • Implementierungsgrenzwerte der Clouddienste gelten.

Wie in Azure Architecture Center beschrieben, erfordert die Behandlung vorübergehender Fehler, dass Sie über eine Wiederholungsfunktion verfügen, die in Ihren Gerätecode integriert ist. Es gibt mehrere Wiederholungsstrategien (z. B. exponentielles Backoff mit Randomisierung, auch bekannt als exponentielles Backoff mit Jitter), die in der Behandlung vorübergehender Fehler beschrieben werden. Dieser Artikel bezieht sich ohne weitere Erläuterung auf diese Muster. Sollten Sie damit nicht vertraut sein, sehen Sie sich diese Seite an.

Die Netzwerkkonnektivität eines Geräts wird von verschiedenen Faktoren beeinflusst:

  • Energiequelle eines Geräts. Akkubetriebene Geräte oder Geräte, die von vorübergehenden Quellen wie Solar- oder Windstrom betrieben werden, verfügen möglicherweise über weniger Netzwerkkonnektivität als ständig mit der Stromversorgung verbundene Geräte.
  • Bereitstellungsstandort eines Geräts. Geräte, die sich in urbanen Fabrikumgebungen befinden, verfügen wahrscheinlich über eine bessere Netzwerkkonnektivität als Geräte, die sich in isolierten Umgebungen befinden.
  • Standortstabilität eines Geräts. Mobile Geräte verfügen wahrscheinlich über weniger Netzwerkkonnektivität als Geräte mit festen Standorten.

Alle diese Bedenken auch auf den Zeitpunkt der Geräteverfügbarkeit und -konnektivität aus. Bei netzbetriebenen Geräten, die in dichten, städtischen Umgebungen weit verbreitet sind (z. B. intelligente Lautsprecher), kann es vorkommen, dass eine große Anzahl von Geräten auf einmal offline geht und dann auf einmal wieder online geht. Mögliche Szenarien:

  • Ein Stromausfall, bei dem 1 Million Geräte gleichzeitig vom Netz gehen und durch die Wiederherstellung der Stromversorgung gleichzeitig wieder online gehen können. Dieses Szenario gilt sowohl für Verbraucherszenarien (z. B. intelligente Lautsprecher) als auch für geschäftliche und industrielle IoT-Szenarien (z. B. vernetzte, netzbetriebene Thermostate, die an ein Immobilienverwaltungsunternehmen melden).
  • Ein kurzfristiges, umfangreiches Onboarding, wie z. B. am Black Friday oder zu Weihnachten, wenn viele Verbraucher ihre Geräte zum ersten Mal in einem relativ kurzen Zeitraum einschalten.
  • Geplante Geräteupdates, bei denen viele Geräte in einem kurzen Zeitfenster ein Update erhalten und alle Geräte ungefähr zur gleichen Zeit mit dem neuen Update neu starten.

Aufgrund des Szenarios „viele Geräte starten gleichzeitig“ können sich die Bedenken der Clouddienste sogar auf Szenarien mit einer angenommenen Netzwerkkonnektivität von nahezu 100 % auswirken, z. B. durch Drosselung (Begrenzung des für einen Dienst zulässigen Datenverkehrs).

Neben Netzwerk- und Kontingentproblemen müssen auch Azure-Dienstausfälle berücksichtigt werden. Dabei kann es sich um Dienstausfälle oder regionale Ausfälle handeln. Während einige Dienste (z. B. IoT Hub) georedundant sind, speichern andere Dienste (z. B. DPS) ihre Daten in einer einzelnen Region. Obwohl es den Anschein hat, dass die regionale Redundanz eingeschränkt wird, ist es wichtig zu beachten, dass Sie einen einzelnen IoT Hub mit mehreren DPS-Instanzen verknüpfen können.

Wenn regionale Redundanz ein Anliegen ist, verwenden Sie das Geoknotenmuster, bei dem Sie eine heterogene Gruppe von Ressourcen in verschiedenen Regionen hosten. Auf ähnliche Weise wendet ein Bereitstellungsstempel (auch als Skalierungsstempel bezeichnet) dieses Muster an, um mehrere Workloads oder Mandanten zu betreiben. Weitere Informationen finden Sie unter Muster mit Bereitstellungsstempeln.

Grundlegendes zu den Auswirkungen des Gerätestandorts. Wenn Architekten Komponenten auswählen, müssen sie auch wissen, dass die meisten Azure-Dienste regional sind, auch solche wie DPS mit globalen Endpunkten. Ausnahmen umfassen Azure Traffic Manager und Microsoft Entra ID. Daher sind die Entscheidungen, die Sie für den Gerätestandort, den Datenspeicherort und den Metadatenspeicherort (Daten zu Daten, z. B. Azure-Ressourcengruppen) treffen, wichtige Eingaben in Ihrem Design.

  • Gerätestandort. Die Anforderungen an den Gerätestandort wirken sich auf Ihre regionale Auswahl aus, da sie die Transaktionswartezeit beeinflussen.
  • Datenstandort. Der Datenstandort ist an den Gerätestandort geknüpft, der ebenfalls den Compliance-Anforderungen unterliegt. Eine Lösung, die Daten für einen Staat in den Vereinigten Staaten speichert, könnte beispielsweise eine Datenspeicherung am geografischen Standort USA erfordern. Anforderungen an die Datenlokalität können ebenfalls ausschlaggebend für diesen Bedarf sein.
  • Metadatenstandort. Obwohl der Gerätestandort in der Regel keinen Einfluss auf den Metadatenstandort hat, wirken sich Compliance- und Kostenaspekte auf den Metadatenstandort aus, da die Geräte mit den Lösungsdaten und nicht mit den Metadaten der Lösung interagieren. In vielen Fällen ist es aus Gründen der Bequemlichkeit erforderlich, dass der Metadatenstandort derselbe ist wie der Datenstandort für regionale Dienste.

Azure Cloud Adoption Framework enthält einen Leitfaden zur Entscheidungsfindung für Azure-Regionen.

Grundlegendes zu SaaS-Bedenken von unabhängigen Softwareanbietern (Independent Software Vendor, ISV). Als ISV, der SaaS anbietet, ist es wichtig, die Erwartungen der Kund*innen an Verfügbarkeit und Resilienz zu erfüllen. ISVs müssen Azure-Dienste so gestalten, dass sie hochverfügbar sind, und sie müssen die Kosten für Resilienz und Redundanz bei der Abrechnung der Kund*innen berücksichtigen.

Trennen Sie die Kosten der verkauften Waren (COGS) basierend auf der Trennung von Kundendaten für jeden Softwarekunden. Diese Unterscheidung ist wichtig, wenn Endbenutzer*innen nicht mit Kund*innen identisch ist. Bei einer Smart-TV-Plattform kann der Kunde des Plattformanbieters beispielsweise der Fernsehanbieter sein, aber die Endbenutzer*innen sind die Käufer*innen des Fernsehers. Diese Trennung, die durch das Kundenmandantenmodell von den Anforderungen gesteuert wird, erfordert separate DPS- und IoT Hub-Instanzen. Der Bereitstellungsdienst muss außerdem über eine eindeutige Kundenidentität verfügen, die durch einen eindeutigen Endpunkt oder Geräteauthentifizierungsprozess angegeben werden kann. Weitere Informationen finden Sie im Leitfaden zu IoT in einer mehrinstanzenfähigen Lösung.

Aufskalieren von Komponenten mit unterstützenden Diensten

Wenn es um die Skalierung von IoT-Lösungen geht, ist es sinnvoll, die einzelnen Dienste zu betrachten und zu sehen, wie sie miteinander zusammenhängen können. Sie können Ihre IoT-Lösung über mehrere DPS-Instanzen oder über Azure IoT Hub skalieren.

Aufskalieren über mehrere DPS-Instanzen

Bei DPS-Dienstgrenzwerten ist es häufig erforderlich, auf mehrere DPS-Instanzen zu erweitern. Es gibt mehrere Möglichkeiten, wie Sie die Gerätebereitstellung über mehrere DPS-Instanzen hinweg angehen können, die sich in zwei Hauptkategorien unterteilen lassen: Zero-Touch- und Low-Touch-Bereitstellung.

Alle folgenden Ansätze wenden das zuvor beschriebene "Stamp"-Konzept für Resilienz und für die Skalierung an. Dieser Ansatz umfasst die Bereitstellung von Azure App Service in mehreren Regionen mit einem Tool wie Azure Traffic Manager oder dem globalen Lastenausgleichs-. Der Einfachheit halber wird dies in den folgenden Diagrammen nicht dargestellt.

(1) Zero-Touch-Bereitstellung mit mehreren DPS-Instanzen: Bei der Zero-Touch-Bereitstellung (automatisierte Bereitstellung) besteht eine bewährte Strategie darin, dass das Gerät einen DPS-ID-Bereich von einer Web-API anfordert, die die Geräte auf den aufskalierten DPS-Instanzen versteht und ausgleicht. Dadurch wird die Web-App zu einem wichtigen Teil des Bereitstellungsprozesses und muss daher skalierbar und hochverfügbar sein. Es gibt drei Hauptvarianten für dieses Design.

Das folgende Diagramm veranschaulicht die erste Option: die Verwendung einer benutzerdefinierten Bereitstellungs-API, die verwaltet, wie das Gerät dem entsprechenden DPS-Pool zugeordnet wird, der wiederum (über standardmäßige DPS-Lastenausgleichsmechanismen) der entsprechenden IoT Hub-Instanz zugeordnet wird:

Diagramm, das ein Beispiel einer automatisierten Zero-Touch-Bereitstellung mit direktem DPS-Zugang zeigt

  1. Das Gerät stellt eine Anforderung an eine Bereitstellungs-API, die in Azure App Service gehostet wird, um einen DPS-ID-Bereich anzufordern. Die Bereitstellungs-API überprüft mit ihrer persistenten Datenbank, welcher Instanz das Gerät basierend auf dem vorhandenen Gerätebestand am besten zugewiesen werden kann, und gibt den DPS-ID-Bereich zurück. In diesem Fall handelt es sich bei der vorgeschlagenen Datenbank um eine Azure Cosmos DB-Instanz mit aktiviertem Multimaster-Schreibzugriff (für regionsübergreifende Hochverfügbarkeit), in der die zugewiesenen DPS jedes Geräts gespeichert werden. Sie können diese Datenbank dann zum Nachverfolgen der Auslastung der DPS-Instanzen für alle geeigneten Metriken verwenden (z. B. Bereitstellungsanforderungen pro Minute, insgesamt bereitgestellte Geräte usw.). Mit dieser Datenbank ist bei Bedarf auch eine erneute Bereitstellung mit demselben DPS-ID-Bereich möglich. Authentifizieren Sie die Bereitstellungs-API, um unangemessene Bereitstellungsanforderungen zu verhindern.
  2. Das Gerät stellt dann eine Anforderung für DPS mit dem zugewiesenen ID-Bereich. DPS gibt Details an das Gerät zurück, dem der IoT Hub zugewiesen werden soll.
  3. Das Gerät sichert den ID-Bereich und die IoT Hub-Verbindungsinformationen im persistenten Speicher, idealerweise an einem geschützten Speicherort (da der ID-Bereich Teil der Authentifizierung für die DPS-Instanz ist). Das Gerät verwendet dann diese IoT Hub-Verbindungsinformationen für weitere Anforderungen an das System.

Bei diesem Design muss die Gerätesoftware das DPS-SDK enthalten und den DPS-Registrierungsprozess verwalten, was das typische Design für ein Azure IoT-Gerät ist. Aber in einer Mikrocontrollerumgebung, in der die Größe der Gerätesoftware ein wichtiger Bestandteil des Designs ist, ist dies möglicherweise nicht akzeptabel, was zu einem anderen Design führen würde.

(2) Zero-Touch-Bereitstellung mit einer Bereitstellungs-API: Bei der zweiten Variante wird der DPS-Aufruf in die Bereitstellungs-API verlagert. In diesem Modell ist die Geräteauthentifizierung für DPS in der Bereitstellungs-API enthalten, ebenso wie der Großteil der Wiederholungslogik. Dieser Prozess ermöglicht komplexere Warteschlangenszenarien und möglicherweise einfacheren Bereitstellungscode auf dem Gerät selbst. Außerdem kann der zugewiesene IoT-Hub zwischengespeichert werden, um den Nachrichtenaustausch zwischen Cloud und Gerät zu beschleunigen. Die Nachrichten werden gesendet, ohne dass DPS nach den Informationen des zugewiesenen Hubs abgefragt werden muss:

Diagramm, das ein Beispiel einer automatisierten Zero-Touch-Bereitstellung mit isoliertem DPS-Zugang zeigt

  1. Das Gerät sendet eine Anforderung an eine Bereitstellungs-API, die in einer Instanz des Azure App Service gehostet wird. Die Bereitstellungs-API überprüft mit ihrer persistenten Datenbank, welcher Instanz das Gerät basierend auf dem vorhandenen Gerätebestand am besten zugewiesen werden kann, und gibt den DPS-ID-Bereich zurück. In diesem Fall handelt es sich bei der vorgeschlagenen Datenbank um eine Azure Cosmos DB-Instanz mit aktiviertem Multimaster-Schreibzugriff (für regionsübergreifende Hochverfügbarkeit), in der die zugewiesenen DPS jedes Geräts gespeichert werden. Sie können diese Datenbank dann zum Nachverfolgen der Nutzung der DPS-Instanzen für alle geeigneten Metriken verwenden (z. B. Bereitstellungsanforderungen pro Minute, insgesamt bereitgestellte Geräte usw.). Mit der Datenbank können Sie auch eine erneute Bereitstellungsanforderung stellen, indem Sie gegebenenfalls denselben DPS-ID-Bereich verwenden. Authentifizieren Sie die Bereitstellungs-API auf irgendeine Weise, um unangemessene Bereitstellungsanforderungen zu verhindern. Dazu können Sie wahrscheinlich dieselbe Authentifizierung verwenden, die der Bereitstellungsdienst für DPS verwendet, z. B. mit einem privaten Schlüssel für ein ausgestelltes Zertifikat. Aber auch andere Optionen sind möglich. FastTrack für Azure (FTA) hat z. B. mit einem Kunden gearbeitet, der eindeutige Hardware-IDs als Teil seines Dienstauthentifizierungsprozesses verwendet. Der Geräteherstellungspartner stellt dem Gerätehersteller regelmäßig eine Liste mit eindeutigen Bezeichnern bereit, die dieser in eine Datenbank lädt, die auf den Dienst hinter der benutzerdefinierten Bereitstellungs-API verweist.

  2. Die Bereitstellungs-API führt den DPS-Bereitstellungsprozess mit dem zugewiesenen ID-Bereich aus und fungiert effektiv als DPS-Proxy.

  3. Die DPS-Ergebnisse werden an das Gerät weitergeleitet.

  4. Das Gerät sichert die IoT Hub-Verbindungsinformationen im persistenten Speicher, idealerweise an einem geschützten Speicherort (da der ID-Bereich Teil der Authentifizierung für die DPS-Instanz ist). Das Gerät verwendet diese IoT Hub-Verbindungsinformationen für spätere Anforderungen an das System.

Bei diesem Design ist es nicht erforderlich, auf das DPS-SDK oder den DPS-Dienst zu verweisen. Außerdem ist es nicht erforderlich, einen DPS-Bereich auf dem Gerät zu speichern oder zu verwalten. Dadurch können Szenarien für die Besitzübertragung ermöglicht werden, da der Bereitstellungsdienst auf die entsprechende DPS-Instanz des Endkunden verweisen kann. Allerdings führt dies dazu, dass die Bereitstellungs-API das DPS-Konzept in gewisser Weise dupliziert, was möglicherweise nicht ideal ist.

(3) Zero-Touch-Bereitstellung mit Besitzübertragung: Ein drittes mögliches Zero-Touch-Bereitstellungsdesign besteht darin, eine werkseitig konfigurierte DPS-Instanz als Startpunkt zu verwenden und dann bei Bedarf auf andere DPS-Instanzen umzuleiten. Dieses Design ermöglicht die Bereitstellung ohne eine benutzerdefinierte Bereitstellungs-API, erfordert jedoch eine Managementanwendung, um DPS-Instanzen nachzuverfolgen und bei Bedarf umzuleiten.

Zu den Anforderungen der Managementanwendung gehört die Nachverfolgung, welcher DPS der aktive DPS für jedes bestimmte Gerät sein soll. Sie können diesen Ansatz für „Besitzübertragungsszenarien“ verwenden, bei denen der Gerätehersteller den Besitz des Geräts vom Hersteller auf den Endkunden überträgt.

  1. Das Gerät stellt eine Verbindung mit der werkseitig konfigurierten DPS-Instanz her und fordert einen ersten Bereitstellungsprozess an.
  2. Das Gerät empfängt eine Erstkonfiguration, einschließlich der gewünschten Ziel-DPS-Instanz.
  3. Das Gerät stellt eine Verbindung mit der gewünschten Ziel-DPS-Instanz her und fordert die Bereitstellung an.
  4. Das Gerät sichert dann die IoT Hub-Verbindungsinformationen im persistenten Speicher, idealerweise an einem geschützten Speicherort (da der ID-Bereich Teil der Authentifizierung für die DPS-Instanz ist). Das Gerät verwendet diese IoT Hub-Verbindungsinformationen für weitere Anforderungen an das System.

Diagramm, das ein Beispiel einer automatisierten Zero-Touch-Bereitstellung mit Besitzübertragung zeigt

(4) Low-Touch-Bereitstellung mit mehreren DPS-Instanzen In einigen Fällen, z. B. in Kundenszenarien oder bei Geräten für Bereitstellungsteams im Außeneinsatz, besteht eine häufige Wahl darin, eine benutzerunterstützte (Low-Touch-)Bereitstellung anzubieten. Beispiele für die Low-Touch-Bereitstellung sind eine mobile Anwendung auf dem Telefon eines Installateurs oder eine webbasierte Anwendung auf einem Gerätegateway. In diesem Fall besteht der bewährte Ansatz darin, dieselben Vorgänge wie beim Zero-Touch-Bereitstellungsprozess auszuführen, aber die Bereitstellungsanwendung überträgt die Details an das Gerät.

Diagramm, das ein Beispiel einer benutzerunterstützten (Low-Touch-)Bereitstellung mit direktem DPS-Zugang zeigt

  1. Der Administrator startet eine Gerätekonfigurations-App, die eine Verbindung mit dem Gerät herstellt.
  2. Die Konfigurations-App stellt eine Verbindung mit einer Bereitstellungs-API her, die in einer Instanz des Azure App Service gehostet wird, um einen DPS-ID-Bereich anzufordern. Die Bereitstellungs-API überprüft mit ihrer persistenten Datenbank, welcher Instanz das Gerät basierend auf dem vorhandenen Gerätebestand am besten zugewiesen werden kann, und gibt den DPS-ID-Bereich zurück. In diesem Fall handelt es sich bei der vorgeschlagenen Datenbank um eine Azure Cosmos DB-Instanz mit aktiviertem Multimaster-Schreibzugriff (für regionsübergreifende Hochverfügbarkeit), in der die zugewiesenen DPS jedes Geräts gespeichert werden. Diese Datenbank kann dann zum Nachverfolgen der Nutzung der DPS-Instanzen für alle geeigneten Metriken (z. B. Bereitstellungsanforderungen pro Minute und insgesamt bereitgestellte Geräte) verwendet werden. Mit dieser Datenbank ist bei Bedarf auch eine erneute Bereitstellung mit demselben DPS-ID-Bereich möglich. Die Bereitstellungs-API sollte authentifiziert werden, um zu verhindern, dass unangemessene Bereitstellungsanforderungen gewartet werden.
  3. Die App gibt den Bereich der Bereitstellungs-ID an das Gerät zurück.
  4. Das Gerät stellt dann eine Anforderung für DPS mit dem zugewiesenen ID-Bereich. DPS gibt Details an das Gerät zurück, dem der IoT Hub zugewiesen werden soll.
  5. Das Gerät sichert den ID-Bereich und die IoT Hub-Verbindungsinformationen im persistenten Speicher, idealerweise an einem geschützten Speicherort, da der ID-Bereich Teil der Authentifizierung für die DPS-Instanz ist. Das Gerät verwendet diese IoT Hub-Verbindungsinformationen für weitere Anforderungen an das System.

Es gibt weitere mögliche Varianten, die in diesem Artikel nicht näher erläutert werden. So können Sie beispielsweise die hier gezeigte Architektur konfigurieren, indem Sie den DPS-Aufruf in die Bereitstellungs-API verlagern, wie weiter oben bei der Zero-Touch-Bereitstellung mit einer Bereitstellungs-API gezeigt. Das Ziel besteht darin, sicherzustellen, dass jede Ebene skalierbar und konfigurierbar ist und problemlos bereitgestellt werden kann.

Allgemeiner Leitfaden für die DPS-Bereitstellung: Sie sollten die folgenden Empfehlungen auf Ihre DPS-Bereitstellung anwenden, die allgemeine bewährte Methoden für diesen Azure-Dienst darstellen:

Nicht bei jedem Startvorgang bereitstellen. In der DPS-Dokumentation heißt es, dass die bewährte Methode darin besteht, die Bereitstellung nicht bei jedem Startvorgang vorzunehmen. Bei kleinen Anwendungsfällen mag es sinnvoll erscheinen, die Bereitstellung bei jedem Systemstart vorzunehmen, da dies der kürzeste Weg zur Bereitstellung ist. Doch beim Hochskalieren auf Millionen von Geräten kann DPS jedoch aufgrund des festen Grenzwerts von 1,000 Registrierungen pro Minute und Dienstinstanz zu einem Engpass werden. Selbst die Statussuche der Geräteregistrierung kann einen Engpass darstellen, da es ein Limit von 5 bis 10 Abrufvorgängen pro Sekunde gibt. Bereitstellungsergebnisse sind in der Regel eine statische Zuordnung zu einem IoT Hub. Wenn Ihre Anforderungen also keine automatisierte Neubereitstellung umfassen, sollte sie nur bei Bedarf ausgeführt werden. Falls Sie mehr Datenverkehr erwarten, ist die Aufskalierung auf mehrere DPS Instanzen möglicherweise die einzige Möglichkeit, solche Szenarien zu unterstützen.

Gestaffelten Bereitstellungszeitplan verwenden. Eine Empfehlung zur Reduzierung einiger der zeitlichen Einschränkungen ist die Verwendung eines gestaffelten Zeitplans für die Bereitstellung. Je nach den Anforderungen an die Bereitstellung kann dieser Zeitplan auf einer zufälligen Verschiebung von einigen Sekunden basieren oder sich über mehrere Minuten erstrecken.

Vor einer Bereitstellungsanforderung immer den Status abfragen. Als bewährte Methode sollten Geräte immer mithilfe der API zum Ermitteln des Geräteregistrierungsstatus ihren Status abfragen, bevor sie die Bereitstellung anfordern. Dieser Anruf zählt derzeit nicht als abgerechnetes Element, und die Grenze ist unabhängig vom Registrierungsgrenzwert. Der Abfragevorgang ist im Vergleich zu einer Bereitstellungsanforderung relativ schnell, was bedeutet, dass das Gerät seinen Status überprüfen und schneller zur normalen Geräteworkload übergehen kann. Die entsprechende Geräteregistrierungslogik ist in der Dokumentation zu umfangreichen Bereitstellungen dokumentiert.

Überlegungen zur Bereitstellungs-API befolgen. Mehrere der hier vorgeschlagenen Entwürfe beinhalten eine Bereitstellungs-API. Die Bereitstellungs-API benötigt einen unterstützenden Metadatenspeicher wie Azure Cosmos DB. Auf diesen Skalierungsebenen ist es am besten, ein global verfügbares und resilientes Entwurfsmuster zu implementieren, das ein gutes Muster für diese API und den unterstützenden Datenspeicher darstellt. Die integrierten georedundanten Multimasterfunktionen und Latenzgarantien in Azure Cosmos DB machen es zu einer hervorragenden Wahl für dieses Szenario. Zu den wichtigsten Aufgaben dieser API gehören:

  • Bereitstellen des DPS-ID-Bereichs. Diese Schnittstelle kann eine GET-Anforderung sein. Denken Sie daran, dass physische Geräte oder die Verwaltungsanwendung eine Verbindung mit dieser Schnittstelle herstellen.
  • Unterstützen des Gerätelebenszyklus. Möglicherweise muss ein Gerät erneut bereitgestellt werden, oder ein anderes unerwartetes Ereignis kann auftreten. Es ist wichtig, mindestens die Geräte-ID und den zugewiesenen DPS für ein Gerät beizubehalten. Auf diese Weise können Sie ein Gerät aus dem zugewiesenen DPS herausnehmen und in einem anderen DPS neu bereitstellen. Oder, wenn der Lebenszyklus eines Geräts abgelaufen ist, können Sie es vollständig aus dem System entfernen.
  • Lastenausgleichssysteme. Durch die Verwendung der gleichen Metadaten für Geräte-ID und DPS ist es einfacher, die aktuelle Last für jedes Subsystem zu ermitteln und diese Informationen anzuwenden, um Geräte besser auf die horizontal skalierten Komponenten zu verteilen.
  • Aufrechterhalten der Systemsicherheit. Wie bereits erwähnt, sollte die Bereitstellungs-API jede Anforderung authentifizieren. Als bewährte Methode wird die Verwendung eines eindeutigen X.509-Zertifikats pro Gerät empfohlen, das sich sowohl gegenüber der Bereitstellungs-API als auch gegenüber der DPS-Instanz authentifizieren kann, sofern die Architektur dies unterstützt. Andere Methoden, wie Flottenzertifikate und Token, sind verfügbar, gelten aber als weniger sicher. Wie Sie die Implementierung konkret vornehmen und welche Auswirkungen dies auf die Sicherheit hat, hängt davon ab, ob Sie eine Zero-Touch- oder eine Low-Touch-Option wählen.

Aufskalieren von Azure IoT Hub

Im Vergleich zum Aufskalieren von DPS ist das Aufskalieren Azure IoT Hub relativ einfach. Wie bereits erwähnt, besteht einer der Vorteile von DPS darin, dass eine Instanz mit vielen IoT Hub-Instanzen verknüpft werden kann. Wenn DPS verwendet wird, wie es für alle Azure IoT-Lösungen empfohlen wird, erfordert die Aufskalierung von IoT Hub:

  1. Erstellen einer neuen Instanz des IoT Hub-Diensts
  2. Konfigurieren der neuen Instanz mit entsprechendem Routing und anderen Details
  3. Verknüpfen der neuen Instanz mit den entsprechenden DPS-Instanzen
  4. Ggf. Neukonfiguration der DPS-Zuteilungsrichtlinie oder Ihrer benutzerdefinierten Zuteilungsrichtlinie

Gestalten von Gerätesoftware

Es gibt viele bewährte Methoden und geräteseitige Überlegungen für ein skalierbares Gerätedesign. Einige davon leiten sich direkt von in der Praxis auftretenden Antimustern ab. In diesem Abschnitt werden Konzepte beschrieben, die für eine erfolgreich skalierte Bereitstellung entscheidend sind.

Schätzen der Workloads für verschiedene Teile des Gerätelebenszyklus und der Szenarien innerhalb des Lebenszyklus. Geräteregistrierungsworkloads können je nach Entwicklungsphase (Pilotphase, Entwicklung, Produktion, Außerbetriebnahme, Lebenszyklusende) stark variieren. In einigen Fällen können sie auch aufgrund externer Faktoren wie dem bereits erwähnten Blackout-Szenario variieren. Die Planung der „Worst Case“-Workload trägt dazu bei, den Erfolg im großen Stil sicherzustellen.

Unterstützung der erneuten Bereitstellung bei Bedarf. Sie können diese Funktion über einen Gerätebefehl und eine Administratoranforderung anbieten, die in der Produktdokumentation erwähnt wird. Mit dieser Option können Sie Besitzerszenarien und Werkseinstellungsszenarien übertragen.

Keine erneute Bereitstellung, wenn nicht nötig. Es ist ungewöhnlich, dass ein aktives, funktionierendes Gerät im Feld eine erneute Bereitstellung benötigt, da die Bereitstellungsinformationen relativ statisch sind. Nehmen Sie keine erneute Bereitstellung ohne triftigen Grund vor.

Überprüfen des Bereitstellungsstatus, wenn Sie die Bereitstellung häufig wiederholen müssen, z. B. bei jedem Start des Geräts. Wenn der Gerätebereitstellungsstatus zweifelhaft ist, fragen Sie zunächst den Bereitstellungsstatus ab. Der Abfragevorgang wird für ein anderes Kontingent als ein Bereitstellungsvorgang durchgeführt und ist schneller als ein Bereitstellungsvorgang. Diese Abfrage ermöglicht es dem Gerät, den Status der Bereitstellung zu überprüfen, bevor es fortfährt. Dies kann z. B. der Fall sein, wenn ein Gerät nicht über einen persistenten Speicher verfügt, um die Bereitstellungsergebnisse zu speichern.

Sicherstellen einer guten Wiederholungslogikstrategie. Das Gerät muss über geeignete Wiederholungsalgorithmen verfügen, die sowohl für die Erstbereitstellung als auch für die spätere Wiederbereitstellung in den Gerätecode integriert sind, z. B. das bereits erwähnte „exponentielle Backoff mit Randomisierung“. Diese Szenarien können für die beiden Anwendungsfälle unterschiedlich sein. Je nach Anwendungsfall muss die anfängliche Bereitstellung im Wiederholungsprozess möglicherweise aggressiver sein als die erneute Bereitstellung. Bei einer Drosselung gibt DPS wie die meisten Azure-Dienste einen HTTP-Fehlercode 429 („Zu viele Anforderungen“) zurück. Das Azure Architecture Center enthält Anleitungen zu Wiederholungsversuchen und, was noch wichtiger ist, zu Antimustern, die in Bezug auf Wiederholungsszenarienvermieden werden sollten. In der DPS-Dokumentation finden Sie außerdem Informationen darüber, was der Dienst für ein Wiederholungsintervall empfiehlt und wie Sie einen angemessenen Jitter als Teil des Skalierungsleitfadens berechnen können. Die Stabilität des Gerätestandorts und der Konnektivitätszugriff beeinflussen auch die entsprechende Wiederholungsstrategie. Wenn beispielsweise bekannt ist, dass ein Gerät für eine gewisse Zeit offline ist, und das Gerät dies erkennen kann, ist es sinnlos, Onlinevorgänge zu wiederholen, während das Gerät offline ist.

Unterstützen von OTA-Updates (Over-the-Air). Zwei einfache Updatemodelle sind die Verwendung von Gerätezwillungseigenschaften mit automatischer Geräteverwaltung und die Verwendung einfacher Gerätebefehle. Für anspruchsvollere Updateszenarien und Berichte sehen Sie sich die Vorschauversion des Azure Device Update-Diensts an. OTA-Updates ermöglichen das Beheben von Fehlern im Gerätecode und bei Bedarf eine grundlegende Neukonfiguration von Diensten (z. B. DPS-ID-Bereich).

Architektur für Zertifikatänderungen auf allen Ebenen und allen Zertifikatsverwendungen. Diese Empfehlung ist an die bewährte Methode für das OTA-Update gebunden. Sie müssen eine Zertifikatsrotation in Betracht ziehen. Die IoT Hub DPS-Dokumentation befasst sich mit diesem Szenario aus Sicht der Geräteidentitätszertifikate. Es ist jedoch wichtig, im Rahmen einer Gerätelösung daran zu denken, dass andere Zertifikate verwendet werden, z. B. für IoT Hub-Zugriff, App Service-Zugriff und Zugriff auf Azure Storage-Konten. Die Änderung des Stammzertifikats auf der Azure-Plattform zeigt, dass Sie mit Änderungen auf allen Ebenen rechnen müssen. Seien Sie außerdem vorsichtig beim Anheften von Zertifikaten, insbesondere wenn die Zertifikate außerhalb der Kontrolle des Geräteherstellers liegen.

Berücksichtigen eines vernünftigen Standardzustands. Um anfängliche Bereitstellungsfehler zu beheben, verwenden Sie entsprechend den Umständen eine angemessene getrennte oder nicht bereitgestellte Konfiguration. Wenn das Gerät im Rahmen der anfänglichen Bereitstellung über eine starke Interaktionskomponente verfügt, kann der Bereitstellungsprozess im Hintergrund erfolgen, während der Benutzer andere Bereitstellungsaufgaben ausführt. In jedem Fall ist bei der Verwendung eines Standardwerts die Verwendung eines geeigneten Wiederholungsmusters und die ordnungsgemäße Verwendung des Architekturmusters des Trennschalters impliziert.

Eventuelles Einschließen der Endpunktkonfigurationsfunktionen. Lassen Sie die Konfiguration des DPS-ID-Bereichs, des DPS-Endpunkts oder des benutzerdefinierten Bereitstellungsdienstendpunkts zu. Es wird nicht erwartet, dass sich der DPS-Endpunkt ändert, aber da Sie ihn auf dem Gerät ändern können, haben Sie eine größere Flexibilität. Denken Sie zum Beispiel an die automatische Validierung des Gerätebereitstellungsprozesses durch Integrationstests ohne direkten Azure-Zugriff. Oder denken Sie an die Möglichkeit künftiger Bereitstellungsszenarien, die es heute noch nicht gibt, z. B. über einen Bereitstellungsproxydienst.

Verwenden der Azure IoT SDKs für die Bereitstellung. Unabhängig davon, ob sich die DPS-Aufrufe auf dem Gerät selbst oder in einer benutzerdefinierten Bereitstellungs-API befinden, bedeutet die Verwendung des Azure IoT SDK, dass Sie einige bewährte Methoden in der Implementierung „gratis“ erhalten. Darüber hinaus ermöglicht es bessere Supportfunktionen. Da die SDKs alle als Open Source veröffentlicht werden, ist es möglich, ihre Funktionsweise zu überprüfen und Änderungen vorzuschlagen. Welches SDK Sie auswählen, hängt in erster Linie davon ab, welche Gerätehardware Sie wählen und welche Runtime(s) auf dem Gerät verfügbar sind.

Bereitstellen von Geräten

Die Gerätebereitstellung ist ein wichtiger Teil des Lebenszyklus eines Geräts, liegt aber außerhalb des Rahmens dieses Artikels, da sie vom jeweiligen Anwendungsfall abhängt. Die bereits erwähnten Diskussionspunkte rund um „Besitzübertragung“ könnten für die Bereitstellung und die Muster gelten, die eine Bereitstellungsanwendung (z. B. eine mobile Anwendung) beinhalten, aber Sie wählen sie je nach verwendetem IoT-Gerätetyp aus.

Überwachen von Geräten

Ein wichtiger Bestandteil der gesamten Bereitstellung ist die Überwachung der Lösung von Anfang bis Ende, um sicherzustellen, dass das System entsprechend ausgeführt wird. Da sich dieser Artikel explizit auf Architektur und Design und nicht auf die operativen Aspekte der Lösung konzentriert, liegt die ausführliche Erläuterung der Überwachung außerhalb des Bereichs. Allerdings sind in Azure über Azure Monitor Überwachungstools integriert, die sicherstellen, dass die Lösung nicht an ihre Grenzen stößt. Ausführliche Informationen finden Sie in den Artikeln zu folgenden Themen:

Sie können diese Tools einzeln oder als Teil einer komplexeren SIEM-Lösung (Security Information and Event Management) wie Microsoft Sentinelverwenden.

Die Dokumentation enthält die folgenden Überwachungsmuster zur Überwachung der Nutzung von DPS im Laufe der Zeit:

  • Erstellen Sie eine Anwendung, um jede Registrierungsgruppe in einer DPS-Instanz abzufragen, rufen Sie die gesamten für diese Gruppe registrierten Geräte ab, und aggregieren Sie dann die Zahlen aus verschiedenen Registrierungsgruppen. Diese Zahl entspricht der genauen Anzahl der Geräte, die derzeit über DPS registriert sind und verwendet werden können, um den Status des Diensts zu überwachen.
  • Überwachen Sie Geräteregistrierungen über einen bestimmten Zeitraum. Überwachen Sie beispielsweise die Registrierungsraten für eine DPS-Instanz in den vorherigen fünf Tagen. Dieser Ansatz liefert nur ein annäherndes Bild und ist auf einen Zeitraum begrenzt.

Schlussbemerkung

Das Hochskalieren einer IoT-Lösung zur Unterstützung von Millionen oder sogar zehn oder hundert Millionen von Geräten ist keine einfache Aufgabe. Es müssen viele Faktoren berücksichtigt werden und es gibt verschiedene Möglichkeiten, die Probleme zu lösen, die bei diesen Größenordnungen auftreten können. Dieser Artikel fasst die Probleme zusammen und liefert Ansätze, wie Sie diese Probleme bei einer erfolgreichen Bereitstellung angehen können.

Beitragende

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

Hauptautor:

Andere Mitwirkende:

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

Nächste Schritte