Az IoT Hub eszközátépítési fogalmai
Az IoT-megoldások életciklusa során gyakori az eszközök áthelyezése az IoT Hubok között. Az áthelyezés okai közé tartozhatnak a következő forgatókönyvek:
Geolokáció/ Geolatencia: Az eszközök helyek közötti mozgása során a hálózati késés javul azáltal, hogy az eszközt egy közelebbi IoT Hubra migrálja.
Több-bérlős: Egy eszköz használható ugyanazon az IoT-megoldáson belül, és hozzárendelhető egy új ügyfélhez vagy ügyfélwebhelyhez. Előfordulhat, hogy ez az új ügyfél egy másik IoT Hub használatával lesz kiszolgálva.
Megoldás módosítása: Az eszköz áthelyezhető egy új vagy frissített IoT-megoldásba. Ez az újbóli hozzárendelés megkövetelheti, hogy az eszköz kommunikáljon egy új IoT Hubbal, amely más háttérösszetevőkhöz csatlakozik.
Karantén: Hasonló a megoldásváltozáshoz. A hibásan működő, sérült vagy elavult eszközöket hozzárendelheti egy olyan IoT Hubhoz, amely csak frissíthet, és vissza tud jutni a megfelelő helyre. Miután az eszköz megfelelően működik, a rendszer visszatelepíti a főközpontba.
A Device Provisioning Service támogatásának újraépítése kielégíti ezeket az igényeket. Az eszközök automatikusan hozzárendelhetők az új IoT Hubokhoz az eszköz regisztrációs bejegyzésében konfigurált újraépítési szabályzat alapján.
Eszközállapot-adatok
Az eszközállapot-adatok az ikereszköz és az eszköz képességeiből állnak. Ezek az adatok a Device Provisioning Service-példányban és az IoT Hubban vannak tárolva, amelyhez egy eszköz hozzá van rendelve.
Amikor egy eszköz kezdetben ki van építve egy Device Provisioning Service-példánysal, a következő lépések végrehajtására kerül sor:
Az eszköz kiépítési kérelmet küld egy Device Provisioning Service-példánynak. A szolgáltatáspéldány egy regisztrációs bejegyzés alapján hitelesíti az eszközidentitást, és létrehozza az eszközállapot-adatok kezdeti konfigurációját. A szolgáltatáspéldány a regisztrációs konfiguráció alapján hozzárendeli az eszközt egy IoT Hubhoz, és visszaadja az IoT Hub-hozzárendelést az eszköznek.
A kiépítési szolgáltatáspéldány másolatot ad a kezdeti eszközállapot-adatokról a hozzárendelt IoT Hubnak. Az eszköz csatlakozik a hozzárendelt IoT Hubhoz, és megkezdi a műveleteket.
Az IoT Hub eszközállapot-adatai idővel frissíthetők az eszközműveletekkel és a háttérműveletekkel. A Device Provisioning Service-példányban tárolt kezdeti eszközállapot-információk érintetlenek maradnak. Ezek az érintetlen eszközállapot-adatok a kezdeti konfigurációk.
A forgatókönyvtől függően, amikor egy eszköz az IoT Hubok között mozog, szükség lehet az előző IoT Hubon frissített eszközállapot áttelepítésére is az új IoT Hubra. Ezt a migrálást a Device Provisioning Service szabályzatainak újraépítése támogatja.
Szabályzatok újraépítése
A forgatókönyvtől függően az eszköz újraindításkor küldhet kérést egy kiépítési szolgáltatáspéldánynak. Emellett támogatja a kiépítés igény szerinti manuális aktiválását is. A regisztrációs bejegyzés újraépítési szabályzata határozza meg, hogy az eszközkiépítési szolgáltatáspéldány hogyan kezeli ezeket a kiépítési kéréseket. A szabályzat azt is meghatározza, hogy az eszközállapot-adatokat migrálni kell-e az újraépítés során. Ugyanezek a szabályzatok érhetők el az egyes regisztrációkhoz és regisztrációs csoportokhoz:
Adatok újbóli létrehozása és migrálása: Ez a szabályzat az új regisztrációs bejegyzések alapértelmezett beállítása. Ez a szabályzat akkor lép érvénybe, ha a regisztrációs bejegyzéshez társított eszközök új kérést küldenek (1). A regisztrációs bejegyzés konfigurációjától függően előfordulhat, hogy az eszköz egy másik IoT Hubhoz van hozzárendelve. Ha az eszköz módosítja az IoT Hubokat, a rendszer eltávolítja a kezdeti IoT Hubra való eszközregisztrációt. A kezdeti IoT Hub frissített eszközállapot-információi át lesznek migrálva az új IoT Hubra (2). A migrálás során az eszköz állapota hozzárendelésként lesz jelentve.
Újraépítés és visszaállítás a kezdeti konfigurációra: Ez a szabályzat akkor lép érvénybe, ha a regisztrációs bejegyzéshez társított eszközök új üzembe helyezési kérelmet küldenek (1). A regisztrációs bejegyzés konfigurációjától függően előfordulhat, hogy az eszköz egy másik IoT Hubhoz van hozzárendelve. Ha az eszköz módosítja az IoT Hubokat, a rendszer eltávolítja a kezdeti IoT Hubra való eszközregisztrációt. A kiépítési szolgáltatáspéldány által az eszköz üzembe helyezésekor kapott kezdeti konfigurációs adatok az új IoT Hubnak (2) lesznek megadva. A migrálás során az eszköz állapota hozzárendelésként lesz jelentve.
Ezt a szabályzatot gyakran használják az IoT Hubok módosítása nélküli gyári visszaállításhoz.
Soha ne telepítse újra: Az eszköz soha nem lesz hozzárendelve egy másik központhoz. Ez a szabályzat a visszamenőleges kompatibilitás kezelésére szolgál.
Megjegyzés:
A DPS mindig meghívja az egyéni foglalási webhookot, függetlenül az újraépítési szabályzattól, ha új ReturnData van az eszközhöz. Ha az újraépítési szabályzat úgy van beállítva, hogy soha ne térjen vissza, a rendszer meghívja a webhookot, de az eszköz nem módosítja a hozzárendelt központot.
A megoldás tervezésekor és az újraépítési logika definiálásakor érdemes megfontolni néhány szempontot. Például:
- Milyen gyakran várható, hogy az eszközök újraindulnak
- A DPS kvótái és korlátai
- A flotta várható üzembehelyezési ideje (fázisos bevezetés és egyszerre)
- Az ügyfélkódon implementált újrapróbálkoztatási képesség az Azure Architecture Center újrapróbálkozása általános útmutatójában leírtak szerint
Tipp.
Javasoljuk, hogy ne építse ki az eszköz minden újraindítását, mivel ez problémákat okozhat több ezer vagy több millió eszköz egyidejű újraépítésekor. Ehelyett próbálja meg használni az eszközregisztrációs állapotkeresési API-t, és próbáljon meg csatlakozni az IoT Hubhoz. Ha ez nem sikerül, próbálkozzon újra, mivel az IoT Hub adatai módosulhattak. Ne feledje, hogy a regisztrációs állapot lekérdezése új eszközregisztrációnak számít, ezért vegye figyelembe az eszközregisztrációs korlátot. Fontolja meg egy megfelelő újrapróbálkozási logika implementálását is, például az újrapróbálkozási általános útmutatóban leírtak szerint az exponenciális visszalépés véletlenszerűsítéssel. Bizonyos esetekben az eszköz képességeitől függően az IoT Hub adatai közvetlenül az eszközön menthetők, hogy közvetlenül az IoT Hubhoz csatlakozzanak a DPS használatával történő első üzembe helyezés után. Ha ezt választja, mindenképpen alkalmazzon tartalék mechanizmust arra az esetre, ha konkrét hibákat kap a Hubtól, például vegye figyelembe a következő forgatókönyveket:
- Próbálkozzon újra a Hub művelettel, ha az eredménykód 429 (túl sok kérelem) vagy egy hiba az 5xx tartományban. Más hibák esetében ne engedélyezze az újrapróbálkozást.
- 429-re vonatkozó hibák esetén csak az Újrapróbálkozás után fejlécben megadott idő után próbálkozzon újra.
- 5xx hibák esetén exponenciális visszatartást használjon, és az első próbálkozás legalább 5 másodperccel a válasz után történik.
- A 429-nél és az 5xx-nél nem régebbi hibáknál regisztráljon újra a DPS-en keresztül
- Ideális esetben egy olyan módszert is támogatnia kell, amely manuálisan aktiválja az igény szerinti kiépítést.
Azt is javasoljuk, hogy figyelembe vegye a szolgáltatási korlátokat olyan tevékenységek tervezésekor, mint a frissítések küldése a flottába. A flotta egyszerre történő frissítése esetén például az összes eszköz újraregisztrációt okozhat a DPS-en keresztül (ami könnyen meghaladhatja a regisztrációs kvótakorlátot) – Ilyen esetekben érdemes megfontolni az eszközfrissítések fázisokban történő tervezését a teljes flotta egyidejű frissítése helyett.
Visszamenőleges kompatibilitás kezelése
2018 szeptembere előtt az IoT Hubs-eszközök hozzárendelése ragadós viselkedést váltott ki. Amikor egy eszköz visszament a kiépítési folyamaton, az csak ugyanahhoz az IoT Hubhoz lesz hozzárendelve.
Az ilyen viselkedést függő megoldások esetében a kiépítési szolgáltatás visszamenőleges kompatibilitást is tartalmaz. Ez a viselkedés jelenleg az eszközök esetében az alábbi feltételeknek megfelelően van fenntartva:
Az eszközök a natív újraépítési támogatás rendelkezésre állása előtt csatlakoznak egy API-verzióhoz a Device Provisioning Service-ben. Tekintse meg az alábbi API-táblázatot.
Az eszközök regisztrációs bejegyzése nem rendelkezik újraépítési szabályzattal.
Ez a kompatibilitás biztosítja, hogy a korábban üzembe helyezett eszközök ugyanazt a viselkedést tapasztalják, mint a kezdeti tesztelés során. Az előző viselkedés megőrzése érdekében ne mentsen újraépítési szabályzatot ezekre a regisztrációkra. Ha egy újraépítési szabályzat be van állítva, az újraépítési szabályzat elsőbbséget élvez a viselkedéssel szemben. Ha lehetővé teszi, hogy az újraépítési szabályzat elsőbbséget élvez, az ügyfelek anélkül frissíthetik az eszköz viselkedését, hogy újra kellene létrehozniuk az eszközt.
Az alábbi folyamatábra segít megjeleníteni, hogy mikor jelenik meg a viselkedés:
Az alábbi táblázat az API-verziókat mutatja be a natív újraépítési támogatás rendelkezésre állása előtt a Device Provisioning Service-ben:
| REST API | C SDK | Python SDK | Node SDK | Java SDK | .NET SDK |
|---|---|---|---|---|---|
| 2018-04-01 és korábbi | 1.2.8 és korábbi verziók | 1.4.2 és korábbi verziók | 1.7.3 vagy korábbi | 1.13.0 vagy korábbi | 1.1.0 vagy korábbi |
Megjegyzés:
Ezek az értékek és hivatkozások valószínűleg megváltoznak. Ez csak egy helyőrzői kísérlet annak meghatározására, hogy az ügyfél hol határozhatja meg a verziókat, és hogy a várt verziók milyenek lesznek.