Profils de ressources de référence pour Opérations Azure IoT

Cette référence fournit une consommation de ressources de référence mesurée pour les déploiements Opérations Azure IoT au niveau inactif (aucune charge de travail active). Utilisez ces profils pour valider que votre matériel répond à la configuration minimale requise et pour établir des bases de référence de surveillance des ressources.

Aperçu

Opérations Azure IoT déploie plusieurs composants sur plusieurs espaces de noms Kubernetes. L’empreinte totale des ressources dépend de deux facteurs : le profil de mémoire du répartiteur MQTT (qui contrôle l’allocation de mémoire par pod) et la cardinalité du répartiteur (nombre de réplicas front-end, partitions principales et facteur de redondance, qui contrôle le nombre de pods déployés). Une cardinalité plus élevée signifie plus de pods, et un profil de mémoire plus élevé signifie que chaque pod utilise plus de mémoire.

Trois configurations ont été mesurées sur des clusters à nœud unique au niveau inactif (aucune ressources connectées, aucun flux de données actif, un trafic proche de zéro). Il s’agit de nombres de référence, et non de nombres maximums. Les charges de travail de production augmentent considérablement la consommation :

Configuration Profil de mémoire Cardinalité Mémoire maximale du nœud Espace de noms maximal RSS Opérations Azure IoT Total maximal RSS des pods Nombre de pods
Configuration A Tiny 1 frontal
1 partition
facteur de redondance 2
~4 979 Mio ~1 298 MiB ~5 409 MiB 55
Configuration B Faible 2 serveurs frontaux
2 partitions
facteur de redondance 2
~5 130 MiB ~1 559 Mio ~5 695 Mio 58
Configuration C Moyenne 2 serveurs frontaux
2 partitions
facteur de redondance 2
~6 088 MiB ~2 407 Mio ~ 6 564 Mio 58

Note

La différence entre la configuration A et la configuration B provient de la cardinalité supérieure (plus de pods broker) et d’un profil de mémoire différent. La différence entre la configuration B et la configuration C est purement du profil de mémoire (même cardinalité, même nombre de pods). Consultez les exemples de déploiement de production pour les scénarios chargés.

Répartition des espaces de noms

Le tableau suivant montre les pics de mémoire RSS par espace de noms sur les trois configurations inactives :

Namespace Configuration A, Tiny (Mio) Configuration B, Low (Mio) Config C, Moyenne (MiB) Description
azure-iot-operations 1,298 1,559 2,407 Opérations Azure IoT principaux services (répartiteur, flux de données, connecteurs, observabilité)
azure-arc 1,964 1,985 1,990 Azure Arc agents et contrôleurs
cert-manager 1,351 1,357 1,362 Gestion des certificats
gatekeeper-system 338 338 350 Application de la stratégie
azure-extensions-usage-system 279 277 278 Opérateur de facturation
arc-workload-identity 90 90 91 Webhooks d’identité de charge de travail
azure-secret-store 87 88 87 Contrôleur de synchronisation des secrets
Total ~5 409 ~5 695 ~6 564

Note

  • Azure Arc, cert-manager, gatekeeper et autres espaces de noms d’infrastructure consomment environ 3,8 à 4,1 Go, quelle que soit la configuration du répartiteur. Cette surcharge est le coût fixe de l’exécution d’un cluster avec Arc avec Opérations Azure IoT.
  • Seul le azure-iot-operationsespace de noms évolue en fonction de la configuration mémoire et des choix de cardinalité, de ~1,3 Go (Petite, cardinalité minimale) à ~2,4 Go (Moyenne, cardinalité plus élevée).
  • Planifiez au moins 6 Go de mémoire dédiée à Opérations Azure IoT infrastructure au niveau inactif avant de prendre en compte les charges de travail.

Consommation des ressources du pod du broker MQTT

Le répartiteur MQTT est le composant variable le plus important. Les différences de mémoire entre les configurations proviennent du profil de mémoire (allocation par pod) et de la cardinalité (nombre de pods). Le tableau suivant montre le flux RSS inactif par pod. Ces nombres augmentent avec le trafic :

Pod Configuration A, Tiny (Mio) Configuration B, Low (Mio) Config C, taille moyenne (MiB) Remarques
aio-broker-frontend-0 29 33 169 La mémoire par pod évolue en fonction du profil
aio-broker-frontend-1 N/A 33 169 Absent dans la configuration A (un réplica frontal)
aio-broker-backend-1-0 41 66 211 La mémoire par pod évolue selon le profil
aio-broker-backend-1-1 41 65 210 Réplique du facteur de redondance
aio-broker-backend-2-0 N/A 66 212 Non présent dans la configuration A (une partition)
aio-broker-backend-2-1 N/A 65 211 Non présent dans la configuration A (une partition)
aio-broker-health-manager-0 41 41 42 Identique sur tous les profils
aio-broker-operator-0 60 60 56 Constante sur tous les profils
aio-broker-diagnostics-probe-0 24 43 43
aio-broker-diagnostics-service-0 49 66 66
aio-broker-authentication-0 24 24 24 Identique sur tous les profils
aio-broker-webhook-0 33 35 32 Identique pour tous les profils

Configuration du courtier par profil testée

Setting Configuration A (Tiny) Configuration B (Low) Configuration C (moyenne)
Réplicas frontaux 1 2 2
Partitions back-end 1 2 2
Facteur de redondance du back-end 2 2 2
Total des pods de répartiteur 10 13 13
Mémoire frontale inactive par pod ~29 Mio ~33 MiB ~169 MiB
Mémoire principale inactive par pod ~41 Mio ~66 MiB ~211 MiB
Taille maximale du message 4 Mo 16 Mo 64 Mo

Consommation des autres composants Opérations Azure IoT

Ces composants ont une utilisation cohérente des ressources inactives, quel que soit le profil de mémoire ou la cardinalité :

Composant RSS maximal (MiB) Nombre maximal de cœurs du processeur Remarques
adr-schema-registry (x2) ~52 chacun 0.002 Pods du registre de schéma
aio-akri-operator-0 ~39 0.001 Découverte d’appareils Akri
aio-akri-adr-service-0 ~30 0.001 Service de registre des appareils Akri Azure (ADR)
aio-dataflow-dev-0 ~67 0.002 Environnement d’exécution du flux de données
aio-dataflow-operator-0 ~56 0.001 Opérateur de flux de données
aio-operator ~114 0.003 opérateur Opérations Azure IoT
aio-observability (x2) ~125 chacun 0.005 Collecteurs OpenTelemetry
aio-observability-operator ~106 0.003 Opérateur d’observabilité
aio-observability-cluster-metrics-agent ~114 0.004 Agent pour les mesures
aio-wasm-graph-controller-0 ~30 0.001 Contrôleur de graphique WebAssembly (WASM)

CPU consumption (Consommation du processeur)

La consommation du processeur est minimale au niveau inactif dans toutes les configurations testées :

Configuration Espace de noms maximal CPU Opérations Azure IoT Pic total de CPU du cluster % de nœuds
Configuration A (Petite) 0.025 cœurs 0.099 cœurs 1,3 %
Configuration B (basse) 0,044 cœurs 0.104 cœurs 1,3 %
Configuration C (moyen) 0,048 cœurs 0.093 cœurs 1,2 %

L’utilisation du processeur est négligeable lors de l’inactivité. En cas de charge de production, attendez-vous à une consommation de processeur beaucoup plus élevée proportionnelle au débit des messages et au nombre de workers frontend/back-end configurés.

Conseils de dimensionnement matériel

En fonction de ces mesures de référence inactives, les recommandations matérielles minimales suivantes s’appliquent aux déploiements à nœud unique. Les exigences réelles sont plus élevées en conditions de trafic de production :

Profil de mémoire RAM minimale (avec marge) RAM recommandée Cas d’usage
Petit 8 Go 8 à 10 Go Trafic faible, petits paquets uniquement
Faible 10 Go 12–16 Go Mémoire limitée, petits paquets
Moyenne 12 Go 16 à 32 Go Modérer le trafic et les tailles de message
Élevé 16 Go 32 Go ou plus Débit élevé, messages volumineux

Important

Ces recommandations tiennent compte du surcoût fixe de l’infrastructure d’environ ~4 Go (Azure Arc, cert-manager, gatekeeper), ainsi que de l’empreinte variable des composants Opérations Azure IoT. Les charges de travail de production nécessitent un espace principal supplémentaire pour la mise en mémoire tampon des messages MQTT, le traitement des flux de données et l’activité du connecteur OPC UA.