Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Durante il ciclo di vita di una soluzione IoT, è comune spostare i dispositivi tra hub IoT. I motivi di questo spostamento possono includere gli scenari seguenti:
Georilevazione/GeoLatency: quando un dispositivo si sposta tra le posizioni, la latenza della rete viene migliorata migrando il dispositivo su un hub IoT più vicino.
Multi-tenancy: un dispositivo può essere usato all'interno della stessa soluzione IoT e riassegnato a un nuovo cliente o sito del cliente. Questo nuovo cliente potrebbe essere gestito usando un hub IoT diverso.
Modifica della soluzione: è stato possibile spostare un dispositivo in una soluzione IoT nuova o aggiornata. Questa riassegnazione potrebbe richiedere al dispositivo di comunicare con un nuovo hub IoT connesso ad altri componenti back-end.
Quarantena: simile a una modifica della soluzione. Un dispositivo che non funziona correttamente, compromesso o non aggiornato potrebbe essere riassegnato a un hub IoT in grado di aggiornare e ripristinare la conformità. Una volta che il dispositivo funziona correttamente, viene quindi migrato nuovamente al suo hub principale.
Il supporto di reprovisioning all'interno del Device Provisioning Service risponde a queste esigenze. I dispositivi possono essere automaticamente riassegnati al nuovo hub IoT in base al criterio di reprovisioning configurato nella voce di registrazione del dispositivo.
Dati relativi allo stato del dispositivo
I dati relativi allo stato del dispositivo sono costituiti dal dispositivo gemello e dalle funzionalità del dispositivo. Questi dati vengono archiviati nell'istanza del servizio Device Provisioning e nell'hub IoT al quale un dispositivo viene assegnato.
Quando un dispositivo viene inizialmente sottoposto a provisioning con un'istanza del servizio Device Provisioning, vengono eseguiti i passaggi seguenti:
Il dispositivo invia una richiesta di provisioning all'istanza del servizio Device Provisioning. L'istanza del servizio autentica l'identità del dispositivo basata su una voce di registrazione e crea la configurazione iniziale dei dati sullo stato del dispositivo. L'istanza del servizio assegna il dispositivo a un hub IoT in base alla configurazione della registrazione e restituisce l'assegnazione dell'hub IoT al dispositivo.
L'istanza del servizio di provisioning restituisce una copia di tutti i dati sullo stato iniziale del dispositivo all'hub IoT assegnato. Il dispositivo si connette all'hub Iot assegnato e inizia le operazioni.
Nel corso del tempo, le operazioni dei dispositivi e le operazioni back-end potrebbero aggiornare i dati sullo stato del dispositivo nell'hub IoT. Le informazioni sullo stato iniziale del dispositivo archiviate nell'istanza del servizio Device Provisioning rimangono inalterate. Questi dati inalterati sullo stato del dispositivo sono la configurazione iniziale.
A seconda dello scenario, quando un dispositivo passa tra hub IoT, potrebbe anche essere necessario eseguire la migrazione dello stato del dispositivo aggiornato nell'hub IoT precedente al nuovo hub IoT. I criteri di reprovisioning nel Servizio di provisioning dei dispositivi possono supportare questa migrazione.
Criteri di reprovisioning
A seconda dello scenario, un dispositivo potrebbe inviare una richiesta a un'istanza del servizio di provisioning al riavvio. Supporta anche un metodo per l'attivazione manuale del provisioning su richiesta. I criteri per rieffettuare il provisioning su una voce di registrazione determinano il modo in cui l'istanza del servizio Device Provisioning gestisce queste richieste di provisioning e stabilisce se i dati sullo stato del dispositivo devono essere migrati durante il nuovo provisioning. Gli stessi criteri sono disponibili per le registrazioni individuali e di gruppi:
Rieffettuare il provisioning e la migrazione dei dati: questo criterio è il valore predefinito per le nuove voci di registrazione. Questi criteri intervengono quando i dispositivi associati alla voce di registrazione presentano una nuova richiesta (1). A seconda della configurazione delle impostazioni di registrazione, il dispositivo potrebbe essere riassegnato a un altro hub IoT. Se il dispositivo sta cambiando gli hub IoT, la registrazione del dispositivo con l'hub IoT iniziale viene rimossa. Le informazioni aggiornate sullo stato del dispositivo dall'hub IoT iniziale vengono migrate al nuovo hub IoT (2). Durante la migrazione, lo stato del dispositivo viene segnalato come Assegnazione.
Rieffettuare il provisioning e ripristinare la configurazione iniziale: questo criterio interviene quando i dispositivi associati alla voce di registrazione presentano una nuova richiesta di provisioning (1). A seconda della configurazione delle impostazioni di registrazione, il dispositivo potrebbe essere riassegnato a un altro hub IoT. Se il dispositivo sta cambiando gli hub IoT, la registrazione del dispositivo con l'hub IoT iniziale viene rimossa. I dati di configurazione iniziali che l'istanza del servizio di provisioning ha ricevuto durante il provisioning del dispositivo vengono forniti al nuovo hub IoT (2). Durante la migrazione, lo stato del dispositivo viene segnalato come Assegnazione.
Questo criterio viene spesso usato per il ripristino senza modificare l'hub IoT.
Mai rieseguire il provisioning: il dispositivo non viene mai riassegnato a un hub diverso. Questo criterio viene fornito per gestire la compatibilità con le versioni precedenti.
Note
DPS chiamerà sempre il webhook di allocazione personalizzato indipendentemente dal criterio di reprovisioning nel caso in cui sia presente un nuovo ReturnData per il dispositivo. Se il criterio di reprovisioning è impostato su non eseguire mai il reprovisioning, il webhook viene chiamato ma il dispositivo non modifica l'hub assegnato.
Durante la progettazione della tua soluzione e la definizione di una logica per il riapprovvigionamento, è necessario tenere in considerazione alcuni fattori. Ad esempio:
- Frequenza con cui si prevede che i dispositivi vengano riavviati
- Le quore e i limiti del servizio Device Provisioning
- Tempo di distribuzione previsto per la flotta (implementazione in più fasi e tutte contemporaneamente)
- Funzionalità di ripetizione dei tentativi implementata nel codice client, come descritto nelle linee guida generali per i tentativi nel Centro architetture di Azure
Suggerimento
È consigliabile non effettuare il provisioning in ogni riavvio del dispositivo, perché questa azione potrebbe causare alcuni problemi durante il provisioning di diverse migliaia o milioni di dispositivi contemporaneamente. È invece consigliabile provare a usare l'API Device Registration Status Lookup e provare a connettersi con tali informazioni all’hub IoT. In caso di errore, provare a eseguire nuovamente il provisioning perché le informazioni sull'hub IoT potrebbero cambiare. Tenere presente che l'esecuzione di query sullo stato di registrazione viene conteggiato come nuova registrazione del dispositivo, pertanto è consigliabile considerare il limite di registrazione del dispositivo. Prendere in considerazione anche l'implementazione di una logica di ripetizione dei tentativi appropriata, ad esempio il back-off esponenziale con randomizzazione, come descritto nelle indicazioni generali sui tentativi. In alcuni casi, a seconda delle funzionalità del dispositivo, è possibile salvare le informazioni dell'hub IoT direttamente nel dispositivo per connettersi direttamente all'hub IoT dopo il primo provisioning tramite DPS. Se si sceglie di salvare direttamente nel dispositivo, assicurarsi di implementare un meccanismo di fallback nel caso in cui si verifichino errori specifici dall'hub IoT . Prendere ad esempio in considerazione i seguenti scenari:
- Ripetere l'operazione dell'hub IoT se il codice del risultato è 429 (troppe richieste) o un errore nell'intervallo 5xx. Non ripetere nuovi tentativi per altri tipi di errore.
- Per gli errori 429, riprovare solo dopo il tempo indicato nell'intestazione Retry-After.
- Per gli errori 5xx, usare il backoff esponenziale, con il primo tentativo effettuato almeno 5 secondi dopo la risposta.
- In caso di errori diversi da 429 e 5xx, ripetere la registrazione tramite DPS
- Idealmente è consigliabile anche supportare un metodo diretto per attivare manualmente il provisioning su richiesta.
È anche consigliabile tenere conto dei limiti del servizio durante la pianificazione di attività quali l’invio degli aggiornamenti alla flotta. Ad esempio, l'aggiornamento della flotta contemporaneamente potrebbe causare la nuova registrazione di tutti i dispositivi tramite DPS (che potrebbe essere facilmente superiore al limite di quota di registrazione). Per questi scenari, è consigliabile pianificare gli aggiornamenti dei dispositivi in fasi anziché aggiornare l'intera flotta contemporaneamente.
Gestire la compatibilità con le versioni precedenti
Prima di settembre 2018, le assegnazioni dei dispositivi agli hub IoT avevano un carattere definitivo. Quando un dispositivo torna indietro nel processo di provisioning, potrà essere assegnato solo allo stesso hub IoT.
Per le soluzioni che dipendono da questo comportamento, il servizio di provisioning include la compatibilità con le versioni precedenti. Questo comportamento viene mantenuto attualmente per i dispositivi in base ai criteri seguenti:
I dispositivi si connettono con una versione dell'API precedente alla disponibilità del supporto di reprovisioning nativo nel servizio Device Provisioning. Fare riferimento alla tabella API seguente.
Alla voce di registrazione per i dispositivi non sono associati criteri di reprovisioning impostati.
Questa compatibilità garantisce che i dispositivi già distribuiti presentino lo stesso comportamento tenuto durante il test iniziale. Per mantenere il comportamento precedente, non salvare un criterio di reprovisioning su queste registrazioni. Se è impostato un criterio di reprovisioning, quest’ultimo ha la precedenza sul comportamento. Consentendo al criterio di reprovisioning di avere la precedenza, i clienti possono aggiornare il comportamento del dispositivo senza dover ricreare l'immagine del dispositivo.
Il seguente diagramma di flusso aiuta a capire quando è presente il comportamento:
La tabella seguente mostra le versioni dell'API precedenti alla disponibilità del supporto di reprovisioning nativo nel servizio Device Provisioning:
| API REST | SDK per C | Python SDK | Node SDK | SDK per Java | .NET SDK |
|---|---|---|---|---|---|
| 2018-04-01 e versioni precedenti | 1.2.8 e versioni precedenti | 1.4.2 e versioni precedenti | 1.7.3 e versioni precedenti | 1.13.0 e versioni precedenti | 1.1.0 e versioni precedenti |
Note
Questi valori e i collegamenti sono soggetti a modifica. Le versioni degli SDK e delle API IoT di Azure consentono di garantire che le applicazioni e i servizi continuino a funzionare man mano che i prodotti e le API si evolvono. È consigliabile verificare le versioni più recenti degli SDK e delle API IoT di Azure nella documentazione di riferimento per tali SDK e API. Ad esempio, la versione più recente dell'API REST del servizio Device Provisioning in hub IoT di Azure è 2021-10-01.