Configurare il comportamento del buffer dei messaggi basato su disco

Importante

Per questa impostazione è necessario modificare la risorsa Broker. Viene configurato solo durante la distribuzione iniziale usando l'interfaccia della riga di comando di Azure o il portale di Azure. Se sono necessarie modifiche alla configurazione di Broker, è necessaria una nuova distribuzione. Per altre informazioni, vedere Personalizzare Broker predefinito.

La funzionalità buffer dei messaggi supportata dal disco viene usata per una gestione efficiente delle code di messaggi all'interno del broker MQTT distribuito. I vantaggi includono:

• Gestione efficiente delle code: in un broker MQTT ogni sottoscrittore è associato a una coda di messaggi. La velocità di elaborazione dei messaggi di un sottoscrittore influisce direttamente sulle dimensioni della coda. Se un sottoscrittore elabora i messaggi lentamente o se si disconnette ma richiede una sessione permanente MQTT, la coda può aumentare di dimensioni superiori alla memoria disponibile.
• Conservazione dei dati per sessioni persistenti: la funzionalità buffer di messaggi con backup su disco garantisce che quando una coda supera la memoria disponibile, viene memorizzata facilmente nel buffer su disco. Questa funzionalità impedisce la perdita di dati e supporta sessioni permanenti MQTT, consentendo ai sottoscrittori di riprendere le sessioni con le code di messaggi intatte quando si riconnette. Il disco viene usato come risorsa di archiviazione temporanea e funge da spillover dalla memoria. I dati scritti su disco non sono durevoli e si perdono quando il pod viene chiuso. Se almeno un pod in ogni catena back-end rimane funzionale, il broker nel suo complesso non perde alcun dato.
• Gestione dei problemi di connettività: i connettori cloud vengono considerati sottoscrittori con sessioni persistenti che possono affrontare problemi di connettività quando non riescono a comunicare con sistemi esterni come un broker MQTT Griglia di eventi di Azure a causa della disconnessione di rete. In questi scenari, i messaggi (PUBLISHes) si accumulano. Il broker MQTT memorizza in modo intelligente questi messaggi in memoria o su disco fino a quando non viene ripristinata la connettività, garantendo l'integrità dei messaggi.

Per impostazione predefinita, la funzionalità buffer dei messaggi supportata dal disco è disabilitata. In questo caso, i messaggi rimangono in memoria e la pressione di backup viene applicata ai client quando il pool di lettura o il pool di scratch raggiunge il limite definito dal limite di coda del sottoscrittore.

La configurazione del buffer di messaggi supportato dal disco è essenziale per mantenere un sistema di accodamento messaggi affidabile e affidabile, soprattutto negli scenari in cui la velocità di elaborazione dei messaggi e la connettività sono fondamentali.

Nota

Il broker MQTT scrive i dati sul disco esattamente come ricevuto dai client, senza aggiungere la crittografia. La protezione del disco è essenziale per proteggere i dati archiviati dal broker.

Opzioni di configurazione

Per configurare il buffer dei messaggi basato su disco, modificare la diskBackedMessageBuffer sezione nella risorsa Broker. Attualmente, questa configurazione è supportata solo usando il --broker-config-file flag quando si distribuiscono le operazioni di Azure IoT usando il az iot ops create comando .

Per iniziare, preparare un file di configurazione broker seguendo le informazioni di riferimento sull'API DiskBackedMessageBuffer .

Ad esempio, la configurazione più semplice prevede solo la specifica delle dimensioni massime. In questo caso, viene montato un emptyDir volume . Il maxSize valore viene utilizzato come limite di dimensioni del emptyDir volume. Questa opzione è tuttavia l'opzione meno preferita a causa delle limitazioni del emptyDir volume.

{
  "diskBackedMessageBuffer": {
    "maxSize": "<SIZE>"
  }
}

Per ottenere una configurazione migliore del buffer di messaggi basato su disco, specificare un volume temporaneo o un'attestazione di volume permanente per montare un volume di archiviazione dedicato per il buffer dei messaggi. Ad esempio:

{
  "diskBackedMessageBuffer": {
    "maxSize": "<SIZE>",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "<NAME>",
      "accessModes": [
        "<MODE>"
      ]
    }
  }
}

{
  "persistentVolumeClaimSpec": {
    "maxSize": "<SIZE>",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "<NAME>",
      "accessModes": [
        "<MODE>"
      ]
    }
  }
}

Personalizzare le opzioni del buffer dei messaggi broker modificando le impostazioni seguenti:

• Configurare il volume: specificare un modello di attestazione di volume per montare un volume di archiviazione dedicato per il buffer dei messaggi.
• Selezionare una classe di archiviazione: definire la classe di archiviazione desiderata usando la storageClassName proprietà .
• Definire le modalità di accesso: determinare le modalità di accesso necessarie per il volume. Per altre informazioni, vedere Modalità di accesso al volume persistente.

Usare le sezioni seguenti per comprendere le diverse modalità di volume:

• Il volume temporaneo è l'opzione preferita.
• Il volume permanente è l'opzione preferita successiva.
• emptyDir volume è l'opzione meno preferita.

I volumi permanenti e temporanei sono in genere forniti dalle stesse classi di archiviazione. Se sono disponibili entrambe le opzioni, scegliere effimero. I volumi temporanei richiedono Kubernetes 1.23 o versione successiva.

Suggerimento

Quando si specifica un modello EVC (EVC) o Un'attestazione di volume permanente (PVC), è possibile usare una classe di archiviazione di propria scelta, che aumenta la flessibilità per alcuni scenari di distribuzione. Ad esempio, i volumi persistenti di cui è stato effettuato il provisioning usando un modello DI PVC vengono visualizzati in comandi come kubectl get pv, che è utile per controllare lo stato del cluster.

Se i nodi Kubernetes non dispongono di spazio su disco locale sufficiente per il buffer dei messaggi, usare una classe di archiviazione che fornisce archiviazione di rete come Archiviazione BLOB di Azure. È preferibile usare un disco locale con un valore inferiore maxSize perché il buffer dei messaggi trae vantaggio dall'accesso rapido e non richiede durabilità.

Distribuire operazioni IoT con buffer di messaggi basato su disco

Per usare un buffer di messaggi basato su disco, distribuire operazioni IoT usando il az iot ops create comando con il --broker-config-file flag . Vedere il comando seguente. Altri parametri vengono omessi per brevità.

az iot ops create ... --broker-config-file <FILE>.json

Questa impostazione non può essere modificata dopo la distribuzione. Per modificare la configurazione del buffer dei messaggi su disco, ridistribuire l'istanza di operazioni IoT.

Volume temporaneo

Il volume temporaneo è l'opzione preferita per il buffer dei messaggi.

Per il volume temporaneo, seguire i consigli nella sezione Considerazioni per i provider di archiviazione.

Il valore della ephemeralVolumeClaimSpec proprietà viene utilizzato come ephemeral.volumeClaimTemplate.spec proprietà del volume nelle StatefulSet specifiche delle catene back-end.

Ad esempio, per usare un volume temporaneo con una capacità di 1 gigabyte, specificare i parametri seguenti nella risorsa broker:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

Volume permanente

Il volume permanente è l'opzione preferita successiva per il buffer dei messaggi dopo il volume temporaneo.

Per un volume permanente, seguire i consigli nella sezione Considerazioni per i provider di archiviazione.

Il valore della persistentVolumeClaimSpec proprietà viene utilizzato come volumeClaimTemplates.spec proprietà delle StatefulSet specifiche delle catene back-end.

Ad esempio, per usare un volume permanente con una capacità di 1 gigabyte, specificare i parametri seguenti nella risorsa broker:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "persistentVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

Volume emptyDir

Un volume emptyDir è l'opzione meno preferita dopo il volume permanente.

Usare un emptyDir volume solo quando si usa un cluster con quote di file system. Per altre informazioni, vedere la scheda Quota del progetto file system. Se la funzionalità non è abilitata, il cluster esegue l'analisi periodica che non applica alcun limite e consente al nodo host di riempire lo spazio su disco e contrassegnare l'intero nodo host come non integro.

Ad esempio, per usare un emptyDir volume con una capacità di 1 gigabyte, specificare i parametri seguenti nella risorsa broker:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G"
  }
}

Considerazioni per i provider di archiviazione

Si consideri il comportamento del provider di archiviazione scelto, ad esempio quando si usano provider come rancher.io/local-path. Se il provider non supporta i limiti, il riempimento del volume utilizza lo spazio su disco del nodo. Questo comportamento potrebbe portare a Kubernetes contrassegnando il nodo e tutti i pod associati come non integri. È fondamentale comprendere il comportamento del provider di archiviazione in tali scenari.

Disabilitata

Se non si vuole usare il buffer dei messaggi basato su disco, non includere la diskBackedMessageBufferSettings proprietà nella risorsa broker. Questo comportamento è anche l'impostazione predefinita.

Persistenza

È importante comprendere che la funzionalità buffer dei messaggi basata su disco non è sinonimo di persistenza. In questo contesto, salvataggio permanente si riferisce ai dati che sopravvivono tra i riavvii dei pod. Questa funzionalità fornisce spazio di archiviazione temporaneo per i dati da salvare su disco, che impedisce gli overflow di memoria e la perdita di dati durante i riavvii dei pod.