Konfigurera brokerinställningar för hög tillgänglighet, skalning och minnesanvändning

Broker-resursen är den viktigaste resursen som definierar de övergripande inställningarna för en MQTT-koordinator. Den avgör också antalet och typen av poddar som kör Broker-konfigurationen, till exempel klientdelarna och serverdelarna. Du kan också använda Broker-resursen för att konfigurera dess minnesprofil. Självläkande mekanismer är inbyggda i mäklaren, och den kan ofta automatiskt återhämta sig från komponentfel. Ett exempel är om en nod misslyckas i ett Kubernetes-kluster som har konfigurerats för hög tillgänglighet.

Du kan skala MQTT-koordinatorn vågrätt genom att lägga till fler klientdelsrepliker och serverdelspartitioner. Frontend-replikerna ansvarar för att acceptera MQTT-anslutningar från klienter och vidarebefordra dem till backend-partitionerna. Serverdelspartitionerna ansvarar för att lagra och leverera meddelanden till klienterna. Frontend-poddarna distribuerar meddelandetrafiken över backend-poddarna. Backend-redundansfaktorn avgör antalet datakopior för att ge återhämtning mot nodfel i klustret.

En lista över tillgängliga inställningar finns i referensen för Broker API.

Konfigurera skalningsinställningar

Om du vill konfigurera skalningsinställningarna för MQTT-koordinatorn anger du kardinalitetsfälten i specifikationen för Broker-resursen under Azure IoT Operations-distributionen.

Kardinalitet för automatisk distribution

Om du vill fastställa den inledande kardinaliteten automatiskt under distributionen utelämnar du kardinalitetsfältet i Broker-resursen.

{
  "memoryProfile": "<MEMORY_PROFILE>"
}

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

MQTT-koordinatoroperatorn distribuerar automatiskt lämpligt antal poddar baserat på antalet tillgängliga noder vid tidpunkten för distributionen. Den här funktionen är användbar för icke-produktionsscenarier där du inte behöver hög tillgänglighet eller skalning.

Den här funktionaliteten är inte automatiskt skalande. Operatorn skalar inte automatiskt antalet poddar baserat på belastningen. Operatorn avgör det ursprungliga antalet poddar som endast ska distribueras baserat på klustermaskinvaran. Som tidigare nämnts anges kardinaliteten endast vid den första implementeringstiden. En ny distribution krävs om kardinalitetsinställningarna behöver ändras.

Konfigurera kardinalitet direkt

Om du vill konfigurera kardinalitetsinställningarna direkt anger du vart och ett av kardinalitetsfälten.

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

Förstå kardinalitet

Kardinalitet innebär antalet instanser av en viss entitet i en uppsättning. I samband med MQTT-mäklaren refererar kardinaliteten till antalet frontend-repliker, backend-partitioner och backend-arbetare som ska distribueras. Kardinalitetsinställningarna används för att skala mäklaren vågrätt för att förbättra den höga tillgängligheten om det finns podd- eller nodfel.

Kardinalitetsfältet är ett kapslat fält med underfält för klientdelen och serverdelskedjan. Vart och ett av dessa underfält har sina egna inställningar.

frontend

Användargränssnittsunderfältet definierar inställningarna för frontend-pods. De två huvudinställningarna är:

• Repliker: Antalet frontend-repliker (poddar) som ska distribueras. Genom att öka antalet frontend-repliker säkerställer du hög tillgänglighet om någon av frontend-poddarna misslyckas.
• Logiska frontend-arbetare: Antalet logiska frontend-arbetare per replik. Varje arbetare kan använda upp till en processorkärna som mest.

Serverdelskedja

Serverdelskedjans underfält definierar inställningarna för serverdelspartitionerna. De tre huvudinställningarna är:

• Partitioner: Antalet partitioner som ska distribueras. Genom en process som kallas horisontell partitionering ansvarar varje partition för en del av meddelandena, dividerat med ämnes-ID och sessions-ID. Frontend-poddarna distribuerar meddelandetrafik över partitionerna. Genom att öka antalet partitioner ökar antalet meddelanden som brokern kan hantera.
• Redundansfaktor: Antalet serverdelsrepliker (poddar) som ska distribueras per partition. Genom att öka redundansfaktorn ökar antalet datakopior, vilket ger motståndskraft mot nodfel i klustret.
• Arbetare: Antalet arbetare som ska användas per backendkopiering. Om du ökar antalet arbetare per serverdelsreplik kan du öka antalet meddelanden som serverdelspodden kan hantera. Varje arbetare kan förbruka högst två CPU-kärnor, så var försiktig när du ökar antalet arbetare per replik till att inte överskrida antalet CPU-kärnor i klustret.

Att tänka på

När du ökar kardinalitetsvärdena förbättras brokerns kapacitet att hantera fler anslutningar och meddelanden i allmänhet, och det förbättrar hög tillgänglighet om det finns podd- eller nodfel. Den ökade kapaciteten leder också till högre resursförbrukning. När du justerar kardinalitetsvärdena bör du därför tänka på minnesprofilinställningarna och koordinatorns CPU-resursbegäranden. Om du ökar antalet arbetare per front-end-replik kan du öka användningen av processorkärnor om du upptäcker att processoranvändningen i front-end är en flaskhals. Att öka antalet backend-arbetare kan hjälpa med meddelandegenomströmningen om CPU-användningen är en flaskhals.

Om klustret till exempel har tre noder, var och en med åtta CPU-kärnor, anger du sedan antalet klientdelsrepliker så att det matchar antalet noder (3) och anger antalet arbetare till 1. Ange antalet serverdelspartitioner så att de matchar antalet noder (3) och ange serverdelsarbetarna till 1. Ange redundansfaktorn som önskat (2 eller 3). Öka antalet klientdelsarbetare om du upptäcker att processoranvändningen i klientdelen är en flaskhals. Kom ihåg att backend- och frontend-arbetare kan konkurrera om CPU-resurser med varandra och andra poddar.

Konfigurera minnesprofil

Minnesprofilen anger brokerns minnesanvändning för resursbegränsade miljöer. Du kan välja mellan fördefinierade minnesprofiler som har olika egenskaper för minnesanvändning. Inställningen för minnesprofil används för att konfigurera minnesanvändningen för klientdels- och serverdelsreplikerna. Minnesprofilen interagerar med kardinalitetsinställningarna för att fastställa den totala minnesanvändningen för mäklaren.

Om du vill konfigurera minnesprofilinställningarna för MQTT-koordinatorn anger du fälten för minnesprofilen i specifikationen för Broker-resursen under IoT Operations-distributionen.

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

Det finns fördefinierade minnesprofiler med olika minnesanvändningsegenskaper för publicering av meddelanden. Det finns ingen gräns för hur många sessioner eller prenumerationer som mäklaren kan hantera. Minnesprofilen styr endast minnesanvändningen för PUBLISH-trafik.

Pytteliten

Använd den här profilen när du har begränsade minnesresurser och klientens publiceringstrafik är låg.

När du använder den här profilen:

• Maximal minnesanvändning för varje klientdelsreplik är cirka 99 MiB, men den faktiska maximala minnesanvändningen kan vara högre.
• Maximal minnesanvändning för varje serverdelsreplik är cirka 102 MiB multiplicerat med antalet serverdelsarbetare, men den faktiska maximala minnesanvändningen kan vara högre.
• Maximal meddelandestorlek är 4 MB.
• Den maximala storleken på den inkommande bufferten för PUBLISH-data är cirka 16 MiB per backend-arbetare. Den effektiva storleken kan dock vara lägre på grund av ryggtrycksmekanismer, som aktiveras när bufferten når 75% kapacitet, vilket resulterar i en buffertstorlek på cirka 12 MiB. Avvisade paket har ett PUBACK-svar med felkoden Kvot överskreds .

Rekommendationer när du använder den här profilen:

• Endast en frontend ska användas.
• Klienter bör inte skicka stora paket. Du bör bara skicka paket som är mindre än 4 MiB.

Låg

Använd den här profilen när du har begränsade minnesresurser och klienter publicerar små paket.

När du använder den här profilen:

• Maximal minnesanvändning för varje klientdelsreplik är cirka 387 MiB, men den faktiska maximala minnesanvändningen kan vara högre.
• Maximal minnesanvändning för varje serverdelsreplik är cirka 390 MiB multiplicerat med antalet serverdelsarbetare, men den faktiska maximala minnesanvändningen kan vara högre.
• Maximal meddelandestorlek är 16 MB.
• Den maximala storleken på PUBLISH-datas inkommande buffert är cirka 64 MiB per backend-arbetare. Den effektiva storleken kan dock vara lägre på grund av ryggtrycksmekanismer, som aktiveras när bufferten når 75% kapacitet, vilket resulterar i en buffertstorlek på cirka 48 MiB. Avvisade paket har ett PUBACK-svar med felkoden Kvot överskreds .

Rekommendationer när du använder den här profilen:

• Endast en eller två användargränssnitt ska användas.
• Klienter bör inte skicka stora paket. Du bör bara skicka paket som är mindre än 16 MiB.

Medel

Använd den här profilen när du behöver hantera ett måttligt antal klientmeddelanden.

Medium är standardprofilen.

• Maximal minnesanvändning för varje klientdelsreplik är cirka 1,9 GiB, men den faktiska maximala minnesanvändningen kan vara högre.
• Maximal minnesanvändning för varje serverdelsreplik är cirka 1,5 GiB multiplicerat med antalet serverdelsarbetare, men den faktiska maximala minnesanvändningen kan vara högre.
• Maximal meddelandestorlek är 64 MB.
• Den maximala storleken för den inkommande bufferten för PUBLISH-data är cirka 576 MiB per backend-arbetare. Den effektiva storleken kan dock vara lägre på grund av ryggtrycksmekanismer, som aktiveras när bufferten når 75% kapacitet, vilket resulterar i en buffertstorlek på cirka 432 MiB. Avvisade paket har ett PUBACK-svar med felkoden Kvot överskreds .

Högt

Använd den här profilen när du behöver hantera ett stort antal klientmeddelanden.

• Maximal minnesanvändning för varje klientdelsreplik är cirka 4,9 GiB, men den faktiska maximala minnesanvändningen kan vara högre.
• Maximal minnesanvändning för varje serverdelsreplik är cirka 5,8 GiB multiplicerat med antalet serverdelsarbetare, men den faktiska maximala minnesanvändningen kan vara högre.
• Maximal meddelandestorlek är 256 MB.
• Den maximala storleken på den inkommande bufferten för PUBLISH-data är cirka 2 GiB per backend-arbetare. Den effektiva storleken kan dock vara lägre på grund av ryggtrycksmekanismer, som aktiveras när bufferten når 75% kapacitet, vilket resulterar i en buffertstorlek på cirka 1,5 GiB. Avvisade paket har ett PUBACK-svar med felkoden Kvot överskreds .

Beräkna total minnesanvändning

Inställningen för minnesprofil anger minnesanvändningen för varje klientdel och serverdelsreplik och interagerar med kardinalitetsinställningarna. Du kan beräkna den totala minnesanvändningen med hjälp av formeln:

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

Var:

Om du till exempel väljer medelminnesprofilen, har profilen en minnesanvändning för klientdelen på 1,9 GB och för serverdelen på 1,5 GB. Anta att mäklarkonfigurationen är 2 frontend-repliker, 2 backend-partitioner och en redundansfaktor för backend på 2. Den totala minnesanvändningen är:

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

Som jämförelse har Tiny-minnesprofilen en minnesanvändning på klientdelen på 99 MiB och serverdelsminnesanvändning på 102 MiB. Om du antar samma mäklarkonfiguration är den totala minnesanvändningen:

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

Resursgränser för kardinalitet och Kubernetes

För att förhindra resurssvält i klustret konfigureras koordinatorn som standard för att begära Kubernetes CPU-resursgränser. Genom att skala antalet repliker eller arbetare proportionellt ökar processorresurserna som krävs. Ett distributionsfel genereras om det inte finns tillräckligt med processorresurser i klustret. Det här meddelandet hjälper dig att undvika situationer där den begärda mäklaren saknar tillräckliga resurser för att fungera optimalt. Det hjälper också till att undvika potentiella CPU-resurskonflikter och avhysning av poddar.

MQTT-brokern begär för närvarande en (1,0) CPU-enhet per frontend-arbetare och två (2,0) CPU-enheter per backend-arbetare. Mer information finns i Kubernetes CPU-resursenheter.

Följande kardinalitet skulle till exempel begära följande CPU-resurser:

• För klientdelar: 2 CPU-enheter per klientdelspodd, totalt 6 CPU-enheter.
• För serverdelar: 4 CPU-enheter per serverdelspodd (för två serverdelsarbetare), gånger 2 (redundansfaktor), gånger 3 (antal partitioner), totalt 24 CPU-enheter.

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

Om du vill inaktivera den här inställningen anger du fältet generateResourceLimits.cpu till Disabled i broker-resursen.

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

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

Distribution med flera noder

För att säkerställa hög tillgänglighet och motståndskraft med distributioner med flera noder anger anti-affinitetsregler för serverdelspoddar i IoT-operations MQTT-mäklare.

Dessa regler är fördefinierade och kan inte ändras.

Syftet med anti-affinitetsregler

Anti-affinitetsreglerna ser till att backendpoddar från samma partition inte placeras på samma nod. Den här funktionen hjälper till att distribuera belastningen och ger motståndskraft mot nodfel. Mer specifikt har serverdelspoddar från samma partition antitillhörighet med varandra.

Verifiera anti-affinitetsinställningar

Använd följande kommando för att verifiera inställningarna för antitillhörighet för en back-end-podden:

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

Utdata visar anti-affinitetskonfigurationen, ungefär som i följande exempel:

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

Dessa regler är de enda anti-affinitetsregler som angetts för mäklaren.

Relaterat innehåll

• Konfigurera lyssnare för MQTT-koordinatorn