Planification du déploiement pour Opérations Azure IoT

De nombreux paramètres Opérations Azure IoT sont résolus au moment du déploiement et ne peuvent être modifiés qu’en redéployant. Avant de déployer, planifiez la topologie de votre cluster, la cardinalité du répartiteur, le profil de mémoire et les paramètres de répartiteur facultatifs dont vous avez besoin. Cet article récapitule les décisions que vous devez prendre.

Comprendre l’architecture

Opérations Azure IoT est un ensemble de services natifs Kubernetes modulaires déployés sur un cluster compatible Azure Arc. Les composants clés sont les suivants :

Deux termes sont utilisés dans la documentation :

• Déploiement : instance, extensions Arc, emplacements personnalisés et toutes les ressources configurables (ressources, appareils, flux de données).
• Instance : ressource parente qui regroupe les services.

Choisir la topologie de votre cluster

Avant de déployer, déterminez si vous avez besoin d’un cluster à nœud unique ou à plusieurs nœuds. Cette décision détermine la configuration matérielle requise et les paramètres de cardinalité du répartiteur.

Comprendre la cardinalité du courtier

La cardinalité correspond au nombre de réplicas et de workers frontaux, de partitions et de workers back-end dans le déploiement du répartiteur. La cardinalité contrôle la mise à l’échelle horizontale du répartiteur et sa résilience aux défaillances de pod ou de nœud.

Le répartiteur MQTT a une architecture à deux niveaux : les pods frontend gèrent les connexions clientes et le traitement du protocole, tandis que les pods principaux gèrent le stockage et la remise des messages. Comprendre comment chaque niveau est important pour la planification de la capacité.

Interface utilisateur

Les pods frontaux acceptent les connexions clientes MQTT et transfèrent les messages au back-end. Les pods frontaux ne stockent pas eux-mêmes les messages. Il existe deux paramètres principaux pour le niveau frontal :

• Réplicas : nombre de pods frontaux à déployer. Le fait d'ajouter des réplicas frontaux augmente le nombre de connexions clientes simultanées que le répartiteur peut gérer et fournit une disponibilité importante si l’un des pods frontaux échoue.
• Workers : nombre de workers logiques par pod frontal. Le fait d'ajouter plus de workers permet au pod frontal d’utiliser davantage de cœurs de processeur. Chaque processus peut utiliser jusqu’à un cœur de processeur.

Chaîne back-end

Les pods principaux gèrent le stockage et la remise des messages. Il existe trois paramètres principaux pour le niveau back-end :

• Partitions : nombre de partitions à déployer. Les partitions sont l’unité de mise à l’échelle horizontale pour le débit des messages. Par le biais d’un processus appelé partitionnement, chaque partition gère une partie des messages, partitionnée par rubrique et session. Les pods front-end distribuent le trafic de messages sur toutes les partitions. L’ajout de partitions supplémentaires augmente le débit total des messages que le répartiteur peut gérer.
• Facteur de redondance : nombre de pods principaux à 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 par pod back-end. Les workers constituent l’unité de mise à l’échelle verticale au sein d’une partition : l’ajout de workers permet au pod backend d’exploiter davantage de cœurs de processeur sur le même nœud. Chaque processus de travail peut consommer jusqu’à deux cœurs de processeur ; veillez donc, lorsque vous augmentez le nombre de processus de travail par réplique, à ne pas dépasser le nombre de cœurs de processeur du cluster.

Estimation du débit

Les performances d’une partition individuelle dépendent fortement des caractéristiques de l’UC du nœud sur lequel il s’exécute. En règle générale, attendez-vous à environ 5 000 à 6 000 messages QoS 1 par seconde par partition avec des charges utiles de 8 Ko sur un processeur de 2 GHz (environ 4 GHz turbo). Les performances réelles dépendent de nombreux facteurs, donc utilisez ce nombre uniquement comme point de départ pour la planification de la capacité.

Pour obtenir des données de benchmark détaillées, consultez l’analyse des performances du répartiteur MQTT.

Recommandations de nœud unique

• Réplicats du frontend : réglé sur 1.
• Workers frontaux : régler sur la moitié du nombre de cœurs de processeur par nœud.
• Réplicas back-end (facteur de redondance) : en régler au moins 2 afin que le répartiteur puisse effectuer des mises à jour propagées.

Exemple : nœud unique, 4 cœurs de CPU

Recommandations multinœud

Les valeurs suivantes sont recommandées pour des performances optimales. Pour les clusters volumineux avec un trafic faible, ces valeurs peuvent être définies plus bas que les recommandations sans provoquer de problèmes. D’autres considérations telles que la mémoire (RAM) et les caractéristiques de performances sont décrites dans les sections suivantes. Testez toujours votre configuration avec la charge de travail attendue pour confirmer les performances.

• Réplicas de front-end : définissez une valeur égale au nombre de nœuds dans le cluster.
• Workers frontaux : régler sur la moitié du nombre de cœurs de processeur par nœud.
• Réplicas back-end (facteur de redondance) : régler sur 2 pour assurer la redondance et prendre en charge les mises à jour propagées.
• Partitions principales : définissez la valeur égale au nombre de nœuds du cluster.
• Workers back-end : régler sur la moitié du nombre de cœurs de processeur par nœud.

Exemple : cluster à 3 nœuds, 8 cœurs d’UC par nœud

Exemple : cluster à 5 nœuds, 16 cœurs d’UC par nœud

Limites des ressources processeur

Pour éviter la pénurie de ressources dans le cluster, le répartiteur peut être configuré pour demander des limites de ressources processeur Kubernetes en fonction des paramètres de cardinalité. Lorsque cette option est activée, augmenter proportionnellement le nombre de réplicas ou de travailleurs accroît les ressources processeur requises.

La valeur par défaut pour les modèles d’API REST, Bicep et ARM est définie dans la spécification de l’API Broker.

Le répartiteur MQTT demande des ressources processeur par pod en fonction du nombre de workers configurés :

• Pods frontaux : 1.0 CPU par travailleur
• Pods backend : 2,0 CPU par worker

Utilisez les formules suivantes pour calculer les exigences totales du processeur :

Exemple : petit cluster

Considérez un cluster à 2 nœuds avec 4 cœurs d’UC par nœud (8 cœurs total) avec la cardinalité suivante :

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

Demandes du répartiteur :

• CPU frontend: 2 réplicas × 2 workers × 1,0 = 4,0 CPU
• CPU backend : 1 partition × 2 RF × 1 worker × 2,0 = 4,0 CPU
• CPU total des brokers : 8,0 CPU

Cette configuration nécessite un processeur 8.0 sur un cluster avec seulement 8 cœurs, ne laissant rien pour les autres composants Opérations Azure IoT (200-300 m) ou pour les pods système Kubernetes. Les pods du répartiteur restent en Pending l’état avec des Insufficient cpu erreurs.

Pour résoudre ce problème, ajoutez d’autres nœuds, augmentez les cœurs par nœud ou réduisez la cardinalité du répartiteur.

Exemple : déploiement plus volumineux

La cardinalité suivante demande beaucoup plus de ressources processeur :

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

• CPU frontend: 3 réplicas × 2 workers × 1,0 = 6,0 CPU
• CPU backend : 3 partitions × 2 RF × 2 workers × 2,0 = 24,0 CPU
• CPU total des brokers : 30,0 CPU

Un cluster a besoin d'au moins 30 cœurs de processeur disponibles pour les seuls pods du répartiteur, plus une marge de manœuvre pour les autres composants d’Opérations Azure IoT et les pods système Kubernetes.

Configuration de la limite des ressources processeur

Les limites de ressources processeur sont contrôlées par le generateResourceLimits.cpu champ dans la ressource Broker. 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.

Préparez un fichier de configuration Broker en suivant la référence de l’API GenerateResourceLimits . Les exemples suivants montrent les deux valeurs possibles :

{
  "generateResourceLimits": {
    "cpu": "Enabled"
  }
}

ou

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

Choisir votre profil de mémoire

Le profil de mémoire contrôle la taille maximale du message MQTT que le répartiteur accepte, l’utilisation de la mémoire inactive et l’utilisation maximale de la mémoire de chaque pod. Choisissez le profil de mémoire approprié avant le déploiement en fonction de vos tailles et débits de messages attendus.

Tampon d’entrée et contre-pression

Chaque profil de mémoire définit une taille maximale de mémoire tampon entrante pour les données PUBLISH par worker principal. Lorsque la mémoire tampon atteint 75% capacité, le répartiteur active les mécanismes de rétropression et commence à rejeter les messages entrants. Les paquets rejetés reçoivent une réponse PUBACK avec le code d’erreur quota dépassé.

Le tableau suivant présente les tailles de mémoire tampon entrante par worker pour chaque profil :

Lorsque vous choisissez un profil de mémoire, tenez compte des éléments suivants :

• Minuscule : un seul front-end doit être utilisé. Envoi de paquets de moins de 4 Mio uniquement.
• Faible : seuls un ou deux serveurs frontaux doivent être utilisés. Envoyez uniquement des paquets inférieurs à 16 Mio.
• Moyen : adapté à la plupart des charges de travail de production avec des tailles de message modérées.
• Élevé : utilisez quand vous devez gérer des messages volumineux ou un débit élevé avec des mémoires tampons volumineuses.

La mémoire totale du répartiteur dépend à la fois du profil mémoire et de la cardinalité (nombre de réplicas frontaux, de partitions back-end et du facteur de redondance). Plus de pods signifient plus de mémoire totale. Pour connaître la consommation de ressources de référence mesurée sur différentes configurations, consultez profils de ressources de base de référence.

Calculer l’utilisation totale de la mémoire

Vous pouvez calculer l’utilisation totale de la mémoire avec cette formule :

M_total = (R_fe × M_fe) + (P_be × RF_be × M_be × W_be)

Where:

Par exemple, si vous choisissez le profil de mémoire moyenne , le profil a une utilisation de la mémoire frontale de 1,9 Gio et une utilisation de la mémoire principale de 1,5 Gio. Supposez que la configuration du courtier soit deux réplicas front-end, deux partitions back-end, et un facteur de redondance back-end égal à deux. L’utilisation totale de la mémoire est la suivante :

M_total = (2 × 1.9 GiB) + (2 × 2 × 1.5 GiB × 2)
        = 15.8 GiB

Par comparaison, le profil de mémoire Tiny a une utilisation de la mémoire front-end de 99 Mio et une utilisation de la mémoire principale de 102 Mio. Avec la même configuration broker, l’utilisation totale de la mémoire est la suivante :

M_total = (2 × 99 MiB) + (2 × 2 × 102 MiB × 2)
        = 198 MiB + 816 MiB
        = 1014 MiB (≈ 1.0 GiB)

Configuration du profil de mémoire

Lorsque vous déployez des opérations IoT à l’aide de la az iot ops create commande, le --broker-mem-profile paramètre spécifie les paramètres du profil de mémoire.

Par exemple, la commande suivante définit le profil Tiny de mémoire sur (d’autres paramètres sont omis pour la concision) :

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

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

Paramètres de répartiteur facultatifs

Les paramètres broker suivants sont également configurés au moment du déploiement et ne peuvent pas être modifiés par la suite. Passez en revue ces éléments s’ils s’appliquent à votre scénario :

• Tampon de messages sur disque — Place les messages en tampon sur le disque lorsque les files d’attente des abonnés dépassent la mémoire disponible. Utile pour les sessions persistantes et les défis de connectivité.
• Persistance : écrire des données de répartiteur critiques sur le disque pour la conserver au cours des redémarrages.
• Diagnostics — Paramétrez les métriques, les journaux et les sondes d’auto-vérification pour le broker MQTT.
• Options MQTT avancées : personnaliser l’expiration de la session, l’expiration des messages, les limites de file d’attente des abonnés et les paramètres de conservation.
• Chiffrement du trafic interne : configurez le chiffrement du trafic interne entre le serveur frontal broker et les pods back-end (activés par défaut).

Étapes suivantes

• Préparer votre cluster
• Déployer sur un cluster de production
• Configurer l’observabilité
• Sécuriser votre déploiement