Hantera enhetsåteranslutningar för att skapa motståndskraftiga program

Artikel
10/17/2024

Den här artikeln innehåller vägledning på hög nivå som hjälper dig att utforma motståndskraftiga program genom att lägga till en strategi för återanslutning av enheter. Det förklarar varför enheter kopplas från och behöver återansluta. Och den beskriver specifika strategier som utvecklare kan använda för att återansluta enheter som har kopplats från.

Vad orsakar frånkopplingar

Följande är de vanligaste orsakerna till att enheter kopplar från IoT Hub:

SAS-token eller X.509-certifikat har upphört att gälla. Enhetens SAS-token eller X.509-autentiseringscertifikat har upphört att gälla.
Nätverksavbrott. Enhetens anslutning till nätverket avbryts.
Avbrott i tjänsten. Azure IoT Hub-tjänsten upplever fel eller är tillfälligt otillgänglig.
Omkonfiguration av tjänsten. När du har konfigurerat om inställningarna för IoT Hub-tjänsten kan det leda till att enheterna behöver återskapas eller återanslutas.

Varför du behöver en återanslutningsstrategi

Det är viktigt att ha en strategi för att återansluta enheter enligt beskrivningen i följande avsnitt. Utan en återanslutningsstrategi kan du se en negativ effekt på lösningens prestanda, tillgänglighet och kostnad.

Massåteranslutningsförsök kan orsaka en DDoS

Ett stort antal anslutningsförsök per sekund kan orsaka ett villkor som liknar en distribuerad överbelastningsattack (DDoS). Det här scenariot är relevant för stora uppsättningar av enheter på miljonnivå. Problemet kan sträcka sig utanför den klientorganisation som äger uppsättningen och påverka hela skalningsenheten. En DDoS kan orsaka en stor kostnadsökning för dina Azure IoT Hub-resurser på grund av ett behov av att skala ut. En DDoS kan också skada lösningens prestanda på grund av resurssvält. I värsta fall kan en DDoS orsaka avbrott i tjänsten.

Hubbfel eller omkonfiguration kan koppla från många enheter

När en IoT-hubb har råträffat ett fel, eller när du har konfigurerat om tjänstinställningarna på en IoT-hubb, kan enheterna kopplas från. För korrekt redundans kräver frånkopplade enheter ometablering. Mer information om redundansalternativ finns i Hög tillgänglighet och haveriberedskap för IoT Hub.

Om du återskapar många enheter kan kostnaderna öka

När enheterna har kopplats från IoT Hub är den optimala lösningen att återansluta enheten i stället för att återskapa den. Om du använder IoT Hub med DPS har DPS en kostnad per etablering. Om du etablerar om många enheter på DPS ökar kostnaden för din IoT-lösning. Mer information om DPS-etableringskostnader finns i IoT Hub DPS-priser.

Designa för elasticitet

IoT-enheter förlitar sig ofta på icke-kontinuerliga eller instabila nätverksanslutningar (till exempel GSM eller satellit). Fel kan uppstå när enheter interagerar med molnbaserade tjänster på grund av tillfällig tjänsttillgänglighet och infrastrukturnivå eller tillfälliga fel. Ett program som körs på en enhet måste hantera mekanismerna för anslutning, återanslutning och logiken för återförsök för att skicka och ta emot meddelanden. Kraven på återförsöksstrategi är också starkt beroende av enhetens IoT-scenario, kontext och funktioner.

Azure IoT Hub-enhetens SDK:er syftar till att förenkla anslutning och kommunikation från moln till enhet och från enhet till moln. Dessa SDK:er är ett robust sätt att ansluta till Azure IoT Hub och en omfattande uppsättning alternativ för att skicka och ta emot meddelanden. Utvecklare kan också ändra befintlig implementering för att anpassa en bättre återförsöksstrategi för ett visst scenario.

Relevanta SDK-funktioner som stöder anslutning och tillförlitliga meddelanden finns tillgängliga i följande IoT Hub-enhets-SDK:er. Mer information finns i API-dokumentationen eller specifika SDK:

I följande avsnitt beskrivs SDK-funktioner som stöder anslutning.

Anslutning och försök igen

Det här avsnittet ger en översikt över de återanslutnings- och återförsöksmönster som är tillgängliga när du hanterar anslutningar. Den beskriver implementeringsvägledningen för att använda en annan återförsöksprincip i ditt enhetsprogram och visar relevanta API:er från enhetens SDK:er.

Felmönster

Anslutningsfel kan inträffa på många nivåer:

Nätverksfel: frånkopplade socket- och namnmatchningsfel
Fel på protokollnivå för HTTP-, AMQP- och MQTT-transport: frånkopplade länkar eller utgångna sessioner
Fel på programnivå som beror på lokala misstag: ogiltiga autentiseringsuppgifter eller tjänstbeteende (till exempel överskrider kvoten eller begränsningen)

Enhets-SDK:erna identifierar fel på alla tre nivåerna. Enhets-SDK:er identifierar och hanterar dock inte OS-relaterade fel och maskinvarufel. SDK-designen baseras på vägledningen för tillfällig felhantering från Azure Architecture Center.

Återförsöksmönster

Följande steg beskriver återförsöksprocessen när anslutningsfel identifieras:

SDK identifierar felet och det associerade felet i nätverket, protokollet eller programmet.
SDK använder felfiltret för att fastställa feltypen och avgöra om ett nytt försök behövs.
Om SDK identifierar ett oåterkalleligt fel stoppas åtgärder som anslutning, sändning och mottagning. SDK:et meddelar användaren. Exempel på oåterkalleliga fel är ett autentiseringsfel och ett felaktigt slutpunktsfel.
Om SDK identifierar ett återställningsbart fel försöker det igen enligt den angivna återförsöksprincipen tills den definierade tidsgränsen förflutit. SDK använder exponentiell back-off med jitter retry policy som standard.
När den definierade tidsgränsen upphör att gälla slutar SDK:n att försöka ansluta eller skicka. Det meddelar användaren.
Med SDK kan användaren koppla ett återanrop för att ta emot ändringar i anslutningsstatusen.

SDK:erna tillhandahåller vanligtvis tre återförsöksprinciper:

Exponentiell back-off med jitter: Den här standardprincipen för återförsök tenderar att vara aggressiv i början och sakta ner med tiden tills den når en maximal fördröjning. Designen baseras på vägledning om återförsök från Azure Architecture Center.
Anpassat återförsök: För vissa SDK-språk kan du utforma en anpassad återförsöksprincip som passar bättre för ditt scenario och sedan mata in den i RetryPolicy. Det anpassade återförsöket är inte tillgängligt i C SDK och stöds för närvarande inte i Python SDK. Python SDK återansluter efter behov.
Inget nytt försök: Du kan ange återförsöksprincipen till "inget nytt försök", vilket inaktiverar logiken för återförsök. SDK:et försöker ansluta en gång och skicka ett meddelande en gång, förutsatt att anslutningen har upprättats. Den här principen används vanligtvis i scenarier med bandbredds- eller kostnadsproblem. Om du väljer det här alternativet går meddelanden som inte skickas förlorade och kan inte återställas.

API:er för återförsöksprincip

SDK	SetRetryPolicy-metod	Principimplementeringar	Riktlinjer för implementering
C	IOTHUB_CLIENT_RESULT IoTHubDeviceClient_SetRetryPolicy	Se: IOTHUB_CLIENT_RETRY_POLICY	C-implementering
Java	SetRetryPolicy	Standard: Klassen ExponentialBackoffWithJitter Anpassad: implementera RetryPolicy-gränssnitt Inget nytt försök: NoRetry-klass	Java-implementering
.NET	DeviceClient.SetRetryPolicy	Standard: ExponentialBackoff-klass Anpassad: implementera IRetryPolicy-gränssnitt Inget nytt försök: NoRetry-klass	C#-implementering
Nod	setRetryPolicy	Standard: Klassen ExponentialBackoffWithJitter Anpassad: implementera RetryPolicy-gränssnitt Inget nytt försök: NoRetry-klass	Nodimplementering
Python	Stöds för närvarande inte	Stöds för närvarande inte	Inbyggda anslutningsförsök: Borttagna anslutningar görs igen med ett fast intervall på 10 sekunder som standard. Den här funktionen kan inaktiveras om du vill och intervallet kan konfigureras.

Hubbåteranslutningsflöde

Om du endast använder IoT Hub utan DPS använder du följande återanslutningsstrategi.

När en enhet inte kan ansluta till IoT Hub eller är frånkopplad från IoT Hub:

Använd en exponentiell back-off med funktionen för jitterfördröjning.
Återanslut till IoT Hub.

Följande diagram sammanfattar återanslutningsflödet:

Diagram över flödet för återanslutning av enheter för IoT Hub.

Hubb med DPS-återanslutningsflöde

Om du använder IoT Hub med DPS använder du följande återanslutningsstrategi.

När en enhet inte kan ansluta till IoT Hub, eller om den är frånkopplad från IoT Hub, återansluter du baserat på följande fall:

Scenario för återanslutning	Återanslutningsstrategi
För fel som tillåter anslutningsförsök (HTTP-svarskod 500)	Använd en exponentiell back-off med funktionen för jitterfördröjning. Återanslut till IoT Hub.
För fel som indikerar att ett nytt försök är möjligt, men återanslutningen har misslyckats 10 gånger i rad	Återskapa enheten till DPS.
För fel som inte tillåter anslutningsförsök (HTTP-svar 401, Obehörig eller 403, Förbjuden eller 404, Hittades inte)	Återskapa enheten till DPS.