Rete a più livelli per Operazioni di Azure IoT

In molti ambienti industriali, le architetture di rete segmentate (ad esempio l'architettura di rete Purdue) separano asset, sistemi di controllo e applicazioni aziendali in livelli di rete distinti. I livelli inferiori in genere non possono connettersi direttamente a Internet e possono comunicare solo con i livelli adiacenti. Operazioni di Azure IoT supporta la distribuzione tra queste reti a più livelli, usando il concatenamento proxy Envoy, CoreDNS e la configurazione basata su Kubernetes per instradare il traffico tra i livelli.

Il diagramma seguente mostra Operazioni di Azure IoT distribuito in più cluster in segmenti di rete diversi. Nell'architettura Purdue Network, il livello 4 è la rete aziendale, il livello 3 è il livello di funzionamento e controllo e il livello 2 è il livello del sistema controller. Solo il livello 4 ha accesso diretto a Internet e gli altri livelli possono comunicare solo con i livelli adiacenti.

In questo esempio, Operazioni di Azure IoT viene distribuito ai livelli da 2 a 4. Ogni livello usa i componenti seguenti per instradare il traffico verso l'alto verso il livello successivo:

• Envoy Proxy (livelli 3 e 4), funge da proxy inverso che inoltra il traffico dai livelli figlio verso Azure.
• CoreDNS (livelli 2 e 3), risolve gli URI approvati nel proxy envoy del cluster padre, in modo che i livelli inferiori possano raggiungere i servizi Azure attraverso livelli adiacenti.

Questa configurazione consente di abilitare i cluster arc a ogni livello e di mantenerli connessi senza accesso diretto a Internet.

È possibile distribuire Operazioni di Azure IoT componenti tra livelli in base alle esigenze dell'architettura e del flusso di dati:

• Connettore per OPC UA : posizionare al livello inferiore, più vicino agli asset e ai server OPC UA.
• Broker MQTT : distribuire a ogni livello per trasferire i dati verso l'alto verso il cloud.
• Flussi di dati : posizionarsi nei nodi con risorse di calcolo sufficienti, perché questo componente usa in genere più risorse di calcolo. Con una configurazione aggiuntiva, i flussi di dati possono anche instradare il traffico est-ovest tra i componenti allo stesso livello o superiore.

Modalità di flusso dei dati di telemetria attraverso i livelli

In una rete a più livelli, i dati di telemetria degli asset non passano direttamente dal livello più basso al cloud. I dati di telemetria terminano e si rigenerano a ogni livello. Questo modello hop per hop è una differenza fondamentale rispetto a una distribuzione di rete piatta.

Il flusso funziona come segue:

1. Livello 2 (livello asset): Il connettore per OPC UA legge i dati dai server OPC UA e lo pubblica nel broker MQTT locale, ad esempio in un argomento come clusterl2/data/oven1. Un Flusso di dati preleva tali messaggi, facoltativamente li trasforma o li arricchisce (ad esempio, aggiungendo contesto di prodotto) e li inoltra al broker MQTT al livello 3.
2. Livello 3 (livello operativo): Il broker MQTT di livello 3 riceve i messaggi dal livello 2. Un Flusso di dati a questo livello può aggiungere ulteriore contesto (ad esempio, dettagli della linea di produzione) e inoltra i messaggi arricchiti al broker MQTT al livello 4.
3. Livello 4 (livello enterprise): Il broker MQTT di livello 4 riceve i messaggi dal livello 3. Un Flusso di dati finale aggiunge qualsiasi contesto rimanente (ad esempio, identificatori factory) e invia i messaggi a una destinazione cloud, ad esempio Hub eventi di Azure o Griglia di eventi di Azure tramite il percorso di connettività privato o pubblico.

A ogni livello, i dati vengono terminati completamente nel broker MQTT locale, non vengono sottoposti a tunneling o pass-through. In questo modo è possibile:

• Arricchire i dati a ogni livello : aggiungere metadati contestuali (prodotto, linea, factory) che gli asset di livello inferiore non conoscono.
• Filtro o aggregazione : ridurre il volume di dati o eliminare messaggi irrilevanti prima di inoltrare verso l'alto.
• Utilizzare localmente : altre applicazioni allo stesso livello possono sottoscrivere il broker MQTT locale per i carichi di lavoro di reparto senza attendere il round trip dei dati nel cloud.

Per una pratica procedura dettagliata di questo modello, vedere il passaggio 5 della procedura dettagliata di esempio.

Procedura dettagliata di esempio

Un esempio di linee guida di rete a strati è disponibile nel repository degli esempi di Operazioni di Azure IoT. Il repository di esempio contiene i file di configurazione dell'infrastruttura (configurazioni proxy Envoy, CoreDNS Corefiles e manifesti Kubernetes) usati a ogni livello di rete. Il tutorial fornisce la guida completa alla distribuzione end-to-end, tra cui la configurazione delle risorse Azure, la configurazione collegamento privato e DNS, l'abilitazione di Arc, le assegnazioni di controllo degli accessi in base al ruolo e il controllo post-distribuzione e fa riferimento all'esempio per i file di configurazione specifici del livello.

L'esempio e le linee guida illustrano come:

• Usare la configurazione basata su Kubernetes e le primitive di rete per gli ambienti a più livelli.
• Connettere i dispositivi in reti isolate su larga scala a Azure Arc per la gestione del ciclo di vita delle applicazioni e la configurazione remota.
• Applicare la sicurezza e la governance tra i livelli di rete con gli elenchi di indirizzi URL/IP consentiti e il controllo delle connessioni.
• Verificare la compatibilità con tutti i servizi Operazioni di Azure IoT.

Per altre informazioni su come prepararsi per una distribuzione pronta per la produzione di Operazioni di Azure IoT, vedere le linee guida per la produzione Operazioni di Azure IoT.

Per provare l'esempio in un ambiente di test, seguire la procedura dettagliata:

1. Come Operazioni di Azure IoT funziona in una rete a più livelli
2. Configurare l'infrastruttura
3. Abilitazione per Arc di cluster K3s
4. Implementare operazioni Azure IoT
5. telemetria dell'asset Flow

Compatibilità della piattaforma

L'approccio di rete a più livelli descritto di seguito si applica ai cluster Kubernetes abilitati per Arc. Se si usano altre piattaforme abilitate per Arc nell'ambiente a più livelli, tenere presente quanto segue:

• Server abilitati per Azure Arc: La catena di proxy Envoy è stata convalidata solo con i cluster Kubernetes abilitati per Arc. I server con abilitazione di Arc usano un agente diverso (Azure agente connected machine) con requisiti di endpoint diversi. Se è necessario abilitare Arc server in una rete a più livelli, verificare che gli endpoint necessari siano inclusi nella configurazione di Envoy proxy e CoreDNS. Componenti di Operazioni di Azure IoT (broker MQTT, Flussi di dati, Connettori per OPC UA) richiedono Kubernetes e non possono essere eseguiti direttamente su server con Arc abilitato.
• Azure Locale (in precedenza Azure Stack HCI): Azure Locale nodi che ospitano cluster Kubernetes (ad esempio AKS abilitati da Azure Arc) sono completamente compatibili con questo approccio di rete a più livelli. Il cluster Kubernetes in esecuzione in Azure Locale segue la stessa catena di abilitazione Arc e dei proxy Envoy descritta in precedenza.

Contenuti correlati

• Rete Operazioni di Azure IoT
• Deploy Operazioni di Azure IoT con connettività privata
• Tutorial: distribuire Operazioni di Azure IoT in una rete a più livelli con connettività privata