Condividi tramite

Modello di configurazione del carico di lavoro Edge

  • Articolo

La grande varietà di sistemi e dispositivi in un reparto produzione può rendere difficile la configurazione del carico di lavoro. Questo articolo illustra alcuni approcci per risolvere tale problema.

Contesto e problema

Le aziende manifatturiere, nell'ambito del percorso di trasformazione digitale, si concentrano sempre più sulla creazione di soluzioni software che possono essere riusate come funzionalità condivise. A causa della varietà di dispositivi e sistemi presenti nel reparto produzione, i carichi di lavoro modulari sono configurati per supportare protocolli, driver e formati di dati diversi. Talvolta, anche più istanze di un carico di lavoro vengono eseguite con configurazioni diverse nella stessa posizione perimetrale. Per alcuni carichi di lavoro, le configurazioni vengono aggiornate più volte al giorno. Pertanto, la gestione della configurazione è sempre più importante per la scalabilità orizzontale delle soluzioni perimetrali.

Soluzione

Esistono alcune caratteristiche comuni nella gestione della configurazione per i carichi di lavoro perimetrali:

  • Esistono diversi punti di configurazione che possono essere raggruppati in livelli distinti, ad esempio origine software, pipeline CI/CD, tenant cloud e posizione perimetrale: Diagramma dei livelli che caratterizzano le configurazioni del carico di lavoro: origini software, pipeline I/C D, tenant cloud e posizione perimetrale.
  • I vari livelli possono essere aggiornati da utenti diversi.
  • Indipendentemente dalla modalità di aggiornamento delle configurazioni, queste ultime devono essere attentamente tracciate e controllate.
  • Per la continuità aziendale, è necessario che le configurazioni siano accessibili offline sul dispositivo perimetrale.
  • È anche necessario che sia disponibile una visualizzazione globale delle configurazioni disponibili nel cloud.

Considerazioni e problemi

Prima di decidere come implementare questo modello, considerare quanto segue:

  • Consentire le modifiche quando il dispositivo perimetrale non è connesso al cloud aumenta significativamente la complessità della gestione della configurazione. È possibile replicare le modifiche nel cloud, ma esistono problemi con:
    • Autenticazione utente, perché si basa su un servizio cloud come Microsoft Entra ID.
    • Risoluzione dei conflitti dopo la riconnessione, se i carichi di lavoro ricevono configurazioni impreviste che richiedono l'intervento manuale.
  • L'ambiente perimetrale può avere vincoli correlati alla rete se la topologia è conforme ai requisiti ISA-95. È possibile superare tali restrizioni selezionando una tecnologia che offre connettività tra più livelli, come le gerarchie dei dispositivi in Azure IoT Edge.
  • Se la configurazione in fase di esecuzione è disaccoppiata dalle versioni software, le modifiche apportate alla configurazione devono essere gestite separatamente. Per offrire le funzioni di cronologia e ripristino dello stato precedente, è necessario archiviare le configurazioni precedenti in un archivio dati nel cloud.
  • Un errore in una configurazione, ad esempio un componente di connettività configurato per un end-point inesistente, può interrompere il carico di lavoro. In una soluzione di osservabilità è quindi fondamentale prendere in considerazione le modifiche alla configurazione insieme ad altri eventi del ciclo di vita della distribuzione, in modo che le dashboard di osservabilità possano agevolare la correlazione tra gli errori di sistema e le modifiche di configurazione. Per altre informazioni sull'osservabilità, vedere Guida al monitoraggio del cloud: osservabilità.
  • Comprendere i ruoli degli archivi dati del cloud e del dispositivo perimetrale nella continuità aziendale. Se l'archivio dati cloud è l'unica fonte di verità, i carichi di lavoro perimetrali dovrebbero essere in grado di ripristinare gli stati destinati usando processi automatizzati.
  • Per la resilienza, l'archivio dati del dispositivo perimetrale deve fungere da cache offline. Ciò ha la precedenza rispetto alle considerazioni sulla latenza.

Quando usare questo modello

Usare questo modello quando:

  • È necessario configurare i carichi di lavoro al di fuori del ciclo di rilascio del software.
  • È necessario che diversi utenti possano leggere e aggiornare le configurazioni.
  • È necessario rendere disponibili le configurazioni anche quando non è presente alcuna connessione al cloud.

Esempi di carichi di lavoro:

  • Soluzioni che si connettono agli asset in un reparto produzione per l'inserimento e il controllo dei dati, ad esempio Publisher OPC
  • Carichi di lavoro di apprendimento automatico per la manutenzione predittiva
  • Carichi di lavoro di apprendimento automatico che controllano in tempo reale la qualità della linea di produzione

Esempi

La soluzione per configurare i carichi di lavoro perimetrali durante la fase di esecuzione può basarsi su un controller di configurazione esterno o su un provider di configurazione interno.

Variazione del controller di configurazione esterno

Diagramma dell'architettura per la variante del controller di configurazione esterna.

Questa variazione ha un controller di configurazione esterno al carico di lavoro. Il ruolo del componente del controller di configurazione del cloud consiste nell'eseguire il push delle modifiche dall'archivio dati del cloud al carico di lavoro tramite il controller di configurazione del dispositivo perimetrale. Il dispositivo perimetrale contiene anche un archivio dati in modo che il sistema funzioni anche quando è disconnesso dal cloud.

Con IoT Edge, il controller di configurazione del dispositivo perimetrale può essere implementato come modulo e le configurazioni possono essere applicate con moduli gemelli. Il modulo gemello ha un limite di dimensioni. Se la configurazione supera tale limite, la soluzione può essere estesa con Archiviazione BLOB di Azure o tramite la suddivisione in blocchi di payload più grandi su metodi diretti.

I vantaggi di questa variazione sono:

  • Il carico di lavoro stesso non deve essere a conoscenza del sistema di configurazione. Questa capacità è fondamentale se il codice sorgente del carico di lavoro non è modificabile, ad esempio quando si usa un modulo dal Marketplace di Azure IoT Edge.
  • È possibile modificare la configurazione di più carichi di lavoro contemporaneamente coordinando le modifiche tramite il controller di configurazione del cloud.
  • È possibile implementare una convalida aggiuntiva come parte della pipeline di push, ad esempio per convalidare l'esistenza di endpoint nel dispositivo perimetrale prima di eseguire il push della configurazione nel carico di lavoro.

Variazione del provider di configurazione interno

Diagramma dell'architettura per la variante del provider di configurazione interna.

Nella variazione del provider di configurazione interno, il carico di lavoro esegue il pull delle configurazioni da un provider di configurazione. Per un esempio di implementazione, vedere Implementare un provider di configurazione personalizzato in .NET. In questo esempio si usa C#, ma è possibile usare altri linguaggi.

In questa variazione, i carichi di lavoro hanno identificatori univoci in modo che lo stesso codice sorgente in esecuzione in ambienti diversi possa avere configurazioni diverse. Un modo per costruire un identificatore consiste nel concatenare la relazione gerarchica del carico di lavoro a un raggruppamento di livello superiore, ad esempio un tenant. Per quanto riguarda IoT Edge, potrebbe essere una combinazione di un gruppo di risorse di Azure, un nome dell'hub IoT, un nome dispositivo IoT Edge e un identificatore del modulo. L'insieme di questi valori forma un identificatore univoco che funge da chiave negli archivi dati.

Sebbene sia possibile aggiungere la versione del modulo all'identificatore univoco, è necessario rendere permanenti le configurazioni tra gli aggiornamenti software. Se tale versione fa parte dell'identificatore, è necessario eseguire la migrazione della versione precedente della configurazione con un'implementazione aggiuntiva.

I vantaggi di questa variazione sono:

  • Oltre agli archivi dati, la soluzione non richiede altri componenti, determinando una riduzione della complessità.
  • La logica di migrazione da versioni precedenti incompatibili può essere gestita all'interno dell'implementazione del carico di lavoro.

Soluzioni basate su IoT Edge

Diagramma dell'architettura per la variante basata su I o T Edge.

Il componente cloud dell'implementazione IoT Edge di riferimento è costituito da un hub IoT che funge da controller di configurazione del cloud. La funzionalità del modulo gemello dell'hub IoT di Azure propaga le modifiche di configurazione e le informazioni sulla configurazione attualmente applicata usando le proprietà desiderate e segnalate del modulo gemello. Il servizio di gestione della configurazione funge da origine delle configurazioni. Può anche essere un'interfaccia utente per la gestione delle configurazioni, un sistema di compilazione e altri strumenti usati per creare configurazioni del carico di lavoro.

Un archivio dati Azure Cosmos DB archivia tutte le configurazioni, può interagire con più hub IoT e fornisce la cronologia delle configurazioni.

Dopo che un dispositivo perimetrale segnala l'applicazione di una configurazione tramite proprietà segnalate, il servizio informazioni sullo stato di configurazione annota l'evento nell'istanza di database.

Quando si crea una nuova configurazione nel servizio di gestione della configurazione, questa viene archiviata in Azure Cosmos DB e le proprietà desiderate del modulo perimetrale vengono modificate nell'hub IoT in cui risiede il dispositivo. La configurazione viene quindi trasmessa dall'hub IoT al dispositivo perimetrale. Il modulo perimetrale deve applicare la configurazione e segnalare tramite il modulo gemello lo stato della configurazione. Il servizio informazioni sullo stato di configurazione resta quindi in attesa degli eventi di modifica del dispositivo gemello e, nel momento in cui rileva la segnalazione di una modifica dello stato di configurazione da parte del modulo, la registra nel database di Azure Cosmos DB.

Il componente perimetrale può usare il controller di configurazione esterno o il provider di configurazione interno. In entrambe le implementazioni, la configurazione viene trasmessa nelle proprietà desiderate del modulo gemello oppure, nel caso in cui sia necessario trasmettere configurazioni di grandi dimensioni, le proprietà desiderate del modulo gemello contengono un URL ad Archiviazione BLOB di Azure o a un altro servizio che può essere usato per recuperare la configurazione. Il modulo indica nelle proprietà segnalate del modulo gemello se la nuova configurazione è stata applicata correttamente e quale configurazione è attualmente applicata.

Collaboratori

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

Autore principale:

  • Camm heather | Senior Program Manager

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

Passaggi successivi