Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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. Die Gründe für diese Verschiebung können die folgenden Szenarien umfassen:
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 kann innerhalb der gleichen IoT-Lösung einem neuen Kunden oder Kundenstandort zugewiesen werden. Dieser neue Kunde kann über einen anderen IoT-Hub gewartet werden.
Änderung einer Lösung: Ein Gerät wird in eine neue oder aktualisierte IoT-Lösung verlagert. Bei dieser 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 nicht ordnungsgemäß funktioniert, kompromittiert oder veraltet ist, kann einem IoT-Hub zugewiesen werden, der es nur aktualisieren und in Übereinstimmung bringen kann. 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 Laufe der Zeit konnten Gerätevorgänge und Back-End-Vorgänge die Gerätestatusdaten auf dem IoT-Hub aktualisieren. 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 kann es auch erforderlich sein, den Gerätestatus, der auf dem vorherigen IoT-Hub aktualisiert wurde, zum neuen IoT-Hub zu migrieren, da ein Gerät zwischen IoT-Hubs wechselt. Die Reprovisioning-Richtlinien im Device Provisioning Service können diese Migration unterstützen.
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 Registrierungseintragskonfiguration wird das Gerät möglicherweise einem anderen IoT-Hub zugewiesen. Wenn das Gerät IoT-Hubs ändert, wird die Geräteregistrierung beim ersten IoT-Hub entfernt. Die aktualisierten Gerätestatusinformationen von diesem ursprünglichen IoT-Hub werden zum neuen IoT-Hub (2) migriert. Während der Migration wird der Status des Geräts 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 Registrierungseintragskonfiguration wird das Gerät möglicherweise einem anderen IoT-Hub zugewiesen. Wenn das Gerät IoT-Hubs ändert, wird die Geräteregistrierung beim ersten 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 Status des Geräts als Wird zugewiesen gemeldet.
Diese Richtlinie wird häufig beim Zurücksetzen einer Factory verwendet, ohne die IoT-Hubs zu ändern.
Niemals erneut bereitstellen: Das Gerät wird niemals 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.
Während Sie Ihre Lösung entwerfen und eine Neuverteilungslogik definieren, müssen Sie einige Dinge berücksichtigen. 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 auf jedem Neustart des Geräts durchzuführen, da diese Aktion einige Probleme verursachen könnte, wenn mehrere Tausend oder Millionen Geräte gleichzeitig neu bereitgestellt werden. 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 die Abfrage nach dem 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 Back-Off mit Randomisierung, wie in der allgemeinen Anleitung zum Wiederholen 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 eine direkte Verbindung mit IoT Hub herzustellen, nachdem die erstmalige Bereitstellung mithilfe von DPS erfolgt ist. Wenn Sie sich dafür entscheiden, direkt auf dem Gerät zu speichern, stellen Sie sicher, dass Sie einen Fallbackmechanismus implementieren, falls bestimmte Fehler von IoT Hub auftreten. Betrachten Sie beispielsweise die folgenden Szenarien:
- Wiederholen Sie den IoT Hub-Vorgang, wenn der Ergebniscode 429 (Zu viele Anforderungen) oder ein Fehler im 5xx-Bereich ist. Bei anderen Fehlern den Vorgang nicht wiederholen.
- Wiederholen Sie bei Fehlern des Typs 429 den Vorgang nach der im Retry-After-Header 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 sollten Sie auch eine direkte Methode unterstützen, um die Bereitstellung bei Bedarf manuell auszulösen.
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.
Bei Lösungen, die von diesem Verhalten abhängig sind, umfasst der Bereitstellungsdienst 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. Weitere Informationen finden Sie in der folgenden 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. Azure IoT-SDKs und APIs sind versionsiert, um sicherzustellen, dass Anwendungen und Dienste weiterhin funktionieren, wenn Produkte und APIs weiterentwickelt werden. Es wird empfohlen, die neuesten Versionen von Azure IoT SDKs und APIs in der Referenzdokumentation für diese SDKs und APIs zu überprüfen. Die neueste Version der REST-API des Azure IoT Hub-Gerätebereitstellungsdiensts lautet beispielsweise 2021-10-01.