Hub IoT e affidabilità

  • Articolo

L'hub IoT di Azure è un servizio gestito, ospitato nel cloud, che funge da hub centrale di messaggi per le comunicazioni bidirezionali tra l'applicazione di 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 e degli errori dei dispositivi.

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

  • Telemetria da dispositivo a cloud
  • Caricamento di file dai dispositivi
  • Metodi request/reply per controllare i dispositivi dal cloud

Per altre informazioni sull'hub IoT, vedere Concetti relativi a IoT e hub IoT di Azure.

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

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

  • Considerazioni relative alla progettazione
  • Elenco di controllo configurazione
  • Opzioni di configurazione consigliate

Considerazioni relative alla progettazione

Per altre informazioni sul contratto di servizio per l'hub IoT di Azure, vedere Contratto di servizio per l'hub IoT di Azure.

Elenco di controllo

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

  • Effettuare il provisioning di un secondo hub IoT in un'altra area e inserire la logica di routing nel dispositivo.
  • Usare il protocollo AMQP o MQTT per l'invio frequente di eventi.
  • Se si usano certificati X.509 per la connessione dei dispositivi, usare solo certificati convalidati da una CA radice nell'ambiente di produzione.
  • 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à dell'hub IoT allocate invece di aggiungere più di un hub IoT per area.
  • 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 strategia di disponibilità e ripristino di emergenza a livello di soluzione, è consigliabile usare l'opzione di ripristino di emergenza tra aree dell'hub IoT.
  • Per la lettura di dati di telemetria del dispositivo dall'endpoint predefinito compatibile con Hub eventi, vedere Raccomandazioni per i consumer dell'hub eventi.
  • Se si usa un SDK per inviare eventi agli hub IoT, verificare che le eccezioni generate dai criteri di ripetizione (EventHubsException o OperationCancelledException) vengano rilevate correttamente.
  • Per evitare l'interruzione dei dati di telemetria a causa di limitazioni e di una quota completamente usata, è consigliabile aggiungere una soluzione di ridimensionamento automatico personalizzata.

Raccomandazioni per la configurazione

Quando si configura l'hub IoT di Azure, prendere in considerazione le raccomandazioni seguenti per ottimizzare l'affidabilità:

Suggerimento Descrizione
Effettuare il provisioning di un secondo hub IoT in un'altra area e inserire la logica di routing nel dispositivo. Queste configurazioni possono essere ulteriormente migliorate con un servizio Concierge.
Usare il protocollo AMQP o MQTT per 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 offrono prestazioni più elevate per i server di pubblicazione più attivi.
Se si usano certificati X.509 per la connessione dei dispositivi, usare solo certificati convalidati da una CA radice nell'ambiente di produzione. Assicurarsi che siano presenti 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 Hub eventi riflette il grado di parallelismo downstream che è possibile ottenere. In questo modo sarà possibile aumentare le entità di elaborazione simultanee fino a 32 e offrire la massima disponibilità di invio e ricezione. Questo numero non può essere cambiato dopo la creazione.
Per il ridimensionamento, aumentare il livello e le unità dell'hub IoT allocate invece di aggiungere più di un hub IoT per 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 distribuisce ai consumer una matrice con più eventi invece che con uno solo. L'applicazione consumer deve elaborare queste matrici.
Se è necessaria la latenza minima possibile, non usare il routing e leggere gli eventi dall'endpoint predefinito. Se si usa il routing dei messaggi nell'hub IoT, la latenza del recapito dei messaggi aumenta. 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 sposterà l'endpoint dell'hub IoT nell'area di Azure associata. Viene replicato solo il registro dei dispositivi. Gli eventi non vengono replicati nell'area secondaria. L'obiettivo del 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 è di 2-26 ore. Verificare che questo RTO sia in linea con i requisiti del cliente e rientri nella strategia di disponibilità di più ampio respiro. Se è necessario un RTO superiore, valutare la possibilità di implementare un criterio di failover sul lato client.
Se si usa un SDK per inviare eventi all'hub IoT, verificare che le eccezioni generate dai criteri di ripetizione (EventHubsException o OperationCancelledException) vengano rilevate correttamente. Se si usa HTTPS, implementare un criterio di ripetizione dei tentativi appropriato.

Passaggio successivo

Hub IoT ed eccellenza operativa