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

Articolo
2025-02-09

Questo articolo descrive come ridimensionare una soluzione IoT (Internet delle cose) con un modello di scalabilità orizzontale nella piattaforma hub IoT di Azure. Il modello di scalabilità orizzontale risolve le sfide di ridimensionamento aggiungendo istanze all'implementazione, anziché aumentare la dimensione delle istanze. Le linee guida per l'implementazione illustrano come ridimensionare una soluzione IoT con milioni di dispositivi e tenere conto dei limiti del servizio e della sottoscrizione in Azure. L'articolo illustra i modelli di distribuzione a basso intervento e a intervento zero dello schema di scalabilità orizzontale che è possibile adottare a seconda delle esigenze. Vedi questi articoli per ulteriori informazioni:

Nota

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

Raccogliere i requisiti

È consigliabile raccogliere sempre i requisiti prima di implementare una nuova soluzione IoT. Iniziare dai requisiti aiuta a garantire che l'implementazione soddisfi gli obiettivi aziendali. Gli obiettivi aziendali e l'ambiente operativo devono soddisfare i requisiti da raccogliere. Come minimo, è necessario conoscere i requisiti seguenti.

Conoscere i tipi di dispositivi da distribuire. IoT comprende un'ampia gamma di soluzioni, da semplici microcontroller (MCU) a soluzioni SOC (System On Chip) e microprocessore (MPU) di livello medio, a progettazioni complete a livello di PC. Le funzionalità software lato dispositivo influenzano direttamente la progettazione della soluzione.

Sapere quanti dispositivi è necessario distribuire. Alcuni dei principi di base per l'implementazione di soluzioni IoT si applicano a tutte le scale. Conoscere la scalabilità consente di evitare di progettare una soluzione più complessa del necessario. Una soluzione per 1.000 dispositivi avrà alcune differenze fondamentali rispetto a una soluzione per 1 milione di dispositivi. Una soluzione proof-of-concept (PoC) per 10.000 dispositivi potrebbe non essere scalabile a 10 milioni di dispositivi se la scala prevista non è stata considerata all'inizio della progettazione della soluzione.

Conoscere il numero di dispositivi da distribuire consente di scegliere il servizio Azure IoT appropriato. Il ridimensionamento per l'hub IoT e per il servizio di provisioning dei dispositivi nell'hub IoT (DPS) è diverso. Per impostazione predefinita, una singola istanza del servizio Device Provisioning può instradarsi a più istanze di hub IoT. Pertanto, la scalabilità di ogni servizio deve essere considerata singolarmente rispetto al numero di dispositivi. Tuttavia, i limiti non esistono in un vuoto. Se i limiti sono un problema per un servizio, in genere sono un problema per gli altri. Pertanto, i limiti del servizio devono essere considerati distinti, ma correlati, quote.

Documentare le posizioni previste dei dispositivi. Includere non solo la posizione fisica, ma anche la disponibilità dell'alimentazione e la connettività Internet. Una soluzione distribuita in un'unica area geografica, ad esempio solo in America del Nord, è progettata in modo diverso da una soluzione globale. Analogamente, una soluzione IoT industriale distribuita in stabilimenti con potenza a tempo pieno differisce da una soluzione di gestione della flotta distribuita nei veicoli a motore con potenza variabile e posizione. Inoltre, il protocollo usato e la larghezza di banda disponibili per le comunicazioni dei dispositivi, a un gateway o direttamente ai servizi cloud, influiscono sulla scalabilità della progettazione a ogni livello. Nascosto in questo aspetto è la disponibilità della connettività. Si prevede che i dispositivi rimangano connessi ad Azure o vengano eseguiti in modalità disconnessa per periodi prolungati?

Esaminare i requisiti di localizzazione dei dati. Potrebbero essere previsti requisiti legali, di conformità o dei clienti in cui è possibile archiviare i dati (ad esempio i dati di telemetria) o i metadati (dati relativi ai dati, ad esempio i dispositivi esistenti) per la soluzione. Queste restrizioni, se presenti, sono un input chiave per la progettazione geografica della soluzione.

Determinare i requisiti di scambio dei dati. Una soluzione che invia dati di telemetria di base, ad esempio "temperatura corrente" una volta all'ora è diversa da una soluzione che carica file di esempio da 1 MB ogni 10 minuti. Una soluzione che rappresenta principalmente una soluzione da dispositivo a cloud (D2C) unidirezionale è diversa da una soluzione da dispositivo a cloud 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à (tempo di attività). La progettazione deve coprire sia gli scenari di manutenzione pianificata che i tempi di inattività non pianificati, inclusi gli errori utente, i fattori ambientali e i bug della soluzione. Tali progettazioni devono anche avere 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 permanente di area o attori malintenzionati. Poiché questo articolo è incentrato sulla scalabilità dei dispositivi, esistono solo una quantità limitata di informazioni relative alla disponibilità elevata e al ripristino di emergenza (HA/DR).

Decidere su un modello di locazione cliente (se appropriato). In una soluzione del fornitore di software indipendente multi-tenant in cui lo sviluppatore di soluzioni sta creando una soluzione per i clienti esterni, la progettazione deve tenere conto del modo in cui i dati dei clienti vengono separati e gestiti. Il Centro architetture di Azure illustra i modelli generali e offre indicazioni specifiche per IoT.

Informazioni sui concetti di Azure IoT

Parte della creazione della soluzione consiste nella scelta dei componenti di Azure IoT (e possibilmente di altri servizi di Azure di supporto) usati come parte della soluzione, inclusi i servizi di supporto. Una grande quantità di lavoro viene da un punto di vista dell'architettura, che è l'obiettivo di questo documento. L'uso corretto dei servizi hub IoT di Azure e hub IoT di Azure DPS consente di ridimensionare le soluzioni a milioni di dispositivi.

Hub IoT di Azure

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. Può essere usato da solo o con hub IoT di Azure DPS.

hub IoT di Azure scala in base alla combinazione di funzionalità desiderate e al numero di messaggi al giorno o dati desiderati. Per selezionare il ridimensionamento di un'istanza vengono usati tre input:

Il livello , gratuito, basic o standard, determina quali funzionalità sono 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.
Le dimensioni determinano l'unità base di messaggi e il traffico dati per i messaggi da dispositivo a cloud per l'hub IoT. Le dimensioni massime per un'istanza dell'hub IoT sono pari a 3, che supporta 300 milioni di messaggi al giorno e 1.114,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 legati alle dimensioni e al numero di unità e ai limiti generali delle funzionalità associati al livello, esistono limiti al secondo per la velocità effettiva. Esiste inoltre un limite di 1 milione di dispositivi per ogni istanza di hub IoT come limite flessibile. Anche se si tratta di un limite flessibile, esiste anche un limite rigido. Anche se si intende richiedere un aumento del limite, è consigliabile progettare con il limite flessibile come limite di progettazione per evitare problemi in futuro. I requisiti per lo scambio di dati guidano la soluzione qui. Per altre informazioni, vedere altri limiti.

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

Servizio di provisioning dei dispositivi di Azure IoT Hub

hub IoT di Azure servizio Device Provisioning (DPS) è un servizio helper per hub IoT che consente il provisioning JIT nell'hub IoT corretto senza richiedere l'intervento umano. Ha un limite rigido di 10 istanze DPS per sottoscrizione Azure. Il servizio ha anche un limite rigido di 1 milione di registrazioni per ogni istanza del servizio. È necessario risolvere i limiti del servizio nel limite di progettazione del carico di lavoro per evitare problemi in futuro.

Le istanze del servizio DPS sono geograficamente distribuite, ma per impostazione predefinita hanno un endpoint pubblico globale. È possibile accedere a istanze specifiche tramite l'ambito ID. Poiché le istanze si trovano in aree specifiche e ogni istanza ha un proprio ambito ID, è necessario essere in grado di configurare l'ambito ID per i dispositivi.

Comprendere i concetti relativi alla resilienza condivisa

Alcuni concetti critici relativi alla resilienza condivisa da considerare sono la gestione degli errori temporanei, l'impatto sulla posizione dei dispositivi e, per gli ISV, la resilienza dei dati SaaS (Software as a Service).

Comprendere la gestione degli errori temporanei. Qualsiasi soluzione distribuita di produzione, sia locale che nel cloud, deve essere in grado di eseguire il ripristino da errori temporanei (temporanei). Gli errori temporanei vengono talvolta considerati più probabili in una soluzione cloud a causa di:

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

Come descritto nel Centro architetture di Azure, per la gestione degli errori temporanei è necessaria una funzionalità di ripetizione dei tentativi integrata nel codice del dispositivo. Esistono più strategie di ripetizione dei tentativi (ad esempio, backoff esponenziale con casualizzazione, noto anche come backoff esponenziale con jitter) descritte in Gestione degli errori temporanei. Questo articolo si riferisce a questi modelli senza ulteriori spiegazioni. Fare quindi riferimento a questa pagina se non si ha familiarità con loro.

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

Fonte di alimentazione di un dispositivo. I dispositivi o i dispositivi basati sulla batteria basati su fonti temporanee, ad esempio solare o eolico, potrebbero avere una connettività di rete inferiore rispetto ai dispositivi con tecnologia line-time a tempo pieno.
Percorso di distribuzione di un dispositivo. I dispositivi che si trovano nelle impostazioni della fabbrica urbana hanno probabilmente una connettività di rete migliore rispetto ai dispositivi che si trovano 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.

Tutti questi problemi influiscono anche sulla tempistica della disponibilità e della connettività dei dispositivi. Ad esempio, i dispositivi basati su linea ma comuni in ambienti urbani densi (come gli smart speaker) potrebbero vedere un numero elevato di dispositivi offline contemporaneamente e quindi tornare online tutti contemporaneamente. Gli scenari possibili includono i seguenti:

Un blackout, durante il quale 1 milione di dispositivi potrebbero essere tutti offline contemporaneamente e tornare online contemporaneamente a causa della perdita di rete elettrica e della riconnessione. Questo scenario si applica sia negli scenari consumer (ad esempio smart speaker) che in scenari IoT aziendali e industriali (ad esempio termostati connessi e basati su linea che segnalano a una società di gestione immobiliare).
Un intervallo di tempo breve, un onboarding su larga scala, ad esempio Black Friday o Natale, quando molti consumatori accendono i dispositivi per la prima volta in un periodo di tempo relativamente breve.
Aggiornamenti pianificati dei dispositivi, quando molti dispositivi ricevono un aggiornamento in un breve intervallo di tempo e tutti si riavviano con il nuovo aggiornamento contemporaneamente.

A causa dello scenario di avvio simultaneo di molti dispositivi, i problemi del servizio cloud possono influire anche sugli scenari con connettività di rete quasi al 100%, come per esempio la strozzatura (regolazione del traffico consentito a un servizio).

Oltre ai problemi di rete e quota, è anche necessario considerare le interruzioni del servizio di Azure. Potrebbero trattarsi di interruzioni del servizio o interruzioni a livello di area. Mentre alcuni servizi ( ad esempio hub IoT) sono con ridondanza geografica, altri servizi (ad esempio DPS) archiviano i dati in una singola area. Anche se potrebbe sembrare che limiti la ridondanza a livello di area, è importante tenere presente che è possibile collegare un singolo hub IoT a più istanze del servizio Device Provisioning.

Se la ridondanza regionale è una preoccupazione, utilizzare il modello geode, che consente di ospitare un gruppo eterogeneo di risorse in diverse aree geografiche. Analogamente, un marcatore di distribuzione (noto anche come marcatore di scala) applica questo modello per gestire più carichi di lavoro o clienti. Per altre informazioni, vedere Modelli di stamp di distribuzione.

Comprendere l'impatto sulla posizione del dispositivo. Quando gli architetti selezionano componenti, devono anche comprendere che la maggior parte dei servizi di Azure è a livello di area, anche quelli come DPS con endpoint globali. Le eccezioni includono Gestione traffico di Azure e Microsoft Entra ID. Le decisioni prese per la posizione del dispositivo, la posizione dei dati e la posizione dei metadati (dati relativi ai dati, ad esempio i gruppi di risorse di Azure) sono input importanti nella progettazione.

Posizione del dispositivo. I requisiti per la posizione del dispositivo influiscono sulla selezione a livello di area perché influisce sulla latenza transazionale.
Posizione dei dati. La posizione dei dati è associata alla posizione del dispositivo, che è soggetta anche a problemi di conformità. Ad esempio, una soluzione che archivia i dati per uno stato nel Stati Uniti potrebbe richiedere l'archiviazione dei dati nell'area geografica degli Stati Uniti. 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, poiché 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.

Azure Cloud Adoption Framework include indicazioni sulla selezione a livello di area.

Informazioni sulle problematiche SaaS del fornitore di software indipendente (ISV). Come offerta SaaS isv, è importante soddisfare le aspettative dei clienti in termini di disponibilità e resilienza. Gli ISV devono progettare i servizi di Azure a disponibilità elevata e devono considerare il costo della resilienza e della ridondanza durante la fatturazione del cliente.

Separare il costo delle merci vendute (COGS) in base alla separazione dei dati dei clienti per ogni cliente software. Questa distinzione è importante quando l'utente finale non è uguale al cliente. Ad esempio, in una piattaforma smart TV, il cliente del fornitore della piattaforma potrebbe essere il fornitore televisivo, ma l'utente finale è l'acquirente della televisione. Questa separazione, guidata dal modello di tenancy del cliente derivato dai requisiti, richiede istanze separate di DPS e IoT Hub. Il servizio di provisioning deve avere anche un'identità univoca del cliente, che può essere indicata tramite un processo di autenticazione univoco di endpoint o dispositivo. Per ulteriori informazioni, vedere Linee guida multitenant IoT.

Espandere i componenti con servizi di supporto

Quando si parla di ridimensionamento delle soluzioni IoT, è opportuno esaminare ogni servizio e come possono interrelate. È possibile ridimensionare la soluzione IOT in più istanze del servizio Device Provisioning o usando l'hub IOT di Azure.

Scalabilità orizzontale tra più istanze del servizio Device Provisioning

Dato i limiti del servizio DPS, è spesso necessario espandere a più istanze DPS. Esistono diversi modi per affrontare i provisioning dei dispositivi in più istanze del servizio Device Provisioning, che si suddividono in due categorie generali: provisioning zero-touch e low-touch.

Tutti gli approcci seguenti applicano il concetto "stamp" descritto in precedenza per la resilienza e per l'aumento del numero di istanze. Questo approccio include la distribuzione di App Service di Azure in più aree con uno strumento come Gestione traffico di Azure o il servizio di bilanciamento del carico globale. Per semplicità, non è illustrato nei diagrammi seguenti.

(1) Provisioning zero-touch con più istanze del servizio Device Provisioning: per il provisioning automatico (automatizzato), una strategia collaudata è che il dispositivo richieda un ambito ID DPS da un'API Web, che comprende e bilancia i dispositivi tra le istanze del servizio Device Provisioning con scalabilità orizzontale. Questa azione rende l'app Web una parte fondamentale del processo di provisioning, pertanto deve essere scalabile e a disponibilità elevata. Esistono tre varianti principali di questa progettazione.

Il diagramma seguente illustra la prima opzione: usando un'API di provisioning personalizzata che gestisce il mapping del dispositivo al pool dps appropriato, che a sua volta esegue il mapping (tramite meccanismi di bilanciamento del carico DPS standard) all'istanza di hub IoT appropriata:

Il dispositivo effettua una richiesta a un'API di provisioning ospitata nel servizio app Azure per richiedere un ambito ID DPS. L'API di provisioning verifica con il suo database persistente per determinare a quale istanza sia meglio assegnare il dispositivo, basandosi sull'inventario dei dispositivi esistente, e restituisce l'ambito dell'ID DPS. In questo caso, il database proposto è un'istanza di Azure Cosmos DB con scrittura multimaster abilitata (per la disponibilità elevata tra aree) che archivia il servizio Device Provisioning assegnato a ogni dispositivo. È quindi possibile usare questo database per tenere traccia dell'utilizzo delle istanze del servizio Device Provisioning per tutte le metriche appropriate, ad esempio le richieste di provisioning al minuto, i dispositivi con provisioning totale e così via. Questo database consente anche di fornire un riprovisionamento nello stesso ambito dell'ID DPS, se necessario. Autenticare l'API di provisioning per impedire richieste di provisioning inadeguate.
Il dispositivo effettua una richiesta sul DPS (servizio di provisioning dei dispositivi) con l'ambito ID assegnato. Dps restituisce i dettagli al dispositivo a cui deve essere assegnato l'hub IoT.
Il dispositivo memorizza l'ambito ID e le informazioni di connessione dell'hub IoT nell'archiviazione permanente, idealmente in una posizione di archiviazione protetta, poiché l'ambito ID fa parte dell'autenticazione contro l'istanza del servizio Device Provisioning. 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 microcontroller, in cui le dimensioni del software del dispositivo sono un componente fondamentale della progettazione, potrebbe non essere accettabile, che porterebbe a un'altra progettazione.

(2) Provisioning zero-touch con un'API di provisioning: il secondo progetto sposta la chiamata DPS all'API di provisioning. In questo modello l'autenticazione del dispositivo rispetto al servizio Device Provisioning è contenuta nell'API di provisioning, come la maggior parte della logica di ripetizione dei tentativi. Questo processo consente scenari di accodamento più avanzati e codice di provisioning potenzialmente più semplice nel dispositivo stesso. Consente inoltre di memorizzare nella cache l'hub IoT assegnato per facilitare la messaggistica da cloud a dispositivo più veloce. I messaggi vengono inviati senza la necessità di interrogare dps per le informazioni dell'hub assegnate:

Il dispositivo effettua una richiesta a un'API di provisioning ospitata in un'istanza del servizio app Azure. L'API di provisioning verifica nel database permanente quale sia l'istanza migliore alla quale assegnare il dispositivo, basandosi sull'inventario dei dispositivi esistente, e quindi stabilisce la portata dell'ID DPS. In questo caso, il database proposto è un'istanza di Azure Cosmos DB con scrittura multimaster abilitata (per la disponibilità elevata tra aree) che archivia il servizio Device Provisioning assegnato a ogni dispositivo. È quindi possibile usare questo database per tenere traccia dell'uso delle istanze del servizio Device Provisioning per tutte le metriche appropriate, ad esempio le richieste di provisioning al minuto, i dispositivi con provisioning totale e così via. Il database permette anche di inviare una richiesta di riprovisioning utilizzando lo stesso ambito ID DPS, se appropriato. Autenticare l'API di provisioning in qualche modo per evitare richieste di provisioning non appropriate. È probabile che questa operazione venga eseguita usando la stessa autenticazione usata dal servizio di provisioning su DPS, ad esempio con una chiave privata per un certificato emesso. Ma sono possibili altre opzioni. Ad esempio, FastTrack per Azure (FTA) ha collaborato con un cliente che usa identificatori univoci hardware come parte del 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 con l'ambito ID assegnato, fungendo efficacemente da proxy per DPS.
I risultati del servizio Device Provisioning vengono inoltrati al dispositivo.
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 le richieste successive nel sistema.

Questa progettazione evita la necessità di fare riferimento a DPS SDK o al servizio DPS. Evita inoltre la necessità di archiviare o mantenere un ambito dps nel dispositivo. Consente il trasferimento della proprietà poiché di conseguenza il servizio di provisioning può indirizzare all'istanza finale appropriata di DPS. Tuttavia, fa sì che l'API di provisioning duplichi in qualche misura il concetto di DPS, il che potrebbe non essere l'ideale.

(3) Provisioning zero-touch con trasferimento di proprietà: una terza possibile progettazione del provisioning zero-touch consiste nell'usare un'istanza del servizio di provisioning device configurata in fabbrica come punto di partenza e quindi reindirizzare in base alle esigenze ad altre istanze del servizio di provisioning device. Questa progettazione consente 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. È possibile usare questo approccio per gli scenari di "trasferimento della proprietà", in cui il fornitore del dispositivo trasferisce la proprietà del dispositivo dal fornitore 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 archivia quindi le informazioni di connessione dell'hub IoT nell'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.

(4) Provisioning a basso intervento con più istanze DPS In alcuni casi, ad esempio in scenari rivolti ai clienti o con dispositivi del team di distribuzione sul campo, una scelta comune consiste nell'offrire il provisioning a basso intervento (assistito dall'utente). Esempi di provisioning a basso tocco includono un'applicazione per dispositivi mobili nel telefono di un programma di installazione o un'applicazione basata sul Web in un gateway dispositivo. In questo caso, l'approccio comprovato consiste nell'eseguire le stesse operazioni del processo di provisioning senza contatto, 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 Azure per richiedere un ambito ID DPS. L'API di provisioning controlla il database persistente per determinare quale istanza sia più appropriata per assegnare il dispositivo, in base all'inventario dei dispositivi esistente, e restituisce lo scope dell'ID DPS. In questo caso, il database proposto è un'istanza di Azure Cosmos DB con scrittura multimaster abilitata (per la disponibilità elevata tra aree) che archivia il servizio Device Provisioning assegnato a ogni dispositivo. Questo database può quindi essere usato per tenere traccia dell'utilizzo delle istanze del servizio Device Provisioning per tutte le metriche appropriate, ad esempio le richieste di provisioning al minuto e i dispositivi con provisioning totale. Questo database consente anche di fornire un nuovo provisioning con lo stesso ambito ID DPS, se appropriato. L'API di provisioning deve essere autenticata in qualche modo per evitare che le richieste di provisioning non appropriate vengano gestite.
L'app restituisce l'ambito dell'ID di provisioning al dispositivo.
Il dispositivo effettua una richiesta al servizio Device Provisioning Service (DPS) con l'ambito ID assegnato. Dps restituisce i dettagli al dispositivo a cui deve essere assegnato l'hub IoT.
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.

Esistono altre possibili varianti non descritte in questo articolo. Ad esempio, è possibile configurare l'architettura illustrata qui spostando la chiamata DPS all'API di provisioning, come illustrato 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 di DPS: Dovreste applicare le seguenti raccomandazioni alla distribuzione del vostro DPS, che rappresentano le migliori pratiche generali per questo servizio di Azure.

Non eseguire il provisioning a ogni avvio. La documentazione del servizio Device Provisioning specifica che la procedura consigliata non consiste nel effettuare il provisioning in ogni avvio. Per i casi d'uso di piccole dimensioni, potrebbe sembrare ragionevole configurare il sistema ad ogni avvio, perché questo è il percorso più breve per la distribuzione. Tuttavia, quando si scala fino a milioni di dispositivi, DPS può diventare un collo di bottiglia, dato il limite rigido di 1.000 registrazioni al minuto per ogni istanza del servizio. Anche la ricerca dello stato di registrazione del dispositivo può costituire un collo di bottiglia perché ha un limite di 5-10 operazioni di interrogazione al secondo. I risultati del provisioning sono in genere una mappatura statica a un hub IoT. Pertanto, a meno che i requisiti non includano richieste di reprovisioning automatizzato, è consigliabile eseguirle solo su richiesta. Se si prevede un maggior traffico, l'aumento del numero di istanze del servizio Device Provisioning in più istanze potrebbe essere l'unico modo per supportare tali scenari.

Usare una pianificazione di provisioning scaglionata. Una raccomandazione per ridurre alcune delle limitazioni basate sul tempo consiste nell'usare un programma di provisioning scaglionato. Per un provisioning iniziale, a seconda dei requisiti di distribuzione, questa pianificazione potrebbe essere basata su un offset casuale di alcuni secondi o potrebbe essere un massimo di molti minuti.

Verificare sempre lo stato prima di richiedere un 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 attualmente conteggiata come articolo fatturato e il limite è indipendente dal limite di registrazione. L'operazione di query è relativamente rapida rispetto a una richiesta di provisioning, il che significa che il dispositivo può convalidarne lo stato e passare al normale carico di lavoro del dispositivo più rapidamente. La logica di registrazione del dispositivo appropriata è documentata nella documentazione sulla distribuzione su larga scala.

Segui le considerazioni relative all’API di provisioning. Alcune delle progettazioni proposte 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à, è consigliabile implementare un modello di progettazione disponibile a livello globale e resiliente, un modello valido per questa API e il backup dell'archivio dati. Le funzionalità multimaster, con ridondanza geografica e le garanzie di latenza predefinite in Azure Cosmos DB lo rendono una scelta eccellente per questo scenario. Le responsabilità principali di questa API includono:

Gestire l'ambito ID DPS. Questa interfaccia potrebbe essere una richiesta GET. Tenere presente che i dispositivi fisici o l'applicazione di gestione si connettono a questa interfaccia.
Supportare il ciclo di vita del dispositivo. Potrebbe essere necessario eseguire nuovamente il provisioning di un dispositivo oppure può verificarsi un altro evento imprevisto. Come minimo, è fondamentale mantenere l'ID dispositivo e assegnare dps per un dispositivo. In questo modo, è possibile eseguire il deprovisioning dal servizio Device Provisioning assegnato e ripetere il provisioning in un altro. In alternativa, se il ciclo di vita di un dispositivo è finito, è possibile rimuoverlo completamente dal sistema.
Sistemi di bilanciamento del carico. Usando gli stessi metadati relativi a ID dispositivo e DPS, è più semplice comprendere il carico corrente in ogni sottosistema e applicare tali informazioni per bilanciare meglio i dispositivi tra i componenti con scalabilità orizzontale.
Sostenere la sicurezza del sistema. Come accennato in precedenza, l'API di provisioning deve autenticare ogni richiesta. La procedura consigliata consiste nell'usare un certificato X.509 univoco per dispositivo, che può eseguire l'autenticazione sia per l'API di provisioning che per l'istanza dps, se l'architettura la supporta. Altri metodi, ad esempio i certificati della flotta e i token, sono disponibili ma considerati meno sicuri. La modalità di implementazione specifica, insieme alle implicazioni di sicurezza dell'implementazione, dipende dal fatto che si selezioni un tocco zero o un'opzione a basso tocco.

La scalabilità orizzontale dell'hub IoT di Azure

Rispetto alla scalabilità orizzontale del servizio Device Provisioning, la scalabilità orizzontale hub IoT di Azure è relativamente semplice. Come accennato in precedenza, uno dei vantaggi del servizio Device Provisioning è che un'istanza può essere collegata a molte istanze di hub IoT. Se il servizio Device Provisioning viene usato come consigliato per tutte le soluzioni Azure IoT, la scalabilità orizzontale dell'IoT Hub consiste in:

Creazione di una nuova istanza del servizio hub IoT.
Configurazione della nuova istanza con il routing appropriato e altri dettagli.
Collegamento della nuova istanza alle istanze del servizio Device Provisioning appropriate.
Se necessario, riconfigurare i criteri di allocazione dps o i criteri di allocazione personalizzati.

Progettare il software del dispositivo

Esistono molte procedure consigliate da seguire e considerazioni sul lato dispositivo per la progettazione scalabile dei dispositivi. Alcuni di essi sono direttamente derivati da antipattern esperienze 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 (pilota, sviluppo, produzione, rimozione delle autorizzazioni, fine della vita). In alcuni casi, possono anche variare in base a fattori esterni, ad esempio lo scenario di black-out menzionato in precedenza. La progettazione per il carico di lavoro "peggiore" consente di garantire il successo su larga scala.

Supportare il reprovisioning su richiesta. È possibile offrire questa funzionalità tramite un comando del dispositivo e una richiesta utente amministrativa, menzionata nella documentazione del prodotto. Questa opzione consente di trasferire scenari di proprietà e scenari predefiniti di fabbrica.

Non eseguire il provisioning quando non è necessario. È insolito che un dispositivo attivo e funzionante nel campo richieda il reprovisioning perché le informazioni di provisioning sono relativamente statiche. Non riprovvisionare senza un buon motivo.

Controllare lo stato del provisioning se è necessario eseguire il ri-provisioning spesso, ad esempio a ogni avvio del dispositivo. Se lo stato del provisioning del dispositivo è in dubbio, iniziare eseguendo prima una query sullo stato del provisioning. L'operazione di query viene gestita rispetto a una quota diversa da quella di un'operazione di provisioning ed è un'operazione più veloce del provisioning. Questa query consente al dispositivo di convalidare lo stato del provisioning prima di proseguire. Potresti incontrare una situazione, ad esempio, quando un dispositivo non dispone di memoria persistente disponibile per archiviare i risultati del provisioning.

Assicurarsi una buona strategia di logica di ripetizione dei tentativi. Il dispositivo deve avere algoritmi di ripetizione dei tentativi appropriati incorporati nel codice del dispositivo sia per il provisioning iniziale che per il reprovisioning successivo, ad esempio il "backoff esponenziale con randomizzazione". Questi scenari potrebbero essere diversi per i due casi d'uso. Il provisioning iniziale, per definizione, potrebbe essere più aggressivo nel processo di ripetizione dei tentativi rispetto al reprovisioning, a seconda del caso d'uso. Se limitato, DPS restituisce un codice di errore HTTP 429 ("Troppe richieste"), come la maggior parte dei servizi di Azure. Il Centro architetture di Azure include indicazioni sulla ripetizione dei tentativi e, soprattutto, sugli anti-pattern per evitare scenari di ripetizione dei tentativi. La documentazione DPS contiene anche informazioni su come conoscere quale intervallo di ritentativo raccomanda il servizio e come calcolare un jitter appropriato come parte delle linee guida per il ridimensionamento. 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 è noto come offline per periodi di tempo e il dispositivo può rilevare che è offline, non c'è alcun punto di riprovare le operazioni online mentre il dispositivo è offline.

Supporta gli aggiornamenti via etere (OTA). Due modelli di aggiornamento semplici sono l'uso di proprietà del dispositivo gemello con la gestione automatica dei dispositivi e l'uso di semplici comandi del dispositivo. Per scenari di aggiornamento e report più sofisticati, vedere l'anteprima del servizio Aggiornamento dispositivi di Azure. Gli aggiornamenti OTA consentono la correzione dei difetti nel codice del dispositivo e per la riconfigurazione fondamentale del servizio (ad esempio, ambito ID DPS) se necessario.

Architetto per le modifiche al certificato a tutti i livelli e a tutti i certificati usati. Questa raccomandazione è associata alla procedura consigliata per l'aggiornamento OTA. È necessario considerare la rotazione dei certificati. La documentazione del servizio Device Provisioning hub IoT tocca questo scenario dal punto di vista di un certificato di identità del dispositivo. È tuttavia importante ricordare che, nell'ambito di una soluzione per dispositivi, vengono utilizzati altri certificati, come per l'accesso a IoT Hub, l'accesso al servizio app e l'accesso all'account di Azure Storage. La modifica del certificato radice nella piattaforma Azure mostra che è necessario prevedere le modifiche a tutti i livelli. Usare anche l'aggiunta di certificati con cautela, in particolare quando i certificati non rientrano nel controllo del produttore del dispositivo.

Considerare 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. In ogni caso, l'uso di un valore predefinito implica l'impiego di un modello di ripetizione dei tentativi adeguato e l'uso appropriato del pattern architetturale dell'interruttore.

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. L'endpoint DPS non dovrebbe cambiare, ma poiché è possibile modificarlo nel dispositivo, è possibile avere una maggiore flessibilità. Si consideri ad esempio il caso della convalida automatizzata del processo di provisioning dei dispositivi tramite test di integrazione senza accesso diretto ad Azure. In alternativa, considerare la possibilità di scenari di provisioning futuri che non sono disponibili oggi, ad esempio tramite un servizio di proxy di provisioning.

Usare gli SDK di Azure IoT per il provisioning. Indipendentemente dal fatto che le chiamate dps si trovino nel dispositivo stesso o in un'API di provisioning personalizzata, l'uso degli SDK di Azure IoT significa ottenere alcune procedure consigliate nell'implementazione "gratuitamente" e consente esperienze di supporto più pulite. Poiché gli SDK sono tutti open source pubblicati, è possibile esaminare il funzionamento e suggerire modifiche. La combinazione dell'hardware del dispositivo che selezioni e dei runtime disponibili sul dispositivo determina principalmente quale SDK scegli.

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à" potrebbero essere applicati alla distribuzione e ai modelli che coinvolgono un'applicazione di provisioning (ad esempio, un'applicazione per dispositivi mobili), ma la si seleziona 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 assicurarsi che il sistema esegua in modo appropriato. Poiché questo articolo è incentrato in modo esplicito sull'architettura e sulla progettazione e non sugli aspetti operativi della soluzione, discutere il monitoraggio in dettaglio non rientra nell'ambito. Tuttavia, a livello generale, gli strumenti di monitoraggio sono integrati in Azure tramite Monitoraggio di Azure per garantire che la soluzione non raggiunga i limiti. Per informazioni dettagliate, vedere questi articoli:

È possibile usare questi strumenti singolarmente o come parte di una soluzione SIEM (Security Information and Event Management) più sofisticata come Microsoft Sentinel.

La documentazione include i modelli di monitoraggio seguenti per il monitoraggio dell'utilizzo del servizio Device Provisioning nel tempo:

Creare un'applicazione per eseguire query su ogni gruppo di registrazione in un'istanza del servizio Device Provisioning, ottenere i dispositivi totali registrati in tale gruppo e quindi aggregare i numeri da diversi gruppi di registrazione. Questo numero fornisce un conteggio esatto dei dispositivi attualmente registrati tramite DPS e può essere usato per monitorare lo stato del servizio.
Monitorare le registrazioni dei dispositivi in un periodo specifico. Ad esempio, monitorare i tassi di registrazione per un'istanza DPS nei cinque giorni precedenti. Questo approccio fornisce solo una figura approssimativa e viene limitato a un periodo di tempo impostato.

Conclusione

L'aumento delle prestazioni di una soluzione IoT per supportare milioni o persino decine o centinaia di milioni di dispositivi non è un'attività semplice. Esistono molti fattori da considerare e vari modi per risolvere i problemi che si verificano su tali scale. In questo articolo vengono riepilogati i problemi e gli approcci forniti per risolvere tali problemi in una distribuzione corretta.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

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

Altri contributori:

David Crook | Principal Customer Engineer, Microsoft Azure CXP G&I
Alberto Gorni | Senior Customer Engineer

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

Passaggi successivi

Esaminare le linee guida del gruppo di prodotti per le procedure consigliate per le distribuzioni di dispositivi Microsoft Azure IoT su larga scala
Esaminare le informazioni di ripristino nel Cloud Adoption Framework

Condividi tramite