Správa opětovného připojení zařízení za účelem vytvoření odolných aplikací

Článek
04/07/2024

Tento článek obsahuje základní pokyny, které vám pomůžou navrhnout odolné aplikace přidáním strategie opětovného připojení zařízení. Vysvětluje, proč se zařízení odpojí a potřebují se znovu připojit. Popisuje konkrétní strategie, které můžou vývojáři použít k opětovnému připojení zařízení, která byla odpojena.

Co způsobuje odpojení

Tady jsou nejčastější důvody, proč se zařízení odpojí od IoT Hubu:

Platnost tokenu SAS nebo certifikátu X.509 vypršela. Platnost tokenu SAS zařízení nebo ověřovacího certifikátu X.509 vypršela.
Přerušení sítě Připojení zařízení k síti se přeruší.
Přerušení služeb U služby Azure IoT Hub dochází k chybám nebo je dočasně nedostupný.
Rekonfigurace služby Po změně konfigurace nastavení služby IoT Hub to může způsobit, že zařízení budou vyžadovat opětovné zřízení nebo opětovné připojení.

Proč potřebujete strategii opětovného připojení

Je důležité mít strategii opětovného připojení zařízení, jak je popsáno v následujících částech. Bez strategie opětovného připojení můžete vidět negativní vliv na výkon, dostupnost a náklady vašeho řešení.

Hromadné pokusy o opětovné připojení můžou způsobit útoky DDoS

Velký počet pokusů o připojení za sekundu může způsobit stav podobný distribuovanému útoku do služby (DDoS). Tento scénář je relevantní pro velké flotily zařízení, která se číslují v milionech. Tento problém může přesahovat tenanta, který vlastní flotilu, a ovlivnit celou jednotku škálování. Služba DDoS může zvýšit velké náklady na prostředky Azure IoT Hubu kvůli nutnosti horizontálního navýšení kapacity. Služba DDoS může také poškodit výkon vašeho řešení kvůli hladovění prostředků. V horším případě může DDoS způsobit přerušení služby.

Selhání centra nebo změna konfigurace můžou odpojit mnoho zařízení

Po selhání centra IoT nebo po změně konfigurace nastavení služby v centru IoT se můžou zařízení odpojit. Pro správné převzetí služeb při selhání vyžadují odpojená zařízení opětovné zřízení. Další informace o možnostech převzetí služeb při selhání najdete v tématu Vysoká dostupnost a zotavení po havárii ve službě IoT Hub.

Opětovné zřízení mnoha zařízení může zvýšit náklady

Po odpojení zařízení od IoT Hubu je optimálním řešením znovu připojit zařízení, nikoli znovu vytvořit. Pokud používáte IoT Hub se službou DPS, služba DPS má náklady na zřízení. Pokud v DPS znovu vytvoříte mnoho zařízení, zvýší se náklady na vaše řešení IoT. Další informace o nákladech na zřizování DPS najdete v tématu o cenách služby IoT Hub DPS.

Návrh pro odolnost

Zařízení IoT často spoléhají na nekontinuá nebo nestabilní síťová připojení (například GSM nebo satelit). K chybám může dojít v případě, že zařízení komunikují s cloudovými službami kvůli přerušované dostupnosti služeb a přechodným chybám na úrovni infrastruktury nebo přechodným chybám. Aplikace, která běží na zařízení, musí spravovat mechanismy připojení, opětovného připojení a logiky opakování pro odesílání a přijímání zpráv. Požadavky na strategii opakování také závisí hodně na scénáři IoT, kontextu a možnostech zařízení.

Sady SDK pro zařízení služby Azure IoT Hub mají za cíl zjednodušit připojení a komunikaci z cloudu na zařízení a zařízení do cloudu. Tyto sady SDK poskytují robustní způsob připojení ke službě Azure IoT Hub a komplexní sadu možností pro odesílání a přijímání zpráv. Vývojáři mohou také upravit existující implementaci a přizpůsobit tak lepší strategii opakování pro daný scénář.

Příslušné funkce sady SDK, které podporují připojení a spolehlivé zasílání zpráv, jsou k dispozici v následujících sadách SDK pro zařízení služby IoT Hub. Další informace najdete v dokumentaci k rozhraní API nebo konkrétní sadě SDK:

Následující části popisují funkce sady SDK, které podporují připojení.

Připojení ion a opakování

Tato část poskytuje přehled schémat opětovného připojení a opakování dostupných při správě připojení. Podrobně popisuje pokyny k implementaci pro použití různých zásad opakování v aplikaci zařízení a uvádí příslušná rozhraní API ze sad SDK zařízení.

Vzory chyb

Připojení selhání může nastat na mnoha úrovních:

Chyby sítě: Chyby odpojeného soketu a překladu ip adres
Chyby na úrovni protokolu pro přenos HTTP, AMQP a MQTT: odpojené odkazy nebo relace s vypršenou platností
Chyby na úrovni aplikace, které vyplývají z místních chyb: neplatné přihlašovací údaje nebo chování služby (například překročení kvóty nebo omezování)

Sady SDK zařízení detekují chyby na všech třech úrovních. Sady SDK zařízení ale nezjišťují a zpracovávají chyby související s operačním systémem a chyby hardwaru. Návrh sady SDK je založený na doprovodných materiálech pro zpracování přechodných chyb z Centra architektury Azure.

Modely opakování

Následující kroky popisují proces opakování při zjištění chyb připojení:

Sada SDK zjistí chybu a přidruženou chybu v síti, protokolu nebo aplikaci.
Sada SDK pomocí filtru chyb určí typ chyby a rozhodne, jestli je potřeba provést opakování.
Pokud sada SDK identifikuje neopravitelnou chybu, zastaví se operace, jako je připojení, odesílání a příjem. Sada SDK uživatele upozorní. Mezi příklady neopravitelných chyb patří chyba ověřování a chybná chyba koncového bodu.
Pokud sada SDK identifikuje obnovitelnou chybu, opakuje se podle zadaných zásad opakování, dokud neuplyne definovaný časový limit. Sada SDK ve výchozím nastavení používá exponenciální back-off se zásadou opakování jitter .
Když vyprší definovaný časový limit, sada SDK se přestane pokoušet připojit nebo odeslat. Upozorní uživatele.
Sada SDK umožňuje uživateli připojit zpětné volání pro příjem změn stavu připojení.

Sady SDK obvykle poskytují tři zásady opakování:

Exponenciální zpět s jitterem: Tato výchozí zásada opakování bývá na začátku agresivní a zpomaluje se v průběhu času, dokud nedosáhne maximálního zpoždění. Návrh vychází z pokynů k opakování centra architektury Azure.
Vlastní opakování: U některých jazyků sady SDK můžete navrhnout vlastní zásadu opakování, která je pro váš scénář vhodnější, a pak ji vložit do zásady opakování. Vlastní opakování není dostupné v sadě C SDK a v současné době není podporováno v sadě Python SDK. Sada Python SDK se podle potřeby znovu připojí.
Žádné opakování: Zásady opakování můžete nastavit na "bez opakování", což zakáže logiku opakování. Sada SDK se pokusí připojit jednou a jednou odeslat zprávu za předpokladu, že je připojení navázáno. Tyto zásady se obvykle používají ve scénářích se obavami o šířku pásma nebo náklady. Pokud zvolíte tuto možnost, zprávy, které se neposílají, budou ztraceny a nelze je obnovit.

Rozhraní API zásad opakování

Sada SDK	Metoda SetRetryPolicy	Implementace zásad	Průvodce implementací
C	IOTHUB_CLIENT_RESULT IoTHubDeviceClient_SetRetryPolicy	Viz: IOTHUB_CLIENT_RETRY_POLICY	Implementace jazyka C
Java	SetRetryPolicy	Výchozí: ExponentialBackoffWithJitter – třída Vlastní: Implementace rozhraní RetryPolicy Žádná třída retry:NoRetry	Implementace Javy
.NET	DeviceClient.SetRetryPolicy	Výchozí: ExponentialBackoff – třída Vlastní: Implementace rozhraní IRetryPolicy Žádná třída retry:NoRetry	Implementace jazyka C#
Uzel	setRetryPolicy	Výchozí: ExponentialBackoffWithJitter – třída Vlastní: Implementace rozhraní RetryPolicy Žádná třída retry:NoRetry	Implementace uzlu
Python	V současnosti není podporováno	V současnosti není podporováno	Předdefinované opakování připojení: Vyřazená připojení se ve výchozím nastavení opakuje s pevným 10sekundovým intervalem. Tuto funkci je možné v případě potřeby zakázat a interval je možné nakonfigurovat.

Tok opětovného připojení centra

Pokud ioT Hub používáte jenom bez DPS, použijte následující strategii opětovného připojení.

Pokud se zařízení nepodaří připojit ke službě IoT Hub nebo se odpojí od IoT Hubu:

Použití exponenciálního zpětného vypnutí s funkcí zpoždění.
Znovu se připojte ke službě IoT Hub.

Následující diagram shrnuje tok opětovného připojení:

Diagram toku opětovného připojení zařízení pro IoT Hub

Centrum s tokem opětovného připojení DPS

Pokud používáte IoT Hub se službou DPS, použijte následující strategii opětovného připojení.

Pokud se zařízení nepodaří připojit ke službě IoT Hub nebo se odpojí od služby IoT Hub, znovu se připojte v závislosti na následujících případech:

Scénář opětovného připojení	Strategie opětovného připojení
Chyby, které umožňují opakování připojení (kód odpovědi HTTP 500)	Použití exponenciálního zpětného vypnutí s funkcí zpoždění. Znovu se připojte ke službě IoT Hub.
Chyby, které značí, že opakování je možné, ale opětovné připojení selhalo 10 po sobě jdoucíchkrát	Znovu zřazení zařízení do DPS
Chyby, které neumožňují opakování připojení (odpovědi HTTP 401, Neautorizováno nebo 403, Zakázáno nebo 404, Nenalezené)	Znovu zřazení zařízení do DPS