Pojęcia dotyczące ponownej aprowizacji urządzeń usługi IoT Hub
W trakcie cyklu życia rozwiązania IoT często przenosi się urządzenia między centrami IoT. Przyczyny tego przeniesienia mogą obejmować następujące scenariusze:
Geolokalizacja/geolatency: w miarę jak urządzenie przenosi się między lokalizacjami, opóźnienie sieci jest ulepszane przez zmigrowanie urządzenia do bliżej centrum IoT.
Obsługa wielu dzierżaw: urządzenie może być używane w tym samym rozwiązaniu IoT i ponownie przydzielone do nowego klienta lub witryny klienta. Ten nowy klient może być obsłużony przy użyciu innego centrum IoT.
Zmiana rozwiązania: urządzenie można przenieść do nowego lub zaktualizowanego rozwiązania IoT. Ponowne przypisanie może wymagać, aby urządzenie komunikowało się z nowym centrum IoT, które jest połączone z innymi składnikami zaplecza.
Kwarantanna: podobna do zmiany rozwiązania. Urządzenie, które działa nieprawidłowo, naruszono lub nieaktualne, może zostać ponownie przydzielone do centrum IoT, które może aktualizować i wracać do zgodności. Gdy urządzenie działa prawidłowo, zostanie ono zmigrowane z powrotem do głównego centrum.
Obsługa ponownej aprowizacji w usłudze Device Provisioning Service odpowiada tym potrzebom. Urządzenia mogą być automatycznie ponownie przypisywane do nowych centrów IoT na podstawie zasad ponownej aprowizacji skonfigurowanych we wpisie rejestracji urządzenia.
Dane stanu urządzenia
Dane stanu urządzenia składają się z bliźniaczej reprezentacji urządzenia i możliwości urządzenia. Te dane są przechowywane w wystąpieniu usługi Device Provisioning Service i centrum IoT, do którego jest przypisane urządzenie.
Gdy urządzenie jest początkowo aprowidowane przy użyciu wystąpienia usługi Device Provisioning Service, należy wykonać następujące kroki:
Urządzenie wysyła żądanie aprowizacji do wystąpienia usługi Device Provisioning Service. Wystąpienie usługi uwierzytelnia tożsamość urządzenia na podstawie wpisu rejestracji i tworzy początkową konfigurację danych stanu urządzenia. Wystąpienie usługi przypisuje urządzenie do centrum IoT Na podstawie konfiguracji rejestracji i zwraca przypisanie centrum IoT do urządzenia.
Wystąpienie usługi aprowizacji udostępnia kopię wszystkich początkowych danych stanu urządzenia do przypisanego centrum IoT. Urządzenie łączy się z przypisanym centrum IoT i rozpoczyna operacje.
W miarę upływu czasu dane stanu urządzenia w centrum IoT mogą być aktualizowane przez operacje urządzeń i operacje zaplecza. Początkowe informacje o stanie urządzenia przechowywane w wystąpieniu usługi Device Provisioning Service pozostają niezmienione. Te nietknięte dane stanu urządzenia to początkowa konfiguracja.
W zależności od scenariusza, w miarę jak urządzenie przechodzi między centrami IoT, może być również konieczne przeprowadzenie migracji stanu urządzenia zaktualizowanego w poprzednim centrum IoT hub do nowego centrum IoT. Ta migracja jest obsługiwana przez zasady ponownego aprowizowania w usłudze Device Provisioning.
Zasady ponownej aprowizacji
W zależności od scenariusza urządzenie może wysłać żądanie do wystąpienia usługi aprowizacji po ponownym uruchomieniu. Obsługuje również metodę ręcznego wyzwalania aprowizacji na żądanie. Zasady ponownej aprowizacji we wpisie rejestracji określają, w jaki sposób wystąpienie usługi aprowizacji urządzeń obsługuje te żądania aprowizacji. Zasady określają również, czy dane stanu urządzenia powinny być migrowane podczas ponownej aprowizacji. Te same zasady są dostępne dla poszczególnych rejestracji i grup rejestracji:
Ponowne aprowizowanie i migrowanie danych: te zasady są domyślne dla nowych wpisów rejestracji. Te zasady podejmuje działania, gdy urządzenia skojarzone z wpisem rejestracji przesyłają nowe żądanie (1). W zależności od konfiguracji wpisu rejestracji urządzenie może zostać ponownie przydzielone do innego centrum IoT. Jeśli urządzenie zmienia centra IoT, rejestracja urządzenia przy użyciu początkowego centrum IoT zostanie usunięta. Zaktualizowane informacje o stanie urządzenia z tego początkowego centrum IoT Zostaną zmigrowane do nowego centrum IoT (2). Podczas migracji stan urządzenia zostanie zgłoszony jako Przypisywanie.
Ponowne aprowizowanie i resetowanie do początkowej konfiguracji: te zasady podejmuje działania, gdy urządzenia skojarzone z wpisem rejestracji przesyłają nowe żądanie aprowizacji (1). W zależności od konfiguracji wpisu rejestracji urządzenie może zostać ponownie przydzielone do innego centrum IoT. Jeśli urządzenie zmienia centra IoT, rejestracja urządzenia przy użyciu początkowego centrum IoT zostanie usunięta. Początkowe dane konfiguracji odebrane przez wystąpienie usługi aprowizacji podczas aprowizowania urządzenia są udostępniane nowemu centrum IoT (2). Podczas migracji stan urządzenia zostanie zgłoszony jako Przypisywanie.
Te zasady są często używane do resetowania do ustawień fabrycznych bez zmieniania centrów IoT.
Nigdy nie należy ponownie aprowizacji: urządzenie nigdy nie jest ponownie przypisywane do innego centrum. Te zasady są udostępniane do zarządzania zgodnością z poprzednimi wersjami.
Uwaga
Usługa DPS zawsze wywołuje niestandardowy element webhook alokacji niezależnie od zasad ponownego aprowizowania w przypadku, gdy urządzenie ma nową wartość ReturnData . Jeśli zasady ponownego aprowizacji nie zostaną ustawione na nigdy nie zostaną ponownie aprowizowania, element webhook zostanie wywołany, ale urządzenie nie zmieni przypisanego centrum.
Podczas projektowania rozwiązania i definiowania logiki ponownej aprowizacji należy wziąć pod uwagę kilka kwestii. Przykład:
- Jak często oczekujesz ponownego uruchomienia urządzeń
- Limity przydziału i limity usługi DPS
- Oczekiwany czas wdrożenia floty (wdrożenie etapowe a wszystkie jednocześnie)
- Możliwość ponawiania prób zaimplementowana w kodzie klienta zgodnie z opisem w ogólnych wskazówkach dotyczących ponawiania prób w Centrum architektury platformy Azure
Napiwek
Zalecamy, aby nie aprowizować każdego ponownego uruchomienia urządzenia, ponieważ może to spowodować pewne problemy podczas ponownej aprowizacji kilku tysięcy lub milionów urządzeń jednocześnie. Zamiast tego należy podjąć próbę użycia interfejsu API wyszukiwania stanu rejestracji urządzenia i spróbować nawiązać połączenie z informacjami z usługą IoT Hub. Jeśli to się nie powiedzie, spróbuj ponownie aprowizacji, ponieważ informacje o usłudze IoT Hub mogły ulec zmianie. Należy pamiętać, że wykonywanie zapytań dotyczących stanu rejestracji będzie liczone jako nowa rejestracja urządzenia, dlatego należy rozważyć limit rejestracji urządzenia. Rozważ również zaimplementowanie odpowiedniej logiki ponawiania, takiej jak wycofywanie wykładnicze z losowością, zgodnie z opisem w ogólnych wskazówkach dotyczących ponawiania prób. W niektórych przypadkach, w zależności od możliwości urządzenia, można zapisać informacje usługi IoT Hub bezpośrednio na urządzeniu, aby połączyć się bezpośrednio z usługą IoT Hub po pierwszej aprowizacji przy użyciu usługi DPS. Jeśli zdecydujesz się to zrobić, upewnij się, że zaimplementowasz mechanizm rezerwowy w przypadku wystąpienia określonych błędów z centrum, na przykład rozważ następujące scenariusze:
- Spróbuj ponownie wykonać operację centrum, jeśli kod wyniku to 429 (zbyt wiele żądań) lub błąd w zakresie 5xx. Nie należy wykonywać ponowień w przypadku innych błędów.
- W przypadku błędów 429 spróbuj ponownie tylko po upływie czasu wskazanego w nagłówku Ponów próbę po.
- W przypadku błędów 5xx należy użyć wycofywania wykładniczego, a pierwsze ponowienie próby co najmniej 5 sekund po odpowiedzi.
- W przypadku błędów innych niż 429 i 5xx ponownie zarejestruj się za pośrednictwem usługi DPS
- Najlepiej jest również obsługiwać metodę ręcznego wyzwalania aprowizacji na żądanie.
Zalecamy również uwzględnienie limitów usług podczas planowania działań, takich jak wypychanie aktualizacji do floty. Na przykład aktualizacja floty jednocześnie może spowodować ponowne zarejestrowanie wszystkich urządzeń za pośrednictwem usługi DPS (co może być łatwe powyżej limitu przydziału rejestracji) — w takich scenariuszach rozważ planowanie aktualizacji urządzeń w fazach zamiast aktualizowania całej floty w tym samym czasie.
Zarządzanie zgodnością z poprzednimi wersjami
Przed wrześniem 2018 r. przypisania urządzeń do centrów IoT miały lepkie zachowanie. Po powrocie urządzenia przez proces aprowizacji zostanie ono przypisane tylko do tego samego centrum IoT.
W przypadku rozwiązań, które miały zależność od tego zachowania, usługa aprowizacji obejmuje zgodność z poprzednimi wersjami. To zachowanie jest obecnie utrzymywane dla urządzeń zgodnie z następującymi kryteriami:
Urządzenia łączą się z wersją interfejsu API przed udostępnieniem natywnej obsługi ponownej aprowizacji w usłudze Device Provisioning. Zapoznaj się z poniższą tabelą interfejsu API.
Wpis rejestracji dla urządzeń nie ma ustawionych zasad ponownej aprowizacji.
Ta zgodność zapewnia, że wcześniej wdrożone urządzenia mają takie samo zachowanie, które występuje podczas testowania początkowego. Aby zachować poprzednie zachowanie, nie zapisuj zasad ponownej aprowizacji w tych rejestracjach. Jeśli ustawiono zasady ponownego aprowizowania, zasady ponownego aprowizowania mają pierwszeństwo przed zachowaniem. Zezwalając na pierwszeństwo zasad ponownego aprowizowania, klienci mogą aktualizować zachowanie urządzenia bez konieczności ponownego tworzenia obrazu urządzenia.
Poniższy wykres blokowy pomaga pokazać, kiedy zachowanie jest obecne:
W poniższej tabeli przedstawiono wersje interfejsu API przed dostępnością natywnej obsługi ponownej obsługi administracyjnej w usłudze Device Provisioning:
| Interfejs API REST | C SDK | Zestaw SDK dla języka Python | Zestaw SDK dla języka Node | Zestaw SDK Java | Zestaw SDK platformy .NET |
|---|---|---|---|---|---|
| 2018-04-01 i starsze | 1.2.8 i starsze | 1.4.2 i starsze | 1.7.3 lub starszy | 1.13.0 lub starszy | 1.1.0 lub starszy |
Uwaga
Te wartości i linki mogą ulec zmianie. Jest to tylko symbol zastępczy, który próbuje określić, gdzie wersje mogą być określane przez klienta i jakie będą oczekiwane wersje.