Partager via

Configurer les paramètres principaux de MQTT broker

  • Article

Important

Opérations Azure IoT Préversion avec Azure Arc est actuellement en préversion. Vous ne devez pas utiliser ce logiciel en préversion dans des environnements de production.

Vous devez déployer une nouvelle installation d’Opérations Azure IoT quand une version en disponibilité générale devient disponible. Vous ne pourrez pas mettre à niveau une installation en préversion.

Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.

La ressource Broker est la ressource principale qui définit les paramètres globaux pour MQTT broker. Elle détermine également le nombre et le type de pods qui exécutent la configuration Broker, comme les serveurs frontaux et principaux. Vous pouvez également utiliser la ressource Broker pour configurer son profil de mémoire. Les mécanismes de réparation automatique sont intégrés au répartiteur et peuvent souvent se remettre automatiquement des défaillances des composants. Par exemple, un nœud échoue dans un cluster Kubernetes configuré pour la haute disponibilité.

Vous pouvez mettre à l’échelle horizontalement le MQTT broker en ajoutant d’autres réplicas front-end et d’autres chaînes back-end. Les réplicas front-end sont responsables de l’acceptation des connexions MQTT à partir de clients et de leur transfert vers les chaînes back-end. Les chaînes back-end sont responsables du stockage et de la remise des messages aux clients. Les pods front-end distribuent le trafic de messages entre les pods back-end, et le facteur de redondance back-end détermine le nombre de copies de données pour fournir une résilience contre les défaillances de nœud dans le cluster.

Pour obtenir la liste des paramètres disponibles, consultez les informations de référence sur l’API de broker.

Configurer les paramètres de mise à l’échelle

Important

À ce stade, la ressource Broker peut uniquement être configurée au moment du déploiement initial à l’aide d’Azure CLI, du Portail ou de GitHub Action. S’il est nécessaire de modifier la configuration Broker, un nouveau déploiement est requis.

Pour configurer les paramètres de mise à l’échelle de MQTT broker, vous devez spécifier les champs cardinality dans la spécification de la ressource personnalisée Broker. Pour obtenir plus d’informations sur la définition des paramètres de mode et de cardinalité à l’aide d’Azure CLI, consultez az iot ops create.

Cardinalité de déploiement automatique

Pour déterminer automatiquement la cardinalité initiale pendant un déploiement, omettez le champ cardinality dans la ressource Broker. L’opérateur MQTT broker déploie automatiquement le nombre approprié de pods en fonction du nombre de nœuds disponibles au moment du déploiement. Il est utile pour les scénarios hors production où vous n’avez pas besoin de mise à l’échelle ou de haute disponibilité.

Toutefois, il ne s’agit pas d’une mise à l’échelle automatique. L’opérateur ne met pas automatiquement à l’échelle le nombre de pods en fonction de la charge. L’opérateur détermine uniquement le nombre initial de pods à déployer en fonction du matériel de cluster. Comme indiqué ci-dessus, la cardinalité peut uniquement être définie au moment du déploiement initial et un nouveau déploiement est requis si vous devez modifier les paramètres de cardinalité.

Configurer directement la cardinalité

Si vous souhaitez configurer directement les paramètres de cardinalité, spécifiez le champ cardinality. Le champ cardinality est un champ imbriqué qui dispose de ces sous-champs :

  • frontend : ce sous-champ définit les paramètres des pods front-end, tels que :
    • replicas : nombre de pods front-end à déployer. L’augmentation du nombre de réplicas front-end offre une haute disponibilité en cas de défaillance de l’un des pods front-end.
    • workers : nombre de Workers front-end logiques par réplica. L’augmentation du nombre de Workers par réplica front-end améliore l’utilisation des cœurs de processeur, car chaque Worker peut utiliser uniquement un cœur de processeur au maximum. Par exemple, si votre cluster a 3 nœuds, chacun avec 8 cœurs de processeurs, définissez alors le nombre de réplicas afin d’établir une correspondance avec le nombre de nœuds (3) et augmentez le nombre de Workers jusqu’à 8 par réplica lorsque vous avez besoin de davantage de débit front-end. Chaque réplica front-end peut de cette manière utiliser tous les cœurs de processeur sur le nœud sans que les Workers soient en concurrence pour les ressources de processeur.
  • backendChain : ce sous-champ définit les paramètres des chaînes back-end, par exemple :
    • partitions : nombre de partitions à déployer. L’augmentation du nombre de partitions augmente le nombre de messages que le Broker peut traiter. Grâce à un processus appelé partitionnement, chaque partition est responsable d’une partie des messages, divisés par ID de sujet et ID de session. Les pods front-end distribuent le trafic de messages sur toutes les partitions.
    • redundancyFactor : nombre de pods back-end à déployer par partition. L’augmentation du facteur de redondance augmente le nombre de copies de données pour fournir une résilience contre les défaillances de nœud dans le cluster.
    • workers : nombre de Workers à déployer par réplica back-end. Les Workers s’occupent en même temps du stockage et de la remise des messages aux clients. L’augmentation du nombre de Workers par réplica back-end augmente le nombre de messages que le pod back-end peut traiter. Chaque Worker peut consommer jusqu’à deux cœurs de processeur au maximum. Soyez donc vigilant lorsque vous augmentez le nombre de Workers par réplica pour ne pas dépasser le nombre de cœurs de processeur dans le cluster.

Lorsque vous augmentez ces valeurs, la capacité du Broker à traiter d’autres connexions et messages s’améliore et il optimise la haute disponibilité en cas de défaillance de nœud ou de pod. Toutefois, cela peut entraîner une consommation de ressources supérieure. Par conséquent, lors de l’ajustement des valeurs de cardinalité, examinez les paramètres du profil de mémoire et équilibrez ces facteurs pour optimiser l’utilisation de la ressource du Broker.

Configurer le profil de mémoire

Important

À ce stade, la ressource Broker peut uniquement être configurée au moment du déploiement initial à l’aide d’Azure CLI, du Portail ou de GitHub Action. S’il est nécessaire de modifier la configuration Broker, un nouveau déploiement est requis.

Pour configurer les paramètres de profil mémoire de MQTT broker, spécifiez les champs memoryProfile dans la spécification de la ressource personnalisée Broker. Pour obtenir plus d’informations sur la définition du paramètre de profil de mémoire à l’aide d’Azure CLI, consultez az iot ops create.

memoryProfile : ce sous-champ définit les paramètres du profil de mémoire. Il existe quelques profils pour l’utilisation de la mémoire que vous pouvez choisir :

Petit

Lorsque vous utilisez ce profil :

  • L’utilisation maximale de la mémoire de chaque réplica front-end est d’environ 99 Mio, mais l’utilisation maximale réelle de la mémoire peut être plus élevée.
  • L’utilisation maximale de la mémoire de chaque réplica back-end est d’environ 102 Mio, mais l’utilisation maximale réelle de la mémoire peut être plus élevée.

Recommandations lors de l’utilisation de ce profil :

  • Un seul serveur front-end doit être utilisé.
  • Les clients ne doivent pas envoyer de paquets volumineux. Vous devez uniquement envoyer des paquets inférieurs à 4 Mio.

Faible

Lorsque vous utilisez ce profil :

  • L’utilisation maximale de la mémoire de chaque réplica front-end est d’environ 387 Mio, mais l’utilisation maximale réelle de la mémoire peut être plus élevée.
  • L’utilisation maximale de la mémoire de chaque réplica back-end est d’environ 390 Mio multipliée par le nombre de workers back-end, mais l’utilisation maximale réelle de la mémoire peut être plus élevée.

Recommandations lors de l’utilisation de ce profil :

  • Uniquement un ou deux serveurs front-end doivent être utilisés.
  • Les clients ne doivent pas envoyer de paquets volumineux. Vous devez uniquement envoyer des paquets inférieurs à 10 Mio.

Moyenne

Média est le profil par défaut.

  • L’utilisation maximale de la mémoire de chaque réplica front-end est d’environ 1,9 Gio, mais l’utilisation maximale réelle de la mémoire peut être plus élevée.
  • L’utilisation maximale de la mémoire de chaque réplica back-end est d’environ 1,5 Gio multipliée par le nombre de workers back-end, mais l’utilisation maximale réelle de la mémoire peut être plus élevée.

Élevée

  • L’utilisation maximale de la mémoire de chaque réplica front-end est d’environ 4,9 Gio, mais l’utilisation maximale réelle de la mémoire peut être plus élevée.
  • L’utilisation maximale de la mémoire de chaque réplica back-end est d’environ 5,8 Gio multipliée par le nombre de workers back-end, mais l’utilisation maximale réelle de la mémoire peut être plus élevée.

Répartiteur par défaut

Par défaut, Opérations Azure IoT – Préversion déploie une ressource de répartiteur par défaut nommée default. Elle est déployée dans l’espace de noms azure-iot-operations avec des paramètres de cardinalité et de profil de mémoire configurés à l’aide du Portail Azure ou d’Azure CLI lors du déploiement initial. Exécutez la commande suivante pour afficher les paramètres :

kubectl get broker default -n azure-iot-operations -o yaml

Configurer les paramètres avancés de MQTT broker

Les paramètres avancés du répartiteur incluent les configurations client, le chiffrement du trafic interne et les rotations de certificats. Pour plus d’informations sur les paramètres avancés, consultez la référence de l’API Broker.

Voici un exemple d’un Broker avec des paramètres avancés :

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: Broker
metadata:
  name: default
  namespace: azure-iot-operations
spec:
  advanced:
    clients:
        maxSessionExpirySeconds: 282277
        maxMessageExpirySeconds: 1622
        subscriberQueueLimit:
          length: 1000
          strategy: DropOldest
        maxReceiveMaximum: 15000
        maxKeepAliveSeconds: 300
    encryptInternalTraffic: Enabled
    internalCerts:
      duration: 240h
      renewBefore: 45m
      privateKey:
        algorithm: Rsa2048
        rotationPolicy: Always

Configurer les paramètres de diagnostic de MQTT broker

Les paramètres de diagnostic vous permettent d’activer les métriques et le suivi pour MQTT broker.

  • Les métriques fournissent des informations sur l’utilisation et le débit des ressources de MQTT broker.
  • Le suivi fournit des informations détaillées sur les demandes et les réponses gérées par MQTT broker.

Pour remplacer les paramètres de diagnostic par défaut pour MQTT broker, mettez à jour la section spec.diagnostics dans la ressource Broker. Ajustez le niveau de consignation pour contrôler la quantité et le détail des informations enregistrées. Le niveau de journalisation peut être défini pour différents composants du MQTT broker. Le niveau de journalisation par défaut est info.

Vous pouvez configurer des diagnostics à l’aide de la définition de ressource personnalisée (CRD) Broker. Pour plus d’informations sur les paramètres de diagnostics, consultez la référence de l’API Broker.

Voici un exemple d’une ressource Broker personnalisée avec les métriques et le suivi activés et la vérification automatique désactivée :

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: Broker
metadata:
  name: default
  namespace: azure-iot-operations
spec:
  diagnostics:
    logs:
      level: "debug"
      opentelemetryExportConfig:
        otlpGrpcEndpoint: "endpoint"
    metrics:
      opentelemetryExportConfig:
        otlpGrpcEndpoint: "endpoint"
        intervalSeconds: 60
    selfCheck:
      mode: Enabled
      intervalSeconds: 120
      timeoutSeconds: 60
    traces:
      cacheSizeMegabytes: 32
      mode: Enabled
      opentelemetryExportConfig:
        otlpGrpcEndpoint: "endpoint"
      selfTracing:
        mode: Enabled
        intervalSeconds: 120
      spanChannelCapacity: 1000

Configurer le chiffrement du trafic interne

Important

À ce stade, cette fonctionnalité ne peut pas être configurée à l’aide d’Azure CLI ou du Portail Azure lors du déploiement initial.

La fonctionnalité encryptInternalTraffic est utilisée pour chiffrer le trafic interne entre les pods front-end et back-end. Pour utiliser cette fonctionnalité, le gestionnaire de certificats doit être installé dans le cluster, qui est installé par défaut lorsqu’Opérations Azure IoT est utilisé.

Les avantages incluent :

  • Sécuriser le trafic interne : tout le trafic interne entre le serveur frontal et les pods back-end est chiffré.

  • Sécuriser les données au repos : toutes les données au repos sont chiffrées.

  • Sécuriser les données en transit : toutes les données en transit sont chiffrées.

  • Sécuriser les données en mémoire : toutes les données en mémoire sont chiffrées.

  • Sécuriser les données dans la mémoire tampon de message : toutes les données de la mémoire tampon de message sont chiffrées.

  • Sécuriser les données dans la mémoire tampon de message sur disque : toutes les données de la mémoire tampon de message sur disque sont chiffrées.

Par défaut, la fonctionnalité encryptInternalTraffic est activée. Pour la désactiver, définissez le champ encryptInternalTraffic sur false dans la spécification de la ressource personnalisée Broker lors du nouveau déploiement du répartiteur.

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

Important

À ce stade, cette fonctionnalité ne peut pas être configurée à l’aide d’Azure CLI ou du Portail Azure lors du déploiement initial.

La fonctionnalité diskBackedMessageBufferSettings est utilisée pour une gestion efficace des files d’attente de messages au sein du MQTT broker 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é diskBackedMessageBufferSettings garantit que lorsqu’une file d’attente dépasse la mémoire disponible, elle est mise en mémoire tampon en toute transparence 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.

Le fait de comprendre et configurer la fonctionnalité diskBackedMessageBufferSettings conserve un système de mise en file d’attente de messages robuste et fiable. Une configuration appropriée est importante dans les scénarios où la vitesse de traitement des messages et la connectivité sont des facteurs critiques.

Options de configuration

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

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

Le volume éphémère est l’option préférée. Le volume persistant est ensuite préféré, puis vient le volume emptyDir. Les volumes persistants et les volumes éphémères sont généralement fournis par les mêmes classes de stockage. Si vous pouvez choisir parmi les deux options, choisissez un volume éphémère. Toutefois, le volume éphémère nécessite Kubernetes 1.23 ou version ultérieure.

Désactivé

Si vous ne souhaitez pas utiliser la mémoire tampon de message sur disque, n’incluez pas la propriété diskBackedMessageBufferSettings dans votre CRD Broker.

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 CRD 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 dans les 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 CRD Broker :

diskBackedMessageBuffer:
  maxSize: "1G"
  persistentVolumeClaimSpec:
    storageClassName: "foo"
    accessModes:
    - "ReadWriteOnce"

Volume emptyDir

Utilisez un volume emptyDir. Un volume emptyDir est l’option préférée suivante 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 CRD 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.

Persistance

Il est important de comprendre que la fonctionnalité diskBackedMessageBufferSettings 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.