Concetti di reprovisioning di un dispositivo hub IoT
Durante il ciclo di vita di una soluzione IoT, è comune spostare i dispositivi tra hub IoT. Le ragioni 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 oppure al sito del cliente. Questo nuovo cliente può essere servito 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 collegato ad altri componenti di back-end.
Quarantena: simile a una modifica della soluzione. Un dispositivo malfunzionante, compromesso o obsoleto può essere riassegnato a un hub IoT che può solo 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 i dati sullo stato del dispositivo nell'hub IoT possono essere aggiornati dalle operazioni del dispositivo e le operazioni back-end. 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, mentre un dispositivo si sposta tra gli hub IoT, potrebbe anche essere necessario migrare lo stato del dispositivo aggiornato sul precedente hub IoT sul nuovo hub IoT. Questa migrazione è supportata da nuovi criteri di reprovisioning del servizio Device Provisioning.
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:
Effettuare il reprovisioning e la migrazione dei dati: questo criterio è l'impostazione predefinita 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 della voce di registrazione, il dispositivo può essere riassegnato a un altro hub IoT. Se il dispositivo sta cambiando hub IoT, la registrazione del dispositivo con l'hub IoT iniziale verrà rimossa. Le informazioni sullo stato dei dispositivi aggiornati da tale hub IoT iniziale verranno migrate sul nuovo hub IoT (2). Durante la migrazione, lo stato del dispositivo risulterà come In fase di assegnazione.
Effettuare il reprovisioning e reimpostare la configurazione iniziale: questo criterio esegue un'azione quando i dispositivi associati alla voce di registrazione inviano una nuova richiesta di provisioning (1). A seconda della configurazione della voce di registrazione, il dispositivo può essere riassegnato a un altro hub IoT. Se il dispositivo sta cambiando hub IoT, la registrazione del dispositivo con l'hub IoT iniziale verrà 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 risulterà come In fase di assegnazione.
Questo criterio viene spesso usato per il ripristino senza modificare l'hub IoT.
Non eseguire mai il provisioning: il dispositivo non viene mai riassegnato a un hub diverso. Questo criterio viene fornito per gestire la compatibilità con le versioni precedenti.
Nota
Il servizio Device Provisioning 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 verrà chiamato, ma il dispositivo non modificherà l'hub assegnato.
Quando si progetta la soluzione e si definisce una logica di reprovisioning, è necessario prendere in considerazione alcuni aspetti. Ad esempio:
- Frequenza con cui si prevede che i dispositivi vengano riavviati
- Quote e 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 eseguire il provisioning in ogni riavvio del dispositivo, perché ciò 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 (Ricerca stato registrazione dispositivo) e provare a connettersi a tali informazioni per hub IoT. In caso di errore, provare a eseguire nuovamente il provisioning perché le informazioni hub IoT potrebbero essere state modificate. Tenere presente che l'esecuzione di query per lo stato di registrazione verrà 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 linee guida generali per i tentativi. In alcuni casi, a seconda delle funzionalità del dispositivo, è possibile salvare le informazioni di hub IoT direttamente nel dispositivo per connettersi direttamente al hub IoT dopo il primo provisioning tramite DPS. Se si sceglie di eseguire questa operazione, assicurarsi di implementare un meccanismo di fallback nel caso in cui si verifichino errori specifici dall'hub, ad esempio, considerare gli scenari seguenti:
- Ripetere l'operazione hub 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 supportare anche un metodo per attivare manualmente il provisioning su richiesta.
È anche consigliabile tenere conto dei limiti del servizio durante la pianificazione di attività come il push 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 hanno aggiunto una dipendenza da questo comportamento, il servizio di provisioning include la retrocompatibilità. 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 di seguito.
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:
| REST API | 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 |
Nota
Questi valori e i collegamenti sono soggetti a modifica. Questo è solo un tentativo di segnaposto per determinare dove le versioni possono essere determinate da un cliente e quali saranno le versioni previste.