Brokerinstellingen configureren voor hoge beschikbaarheid, schaalaanpassing en geheugengebruik

De Broker-resource is de belangrijkste resource die de algemene instellingen voor een MQTT-broker definieert. Het bepaalt ook het aantal en het type pods waarop de Broker-configuratie wordt uitgevoerd, zoals de front-ends en de back-ends. U kunt de Broker-resource ook gebruiken om het geheugenprofiel te configureren. Zelfherstelmechanismen zijn ingebouwd in het systeem van de broker, waardoor deze vaak automatisch kan herstellen van onderdeelfouten. Een voorbeeld is als een knooppunt mislukt in een Kubernetes-cluster dat is geconfigureerd voor hoge beschikbaarheid.

U kunt de MQTT-broker horizontaal schalen door meer frontend-replica's en back-endpartities toe te voegen. De front-endreplica's zijn verantwoordelijk voor het accepteren van MQTT-verbindingen van clients en het doorsturen ervan naar de back-endpartities. De back-endpartities zijn verantwoordelijk voor het opslaan en leveren van berichten aan de clients. De frontend-pods verdelen het berichtverkeer over de backend-pods. De back-endredundantiefactor bepaalt het aantal gegevenskopieën om veerkracht tegen knooppuntfouten in het cluster te bieden.

Zie de broker-API-verwijzing voor een lijst met de beschikbare instellingen.

Schaalinstellingen configureren

Als u de schaalinstellingen van de MQTT-broker wilt configureren, geeft u de kardinaliteitsvelden op in de specificatie van de Broker-resource tijdens de implementatie van Azure IoT Operations.

Kardinaliteit van automatische implementatie

Als u automatisch de initiële kardinaliteit tijdens de implementatie wilt bepalen, laat u het kardinaliteitsveld in de Broker-resource weg.

{
  "memoryProfile": "<MEMORY_PROFILE>"
}

az iot ops create ... --broker-config-file <FILE>.json

De MQTT-brokeroperator implementeert automatisch het juiste aantal pods op basis van het aantal beschikbare knooppunten op het moment van de implementatie. Deze mogelijkheid is handig voor niet-productiescenario's waarbij u geen hoge beschikbaarheid of schaal nodig hebt.

Deze mogelijkheid is niet automatisch schalen. De operator schaalt niet automatisch het aantal pods op basis van de belasting. De operator bepaalt het initiële aantal pods dat moet worden geïmplementeerd, uitsluitend op basis van de clusterhardware. Zoals eerder vermeld, wordt kardinaliteit alleen ingesteld bij de eerste implementatie. Er is een nieuwe implementatie vereist als de kardinaliteitsinstellingen moeten worden gewijzigd.

Kardinaliteit rechtstreeks configureren

Als u de kardinaliteitsinstellingen rechtstreeks wilt configureren, geeft u elk van de kardinaliteitsvelden op.

az iot ops create ... --broker-frontend-replicas 1 --broker-frontend-workers 1  --broker-backend-part 1  --broker-backend-workers 1 --broker-backend-rf 2

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

az iot ops create ... --broker-config-file <FILE>.json

Inzicht in kardinaliteit

Kardinaliteit betekent het aantal exemplaren van een bepaalde entiteit in een set. In de context van de MQTT-broker verwijst cardinaliteit naar het aantal frontend-replica's, backend-partities en backend-medewerkers dat moet worden ingezet. De cardinaliteitsinstellingen worden gebruikt om de broker horizontaal te schalen en de hoge beschikbaarheid te verbeteren als er pod- of nodefouten zijn.

Het kardinaliteitsveld is een genest veld, met subvelden voor de frontend en de backend-keten. Elk van deze subvelden heeft zijn eigen instellingen.

Voorkant

Het subveld frontend definieert de instellingen voor de frontendpods. De twee belangrijkste instellingen zijn:

• Replica's: het aantal front-endreplica's (pods) dat moet worden geïmplementeerd. Het vergroten van het aantal frontend-replica's zorgt voor hoge beschikbaarheid in het geval dat een van de frontend-pods uitvalt.
• Bewerkers: het aantal logische frontend-bewerkers per replica. Elke werknemer kan maximaal één CPU-kern verbruiken.

Back-end keten

Het subveld backend-keten definieert de instellingen voor de backend-partities. De drie belangrijkste instellingen zijn:

• Partities: het aantal partities dat moet worden geïmplementeerd. Via een proces met de naam sharding is elke partitie verantwoordelijk voor een deel van de berichten, gedeeld door onderwerp-id en sessie-id. De frontendpods verdelen het berichtverkeer over de partities. Door het aantal partities te verhogen, wordt het aantal berichten dat de broker kan verwerken, verhoogd.
• Redundantiefactor: het aantal achterendreplica's (pods) dat per partitie moet worden uitgerold. Het verhogen van de redundantiefactor verhoogt het aantal gegevenskopieën om tolerantie te bieden tegen knooppuntfouten in het cluster.
• Werknemers: Het aantal werknemers dat per back-endreplica moet worden geïnstantieerd. Het verhogen van het aantal werknemers per backend-replica kan het aantal berichten dat door de backend-pod kan worden verwerkt, doen toenemen. Elke werkrol kan maximaal twee CPU-kernen verbruiken, dus wees voorzichtig wanneer u het aantal werkrollen per replica verhoogt om het aantal CPU-kernen in het cluster niet te overschrijden.

Overwegingen

Wanneer u de kardinaliteitswaarden verhoogt, wordt de capaciteit van de broker voor het afhandelen van meer verbindingen en berichten over het algemeen verbeterd en wordt de hoge beschikbaarheid verbeterd als er pod- of knooppuntfouten optreden. Deze verhoogde capaciteit leidt ook tot een hoger resourceverbruik. Wanneer u kardinaliteitswaarden aanpast, moet u rekening houden met de instellingen van het geheugenprofiel en de CPU-resourceaanvragen van de broker. Het verhogen van het aantal werkrollen per front-endreplica kan helpen het CPU-kerngebruik te verhogen als u ontdekt dat het CPU-gebruik van front-end een knelpunt is. Het verhogen van het aantal back-endmedewerkers kan helpen bij de doorvoer van berichten als het CPU-gebruik van de back-end een knelpunt is.

Als uw cluster bijvoorbeeld drie knooppunten heeft, elk met acht CPU-kernen, stelt u het aantal frontend-replica's in op het aantal knooppunten (3) en stelt u het aantal werknemers in op 1. Stel het aantal back-endpartities in dat overeenkomt met het aantal knooppunten (3) en stel de back-endwerkers in op 1. Stel de redundantiefactor naar wens in (2 of 3). Verhoog het aantal front-endwerkers als u ontdekt dat het CPU-gebruik van de front-end een knelpunt is. Houd er rekening mee dat back-end- en front-endmedewerkers kunnen concurreren voor CPU-resources met elkaar en andere pods.

Geheugenprofiel configureren

Het geheugenprofiel geeft het geheugengebruik van de broker op voor omgevingen met beperkte resources. U kunt kiezen uit vooraf gedefinieerde geheugenprofielen met verschillende kenmerken voor geheugengebruik. De instelling voor het geheugenprofiel wordt gebruikt om het geheugengebruik van de front-end- en back-endreplica's te configureren. Het geheugenprofiel communiceert met de kardinaliteitsinstellingen om het totale geheugengebruik van de broker te bepalen.

Als u de geheugenprofielinstellingen van de MQTT-broker wilt configureren, geeft u de geheugenprofielvelden op in de specificatie van de Broker-resource tijdens de implementatie van IoT Operations.

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

Er zijn vooraf gedefinieerde geheugenprofielen met verschillende kenmerken van geheugengebruik voor het publiceren van berichten. Er is geen limiet voor het aantal sessies of abonnementen dat de broker kan verwerken. Het geheugenprofiel bepaalt alleen het geheugengebruik voor PUBLISH-verkeer.

Piepklein

Gebruik dit profiel wanneer u beperkte geheugenmiddelen heeft en het aantal publicaties door clients laag is.

Wanneer u dit profiel gebruikt:

• Het maximale geheugengebruik van elke front-endreplica is ongeveer 99 MiB, maar het werkelijke maximale geheugengebruik kan hoger zijn.
• Het maximale geheugengebruik van elke back-endreplica is ongeveer 102 MiB vermenigvuldigd met het aantal back-endmedewerkers, maar het werkelijke maximale geheugengebruik kan hoger zijn.
• De maximale berichtgrootte is 4 MB.
• De maximale grootte van de binnenkomende buffer voor PUBLISH-gegevens is ongeveer 16 MiB per back-end worker. De effectieve grootte kan echter lager zijn vanwege backpressuremechanismen, die activeren wanneer de buffer 75% capaciteit bereikt, wat resulteert in een buffergrootte van ongeveer 12 MiB. Geweigerde pakketten hebben een PUBACK-antwoord met een Quotum overschreden foutcode.

Aanbevelingen wanneer u dit profiel gebruikt:

• Er mag slechts één front-end worden gebruikt.
• Clients mogen geen grote pakketten verzenden. U moet alleen pakketten verzenden die kleiner zijn dan 4 MiB.

Laag

Gebruik dit profiel wanneer u beperkte geheugenbronnen hebt en clients kleine pakketten publiceren.

Wanneer u dit profiel gebruikt:

• Het maximale geheugengebruik van elke front-endreplica is ongeveer 387 MiB, maar het werkelijke maximale geheugengebruik kan hoger zijn.
• Het maximale geheugengebruik van elke back-endreplica is ongeveer 390 MiB vermenigvuldigd met het aantal back-endmedewerkers, maar het werkelijke maximale geheugengebruik kan hoger zijn.
• De maximale berichtgrootte is 16 MB.
• De maximale grootte van de binnenkomende buffer voor PUBLISH-gegevens is ongeveer 64 MiB per back-end worker. De effectieve grootte kan echter lager zijn vanwege backpressuremechanismen, die activeren wanneer de buffer 75% capaciteit bereikt, wat resulteert in een buffergrootte van ongeveer 48 MiB. Geweigerde pakketten hebben een PUBACK-antwoord met een Quotum overschreden foutcode.

Aanbevelingen wanneer u dit profiel gebruikt:

• Er moeten slechts één of twee front-ends worden gebruikt.
• Clients mogen geen grote pakketten verzenden. U moet alleen pakketten verzenden die kleiner zijn dan 16 MiB.

Gemiddeld

Gebruik dit profiel wanneer u een gemiddeld aantal clientberichten moet verwerken.

Gemiddeld is het standaardprofiel.

• Het maximale geheugengebruik van elke front-endreplica is ongeveer 1,9 GiB, maar het werkelijke maximale geheugengebruik kan hoger zijn.
• Het maximale geheugengebruik van elke back-endreplica is ongeveer 1,5 GiB vermenigvuldigd met het aantal back-endmedewerkers, maar het werkelijke maximale geheugengebruik kan hoger zijn.
• De maximale berichtgrootte is 64 MB.
• De maximale grootte van de binnenkomende buffer voor PUBLISH-gegevens is ongeveer 576 MiB per back-end worker. De effectieve grootte kan echter lager zijn vanwege backpressuremechanismen, die activeren wanneer de buffer 75% capaciteit bereikt, wat resulteert in een buffergrootte van ongeveer 432 MiB. Geweigerde pakketten hebben een PUBACK-antwoord met een Quotum overschreden foutcode.

Hoog

Gebruik dit profiel wanneer u een groot aantal clientberichten moet verwerken.

• Het maximale geheugengebruik van elke front-endreplica is ongeveer 4,9 GiB, maar het werkelijke maximale geheugengebruik kan hoger zijn.
• Het maximale geheugengebruik van elke back-endreplica is ongeveer 5,8 GiB vermenigvuldigd met het aantal back-endmedewerkers, maar het werkelijke maximale geheugengebruik kan hoger zijn.
• De maximale berichtgrootte is 256 MB.
• De maximale grootte van de binnenkomende buffer voor PUBLISH-gegevens is ongeveer 2 GiB per back-end worker. De effectieve grootte kan echter lager zijn vanwege backpressuremechanismen, die activeren wanneer de buffer 75% capaciteit bereikt, wat resulteert in een buffergrootte van ongeveer 1,5 GiB. Geweigerde pakketten hebben een PUBACK-antwoord met een Quotum overschreden foutcode.

Het totale geheugengebruik berekenen

De instelling voor het geheugenprofiel geeft het geheugengebruik op voor elke front-end- en back-endreplica en communiceert met de kardinaliteitsinstellingen. U kunt het totale geheugengebruik berekenen met behulp van de formule:

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

Waar:

Als u bijvoorbeeld het Gemiddeld-geheugenprofiel kiest, heeft het profiel een front-endgeheugengebruik van 1,9 GB en back-endgeheugengebruik van 1,5 GB. Stel dat de brokerconfiguratie bestaat uit 2 frontend-replica's, 2 backend-partities en een backend-redundantiefactor van 2. Het totale geheugengebruik is:

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

Ter vergelijking: het Tiny-geheugenprofiel heeft een front-endgeheugengebruik van 99 MiB en back-endgeheugengebruik van 102 MiB. Als u van dezelfde brokerconfiguratie uitgaat, is het totale geheugengebruik:

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

Kardinaliteit en Kubernetes-resourcelimieten

Om uitputting van resources in het cluster te voorkomen, wordt de broker standaard geconfigureerd om Kubernetes CPU-resourcelimieten aan te geven. Door het aantal replica's of werkrollen proportioneel te schalen, worden de vereiste CPU-resources verhoogd. Er wordt een implementatiefout gegenereerd als er onvoldoende CPU-resources beschikbaar zijn in het cluster. Deze melding helpt u situaties te voorkomen waarin het aangevraagde broker-aantal onvoldoende middelen heeft om optimaal te functioneren. Het helpt ook om mogelijke CPU-conflicten en podverzettingen te voorkomen.

De MQTT-broker vraagt momenteel één (1.0) CPU-eenheid per front-end worker aan en twee (2.0) CPU-eenheden per back-end worker. Zie Kubernetes CPU-resource-eenheden voor meer informatie.

De volgende kardinaliteit vraagt bijvoorbeeld de volgende CPU-resources aan:

• Voor front-ends: 2 CPU-eenheden per front-end pod, in totaal 6 CPU-eenheden.
• Voor back-ends: 4 CPU-eenheden per back-endpod (voor twee back-endwerkers), keer 2 (redundantiefactor), keer 3 (aantal partities), in totaal 24 CPU-eenheden.

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

Als u deze instelling wilt uitschakelen, stelt u het generateResourceLimits.cpu veld Disabled in op de Broker-resource.

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

az iot ops create ... --broker-config-file <FILE>.json

Implementatie met meerdere knooppunten

Om hoge beschikbaarheid en tolerantie met implementaties met meerdere knooppunten te garanderen, stelt de IoT Operations MQTT-broker automatisch antiaffiniteitsregels in voor back-endpods.

Deze regels zijn vooraf gedefinieerd en kunnen niet worden gewijzigd.

Doel van antiaffiniteitsregels

De antiaffiniteitsregels zorgen ervoor dat backend-pods van dezelfde partitie niet op hetzelfde knooppunt worden gebruikt. Deze mogelijkheid helpt bij het distribueren van de belasting en biedt tolerantie tegen knooppuntfouten. Backend-pods van dezelfde partitie hebben antiaffiniteit met elkaar.

Instellingen voor antiaffiniteit controleren

Gebruik de volgende opdracht om de antiaffiniteitsinstellingen voor een backendpod te controleren:

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

De uitvoer toont de configuratie van antiaffiniteit, vergelijkbaar met het volgende voorbeeld:

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

Deze regels zijn de enige antiaffiniteitsregels die zijn ingesteld voor de broker.

Gerelateerde inhoud

• Listeners configureren voor de MQTT-broker