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

In diesem Artikel wird beschrieben, wie Sie eine IoT-Lösung (Internet of Things) mithilfe eines Skalierungsmusters auf der Azure IoT Hub-Plattform skalieren. Das Scale-out-Muster behebt Skalierungsprobleme, indem Instanzen zu einer Bereitstellung hinzugefügt werden, statt die Instanzgröße zu erhöhen. Dieser Implementierungsleitfaden zeigt Ihnen, wie Sie eine IoT-Lösung skalieren, die Millionen von Geräten unterstützt und Azure-Dienst- und Abonnementbeschränkungen berücksichtigt. Der Artikel beschreibt Low-Touch- und Zero-Touch-Bereitstellungsmodelle der Staffelung, die Sie je nach Bedarf einsetzen können.

Weitere Informationen finden Sie in den folgenden Artikeln:

Hinweis

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

Anforderungen erfassen

Sammeln Sie Anforderungen, bevor Sie eine neue IoT-Lösung implementieren. Mit diesem Schritt wird sichergestellt, dass die Implementierung Ihre Geschäftsziele erfüllt. Ihre geschäftlichen Ziele und Ihre Betriebsumgebung sollten Ihre Anforderungen bestimmen. Sammeln Sie mindestens die folgenden Anforderungen:

Identifizieren Sie die Gerätetypen, die Sie bereitstellen möchten. IoT umfasst eine breite Palette von Lösungen, von einfachen Mikrocontrollereinheiten (MCUs) bis hin zu Mid-Level-System-on-Chip (SoC) und Mikroprozessoreinheiten (MPUs) bis hin zu vollständigen DESIGNS auf PC-Ebene. Geräteseitige Softwarefunktionen beeinflussen das Lösungsdesign direkt.

Ermitteln Sie die Anzahl der Geräte, die Sie bereitstellen müssen. Einige Grundprinzipien der Implementierung von IoT-Lösungen gelten in allen Größenordnungen. Verstehen Sie den Maßstab, um eine Übertechnisierung einer Lösung zu vermeiden. Eine Lösung für 1.000 Geräte weist grundlegende Unterschiede im Vergleich zu einer Lösung für 1 Millionen Geräte auf. Eine PoC-Lösung (Proof-of-Concept) für 10.000 Geräte wird möglicherweise nicht entsprechend auf 10 Millionen Geräte skaliert, wenn Sie die Zielskala nicht am Anfang des Lösungsdesigns berücksichtigen.

Ermitteln Sie, wie viele Geräte Sie bereitstellen müssen, damit Sie den richtigen Azure IoT-Dienst auswählen können. Die Skalierung für IoT Hub und IoT Hub DPS unterscheidet sich. Eine einzelne DPS-Instanz kann standardmäßig an mehrere IoT Hub-Instanzen weitergeleitet werden. Berücksichtigen Sie also den Maßstab der einzelnen Dienste in Bezug auf die Anzahl der Geräte. Grenzen existieren jedoch nicht isoliert. Wenn ein Dienst eine Einschränkung aufweist, gilt dies wahrscheinlich auch für andere Dienste. Behandeln Sie Dienstgrenzwerte als unterschiedliche, aber verwandte Kontingente.

Dokumentieren Sie die erwarteten Gerätestandorte. Schließen Sie physischen Standort, Energieverfügbarkeit und Internetverbindung ein. Eine Lösung, die Sie in einer einzelnen Geografie bereitstellen, z. B. nur in Nordamerika, ist anders gestaltet als bei einer globalen Lösung. Ebenso unterscheidet sich eine industrielle IoT-Lösung, die in Fabriken mit Vollzeitleistung eingesetzt wird, von einer Flottenmanagementlösung, die in Kraftfahrzeugen mit variabler Leistung und Standort eingesetzt wird. Das Kommunikationsprotokoll und die verfügbare Bandbreite , ob zu einem Gateway oder direkt zu einem Clouddienst, wirken sich auf die Entwurfsskalierbarkeit auf jeder Ebene aus. Berücksichtigen Sie auch die Konnektivitätsverfügbarkeit. Ermitteln Sie, ob Geräte über längere Zeiträume mit Azure verbunden bleiben oder in einem getrennten Modus ausgeführt werden.

Untersuchen sie die Datenlokalitätsanforderungen. Rechtliche, Compliance- oder Kundenanforderungen können einschränken, wo Sie Daten (z. B. Telemetrie) oder Metadaten (z. B. Geräteinformationen) für die Lösung speichern können. Diese Einschränkungen beeinflussen den geografischen Entwurf der Lösung erheblich.

Ermitteln sie die Anforderungen für den Datenaustausch. Eine Lösung, die grundlegende Telemetriedaten wie die aktuelle Temperatur einmal pro Stunde sendet, unterscheidet sich von einer Lösung, die einmal alle 10 Minuten 10 MB Beispieldateien hochlädt. Eine unidirektionale D2C-Lösung (Device-to-Cloud) unterscheidet sich von einer bidirektionalen D2C- und Cloud-to-Device-Lösung (C2D). Auch die Einschränkungen der Produktskalierbarkeit behandeln Nachrichtengröße und Nachrichtenmenge als unterschiedliche Dimensionen.

Dokument erwartet hohe Verfügbarkeits- und Notfallwiederherstellungsanforderungen. Wie jede Produktionslösung umfassen vollständige IoT-Lösungsdesigns verfügbarkeits- oder uptime-Anforderungen. Das Design muss sowohl geplante Wartungsszenarien als auch ungeplante Ausfallzeiten abdecken, einschließlich Benutzerfehlern, Umgebungsfaktoren und Lösungsfehlern. Das Design muss außerdem ein dokumentiertes Wiederherstellungspunktziel (RPO) und ein Wiederherstellungszeitziel (Recovery Time Objective, RTO) aufweisen, wenn ein Notfall auftritt, z. B. einen dauerhaften Verlust der Region oder böswillige Akteure. Dieser Artikel konzentriert sich auf die Geräteskala, sodass er nur begrenzte Informationen zu Problemen mit hoher Verfügbarkeit und Notfallwiederherstellung enthält.

Entscheiden Sie sich für ein Kundenmietmodell, falls erforderlich. In einer mehrinstanzenfähigen Softwareentwicklungs-Unternehmenslösung, bei der der Lösungsentwickler eine Lösung für externe Kunden erstellt, muss das Design definieren, wie Kundendaten getrennt und verwaltet werden. Weitere Informationen finden Sie unter Mandantenmodelle und den zugehörigen IoT-spezifischen Leitfaden.

Grundlegendes zu Azure IoT-Konzepten

Wenn Sie eine Lösung erstellen, wählen Sie die entsprechenden Azure IoT-Komponenten und andere unterstützende Azure-Dienste aus. Die Architektur Ihrer Lösung erfordert erhebliche Anstrengungen. Die ordnungsgemäße Verwendung der IoT Hub- und IoT Hub DPS-Dienste kann Ihnen helfen, Ihre Lösungen auf Millionen von Geräten zu skalieren.

IoT Hub

IoT Hub ist ein in der Cloud gehosteter verwalteter Dienst, der als zentraler Nachrichtenhub für die Kommunikation zwischen einer IoT-Anwendung und den angeschlossenen Geräten fungiert. Sie können IoT Hub allein oder mit IoT Hub DPS verwenden.

IoT Hub skaliert basierend auf der gewünschten Funktionalität und der Anzahl der Nachrichten oder des Datenvolumens pro Tag. Verwenden Sie die folgenden drei Eingaben, um zu bestimmen, wie eine Instanz skaliert wird:

Die kostenlosen, grundlegenden und Standardebenen bestimmen die verfügbaren Funktionen. 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 Nachrichten- und Datendurchsatzbasiseinheit für D2C-Nachrichten für IoT Hub. Die maximale Größe für eine Instanz von IoT Hub beträgt Größe 3, die 300 Millionen Nachrichten pro Tag und 1.114,4 GB 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 Kapazität 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 basierend auf der Größe und Einheitenanzahl und den allgemeinen Funktionalitätsgrenzwerten auf der Ebene erzwingt IoT Hub pro Sekunde Grenzwerte für den Durchsatz. Jede IoT Hub-Instanz unterstützt auch bis zu 1 Millionen Geräte als harte Grenze. Ihre Anforderungen an den Datenaustausch helfen beim Definieren der geeigneten Konfiguration. Weitere Informationen finden Sie unter "Weitere Grenzwerte".

Ihre Lösungsanforderungen fördern die erforderliche Größe und Anzahl von IoT Hub-Instanzen als Ausgangspunkt. Wenn Sie IoT Hub DPS verwenden, unterstützt Azure Sie bei der Verteilung Ihrer Workloads auf mehrere IoT Hub Instanzen.

IoT Hub DPS

IoT Hub DPS ist ein Hilfsdienst für IoT Hub, der Zero-Touch- und Just-in-Time-Bereitstellung auf dem richtigen IoT-Hub ermöglicht, ohne dass ein menschliches Eingreifen erforderlich ist. Jedes Azure-Abonnement unterstützt maximal 10 DPS-Instanzen. Jede Dienstinstanz unterstützt maximal 1 Millionen Registrierungen. Beachten Sie Dienstbeschränkungen bei der Gestaltung Ihrer Workloads, um zukünftige Probleme zu vermeiden.

DPS-Instanzen befinden sich in bestimmten geografischen Regionen, verfügen jedoch standardmäßig über einen globalen öffentlichen Endpunkt . Der Zugriff auf bestimmte Instanzen erfolgt über einen ID-Gültigkeitsbereich. Da sich Instanzen in bestimmten Regionen befinden und jede Instanz über einen eigenen ID-Bereich verfügt, sollten Sie den ID-Bereich für Ihre Geräte konfigurieren können.

Verständnis von geteilten Resilienzkonzepten

Sie müssen gemeinsame Resilienzkonzepte berücksichtigen, z. B. vorübergehende Fehlerbehandlung, Auswirkungen auf den Standort des Geräts und für Softwareunternehmen, Software as a Service (SaaS)-Datenresilienz.

Grundlegendes zur Behandlung vorübergehender Fehler. Jede verteilte Produktionslösung, unabhängig davon, ob sie lokal oder in der Cloud vorhanden ist, muss in der Lage sein, aus vorübergehenden oder temporären Fehlern wiederherzustellen. Vorübergehende Fehler können aufgrund der folgenden Faktoren häufiger in einer Cloudlösung auftreten:

Abhängigkeit von einem externen Anbieter
Abhängigkeit von der Netzwerkkonnektivität zwischen Dem Gerät und Clouddiensten
Implementierungsgrenzwerte von Clouddiensten

Die vorübergehende Fehlerbehandlung erfordert, dass Sie über eine Wiederholungsfunktion verfügen, die in Ihren Gerätecode integriert ist. Es gibt mehrere Wiederholungsstrategien, einschließlich exponentieller Backoff mit Randomisierung, auch als exponentieller Backoff mit Jitter bezeichnet. Weitere Informationen finden Sie unter Vorübergehende Fehlerbehandlung.

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

Die Energiequelle eines Geräts: Batteriebetriebene Geräte oder Geräte, die von vorübergehenden Quellen wie Solar oder Wind betrieben werden, weisen möglicherweise weniger Netzwerkkonnektivität auf als vollzeitbetriebene Geräte.
Der Bereitstellungsort eines Geräts: Geräte in städtischen Fabrikumgebungen haben tendenziell eine bessere Netzwerkkonnektivität als Geräte in isolierten Feldumgebungen.
Die Positionsstabilität eines Geräts: Mobile Geräte haben wahrscheinlich weniger Netzwerkkonnektivität als Geräte mit fester Position.

Diese Bedenken beeinflussen auch den Zeitpunkt der Verfügbarkeit und Konnektivität von Geräten. Beispielsweise könnten leitungsbetriebene Geräte in dichten, städtischen Umgebungen, wie intelligenten Lautsprechern, in großen Gruppen getrennt und wieder verbunden werden. Betrachten Sie die folgenden Szenarien:

Ein Blackout kann dazu führen, dass 1 Millionen Geräte gleichzeitig offline gehen und aufgrund eines Stromausfalls und einer erneuten Verbindung wieder online sind. Dieses Szenario gilt sowohl für Verbraucherszenarien wie intelligente Lautsprecher als auch für Geschäfts- und Industrie-IoT-Szenarien, z. B. verbundene, strombetriebene Thermometer, die einem Immobilienmanagementunternehmen gemeldet werden.
Während eines kurzen Zeitrahmens, eines großen Onboardingereignisses wie Black Friday oder Weihnachten, schalten viele Verbraucher erstmals in relativ kurzer Zeit Geräte ein.
Viele Geräte erhalten geplante Updates in einem kurzen Zeitfenster, und alle Geräte starten mit dem neuen Update gleichzeitig neu.

Diese vielen Geräte, die gleichzeitig gestartet werden , können die Drosselung des Clouddiensts auch bei nahezu konstanter Netzwerkkonnektivität auslösen.

Über Netzwerk- und Kontingentprobleme hinaus sollten Sie auch Azure-Dienstausfälle in Betracht ziehen. Diese Ausfälle können sich auf einzelne Dienste oder ganze Regionen auswirken. Einige Dienste, z. B. IoT Hub, unterstützen Georedundanz. Andere Dienste, z. B. IoT Hub DPS, speichern ihre Daten in einer einzelnen Region. Sie können einen IoT-Hub mit mehreren DPS-Instanzen verknüpfen, wodurch regionale Risiken verringert werden.

Wenn regionale Redundanz ein Problem darstellt, verwenden Sie das Geode-Muster. Dieses Muster hostet unabhängige, gruppierte Ressourcen in verschiedenen Regionen. Ähnlich verhält es sich mit einem Bereitstellungsstempel, auch bekannt als Staffelung Stempel, dieses Muster wird für den Betrieb mehrerer Workloads oder Tenants verwendet. Weitere Informationen finden Sie unter Muster mit Bereitstellungsstempeln.

Auswirkungen des Gerätestandorts verstehen. Die meisten Azure-Dienste sind regional, sogar DPS mit globalen Endpunkten. Ausnahmen sind Azure Traffic Manager und Microsoft Entra ID. Ihre Entscheidungen über Gerätespeicherort, Datenspeicherort und Metadatenspeicherort (z. B. Azure-Ressourcengruppen) spielen eine wichtige Rolle in Ihrem Design.

Standort des Geräts: Gerätestandortanforderungen beeinflussen Ihre regionale Auswahl, da sie sich auf die Transaktionslatenz auswirken.
Datenspeicherort: Der Datenspeicherort ist an den Gerätespeicherort gebunden, der Compliance-Bedenken unterliegt. Eine Lösung, in der Daten für einen Bundesstaat in den USA gespeichert werden, kann beispielsweise eine Datenspeicherung in der GEOGRAFIE der USA erfordern. Anforderungen an die Datenlokalität können ebenfalls ausschlaggebend für diesen Bedarf sein.
Speicherort der Metadaten: Obwohl sich der Standort des Geräts in der Regel nicht auf den Metadatenspeicherort auswirkt, da Geräte mit Lösungsdaten interagieren und keine Lösungsmetadaten verwenden, wirken sich Compliance- und Kostenbedenken auf den Speicherort von Metadaten aus. In vielen Fällen ist es aus Gründen der Bequemlichkeit erforderlich, dass der Metadatenstandort derselbe ist wie der Datenstandort für regionale Dienste.

Das Azure Cloud Adoption Framework enthält Anleitungen zur regionalen Auswahl.

Einblick in die SaaS-Anliegen eines Softwareunternehmens. Softwareunternehmen, die SaaS-Lösungen anbieten, sollten die Erwartungen der Kunden an Verfügbarkeit und Ausfallsicherheit erfüllen. Softwareunternehmen müssen Azure-Dienste so entwerfen, dass sie hoch verfügbar sind, und die Kosten für Resilienz und Redundanz bei der Abrechnung des Kunden berücksichtigen.

Trennen Sie die Kosten der verkauften Waren basierend auf der Kundendatentrennung für jeden Softwarekunden. Diese Unterscheidung ist wichtig, wenn der Benutzer nicht derselbe wie der Kunde ist. Bei einer Smart-TV-Plattform kann der Kunde des Plattformanbieters beispielsweise der Fernsehanbieter sein, aber der Benutzer ist der Käufer des Fernsehgeräts. Diese Trennung, die durch das Kunden-Mandantenmodell und dessen Anforderungen gesteuert wird, erfordert getrennte Instanzen von DPS und IoT Hub. Der Bereitstellungsdienst muss auch über eine eindeutige Kundenidentität verfügen, die Sie über einen eindeutigen Endpunkt oder geräteauthentifizierungsprozess definieren können. Weitere Informationen finden Sie im Leitfaden für mehrinstanzenfähiges IoT.

Skalieren von Komponenten und deren unterstützenden Diensten

Wenn Sie IoT-Lösungen skalieren, bewerten Sie jeden Dienst und wie sie interreiliert werden. Sie können Ihre IoT-Lösung auf mehrere DPS-Instanzen oder mithilfe von IoT Hub skalieren.

Über mehrere DPS-Instanzen skalieren

Aufgrund von DPS-Dienstgrenzwerten ist es oft erforderlich, auf mehrere DPS-Instanzen zu erweitern. Sie können die Bereitstellung von Geräten über mehrere DPS-Instanzen hinweg entweder durch Zero-Touch-Provisioning oder Low-Touch-Provisioning angehen.

Die folgenden Ansätze wenden das zuvor beschriebene Stempelkonzept für Resilienz und Skalierung an. Dieses Konzept umfasst die Bereitstellung von Azure App Service in mehreren Regionen und die Verwendung eines Tools wie Traffic Manager oder eines globalen Lastenausgleichs. Aus Gründen der Einfachheit zeigen die folgenden Diagramme diese Komponenten nicht an.

Ansatz 1: Zero-Touch-Bereitstellung mit mehreren DPS-Instanzen

Für eine Zero-Touch- oder automatisierte Bereitstellung ist es eine bewährte Strategie, das Gerät einen DPS-ID-Reservierungsumfang von einer Web-API anfordern zu lassen. Die API versteht die Geräte und gleicht sie über die horizontal gestaffelten DPS-Instanzen gleichmäßig aus. Dadurch wird die Web-App zu einem wichtigen Teil des Bereitstellungsprozesses und muss daher skalierbar und hochverfügbar sein. Dieses Design hat drei Hauptvariationen.

Das folgende Diagramm zeigt die erste Option, die eine benutzerdefinierte Bereitstellungs-API verwendet, die verwaltet, wie das Gerät dem entsprechenden DPS-Pool zugeordnet wird. Jede DPS-Instanz ordnet das Gerät dann dem entsprechenden IoT Hub mithilfe standardmäßiger DPS-Lastenausgleichsmechanismen zu.

Das Gerät sendet eine Anforderung an eine in App Service gehostete Bereitstellungs-API, um einen DPS-ID-Bereich anzufordern. Die Bereitstellungs-API führt eine Überprüfung mit ihrer persistenten Datenbank durch, um die optimal geeignete Instanz für das Gerät zu identifizieren, basierend auf dem bestehenden Gerätebestand, und gibt den Umfang der DPS-ID zurück.

In diesem Beispiel handelt es sich bei der Datenbank um eine Azure Cosmos DB-Instanz, bei der der Multi-Primary-Schreibzugriff für regionsübergreifende hohe Verfügbarkeit aktiviert ist. Diese Datenbank speichert die zugewiesenen DPS jedes Geräts. Es unterstützt die Nachverfolgung der DPS-Instanznutzung für alle geeigneten Metriken, z. B. Bereitstellungsanforderungen pro Minute und gesamt bereitgestellte Geräte. Diese Datenbank ermöglicht bei Bedarf auch die erneute Bereitstellung mit demselben DPS-ID-Reservierungsumfang. Authentifizieren Sie die Bereitstellungs-API, um unangemessene Bereitstellungsanforderungen zu verhindern.
Das Gerät stellt eine Anforderung an DPS, indem es den zugewiesenen Reservierungsumfang verwendet. DPS antwortet mit IoT-Hub-Zuordnungsdetails.
Das Gerät speichert die ID-Bereichs- und IoT-Hubverbindungsinformationen im beständigen Speicher, idealerweise an einem gesicherten 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 Gerätesoftwaregröße eine wichtige Komponente des Designs ist, ist sie möglicherweise nicht akzeptabel und erfordert möglicherweise ein alternatives Design.

Ansatz 2: Zero-Touch-Bereitstellung mit einer Bereitstellungs-API

Der zweite Entwurf verschiebt den DPS-Aufruf an die Bereitstellungs-API. 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. Es ermöglicht auch das Zwischenspeichern des zugewiesenen IoT-Hubs, um schnellere C2D-Nachrichten zu erleichtern. Die Nachrichten werden gesendet, ohne dass Sie DPS nach den zugewiesenen Hub-Informationen abfragen müssen.

Das Gerät sendet eine Anforderung an eine Bereitstellungs-API, die in einer Instanz von App Service gehostet wird. Die Bereitstellungs-API überprüft mit ihrer persistenten Datenbank, um die beste Instanz für das Gerät basierend auf vorhandenem Gerätebestand zu ermitteln, und bestimmt dann den DPS-ID-Bereich.

In diesem Beispiel handelt es sich bei der Datenbank um eine Azure Cosmos DB-Instanz, bei der der Multi-Primary-Schreibzugriff für regionsübergreifende hohe Verfügbarkeit aktiviert ist. Diese Datenbank speichert die zugewiesenen DPS jedes Geräts. Es unterstützt die Nachverfolgung der DPS-Instanznutzung für alle geeigneten Metriken. Die Datenbank ermöglicht bei Bedarf auch die erneute Bereitstellung unter Verwendung desselben DPS-ID-Reservierungsumfangs.

Authentifizieren Sie die Bereitstellungs-API, um unangemessene Bereitstellungsanforderungen zu verhindern. Sie können wahrscheinlich dieselbe Authentifizierung verwenden, die der Bereitstellungsdienst für DPS verwendet, z. B. einen privaten Schlüssel für ein ausgestelltes Zertifikat. Es sind jedoch andere Optionen vorhanden. FastTrack für Azure kann z. B. mit einem Kunden arbeiten, 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.
Die Bereitstellungs-API führt den DPS-Bereitstellungsprozess mithilfe des zugewiesenen ID-Bereichs durch, der effektiv als DPS-Proxy fungiert.
Die API leitet die DPS-Ergebnisse an das Gerät weiter.
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. Dieses Modell unterstützt Übernahmeszenarien, da der Bereitstellungsdienst direkt zur entsprechenden DPS-Instanz des Kunden führen kann. Dieser Ansatz bewirkt jedoch, dass die Bereitstellungs-API einige DPS-Funktionen dupliziert, was möglicherweise nicht allen Szenarien entspricht.

Ansatz 3: Zero-Touch-Bereitstellung mit Eigentumsübertragung

Ein drittes Zero-Touch-Bereitstellungsdesign verwendet eine werksseitig konfigurierte DPS-Instanz als Ausgangspunkt und leitet bei Bedarf Geräte an andere DPS-Instanzen weiter. Dieser Entwurf ermöglicht die Bereitstellung ohne benutzerdefinierte Bereitstellungs-API, erfordert jedoch eine Verwaltungsanwendung, um DPS-Instanzen und die Umleitung nach Bedarf nachzuverfolgen.

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 Übernahmeszenarien verwenden, bei denen der Geräteanbieter den Besitz des Geräts vom Anbieter an den Endbenutzer überträgt.

Das Gerät stellt eine Verbindung mit der werkseitig konfigurierten DPS-Instanz her und fordert einen ersten Bereitstellungsprozess an.
Das Gerät empfängt eine Erstkonfiguration, einschließlich der gewünschten Ziel-DPS-Instanz.
Das Gerät stellt eine Verbindung mit der gewünschten Ziel-DPS-Instanz her und fordert die Bereitstellung an.
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 weitere Anforderungen an das System.

Ansatz 4: Low-Touch-Bereitstellung mit mehreren DPS-Instanzen

In einigen Fällen, z. B. in Szenarien mit Kundenkontakt oder bei der Bereitstellung von Geräten durch Mannschaften vor Ort, besteht eine gängige Entscheidung darin, eine benutzerfreundliche oder benutzerunterstützte Bereitstellung anzubieten. Beispiele für die Low-Touch-Bereitstellung sind eine mobile Anwendung auf dem Smartphone eines Installers oder eine webbasierte Anwendung auf einem Gerätegateway. Bei diesem Ansatz werden dieselben Vorgänge ausgeführt wie der Zero-Touch-Bereitstellungsprozess, aber die Bereitstellungsanwendung überträgt die Details an das Gerät.

Der Administrator startet eine Gerätekonfigurations-App, die eine Verbindung mit dem Gerät herstellt.
Die Konfigurations-App stellt eine Verbindung zu einer Bereitstellungs-API her, die in einer Instanz von App Service gehostet wird, um einen DPS-ID-Umfang anzufordern. Die Bereitstellungs-API überprüft die persistente Datenbank, um die beste Instanz für das Gerät zu ermitteln, basierend auf vorhandenem Gerätebestand und gibt den DPS-ID-Bereich zurück.

In diesem Beispiel handelt es sich bei der Datenbank um eine Azure Cosmos DB-Instanz, bei der der Multi-Primary-Schreibzugriff für regionsübergreifende hohe Verfügbarkeit aktiviert ist. Diese Datenbank speichert die zugewiesenen DPS jedes Geräts. Es unterstützt die Nachverfolgung der Verwendung der DPS-Instanzen für alle geeigneten Metriken. Diese Datenbank ermöglicht auch die Wiederbereitstellung, indem nach Bedarf derselbe DPS-ID-Bereich verwendet wird. Authentifizieren Sie die Bereitstellungs-API, um zu verhindern, dass unangemessene Bereitstellungsanforderungen gewartet werden.
Die App gibt den Bereich der Bereitstellungs-ID an das Gerät zurück.
Das Gerät stellt dann eine Anforderung für DPS mit dem zugewiesenen ID-Bereich. DPS gibt Details zur IoT-Hub-Zuweisung an das Gerät zurück.
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.

In diesem Artikel werden keine anderen Variationen behandelt. Sie können diesen Ansatz beispielsweise konfigurieren, indem Sie den DPS-Aufruf an die Bereitstellungs-API verschieben, wie weiter oben in der Zero-Touch-Bereitstellung mit einer Bereitstellungs-API gezeigt. Ziel ist es, sicherzustellen, dass jede Ebene skalierbar, konfigurierbar und leicht bereitzustellen ist.

Allgemeine Richtlinien für die DPS-Bereitstellung

Wenden Sie die folgenden Empfehlungen auf Ihre DPS-Bereitstellung an:

Nicht bei jedem Startvorgang bereitstellen. Die DPS-Dokumentation empfiehlt, dass Sie die Bereitstellung nicht bei jedem Starten vornehmen. In kleinen Fällen kann es sinnvoll sein, die Bereitstellung bei jedem Starten vorzunehmen, da dies der kürzeste Weg zur Bereitstellung ist. Wenn Sie jedoch bis zu Millionen von Geräten skalieren, kann DPS aufgrund seiner harten Grenze von 1.000 Registrierungen pro Minute, pro Dienstinstanz zu einem Engpass werden. Selbst Abfragen des Geräteregistrierungsstatus können zu einem Engpass werden, da sie einen Grenzwert von 5 bis 10 Polling-Operationen pro Sekunde haben. Bereitstellungsergebnisse werden normalerweise statisch einem IoT-Hub zugeordnet. Daher sollten Sie die Bereitstellung nur bei Bedarf initiieren, es sei denn, Ihre Anforderungen umfassen automatisierte Neubereitstellungsanforderungen. Wenn Sie mehr Datenverkehr erwarten, skalieren Sie auf mehrere DPS-Instanzen, um Ihr Szenario zu unterstützen.

Verwenden Sie einen gestaffelten Bereitstellungszeitplan. Verwenden Sie einen gestaffelten Bereitstellungszeitplan, um zeitbasierte Einschränkungen zu reduzieren. Bei der erstbereitstellung können Sie eine zufällige Verzögerung von ein paar Sekunden anwenden oder die Verzögerung je nach Bereitstellungsanforderungen auf Minuten verlängern.

Den Status immer abfragen, bevor die Bereitstellung angefordert wird. 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 Aufruf zählt nicht als Abrechnungsposten, und der Grenzwert ist unabhängig vom Registrierungsgrenzwert. Der Abfragevorgang ist relativ schnell im Vergleich zu einer Bereitstellungsanforderung, sodass das Gerät seinen Status überprüfen und seine normale Arbeitsauslastung schneller starten kann. Die entsprechende Geräteregistrierungslogik finden Sie unter "Große Bereitstellung".

Beachten Sie die Vorgaben zur Bereitstellungs-API. Einige der Designs in diesem Artikel umfassen eine Bereitstellungs-API. Die Bereitstellungs-API benötigt einen Sicherungsmetadatenspeicher, z. B. Azure Cosmos DB. Auf diesen Skalierungsebenen sollten Sie ein global verfügbares und robustes Entwurfsmuster implementieren. Die integrierten multi-primären, georedundanten Funktionen und Latenzgarantien in Azure Cosmos DB machen es zu einer hervorragenden Wahl für dieses Szenario. Diese API hat die folgenden Schlüsselverantwortlichkeiten:

Bereitstellen des DPS-ID-Bereichs. Diese Schnittstelle kann eine GET-Anforderung verwenden. Physische Geräte oder Verwaltungsanwendungen stellen eine Verbindung mit dieser Schnittstelle her.
Unterstützung des Gerätelebenszyklus. Ein Gerät benötigt möglicherweise eine erneute Bereitstellung, oder unerwartete Ereignisse können auftreten. Behalten Sie mindestens die Geräte-ID und die zugewiesene DPS für ein Gerät bei. Mit diesen Informationen können Sie den zugewiesenen DPS deaktivieren und einen anderen DPS verwenden. Oder wenn der Lebenszyklus eines Geräts abgelaufen ist, können Sie es vollständig aus dem System entfernen.
Lastenausgleichssysteme. Das System verwendet die gleichen Metadaten bezüglich Geräte-ID und DPS, sodass sie die aktuelle Last für jedes Subsystem verstehen und diese Informationen anwenden kann, um Geräte über die horizontal skalierten Komponenten hinweg besser abzugleichen.
Aufrechterhalten der Systemsicherheit. Die Bereitstellungs-API sollte jede Anforderung authentifizieren. Die empfohlene bewährte Methode ist die Verwendung eines eindeutigen X.509-Zertifikats für jedes Gerät. Dieses Zertifikat kann das Gerät sowohl für die Bereitstellungs-API als auch für die DPS-Instanz authentifizieren, wenn die Architektur es unterstützt. Andere Methoden wie Flottenzertifikate und Token sind verfügbar, bieten jedoch weniger Sicherheit. Ihre spezifische Implementierung und ihre Sicherheitsauswirkungen hängen davon ab, ob Sie eine Zero-Touch- oder Low-Touch-Option auswählen.

Skalieren des IoT-Hubs

Im Vergleich zum Skalieren von DPS ist das Skalieren von IoT Hub relativ einfach. Einer der Vorteile von DPS ist die Möglichkeit, eine Verbindung zu vielen IoT Hub-Instanzen zu erstellen. Wenn Sie die empfohlene Vorgehensweise für die Verwendung von DPS in Azure IoT-Lösungen befolgen, umfasst das Skalieren von IoT Hub die folgenden Schritte:

Erstellen Sie eine neue Instanz des IoT Hub-Diensts.
Konfigurieren Sie die neue Instanz mit den entsprechenden Routingregeln und anderen Details.
Verknüpfen Sie die neue Instanz mit den entsprechenden DPS-Instanzen.
Konfigurieren Sie bei Bedarf die DPS-Zuordnungsrichtlinie oder Ihre benutzerdefinierte Zuordnungsrichtlinie neu.

Gestalten von Gerätesoftware

Für das skalierbare Gerätedesign sind die folgenden bewährten Methoden und geräteseitigen Überlegungen erforderlich. Einige dieser Methoden stammen aus Antimustern, die in der Praxis auftreten. In diesem Abschnitt werden wichtige Konzepte für eine erfolgreich skalierte Bereitstellung beschrieben.

Schätzen Sie Workloads in verschiedenen Teilen des Gerätelebenszyklus und Szenarien innerhalb des Lebenszyklus. Geräteregistrierungsworkloads können zwischen Entwicklungsphasen, z. B. Pilotphase, Entwicklung, Produktion, Außerbetriebnahme und Ende der Lebensdauer, stark variieren. In einigen Fällen können sie auch aufgrund externer Faktoren wie dem bereits erwähnten Blackout-Szenario variieren. Entwerfen Sie die Arbeitsauslastung im schlimmsten Fall, um den Erfolg im großen Maßstab sicherzustellen.

Unterstützung der erneuten Bereitstellung bei Bedarf. Sie können dieses Feature über einen Gerätebefehl und eine Administratorbenutzeranforderung bereitstellen. Für weitere Informationen siehe Wiederherstellungsgeräte. Diese Option erleichtert Szenarien zur Übertragung des Eigentums und Szenarien mit Werksvorgaben.

Vermeiden Sie unnötiges erneutes Bereitstellen. Aktive, funktionierende Geräte erfordern nur selten eine erneute Bereitstellung, da Bereitstellungsinformationen relativ statisch bleiben. Reprovisionieren Sie nicht ohne triftigen Grund.

Überprüfen Sie den Bereitstellungsstatus, wenn Sie häufig neu bereitstellen müssen, z. B. bei jedem Gerätestart. Wenn Sie sich nicht über den Gerätebereitstellungsstatus sicher sind, fragen Sie zuerst den Bereitstellungsstatus ab. Der Abfragevorgang wird mit einem anderen Kontingent als einem Bereitstellungsvorgang behandelt und ist schneller. Diese Abfrage ermöglicht es dem Gerät, den Status der Bereitstellung zu überprüfen, bevor es fortfährt. Dieser Ansatz ist besonders hilfreich, wenn ein Gerät keinen beständigen Speicher zum Speichern der Bereitstellungsergebnisse aufweist.

Sorgen Sie für eine effektive Strategie zur Wiederholungslogik. Das Gerät muss über geeignete Wiederholungsalgorithmen verfügen, die in den Gerätecode integriert sind, sowohl für die erstbereitstellung als auch für die spätere Neubereitstellung. Verwenden Sie Techniken wie exponentielle Backoffs mit Randomisierung. Je nach Anwendungsfall muss die anfängliche Bereitstellung im Wiederholungsprozess möglicherweise aggressiver sein als die erneute Bereitstellung. Beim Drosseln gibt DPS einen Fehlercode HTTP 429 "Too Many Requests" zurück, ähnlich wie die meisten Azure-Dienste. Weitere Informationen finden Sie unter Wiederholen und Antimuster vermeiden. In der DPS-Dokumentation wird auch erläutert, wie man Empfehlungen für Diensterneutversuche interpretiert und Jitter berechnet. Die Stabilität des Gerätestandorts und der Konnektivitätszugriff beeinflussen auch die entsprechende Wiederholungsstrategie. Wenn z. B. ein Gerät erkennt, dass es für Zeiträume offline ist, sollte es vermieden werden, online-Vorgänge erneut auszuführen.

Unterstützen Sie Over-the-Air-Updates (OTA). Zwei einfache Updatemodelle umfassen die Verwendung von Geräte-Twin-Eigenschaften mit der automatischen Geräteverwaltung und die Verwendung einfacher Gerätebefehle. Komplexere Updateszenarien und Berichte finden Sie unter Azure Device Update. Mit OTA-Updates können Sie Fehler im Gerätecode beheben und Dienste wie z. B. DPS-ID-Bereich bei Bedarf neu konfigurieren.

Architekt für Zertifikatänderungen auf allen Ebenen und Zertifikatverwendungen. Diese Empfehlung entspricht den bewährten Methoden des OTA-Updates. Sie müssen eine Zertifikatsrotation in Betracht ziehen. Die IoT Hub DPS-Dokumentation befasst sich mit diesem Szenario anhand eines Geräteidentitätszertifikats-Standpunktes. In einer Gerätelösung werden andere Zertifikate für den Zugriff auf Dienste wie IoT Hub-, App Service- und Azure Storage-Konten verwendet. Azure ändert manchmal Konfigurationen der Zertifizierungsstelle, sodass Sie Änderungen auf allen Ebenen antizipieren müssen. Verwenden Sie außerdem das Anheften von Zertifikaten mit Vorsicht, insbesondere, wenn Zertifikate außerhalb der Kontrolle des Geräteherstellers liegen.

Erwägen Sie einen angemessenen Standardzustand. 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. Koppeln Sie diesen Ansatz immer mit einem geeigneten Wiederholungsmuster und dem Circuit Breaker Pattern.

Schließen Sie ggf. Endpunktkonfigurationsfunktionen ein. Lassen Sie die Konfiguration des DPS-ID-Bereichs, des DPS-Endpunkts oder des benutzerdefinierten Bereitstellungsdienstendpunkts zu. Obwohl sich der DPS-Endpunkt selten ändert, unterstützt die Aktivierung dieser Flexibilität Szenarien wie die automatisierte Überprüfung des Gerätebereitstellungsprozesses durch Integrationstests ohne direkten Azure-Zugriff oder zukünftige Bereitstellungsmodelle, die einen Proxydienst verwenden.

Verwenden Sie die 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, verwenden Sie die Azure IoT-SDKs, um von integrierten bewährten Methoden zu profitieren und die Unterstützung zu vereinfachen. Die SDKs werden open Source veröffentlicht, sodass Sie überprüfen können, wie sie funktionieren und Änderungen vorschlagen. Ihre Wahl des SDK hängt von der Gerätehardware und verfügbaren Laufzeiten auf dem Gerät ab.

Bereitstellen von Geräten

Die Gerätebereitstellung ist ein wichtiger Bestandteil des Gerätelebenszyklus, liegt jedoch außerhalb des Umfangs dieses Artikels, da sie vom Anwendungsfall abhängig ist. Die zuvor erwähnten Diskussionspunkte zur Eigentumsübertragung können für die Bereitstellung und Muster gelten, die eine Bereitstellungsanwendung umfassen, z. B. eine mobile Anwendung. Sie müssen jedoch den Bereitstellungsansatz basierend auf dem verwendeten IoT-Gerätetyp auswählen.

Ü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. Dieser Artikel konzentriert sich explizit auf Architektur und Entwurf und nicht auf die betrieblichen Aspekte der Lösung, daher ist die Überwachung nicht enthalten. Auf hoher Ebene sind überwachungstools jedoch über Azure Monitor in Azure integriert , um sicherzustellen, dass die Lösung keine Grenzwerte erreicht. Weitere Informationen finden Sie in den folgenden Artikeln:

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

Verwenden Sie die folgenden Überwachungsmuster , um die DPS-Nutzung im Laufe der Zeit zu überwachen:

Erstellen Sie eine Anwendung, die jede Registrierungsgruppe auf einer DPS-Instanz abfragt, die Gesamtgeräte abruft, die für diese Gruppe registriert sind, und aggregiert dann die Nummern aus verschiedenen Registrierungsgruppen. Diese Methode bietet eine genaue Anzahl von Geräten, die derzeit über DPS registriert sind, und hilft dabei, den Status des Diensts zu überwachen.
Überwachen Sie Geräteregistrierungen über einen bestimmten Zeitraum. Beispielsweise können Sie die Registrierungsraten für eine DPS-Instanz in den letzten fünf Tagen überwachen. Dieser Ansatz bietet nur eine ungefähre Zahl und ist auf einen festgelegten Zeitraum beschränkt.

Schlussbemerkung

Die Skalierung einer IoT-Lösung zur Unterstützung von Millionen oder sogar Hunderten Millionen von Geräten erfordert eine sorgfältige Planung. Sie müssen viele Faktoren und verschiedene Möglichkeiten berücksichtigen, um die Probleme zu lösen, die in diesen Skalierungen auftreten. In diesem Artikel werden die wichtigsten Bedenken zusammengefasst und Ansätze zur Behandlung dieser Bedenken bei einer erfolgreichen Bereitstellung bereitgestellt.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

Michael C. Bazarewsky | Senior Customer Engineer, Microsoft Azure CXP

Andere Mitwirkende:

David Crook | Principal Customer Engineering Manager, Microsoft Azure CXP
Alberto Gorni | Ehemaliger Senior Customer Engineer, Microsoft Azure CXP

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

Nächste Schritte

Feedback

War diese Seite hilfreich?

Last updated on 2025-10-12