IoT Hub pojęcia dotyczące ponownej aprowizacji urządzeń

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ższego centrum IoT.

  • Obsługa wielu dzierżaw: urządzenie może być używane w ramach tego samego rozwiązania 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. To 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: podobnie jak w przypadku zmiany rozwiązania. Urządzenie, które działa nieprawidłowo, naruszone 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 w oparciu o zasady ponownego aprowizowania skonfigurowane 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.

Diagram przedstawiający sposób współdziałania aprowizacji z usługą Device Provisioning Service.

Gdy urządzenie jest początkowo aprowidowane przy użyciu wystąpienia usługi Device Provisioning Service, należy wykonać następujące kroki:

  1. 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 tego centrum IoT do urządzenia.

  2. Wystąpienie usługi aprowizacji udostępnia kopię wszystkich początkowych danych o stanie 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 są konfiguracją początkową.

Aprowizowanie za pomocą usługi Device Provisioning Service

W zależności od scenariusza, gdy urządzenie przechodzi między centrami IoT, może być również konieczne przeprowadzenie migracji stanu urządzenia zaktualizowanego w poprzednim centrum IoT do nowego centrum IoT. Ta migracja jest obsługiwana przez zasady ponownego aprowizowania w usłudze Device Provisioning.

Zasady ponownego aprowizowania

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 ponownego 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 ponownego aprowizowania. Te same zasady są dostępne dla poszczególnych rejestracji i grup rejestracji:

  • Ponowne inicjowanie obsługi i migrowanie danych: te zasady są domyślne dla nowych wpisów rejestracji. Te zasady są uruchamiane, 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 będzie zgłaszany jako Przypisywanie.

    Diagram pokazujący, że zasady podejmuje działania, gdy urządzenia skojarzone z wpisem rejestracji przesyłają nowe żądanie.

  • Ponowne aprowizowanie i resetowanie do konfiguracji początkowej: 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 będzie zgłaszany jako Przypisywanie.

    Te zasady są często używane do resetowania do ustawień fabrycznych bez zmieniania centrów IoT.

    Diagram przedstawiający sposób podejmowania akcji przez zasady, gdy urządzenia skojarzone z wpisem rejestracji przesyłają nowe żądanie aprowizacji.

  • Nigdy nie aprowizuj ponownie: urządzenie nigdy nie jest ponownie przypisywane do innego centrum. Te zasady są udostępniane na potrzeby zarządzania zgodnością z poprzednimi wersjami.

Uwaga

Usługa DPS zawsze wywołuje niestandardowy element webhook alokacji niezależnie od zasad ponownej aprowizacji w przypadku, gdy urządzenie ma nową wartość ReturnData . Jeśli zasady ponownej aprowizacji nie zostaną ustawione tak, aby nigdy nie ponownie aprowizować, 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:

Porada

Zalecamy, aby nie aprowizować przy każdym ponownym uruchomieniu urządzenia, ponieważ może to spowodować pewne problemy podczas ponownego aprowizowania kilku tysięcy lub milionów urządzeń jednocześnie. Zamiast tego należy spróbować użyć interfejsu API wyszukiwania stanu rejestracji urządzenia i spróbować połączyć się z informacjami, aby IoT Hub. Jeśli to się nie powiedzie, spróbuj ponownie aprowizacji, ponieważ informacje o IoT Hub mogły ulec zmianie. Należy pamiętać, że wykonywanie zapytań dotyczących stanu rejestracji będzie liczyć jako nową rejestrację urządzenia, dlatego należy rozważyć limit rejestracji urządzenia. Należy również rozważyć zaimplementowanie odpowiedniej logiki ponawiania, takiej jak wycofywanie wykładnicze z randomizacją, 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ć IoT Hub informacje bezpośrednio na urządzeniu, aby połączyć się bezpośrednio z IoT Hub po pierwszym zainicjowaniu obsługi administracyjnej przy użyciu usługi DPS. Jeśli zdecydujesz się to zrobić, upewnij się, że implementujesz 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 Retry-After.
  • W przypadku błędów 5xx należy użyć wycofywania wykładniczego, a pierwsza ponowna próba co najmniej 5 sekund po odpowiedzi.
  • W przypadku błędów innych niż 429 i 5xx ponownie zarejestruj się za pomocą usługi DPS
  • W idealnym przypadku należy 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ż zaplanowanie 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 do procesu 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 obsługiwane dla urządzeń zgodnie z następującymi kryteriami:

  1. 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.

  2. Wpis rejestracji dla urządzeń nie ma ustawionych zasad ponownego 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 zasady ponownego aprowizacji są ustawione, zasady ponownego aprowizacji mają pierwszeństwo przed zachowaniem. Dzięki umożliwieniu pierwszeństwa zasad ponownego aprowizacji klienci mogą aktualizować zachowanie urządzenia bez konieczności ponownego tworzenia obrazu urządzenia.

Poniższy wykres blokowy pomaga pokazać, kiedy występuje zachowanie:

wykres blokowy zgodności z poprzednimi wersjami

W poniższej tabeli przedstawiono wersje interfejsu API przed udostępnieniem 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 .NET
2018-04-01 i starsze 1.2.8 i starsze wersje 1.4.2 i starsze wersje 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 próba symbolu zastępczego, aby określić, gdzie wersje mogą być określane przez klienta i jakie będą oczekiwane wersje.

Następne kroki