Bereitstellungsplanung für Azure IoT Einsatz

Viele Azure IoT Einsatz Einstellungen sind bei der Bereitstellung festgelegt und können nur durch eine erneute Bereitstellung geändert werden. Planen Sie vor der Bereitstellung Die Clustertopologie, die Broker-Kardinalität, das Speicherprofil und die optionalen Brokereinstellungen, die Sie benötigen. In diesem Artikel werden die Entscheidungen zusammengefasst, die Sie treffen sollten.

Die Architektur verstehen

Azure IoT Einsatz ist eine Reihe modularer, kubernetes-nativer Dienste, die in einem Azure Arc-fähigen Cluster bereitgestellt werden. Zu den wichtigsten Komponenten gehören:

In der gesamten Dokumentation werden zwei Begriffe verwendet:

• Bereitstellung – Die Instanz, Arc-Erweiterungen, benutzerdefinierte Standorte und alle konfigurierbaren Ressourcen (Ressourcen, Geräte, Datenflüsse).
• Instanz – Die übergeordnete Ressource, die die Dienste bündelt.

Auswählen der Clustertopologie

Bevor Sie die Bereitstellung ausführen, entscheiden Sie, ob Sie einen Einzelknoten oder einen Cluster mit mehreren Knoten benötigen. Diese Entscheidung bestimmt die Hardwareanforderungen und die Broker-Kardinalitätseinstellungen.

Brokerkardinalität verstehen

Die Kardinalität ist die Anzahl der Frontend-Replikate, Frontend-Worker, Backend-Partitionen und Backend-Worker in der Broker-Bereitstellung. Die Kardinalität steuert, wie der Broker horizontal skaliert und wie widerstandsfähig er gegenüber Ausfällen von Pods oder Nodes ist.

Der MQTT-Broker verfügt über eine zweistufige Architektur: Frontend-Pods verarbeiten Clientverbindungen und Protokollverarbeitung, während Back-End-Pods nachrichtenspeicherung und -übermittlung verarbeiten. Das Verständnis, wie die einzelnen Ebenen skaliert werden, ist für die Kapazitätsplanung wichtig.

Frontend

Frontend-Pods akzeptieren MQTT-Clientverbindungen und weiterleiten Nachrichten an das Back-End. Front-End-Pods speichern keine Nachrichten selbst. Es gibt zwei Haupteinstellungen für die Front-End-Ebene:

• Replikate: Die Anzahl der bereitzustellenden Front-End-Pods. Das Hinzufügen weiterer Frontend-Replikate erhöht die Anzahl gleichzeitiger Client-Verbindungen, die der Broker verarbeiten kann, und sorgt für Hochverfügbarkeit, falls einer der Frontend-Pods ausfällt.
• Workers: Die Anzahl der logischen Worker pro Front-End-Pod. Durch das Hinzufügen weiterer Mitarbeiter kann der Frontend-Pod mehr CPU-Kerne verwenden. Jeder Worker kann bis zu einem CPU-Kern verbrauchen.

Back-End-Kette

Backend-Pods übernehmen die Nachrichtenspeicherung und -zustellung. Es gibt drei Haupteinstellungen für die Back-End-Ebene:

• Partitionen: Die Anzahl der bereitzustellenden Partitionen. Partitionen sind die Einheit der horizontalen Skalierung für den Nachrichtendurchsatz. Durch einen Prozess, der als Sharding bezeichnet wird, verarbeitet jede Partition einen Teil der Nachrichten, die nach Thema und Sitzung gehardet werden. Die Front-End-Pods verteilen den Nachrichtendatenverkehr auf die Partitionen. Durch das Hinzufügen weiterer Partitionen erhöht sich der gesamte Nachrichtendurchsatz, den der Broker verarbeiten kann.
• Redundanzfaktor: Die Anzahl der Back-End-Pods, die pro Partition bereitgestellt werden sollen. Durch das Erhöhen des Redundanzfaktors erhöht sich die Anzahl der Datenkopien, um Resilienz gegenüber Knotenfehlern im Cluster zu ermöglichen.
• Worker: Die Anzahl der Worker pro Back-End-Pod. Mitarbeiter sind die Einheit der vertikalen Skalierung innerhalb einer Partition . Durch das Hinzufügen weiterer Mitarbeiter kann der Back-End-Pod mehr CPU-Kerne auf demselben Knoten verwenden. Jeder Worker kann bis zu zwei CPU-Kerne nutzen. Achten Sie daher darauf, beim Erhöhen der Anzahl der Worker pro Replikat die Anzahl der CPU-Kerne im Cluster nicht zu überschreiten.

Durchsatzschätzung

Die Leistung einer einzelnen Partition hängt stark von den CPU-Merkmalen des Knotens ab, auf dem sie ausgeführt wird. Als Faustregel erwarten Sie ungefähr 5.000 bis 6.000 QoS 1-Nachrichten pro Sekunde pro Partition mit 8-KB-Nutzlasten auf einer 2-GHz-CPU (~4-GHz Turbo). Die reale Leistung hängt von vielen Faktoren ab. Verwenden Sie diese Zahl also nur als Ausgangspunkt für die Kapazitätsplanung.

Detaillierte Benchmarkdaten finden Sie unter MQTT Broker Performance Benchmarking.

Empfehlungen für einen einzelnen Knoten

• Frontend-Replikate: Auf 1 festgelegt.
• Front-End-Worker: Legen Sie die Hälfte der CPU-Kerne pro Knoten fest.
• Back-End-Replikate (Redundanzfaktor): Legen Sie auf mindestens 2 fest, damit der Broker Rollupdates ausführen kann.

Beispiel: Einzelner Knoten, 4 CPU-Kerne

Empfehlungen für mehrere Knoten

Die folgenden Werte werden für eine optimale Leistung empfohlen. Bei großen Clustern mit geringem Datenverkehr können diese Werte niedriger als die Empfehlungen festgelegt werden, ohne Probleme zu verursachen. Weitere Überlegungen wie Arbeitsspeicher (RAM) und Leistungsmerkmale werden in den folgenden Abschnitten erläutert. Testen Sie ihre Konfiguration immer mit der erwarteten Workload, um die Leistung zu bestätigen.

• Front-End-Replikate: Gleich der Anzahl der Knoten im Cluster setzen.
• Front-End-Worker: Legen Sie die Hälfte der CPU-Kerne pro Knoten fest.
• Backend-Replikate (Redundanzfaktor): Für Redundanz und Unterstützung für Rolling Updates auf 2 festlegen.
• Back-End-Partitionen: Legen Sie gleich der Anzahl der Knoten im Cluster fest.
• Back-End-Mitarbeiter: Legen Sie die Hälfte der CPU-Kerne pro Knoten fest.

Beispiel: 3-Knoten-Cluster, 8 CPU-Kerne pro Knoten

Beispiel: 5-Knoten-Cluster, 16 CPU-Kerne pro Knoten

CPU-Ressourcenbeschränkungen

Um Ressourcenverhungern im Cluster zu verhindern, kann der Broker so konfiguriert werden, dass Kubernetes CPU-Ressourcengrenzwerte basierend auf den Kardinalitätseinstellungen angefordert werden. Wenn diese Option aktiviert ist, erhöht die Skalierung der Anzahl von Replikaten oder Workern proportional die erforderlichen CPU-Ressourcen.

Die Standardeinstellung für REST-API-, Bicep- und ARM-Vorlagen ist in der Broker-API-Spezifikation definiert.

Der MQTT-Broker fordert CPU-Ressourcen pro Pod basierend auf der Anzahl der konfigurierten Mitarbeiter an:

• Frontend-Pods: 1,0 CPU pro Worker
• Back-End-Pods: 2.0 CPU pro Worker

Verwenden Sie die folgenden Formeln, um die CPU-Gesamtanforderungen zu berechnen:

Beispiel: kleiner Cluster

Erwägen Sie einen 2-Knoten-Cluster mit 4 CPU-Kernen pro Knoten (insgesamt 8 Kerne) mit der folgenden Kardinalität:

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

Der Broker fordert Folgendes an:

• Frontend CPU: 2 Replikas × 2 Arbeiter × 1:0 = 4:0 CPU
• Backend-CPU: 1 Partition × 2 RF × 1 Worker × 2,0 = 4,0 CPU
• Gesamtbroker-CPU: 8.0 CPU

Diese Konfiguration fordert 8.0 CPU auf einem Cluster mit nur 8 Kernen an, wobei für andere Azure IoT Einsatz Komponenten (200-300m) oder für Kubernetes-System pods nichts übrig bleibt. Die Broker-Pods verbleiben im Zustand Pending mit Fehlern vom Typ Insufficient cpu.

Um dies zu beheben, fügen Sie entweder weitere Knoten hinzu, erhöhen Sie die Kerne pro Knoten, oder verringern Sie die Broker-Kardinalität.

Beispiel: größere Bereitstellung

Die folgende Kardinalität fordert deutlich mehr CPU-Ressourcen an:

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

• Frontend CPU: 2 Replikas × 2 Arbeiter × 1:0 = 6:0 CPU
• Back-End-CPU: 3 Partitionen × 2 RF × 2 Worker × 2,0 = 24.0 CPU
• Gesamt-Broker CPU: 30.0 CPU

Ein Cluster benötigt mindestens 30 verfügbare CPU-Kerne allein für Broker-Pods sowie zusätzliche Kapazität für andere Azure IoT Einsatz-Komponenten und Kubernetes-System-Pods.

Konfiguration der CPU-Ressourcenbeschränkung

CPU-Ressourcengrenzwerte werden vom generateResourceLimits.cpu Feld in der Brokerressource gesteuert. Diese Konfiguration wird nur mithilfe des --broker-config-file Flags unterstützt, wenn Sie Azure IoT Einsatz mithilfe des az iot ops create Befehls bereitstellen. Weitere Informationen finden Sie unter Azure CLI-Unterstützung für die erweiterte MQTT-Brokerkonfiguration.

Bereiten Sie eine Brokerkonfigurationsdatei vor, indem Sie der GenerateResourceLimits-API-Referenz folgen. Die folgenden Beispiele zeigen die beiden möglichen Werte:

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

Oder

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

Wählen Sie Ihr Speicherprofil aus.

Das Speicherprofil steuert die maximale MQTT-Nachrichtengröße, die der Broker akzeptiert, die Speicherauslastung im Leerlauf und die maximale Speicherauslastung der einzelnen Pods. Entscheiden Sie sich für das richtige Speicherprofil vor der Bereitstellung basierend auf den erwarteten Nachrichtengrößen und dem Durchsatz.

Eingehender Puffer und Rückdruck

Jedes Speicherprofil definiert eine maximale Eingehende Puffergröße für PUBLISH-Daten pro Back-End-Worker. Wenn der Puffer 75% Kapazität erreicht, aktiviert der Broker Backpressure-Mechanismen und beginnt mit dem Ablehnen eingehender Nachrichten. Abgelehnte Pakete erhalten als Antwort ein PUBACK mit dem Fehlercode Kontingent überschritten.

Die folgende Tabelle zeigt die Größe der eingehenden Puffer für jeden Mitarbeiter für jedes Profil:

Berücksichtigen Sie bei der Auswahl eines Speicherprofils Folgendes:

• Klein: Es sollte nur ein Frontend verwendet werden. Nur Pakete senden, die kleiner als 4 MiB sind.
• Niedrig: Es sollten nur ein oder zwei Frontends verwendet werden. Senden Sie nur Pakete, die kleiner als 16 MiB sind.
• Mittel: Geeignet für die meisten Produktionsworkloads mit moderaten Nachrichtengrößen.
• Hoch: Verwenden Sie diese Eigenschaft, wenn Sie große Nachrichten oder hohen Durchsatz mit großen Puffern verarbeiten müssen.

Der gesamte Brokerspeicher hängt sowohl vom Speicherprofil als auch von der Kardinalität ab (Anzahl der Frontend-Replikate, Back-End-Partitionen und Redundanzfaktor). Mehr Pods bedeuten mehr Gesamtspeicher. Informationen zum gemessenen geplanten Ressourcenverbrauch in verschiedenen Konfigurationen finden Sie unter Baseline-Ressourcenprofile.

Berechnen der Gesamtspeicherauslastung

Sie können die Gesamtspeicherauslastung mit dieser Formel berechnen:

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

Ort:

Wenn Sie z. B. das Profil für mittleren Speicher auswählen, verfügt das Profil über eine Frontend-Speicherauslastung von 1,9 GiB und eine Back-End-Speicherauslastung von 1.5 GiB. Angenommen, die Brokerkonfiguration ist 2 Frontend-Replikate, 2 Back-End-Partitionen und ein Back-End-Redundanzfaktor von 2. Die Gesamtspeicherauslastung lautet:

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

Im Vergleich dazu verfügt das Tiny-Speicherprofil über eine Frontend-Speicherauslastung von 99 MiB und eine Back-End-Speicherauslastung von 102 MiB. Bei derselben Brokerkonfiguration lautet die Gesamtspeicherauslastung:

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

Speicherprofilkonfiguration

Wenn Sie IoT-Vorgänge mithilfe des az iot ops create Befehls bereitstellen, gibt der --broker-mem-profile Parameter die Speicherprofileinstellungen an.

Mit dem folgenden Befehl wird das Speicherprofil beispielsweise auf Tiny festgelegt (andere Parameter werden der Kürze halber weggelassen):

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

Weitere Informationen finden Sie unter az iot ops create optionale Parameter.

Optionale Brokereinstellungen

Die folgenden Brokereinstellungen werden auch zur Bereitstellungszeit konfiguriert und können danach nicht mehr geändert werden. Überprüfen Sie diese, wenn sie für Ihr Szenario gelten:

• Disk-backed message buffer – Puffern von Nachrichten auf datenträger, wenn Abonnentenwarteschlangen den verfügbaren Arbeitsspeicher überschreiten. Nützlich für dauerhafte Sitzungen und Konnektivitätsprobleme.
• Persistenz – Schreiben Sie kritische Brokerdaten auf den Datenträger, um sie über Neustarts hinweg beizubehalten.
• Diagnose – Konfigurieren von Metriken, Protokollen und Selbstüberprüfungssonden für den MQTT-Broker.
• Erweiterte MQTT-Optionen – Anpassen des Sitzungsablaufs, Ablauf der Nachricht, Begrenzungen der Abonnentenwarteschlange und Keep-Alive-Einstellungen.
• Interne Datenverkehrsverschlüsselung – Konfigurieren der Verschlüsselung des internen Datenverkehrs zwischen Broker-Frontend- und Back-End-Pods (standardmäßig aktiviert).

Nächste Schritte

• Vorbereiten des Clusters
• Auf einem Produktionscluster bereitstellen
• Observability konfigurieren
• Sichern Sie Ihre Bereitstellung