Hub IoT e affidabilità

l'hub IoT di Azure è un servizio gestito ospitato nel cloud che funge da hub messaggi centrale per la comunicazione tra un'applicazione IoT e i relativi dispositivi collegati. È possibile connettere milioni di dispositivi e le relative soluzioni back-end in modo affidabile e sicuro. Quasi tutti i dispositivi possono essere connessi a un hub IoT.

L'hub IoT supporta il monitoraggio per tenere traccia della creazione, delle connessioni dei dispositivi e degli errori dei dispositivi.

L'hub IoT supporta anche i modelli di messaggistica seguenti:

• Telemetria da dispositivo a cloud
• Caricamento di file da dispositivi
• Metodi di richiesta di risposta per controllare i dispositivi dal cloud

Per ulteriori informazioni su IoT Hub, fare riferimento a Concetti IoT e IoT Hub di Azure.

Per comprendere in che modo l'hub IoT supporta un carico di lavoro affidabile, fare riferimento agli argomenti seguenti:

• L'elevata disponibilità e il ripristino di emergenza dell'IoT Hub
• Come ottenere la disponibilità elevata tra aree con l'hub IoT
• Come clonare un hub IoT di Azure in un'altra area

Le sezioni seguenti sono specifiche dell'hub IoT di Azure e dell'affidabilità:

• Considerazioni sulla progettazione
• Elenco di controllo della configurazione
• Opzioni di configurazione consigliate

Considerazioni sulla progettazione

Per ulteriori informazioni sul Contratto di Livello di Servizio dell'hub IoT di Azure, consultare SLA per l'hub IoT di Azure.

Lista di controllo

È stato configurato l'hub IoT di Azure tenendo presente l'affidabilità?

• Provvedere al provisioning di un secondo hub IoT in un'altra regione e implementare la logica di routing sul dispositivo.
• Usare il protocollo AMQP o MQTT durante l'invio frequente di eventi.
• Usare solo i certificati convalidati da una CA radice nell'ambiente di produzione se si usano certificati X.509 per la connessione del dispositivo.
• Per la velocità effettiva massima, usare il numero massimo di partizioni (32) durante la creazione dell'hub IoT, se si prevede di usare l'endpoint predefinito.
• Per il ridimensionamento, aumentare il livello e le unità IoT Hub allocate anziché aggiungere più di un hub IoT per regione.
• Negli scenari con velocità effettiva elevata usare eventi in batch.
• Se è necessaria la latenza minima possibile, non usare il routing e leggere gli eventi dall'endpoint predefinito.
• Come parte della tua strategia di disponibilità e ripristino di emergenza dell'intera soluzione, considera l'uso dell'opzione di ripristino di emergenza tra regioni per IoT Hub .
• Quando si utilizza un SDK per inviare eventi agli hub IoT, è fondamentale assicurarsi che le eccezioni generate dal criterio di tentativi di ripetizione (EventHubsException o OperationCancelledException) vengano correttamente intercettate.
• Per evitare l'interruzione dei dati di telemetria a causa della limitazione e di una quota completamente usata, è consigliabile aggiungere una soluzione di ridimensionamento automatico personalizzata.

Consigli sulla configurazione

Per ottimizzare l'affidabilità durante la configurazione dell'hub IoT di Azure, considerare le seguenti raccomandazioni:

Raccomandazione	Descrizione
Effettuare il provisioning di un secondo hub IoT in un'altra area e implementare la logica di routing sul dispositivo.	Queste configurazioni possono essere ulteriormente migliorate con un Concierge Service.
Usare il protocollo AMQP o MQTT durante l'invio frequente di eventi.	AMQP e MQTT hanno costi di rete più elevati durante l'inizializzazione della sessione, tuttavia HTTPS richiede un sovraccarico TLS aggiuntivo per ogni richiesta. AMQP e MQTT hanno prestazioni più elevate per i server di pubblicazione frequenti.
Usare solo i certificati convalidati da una CA radice nell'ambiente di produzione se si usano certificati X.509 per la connessione del dispositivo.	Assicurarsi di disporre di processi per aggiornare il certificato prima della scadenza.
Per la velocità effettiva massima, usare il numero massimo di partizioni (32) durante la creazione dell'hub IoT, se si prevede di usare l'endpoint predefinito.	Il numero di partizioni da dispositivo a cloud per l'endpoint compatibile con Event Hub riflette il grado di parallelismo downstream possibile ottenere. Ciò consentirà di aumentare le prestazioni fino a 32 entità di elaborazione simultanee e offrirà la massima disponibilità di invio e ricezione. Questo numero non può essere modificato dopo la creazione.
Per il ridimensionamento, aumentare il livello e le unità dell'hub IoT allocate invece di aggiungere più di un hub IoT in ciascuna area.	L'aggiunta di più hub IoT per area non offre resilienza aggiuntiva perché tutti gli hub possono essere eseguiti nello stesso cluster sottostante.
Negli scenari con velocità effettiva elevata usare eventi in batch.	Il servizio distribuirà una matrice con più eventi ai consumer, anziché una matrice con un solo evento. L'applicazione che consuma deve elaborare queste matrici.
Se è necessaria la latenza minima possibile, non usare il routing e leggi gli eventi dall'endpoint predefinito.	Quando si usa il routing dei messaggi nell'hub IoT, aumenta la latenza del recapito dei messaggi. In media, la latenza non deve superare 500 ms, ma non esiste alcuna garanzia per la latenza di recapito.
Come parte della strategia di disponibilità e ripristino di emergenza a livello di soluzione, è consigliabile usare l'opzione di ripristino di emergenza tra aree dell'Hub IoT .	Questa opzione sposta l'endpoint dell'hub IoT nell'area di Azure abbinata. Viene replicato solo il Registro di sistema del dispositivo. Gli eventi non vengono replicati nell'area secondaria. L'obiettivo di tempo di ripristino (RTO) per il failover avviato dal cliente è compreso tra 10 minuti e un paio di ore. Per un failover avviato da Microsoft, l'RTO è 2-26 ore. Conferma che questo RTO sia allineato ai requisiti del cliente in questione e si adatti alla strategia generale di disponibilità. Se è necessario un RTO superiore, prendere in considerazione l'implementazione di un modello di failover lato client.
Quando si usa un SDK per inviare eventi all'hub IoT, assicurarsi che le eccezioni generate dal criterio di ripetizione dei tentativi (EventHubsException o OperationCancelledException) vengano rilevate correttamente.	Quando si usa HTTPS, implementare un modello di ripetizione corretto.

Passaggio successivo

hub IoT ed eccellenza operativa