Planification du déploiement - Mémoire tampon de message sauvegardée sur disque

La mémoire tampon de message sauvegardée sur disque est une fonctionnalité qui permet au répartiteur MQTT de déverser les files d’attente de messages des abonnés sur le disque lorsqu’elles dépassent la mémoire disponible. Décidez avant le déploiement si vous avez besoin d’une mise en mémoire tampon de messages sauvegardée sur disque pour votre répartiteur MQTT.

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. Un nouveau déploiement est nécessaire si les modifications de configuration de Broker sont nécessaires. 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 du répartiteur MQTT distribué. Les avantages sont les suivants :

  • Gestion efficace des files d’attente : dans un répartiteur MQTT, 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’ils se déconnectent, mais demandent une session permanente MQTT, la file d’attente peut croître plus grande que la mémoire disponible.
  • Conservation des données pour les sessions persistantes : la fonctionnalité de mémoire tampon de message sauvegardée sur disque garantit que lorsqu’une file d’attente dépasse la mémoire disponible, elle est en toute transparence mise en mémoire tampon sur le disque. Cette fonctionnalité empêche la perte de données et prend en charge les sessions persistantes MQTT, ce qui permet aux abonnés de reprendre leurs sessions avec leurs files d’attente de messages intactes lorsqu’ils se reconnectent. Le disque est utilisé comme stockage éphémère et sert de dépassement de 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, le répartiteur dans son ensemble ne perd pas de données.
  • Gestion des problèmes de connectivité : les connecteurs cloud sont traités comme des abonnés avec des sessions persistantes qui peuvent faire face à des problèmes de connectivité lorsqu'ils ne parviennent pas à communiquer avec des systèmes externes comme un répartiteur MQTT Azure Event Grid en raison de la déconnexion du réseau. Dans de tels scénarios, les messages (PUBLISHes) s’accumulent. Le broker MQTT met intelligemment ces messages en mémoire ou sur disque jusqu’au rétablissement de la connectivité, ce qui garantit l’intégrité des messages.

Par défaut, la fonctionnalité de mémoire tampon de message sauvegardée sur disque est désactivée. Dans ce cas, les messages restent en mémoire et la pression arrière est appliquée aux clients lorsque l’utilisation de la mémoire atteint la limite définie par la limite de file d’attente de l’abonné.

Remarque

Le broker MQTT écrit les données sur le disque exactement telles qu’elles sont reçues des clients, sans chiffrement supplémentaire. La sécurisation du disque est essentielle pour protéger les données stockées par le répartiteur.

Configurer la mémoire tampon de message sauvegardée sur disque

Pour configurer la mémoire tampon de message sauvegardée sur disque, modifiez la diskBackedMessageBuffer section 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 az iot ops create commande. Pour plus d’informations, consultez la prise en charge de la configuration avancée du répartiteur MQTT par Azure CLI.

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

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

Ensuite, déployez les opérations IoT avec l’indicateur --broker-config-file (autres paramètres omis pour la concision) :

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

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

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

Pour obtenir une meilleure configuration de mémoire tampon de message 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 message. Par exemple:

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

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

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

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

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 la propriété ephemeral.volumeClaimTemplate.spec du volume dans les spécifications StatefulSet des chaînes de 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

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

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 backend.

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 privilégiée après un volume persistant.

Utilisez un emptyDir volume uniquement lorsque vous utilisez un cluster avec des quotas de système de fichiers. Pour 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 emptyDir volume 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 conduire à Kubernetes marquant le nœud et tous les pods associés comme non sains. Il est essentiel de comprendre comment votre fournisseur de stockage se comporte dans de tels scénarios.

Tip

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 provisionnés à l’aide d’un modèle de PVC apparaissent dans des commandes comme kubectl get pv, ce qui est utile pour examiner l’état du cluster.

Si vos nœuds Kubernetes n’ont pas suffisamment d’espace disque local pour la mémoire tampon de message, 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 plus petite maxSize , car la mémoire tampon de message bénéficie d’un accès rapide et ne nécessite pas de durabilité.

Désactivé

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

Mémoire tampon de disque et persistance

La mémoire tampon de message sauvegardée sur disque et la persistance du répartiteur écrivent des données sur le disque, mais elles servent des objectifs différents :

Fonctionnalité Mémoire tampon de messages sur disque Persévérance
Purpose Décharger les files d’attente d’abonnés de la mémoire vers le disque lorsqu’elles deviennent trop volumineuses Préserver l’état critique du broker (messages retenus, sessions, abonnements) lors des redémarrages des pods
Durability Éphémère : les données sont perdues lorsque le pod quitte Durable : les données survivent aux redémarrages des pods
Quand utiliser Abonnés lents, sessions persistantes hors connexion, interruptions de connectivité au cloud Vous avez besoin de messages ou d’état de session conservés pour survivre aux redémarrages du répartiteur
Étendue des données PUBLIER des messages dans les files d’attente des abonnés Messages conservés, métadonnées de file d’attente de l’abonné, données du magasin d’états
Configuration diskBackedMessageBuffer dans la ressource Broker Paramètres de persistance au moment du déploiement ou de l’exécution

Remarque

La mémoire tampon de disque et la persistance peuvent être utilisées ensemble. La persistance garantit que l’état survive aux redémarrages, tandis que la mémoire tampon du disque empêche les conditions de mémoire insuffisante pendant l’opération normale.

Étapes suivantes

  • Last updated on