Partager via

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

  • Article

Important

Ce paramètre nécessite la modification de la ressource Broker et ne peut être configuré qu’au moment du déploiement initial, en utilisant Azure CLI ou le Portail Azure. S’il est nécessaire de modifier la configuration Broker, un nouveau déploiement est requis. Pour plus d’informations, consultez Personnaliser le Broker par défaut.

La fonctionnalité de mémoire tampon de messages sauvegardée sur disque est utilisée pour une gestion efficace des 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 à laquelle un abonné traite les message a un impact direct sur 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 disque ne sont pas durables et sont perdues lorsque le pod sort, mais tant qu’au moins un pod de chaque chaîne back-end reste fonctionnel, le répartiteur 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 le MQTT broker Event Grid en raison d’une déconnexion réseau. Dans de tels scénarios, les messages (PUBLISH) s’accumulent. MQTT broker 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 le répartiteur.

Options de configuration

Pour configurer la mémoire tampon de messages sauvegardée sur disque, modifiez la section diskBackedMessageBuffer dans la ressource Broker. Ceci n’est actuellement pris en charge qu’en utilisant l’indicateur --broker-config-file lorsque vous déployez Opérations Azure IoT en utilisant la commande az iot ops create.

Pour commencer, préparez un fichier de configuration Broker 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 il s’agit de l’option la moins recommandée pour fournir les 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 StorageClass 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 les modes d’accès des volumes persistants.

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

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. Notez que les volumes éphémères nécessitent Kubernetes 1.23 ou une version ultérieure.

Conseil

Spécifier un modèle de revendication de volume éphémère (Ephemeral Volume Claim/EVC) ou de revendication de volume persistant (Persistent Volume Claim/PVC) vous permet d’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 (Persistent Volumes/PV) approvisionnés en utilisant un modèle PVC apparaissent dans des commandes comme kubectl get pv , ce qui peut être 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 Azure Blobs. Toutefois, il est généralement 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 Azure IoT avec une mémoire tampon de messages sauvegardée sur disque

Pour utiliser la mémoire tampon de messages sauvegardée sur disque, déployez Opérations Azure IoT en utilisant la commande az iot ops create avec l’indicateur --broker-config-file. Consultez la commande ci-dessous (autres paramètres omis pour rester concis) :

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 Azure 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 uniquement le volume emptyDir lors de l’utilisation d’un cluster avec des quotas de système de fichiers. Pour obtenir plus d’informations, consultez les détails de 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

Tenez compte du comportement du fournisseur de stockage que vous avez choisi. Par exemple, lorsque vous utilisez des fournisseurs tels que 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. Cela 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. Il s’agit également du comportement 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. Toutefois, cette fonctionnalité fournit un espace de stockage temporaire pour que les données soient enregistrées sur le disque, empêchant les dépassements de mémoire et la perte de données lors des redémarrages des pods.