Gestire le riconnessioni dei dispositivi per creare applicazioni resilienti

Articolo
04/07/2024

Questo articolo fornisce indicazioni generali per progettare applicazioni resilienti aggiungendo una strategia di riconnessione del dispositivo. Illustra il motivo per cui i dispositivi si disconnettono e devono riconnettersi. Descrive inoltre le strategie specifiche a cui gli sviluppatori possono ricorrere per riconnettere i dispositivi disconnessi.

Quali cause sono le disconnessioni

Di seguito sono riportati i motivi più comuni per cui i dispositivi si disconnettono da hub IoT:

Il token di firma di accesso condiviso o il certificato X.509 è scaduto. Il token di firma di accesso condiviso del dispositivo o il certificato di autenticazione X.509 è scaduto.
Si è verificata un'interruzione della rete. La connessione del dispositivo alla rete viene interrotta.
Interruzioni del servizio. Il servizio hub IoT di Azure riscontra errori o è temporaneamente non disponibile.
Riconfigurazione del servizio. Dopo aver riconfigurato le impostazioni del servizio hub IoT, i dispositivi possono richiedere il provisioning o la riconnessione dei dispositivi.

Perché è necessaria una strategia di riconnessione

È importante disporre di una strategia per riconnettere i dispositivi, come descritto nelle sezioni seguenti. In assenza di una strategia di riconnessione, si potrebbe notare un effetto negativo sulle prestazioni, sulla disponibilità e sui costi della soluzione.

I tentativi di riconnessione di massa potrebbero causare un DDoS

Un numero elevato di tentativi di connessione al secondo può provocare una condizione simile a un attacco Denial of Service distribuito (DDoS). Questo scenario è rilevante per grandi flotte di dispositivi che contano milioni di unità. Il problema può estendersi oltre il tenant proprietario della flotta e influire sull'intera unità di scala. Un attacco Denial of Service distribuito può comportare un aumento dei costi elevato per le risorse di hub IoT di Azure, a causa della necessità di aumentare. Un attacco Denial of Service distribuito potrebbe anche danneggiare le prestazioni della soluzione per via dell'esaurimento delle risorse. Nel peggiore dei casi, un attacco Denial of Service distribuito può causare un'interruzione del servizio.

Un errore o una riconfigurazione dell'hub potrebbe disconnettere numerosi dispositivi

Dopo che un hub IoT ha subito un errore o in seguito alla riconfigurazione delle impostazioni del servizio in un hub IoT, i dispositivi potrebbero venire disconnessi. Affinché il failover sia corretto, deve essere eseguito un nuovo provisioning dei dispositivi disconnessi. Per altre informazioni sulle opzioni di failover, vedere Disponibilità elevata e ripristino di emergenza di hub IoT.

Il reprovisioning di molti dispositivi potrebbe aumentare i costi

Dopo la disconnessione dei dispositivi da hub IoT, la soluzione ottimale consiste nel riconnettere il dispositivo, anziché eseguirne nuovamente il provisioning. Se si usa hub IoT con dps, il servizio Device Provisioning ha un costo per ogni provisioning. Se si esegue nuovamente il provisioning di numerosi dispositivi nel servizio Device Provisioning, ciò aumenta il costo della soluzione IoT. Per altre informazioni sui costi di provisioning del servizio Device Provisioning, vedere prezzi hub IoT DPS.

Progettare per la resilienza

I dispositivi IoT spesso si basano su connessioni di rete non continue o instabili ( ad esempio, GSM o satellite). Quando i dispositivi interagiscono con servizi basati sul cloud, possono verificarsi errori dovuti a una disponibilità intermittente del servizio ed errori a livello di infrastruttura o errori temporanei. Un'applicazione in esecuzione su un dispositivo deve gestire i meccanismi di connessione e riconnessione, nonché la logica di ripetizione dei tentativi per l'invio e la ricezione dei messaggi. I requisiti della strategia di ripetizione dei tentativi, inoltre, dipendono principalmente dallo scenario IoT, dal contesto e dalle funzionalità del dispositivo.

Gli Azure IoT Hub SDK per dispositivi hanno lo scopo di semplificare le connessioni e le comunicazioni da cloud a dispositivo e da dispositivo a cloud. Offrono infatti la possibilità di connettersi all'hub IoT di Azure in modo affidabile e una gamma completa di opzioni per l'invio e la ricezione di messaggi. Gli sviluppatori possono anche modificare l'implementazione esistente per personalizzare la strategia di ripetizione dei tentativi per un determinato scenario.

Le funzionalità SDK pertinenti che supportano la connettività e la messaggistica affidabile sono disponibili negli SDK per i seguenti dispositivi di hub IoT. Per altre informazioni, vedere la documentazione dell'API o l'SDK specifico:

Le seguenti sezioni descrivono le funzionalità SDK che supportano la connettività.

Connessione e ripetizione dei tentativi

Questa sezione fornisce una panoramica dei modelli di riconnessione e ripetizione dei tentativi disponibili quando si gestiscono le connessioni. Offre inoltre indicazioni di implementazione per l'uso dei vari criteri di ripetizione dei tentativi nell'applicazione per dispositivi ed elenca le API pertinenti per gli SDK per dispositivi.

Modelli di errore

Gli errori di connessione possono verificarsi a vari livelli:

Errori di rete: socket disconnesso ed errori di risoluzione dei nomi
Errori a livello di protocollo per trasporto HTTP, AMQP e MQTT: collegamenti rimossi o sessioni scadute
Errori a livello di applicazione che derivano da errori locali: credenziali non valide o comportamento anomalo del servizio (ad esempio, superamento delle quote o delle limitazioni del servizio)

Gli SDK per dispositivi sono in grado di rilevare errori in tutti e tre i livelli. Tuttavia, gli SDK dei dispositivi non rilevano e gestiscono gli errori relativi al sistema operativo e gli errori hardware. La progettazione degli SDK si basa sulle indicazioni relative alla gestione degli errori temporanei del Centro architetture di Azure.

Modelli di ripetizione dei tentativi

La procedura seguente descrive il processo di ripetizione dei tentativi quando vengono rilevati errori di connessione:

L'SDK rileva l'errore e l'errore associato nella rete, nel protocollo o nell'applicazione.
L'SDK usa il filtro degli errori per determinare il tipo di errore e determina se è necessaria una ripetizione dei tentativi.
Se l'SDK identifica un errore irreversibile, operazioni come connessione, invio e ricezione vengono arrestate. L'SDK invia una notifica all'utente. Un errore irreversibile può essere, ad esempio, un errore di autenticazione o un errore di endpoint non valido.
Se l'SDK identifica un errore reversibile, ripete i tentativi secondo i criteri di ripetizione specificati, fino alla scadenza del timeout definito. L'SDK usa il criterio di ripetizione Interruzione temporanea esponenziale con instabilità per impostazione predefinita.
Quando scade il timeout definito, l'SDK interrompe i tentativi di connessione o invio e invia una notifica all'utente.
L'SDK consente all'utente di associare un callback per ricevere le modifiche relative allo stato della connessione.

Gli SDK in genere forniscono tre criteri di ripetizione dei tentativi:

Interruzione temporanea esponenziale con instabilità: criteri di ripetizione dei tentativi predefiniti che tendono a essere aggressivi all'inizio e rallentano fino a raggiungere il ritardo massimo. La progettazione si basa sulle indicazioni relative alla ripetizione dei tentativi del Centro architetture Azure.
Ripetizione dei tentativi personalizzata: per alcuni linguaggi SDK, è possibile progettare i criteri di ripetizione dei tentativi più adatti al proprio scenario e inserirli in RetryPolicy. I tentativi personalizzati non sono disponibili in C SDK e non sono attualmente supportati in Python SDK. Python SDK si riconnette in base alle esigenze.
Nessun nuovo tentativo: è possibile impostare i criteri di ripetizione dei tentativi su "nessun nuovo tentativo", che disabilita la logica di ripetizione dei tentativi. L'SDK prova a connettersi e a inviare un messaggio una sola volta, supponendo che la connessione sia stata stabilita. Questi criteri vengono solitamente usati nei casi in cui sono presenti problemi relativi alla larghezza di banda o ai costi. Se si sceglie questa opzione, i messaggi non inviati vengono persi e non possono essere recuperati.

API dei criteri di ripetizione dei tentativi

SDK	Metodo SetRetryPolicy	Implementazioni dei criteri	Linee guida per l'implementazione
A	IOTHUB_CLIENT_RESULT IoTHubDeviceClient_SetRetryPolicy	Vedere: IOTHUB_CLIENT_RETRY_POLICY	Implementazione C
Java	SetRetryPolicy	Predefinita: classe ExponentialBackoffWithJitter Personalizzato: implementare l'interfaccia RetryPolicy Nessun tentativo: classe NoRetry	Implementazione di Java
.NET	DeviceClient.SetRetryPolicy	Predefinita: classe ExponentialBackoff Personalizzata: implementare l'interfaccia IRetryPolicy Nessun tentativo: classe NoRetry	Implementazione di C#
Nodo	setRetryPolicy	Predefinita: classe ExponentialBackoffWithJitter Personalizzata: implementare l'interfaccia RetryPolicy Nessun tentativo: classe NoRetry	Implementazione di Node
Python	Non è al momento supportato	Non è al momento supportato	Tentativi di connessione predefiniti: Per impostazione predefinita, le connessioni eliminate vengono ritentate con un intervallo fisso di 10 secondi. Questa funzionalità può essere disabilitata se necessario e l'intervallo può essere configurato.

Flusso di riconnessione dell'hub

Se si usa solo hub IoT senza il servizio Device Provisioning, ricorrere alla strategia di riconnessione seguente.

Quando un dispositivo non riesce a connettersi a hub IoT o viene disconnesso da esso:

Usare un backoff esponenziale con funzione di ritardo di instabilità.
Riconnettersi a hub IoT.

Il diagramma seguente riepiloga il flusso di riconnessione:

Diagramma del flusso di riconnessione del dispositivo per hub IoT.

Hub con il flusso di riconnessione del servizio Device Provisioning

Se si usa hub IoT con il servizio Device Provisioning, ricorrere alla strategia di riconnessione seguente.

Quando un dispositivo non riesce a connettersi a hub IoT o viene disconnesso da hub IoT, riconnettersi in base ai casi seguenti:

Scenario di riconnessione	Strategia di riconnessione
Per errori che consentono tentativi di connessione (codice di risposta HTTP 500)	Usare un backoff esponenziale con funzione di ritardo di instabilità. Riconnettersi a hub IoT.
Per gli errori che indicano un nuovo tentativo è possibile, ma la riconnessione ha avuto esito negativo 10 volte consecutivi	Effettuare nuovamente il provisioning del dispositivo nel servizio Device Provisioning.
Per gli errori che non consentono tentativi di connessione (risposte HTTP 401, Non autorizzate o 403, Accesso negato o 404, Non trovato)	Effettuare nuovamente il provisioning del dispositivo nel servizio Device Provisioning.