Configurer les paramètres de l’Agent MQTT pour la haute disponibilité, la mise à l’échelle et l’utilisation de la mémoire

Article
11/21/2024

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 l’Agent MQTT en ajoutant d’autres réplicas front-end et d’autres partitions back-end. Les réplicas front-end sont responsables de l’acceptation des connexions MQTT à partir de clients et de leur transfert vers les partitions back-end. Les partitions 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 paramètre nécessite la modification de la ressource d’Agent et peut être configuré uniquement 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.

Pour configurer les paramètres de mise à l’échelle de l’Agent MQTT, spécifiez les champs de cardinalité dans la spécification de la ressource Broker pendant le déploiement d’Opérations Azure IoT.

Cardinalité de déploiement automatique

Pour déterminer automatiquement la cardinalité initiale pendant le déploiement, omettez le champ de cardinalité dans la ressource Broker.

Portail
Azure CLI

La cardinalité automatique n’est pas encore prise en charge lors du déploiement d’Opérations Azure IoT via le portail Azure. Toutefois, vous pouvez spécifier manuellement Nœud unique ou Multi-nœud comme mode de déploiement du cluster. Pour en savoir plus, veuillez consulter la section Déployer des opérations Azure IoT.

Capture d’écran montrant dans le portail Azure où sélectionner une configuration à nœud unique ou multinœud.

Préparez un fichier de configuration Broker au format JSON qui inclut les propriétés souhaitées de la ressource microsoft.iotoperations/instances/brokers Azure Resource Manager et veillez à omettre le champ cardinality. Par exemple, définissez uniquement le profil de mémoire :

{
  "memoryProfile": "<MEMORY_PROFILE>"
}

Ensuite, déployez Opérations Azure IoT en utilisant la commande az iot ops create avec l’indicateur --broker-config-file, comme la commande suivante (les autres paramètres sont omis pour des raisons de concision) :

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

Pour plus d’informations, consultez Prise en charge de l’interface Azure CLI pour la configuration avancée de l’Agent MQTT.

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é précédemment, 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é

Pour configurer directement les paramètres de cardinalité, spécifiez chacun des champs de cardinalité.

Portail
Azure CLI

Lorsque vous suivez le guide pour déployer Opérations Azure IoT, dans la section Configuration, consultez Configuration de l’Agent MQTT. Ici, vous pouvez spécifier le nombre de réplicas front-end, de partitions back-end et de Workers back-end.

Capture d’écran montrant dans le portail Azure où configurer directement la cardinalité du Broker.

Lorsque vous déployez Opérations Azure IoT à l’aide de la commande az iot ops create, utilisez les paramètres --broker-frontend-replicas, --broker-frontend-workers, --broker-backend-part, --broker-backend-rf, et --broker-backend-workers pour spécifier les paramètres de cardinalité.

Par exemple, pour spécifier un réplica front-end, un Worker front-end, une partition back-end, deux réplicas back-end par partition et un Worker back-end par réplica, consultez la commande suivante (les autres paramètres sont omis pour des raisons de concision) :

az iot ops create ... --broker-frontend-replicas 1 --broker-frontend-workers 1  --broker-backend-part 1  --broker-backend-workers 1 --broker-backend-rf 2

Vous pouvez également utiliser l’indicateur --broker-config-file pour spécifier un fichier JSON qui inclut les paramètres de cardinalité. Exemple de fichier JSON pour les mêmes paramètres :

{
  "cardinality": {
    "frontend": {
      "replicas": 1,
      "workers": 1
    },
    "backendChain": {
      "partitions": 1,
      "redundancyFactor": 2,
      "workers": 1
    }
  }
}

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

Définition de la cardinalité

La cardinalité est le nombre d’instances d’une entité particulière dans un jeu. Dans le contexte de l’Agent MQTT, la cardinalité fait référence au nombre de réplicas front-end, de partitions back-end et de Workers back-end à déployer. Les paramètres de cardinalité sont utilisés pour mettre à l’échelle le répartiteur horizontalement et améliorer la haute disponibilité en cas de défaillance de pod ou de nœud.

Le champ de cardinalité est un champ imbriqué, avec des sous-champs pour frontend et backendChain. Chacun de ces sous-champs a ses propres paramètres.

Serveur frontal

Le sous-champ frontend définit les paramètres des pods front-end. Les deux paramètres principaux sont les suivants :

Réplicas : nombre de réplicas front-end (pods) à 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. Chaque Worker peut consommer jusqu’à un cœur de processeur au maximum.

Chaîne back-end

Le sous-champ de chaîne back-end définit les paramètres des partitions back-end. Les trois principaux paramètres sont les suivants :

Partitions : nombre de partitions à déployer. 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. L’augmentation du nombre de partitions augmente le nombre de messages que le Broker peut traiter.
Facteur de redondance : nombre de réplicas back-end (pods) à 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. L’augmentation du nombre de Workers par réplica back-end peut augmenter le nombre de messages que le pod back-end est capable de 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.

À propos de l’installation

Lorsque vous augmentez les valeurs de cardinalité, la capacité du Broker à traiter davantage de connexions et de messages s’améliore généralement, et cela 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é, tenez compte des paramètres du profil de mémoire et des demandes de ressources processeur du Broker. L’augmentation du nombre de Workers par réplica front-end peut aider à augmenter l’utilisation du cœur de processeur si vous découvrez que l’utilisation du processeur front-end est un goulot d’étranglement. L’augmentation du nombre de Workers back-end peut accroître le débit des messages si le processeur back-end est un goulot d’étranglement.

Par exemple, si votre cluster a trois nœuds, chacun avec huit cœurs de processeur, définissez le nombre de réplicas front-end de façon à ce qu’il corresponde au nombre de nœuds (trois) et définissez le nombre de Workers sur 1. Définissez le nombre de partitions back-end de façon à ce qu’il corresponde au nombre de nœuds (trois), et le nombre de Workers back-end sur 1. Définissez le facteur de redondance comme vous le souhaitez (deux ou trois). Augmentez le nombre de Workers front-end si vous découvrez que le processeur front-end est un goulot d’étranglement. N’oubliez pas que les Workers back-end et front-end peuvent entrer en concurrence pour les ressources de processeur, entre elles et avec d’autres pods.

Configurer le profil de mémoire

Important

Pour configurer les paramètres de profil de mémoire de l’Agent MQTT, spécifiez les champs de profil de mémoire dans la spécification de la ressource Broker pendant le déploiement d’Opérations Azure IoT.

Portail
Azure CLI

Lorsque vous suivez le guide pour déployer Opérations Azure IoT, dans la section Configuration, consultez Configuration de l’Agent MQTT et recherchez le paramètre Profil de mémoire. Ici, vous pouvez sélectionner parmi les profils de mémoire disponibles dans une liste déroulante.

Lorsque vous déployez Opérations Azure IoT à l’aide de la commande az iot ops create, utilisez le paramètre --broker-mem-profile pour spécifier les paramètres de profil de mémoire.

Par exemple, pour spécifier Tiny comme profil de mémoire, consultez la commande suivante (les autres paramètres sont omis pour des raisons de concision) :

az iot ops create ... --broker-mem-profile Tiny

Pour en savoir plus, consultez Paramètres facultatives az iot ops create.

Vous avez le choix entre quelques profils de mémoire, chacun présentant des caractéristiques d’utilisation de la mémoire différentes.

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 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 :

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.

Cardinalité et limites de ressources Kubernetes

Pour éviter la pénurie de ressources dans le cluster, le Broker est configuré par défaut pour demander les limites de ressources de processeur Kubernetes. La mise à l’échelle du nombre de réplicas ou de Workers augmente proportionnellement les ressources de processeur requises. Une erreur de déploiement est émise si les ressources de processeur disponibles dans le cluster sont insuffisantes. Cela permet d’éviter les situations où la cardinalité du Broker demandée ne dispose pas de suffisamment de ressources pour s’exécuter de manière optimale. Cela permet également d’éviter la contention potentielle de processeur et les évictions de pod.

L’Agent MQTT demande actuellement une unité de processeur (1,0) par Worker front-end et deux unités de processeur (2,0) par Worker back-end. Pour plus d’informations, consultez Unités de ressources de processeur Kubernetes.

Par exemple, la cardinalité ci-dessous demanderait les ressources de processeur suivantes :

Pour les front-ends : deux unités de processeur par pod front-end, soit six unités de processeur au total.
Pour les back-ends : quatre unités de processeur par pod back-end (pour deux Workers back-end), multiplié par deux (facteur de redondance), multiplié par 3 (nombre de partitions), soit au total 24 unités de processeur.

{
  "cardinality": {
    "frontend": {
      "replicas": 3,
      "workers": 2
    },
    "backendChain": {
      "partitions": 3,
      "redundancyFactor": 2,
      "workers": 2
    }
  }
}

Pour désactiver ce paramètre, affectez la valeur Disabled au champ generateResourceLimits.cpu dans la ressource Broker.

Portail
Azure CLI

La modification du champ generateResourceLimits n’est pas prise en charge dans le portail Azure. Pour désactiver ce paramètre, utilisez Azure CLI.

Préparez un fichier de configuration Broker au format JSON qui inclut les propriétés souhaitées de la ressource microsoft.iotoperations/instances/brokers Azure Resource Manager et affectez la valeur Disabled au champ generateResourceLimits.cpu. Par exemple :

{
  "generateResourceLimits": {
    "cpu": "Disabled"
  }
}

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

Pour plus d’informations, consultez Prise en charge de l’interface Azure CLI pour la configuration avancée de l’Agent MQTT.

Déploiement multi-nœud

Pour garantir la haute disponibilité et la résilience des déploiements multinœuds, l’Agent MQTT Opérations Azure IoT définit automatiquement des règles d’anti-affinité pour les pods back-end.

Ces règles sont prédéfinies et ne peuvent pas être modifiées.

Objectif des règles d’anti-affinité

Les règles d’anti-affinité garantissent que les pods back-end de la même partition ne s’exécutent pas sur le même nœud. Cela permet de distribuer la charge et de fournir une résilience contre les défaillances de nœud. Plus précisément, les pods back-end de la même partition ont une anti-affinité les uns avec les autres.

Vérification des paramètres d’anti-affinité

Pour vérifier les paramètres d’anti-affinité pour un pod back-end, utilisez la commande suivante :

kubectl get pod aio-broker-backend-1-0 -n azure-iot-operations -o yaml | grep affinity -A 15

La sortie affiche la configuration d’anti-affinité, similaire à ce qui suit :

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: chain-number
            operator: In
            values:
            - "1"
        topologyKey: kubernetes.io/hostname
      weight: 100

Il s’agit des seules règles d’anti-affinité définies pour le Broker.

Étapes suivantes

Configurer les écouteurs de l’Agent MQTT

Partager via