Scalare una soluzione hub IoT di Azure per supportare milioni di dispositivi

Il modello di scalabilità orizzontale è un approccio alla scalabilità di una soluzione Internet delle cose (IoT) che aggiunge istanze a una distribuzione anziché aumentare le dimensioni di ogni istanza. Nella piattaforma hub IoT di Azure è possibile aumentare il numero di istanze per supportare milioni di dispositivi pur rimanendo entro i limiti del servizio e delle sottoscrizioni Azure.

Questo articolo illustra come applicare il modello di scalabilità orizzontale a una soluzione basata su hub IoT. Descrive i modelli di distribuzione a basso tocco e zero-touch in modo da poter adottare l'approccio più adatto alle proprie esigenze.

Un diagramma

Per altre informazioni, vedere gli articoli seguenti:

Nota

Questo documento non illustra la piattaforma Operazioni di Azure IoT, che viene ridimensionata in base alla configurazione della piattaforma Kubernetes di hosting.

Raccogliere i requisiti

Raccogliere i requisiti prima di implementare una nuova soluzione IoT. Questo passaggio consente di garantire che l'implementazione soddisfi gli obiettivi aziendali. Gli obiettivi aziendali e l'ambiente operativo dovrebbero guidare i vostri requisiti. Come minimo, raccogliere i requisiti seguenti:

Identificare i tipi di dispositivi da distribuire. IoT comprende un'ampia gamma di soluzioni, da unità microcontroller semplici (MCU) a unità di microcontroller a unità soC (System-On-Chip) di livello intermedio e processori (MPU), fino a progettazioni complete a livello di PC. Le funzionalità software sul lato dispositivo influenzano direttamente la progettazione della soluzione.

Determinare il numero di dispositivi da distribuire. Alcuni principi di base dell'implementazione di soluzioni IoT si applicano a tutte le scale. Comprendere la scalabilità per evitare l'overengineering di una soluzione. Una soluzione per 1.000 dispositivi differisce fondamentalmente da una soluzione per 1 milione di dispositivi. Una soluzione PoC per 10.000 dispositivi potrebbe non scalare adeguatamente a 10 milioni di dispositivi se fin dall'inizio della progettazione non si considera la scala di destinazione.

Identificare il numero di dispositivi da distribuire in modo da poter scegliere il servizio Azure IoT corretto. Il ridimensionamento per hub IoT e hub IoT DPS è diverso. Per impostazione predefinita, una singola istanza del servizio Device Provisioning può instradarsi a più istanze di hub IoT. Considerare quindi la scalabilità di ogni servizio singolarmente rispetto al numero di dispositivi. Ma i limiti non esistono in isolamento. Se un servizio presenta un problema di limite, è probabile che anche altri servizi presentino un problema simile. Considerare i limiti del servizio come quote distinte ma correlate.

Documentare le posizioni previste dei dispositivi. Includere la posizione fisica, la disponibilità dell'alimentazione e la connettività Internet. Una soluzione distribuita in una singola area geografica, ad esempio solo in America del Nord, è progettata in modo diverso rispetto a una soluzione globale. Analogamente, una soluzione IoT industriale distribuita in fabbriche con potenza a tempo pieno differisce da una soluzione di gestione della flotta distribuita nei veicoli a motore con potenza variabile e posizione. Il protocollo di comunicazione e la larghezza di banda disponibile, sia che si tratti di un gateway che direttamente a un servizio cloud, influiscono sulla scalabilità della progettazione a ogni livello. Prendere in considerazione anche la disponibilità della connettività. Determinare se i dispositivi rimangono connessi a Azure o eseguiti in modalità disconnessa per periodi prolungati.

Esaminare i requisiti di localizzazione dei dati. I requisiti legali, di conformità o dei clienti possono limitare la posizione in cui è possibile archiviare i dati (ad esempio i dati di telemetria) o i metadati (ad esempio le informazioni sul dispositivo) per la soluzione. Queste restrizioni influiscono in modo significativo sulla progettazione geografica della soluzione.

Determinare i requisiti di scambio dei dati. Una soluzione che invia dati di telemetria di base, ad esempio la temperatura corrente una volta all'ora, è diversa da una soluzione che carica file di esempio di 1 MB una volta ogni 10 minuti. Una soluzione da dispositivo a cloud (D2C) unidirezionale differisce da una soluzione D2C bidirezionale e da cloud a dispositivo (C2D). Inoltre, le limitazioni di scalabilità dei prodotti considerano le dimensioni dei messaggi e la quantità dei messaggi come dimensioni diverse.

Documentare i requisiti di disponibilità elevata e ripristino di emergenza previsti. Analogamente a qualsiasi soluzione di produzione, le progettazioni complete di soluzioni IoT includono requisiti di disponibilità o tempo di attività. La progettazione deve coprire sia gli scenari di manutenzione pianificata che i tempi di inattività non pianificati, inclusi errori utente, fattori ambientali e bug della soluzione. La progettazione richiede anche un obiettivo del punto di ripristino (RPO) documentato e un obiettivo del tempo di ripristino (RTO) se si verifica un'emergenza, ad esempio una perdita di area permanente o utenti malintenzionati. Questo articolo è incentrato sulla scalabilità dei dispositivi, quindi include solo informazioni limitate sui problemi di disponibilità elevata e ripristino di emergenza.

Se opportuno, decidere su un modello di gestione per il cliente. In una soluzione aziendale di sviluppo di software multi-tenant, in cui lo sviluppatore di soluzioni crea una soluzione per i clienti esterni, la progettazione deve definire come separare e gestire i dati dei clienti. Per altre informazioni, vedere Modelli di tenancy e le linee guida correlate specifiche per IoT.

Informazioni sui concetti relativi a hub IoT di Azure e DPS

Quando si crea una soluzione, scegliere i componenti Azure IoT appropriati e altri servizi di supporto Azure. L'architettura della soluzione richiede un impegno significativo. L'uso corretto dei servizi hub IoT e hub IoT DPS consente di ridimensionare le soluzioni a milioni di dispositivi.

hub IoT

hub IoT è 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 usare hub IoT da solo o con hub IoT DPS.

hub IoT si ridimensiona in base alla funzionalità desiderata e al numero di messaggi o al volume di dati al giorno. Usare i tre input seguenti per determinare come ridimensionare un'istanza:

Gli livelli gratuito, base e standard determinano le funzionalità disponibili. Un'istanza di produzione non usa il livello gratuito perché è limitata in scala e destinata solo agli scenari di sviluppo di introduzione. La maggior parte delle soluzioni usa il livello standard per ottenere le funzionalità complete di hub IoT.
Il size determina l'unità di base di velocità effettiva del messaggio e dei dati per i messaggi D2C per hub IoT. La dimensione massima per un'istanza di hub IoT è 3, che supporta 300 milioni di messaggi al giorno e 1.144,4 GB di dati al giorno, per unità.
Il numero di unità determina il moltiplicatore per la scala in base alle dimensioni. Ad esempio, tre unità supportano tre volte la scala di un'unità. Il limite per le dimensioni 1 o 2 istanze dell'hub è 200 unità e il limite per le dimensioni 3 istanze dell'hub è 10 unità.

Oltre ai limiti giornalieri in base alle dimensioni e al numero di unità e ai limiti generali delle funzionalità in base al livello, hub IoT applica limiti al secondo per la velocità effettiva. Ogni istanza di hub IoT supporta anche fino a 1 milione di dispositivi come limite hard. I requisiti di scambio dei dati consentono di definire la configurazione appropriata. Per altre informazioni, vedere Altri limiti.

I requisiti della soluzione determinano le dimensioni necessarie e il numero di istanze di hub IoT come punto di partenza. Se si usa hub IoT DPS, Azure consente di distribuire i carichi di lavoro in più istanze di hub IoT.

hub IoT DPS

hub IoT DPS è un servizio di supporto per hub IoT che fornisce il provisioning just-in-time, senza intervento manuale, nell'hub IoT corretto senza intervento umano. Ogni sottoscrizione Azure supporta un valore predefinito di 10 istanze del servizio Device Provisioning. Ogni istanza del servizio supporta a sua volta un valore predefinito di 1 milione di registrazioni. Risolvere i limiti del servizio nella progettazione del carico di lavoro per evitare problemi futuri.

Le istanze del servizio Device Provisioning si trovano in aree geografiche specifiche, ma hanno un endpoint pubblico globale per impostazione predefinita. È possibile accedere a istanze specifiche tramite un ambito ID. Poiché le istanze si trovano in aree specifiche e ogni istanza ha un proprio ambito ID, è possibile configurare l'ambito ID per i dispositivi.

Per impostazione predefinita, dps sfrutta la replica geografica per abilitare il ripristino di emergenza a livello di area. Per altre informazioni, vedi la documentazione di DPS sul ripristino di emergenza.

Comprendere i concetti relativi alla resilienza condivisa

È necessario considerare concetti di resilienza condivisa, ad esempio la gestione degli errori temporanei, l'impatto sulla posizione dei dispositivi e, per le aziende software, la resilienza dei dati SaaS (Software as a Service).

Comprendere la gestione degli errori temporanei. Qualsiasi soluzione distribuita di produzione, sia in locale che nel cloud, deve essere in grado di riprendersi da guasti transitori o temporanei. Gli errori temporanei possono verificarsi più frequentemente in una soluzione cloud a causa dei fattori seguenti:

Dipendenza da un provider esterno
Dipendenza dalla connettività di rete tra il dispositivo e i servizi cloud
Limiti di implementazione dei servizi cloud

La gestione degli errori temporanei richiede di compilare una funzionalità di ripetizione dei tentativi nel codice del dispositivo. Esistono diverse strategie di ripetizione, tra cui il backoff esponenziale con randomizzazione, noto anche come backoff esponenziale con jitter. Per altre informazioni, vedere Gestione degli errori temporanei.

Diversi fattori possono influire sulla connettività di rete di un dispositivo:

Fonte di alimentazione di un dispositivo: I dispositivi alimentati dalla batteria o da fonti transitorie, come solare o eolico, potrebbero avere una connettività di rete inferiore rispetto ai dispositivi alimentati continuamente dalla rete elettrica.
Percorso di distribuzione di un dispositivo: I dispositivi nelle impostazioni della fabbrica urbana hanno probabilmente una connettività di rete migliore rispetto ai dispositivi in ambienti di campo isolato.
Stabilità della posizione di un dispositivo: I dispositivi mobili hanno probabilmente meno connettività di rete rispetto ai dispositivi a posizione fissa.

Questi problemi influiscono anche sulla tempistica della disponibilità e della connettività dei dispositivi. Ad esempio, i dispositivi basati su linea in ambienti urbani densi, come gli smart speaker, potrebbero disconnettersi e riconnettersi in gruppi di grandi dimensioni. Considerare gli scenari seguenti:

Un blackout potrebbe causare 1 milione di dispositivi andare offline contemporaneamente e tornare online contemporaneamente a causa di perdita di rete elettrica e riconnessione. Questo scenario si applica in entrambi gli scenari consumer, ad esempio smart speaker, e scenari IoT aziendali e industriali, ad esempio termostati connessi e basati su linea che segnalano a una società di gestione immobiliare.
Durante un evento di onboarding su larga scala, come il Black Friday o il Natale, molti consumatori accendono i dispositivi per la prima volta in un periodo di tempo relativamente breve.
Molti dispositivi ricevono aggiornamenti pianificati in un breve intervallo di tempo e tutti vengono riavviati con il nuovo aggiornamento allo stesso tempo.

Questi molti dispositivi che si avviano contemporaneamente possono attivare la limitazione delle richieste dei servizi cloud, anche con connettività di rete quasi costante.

Oltre ai problemi di rete e di quota, è consigliabile prendere in considerazione anche le interruzioni del servizio di Azure. Queste interruzioni possono influire su singoli servizi o intere aree. Alcuni servizi, ad esempio hub IoT e hub IoT DPS, supportano alcune forme di ridondanza geografica. È possibile collegare una hub IoT a più istanze del servizio Device Provisioning e un'istanza del servizio Device Provisioning supporta più istanze di hub IoT, entrambe utili per la mitigazione, ma non risolvono completamente i rischi a livello di area. Se la disponibilità elevata a livello di area completa è un problema, usare il modello Geode. Questo modello ospita risorse indipendenti raggruppate in aree geografiche diverse. Analogamente, un timbro di distribuzione, noto anche come timbro di scala, applica questo modello per gestire più carichi di lavoro o tenant. Per ulteriori informazioni, consultare Schema di distribuzione con timbratura. Questi modelli consentono anche di risolvere il problema che hub IoT DPS non esegue il monitoraggio dell'integrità negli hub IoT collegati, perché una distribuzione geograficamente dispersa con una soluzione di monitoraggio dell'integrità e una soluzione di bilanciamento del carico appropriata consente il routing a un'istanza del servizio Device Provisioning diversa e quindi a un'istanza diversa hub IoT.

Comprendere l'impatto sulla posizione del dispositivo. La maggior parte dei servizi Azure sono regionali, anche DPS con endpoint globali. Le eccezioni includono Gestione traffico di Azure e Microsoft Entra ID. Le decisioni relative alla posizione del dispositivo, alla posizione dei dati e alla posizione dei metadati ,ad esempio Azure gruppi di risorse, svolgono un ruolo fondamentale nella progettazione.

Posizione del dispositivo: I requisiti di posizione del dispositivo influiscono sulla selezione a livello di area perché influiscono sulla latenza transazionale.
Posizione dei dati: La posizione dei dati dipende dalla posizione del dispositivo ed è soggetta a problemi di conformità. Ad esempio, una soluzione che archivia i dati per uno stato nel Stati Uniti potrebbe richiedere l'archiviazione dei dati negli Stati Uniti geography. I requisiti di localizzazione dei dati potrebbero anche favorire questa esigenza.
Posizione dei metadati: Anche se la posizione del dispositivo non influisce in genere sulla posizione dei metadati perché i dispositivi interagiscono con i dati della soluzione e non i metadati della soluzione, i problemi di conformità e costi influiscono sulla posizione dei metadati. In molti casi, la praticità determina che la posizione dei metadati corrisponde alla posizione dei dati per i servizi regionali.

L'Azure Cloud Adoption Framework include linee guida sulla selezione regionale.

Comprendere le preoccupazioni delle aziende di software SaaS. Le aziende software che offrono soluzioni SaaS devono soddisfare le aspettative dei clienti per la disponibilità e la resilienza. Le aziende software devono progettare i servizi Azure per essere altamente disponibili e considerare il costo della resilienza e della ridondanza durante la fatturazione del cliente.

Anche se è possibile tenere traccia dell'utilizzo del tenant a un livello superiore rispetto al livello di servizio, spesso è più semplice separare il costo delle merci vendute (COGS) in base alla separazione dei dati dei clienti per ogni cliente del provider SaaS. Questa distinzione è particolarmente importante quando l'utente finale non è uguale al cliente SaaS. Ad esempio, per una piattaforma smart TV, il cliente del fornitore della piattaforma potrebbe essere il fornitore televisivo, mentre l'utente finale è l'acquirente televisivo. Il modello di tenancy richiesto dal cliente determina questa separazione, che a sua volta porta spesso a utilizzare istanze separate di DPS e hub IoT per maggiore semplicità, con il rischio di un costo di distribuzione potenzialmente più elevato. Va notato che questa segregazione è specificamente finalizzata al monitoraggio del COGS; non è necessaria ai fini del solo isolamento del tenant, come illustrato in Approcci architetturali per soluzioni multi-tenant basate su hub IoT.

Il servizio di provisioning deve avere anche un'identità univoca del cliente, che è possibile definire tramite un endpoint univoco o un processo di autenticazione del dispositivo. Per ulteriori informazioni, vedere Linee guida multitenant IoT.

Aumentare il numero di componenti e i relativi servizi di supporto

Quando espandi le soluzioni IoT, valuta ogni servizio e come questi siano interconnessi. Scalare la soluzione IoT su più istanze di DPS e/o su più istanze di hub IoT.

Distribuire il carico su più istanze del servizio Device Provisioning Service (DPS)

A causa dei limiti del servizio DPS, spesso è necessario espandersi in più istanze DPS. Approccio al provisioning dei dispositivi tra più istanze del servizio Device Provisioning tramite il provisioning senza tocco o con basso tocco.

Gli approcci seguenti applicano il concetto di stamp descritto in precedenza per la resilienza e la scalabilità orizzontale. Questo concetto include la distribuzione di Servizio app di Azure in più aree e l'uso di uno strumento come Gestione traffico o Frontdoor di Azure. Per semplicità, i diagrammi seguenti non mostrano questi componenti.

Approccio 1: Provisioning senza intervento con più istanze di DPS

Per il provisioning automatico o zero-touch, una strategia collaudata prevede che il dispositivo richieda un ambito ID DPS da una API Web. L'API riconosce e bilancia i dispositivi tra le istanze DPS scalate orizzontalmente. Questa azione rende l'app Web una parte fondamentale del processo di provisioning, pertanto deve essere scalabile e a disponibilità elevata. Questa progettazione ha tre varianti principali.

Il diagramma seguente illustra la prima opzione che usa un'API di provisioning personalizzata che gestisce il mapping del dispositivo al pool dps appropriato. Ogni istanza DPS esegue quindi il mapping del dispositivo all'hub IoT appropriato utilizzando i meccanismi standard di bilanciamento del carico.

Il dispositivo richiede un ambito dell'ID DPS da un'API di provisioning ospitata in App Service. L'API di provisioning consulta il proprio database permanente per determinare l'istanza migliore per il dispositivo, basandosi sull'inventario esistente dei dispositivi, e restituisce l'ambito dello ID DPS.

In questo esempio il database è un'istanza di Azure Cosmos DB con scrittura multi-primaria abilitata per la disponibilità elevata tra aree. Questo database archivia i DPS assegnati a ogni dispositivo. Supporta il monitoraggio dell'utilizzo delle istanze DPS per tutte le metriche appropriate, ad esempio le richieste di provision al minuto e il totale dei dispositivi provisionati. Questo database supporta anche il reprovisioning utilizzando, quando necessario, lo stesso ambito ID di DPS. Autenticare l'API di provisioning per impedire richieste di provisioning inadeguate.
Il dispositivo richiede il provisioning a DPS usando l'ID scope assegnato. Dps risponde con i dettagli dell'assegnazione dell'hub IoT.
Il dispositivo archivia l'ID scope e le informazioni di connessione dell'hub IoT nella memoria permanente, idealmente in una posizione di archiviazione sicura perché l'ID scope fa parte dell'autenticazione nell'istanza DPS. Il dispositivo usa quindi queste informazioni di connessione dell'hub IoT per ulteriori richieste nel sistema.

Questa progettazione richiede che il software del dispositivo includa DPS SDK e gestisca il processo di registrazione dps, che è la progettazione tipica per un dispositivo Azure IoT. Ma in un ambiente di microcontroller, in cui le dimensioni del software del dispositivo sono un componente fondamentale della progettazione, potrebbe non essere accettabile e potrebbe richiedere una progettazione alternativa.

Approccio 2: Zero-Touch Provisioning con un'API di provisioning

Il secondo progetto sposta la chiamata DPS all'API di provisioning. In questo modello, l'API di provisioning contiene l'autenticazione del dispositivo rispetto al servizio Device Provisioning, insieme alla maggior parte della logica di ripetizione dei tentativi. Questo processo supporta scenari di accodamento più avanzati e codice di provisioning potenzialmente più semplice nel dispositivo stesso. Supporta anche la memorizzazione nella cache dell'hub IoT assegnato per facilitare la messaggistica C2D più veloce senza dover interrogare dps per le informazioni dell'hub assegnate.

Il dispositivo invia una richiesta a un'API di provisioning ospitata in un'istanza del servizio app. L'API di provisioning controlla con il proprio database permanente per determinare l'istanza migliore per il dispositivo in base all'inventario dei dispositivi esistente e quindi determina l'ambito ID DPS.

In questo esempio il database è un'istanza di Azure Cosmos DB con scrittura multi-primaria abilitata per la disponibilità elevata tra aree. Questo database archivia i DPS assegnati a ogni dispositivo. Supporta il rilevamento dell'utilizzo delle istanze dps per tutte le metriche appropriate. Il database consente anche il reprovisioning utilizzando lo stesso ambito ID di DPS, quando necessario.

Autenticare l'API di provisioning per impedire richieste di provisioning inadeguate. È probabile che tu possa usare la stessa autenticazione che il servizio di provisioning usa contro DPS, ad esempio una chiave privata per un certificato emesso. Esistono tuttavia altre opzioni. Ad esempio, una soluzione potrebbe usare identificatori univoci hardware come parte di un processo di autenticazione del servizio. Il partner di produzione di dispositivi fornisce regolarmente un elenco di identificatori univoci al fornitore del dispositivo da caricare in un database, che fa riferimento al servizio dietro l'API di provisioning personalizzata.
L'API di provisioning esegue il processo di provisioning DPS utilizzando l'ambito ID assegnato, fungendo efficacemente da proxy DPS.
L'API inoltra i risultati del servizio Device Provisioning al dispositivo.
Il dispositivo archivia le informazioni di connessione dell'hub IoT nella memoria persistente, idealmente in una posizione di archiviazione sicura, perché l'ID scope fa parte dell'autenticazione rispetto all'istanza DPS. Il dispositivo usa queste informazioni di connessione all'hub IoT per le richieste successive al sistema.

Questa progettazione evita la necessità di fare riferimento direttamente a DPS SDK o al servizio DPS. Evita inoltre la necessità di gestire manualmente un ambito DPS sul dispositivo, poiché proviene dall'API di provisioning. Questo modello supporta scenari di trasferimento della proprietà perché il servizio di provisioning può indirizzare all'istanza DPS finale appropriata. Tuttavia, questo approccio fa sì che l'API di provisioning duplici alcune funzionalità del servizio Device Provisioning, che potrebbero non soddisfare tutti gli scenari.

Approccio 3: provisioning senza intervento manuale con trasferimento della proprietà

Una terza progettazione del provisioning zero-touch utilizza un'istanza del servizio Device Provisioning configurata in fabbrica come punto di partenza e reindirizza i dispositivi ad altre istanze del servizio Device Provisioning secondo necessità. Questa progettazione supporta il provisioning senza un'API di provisioning personalizzata, ma richiede un'applicazione di gestione per tenere traccia delle istanze del servizio Device Provisioning e fornire il reindirizzamento in base alle esigenze.

I requisiti dell'applicazione di gestione includono il rilevamento del servizio Device Provisioning attivo per ogni dispositivo specifico. Usare questo approccio per gli scenari di trasferimento della proprietà, in cui il fornitore del dispositivo trasferisce la proprietà del dispositivo al cliente del dispositivo finale.

Il dispositivo si connette all'istanza del servizio Device Provisioning configurata per la factory e richiede un processo di provisioning iniziale.
Il dispositivo riceve una configurazione iniziale, inclusa la prescelta istanza di destinazione del servizio Device Provisioning.
Il dispositivo si connette all'istanza desiderata del servizio Device Provisioning e richiede la configurazione.
Il dispositivo memorizza le informazioni di connessione dell'hub IoT nella memoria permanente, idealmente in un percorso di archiviazione protetto perché l'ID scope fa parte dell'autenticazione nell'istanza del servizio Device Provisioning (DPS). Il dispositivo usa queste informazioni di connessione dell'hub IoT per ulteriori richieste nel sistema.

Approccio 4: provisioning a basso tocco con più istanze del servizio Device Provisioning

In alcuni casi, come negli scenari destinati ai consumatori o nei dispositivi dei team di distribuzione sul campo, una scelta comune è offrire un provisioning a basso coinvolgimento o assistito dall'utente. Esempi di provisioning a basso tocco includono un'applicazione per dispositivi mobili sul telefono di un installatore o un'applicazione basata sul Web in un gateway dispositivo. Questo approccio esegue le stesse operazioni del processo di provisioning zero-touch, ma l'applicazione di provisioning trasferisce i dettagli al dispositivo.

L'amministratore avvia un'app di configurazione del dispositivo, che si connette al dispositivo.
L'app di configurazione si connette a un'API di provisioning ospitata in un'istanza del servizio app per richiedere un ambito ID DPS. L'API di provisioning controlla il database permanente per determinare l'istanza migliore per il dispositivo, in base all'inventario dei dispositivi esistente e restituisce l'ambito ID DPS.

In questo esempio il database è un'istanza di Azure Cosmos DB con scrittura multi-primaria abilitata per la disponibilità elevata tra aree. Questo database archivia i DPS assegnati a ogni dispositivo. Supporta il rilevamento dell'utilizzo delle istanze del servizio Device Provisioning per tutte le metriche appropriate. Questo database supporta anche il reprovisioning utilizzando, quando necessario, lo stesso ambito ID di DPS. Autenticare l'API di provisioning per impedire richieste di provisioning inadeguate.
L'app restituisce l'ambito dell'ID di provisioning al dispositivo.
Il dispositivo richiede il provisioning a DPS usando l'ID scope assegnato. DPS restituisce i dettagli dell'assegnazione dell'hub IoT al dispositivo.
Il dispositivo mantiene l'ambito ID e le informazioni di connessione dell'hub IoT all'archiviazione permanente, idealmente in un percorso di archiviazione protetto perché l'ambito ID fa parte dell'autenticazione nell'istanza del servizio Device Provisioning. Il dispositivo usa queste informazioni di connessione dell'hub IoT per ulteriori richieste nel sistema.

Questo articolo non tratta altre varianti. Ad esempio, è possibile configurare questo approccio spostando la chiamata DPS all'API di provisioning, come mostrato in precedenza nel provisioning zero-touch con un'API di provisioning. L'obiettivo è assicurarsi che ogni livello sia scalabile, configurabile e facilmente distribuibile.

Indicazioni generali sul provisioning del DPS

Applica le seguenti raccomandazioni al tuo deployment di DPS:

Non effettuare il provisioning in ogni avvio. La documentazione del servizio Device Provisioning consiglia di non eseguire il provisioning in ogni avvio. Per i casi d'uso di piccole dimensioni, potrebbe sembrare ragionevole provvedere alla configurazione a ogni avvio perché è il percorso più breve per la distribuzione. Tuttavia, quando si passa a milioni di dispositivi, DPS può diventare un collo di bottiglia a causa del suo limite predefinito di 1.000 registrazioni al minuto per istanza del servizio. Anche le verifiche dello stato di registrazione del dispositivo possono diventare un collo di bottiglia, perché sono limitate a cinque operazioni di polling ogni 10 secondi per dispositivo. I risultati del provisioning vengono in genere mappati in modo statico a un hub IoT. Dovresti quindi avviare il provisioning solo quando strettamente necessario, a meno che i tuoi requisiti non includano richieste di ri-provisioning automatizzate. Se si prevede un maggior traffico, aumentare il numero di istanze DPS per supportare lo scenario.

Usare una pianificazione del provisioning sfalsata. Per ridurre le limitazioni basate sul tempo, usare una programmazione del provisioning scaglionata. Per il provisioning iniziale, introdurre un ritardo casuale di alcuni secondi oppure estenderlo fino a diversi minuti, in base ai requisiti di distribuzione.

Interrogare sempre lo stato prima di richiedere il provisioning. Come procedura consigliata, i dispositivi devono sempre verificare il proprio stato prima di richiedere il provisioning utilizzando l'API Device Registration Status Lookup API. Questa chiamata non viene conteggiata come articolo fatturato e il limite è indipendente dal limite di registrazione. L'operazione di query è relativamente rapida rispetto a una richiesta di provisioning, in modo che il dispositivo possa convalidarne lo stato e avviare il normale carico di lavoro più velocemente. Per la logica di registrazione del dispositivo appropriata, vedere Distribuzione su larga scala.

Seguire le considerazioni sull'API di provisioning. Molte delle progettazioni di questo articolo includono un'API di provisioning. L'API di provisioning richiede un archivio di metadati di backup, ad esempio Azure Cosmos DB. A questi livelli di scalabilità, è necessario implementare un modello di progettazione disponibile a livello globale e resiliente. Le funzionalità multi-primaria e a ridondanza geografica e le garanzie di latenza integrate in Azure Cosmos DB rendono quest'ultimo una scelta eccellente per questo scenario. Questa API ha le responsabilità principali seguenti:

Gestire l'ambito ID DPS. Questa interfaccia potrebbe usare una richiesta GET. I dispositivi fisici o le applicazioni di gestione si connettono a questa interfaccia.
Supportare il ciclo di vita del dispositivo. Un dispositivo potrebbe richiedere la riassegnazione o possono verificarsi eventi imprevisti. Mantenere almeno l'ID dispositivo e il DPS assegnato per un dispositivo. Usa queste informazioni per eseguire il deprovisioning dal DPS assegnato e ripetere il provisioning su un altro. In alternativa, se il ciclo di vita di un dispositivo è finito, è possibile rimuoverlo completamente dal sistema.
Sistemi di bilanciamento del carico. Il sistema usa gli stessi metadati relativi all'ID del dispositivo e a DPS, in modo da determinare il carico attuale di ciascun sottosistema e usare queste informazioni per bilanciare meglio i dispositivi tra i componenti con scalabilità orizzontale.
Sostenere la sicurezza del sistema. L'API di provisioning deve autenticare ogni richiesta. La procedura consigliata consiste nell'usare un certificato X.509 univoco per ogni dispositivo. Questo certificato può autenticare il dispositivo sia per l'API di provisioning che per l'istanza del servizio Device Provisioning, se l'architettura lo supporta. Altri metodi, ad esempio i certificati della flotta e i token, sono disponibili, ma offrono una minore sicurezza. L'implementazione specifica e le relative implicazioni per la sicurezza dipendono dal fatto che si scelga un'opzione zero-touch o low-touch.

Aumentare il numero di istanze hub IoT

Rispetto alla scalabilità orizzontale del Servizio di provisioning dei dispositivi (DPS), la scalabilità orizzontale di hub IoT è relativamente semplice. Uno dei vantaggi del servizio Device Provisioning è la possibilità di collegarsi a molte istanze di hub IoT. Quando si segue la procedura consigliata per l'uso del Servizio di Provisioning dei Dispositivi nelle soluzioni Azure IoT, espandere la capacità di hub IoT prevede i passaggi seguenti:

Creare una nuova istanza del servizio hub IoT.
Configurare la nuova istanza con le regole di routing appropriate e altri dettagli.
Collegare la nuova istanza alle istanze appropriate del servizio di provisioning dei dispositivi (DPS).
Se necessario, riconfigurare i criteri di allocazione dps o i criteri di allocazione personalizzati.

Progettare il software del dispositivo per la scalabilità

La progettazione scalabile dei dispositivi richiede buone pratiche e considerazioni relative ai dispositivi. Alcune di queste pratiche derivano da anti-pattern che si riscontrano sul campo. Questa sezione descrive i concetti chiave per una distribuzione con scalabilità corretta.

Stimare i carichi di lavoro in diverse parti del ciclo di vita e degli scenari del dispositivo all'interno del ciclo di vita. I carichi di lavoro di registrazione dei dispositivi possono variare notevolmente tra le fasi di sviluppo, ad esempio pilota, sviluppo, produzione, rimozione delle autorizzazioni e fine del ciclo di vita. In alcuni casi, possono anche variare in base a fattori esterni, ad esempio lo scenario di black-out menzionato in precedenza. Progettare il carico di lavoro peggiore per garantire il successo su larga scala.

Supporto per il reprovisioning su richiesta. Fornire questa funzionalità tramite un comando del dispositivo e una richiesta utente amministrativa. Per altre informazioni, vedere Ripristinare la configurazione dei dispositivi. Questa opzione facilita gli scenari di trasferimento della proprietà e gli scenari predefiniti della factory.

Evitare il reprovisioning non necessario. I dispositivi che sono attivi e funzionanti richiedono raramente una nuova fornitura, poiché le informazioni di provisioning rimangono relativamente statiche. Non eseguire il provisioning senza un buon motivo.

Controllare lo stato del provisioning se è necessario eseguire il reprovisioning spesso, ad esempio a ogni avvio del dispositivo. Se non si è certi dello stato del provisioning del dispositivo, eseguire prima una query sullo stato del provisioning . L'operazione di query usa una quota diversa rispetto a un'operazione di provisioning ed è più veloce. Con questa query, il dispositivo può verificare lo stato del provisioning prima di procedere. Questo approccio è particolarmente utile quando un dispositivo non dispone di spazio di archiviazione permanente disponibile per archiviare i risultati del provisioning.

Assicurarsi una buona strategia di logica di ripetizione dei tentativi. Il dispositivo deve disporre di algoritmi di ritentativo integrati appropriati nel codice del dispositivo per il provisioning iniziale e il ri-provisioning. Usare tecniche come il backoff esponenziale con randomizzazione. Il provisioning iniziale, per definizione, potrebbe essere più aggressivo nel processo di ripetizione dei tentativi rispetto al reprovisioning, a seconda del caso d'uso. Quando è limitato, DPS restituisce un codice di errore HTTP 429 Troppe richieste come la maggior parte dei servizi di Azure. Tale risposta includerà talvolta l'intestazione Retry-After per aiutare a determinare i tempi di backoff. Per altre informazioni, vedere Riprovare e Antipattern da evitare. La documentazione DPS illustra anche come interpretare le raccomandazioni per i tentativi di ripetizione del servizio e calcolare il jitter. La stabilità della posizione del dispositivo e l'accesso alla connettività influisce anche sulla strategia di ripetizione dei tentativi appropriata. Ad esempio, se un dispositivo rileva che è offline per un periodo di tempo, è consigliabile evitare di ripetere le operazioni online.

Supporta gli aggiornamenti over-the-air (OTA). Due modelli di aggiornamento semplici includono le proprietà dei dispositivi gemelli con la gestione automatica dei dispositivi e i comandi semplici del dispositivo. Per scenari di aggiornamento e report più sofisticati, vedere Azure Device Update. Con gli aggiornamenti OTA, è possibile correggere i difetti nel codice del dispositivo e riconfigurare i servizi, ad esempio l'ambito ID DPS, se necessario.

Progettare le modifiche dei certificati a tutti i livelli e per tutti gli usi dei certificati. Questa raccomandazione è allineata alle procedure consigliate per l'aggiornamento OTA. È necessario considerare la rotazione dei certificati. La documentazione hub IoT DPS riguarda questo scenario dal punto di vista di un certificato di identità del dispositivo. In una soluzione per dispositivi si usano altri certificati per accedere a servizi come hub IoT, servizio app e account Archiviazione di Azure. Azure talvolta modifica le configurazioni dell'autorità di certificazione, pertanto è necessario prevedere le modifiche a tutti i livelli. Usare anche il pinning dei certificati con cautela, specialmente quando i certificati sono al di fuori del controllo del produttore del dispositivo.

Si consideri uno stato predefinito ragionevole. Per risolvere gli errori di provisioning iniziali, avere una configurazione disconnessa o non con provisioning ragionevole, a seconda delle circostanze. Se il dispositivo ha un componente di interazione significativa come parte della configurazione iniziale, il processo di configurazione può avvenire in background contemporaneamente mentre l'utente esegue altre attività di configurazione. Associa sempre questo approccio con uno schema di ritentativi appropriato e lo Schema Circuit Breaker.

Includere le funzionalità di configurazione dell'endpoint, se appropriato. Consentire la configurazione dell'ambito ID DPS, dell'endpoint DPS o dell'endpoint del servizio di provisioning personalizzato. Anche se l'endpoint DPS cambia raramente, l'abilitazione di questa flessibilità supporta scenari come la convalida automatizzata del processo di provisioning dei dispositivi tramite test di integrazione senza Azure diretta o modelli di provisioning futuri che usano un servizio proxy.

Usare gli SDK Azure IoT per il provisioning. Indipendentemente dal fatto che le chiamate dps si trovino nel dispositivo stesso o in un'API di provisioning personalizzata, usare gli SDK di Azure IoT per trarre vantaggio dalle procedure consigliate predefinite e semplificare il supporto. Gli SDK sono open source, quindi è possibile esaminare il funzionamento e suggerire modifiche. La scelta dell'SDK dipende dall'hardware del dispositivo e dai runtime disponibili nel dispositivo.

Distribuire dispositivi

La distribuzione dei dispositivi è una parte fondamentale del ciclo di vita del dispositivo, ma non rientra nell'ambito di questo articolo perché dipende dal caso d'uso. I punti di discussione a cui si fa riferimento in precedenza sul trasferimento della proprietà possono essere applicati alla distribuzione e ai modelli che coinvolgono un'applicazione di provisioning, ad esempio un'applicazione per dispositivi mobili. È tuttavia necessario selezionare l'approccio di distribuzione in base al tipo di dispositivo IoT in uso.

Monitorare i dispositivi

Una parte importante della distribuzione complessiva consiste nel monitorare la soluzione dall'inizio alla fine per garantire che il sistema esegua in modo appropriato. Questo articolo è incentrato in modo esplicito sull'architettura e sulla progettazione e non sugli aspetti operativi della soluzione, quindi non copre il monitoraggio approfondito. Tuttavia, a livello generale, Azure fornisce strumenti di monitoraggio predefiniti tramite Monitoraggio di Azure per aiutare un operatore a garantire che la soluzione non raggiunga i limiti. Per altre informazioni, vedere gli articoli seguenti:

Usare questi strumenti singolarmente o come parte di una soluzione SIEM (Security Information and Event Management) più sofisticata, ad esempio Microsoft Sentinel.

Usare i modelli di monitoraggio seguenti per monitorare l'utilizzo del servizio Device Provisioning nel tempo:

Creare un'applicazione che esegue query su ogni gruppo di registrazione in un'istanza del servizio Device Provisioning, recupera i dispositivi totali registrati in tale gruppo e quindi aggrega i numeri da diversi gruppi di registrazione. Questo metodo fornisce un conteggio esatto dei dispositivi attualmente registrati tramite DPS e consente di monitorare lo stato del servizio.
Monitorare le registrazioni dei dispositivi in un periodo specifico. Ad esempio, è possibile monitorare i tassi di registrazione per un'istanza DPS negli ultimi cinque giorni. Questo approccio fornisce solo una cifra approssimativa e si applica solo a un periodo di tempo impostato.

Considerazioni chiave per il ridimensionamento di una soluzione IoT

La scalabilità orizzontale di una soluzione IoT per supportare milioni o anche centinaia di milioni di dispositivi richiede un'attenta pianificazione. È necessario considerare molti fattori e vari modi per risolvere i problemi che si verificano su tali scale. Questo articolo riepiloga i principali problemi e fornisce approcci per risolvere tali problemi in una distribuzione corretta.

Collaboratori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autore principale:

Michael C. Bazarewsky | Senior Customer Engineer, Microsoft Azure CXP

Altri contributori:

David Crook | Principal Customer Engineering Manager, Microsoft Azure CXP
Alberto Gorni | Ex Senior Customer Engineer, Microsoft Azure CXP

Per visualizzare i profili di LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-09-02