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

Das Skalierungsmuster ist ein Ansatz zum Skalieren einer IoT-Lösung (Internet of Things), die Instanzen zu einer Bereitstellung hinzufügt, anstatt die Größe jeder Instanz zu erhöhen. Auf der Azure IoT Hub-Plattform können Sie eine Skalierung durchführen, um Millionen von Geräten zu unterstützen, während Sie in Azure Dienst- und Abonnementbeschränkungen bleiben.

In diesem Artikel erfahren Sie, wie Sie das Skalierungsmuster auf eine IoT Hub-basierte Lösung anwenden. Es beschreibt die Bereitstellungsmodelle mit geringer Toucheingabe und Zero Touch, damit Sie den Ansatz übernehmen können, der Ihren Anforderungen entspricht.

Weitere Informationen finden Sie in den folgenden Artikeln:

Hinweis

Dieses Dokument behandelt nicht die Azure IoT Einsatz-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 unterscheidet sich grundlegend von einer Lösung für 1 Millionen Geräte. 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. Von Haus aus kann eine einzelne DPS-Instanz zu mehreren IoT Hub Instanzen routen. 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 für 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 benötigt auch ein dokumentiertes Wiederherstellungspunktziel (RPO) und ein Wiederherstellungszeitziel (Recovery Time Objective, RTO), 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 Hub und DPS-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 wird basierend auf der gewünschten Funktionalität und der Anzahl der Nachrichten oder des Datenvolumens pro Tag skaliert. 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 vollständigen Funktionen von IoT Hub zu erhalten.
Die size bestimmt die Nachrichten- und Datendurchsatzbasiseinheit für D2C-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.144,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.

Zusätzlich zu den täglichen Grenzwerten, die auf der Größe, der Einheitenanzahl sowie den allgemeinen Funktionalitätsgrenzwerten der Ebene basieren, erzwingt IoT Hub Grenzwerte pro Sekunde für den Durchsatz. Jede IoT Hub Instanz unterstützt auch bis zu 1 Million Geräte als hard limit. Ihre Anforderungen an den Datenaustausch helfen beim Definieren der geeigneten Konfiguration. Weitere Informationen finden Sie unter "Weitere Grenzwerte".

Ihre Lösungsanforderungen steuern die erforderliche Größe und Anzahl von IoT Hub Instanzen als Ausgangspunkt. Wenn Sie IoT Hub DPS verwenden, hilft ihnen Azure, Ihre Workloads über mehrere IoT Hub Instanzen zu verteilen.

IoT Hub DPS

IoT Hub DPS ist ein Hilfsservice für IoT Hub, der eine vollautomatische Just-in-Time-Bereitstellung für den richtigen IoT Hub ohne menschliches Eingreifen ermöglicht. Jedes Azure-Abonnement unterstützt standardmäßig 10 DPS-Instanzen. Jede Dienstinstanz unterstützt wiederum eine Standardeinstellung von 1 Millionen Registrierungen. Berücksichtigen Sie Dienstlimits beim Entwurf Ihrer Workload, um zukünftige Probleme zu vermeiden.

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

Standardmäßig nutzt DPS die Georeplikation, um die Notfallwiederherstellung auf Regionsebene zu aktivieren. Weitere Informationen finden Sie in der DPS-Dokumentation zur Notfallwiederherstellung.

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 sich von vorübergehenden oder temporären Fehlern erholen. 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

Für die vorübergehende Fehlerbehandlung müssen Sie eine Wiederholungsfunktion in Ihrem Gerätecode erstellen. Es gibt mehrere Wiederholungsstrategien, einschließlich exponentieller Backoff mit Randomisierung, auch als exponentieller Backoff mit Jitter bezeichnet. Weitere Informationen finden Sie unter Behandeln vorübergehender Fehler.

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 berücksichtigen. Diese Ausfälle können sich auf einzelne Dienste oder ganze Regionen auswirken. Einige Dienste wie IoT Hub und IoT Hub DPS unterstützen einige Arten von Georedundanz. Sie können einen IoT Hub mit mehreren DPS-Instanzen verknüpfen, und eine DPS-Instanz unterstützt mehrere IoT-Hub-Instanzen; beides trägt zwar zur Minderung regionaler Risiken bei, beseitigt sie jedoch nicht vollständig. Wenn eine vollständige regionale Hochverfügbarkeit 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. Diese Muster helfen auch bei der Behebung der Sorge, dass IoT Hub DPS keine Integritätsüberwachung auf verknüpften IoT-Hubs durchführt, da eine geografisch verteilte Bereitstellung mit einer geeigneten Lösung zur Integritätsüberwachung und lastenausgleichslösung das Routing an eine andere DPS-Instanz und somit eine andere IoT Hub Instanz ermöglicht.

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ätestandort, Datenspeicherort und Metadatenspeicherort (z. B. Azure Ressourcengruppen) spielen eine wichtige Rolle bei Ihrem Entwurf.

Standort des Geräts: Gerätestandortanforderungen beeinflussen Ihre regionale Auswahl, da sie sich auf die Transaktionslatenz auswirken.
Datenspeicherort: Der Datenspeicherort hängt vom Gerätespeicherort ab und unterliegt Compliance-Bedenken. Zum Beispiel könnte eine Lösung, die Daten für einen Bundesstaat in den Vereinigten Staaten speichert, möglicherweise eine Datenspeicherung in der US-amerikanischen Geographie 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 Leitlinien 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 entwerfen, um hoch verfügbar zu sein und die Kosten für Resilienz und Redundanz bei der Abrechnung des Kunden zu berücksichtigen.

Obwohl es möglich ist, die Mandantennutzung auf einer höheren Ebene als die Serviceebene nachzuverfolgen, ist es oft einfacher, die Kosten für verkaufte Waren (COGS) basierend auf der Kundendatentrennung für jeden SaaS-Anbieter zu trennen. Diese Unterscheidung ist besonders wichtig, wenn der Endbenutzer nicht derselbe ist wie der SaaS-Kunde. Bei einer Smart-TV-Plattform könnte der Kunde des Plattformanbieters beispielsweise der Fernsehanbieter sein, während der Endbenutzer der Fernsehkäufer ist. Das erforderliche Kunden-Mandantenmodell bedingt diese Trennung, was wiederum der Einfachheit halber häufig zu separaten DPS- und IoT-Hub-Instanzen führt (mit dem Risiko potenziell höherer Bereitstellungskosten). Es sollte beachtet werden, dass diese Trennung speziell für die Nachverfolgung der COGS vorgesehen ist; sie ist für die reine Mandantenisolation nicht erforderlich, wie unter IoT Hub-basierte Architekturansätze für Mehrmandantenlösungen erläutert.

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. Skalieren Sie Ihre IoT-Lösung auf mehrere DPS-Instanzen und/oder mehrere IoT Hub Instanzen.

Über mehrere DPS-Instanzen skalieren

Aufgrund von DPS-Dienstgrenzwerten ist es oft erforderlich, auf mehrere DPS-Instanzen zu erweitern. Gehen Sie die Gerätebereitstellung über mehrere DPS-Instanzen mithilfe der Zero-Touch- oder der Low-Touch-Bereitstellung an.

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 Azure Front Door. 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 von Standard-DPS Load-Balancingmechanismen zu.

Das Gerät fordert einen DPS-ID-Bereich von einer in App Service gehosteten Bereitstellungs-API an. 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 ist die Datenbank eine Azure Cosmos DB Instanz mit mehrstufigem Schreibzugriff, die für eine 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 unterstützt bei Bedarf auch die erneute Bereitstellung mithilfe desselben DPS-ID-Bereichs. Authentifizieren Sie die Bereitstellungs-API, um unangemessene Bereitstellungsanforderungen zu verhindern.
Das Gerät fordert die Bereitstellung von DPS mithilfe des zugewiesenen ID-Bereichs an. 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.

Für dieses Design ist die Gerätesoftware erforderlich, um das DPS SDK einzuschließen und den DPS-Registrierungsprozess zu verwalten. Dies ist das typische Design für ein Azure IoT-Gerät. 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 enthält die Bereitstellungs-API die Geräteauthentifizierung für DPS zusammen mit den meisten Wiederholungslogiken. Dieser Prozess unterstützt erweiterte Warteschlangenszenarien und potenziell einfacheren Bereitstellungscode auf dem Gerät selbst. Es unterstützt auch das Zwischenspeichern des zugewiesenen IoT-Hubs, um schnellere C2D-Nachrichten zu ermöglichen, ohne DPS für die zugewiesenen Hubinformationen abzufragen.

Das Gerät sendet eine Anforderung an eine Bereitstellungs-API, die in einer Instanz des App-Diensts 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 ist die Datenbank eine Azure Cosmos DB Instanz mit mehrstufigem Schreibzugriff, die für eine 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 unterstützt bei Bedarf auch die erneute Bereitstellung mithilfe desselben DPS-ID-Bereichs.

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. Eine Lösung kann beispielsweise Hardware-eindeutige IDs als Teil eines Dienstauthentifizierungsprozesses verwenden. 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 speichert die IoT Hub Verbindungsinformationen im beständigen Speicher, idealerweise an einem gesicherten Speicherort, da der ID-Bereich Teil der Authentifizierung gegenüber der DPS-Instanz ist. Das Gerät verwendet diese IoT-Hub-Verbindungsinformationen für spätere Anfragen an das System.

Dieses Design vermeidet die Notwendigkeit, direkt auf das DPS SDK oder den DPS-Dienst zu verweisen. Außerdem wird vermieden, dass ein DPS-Bereich auf dem Gerät manuell verwaltet werden muss, da er von der Bereitstellungs-API stammt. 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 unterstützt die Bereitstellung ohne eine benutzerdefinierte Bereitstellungs-API, erfordert jedoch eine Verwaltungsanwendung, um DPS-Instanzen nach Bedarf nachzuverfolgen und die Umleitung bereitzustellen.

Zu den Anforderungen der Managementanwendung gehört die Nachverfolgung, welcher DPS der aktive DPS für jedes bestimmte Gerät sein soll. Verwenden Sie diesen Ansatz für Übernahmeszenarien, bei denen der Geräteanbieter den Besitz des Geräts 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 ist die Datenbank eine Azure Cosmos DB Instanz mit mehrstufigem Schreibzugriff, die für eine 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 unterstützt bei Bedarf auch die erneute Bereitstellung unter Verwendung desselben DPS-ID-Bereichs. Authentifizieren Sie die Bereitstellungs-API, um unangemessene Bereitstellungsanforderungen zu verhindern.
Die App gibt den Bereich der Bereitstellungs-ID an das Gerät zurück.
Das Gerät fordert die Bereitstellung bei DPS mithilfe des zugewiesenen ID-Bereichs an. 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 der Standardgrenze 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 pro Gerät auf fünf Abfragen alle 10 Sekunden begrenzt sind. 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. Wenden Sie bei der erstbereitstellung je nach Bereitstellungsanforderungen eine zufällige Verzögerung von ein paar Sekunden an oder verlängern Sie die Verzögerung auf Minuten.

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 die 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. Verwenden Sie diese Informationen, um die Bereitstellung von dem zugewiesenen DPS auf einen anderen zu aufheben und erneut zu übertragen. Oder wenn der Lebenszyklus eines Geräts abgelaufen ist, können Sie es vollständig aus dem System entfernen.
Lastenausgleichssysteme. Das System verwendet dieselben Metadaten zu 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 bewährte Methode besteht darin, ein eindeutiges X.509-Zertifikat für jedes Gerät zu verwenden. 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.

IoT Hub skalieren

Im Vergleich zum Skalieren von DPS ist das Skalieren von IoT Hub relativ einfach. Einer der Vorteile von DPS ist die Fähigkeit, mit vielen IoT Hub Instanzen zu verknüpfen. Wenn Sie die empfohlene Vorgehensweise für die Verwendung von DPS in Azure IoT Lösungen befolgen, umfasst das Skalieren 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.

Entwerfen von Gerätesoftware zur Skalierung

Für das skalierbare Gerätedesign sind die folgenden bewährten Methoden und geräteseitigen Überlegungen erforderlich. Einige dieser Vorgehensweisen gehen auf Antimuster zurück, 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. Stellen Sie dieses Feature über einen Gerätebefehl und eine Administratorbenutzeranforderung bereit. 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 verwendet ein anderes Kontingent als einen Bereitstellungsvorgang und ist schneller. Mit dieser Abfrage kann das Gerät den Bereitstellungsstatus überprüfen, bevor sie fortfahren. 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 HTTP 429 Zu viele Anforderungen Fehlercode zurück, ähnlich wie die meisten Azure-Dienste. Diese Antwort enthält manchmal den Header Retry-After, um Hinweise für das Backoff-Timing zu geben. 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 einen bestimmten Zeitraum offline ist, sollte es vermieden werden, Onlinevorgänge erneut auszuführen.

Unterstützen Sie Over-the-Air-Updates (OTA). Zwei einfache Updatemodelle umfassen Geräte-Twin-Eigenschaften mit automatischer Geräteverwaltung und einfachen Gerätebefehlen. 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 behandelt dieses Szenario aus einem Geräteidentitätszertifikat Standpunkt. In einer Gerätelösung verwenden Sie andere Zertifikate für den Zugriff auf Dienste wie IoT Hub, App Service und Azure Storage Konten. 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 sind Open Source, 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ängt. 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 Ihrer gesamten Bereitstellung besteht darin, die Lösung von Anfang bis Ende zu überwachen, um sicherzustellen, dass das System wie vorgesehen funktioniert. Dieser Artikel konzentriert sich explizit auf Architektur und Design und nicht auf die betrieblichen Aspekte der Lösung, sodass er die Überwachung nicht ausführlich behandelt. Auf hoher Ebene bietet Azure jedoch integrierte Überwachungstools über Azure Monitor, um sicherzustellen, dass die Lösung keine Grenzwerte erreicht. Weitere Informationen finden Sie in den folgenden Artikeln:

Verwenden Sie diese Tools einzeln oder als Teil einer komplexeren SIEM-Lösung (Security Information and Event Management), z. B. Microsoft Sentinel.

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 gilt nur für einen festgelegten Zeitraum.

Wichtige Voraussetzungen für die Skalierung einer IoT-Lösung

Das Skalieren 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 Behebung 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 zu sehen, melden Sie sich bei LinkedIn an.

Nächste Schritte

Feedback

War diese Seite hilfreich?

Last updated on 2026-08-14