Koncept för ometablering av IoT Hub-enheter
Under livscykeln för en IoT-lösning är det vanligt att flytta enheter mellan IoT-hubbar. Orsakerna till den här flytten kan vara följande scenarier:
Geoplats/GeoLatency: När en enhet flyttas mellan platser förbättras nätverksfördröjningen genom att enheten migreras till en närmare IoT-hubb.
Flera innehavare: En enhet kan användas i samma IoT-lösning och omtilldelas till en ny kund eller kundwebbplats. Den här nya kunden kan betjänas med hjälp av en annan IoT-hubb.
Lösningsändring: En enhet kan flyttas till en ny eller uppdaterad IoT-lösning. Den här omtilldelningen kan kräva att enheten kommunicerar med en ny IoT-hubb som är ansluten till andra serverdelskomponenter.
Karantän: Liknar en lösningsändring. En enhet som inte fungerar, komprometteras eller är inaktuell kan omtilldelas till en IoT-hubb som bara kan uppdatera och komma tillbaka i kompatibilitet. När enheten fungerar korrekt migreras den sedan tillbaka till huvudhubben.
Ometableringsstöd inom device provisioning-tjänsten tillgodoser dessa behov. Enheter kan tilldelas om automatiskt till nya IoT-hubbar baserat på den ometableringsprincip som konfigureras på enhetens registreringspost.
Data om enhetstillstånd
Enhetstillståndsdata består av enhetstvillingen och enhetsfunktionerna. Dessa data lagras i enhetsetableringstjänstens instans och den IoT-hubb som en enhet har tilldelats till.
När en enhet först etableras med en instans av enhetsetableringstjänsten utförs följande steg:
Enheten skickar en etableringsbegäran till en instans av enhetsetableringstjänsten. Tjänstinstansen autentiserar enhetsidentiteten baserat på en registreringspost och skapar den första konfigurationen av enhetens tillståndsdata. Tjänstinstansen tilldelar enheten till en IoT-hubb baserat på registreringskonfigurationen och returnerar IoT Hub-tilldelningen till enheten.
Etableringstjänstinstansen ger en kopia av alla initiala enhetstillståndsdata till den tilldelade IoT-hubben. Enheten ansluter till den tilldelade IoT-hubben och påbörjar åtgärder.
Med tiden kan enhetstillståndsdata på IoT-hubben uppdateras av enhetsåtgärder och backend-åtgärder. Den initiala informationen om enhetstillståndet som lagras i instansen av enhetsetableringstjänsten förblir orörd. Dessa orörda enhetstillståndsdata är den inledande konfigurationen.
Beroende på scenariot kan det också vara nödvändigt att migrera enhetstillståndet som uppdaterades på den tidigare IoT-hubben till den nya IoT-hubben när en enhet flyttas mellan IoT-hubbar. Den här migreringen stöds av ometableringsprinciper i enhetsetableringstjänsten.
Ometablera principer
Beroende på scenariot kan en enhet skicka en begäran till en etableringstjänstinstans vid omstart. Den stöder också en metod för att manuellt utlösa etablering på begäran. Ometableringsprincipen för en registreringspost avgör hur instansen av enhetsetableringstjänsten hanterar dessa etableringsbegäranden. Principen avgör också om enhetstillståndsdata ska migreras under ometablering. Samma principer är tillgängliga för enskilda registreringar och registreringsgrupper:
Återskapa och migrera data: Den här principen är standard för nya registreringsposter. Den här principen vidtar åtgärder när enheter som är associerade med registreringsposten skickar en ny begäran (1). Beroende på konfigurationen av registreringsposten kan enheten omtilldelas till en annan IoT-hubb. Om enheten ändrar IoT-hubbar tas enhetsregistreringen med den första IoT-hubben bort. Den uppdaterade informationen om enhetstillståndet från den första IoT-hubben migreras till den nya IoT-hubben (2). Under migreringen rapporteras enhetens status som Tilldelning.
Ometablera och återställa till den första konfigurationen: Den här principen vidtar åtgärder när enheter som är associerade med registreringsposten skickar en ny etableringsbegäran (1). Beroende på konfigurationen av registreringsposten kan enheten omtilldelas till en annan IoT-hubb. Om enheten ändrar IoT-hubbar tas enhetsregistreringen med den första IoT-hubben bort. De första konfigurationsdata som etableringstjänstinstansen tog emot när enheten etablerades tillhandahålls till den nya IoT-hubben (2). Under migreringen rapporteras enhetens status som Tilldelning.
Den här principen används ofta för en fabriksåterställning utan att ändra IoT-hubbar.
Återskapa aldrig: Enheten tilldelas aldrig om till en annan hubb. Den här principen tillhandahålls för att hantera bakåtkompatibilitet.
Kommentar
DPS anropar alltid webhooken för anpassad allokering oavsett om du etablerar principen om det finns nya ReturnData för enheten. Om återetableringsprincipen är inställd på att aldrig återskapas anropas webhooken, men enheten ändrar inte sin tilldelade hubb.
När du utformar din lösning och definierar en ometableringslogik finns det några saker att tänka på. Till exempel:
- Hur ofta du förväntar dig att dina enheter ska startas om
- DPS-kvoter och -gränser
- Förväntad distributionstid för din flotta (stegvis distribution jämfört med alla på en gång)
- Återförsöksfunktion implementerad på klientkoden enligt beskrivningen i den allmänna vägledningen om återförsök i Azure Architecture Center
Dricks
Vi rekommenderar att du inte etablerar varje omstart av enheten eftersom det kan orsaka vissa problem när flera tusentals eller miljontals enheter etableras samtidigt. I stället bör du försöka använda API:et för enhetsregistreringsstatussökning och försöka ansluta med den informationen till IoT Hub. Om det misslyckas kan du försöka återskapa eftersom IoT Hub-informationen kan ha ändrats. Tänk på att frågan om registreringstillståndet räknas som en ny enhetsregistrering, så du bör överväga gränsen för enhetsregistrering. Överväg också att implementera en lämplig logik för återförsök, till exempel exponentiell säkerhetskopiering med slumpmässighet, enligt beskrivningen i allmänna riktlinjer för återförsök. I vissa fall, beroende på enhetsfunktionerna, är det möjligt att spara IoT Hub-informationen direkt på enheten för att ansluta direkt till IoT Hub efter att den första etableringen med DPS inträffade. Om du väljer att göra detta kontrollerar du att du implementerar en återställningsmekanism om du får specifika fel från hubben, till exempel bör du överväga följande scenarier:
- Försök utföra hubbåtgärden igen om resultatkoden är 429 (för många begäranden) eller ett fel i 5xx-intervallet. Gör inga nya försök för andra fel.
- För 429-fel försöker du bara igen efter den tid som anges i återförsökshuvudet.
- För 5xx-fel använder du exponentiell säkerhetskopiering, med det första återförsöket minst 5 sekunder efter svaret.
- Vid andra fel än 429 och 5xx registrerar du igen via DPS
- Helst bör du också ha stöd för en metod för att manuellt utlösa etablering på begäran.
Vi rekommenderar också att du tar hänsyn till tjänstbegränsningarna när du planerar aktiviteter som att push-överföra uppdateringar till din flotta. Om du till exempel uppdaterar flottan på en gång kan det leda till att alla enheter registreras igen via DPS (vilket lätt kan ligga över registreringskvotgränsen) – För sådana scenarier bör du överväga att planera för enhetsuppdateringar i faser i stället för att uppdatera hela flottan samtidigt.
Hantera bakåtkompatibilitet
Före september 2018 hade enhetstilldelningar till IoT-hubbar ett fast beteende. När en enhet gick tillbaka genom etableringsprocessen skulle den bara tilldelas tillbaka till samma IoT-hubb.
För lösningar som har varit beroende av det här beteendet innehåller etableringstjänsten bakåtkompatibilitet. Det här beteendet underhålls för närvarande för enheter enligt följande kriterier:
Enheterna ansluter med en API-version innan det finns inbyggt återetableringsstöd i Enhetsetableringstjänsten. Se API-tabellen nedan.
Registreringsposten för enheterna har ingen princip för ometablering inställd på dem.
Den här kompatibiliteten säkerställer att tidigare distribuerade enheter har samma beteende som under den första testningen. Spara inte en återetableringsprincip för dessa registreringar för att bevara det tidigare beteendet. Om en ometableringsprincip har angetts har återetableringsprincipen företräde framför beteendet. Genom att låta principen för ometablering ha företräde kan kunderna uppdatera enhetens beteende utan att behöva återskapa enheten.
Följande flödesdiagram hjälper till att visa när beteendet finns:
I följande tabell visas API-versionerna före tillgängligheten för inbyggt återetableringsstöd i Device Provisioning Service:
| REST-API | C SDK | Python SDK | SDK för Node | Java SDK | .NET SDK |
|---|---|---|---|---|---|
| 2018-04-01 och tidigare | 1.2.8 och tidigare | 1.4.2 och tidigare | 1.7.3 eller tidigare | 1.13.0 eller tidigare | 1.1.0 eller tidigare |
Kommentar
Dessa värden och länkar kommer sannolikt att ändras. Detta är bara ett platshållarförsök för att avgöra var versionerna kan fastställas av en kund och vilka de förväntade versionerna kommer att vara.