Disponibilità elevata e ripristino di emergenza dell'hub IoT

Come primo passaggio verso l'implementazione di una soluzione IoT resiliente, architetti, sviluppatori e proprietari di aziende devono definire gli obiettivi dei tempi di attività per le soluzioni che stanno costruendo. Questi obiettivi possono essere definiti principalmente in base a obiettivi di business specifici per ogni scenario di base. In questo contesto, l'articolo Informazioni tecniche sulla continuità aziendale Azure descrive un contesto generale per aiutare a pensare alla continuità aziendale e al ripristino di emergenza. Il documento Ripristino di emergenza e disponibilità elevata per le applicazioni Azure fornisce informazioni sull'architettura nelle strategie per consentire alle applicazioni di Azure di ottenere disponibilità elevata e ripristino di emergenza.

Questo articolo illustra le funzionalità di disponibilità elevata e ripristino di emergenza offerte in modo specifico dal servizio IoT Hub. Le aree generali illustrate in questo articolo sono:

• Disponibilità elevata intra-area
• Ripristino di emergenza tra aree
• Ottenere disponibilità elevata tra aree

A seconda degli obiettivi di tempo di attività definiti per le soluzioni IoT, è necessario determinare le opzioni descritte in questo articolo più adatte agli obiettivi aziendali. L'inclusione di una delle alternative tra disponibilità elevata e ripristino di emergenza nella soluzione IoT richiede un'attenta valutazione dei compromessi tra il:

• Livello di resilienza desiderata
• Complessità di implementazione e manutenzione
• Impatto COGS

Disponibilità elevata intra-area

Il servizio Hub IoT fornisce disponibilità elevata intra-area tramite l'implementazione delle ridondanze in quasi tutti i livelli di servizio. Il Contratto di servizio pubblicato dal servizio Hub IoT è realizzato sfruttando queste ridondanze. Gli sviluppatori di una soluzione IoT non richiedono alcun lavoro aggiuntivo per sfruttare queste funzionalità a disponibilità elevata. Anche se l'Hub IoT offre una garanzia di tempo di attività relativamente elevata, sono comunque attesi errori temporanei come in una qualsiasi piattaforma di elaborazione distribuita. Se si è appena iniziato a eseguire la migrazione delle soluzioni al cloud da una soluzione locale, l'attenzione deve passare dall'ottimizzazione del "tempo medio tra gli errori" al "tempo medio per il ripristino". In altre parole, gli errori temporanei sono considerati normali quando si opera con il cloud in combinazione. I modelli di ripetizione appropriati devono essere compilati nei componenti che interagiscono con un'applicazione cloud per gestire gli errori temporanei.

Zone di disponibilità

hub IoT supporta Zone di disponibilità di Azure. Una zona di disponibilità è un'offerta a disponibilità elevata che protegge le applicazioni e i dati da errori del data center. Un'area con supporto per la zona di disponibilità comprende tre zone che supportano tale area. Ogni zona fornisce uno o più data center, ognuno in una posizione fisica univoca con alimentazione, raffreddamento e rete indipendenti. Questa configurazione fornisce la replica e la ridondanza all'interno dell'area.

Le zone di disponibilità offrono due vantaggi: resilienza dei dati e distribuzioni più fluide.

La resilienza dei dati deriva dalla sostituzione dei servizi di archiviazione sottostanti con l'archiviazione supportata dalle zone di disponibilità. La resilienza dei dati è importante per le soluzioni IoT perché queste soluzioni spesso operano in ambienti complessi, dinamici e incerti in cui gli errori o le interruzioni possono avere conseguenze significative. Indipendentemente dal fatto che una soluzione IoT supporti ambienti di produzione, vendita al dettaglio o ristorante, sistemi sanitari o infrastruttura, la disponibilità e la qualità dei dati è necessaria per il ripristino da errori e per fornire servizi affidabili e coerenti.

Le distribuzioni più fluide provengono dalla sostituzione dell'hardware del data center sottostante con hardware più recente che supporta le zone di disponibilità. Questi miglioramenti hardware riducono al minimo l'impatto dei clienti sulle disconnessioni dei dispositivi e sulle riconnessioni e altri tempi di inattività correlati alla distribuzione. Il team di progettazione hub IoT distribuisce più aggiornamenti a ogni hub IoT ogni mese, sia per motivi di sicurezza che per fornire miglioramenti delle funzionalità. L'hardware supportato dalle zone di disponibilità è suddiviso in 15 domini di aggiornamento in modo che ogni aggiornamento sia più fluido, con un impatto minimo per i flussi di lavoro. Per altre informazioni sui domini di aggiornamento, vedere Set di disponibilità.

Il supporto della zona di disponibilità per hub IoT viene abilitato automaticamente per le nuove risorse hub IoT create nelle aree di Azure seguenti:

Paese	Resilienza dei dati	Distribuzioni più fluide
Australia orientale
Brasile meridionale
Canada centrale
India centrale
Stati Uniti centrali
Stati Uniti orientali
Francia centrale
Germania centro-occidentale
Giappone orientale
Corea centrale
Europa settentrionale
Norvegia orientale
Qatar centrale
Stati Uniti meridionali
Asia sud-orientale
Regno Unito meridionale
Europa occidentale
West US 2
Stati Uniti occidentali 3

Ripristino di emergenza tra aree

Potrebbero esserci alcune rare situazioni in cui un data center subisce interruzioni prolungate a causa di interruzioni dell'alimentazione o altri guasti che coinvolgono risorse fisiche. Tali eventi sono rari durante i quali la funzionalità a disponibilità elevata all'interno dell'area descritta in precedenza potrebbe non essere sempre utile. L'Hub IoT offre diverse soluzioni per il ripristino da tali interruzioni estese.

Le opzioni di ripristino disponibili per i clienti in una situazione di questo tipo sono failover avviato da Microsoft e failover manuale. La differenza fondamentale tra i due è che Microsoft avvia il primo mentre l'ultimo è avviato dall'utente. Inoltre, il failover manuale fornisce un obiettivo di recupero inferiore (RTO) rispetto all'opzione di failover avviato da Microsoft. Le specifiche RTO offerte con ogni opzione sono descritte nelle sezioni seguenti. Quando viene eseguita una di queste opzioni per effettuare il failover di un Hub IoT dalla sua area principale, l'Hub diventa pienamente funzionante nella corrispondente area geografica di Azure abbinata.

Entrambe queste opzioni di failover offrono gli obiettivi del punto di ripristino (RPO) seguenti:

¹I messaggi da cloud a dispositivo e i processi padre non vengono recuperati come parte del failover manuale.

Una volta completata l'operazione di failover per l'Hub IoT, tutte le operazioni dal dispositivo e dalle applicazioni di back-end continueranno a funzionare senza richiedere un intervento manuale. Ciò significa che i messaggi da dispositivo a cloud devono continuare a funzionare e l'intero registro dei dispositivi è intatto. Gli eventi generati tramite Griglia di eventi possono essere utilizzati tramite le stesse sottoscrizioni configurate in precedenza, purché tali sottoscrizioni di Griglia di eventi continuino a essere disponibili. Non è necessaria alcuna gestione aggiuntiva per gli endpoint personalizzati.

Failover avviato da Microsoft

Il failover avviato da Microsoft viene eseguito da Microsoft in rare situazioni per eseguire il failover di tutti gli hub IoT da un'area interessata all'area geografica associata corrispondente. Questo processo è un'opzione predefinita e non richiede alcun intervento da parte dell'utente. Microsoft si riserva il diritto di effettuare una determinazione di quando questa opzione viene esercitata. Questo meccanismo non implica il consenso dell'utente prima che l'Hub dell'utente eseguito il failover. Il failover avviato da Microsoft ha un obiettivo di ripristino (RTO) di 2-26 ore.

L'obiettivo RTO è di grandi dimensioni poiché Microsoft deve eseguire l'operazione di failover per conto di tutti i clienti interessati in tale area. Se si esegue una soluzione IoT meno critica che può sostenere un tempo di inattività di circa un giorno, è possibile adottare una dipendenza da questa opzione per soddisfare gli obiettivi generali di ripristino di emergenza per la soluzione IoT. Il tempo totale per cui le operazioni di runtime diventano pienamente operative una volta che questo processo è stato attivato, è descritto nella sezione "Tempo di ripristino".

Solo gli utenti che distribuiscono hub IoT nelle aree Brasile meridionale e Asia sud-orientale (Singapore) possono rifiutare esplicitamente questa funzionalità. Per altre informazioni, vedere Disabilitare il ripristino di emergenza.

Failover manuale

Se gli obiettivi del tempo di attività aziendale non sono soddisfatti dall'obiettivo RTO fornito dal failover avviato da Microsoft, è consigliabile usare il failover manuale per attivare manualmente il processo di failover. L'obiettivo RTO che utilizza questa opzione può essere compreso tra 10 minuti e un paio d'ore. L'obiettivo RTO è attualmente una funzione del numero di dispositivi registrati con l'istanza dell'Hub IoT su cui viene eseguito il failover. È possibile prevedere l'obiettivo RTO per un Hub di hosting di circa 100.000 dispositivi in approssimativamente 15 minuti. Il tempo totale per cui le operazioni di runtime diventano pienamente operative una volta che questo processo è stato attivato, è descritto nella sezione "Tempo di ripristino".

L'opzione di failover manuale è sempre disponibile per l'uso, indipendentemente dal fatto che nell'area primaria si siano verificati o meno tempi di inattività. Pertanto, questa opzione potrebbe potenzialmente essere usata per eseguire i failover pianificati. Un esempio di utilizzo del failover pianificato consiste nell'eseguire esercitazioni periodiche per il failover. Tuttavia, è importante precisare che un'operazione di failover pianificata determina un tempo di inattività per l'Hub per il periodo definito per l'obiettivo RTO per questa opzione e genera anche una perdita di dati definita dalla tabella RPO sovrastante. Si può considerare l'impostazione di un test di istanza dell'Hub IoT per provare l'opzione di failover pianificato periodicamente per ottenere una maggiore fiducia nella capacità di soluzioni end-to-end backup e in esecuzione quando si verifica un'emergenza reale.

Il failover manuale è disponibile senza costi aggiuntivi per gli hub IoT creati dopo il 18 maggio 2017

Per istruzioni dettagliate, vedere Esercitazione: Eseguire il failover manuale per un hub IoT

Failover manuale e Hub eventi

Il nome e l'endpoint compatibili con Hub eventi dell'hub IoT modifica dell'endpoint degli eventi predefiniti dopo il failover manuale. Ciò è dovuto al fatto che il client di Hub eventi non ha visibilità sugli eventi hub IoT. Lo stesso vale per altri client basati sul cloud, ad esempio Funzioni e Analisi di flusso di Azure. Per recuperare l'endpoint e il nome, è possibile usare il portale di Azure o .NET SDK.

Usare il portale

Per altre informazioni sull'uso del portale per recuperare l'endpoint compatibile con Hub eventi e il nome compatibile con Hub eventi, vedere Connettersi all'endpoint predefinito.

Usare .NET SDK

Per usare il hub IoT stringa di connessione per ricapitolare l'endpoint compatibile con Hub eventi, usare un esempio disponibile in https://github.com/Azure/azure-sdk-for-net/tree/main/samples/iothub-connect-to-eventhubs. L'esempio di codice usa il stringa di connessione per ottenere il nuovo endpoint di Hub eventi e ristabilire la connessione. È necessario aver installato Visual Studio.

Eseguire esercitazioni di test

Le esercitazioni sui test non devono essere eseguite negli hub IoT usati negli ambienti di produzione.

Non usare il failover manuale per eseguire la migrazione dell'hub IoT in un'area diversa

Il failover manuale non deve essere usato come meccanismo per eseguire la migrazione permanente dell'hub tra le aree geografiche associate di Azure. Supponendo che i dispositivi si trovassero più vicini all'area primaria dell'hub, la latenza per le operazioni eseguite sull'hub IoT aumenterà quando l'hub esegue il failover in un'area secondaria.

Failback

È possibile eseguire il failback nell'area primaria precedente attivando l'azione di failover una seconda volta. Se l'operazione di failover originale è stata eseguita per il ripristino da un'interruzione prolungata nell'area primaria originale, si consiglia di ripristinare l'Hub nella posizione originale dalla situazione di interruzione.

Tempo di ripristino

Anche se il nome di dominio completo (e quindi il stringa di connessione) dell'istanza dell'hub IoT rimane invariato dopo il failover, l'indirizzo IP sottostante cambia. Tempo per l'esecuzione delle operazioni di runtime sull'istanza dell'hub IoT per diventare completamente operativo dopo che il processo di failover può essere espresso usando la funzione seguente:

Tempi di ripristino = RTO [10 min - 2 ore per il failover manuale | 2-26 ore per il failover avviato da Microsoft] + ritardo nella propagazione DNS + Tempo impiegato dall'applicazione client per aggiornare qualsiasi indirizzo IP dell'hub IoT memorizzato nella cache.

Disabilitare il ripristino di emergenza

hub IoT fornisce failover avviato da Microsoft e failover manuale replicando i dati nell'area abbinata per ogni hub IoT. Per alcune aree, è possibile evitare la replica dei dati all'esterno dell'area disabilitando il ripristino di emergenza durante la creazione di un hub IoT. Le aree seguenti supportano questa funzionalità:

• Brasile meridionale; area abbinata, Stati Uniti centro-meridionali.
• Asia sud-orientale (Singapore); area abbinata, Asia orientale (HONG KONG SAR).

Per disabilitare il ripristino di emergenza nelle aree supportate, assicurarsi che il ripristino di emergenza abilitato sia deselezionato quando si crea l'hub IoT:

È anche possibile disabilitare il ripristino di emergenza quando si crea un hub IoT usando un modello di Resource Manager.

La funzionalità di failover non sarà disponibile se si disabilita il ripristino di emergenza per un hub IoT.

È possibile disabilitare il ripristino di emergenza solo per evitare la replica dei dati all'esterno dell'area abbinata in Brasile meridionale o asia sud-orientale quando si crea un hub IoT. Se si vuole configurare l'hub IoT esistente per disabilitare il ripristino di emergenza, è necessario creare un nuovo hub IoT con ripristino di emergenza disabilitato ed eseguire manualmente la migrazione dell'hub IoT esistente. Per indicazioni, vedere Come eseguire la migrazione di un hub IoT.

Ottenere disponibilità elevata tra aree

Se gli obiettivi di uptime aziendali non sono soddisfatti dal RTO che forniscono le opzioni di failover manuale o di failover avviato da Microsoft, si dovrebbe prendere in considerazione l'implementazione di un meccanismo di failover automatico tra aree per dispositivo. L'analisi completa delle topologie di distribuzione nelle soluzioni IoT esula dall'ambito di questo articolo. L'articolo illustra il modello di distribuzione di failover a livello di area per la disponibilità elevata e il ripristino di emergenza.

In un modello di failover a livello di area il back-end della soluzione viene eseguito principalmente nella località di un data center. Un hub IoT e un back-end secondari vengono distribuiti in un'altra località di data center. Se l'Hub IoT nella regione principale subisce un'interruzione o la connettività di rete dal dispositivo all'area principale viene interrotta, i dispositivi usano un endpoint del servizio secondario. È possibile migliorare la disponibilità della soluzione implementando un modello di failover tra aree invece di usare una sola area.

In generale, per implementare un modello di failover regionale con l'Hub IoT è necessario quanto segue:

• Un hub IoT secondario e una logica di routing del dispositivo: se il servizio nell'area primaria viene interrotto, i dispositivi devono avviare la connessione all'area secondaria. Data la condizione con riconoscimento dello stato della maggior parte dei servizi coinvolti, gli amministratori delle soluzioni attivano comunemente il processo di failover tra aree. Il modo migliore per comunicare il nuovo endpoint ai dispositivi, mantenendo il controllo del processo, consiste nel fare in modo che controllino regolarmente un servizio concierge per verificare la disponibilità dell'endpoint attualmente attivo. Il servizio concierge può essere un'applicazione Web replicata e mantenuta raggiungibile con tecniche di reindirizzamento DNS, ad esempio con Gestione traffico di Azure.

  Nota

  Il servizio Hub IoT non è un tipo di endpoint supportato in Gestione traffico di Azure. La raccomandazione è quella di integrare il servizio di concierge proposto con il gestore del traffico di Azure, implementando l'API della sonda di endpoint.

• Replica del registro delle identità: per poter essere usato, l'hub IoT secondario deve contenere tutte le identità dei dispositivi che possono connettersi alla soluzione. La soluzione deve mantenere backup con replica geografica delle identità dei dispositivi e caricarli nell'hub IoT secondario prima del passaggio all'endpoint attivo per i dispositivi. La funzionalità di esportazione delle identità dei dispositivi dell'hub IoT è utile in questo contesto. Per altre informazioni, vedere la Guida per gli sviluppatori dell'hub IoT: registro delle identità.

• Logica di unione: quando un'area primaria diventa di nuovo disponibile, deve essere eseguita la migrazione di tutti i dati e dello stato creati nel sito secondario all'area primaria. Lo stato e i dati sono per lo più correlati alle identità dei dispositivi e ai metadati dell'applicazione, che devono essere uniti all'hub IoT primario e agli altri archivi specifici dell'applicazione nell'area primaria.

Per semplificare questo passaggio è consigliabile usare operazioni idempotenti. Le operazioni idempotenti riducono al minimo gli effetti collaterali della distribuzione coerente degli eventi e dei duplicati o del recapito non ordinato degli eventi. La logica dell'applicazione deve inoltre essere progettata per tollerare eventuali incoerenze o uno stato "leggermente" obsoleto. Questa situazione può verificarsi a causa del tempo aggiuntivo necessario per il ripristino del sistema in base agli obiettivi del punto di ripristino (RPO).

Scegliere l'opzione disponibilità elevata o ripristino di emergenza corretta

Ecco un riepilogo delle opzioni di disponibilità elevata e ripristino di emergenza presentate in questo articolo, utilizzabili come riferimento per scegliere l'opzione corretta per la soluzione.

Passaggi successivi

• Che cos'è l'hub IoT Azure?
• Guida introduttiva: Inviare dati di telemetria da un dispositivo Plug and Play IoT a hub IoT di Azure
• Esercitazione: Eseguire il failover manuale per un hub IoT