Spostare una soluzione basata su hub IoT in un ambiente di produzione

Questo articolo fornisce considerazioni chiave che consentono di eseguire la transizione di una soluzione basata su hub IoT di Azure da un ambiente di test a un ambiente di produzione.

Usare i francobolli di distribuzione

I francobolli di distribuzione sono unità discrete di componenti principali della soluzione che supportano un numero definito di dispositivi. Una singola unità è nota come stamp o unità di scala. Un timbro può essere costituito da un popolamento di dispositivi specifico, un hub IoT, un hub eventi o un altro endpoint di routing e un componente di elaborazione. Ogni stampo supporta una popolazione di dispositivi definita. Si sceglie il numero massimo di dispositivi che il timbro può contenere. Al crescere del numero di dispositivi, aggiungi istanze di stamp anziché aumentare in modo indipendente le diverse parti della soluzione.

Se si sposta una singola istanza della soluzione basata su hub IoT nell'ambiente di produzione anziché aggiungere stamp, è possibile che si verifichino le limitazioni seguenti:

  • Limiti di ridimensionamento: La singola istanza può riscontrare limiti di ridimensionamento. Ad esempio, la soluzione potrebbe usare servizi che limitano il numero di connessioni in ingresso, nomi host, socket TCP (Transmission Control Protocol) o altre risorse.

  • Scalabilità non lineare o costo: I componenti della soluzione potrebbero non essere ridimensionati in modo lineare con il numero di richieste o il volume di dati inseriti. Alcuni componenti potrebbero invece riscontrare una riduzione delle prestazioni o un aumento dei costi dopo aver raggiunto una soglia. In questi scenari, è possibile che l'aumento del numero di istanze aggiungendo timbri sia più efficace rispetto all'aumento della capacità.

  • Separazione dei clienti: Potrebbe essere necessario isolare dati specifici dei clienti dai dati di altri clienti. È possibile raggruppare i clienti che hanno esigenze di risorse più elevate su timbri diversi.

  • Istanze a tenant singolo e multi-tenant: Potrebbero essere presenti diversi clienti di grandi dimensioni che necessitano delle proprie istanze indipendenti della soluzione. In alternativa, potrebbe essere disponibile un pool di clienti più piccoli che possono condividere una distribuzione multi-tenant.

  • Requisiti di distribuzione complessi: Potrebbe essere necessario distribuire gli aggiornamenti al servizio in modo controllato e distribuire gli aggiornamenti a timbri diversi in momenti diversi.

  • Frequenza di aggiornamento: È possibile che i clienti possano tollerare aggiornamenti frequenti del sistema, mentre altri clienti potrebbero volere aggiornamenti del servizio poco frequenti.

  • Restrizioni geografiche o geopolitiche: Per ridurre la latenza o rispettare i requisiti di sovranità dei dati, è possibile distribuire alcuni clienti in aree specifiche.

Per evitare questi problemi, è consigliabile raggruppare il servizio in più francobolli. I francobolli operano indipendentemente l'uno dall'altro, quindi è possibile distribuirli e aggiornarli in modo indipendente. Una singola area geografica può contenere un singolo timbro o più francobolli per abilitare la scalabilità orizzontale all'interno dell'area. Ogni timbro contiene un sottoinsieme dei clienti.

Per ulteriori informazioni, vedere il modello Deployment Stamps.

Usare un approccio di back-off quando si verifica un errore temporaneo

È necessario progettare tutte le applicazioni che comunicano con servizi remoti e risorse per gestire gli errori temporanei. Questa funzionalità è particolarmente cruciale negli ambienti cloud, in cui la connettività aumenta la probabilità di errori temporanei. L'elenco seguente fornisce esempi di errori temporanei:

  • Perdita momentanea della connettività di rete ai componenti e ai servizi
  • Indisponibilità temporanea di un servizio
  • Timeout che si verificano quando il servizio è occupato
  • Collisioni che si verificano quando i dispositivi trasmettono simultaneamente

Gli errori temporanei sono in genere auto-corretti. Se si ripete l'azione dopo un ritardo appropriato, è probabile che abbia esito positivo. Tuttavia, determinare gli intervalli appropriati tra i tentativi è difficile. Le strategie tipiche usano i tipi di intervalli di ripetizione dei tentativi seguenti:

  • Back-off esponenziale: L'applicazione attende un breve periodo di tempo prima del primo tentativo e quindi aumenta progressivamente il tempo di attesa tra i tentativi successivi. Ad esempio, potrebbe ritentare l'operazione dopo 3 secondi, 12 secondi e 30 secondi.

  • Intervalli regolari: L'applicazione attende lo stesso periodo di tempo tra ogni tentativo. Ad esempio, potrebbe ritentare l'operazione ogni tre secondi.

  • Tentativo immediato: A volte un errore temporaneo è breve e può verificarsi a causa di eventi come un conflitto di pacchetti di rete o un picco in un componente hardware. In questo scenario, è possibile ritentare immediatamente l'operazione. Se l'errore viene cancellato dal momento in cui l'applicazione viene assemblata e inviata la richiesta successiva, l'operazione può avere esito positivo. Tuttavia, un'applicazione non deve mai tentare più di un nuovo tentativo immediato. Se il nuovo tentativo immediato ha esito negativo, passare a strategie alternative, ad esempio azioni di back-off esponenziale o di fallback.

  • Randomizzazione: Una delle strategie di ripetizione dei tentativi precedenti può includere un elemento di randomizzazione per impedire a più istanze del client di inviare tentativi successivi contemporaneamente.

È consigliabile eseguire le azioni seguenti per evitare antipattern:

  • Non includere livelli duplicati di codice di ripetizione dei tentativi nelle implementazioni.

  • Non implementare mai un meccanismo di tentativi infiniti.

  • Non eseguire mai un tentativo immediato più di una volta.

  • Evitare di usare un intervallo regolare per i tentativi.

  • Impedire a più istanze dello stesso client o a più istanze di client diversi di inviare nuovi tentativi contemporaneamente.

Per altre informazioni, vedere Gestione degli errori temporanei.

Usare il provisioning zero-touch

Il provisioning permette la registrazione di un dispositivo nell'hub IoT. Il provisioning registra un dispositivo con hub IoT e specifica il meccanismo di attestazione usato. È possibile usare il servizio di provisioning dei dispositivi di hub IoT o effettuare il provisioning direttamente tramite le API del gestore del registro di sistema di hub IoT. Il servizio di provisioning dei dispositivi offre il vantaggio del binding ritardato, in modo da poter rimuovere e riprovisionare dispositivi sul campo per hub IoT senza modificare il software del dispositivo.

Per le distribuzioni di produzione che supportano la flotta di dispositivi di grandi dimensioni, usare il servizio di provisioning dei dispositivi hub IoT come modello di onboarding fondamentale. Il servizio di configurazione dei dispositivi fornisce provisioning sicuro, zero-touch, e associazione ritardata dei dispositivi alle istanze di hub IoT. È possibile riconfigurare i dispositivi in diversi ambienti o ridimensionarli orizzontalmente senza aggiornamenti del firmware. Quando si incorpora il servizio device provisioning fin dall'inizio, la soluzione può:

  • Distribuire i popolamenti dei dispositivi tra più hub.

  • Supportare le distribuzioni a livello di area.

  • Isolare gli ambienti dei clienti.

  • Effettuare la transizione dei dispositivi tra ambiti di distribuzione senza richiedere il ri-provisioning dei dispositivi o modifiche di produzione in un secondo momento del ciclo di vita.

Per altre informazioni, vedere Procedure consigliate per distribuzioni di dispositivi IoT su larga scala.

Il servizio device provisioning semplifica anche le transizioni dei dispositivi tra ambienti di test e produzione. L'esempio seguente illustra come usare il servizio device provisioning per implementare un flusso di lavoro di transizione dell'ambiente test-to-production.

Diagramma che mostra come usare il servizio device provisioning per implementare un flusso di lavoro di transizione dall'ambiente di test a produzione.

  1. Lo sviluppatore della soluzione collega i cloud IoT di test e produzione al servizio di provisioning.

  2. Se l'hub IoT non è stato effettuato il provisioning, il dispositivo implementa il protocollo del servizio di provisioning del dispositivo per trovare l'hub. Il servizio di provisioning dei dispositivi configura inizialmente il dispositivo nell'ambiente di test.

  3. Dopo la registrazione del dispositivo con l'ambiente di test, si connette a tale ambiente e viene eseguito il test.

  4. Lo sviluppatore riconfigura il dispositivo nell'ambiente di produzione e lo rimuove dall'hub di test. L'hub di test rifiuta il dispositivo alla successiva riconnessione.

  5. Il dispositivo si connette e rinegozia il flusso di provisioning. Il servizio device provisioning indirizza il dispositivo all'ambiente di produzione e il dispositivo si connette ed esegue l'autenticazione in tale ambiente.

Per altre informazioni, vedere Panoramica del servizio hub IoT device provisioning.

Preparare le funzionalità di gestione dei cicli di vita e delle identità

hub IoT supporta le funzionalità di gestione delle credenziali e del ciclo di vita dei dispositivi tramite l'integrazione del Registro dispositivi Azure e il rilascio di certificati operativi supportati da Microsoft.

La migrazione delle distribuzioni di hub IoT esistenti in questi nuovi modelli di gestione del ciclo di vita delle identità e dei certificati non è supportata in anteprima. Tuttavia, è possibile prepararsi per l'adozione implementando le procedure di architettura seguenti:

  • Usare il servizio di provisioning dei dispositivi per l'onboarding dei dispositivi anziché la registrazione diretta nel registro dell'hub.

  • Colocare hub IoT e risorse del servizio device provisioning all'interno della stessa area Azure.

  • Separare le credenziali di onboarding dall'autenticazione di runtime, quando possibile.

  • Evitare di incorporare metadati di connessione specifici hub IoT nel firmware del dispositivo.

Queste procedure allineano i flussi di onboarding dei dispositivi con la proiezione delle identità basata sul Registro dei dispositivi e i flussi di lavoro relativi al ciclo di vita dei certificati. Possono ridurre i requisiti di onboarding o reprovisioning futuri quando si adottano queste funzionalità.

Contributors

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

Autori principali:

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

Passo successivo

  • Last updated on