Eszköz-újracsatlakozások kezelése rugalmas alkalmazások létrehozásához

Cikk
10/17/2024

Ez a cikk magas szintű útmutatást nyújt a rugalmas alkalmazások tervezéséhez egy eszköz-újracsatlakozási stratégia hozzáadásával. Ez megmagyarázza, hogy miért kell leválasztani az eszközöket, és miért kell újracsatlakozni. Emellett konkrét stratégiákat ír le, amelyekkel a fejlesztők újracsatlakoztathatják a leválasztott eszközöket.

Mi okozza a leválasztást?

Az eszközök IoT Hubról való leválasztása leggyakoribb okai a következők:

Lejárt SAS-jogkivonat vagy X.509-tanúsítvány. Az eszköz SAS-jogkivonata vagy X.509 hitelesítési tanúsítványa lejárt.
Hálózatkimaradás. Az eszköz hálózati kapcsolata megszakad.
Szolgáltatáskimaradás. Az Azure IoT Hub szolgáltatás hibákat tapasztal, vagy átmenetileg nem érhető el.
Szolgáltatás-újrakonfigurálás. Az IoT Hub szolgáltatásbeállítások újrakonfigurálása után az eszközök újraépítést vagy újracsatlakozást igényelhetnek.

Miért van szükség újracsatlakozási stratégiára?

Fontos, hogy legyen stratégiája az eszközök újracsatlakoztatására az alábbi szakaszokban leírtak szerint. Újracsatlakozási stratégia nélkül negatív hatással lehet a megoldás teljesítményére, rendelkezésre állására és költségeire.

A tömeges újracsatlakozási kísérletek DDoS-t okozhatnak

A másodpercenkénti nagyszámú csatlakozási kísérlet az elosztott szolgáltatásmegtagadási támadáshoz (DDoS) hasonló állapotot okozhat. Ez a forgatókönyv a nagy, milliós nagyságrendű eszközflotta esetében releváns. A probléma túlmutathat a flottát birtokló bérlőn, és érintheti az egész skálázási egységet. Egy DDoS nagymértékben megnövelheti az Azure IoT Hub erőforrásainak költségeit, mivel a skálázásra van szükség. A DDoS az erőforráshiány miatt a megoldás teljesítményét is károsíthatja. Rosszabb esetben a DDoS szolgáltatáskimaradást okozhat.

A központ meghibásodása vagy újrakonfigurálása számos eszközt leválaszthat

Miután egy IoT Hub hibát tapasztal, vagy miután újrakonfigurálta a szolgáltatásbeállításokat egy IoT Hubon, előfordulhat, hogy az eszközök le lesznek választva. A megfelelő feladatátvételhez a leválasztott eszközök újraépítést igényelnek. A feladatátvételi lehetőségekről további információt az IoT Hub magas rendelkezésre állása és vészhelyreállítása című témakörben talál.

Sok eszköz újraépítése növelheti a költségeket

Miután az eszközök lecsatlakoztak az IoT Hubról, az optimális megoldás az eszköz újracsatlakoztatása ahelyett, hogy újra kiépíteném. Ha az IoT Hubot a DPS-vel használja, a DPS kiépítésenkénti költséggel jár. Ha sok eszközt újraépít a DPS-en, az növeli az IoT-megoldás költségeit. A DPS kiépítési költségeiről további információt az IoT Hub DPS díjszabásában talál.

Rugalmasságot szem előtt tartó tervezés

Az IoT-eszközök gyakran nem folytonos vagy instabil hálózati kapcsolatokra támaszkodnak (például GSM vagy műhold). Hibák akkor fordulhatnak elő, ha az eszközök időszakos szolgáltatás-rendelkezésre állás, infrastruktúraszintű vagy átmeneti hibák miatt kommunikálnak a felhőalapú szolgáltatásokkal. Az eszközön futó alkalmazásoknak kezelnie kell az üzenetek küldéséhez és fogadásához szükséges kapcsolati, újracsatlakozási és újrapróbálkozási logikát. Emellett az újrapróbálkozásokra vonatkozó stratégiai követelmények nagymértékben függnek az eszköz IoT-forgatókönyvétől, környezetétől és képességeitől.

Az Azure IoT Hub eszközoldali SDK-k célja, hogy leegyszerűsítse a felhőről az eszközre és az eszközről a felhőbe való kapcsolódást és kommunikációt. Ezek az SDK-k robusztus módot biztosítanak az Azure IoT Hubhoz való csatlakozásra, valamint az üzenetek küldésének és fogadásának átfogó lehetőségeire. A fejlesztők a meglévő implementációt is módosíthatják egy adott forgatókönyv jobb újrapróbálkozási stratégiájának testreszabásához.

A kapcsolatot és a megbízható üzenetküldést támogató releváns SDK-funkciók az alábbi IoT Hub-eszközoldali SDK-kban érhetők el. További információkért tekintse meg az API dokumentációját vagy az adott SDK-t:

Az alábbi szakaszok a kapcsolatot támogató SDK-funkciókat ismertetik.

Kapcsolat és újrapróbálkozás

Ez a szakasz áttekintést nyújt a kapcsolatok kezelése során elérhető újracsatlakozási és újrapróbálkozási mintákról. Részletesen ismerteti az eszközalkalmazásban egy másik újrapróbálkozási szabályzat használatára vonatkozó megvalósítási útmutatót, és felsorolja az eszköz SDK-jából származó releváns API-kat.

Hibaminták

A kapcsolati hibák több szinten is előfordulhatnak:

Hálózati hibák: leválasztott szoftvercsatorna és névfeloldási hibák
Protokollszintű hibák HTTP, AMQP és MQTT átvitel esetén: leválasztott hivatkozások vagy lejárt munkamenetek
Alkalmazásszintű hibák, amelyek helyi hibákból erednek: érvénytelen hitelesítő adatok vagy szolgáltatás viselkedése (például túllépve a kvótát vagy a szabályozást)

Az eszköz SDK-k mindhárom szinten észlelik a hibákat. Az eszközoldali SDK-k azonban nem észlelik és kezelik az operációs rendszerrel kapcsolatos hibákat és hardverhibákat. Az SDK kialakítása az Azure Architecture Center átmeneti hibakezelési útmutatóján alapul.

Újrapróbálkozási minták

Az alábbi lépések a kapcsolati hibák észlelésekor az újrapróbálkozási folyamatot írják le:

Az SDK észleli a hibát és a kapcsolódó hibát a hálózatban, a protokollban vagy az alkalmazásban.
Az SDK a hibaszűrővel határozza meg a hiba típusát, és döntse el, hogy szükség van-e újrapróbálkozásra.
Ha az SDK helyreállíthatatlan hibát azonosít, a rendszer leállítja az olyan műveleteket, mint a kapcsolat, a küldés és a fogadás. Az SDK értesíti a felhasználót. A helyreállíthatatlan hibák közé tartozik például egy hitelesítési hiba és egy hibás végponthiba.
Ha az SDK helyreállítható hibát azonosít, a megadott újrapróbálkozési szabályzatnak megfelelően újra próbálkozik, amíg a megadott időtúllépés el nem telik. Az SDK alapértelmezés szerint exponenciális visszatartást és jitter újrapróbálkozási szabályzatot használ.
Amikor a megadott időtúllépés lejár, az SDK nem próbál csatlakozni vagy küldeni. Értesíti a felhasználót.
Az SDK lehetővé teszi, hogy a felhasználó visszahívást csatoljon a kapcsolat állapotváltozásainak fogadásához.

Az SDK-k általában három újrapróbálkozési szabályzatot biztosítanak:

Exponenciális visszatartás a jitterrel: Ez az alapértelmezett újrapróbálkozási szabályzat kezdetben agresszív, és idővel lelassul, amíg el nem éri a maximális késleltetést. A kialakítás az Azure Architecture Center újrapróbálkozása alapján készült.
Egyéni újrapróbálkozás: Egyes SDK-nyelvek esetében létrehozhat egy egyéni újrapróbálkozési szabályzatot, amely jobban megfelel a forgatókönyvnek, majd beszúrhatja a RetryPolicyba. Az egyéni újrapróbálkozás nem érhető el a C SDK-n, és jelenleg nem támogatott a Python SDK-n. A Python SDK szükség szerint újracsatlakozik.
Nincs újrapróbálkozás: Az újrapróbálkozési szabályzatot "nincs újrapróbálkozás" értékre állíthatja, ami letiltja az újrapróbálkozás logikáját. Az SDK megpróbál egyszer csatlakozni, és egyszer üzenetet küld, feltéve, hogy a kapcsolat létrejött. Ezt a szabályzatot általában sávszélességgel vagy költségproblémákkal kapcsolatos forgatókönyvekben használják. Ha ezt a beállítást választja, a sikertelen üzenetek elvesznek, és nem állíthatók helyre.

Újrapróbálkoznak a szabályzat API-i

SDK	SetRetryPolicy metódus	Szabályzat-implementációk	Megvalósítási útmutató
C	IOTHUB_CLIENT_RESULT IoTHubDeviceClient_SetRetryPolicy	Lásd: IOTHUB_CLIENT_RETRY_POLICY	C implementáció
Java	SetRetryPolicy	Alapértelmezett: ExponenciálisBackoffWithJitter osztály Egyéni: a RetryPolicy felület implementálása Nincs újrapróbálkozás: NoRetry osztály	Java-implementáció
.NET	DeviceClient.SetRetryPolicy	Alapértelmezett: ExponenciálisBackoff osztály Egyéni: IRetryPolicy felület implementálása Nincs újrapróbálkozás: NoRetry osztály	C# implementáció
Csomópont	setRetryPolicy	Alapértelmezett: ExponenciálisBackoffWithJitter osztály Egyéni: a RetryPolicy felület implementálása Nincs újrapróbálkozás: NoRetry osztály	Csomópont implementálása
Python	Jelenleg nem támogatott	Jelenleg nem támogatott	Beépített kapcsolat újrapróbálkozása: Az elvetett kapcsolatokat a rendszer alapértelmezés szerint rögzített 10 másodperces időközzel próbálkozik újra. Ez a funkció igény szerint le is tiltható, és konfigurálható az időköz.

Hub újracsatlakozási folyamata

Ha csak DPS nélkül használja az IoT Hubot, használja az alábbi újracsatlakozási stratégiát.

Ha egy eszköz nem tud csatlakozni az IoT Hubhoz, vagy nem csatlakozik az IoT Hubhoz:

Használjon exponenciális visszalépést a jitter delay függvénysel.
Csatlakozzon újra az IoT Hubhoz.

Az alábbi diagram az újracsatlakozási folyamatot foglalja össze:

Az IoT Hub eszköz-újracsatlakozási folyamatának diagramja.

Hub a DPS újracsatlakozási folyamatával

Ha az IoT Hubot a DPS-vel használja, használja az alábbi újracsatlakozási stratégiát.

Ha egy eszköz nem tud csatlakozni az IoT Hubhoz, vagy nem csatlakozik az IoT Hubhoz, az alábbi esetek alapján csatlakozzon újra:

Újracsatlakozási forgatókönyv	Újracsatlakozási stratégia
Csatlakozási újrapróbálkozások engedélyezését lehetővé tevő hibák esetén (HTTP-válaszkód: 500)	Használjon exponenciális visszalépést a jitter delay függvénysel. Csatlakozzon újra az IoT Hubhoz.
Olyan hibák esetén, amelyek újrapróbálkozást jeleznek, de az újracsatlakozás 10 egymást követő alkalommal meghiúsult	Az eszköz visszaépítése a DPS-re.
Olyan hibák esetén, amelyek nem engedélyezik a kapcsolat újrapróbálkozásait (HTTP-válaszok 401, Jogosulatlan vagy 403, Tiltott vagy 404, Nem található)	Az eszköz visszaépítése a DPS-re.