Hub IoT ed eccellenza operativa
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 al cloud
- Caricamento di file da dispositivi
- Metodi di richiesta di risposta per controllare i dispositivi dal cloud
Per ulteriori informazioni sull'hub IoT, fare riferimento ai Concetti di IoT e Hub IoT di Azure.
Per comprendere in che modo l'hub IoT promuove l'eccellenza operativa, fare riferimento agli argomenti seguenti:
- Tutorial: Configurare e usare metriche e log con un IoT Hub
- Monitoraggio dell'hub IoT di Azure
- Tracciare i messaggi da dispositivo a cloud di Azure IoT con di traccia distribuita (anteprima)
- Controllare l'integrità del servizio e delle risorse dell'hub IoT
Le sezioni seguenti sono specifiche dell'hub IoT di Azure e dell'eccellenza operativa:
- Considerazioni sulla progettazione
- Elenco di controllo della configurazione
- Opzioni di configurazione consigliate
Considerazioni sulla progettazione
Per ulteriori informazioni sull'accordo sul livello di servizio dell'Azure IoT Hub, fai riferimento SLA per l'Azure IoT Hub.
Lista di controllo
L'hub IoT di Azure è stato configurato tenendo conto dell'eccellenza operativa?
- Provisionare un secondo hub IoT in un'altra regione e avere la logica di instradamento sul dispositivo.
- Usare il protocollo
AMQP
oMQTT
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à dell'hub IoT allocate anziché aggiungere più di un hub IoT per regione.
- Negli scenari con alto flusso di dati, è consigliabile usare eventi in batch.
- Se è necessaria la latenza minima possibile, non usare il routing e leggi gli eventi dall'endpoint predefinito.
- Come parte della tua strategia di disponibilità e ripristino di emergenza a livello di intera soluzione, considera l'opzione di Ripristino di emergenza tra aree dell'IoT Hub .
- Quando si usa un SDK per inviare eventi agli hub IoT, assicurarsi che le eccezioni generate dal criterio di ripetizione dei tentativi (
EventHubsException
oOperationCancelledException
) vengano rilevate correttamente. - Per evitare l'interruzione del flusso di telemetria dovuta alla limitazione e a una quota completamente usata, potrebbe essere utile aggiungere una soluzione di ridimensionamento automatico personalizzata .
Consigli sulla configurazione
Quando si configura l'hub IoT di Azure, prendere in considerazione le raccomandazioni seguenti per aumentare l'eccellenza operativa:
Raccomandazione | Descrizione |
---|---|
Effettuare il provisioning di un secondo hub IoT in un'altra area e avere 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 che è possibile ottenere. Ciò consentirà di scalare 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 anziché 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 alto throughput, usare gli eventi in batch. | Il servizio distribuirà una matrice con più eventi ai consumer, anziché una matrice con un solo evento. L'applicazione consumatrice 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 a livello di soluzione, è consigliabile utilizzare l'opzione di ripristino di emergenza cross-regionale dell'IoT Hub . | 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 Recovery Time Objective (RTO) per un failover avviato dall'utente è compreso tra 10 minuti e alcune ore. Per un failover avviato da Microsoft, l'obiettivo RTO è 2-26 ore. Verificare che questo RTO sia allineato ai requisiti del cliente e si adatti alla strategia di disponibilità più ampia. 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. |