Configurer le comportement de la mémoire tampon de message sur disque

Article
02/20/2025

Important

Ce paramètre nécessite la modification de la ressource Broker. Il est configuré uniquement lors du déploiement initial à l’aide d’Azure CLI ou du portail Azure. S’il est nécessaire de modifier la configuration Broker, un nouveau déploiement est requis. Pour en savoir plus, consultez Personnaliser l’Agent par défaut.

La fonctionnalité de mémoire tampon de messages sauvegardée sur disque est utilisée pour gérer efficacement les files d’attente de messages au sein de l’agent MQTT distribué. Les avantages incluent :

Gestion efficace des files d’attente : dans un MQTT broker, chaque abonné est associé à une file d’attente de messages. La vitesse de traitement des messages d’un abonné affecte directement la taille de la file d’attente. Si un abonné traite les messages lentement ou s’il se déconnecte, mais demande une session persistante MQTT, la file d’attente peut devenir plus volumineuse que la mémoire disponible.
Conservation des données pour les sessions persistantes : la fonctionnalité de mémoire tampon de messages sauvegardée sur disque garantit que, lorsqu’une file d’attente dépasse la mémoire disponible, elle est mise en mémoire tampon en toute fluidité sur le disque. Cette fonctionnalité empêche la perte de données et prend en charge les sessions persistantes MQTT, permettant ainsi aux abonnés de reprendre leurs sessions avec leurs files d’attente de messages intactes lors de la reconnexion. Le disque est utilisé comme stockage éphémère et sert de débordement de la mémoire. Les données écrites sur le disque ne sont pas durables et sont perdues lorsque le pod quitte. Si au moins un pod de chaque chaîne back-end reste fonctionnel, l’agent dans son ensemble ne perd pas de données.
Gestion des problèmes de connectivité : les connecteurs cloud sont traités en tant qu’abonnés avec des sessions persistantes qui peuvent rencontrer des problèmes de connectivité lorsqu’ils ne parviennent pas à communiquer avec des systèmes externes tels que l’agent MQTT Azure Event Grid en raison d’une déconnexion réseau. Dans de tels scénarios, les messages (PUBLISH) s’accumulent. L’agent MQTT sauvegarde intelligemment ces messages en mémoire tampon ou sur disque jusqu’à ce que la connectivité soit restaurée, garantissant ainsi l’intégrité des messages.

Par défaut, la fonctionnalité de mémoire tampon de messages sauvegardée sur disque est désactivée. Dans ce cas, les messages restent en mémoire et une contre-pression est appliquée aux clients, car le pool de lecteurs ou le pool temporaire atteint la limite définie par la limite de file d’attente de l’abonné.

Configurer la mémoire tampon de messages sauvegardée sur disque est essentiel pour maintenir un système de mise en file d’attente des messages robuste et fiable, en particulier dans les scénarios où la vitesse de traitement des messages et la connectivité sont essentielles.

Remarque

L’agent MQTT écrit des données sur le disque exactement comme ils sont reçus des clients, sans chiffrement supplémentaire. Sécuriser le disque est essentiel pour protéger les données stockées par l’agent.

Options de configuration

Pour configurer la mémoire tampon de messages sauvegardée sur disque, modifiez la section diskBackedMessageBuffer dans la ressource Broker. Actuellement, cette configuration est prise en charge uniquement à l’aide de l’indicateur --broker-config-file lorsque vous déployez Opérations Azure IoT à l’aide de la commande az iot ops create.

Pour commencer, préparez un fichier de configuration d’agent en suivant la référence de l’API DiskBackedMessageBuffer.

Par exemple, la configuration la plus simple implique de ne spécifier que la taille maximale. Dans ce cas, un volumeemptyDir est monté. La valeur maxSize est utilisée comme limite de taille du volume emptyDir. Mais cette option est l’option la moins recommandée en raison des limitations du volume emptyDir.

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

Pour obtenir une meilleure configuration de mémoire tampon de messages sauvegardée sur disque, spécifiez un volume éphémère ou une revendication de volume persistant pour monter un volume de stockage dédié pour votre mémoire tampon de messages. Par exemple :

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

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

Personnalisez les options de mémoire tampon de message du répartiteur en ajustant les paramètres suivants :

Configurer le volume : spécifiez un modèle de revendication de volume persistant pour monter un volume de stockage dédié pour votre mémoire tampon de messages.
Sélectionner une classe de stockage : définissez la classe de stockage souhaitée à l’aide de la propriété storageClassName.
Définir les modes d’accès : déterminez les modes d’accès dont vous avez besoin pour votre volume. Pour obtenir plus d’informations, consultez Modes d’accès des volumes persistants.

Utilisez les sections suivantes pour comprendre les différents modes de volume :

Le volume éphémère est l’option préférée.
Volume persistant est l’option préférée suivante.
Volume emptyDir est l’option la moins recommandée.

Les volumes persistants et éphémères sont généralement fournis par les mêmes classes de stockage. Si les deux options sont disponibles, choisissez un volume éphémère. Les volumes éphémères nécessitent Kubernetes 1.23 ou une version ultérieure.

Conseil

Lorsque vous spécifiez un modèle de revendication de volume éphémère (EVC) ou de revendication de volume persistant (PVC), vous pouvez utiliser une classe de stockage de votre choix, ce qui augmente la flexibilité pour certains scénarios de déploiement. Par exemple, les volumes persistants approvisionnés en utilisant un modèle PVC apparaissent dans des commandes comme kubectl get pv, ce qui est utile pour inspecter l’état du cluster.

Si vos nœuds Kubernetes n’ont pas suffisamment d’espace disque local pour la mémoire tampon de messages, utilisez une classe de stockage qui fournit un stockage réseau comme Stockage Blob Azure. Il est préférable d’utiliser un disque local avec une valeur maxSize plus petite, car la mémoire tampon de messages bénéficie d’un accès rapide et ne nécessite pas de durabilité.

Déployer Opérations IoT avec une mémoire tampon de messages sauvegardée sur disque

Pour utiliser une mémoire tampon de messages sauvegardée sur disque, déployez Opérations IoT en utilisant la commande az iot ops create avec l’indicateur --broker-config-file. Voyez la commande suivante. (D’autres paramètres sont omis pour la concision.)

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

Ce paramètre ne peut pas être modifié après le déploiement. Pour modifier la configuration de la mémoire tampon de messages sauvegardée sur disque, redéployez l’instance Opérations IoT.

Volume éphémère

Le volume éphémère est l’option préférée pour votre mémoire tampon de message.

Pour un volume éphémère, suivez les conseils de la section Considérations relatives aux fournisseurs de stockage.

La valeur de la propriété ephemeralVolumeClaimSpec est utilisée comme propriété ephemeral.volumeClaimTemplate.spec du volume dans les spécifications StatefulSet des chaînes back-end.

Par exemple, pour utiliser un volume éphémère avec une capacité de 1 gigaoctet, spécifiez les paramètres suivants dans votre ressource Broker :

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

Volume persistant

Après le volume éphémère, le volume persistant est l’option préférée pour votre mémoire tampon de message.

Pour un volume persistant, suivez les conseils de la section Considérations relatives aux fournisseurs de stockage.

La valeur de la propriété persistentVolumeClaimSpec est utilisée comme propriété volumeClaimTemplates.spec des spécifications StatefulSet des chaînes back-end.

Par exemple, pour utiliser un volume persistant avec une capacité de 1 gigaoctet, spécifiez les paramètres suivants dans votre ressource Broker :

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

Volume emptyDir

Un volume emptyDir est l’option la moins recommandée, après le volume persistant.

Utilisez un volume emptyDir uniquement lorsque vous utilisez un cluster avec des quotas de système de fichiers. Pour obtenir plus d’informations, consultez l’onglet Quota de projet du système de fichiers. Si la fonctionnalité n’est pas activée, le cluster effectue une analyse périodique qui n’applique aucune limite et permet au nœud hôte de remplir l’espace disque et de marquer l’ensemble du nœud hôte comme non sain.

Par exemple, pour utiliser un volume emptyDir avec une capacité de 1 gigaoctet, spécifiez les paramètres suivants dans votre ressource Broker :

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

Considérations relatives aux fournisseurs de stockage

Considérez le comportement de votre fournisseur de stockage choisi, par exemple lorsque vous utilisez des fournisseurs comme rancher.io/local-path. Si le fournisseur ne prend pas en charge les limites, le remplissage du volume consomme l’espace disque du nœud. Ce comportement peut entraîner le marquage du nœud et de tous les pods associés comme non sains par Kubernetes. Il est essentiel de comprendre comment votre fournisseur de stockage se comporte dans de tels scénarios.

Désactivé

Si vous ne souhaitez pas utiliser la mémoire tampon de messages sauvegardée sur disque, n’incluez pas la propriété diskBackedMessageBufferSettings dans votre ressource Broker. Ce comportement est également celui par défaut.

Persistance

Il est important de comprendre que la fonctionnalité de mémoire tampon de messages sauvegardée sur disque n’est pas synonyme de persistance. Dans ce contexte, la persistance fait référence aux données qui survivent aux redémarrages des pods. Cette fonctionnalité fournit un espace de stockage temporaire pour que les données soient enregistrées sur le disque, ce qui empêche les dépassements de mémoire et la perte de données lors des redémarrages des pods.

Partager via