Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Diese Referenz enthält einen gemessenen geplanten Ressourcenverbrauch für Azure IoT Einsatz Bereitstellungen im Leerlauf (keine aktiven Workloads). Verwenden Sie diese Profile, um ihre Hardware zu überprüfen, die Mindestanforderungen erfüllt, und um Ressourcenüberwachungsbaselines einzurichten.
Übersicht
Azure IoT Einsatz stellt mehrere Komponenten in mehreren Kubernetes-Namespaces bereit. Der gesamte Ressourcenbedarf hängt von zwei Faktoren ab: dem MQTT-Broker-Speicherprofil (das die Speicherzuweisung pro Pod steuert) und die Broker-Kardinalität (Anzahl der Frontend-Replikate, Back-End-Partitionen und Redundanzfaktor, der steuert, wie viele Pods bereitgestellt werden). Höhere Kardinalität bedeutet mehr Pods, und ein höheres Speicherprofil bedeutet, dass jeder Pod mehr Arbeitsspeicher verwendet.
Drei Konfigurationen wurden in Einzelknotenclustern im Leerlauf gemessen (keine verbundenen Ressourcen, keine aktiven Datenflüsse, nahezu null Datenverkehr). Hierbei handelt es sich um Basiswerte, nicht um Maximalwerte. Produktionsarbeitsauslastungen erhöhen den Verbrauch erheblich:
| Configuration | Speicherprofil | Kardinalität | Maximaler Speicherverbrauch des Knotens | Azure IoT Einsatz Namespace Peak RSS | Gesamter RSS-Spitzenwert des Pods | Podanzahl |
|---|---|---|---|---|---|---|
| Konfiguration A | Sehr klein | 1 Frontend 1 Partition Redundanzfaktor 2 |
~4.979 MiB | ~1,298 MiB | ~5.409 MiB | 55 |
| Konfiguration B | Niedrig | 2 Frontends 2 Partitionen Redundanzfaktor 2 |
~5,130 MiB | ~1.559 MiB | ~5,695 MiB | 58 |
| Konfiguration C | Medium | 2 Front-Ends 2 Partitionen Redundanzfaktor 2 |
~6.088 MiB | ~2.407 MiB | ~6,564 MiB | 58 |
Note
Der Unterschied zwischen Config A und Config B kommt sowohl von höherer Kardinalität (mehr Broker-Pods) als auch aus einem anderen Speicherprofil. Der Unterschied zwischen Config B und Config C ist rein aus dem Speicherprofil (gleiche Kardinalität, gleiche Podanzahl). Unter Beispiele für Produktionsbereitstellungen finden Sie Auslastungsszenarien.
Aufschlüsselung des Namespace
Die folgende Tabelle zeigt den Spitzenwert des RSS-Speichers pro Namespace über alle drei Konfigurationen hinweg im Leerlauf:
| Namespace | Konfiguration A, Klein (MiB) | Konfiguration B, Niedrig (MiB) | Konfiguration C, Mittel (MiB) | Description |
|---|---|---|---|---|
| Azure-iot-operations | 1,298 | 1,559 | 2,407 | Azure IoT Einsatz Kerndienste (Broker, Datenflüsse, Konnektoren, Beobachtbarkeit) |
| Azure-Arc | 1,964 | 1,985 | 1,990 | Azure Arc-Agenten und Controller |
| cert-manager | 1,351 | 1,357 | 1,362 | Zertifikatverwaltung |
| Gatekeeper-System | 338 | 338 | 350 | Durchsetzung von Richtlinien |
| azure-extensions-usage-system | 279 | 277 | 278 | Abrechnungsoperator |
| arc-workload-identity | 90 | 90 | 91 | Webhooks für die Workload-Identität |
| azure-secret-store | 87 | 88 | 87 | Geheimer Synchronisierungscontroller |
| Gesamt | ~5.409 | ~5,695 | ~6,564 |
Note
- Azure Arc, cert-manager, gatekeeper und andere Infrastrukturnamespaces verbrauchen ~ 3.8-4.1 GB, unabhängig von der Brokerkonfiguration. Dieser Aufwand ist die Fixkosten für die Ausführung eines Arc-fähigen Clusters mit Azure IoT Einsatz.
-
Nur der
azure-iot-operationsNamespace skaliert mit den Speicherprofilen und Kardinalitätsoptionen von ~1,3 GB (Winzige, minimale Kardinalität) auf ~2,4 GB (Mittel, höhere Kardinalität). - Planen Sie mindestens 6 GB Arbeitsspeicher für Azure IoT Einsatz Infrastruktur im Leerlauf, bevor Sie Workloads berücksichtigen.
Ressourcenverbrauch des MQTT-Broker-Pods
Der MQTT-Broker ist die größte variable Komponente. Speicherunterschiede zwischen Konfigurationen stammen sowohl aus dem Speicherprofil (pro Pod-Zuweisung) als auch aus der Kardinalität (Anzahl der Pods). Die folgende Tabelle zeigt die RSS-Werte im Leerlauf pro Pod. Diese Zahlen wachsen mit Datenverkehr:
| Pod | Konfiguration A, Klein (MiB) | Config B, Niedrig (MiB) | Konfiguration C, Mittel (MiB) | Hinweise |
|---|---|---|---|---|
| aio-broker-frontend-0 | 29 | 33 | 169 | Der Arbeitsspeicher pro Pod skaliert mit dem Profil |
| aio-broker-frontend-1 | – | 33 | 169 | In Config A nicht vorhanden (ein Frontend-Replikat) |
| aio-broker-backend-1-0 | 41 | 66 | 211 | Speicherskalen pro Pod mit Profil |
| aio-broker-backend-1-1 | 41 | 65 | 210 | Replikat des Redundanzfaktors |
| aio-broker-backend-2-0 | – | 66 | 212 | In Config A nicht vorhanden (eine Partition) |
| aio-broker-backend-2-1 | – | 65 | 211 | In Config A nicht vorhanden (eine Partition) |
| aio-broker-health-manager-0 | 41 | 41 | 42 | Profilübergreifend konstant |
| aio-broker-operator-0 | 60 | 60 | 56 | Über alle Profile hinweg konstant |
| aio-broker-diagnostics-probe-0 | 24 | 43 | 43 | |
| aio-broker-diagnostics-service-0 | 49 | 66 | 66 | |
| aio-broker-authentication-0 | 24 | 24 | 24 | Profilübergreifend konstant |
| aio-broker-webhook-0 | 33 | 35 | 32 | Konstant in allen Profilen |
Brokerkonfiguration pro getesteten Profilen
| Setting | Konfiguration A (Klein) | Konfiguration B (Niedrig) | Konfiguration C (Mittel) |
|---|---|---|---|
| Frontend-Replikate | 1 | 2 | 2 |
| Back-End-Partitionen | 1 | 2 | 2 |
| Back-End-Redundanzfaktor | 2 | 2 | 2 |
| Gesamtbroker-Pods | 10 | 13 | 13 |
| Frontend-Speicherverbrauch im Leerlauf pro Pod | ~29 MiB | ~33 MiB | ~169 MiB |
| Back-End-Speicher im Leerlauf pro Pod | ~41 MiB | ~66 MiB | ~211 MiB |
| Maximale Nachrichtengröße | 4 MB | 16 MB | 64 MB |
Anderer Azure IoT Einsatz Komponentenverbrauch
Diese Komponenten weisen unabhängig von Speicherprofil oder Kardinalität eine konsistente Leerlaufressourcennutzung auf:
| Bestandteil | Maximaler RSS (MiB) | Spitzen-CPU (Kerne) | Hinweise |
|---|---|---|---|
| adr-schema-registry (x2) | ~52 je Stück | 0.002 | Schema-Registrierungs-Pods |
| aio-akri-operator-0 | ~39 | 0.001 | Akri-Geräteerkennung |
| aio-akri-adr-service-0 | ~30 | 0.001 | Akri Azure Device Registry (ADR)-Dienst |
| aio-dataflow-dev-0 | ~67 | 0.002 | Datenflusslaufzeit |
| aio-dataflow-operator-0 | ~56 | 0.001 | Datenflussoperator |
| aio-operator | ~114 | 0.003 | Azure IoT Einsatz-Operator |
| aio-Observability (x2) | jeweils ~125 | 0.005 | OpenTelemetry-Collectors |
| aio-observability-operator | ~106 | 0.003 | Operator für Beobachtbarkeit |
| aio-observability-cluster-metrics-agent | ~114 | 0.004 | Agent für Metriken |
| aio-wasm-graph-controller-0 | ~30 | 0.001 | WebAssembly (WASM)-Graph-Controller |
CPU-Verbrauch
Die CPU-Auslastung ist für alle getesteten Konfigurationen minimal im Leerlauf:
| Configuration | Azure IoT Einsatz Namespace Peak CPU | Gesamtanzahl der Cluster-Spitzen-CPU | % des Knotens |
|---|---|---|---|
| Config A (Tiny) | 0,025 Kerne | 0,099 Kerne | 1,3 % |
| Konfiguration B (Niedrig) | 0,044 Kerne | 0,104 Kerne | 1,3 % |
| Config C (Mittel) | 0,048 Kerne | 0,093 Kerne | 1,2 % |
Die CPU-Auslastung ist im Leerlauf vernachlässigbar. Erwarten Sie bei produktionsbezogener Auslastung einen deutlich höheren CPU-Verbrauch im Verhältnis zum Nachrichtendurchsatz und die Anzahl der konfigurierten Frontend-/Back-End-Mitarbeiter.
Leitfaden zur Hardwaredimensionierung
Basierend auf diesen Leerlaufbasiswerten gelten die folgenden Hardwareempfehlungen für Bereitstellungen mit einem einzigen Knoten. Die tatsächlichen Anforderungen sind im Produktionsverkehr höher:
| Speicherprofil | Min. RAM (mit Spielraum) | Empfohlener RAM | Anwendungsfall |
|---|---|---|---|
| Winzig | 8 GB | 8–10 GB | Geringer Datenverkehr, nur kleine Pakete |
| Low | 10 GB | 12–16 GB | Begrenzter Arbeitsspeicher, kleine Pakete |
| Mittel | 12 GB | 16–32 GB | Moderater Datenverkehr und Nachrichtengrößen |
| Hoch | 16 GB | 32+ GB | Hoher Durchsatz, große Nachrichten |
Important
Diese Empfehlungen berücksichtigen den ca. 4 GB festen Infrastrukturaufwand (Azure Arc, Cert-Manager, Gatekeeper) sowie die Variable Azure IoT Einsatz Komponentenbedarf. Für Produktionsworkloads wird zusätzlicher Spielraum für die Pufferung von MQTT-Nachrichten, die Verarbeitung von Datenflüssen und die Aktivität des OPC UA-Connectors benötigt.