IoT Hub Device-Konzepte für die erneute Bereitstellung
Im Lauf des Lebenszyklus einer IoT-Lösung kommt es häufig vor, dass Geräte von einem IoT-Hub zu einem anderen verlagert werden. Folgende Szenarien können der Grund für eine solche Verlagerung sein:
Geolocation oder Geolatenz: Wenn ein Gerät von einem Standort zu einem anderen verlagert wird, lässt sich die Netzwerklatenz verbessern, indem das Gerät zu einem näher gelegenen IoT-Hub migriert wird.
Mehrinstanzenfähigkeit: Ein Gerät wird innerhalb der gleichen IoT-Lösung einem neuen Kunden oder Kundenstandort zugewiesen. Die Dienstbereitstellung für diesen neuen Kunden erfolgt möglicherweise über einen anderen IoT-Hub.
Änderung einer Lösung: Ein Gerät wird in eine neue oder aktualisierte IoT-Lösung verlagert. Aufgrund der Neuzuweisung muss das Gerät möglicherweise mit einem neuen IoT-Hub kommunizieren, der mit anderen Back-End-Komponenten verbunden ist.
Quarantäne: Dieses Szenario ähnelt der Änderung einer Lösung. Ein Gerät, das Fehlfunktionen aufweist, eine Sicherheitslücke darstellt oder veraltet ist, kann einem IoT-Hub zugewiesen werden, der ausschließlich Updates ausführen kann, um die Compliance wiederherzustellen. Sobald das Gerät wieder ordnungsgemäß funktioniert, wird es wieder zu seinem primären Hub migriert.
Die Unterstützung für die erneute Bereitstellung im Device Provisioning Service erfüllt diese Anforderungen. Auf Basis der Richtlinie für die erneute Bereitstellung, die im Registrierungseintrag des Geräts konfiguriert ist, können Geräte neuen IoT-Hubs automatisch erneut zugewiesen werden.
Daten zum Gerätezustand
Die Daten zum Gerätestatus bestehen aus dem Gerätezwilling und den Gerätefunktionen. Diese Daten werden in der Device Provisioning Service-Instanz und dem IoT-Hub gespeichert, dem das Gerät zugewiesen ist.
Wenn ein Gerät erstmals mit einer Device Provisioning Service-Instanz bereitgestellt wird, werden folgende Schritte ausgeführt:
Das Gerät sendet eine Bereitstellungsanforderung an eine Device Provisioning Service-Instanz. Die Dienstinstanz authentifiziert die Geräteidentität anhand eines Registrierungseintrags und erstellt die anfängliche Konfiguration der Gerätezustandsdaten. Die Dienstinstanz weist das Gerät basierend auf der Registrierungskonfiguration einem IoT-Hub zu und gibt diese IoT-Hub-Zuweisung an das Gerät zurück.
Die Provisioning Service-Instanz sendet eine Kopie aller anfänglichen Gerätezustandsdaten an den zugewiesenen IoT-Hub. Das Gerät stellt eine Verbindung mit dem zugewiesenen IoT-Hub her, und beginnt mit dem Betrieb.
Im Lauf der Zeit können die Gerätezustandsdaten im IoT-Hub durch Gerätevorgänge und Back-End-Vorgänge aktualisiert werden. Die anfänglichen Informationen zum Gerätestatus, die in der Device Provisioning Service-Instanz gespeichert sind, bleiben davon unberührt. Diese unveränderten Gerätezustandsdaten stellen die anfängliche Konfiguration dar.
Je nach Szenario ist es bei der Verlagerung von Geräten von einem IoT-Hub zu einem anderen möglicherweise erforderlich, den im vorherigen IoT-Hub aktualisierten Gerätezustand zum neuen IoT-Hub zu migrieren. Diese Migration wird durch die Richtlinien für die erneute Bereitstellung im Device Provisioning Service unterstützt.
Richtlinien für die erneute Bereitstellung
Je nach Szenario könnte ein Gerät beim Neustart eine Anforderung an eine Provisioning Service-Instanz senden. Außerdem wird eine Methode zum manuellen Auslösen der Bereitstellung nach Bedarf unterstützt. Die in einem Registrierungseintrag befindliche Richtlinie für die erneute Bereitstellung bestimmt, wie die Device Provisioning Service-Instanz diese Bereitstellungsanforderungen verarbeitet. Die Richtlinie bestimmt auch, ob Gerätestatusdaten während der erneuten Bereitstellung migriert werden sollen. Für einzelne Registrierungen und Registrierungsgruppen sind die gleichen Richtlinien verfügbar:
Gerät erneut bereitstellen und Daten migrieren: Dies ist die Standardrichtlinie für neue Registrierungseinträge. Diese Richtlinie wird angewendet, wenn Geräte, die dem Registrierungseintrag zugeordnet sind, eine neue Anforderung senden (1). Je nach Konfiguration des Registrierungseintrags wird das Gerät möglicherweise einem anderen IoT-Hub zugewiesen. Wenn das Gerät den IoT-Hub wechselt, wird die Geräteregistrierung für den ursprünglichen IoT-Hub entfernt. Die aktualisierten Gerätezustandsinformationen von diesem ursprünglichen IoT-Hub werden zum neuen IoT-Hub migriert (2). Während der Migration wird der Gerätestatus als Wird zugewiesen gemeldet.
Erneut zuweisen und auf anfängliche Konfiguration zurücksetzen: Diese Richtlinie wird angewendet, wenn Geräte, die dem Registrierungseintrag zugeordnet sind, eine neue Bereitstellungsanforderung (1) senden. Je nach Konfiguration des Registrierungseintrags wird das Gerät möglicherweise einem anderen IoT-Hub zugewiesen. Wenn das Gerät den IoT-Hub wechselt, wird die Geräteregistrierung für den ursprünglichen IoT-Hub entfernt. Die anfänglichen Konfigurationsdaten, die von der Provisioning Service-Instanz bei der Bereitstellung des Geräts empfangen wurden, werden an den neuen IoT-Hub gesendet (2). Während der Migration wird der Gerätestatus als Wird zugewiesen gemeldet.
Diese Richtlinie wird häufig beim Zurücksetzen einer Factory verwendet, ohne die IoT-Hubs zu ändern.
Nie neu bereitstellen: Das Gerät wird nie einem anderen Hub zugewiesen. Diese Richtlinie dient der Verwaltung der Abwärtskompatibilität.
Hinweis
DPS ruft unabhängig von der Richtlinie für die erneute Bereitstellung immer den benutzerdefinierten Zuteilungswebhook auf, falls für das Gerät neue ReturnData vorhanden sind. Wenn die Richtlinie für die erneute Bereitstellung auf Nie erneut bereitstellen festgelegt ist, wird der Webhook zwar aufgerufen, das Gerät ändert seinen zugewiesenen Hub jedoch nicht.
Beim Entwerfen Ihrer Lösung und Definieren einer Logik für die erneute Bereitstellung sind einige Punkte zu berücksichtigen. Zum Beispiel:
- Wie oft sollen Ihre Geräte neu gestartet werden?
- DPS-Kontingente und -Grenzwerte
- Erwartete Bereitstellungszeit für Ihren Bestand (stufenweiser Rollout im Vergleich zum gleichzeitigen Rollout)
- Für Ihren Clientcode implementierte Wiederholungsfunktion, wie im allgemeinen Leitfaden zum Wiederholen von Vorgängen im Azure Architecture Center beschrieben
Tipp
Es wird empfohlen, die Bereitstellung nicht bei jedem Neustart des Geräts durchzuführen, da dies bei der erneuten gleichzeitigen Bereitstellung mehrerer Tausender oder Millionen von Geräten zu Problemen führen kann. Stattdessen sollten Sie versuchen, die API zum Abrufen des Geräteregistrierungsstatus zu verwenden und mit diesen Informationen eine Verbindung mit IoT Hub herzustellen. Wenn dabei ein Fehler auftritt, versuchen Sie, die Bereitstellung zu wiederholen, da sich die IoT Hub-Informationen möglicherweise geändert haben. Beachten Sie, dass das Abfragen des Registrierungsstatus als neue Geräteregistrierung gilt. Daher sollten Sie den Grenzwert für die Geräteregistrierung berücksichtigen. Erwägen Sie auch die Implementierung einer geeigneten Wiederholungslogik, z. B. exponentielles Backoff mit Randomisierung, wie im allgemeinen Leitfaden zum Wiederholen von Vorgängen beschrieben. In einigen Fällen ist es abhängig von den Gerätefunktionen möglich, die IoT Hub-Informationen direkt auf dem Gerät zu speichern, um nach der erstmaligen Bereitstellung mit DPS eine direkte Verbindung mit IoT Hub herzustellen. Stellen Sie in diesem Fall sicher, dass Sie einen Fallbackmechanismus implementieren, falls bestimmte Fehler auf dem Hub auftreten. Betrachten Sie beispielsweise die folgenden Szenarien:
- Wiederholen Sie den Hub-Vorgang wenn der Ergebniscode 429 (Zu viele Anforderungen) lautet oder das Ergebnis ein Fehler im Bereich 5xx ist. Bei anderen Fehlern den Vorgang nicht wiederholen.
- Wiederholen Sie bei Fehlern des Typs 429 den Vorgang nach der im Header Retry-After angegebenen Zeit.
- Verwenden Sie bei Fehlern des Typs 5xx exponentielles Backoff mit dem ersten Wiederholungsversuch mindestens 5 Sekunden nach der Antwort.
- Registrieren Sie sich bei anderen Fehlern als 429 und 5xx erneut über DPS
- Im Idealfall sollte eine Methode zum manuellen Auslösen der Bereitstellung nach Bedarf unterstützt werden.
Es wird auch empfohlen, die Dienstgrenzwerte zu berücksichtigen, wenn Sie Aktivitäten wie das Pushen von Updates an Ihren Bestand planen. Wenn sie beispielsweise den gesamten Bestand auf einmal aktualisieren, kann dies dazu führen, dass sich alle Geräte über DPS erneut registrieren (was leicht über dem Grenzwert für Registrierungskontingente liegen kann). In solchen Szenarien sollten Sie die Planung von Geräteupdates in Phasen in Erwägung ziehen, anstatt den gesamten Bestand auf einmal zu aktualisieren.
Verwalten der Abwärtskompatibilität
Vor September 2018 legten Gerätezuweisungen in IoT-Hubs ein bestimmtes Verhalten an den Tag. Wenn ein Gerät den Bereitstellungsprozess erneut durchlief, wurde es immer nur dem gleichen IoT-Hub zugewiesen.
Für Lösungen, die von diesem Verhalten abhängig sind, bietet der Provisioning Service Abwärtskompatibilität. Dieses Verhalten wird derzeit gemäß den folgenden Kriterien für Geräte beibehalten:
Die Geräte stellen eine Verbindung mit einer API-Version her, bevor die native Unterstützung der erneuten Bereitstellung im Device Provisioning Service verfügbar ist. Informationen dazu finden Sie in der unten stehenden API-Tabelle.
Für den Registrierungseintrag für die Geräte ist keine Richtlinie für die erneute Bereitstellung festgelegt.
Diese Kompatibilität stellt sicher, dass für bereits bereitgestellte Geräte das gleiche Verhalten gilt wie in der anfänglichen Testphase. Um das vorherige Verhalten beizubehalten, speichern Sie für diese Registrierungen keine Richtlinie für die erneute Bereitstellung. Wenn eine Richtlinie für die erneute Bereitstellung festgelegt wurde, hat diese Richtlinie Vorrang vor dem Verhalten. Da die Richtlinie für die erneute Bereitstellung Vorrang hat, können Kunden das Geräteverhalten aktualisieren, ohne ein Reimaging des Geräts durchführen zu müssen.
Das folgende Flussdiagramm zeigt, wann das Verhalten vorhanden ist:
Die folgende Tabelle zeigt die API-Versionen, für welche die native Unterstützung der erneuten Bereitstellung im Device Provisioning Service noch nicht verfügbar ist:
| REST-API | C SDK | Python SDK | Node SDK | Java SDK | .NET SDK |
|---|---|---|---|---|---|
| 2018-04-01 und früher | 1.2.8 und früher | 1.4.2 und früher | 1.7.3 und früher | 1.13.0 und früher | 1.1.0 und früher |
Hinweis
Diese Werte und Links werden sich voraussichtlich ändern. Dies ist nur ein Platzhalter zur Angabe, wo die Versionen vom Kunden bestimmt werden können und wie die erwarteten Versionen lauten.