Pianificazione della distribuzione per Operazioni di Azure IoT

Molte impostazioni di Operazioni di Azure IoT sono fisse in fase di distribuzione e possono essere modificate solo tramite ridistribuzione. Prima di distribuire, pianificare la topologia del cluster, la cardinalità del broker, il profilo di memoria e le impostazioni facoltative del broker necessarie. Questo articolo riepiloga le decisioni da prendere.

Comprendere l'architettura

Operazioni di Azure IoT è un set di servizi modulari nativi di Kubernetes distribuiti in un cluster abilitato per Azure Arc. I componenti principali includono:

Nella documentazione vengono usati due termini:

• Distribuzione : istanza, estensioni Arc, percorsi personalizzati e tutte le risorse configurabili (asset, dispositivi, flussi di dati).
• Istanza : risorsa padre che aggrega i servizi.

Scegliere la topologia del cluster

Prima di eseguire la distribuzione, decidere se è necessario un cluster a nodo singolo o multinodo. Questa decisione determina i requisiti hardware e le impostazioni di cardinalità del broker.

Comprendere la cardinalità del broker

La cardinalità è il numero di repliche front-end, ruoli di lavoro front-end, partizioni back-end e ruoli di lavoro back-end nella distribuzione del broker. La cardinalità determina come il broker si ridimensiona orizzontalmente e quanto è resiliente ai guasti dei pod o dei nodi.

Il broker MQTT ha un'architettura a due livelli: i pod front-end gestiscono le connessioni client e l'elaborazione del protocollo, mentre i pod back-end gestiscono l'archiviazione e il recapito dei messaggi. Comprendere in che modo ogni livello viene ridimensionato è importante per la pianificazione della capacità.

Frontend

I pod front-end accettano connessioni client MQTT e inoltrano messaggi al back-end. I pod front-end non archiviano i messaggi stessi. Esistono due impostazioni principali per il livello front-end:

• Repliche: il numero di pod frontend da distribuire. L'aggiunta di più repliche front-end aumenta il numero di connessioni client simultanee che il broker può gestire e fornisce disponibilità elevata se uno dei pod front-end ha esito negativo.
• Worker: il numero di worker logici per pod frontend. Aggiungere altri worker consente al pod frontend di usare più core della CPU. Ogni worker può consumare fino a un core della CPU.

Catena back-end

I pod back-end gestiscono l'archiviazione e il recapito dei messaggi. Esistono tre impostazioni principali per il livello back-end:

• Partizioni: numero di partizioni da distribuire. Le partizioni sono l'unità di ridimensionamento orizzontale per la velocità effettiva dei messaggi. Tramite un processo denominato partizionamento orizzontale, ogni partizione gestisce una parte dei messaggi, partizionata per argomento e sessione. I pod front-end distribuiscono il traffico dei messaggi tra le partizioni. L'aggiunta di altre partizioni aumenta la velocità effettiva totale dei messaggi che il broker può gestire.
• Fattore di ridondanza: numero di pod back-end da distribuire per partizione. L'aumento del fattore di ridondanza aumenta il numero di copie di dati per fornire resilienza contro gli errori dei nodi nel cluster.
• Worker: il numero di worker per pod backend. I ruoli di lavoro sono l'unità di ridimensionamento verticale all'interno di una partizione. L'aggiunta di altri ruoli di lavoro consente al pod back-end di usare più core CPU nello stesso nodo. Ogni worker può utilizzare fino a due core CPU, quindi occorre fare attenzione, quando si aumenta il numero di worker per replica, a non superare il numero di core CPU nel cluster.

Stima della capacità effettiva

Le prestazioni di una singola partizione dipendono principalmente dalle caratteristiche della CPU del nodo su cui è in esecuzione. Come regola generale, aspettarsi approssimativamente da 5.000 a 6.000 messaggi QoS 1 al secondo per partizione con payload da 8 KB su una CPU a 2 GHz (~4 GHz turbo). Le prestazioni reali dipendono da molti fattori, quindi usare questo numero solo come punto di partenza per la pianificazione della capacità.

Per informazioni dettagliate sui dati di benchmark, vedere Benchmarking delle prestazioni di MQTT Broker.

Raccomandazioni a nodo singolo

• Repliche del frontend: impostare su 1.
• Ruoli di lavoro front-end: impostare su metà del numero di core CPU per nodo.
• Repliche backend (fattore di ridondanza): impostare su un valore minimo di 2 in modo che il broker possa eseguire aggiornamenti progressivi.

Esempio: nodo singolo, 4 core CPU

Raccomandazioni su più nodi

I valori seguenti sono consigliati per ottenere prestazioni ottimali. Per i cluster di grandi dimensioni con traffico ridotto, questi valori possono essere impostati in modo inferiore rispetto alle raccomandazioni senza causare problemi. Altre considerazioni, ad esempio la memoria (RAM) e le caratteristiche delle prestazioni sono descritte nelle sezioni seguenti. Testare sempre la configurazione con il carico di lavoro previsto per confermare le prestazioni.

• Repliche frontend: impostare sullo stesso valore del numero di nodi nel cluster.
• Ruoli di lavoro front-end: impostare su metà del numero di core CPU per nodo.
• Repliche backend (fattore di ridondanza): impostare su 2 per garantire la ridondanza e supportare l'aggiornamento progressivo.
• Partizioni back-end: impostare uguale al numero di nodi nel cluster.
• Ruoli di lavoro backend: impostare su metà del numero di core CPU per nodo.

Esempio: cluster a 3 nodi, 8 core CPU per nodo

Esempio: cluster a 5 nodi, 16 core CPU per nodo

Limiti delle risorse CPU

Per evitare la fame di risorse nel cluster, il broker può essere configurato per richiedere i limiti delle risorse DELLA CPU Kubernetes in base alle impostazioni di cardinalità. Quando abilitata, il ridimensionamento del numero di repliche o lavoratori aumenta proporzionalmente le risorse CPU richieste.

L'impostazione predefinita per i modelli api REST, Bicep e ARM è definita nella specifica api Broker.

Il broker MQTT richiede risorse CPU per pod in base al numero di ruoli di lavoro configurati:

• Pod front-end: 1,0 CPU per processo di lavoro
• Pod back-end: 2.0 CPU per processo di lavoro

Usare le formule seguenti per calcolare i requisiti totali della CPU:

Esempio: cluster di piccole dimensioni

Si consideri un cluster a 2 nodi con 4 core CPU per nodo (8 core totali) con la cardinalità seguente:

{
  "cardinality": {
    "frontend": {
      "replicas": 2,
      "workers": 2
    },
    "backendChain": {
      "partitions": 1,
      "redundancyFactor": 2,
      "workers": 1
    }
  }
}

Le richieste del broker:

• CPU front-end: 2 repliche × 2 processi di lavoro × 1,0 = 4,0 CPU
• CPU back-end: 1 partizione × 2 fattori di replica × 1 processo di lavoro × 2,0 = 4,0 CPU
• CPU totale del broker: 8,0 CPU

Questa configurazione richiede 8.0 CPU in un cluster con soli 8 core, lasciando nulla per altri componenti Operazioni di Azure IoT (200-300m) o per i pod di sistema Kubernetes. I pod broker rimangono nello stato Pending con errori Insufficient cpu.

Per risolvere questo problema, aggiungere altri nodi, aumentare i core per nodo o ridurre la cardinalità del broker.

Esempio: distribuzione più grande

La cardinalità seguente richiede molte più risorse cpu:

{
  "cardinality": {
    "frontend": {
      "replicas": 3,
      "workers": 2
    },
    "backendChain": {
      "partitions": 3,
      "redundancyFactor": 2,
      "workers": 2
    }
  }
}

• CPU front-end: 3 repliche × 2 processi di lavoro × 1,0 = 6,0 CPU
• CPU back-end: 3 partizioni × 2 fattori di replica × 2 processi di lavoro × 2,0 = 24,0 CPU
• CPU broker totale: 30,0 CPU

Un cluster richiede almeno 30 core CPU disponibili per i soli pod broker, oltre a un margine di capacità per altri componenti di Operazioni di Azure IoT e per i pod di sistema di Kubernetes.

Configurazione del limite di risorse CPU

I limiti delle risorse della CPU sono controllati dal generateResourceLimits.cpu campo nella risorsa Broker. Questa configurazione è supportata solo usando il flag --broker-config-file quando si distribuisce Operazioni di Azure IoT usando il comando az iot ops create. Per altre informazioni, vedere Supporto dell'interfaccia della riga di comando di Azure per la configurazione avanzata del broker MQTT.

Prepara un file di configurazione del broker seguendo il riferimento API GenerateResourceLimits. Gli esempi seguenti illustrano i due valori possibili:

{
  "generateResourceLimits": {
    "cpu": "Enabled"
  }
}

O

{
  "generateResourceLimits": {
    "cpu": "Disabled"
  }
}

Scegliere il profilo di memoria

Il profilo di memoria controlla le dimensioni massime dei messaggi MQTT accettate dal broker, l'utilizzo della memoria inattiva e l'utilizzo massimo della memoria di ogni pod. Decidere il profilo di memoria corretto prima della distribuzione in base alle dimensioni e alla velocità effettiva previsti del messaggio.

Buffer in ingresso e backpressure

Ogni profilo di memoria definisce una dimensione massima del buffer in ingresso per i dati PUBLISH per ogni ruolo di lavoro back-end. Quando il buffer raggiunge 75% capacità, il broker attiva i meccanismi di backpressure e inizia a rifiutare i messaggi in arrivo. I pacchetti rifiutati ricevono in risposta un PUBACK con un codice di errore Quota superata.

La tabella seguente mostra le dimensioni del buffer in ingresso per worker per ciascun profilo:

Quando si sceglie un profilo di memoria, prendere in considerazione:

• Tiny: deve essere usato un solo front-end. Inviare solo pacchetti inferiori a 4 MiB.
• Basso: è consigliabile usare solo uno o due front-end. Inviare solo pacchetti inferiori a 16 MiB.
• Medio: adatto per la maggior parte dei carichi di lavoro di produzione con dimensioni moderate dei messaggi.
• Elevato: usare quando è necessario gestire messaggi di grandi dimensioni o velocità effettiva elevata con buffer di grandi dimensioni.

La memoria totale del broker dipende sia dal profilo di memoria che dalla cardinalità (numero di repliche front-end, partizioni back-end e fattore di ridondanza). Più pod significano più memoria totale. Per il consumo delle risorse di base misurato in diverse configurazioni, vedere Profili di risorse di base.

Calcolare l'utilizzo totale della memoria

È possibile calcolare l'utilizzo totale della memoria con questa formula:

M_total = (R_fe × M_fe) + (P_be × RF_be × M_be × W_be)

Where:

Ad esempio, se si sceglie il profilo di memoria media , il profilo ha un utilizzo di memoria front-end di 1,9 GiB e un utilizzo della memoria back-end di 1,5 GiB. Si supponga che la configurazione del broker sia di 2 repliche front-end, 2 partizioni back-end e un fattore di ridondanza back-end pari a 2. L'utilizzo totale della memoria è:

M_total = (2 × 1.9 GiB) + (2 × 2 × 1.5 GiB × 2)
        = 15.8 GiB

In confronto, il profilo di memoria Tiny ha un utilizzo di memoria front-end di 99 MiB e un utilizzo della memoria back-end pari a 102 MiB. Con la stessa configurazione broker, l'utilizzo totale della memoria è:

M_total = (2 × 99 MiB) + (2 × 2 × 102 MiB × 2)
        = 198 MiB + 816 MiB
        = 1014 MiB (≈ 1.0 GiB)

Configurazione del profilo di memoria

Quando si distribuiscono operazioni IoT usando il az iot ops create comando , il --broker-mem-profile parametro specifica le impostazioni del profilo di memoria.

Ad esempio, il comando seguente imposta il profilo di memoria su Tiny (altri parametri vengono omessi per brevità):

az iot ops create ... --broker-mem-profile Tiny

Per altre informazioni, vedere az iot ops create parametri facoltativi.

Impostazioni broker facoltative

Le impostazioni broker seguenti sono configurate anche in fase di distribuzione e non possono essere modificate in seguito. Esaminare questi elementi se si applicano allo scenario:

• Buffer di messaggi con backup su disco: memorizzare nel buffer i messaggi su disco quando le code dei sottoscrittori superano la memoria disponibile. Utile per le sessioni persistenti e le problematiche di connettività.
• Persistenza — Scrivere i dati critici del broker su disco per preservarli tra un riavvio e l’altro.
• Diagnostica : configurare metriche, log e probe di controllo automatico per il broker MQTT.
• Opzioni MQTT avanzate : personalizzare la scadenza della sessione, la scadenza dei messaggi, i limiti della coda del sottoscrittore e le impostazioni keep-alive.
• Crittografia del traffico interno : configurare la crittografia del traffico interno tra il front-end broker e i pod back-end (attivato per impostazione predefinita).

Passaggi successivi

• Prepara il cluster
• Eseguire la distribuzione in un cluster di produzione
• Configurare l'osservabilità
• Proteggi la distribuzione