Freigeben über

Konfigurieren von Brokereinstellungen für Hochverfügbarkeit, Skalierung und Speicherauslastung

Die Broker-Ressource ist die Hauptressource, die die allgemeinen Einstellungen für einen MQTT-Broker definiert. Sie bestimmt auch die Anzahl und den Typ der Pods, die die Broker-Konfiguration ausführen, z. B. die Front-Ends und die Back-Ends. Sie können auch die Brokerressource verwenden, um ihr Speicherprofil zu konfigurieren. In den Broker sind Self-healing-Mechanismen integriert, und er kann häufig automatisch nach Komponentenausfällen wiederhergestellt werden. Beispiel: Wenn ein Knoten in einem für Hochverfügbarkeit konfigurierten Kubernetes-Cluster ausfällt

Sie können den MQTT-Broker horizontal skalieren, indem Sie weitere Front-End-Replikate und Back-End-Partitionen hinzufügen. Die Front-End-Replikate sind für die Annahme von MQTT-Verbindungen von Clients und deren Weiterleitung an die Back-End-Partitionen zuständig. Die Back-End-Partitionen sind für das Speichern und Übermitteln von Nachrichten an die Clients verantwortlich. Die Front-End-Pods verteilen den Nachrichtendatenverkehr auf die Back-End-Pods. Der Back-End-Redundanzfaktor bestimmt die Anzahl der Datenkopien, um Resilienz gegenüber Knotenfehlern im Cluster zu ermöglichen.

Eine Liste der verfügbaren Einstellungen finden Sie in der API-Referenz zum Broker.

Konfigurieren von Skalierungseinstellungen

Wichtig

Für diese Einstellung müssen Sie die Brokerressource ändern. Sie ist nur bei der ersten Bereitstellung mithilfe der Azure CLI oder des Azure-Portals konfiguriert. Eine neue Bereitstellung ist erforderlich, wenn Änderungen an der Broker-Konfiguration erforderlich sind. Weitere Informationen finden Sie unter Anpassen des Standardbrokers.

Um die Skalierungseinstellungen des MQTT-Brokers zu konfigurieren, geben Sie die Kardinalitätsfelder in der Spezifikation der Broker-Ressource während der Azure IoT Einsatz-Bereitstellung an.

Kardinalität bei der automatischen Bereitstellung

Um die anfängliche Kardinalität während der Bereitstellung automatisch zu ermitteln, lassen Sie das Kardinalitätsfeld in der Broker-Ressource leer.

Die automatische Kardinalität wird noch nicht unterstützt, wenn Sie Azure IoT Einsatz über das Azure-Portal bereitstellen. Sie können den Clusterbereitstellungsmodus manuell als Einzelner Knoten oder Mehrere Knoten angeben. Weitere Informationen finden Sie unter Bereitstellen von Azure IoT-Vorgängen.

Screenshot, der zeigt, wo die Einrichtung eines einzelnen oder mehrerer Knoten im Azure-Portal ausgewählt werden soll

Der Operator für den MQTT-Broker stellt die entsprechende Anzahl von Pods basierend auf der Anzahl der Knoten automatisch bereit, die zur Bereitstellungszeit verfügbar sind. Diese Funktion ist nützlich für Nichtproduktionsszenarios, in denen Sie keine Hochverfügbarkeit oder Skalierung benötigen.

Diese Funktion ist keine automatische Skalierung. Der Operator skaliert die Anzahl der Pods basierend auf der Last nicht automatisch. Der Operator bestimmt nur die anfängliche Anzahl von Pods, die nur basierend auf der Clusterhardware bereitgestellt werden sollen. Wie bereits erwähnt, wird die Kardinalität nur zur Erstbereitstellungszeit festgelegt. Eine neue Bereitstellung ist erforderlich, wenn die Kardinalitätseinstellungen geändert werden müssen.

Direktes Konfigurieren der Kardinalität

Um die Kardinalitätseinstellungen direkt zu konfigurieren, geben Sie die einzelnen Kardinalitätsfelder an.

Wenn Sie den folgenden Leitfaden zum Bereitstellen von IoT Einsatz befolgen, sehen Sie im Abschnitt Konfiguration unter MQTT-Brokerkonfiguration nach. Hier können Sie die Anzahl der Front-End-Replikate, Back-End-Partitionen und Back-End-Worker angeben.

Screenshot, der zeigt, wo die Brokerkardinalität direkt im Azure-Portal konfiguriert werden soll

Grundlegendes zur Kardinalität

Kardinalität steht für die Anzahl von Instanzen einer bestimmten Entität in einer Gruppe. Im Kontext des MQTT-Brokers bezieht sich die Kardinalität auf die Anzahl der Front-End-Replikate, Back-End-Partitionen und Back-End-Worker, die bereitgestellt werden sollen. Die Kardinalitätseinstellungen werden verwendet, um den Broker horizontal zu skalieren und Hochverfügbarkeit zu verbessern, wenn Pod- oder Knotenfehler auftreten.

Das Kardinalitätsfeld ist ein geschachteltes Feld mit Unterfeldern für Front-End- und Back-End-Kette. Jedes dieser Unterfelder verfügt über eigene Einstellungen.

Front-End

Im Front-End-Unterfeld legen Sie die Einstellungen für die Front-End-Pods fest. Die beiden Haupteinstellungen sind:

  • Replikate: Die Anzahl der bereitzustellenden Front-End-Replikate (Pods) Das Erhöhen der Anzahl der Front-End-Replikate bietet Hochverfügbarkeit, falls einer der Front-End-Pods ausfüllt.
  • Worker: Die Anzahl der logischen Front-End-Worker pro Replikat Jeder Worker kann höchstens bis zu einem CPU-Kern verbrauchen.

Back-End-Kette

Das Unterfeld der Back-End-Kette definiert die Einstellungen für die Back-End-Partitionen. Die drei Haupteinstellungen sind:

  • Partitionen: Die Anzahl der bereitzustellenden Partitionen. Durch einen Prozess namens Sharding ist jede Partition für einen Teil der Nachrichten verantwortlich, getrennt nach Themen-ID und Sitzungs-ID. Die Front-End-Pods verteilen den Nachrichtendatenverkehr auf die Partitionen. Durch das Erhöhen der Anzahl von Partitionen erhöht sich auch die Anzahl der Nachrichten, die der Broker verarbeiten kann.
  • Redundanzfaktor: Die Anzahl der Back-End-Replikate (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 bereitzustellenden Worker pro Back-End-Replikat Durch das Erhöhen der Anzahl der Worker pro Back-End-Replikat erhöht sich eventuell die Anzahl der Nachrichten, die der Back-End-Pod verarbeiten kann. Jeder Worker kann höchstens zwei CPU-Kerne nutzen. Achten Sie daher bei der Erhöhung der Anzahl der Worker pro Replikat darauf, dass die Anzahl der CPU-Kerne im Cluster nicht überschritten wird.

Überlegungen

Wenn Sie die Kardinalitätswerte erhöhen, verbessert sich im Allgemeinen die Fähigkeit des Brokers, mehr Verbindungen und Nachrichten zu verarbeiten, und es wird die Hochverfügbarkeit bei Pod- oder Knotenausfällen erhöht. Diese erhöhte Kapazität führt auch zu einem höheren Ressourcenverbrauch. Berücksichtigen Sie also beim Anpassen von Kardinalitätswerten die Speicherprofileinstellungen und die CPU-Ressourcenanforderungen des Brokers. Das Erhöhen der Anzahl der Worker pro Front-End-Replikat kann dazu beitragen, die Auslastung der CPU-Kerne zu erhöhen, wenn Sie feststellen, dass die Front-End-CPU-Auslastung einen Engpass darstellt. Das Erhöhen der Anzahl der Back-End-Worker kann den Nachrichtendurchsatz verbessern, wenn die Back-End-CPU ein Engpass ist.

Wenn Ihr Cluster beispielsweise drei Knoten mit acht CPU-Kernen aufweist, legen Sie die Anzahl der Front-End-Replikate so fest, dass sie mit der Anzahl der Knoten (3) übereinstimmt, und legen Sie die Anzahl der Worker auf 1 fest. Legen Sie die Anzahl der Back-End-Partitionen so fest, dass sie der Anzahl der Knoten (3) entspricht, und legen Sie Back-End-Worker auf 1 fest. Legen Sie den Redundanzfaktors nach Bedarf (2 oder 3) fest. Erhöhen Sie die Anzahl der Front-End-Worker, wenn Sie feststellen, dass die Nutzung der Front-End-CPU einen Engpass darstellt. Denken Sie daran, dass Back-End- und Front-End-Worker möglicherweise miteinander und mit anderen Pods um CPU-Ressourcen konkurrieren können.

Konfigurieren des Arbeitsspeicherprofils

Das Speicherprofil gibt die Speicherauslastung des Brokers für ressourcenbeschränkte Umgebungen an. Sie können aus vordefinierten Speicherprofilen wählen, die unterschiedliche Merkmale der Speicherauslastung aufweisen. Die Speicherprofileinstellung wird verwendet, um die Speicherauslastung der Frontend- und Back-End-Replikate zu konfigurieren. Das Speicherprofil interagiert mit den Kardinalitätseinstellungen, um die Gesamtspeicherauslastung des Brokers zu bestimmen.

Wichtig

Für diese Einstellung müssen Sie die Brokerressource ändern. Sie ist nur bei der ersten Bereitstellung mithilfe der Azure CLI oder des Azure-Portals konfiguriert. Eine neue Bereitstellung ist erforderlich, wenn Änderungen an der Broker-Konfiguration erforderlich sind. Weitere Informationen finden Sie unter Anpassen des Standardbrokers.

Um die Speicherprofileinstellungen für den MQTT-Broker zu konfigurieren, geben Sie die Speicherprofilfelder in der Spezifikation der Brokerressource während der Azure IoT Einsatz-Bereitstellung an.

Im folgenden Leitfaden zum Bereitstellen von Azure IoT Einsatz finden Sie im Abschnitt Konfiguration unter MQTT-Brokerkonfiguration die Einstellung für das Speicherprofil. Hier können Sie aus den verfügbaren Speicherprofilen in einer Dropdownliste auswählen.

Screenshot, der zeigt, wo das Speicherprofil im Azure-Portal konfiguriert werden kann

Es gibt vordefinierte Speicherprofile mit unterschiedlichen Speicherauslastungsmerkmalen für die Veröffentlichung von Nachrichten. Es gibt keine Beschränkung für die Anzahl der Sitzungen oder Abonnements, die der Broker verarbeiten kann. Das Speicherprofil steuert nur die Speicherauslastung für PUBLISH-Datenverkehr.

Sehr klein

Verwenden Sie dieses Profil, wenn Sie begrenzte Speicherressourcen haben und der Veröffentlichungsdatenverkehr des Clients niedrig ist.

Wenn Sie dieses Profil verwenden, gilt Folgendes:

  • Die maximale Speicherauslastung jedes Front-End-Replikats beträgt etwa 99 MiB, aber die tatsächliche maximale Speicherauslastung kann höher sein.
  • Die maximale Speicherauslastung jedes Back-End-Replikats beträgt etwa 102 MiB multipliziert mit der Anzahl der Back-End-Worker, aber die tatsächliche maximale Speicherauslastung kann höher sein.
  • Die maximale Nachrichtengröße beträgt 4 MB.
  • Die maximale Größe des eingehenden Puffers für PUBLISH-Daten beträgt ca. 16 MiB pro Back-End-Worker. Die effektive Größe kann jedoch aufgrund von Rückdruckmechanismen niedriger sein, die aktiviert werden, wenn der Puffer 75% Kapazität erreicht, was zu einer Puffergröße von ca. 12 MiB führt. Abgelehnte Pakete haben eine PUBACK-Antwort mit einem Kontingent überschrittenen Fehlercode.

Empfehlungen bei Verwendung dieses Profils:

  • Es sollte nur ein Front-End verwendet werden.
  • Clients sollten keine großen Pakete senden. Sie sollten nur Pakete senden, die kleiner als 4 MiB sind.

Niedrig

Verwenden Sie dieses Profil, wenn Sie über begrenzte Speicherressourcen verfügen und Clients kleine Pakete veröffentlichen.

Wenn Sie dieses Profil verwenden, gilt Folgendes:

  • Die maximale Speicherauslastung jedes Front-End-Replikats beträgt etwa 387 MiB, aber die tatsächliche maximale Speicherauslastung kann höher sein.
  • Die maximale Speicherauslastung jedes Back-End-Replikats beträgt etwa 390 MiB multipliziert mit der Anzahl der Back-End-Worker, aber die tatsächliche maximale Speicherauslastung kann höher sein.
  • Die maximale Nachrichtengröße beträgt 16 MB.
  • Die maximale Größe des eingehenden Puffers für PUBLISH-Daten beträgt ca. 64 MiB pro Back-End-Worker. Die effektive Größe kann jedoch aufgrund von Rückdruckmechanismen niedriger sein, die aktiviert werden, wenn der Puffer 75% Kapazität erreicht, was zu einer Puffergröße von ca. 48 MiB führt. Abgelehnte Pakete haben eine PUBACK-Antwort mit einem Kontingent überschrittenen Fehlercode.

Empfehlungen bei Verwendung dieses Profils:

  • Es sollten nur ein oder zwei Front-Ends verwendet werden.
  • Clients sollten keine großen Pakete senden. Sie sollten nur Pakete senden, die kleiner als 16 MiB sind.

Mittelstufe

Verwenden Sie dieses Profil, wenn Sie eine moderate Anzahl von Clientnachrichten behandeln müssen.

„Mittel“ ist das Standardprofil.

  • Die maximale Speicherauslastung jedes Front-End-Replikats beträgt etwa 1,9 GiB, aber die tatsächliche maximale Speicherauslastung kann höher sein.
  • Die maximale Speicherauslastung jedes Back-End-Replikats beträgt etwa 1,5 GiB multipliziert mit der Anzahl der Back-End-Worker, aber die tatsächliche maximale Speicherauslastung kann höher sein.
  • Die maximale Nachrichtengröße beträgt 64 MB.
  • Die maximale Größe des eingehenden Puffers für PUBLISH-Daten beträgt ca. 576 MiB pro Back-End-Worker. Die effektive Größe kann jedoch aufgrund von Rückdruckmechanismen niedriger sein, die aktiviert werden, wenn der Puffer 75% Kapazität erreicht, was zu einer Puffergröße von ca. 432 MiB führt. Abgelehnte Pakete haben eine PUBACK-Antwort mit einem Kontingent überschrittenen Fehlercode.

Hoch

Verwenden Sie dieses Profil, wenn Sie eine große Anzahl von Clientnachrichten behandeln müssen.

  • Die maximale Speicherauslastung jedes Front-End-Replikats beträgt etwa 4,9 GiB, aber die tatsächliche maximale Speicherauslastung kann höher sein.
  • Die maximale Speicherauslastung jedes Back-End-Replikats beträgt etwa 5,8 GiB multipliziert mit der Anzahl der Back-End-Worker, aber die tatsächliche maximale Speicherauslastung kann höher sein.
  • Die maximale Nachrichtengröße beträgt 256 MB.
  • Die maximale Größe des eingehenden Puffers für PUBLISH-Daten beträgt ca. 2 GiB pro Back-End-Worker. Die effektive Größe kann jedoch aufgrund von Rückdruckmechanismen niedriger sein, die aktiviert werden, wenn der Puffer 75% Kapazität erreicht, was zu einer Puffergröße von ca. 1,5 GiB führt. Abgelehnte Pakete haben eine PUBACK-Antwort mit einem Kontingent überschrittenen Fehlercode.

Berechnen der Gesamtspeicherauslastung

Die Speicherprofileinstellung gibt die Speicherauslastung für jedes Frontend- und Back-End-Replikat an und interagiert mit den Kardinalitätseinstellungen. Sie können die Gesamtspeicherauslastung mithilfe der Formel berechnen:

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

Ort:

Variable BESCHREIBUNG
M_total Gesamtspeicherauslastung
R_fe Die Anzahl der Frontend-Replikate
M_fe Die Speicherauslastung der einzelnen Frontend-Replikate
P_be Die Anzahl der Backend-Partitionen
RF_be Back-End-Redundanzfaktor
M_be Die Speicherauslastung der einzelnen Back-End-Replikate
W_be Die Anzahl der Arbeitskräfte pro Backend-Replikat

Wenn Sie z. B. das Profil für mittleren Arbeitsspeicher auswählen, hat das Profil eine Frontend-Speicherauslastung von 1,9 GB und eine Back-End-Speicherauslastung von 1,5 GB. Angenommen, die Brokerkonfiguration ist 2 Frontend-Replikate, 2 Back-End-Partitionen und ein Back-End-Redundanzfaktor von 2. Die Gesamtspeicherauslastung lautet:

2 * 1,9 GB + (2 * 2) * 1,5 GB * 2 = 15,8 GB

Im Vergleich dazu verfügt das Tiny-Speicherprofil über eine Frontend-Speicherauslastung von 99 MiB und Back-End-Speicherauslastung von 102 MiB. Wenn Sie die gleiche Brokerkonfiguration annehmen, lautet die Gesamtspeicherauslastung:

2 * 99 MB + (2 * 2) * 102 MB * 2 = 198 MB + 816 MB = 1,014 GB.

Wichtig

Der MQTT-Broker beginnt, Nachrichten abzulehnen, wenn der Speicher 75% voll ist.

Ressourcenbeschränkungen für Kardinalität und Kubernetes

Um Verhungern von Ressourcen im Cluster zu verhindern, wird der Broker standardmäßig so konfiguriert, dass Kubernetes CPU-Ressourcengrenzwerte angefordert werden. Durch die Skalierung der Anzahl von Replikaten oder Workern erhöht sich die Menge an erforderlichen CPU-Ressourcen proportional. Es wird ein Bereitstellungsfehler ausgegeben, wenn im Cluster nicht genügend CPU-Ressourcen verfügbar sind. Durch diese Benachrichtigung können Situationen vermieden werden, in denen die angeforderte Brokerkardinalität nicht über genügend Ressourcen für ein optimales Ausführungsverhalten verfügt. Es trägt auch zur Vermeidung potenzieller CPU-Konflikte und Pod-Räumungen bei.

Der MQTT-Broker fordert derzeit eine (1,0) CPU-Einheit pro Front-End-Worker und zwei (2,0) CPU-Einheiten pro Back-End-Worker an. Weitere Informationen finden Sie unter Kubernetes CPU-Ressourceneinheiten.

Die folgende Kardinalität würde beispielsweise die folgenden CPU-Ressourcen anfordern:

  • Für Front-Ends: 2 CPU-Einheiten pro Front-End-Pod, insgesamt 6 CPU-Einheiten
  • Für Back-Ends: 4 CPU-Einheiten pro Back-End-Pod (für zwei Back-End-Worker), multipliziert mit 2 (Redundanzfaktor), multipliziert mit 3 (Anzahl der Partitionen), insgesamt 24 CPU-Einheiten
{
  "cardinality": {
    "frontend": {
      "replicas": 3,
      "workers": 2
    },
    "backendChain": {
      "partitions": 3,
      "redundancyFactor": 2,
      "workers": 2
    }
  }
}

Um diese Einstellung zu deaktivieren, legen Sie das Feld generateResourceLimits.cpu in der Brokerressource auf Disabled fest.

Das Feld generateResourceLimits kann im Azure-Portal nicht geändert werden. Verwenden Sie die Azure CLI, um diese Einstellung zu deaktivieren.

Bereitstellung mit mehreren Knoten

Um Hochverfügbarkeit und Resilienz mit Bereitstellungen mit mehreren Knoten sicherzustellen, legt der MQTT-Broker von Azure IoT Einsatz automatisch Antiaffinitätsregeln für Back-End-Pods fest.

Diese Regeln sind vordefiniert und können nicht geändert werden.

Zweck von Antiaffinitätsregeln

Die Antiaffinitätsregeln stellen sicher, dass Back-End-Pods aus derselben Partition nicht auf demselben Knoten ausgeführt werden. Diese Funktion erleichtert das Verteilen der Last und bietet Resilienz bei Knotenfehlern. Insbesondere haben Back-End-Pods aus derselben Partition eine Antiaffinität zueinander.

Überprüfen von Antiaffinitätseinstellungen

Verwenden Sie den folgenden Befehl, um die Antiaffinitätseinstellungen für einen Back-End-Pod zu überprüfen:

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

Die Ausgabe zeigt die Antiaffinitätskonfiguration an, die dem folgenden Beispiel ähnelt:

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

Diese Regeln sind die einzigen Antiaffinitätsregeln, die für den Broker festgelegt werden.

Zugehöriger Inhalt