Distributionsplanering för Azure IoT Operations

Många Azure IoT Operations inställningar är fasta vid distributionen och kan bara ändras genom omdistribution. Innan du driftsätter ska du planera klustertopologin, antalet mäklare, minnesprofilen och de valfria mäklarinställningar du behöver. Den här artikeln sammanfattar de beslut du bör fatta.

Förstå arkitekturen

Azure IoT Operations är en uppsättning modulära Kubernetes-interna tjänster som distribueras till ett Azure Arc-aktiverat kluster. Viktiga komponenter är:

Två termer används i hela dokumentationen:

• Distribution – instansen, Arc-tillägg, anpassade platser och alla konfigurerbara resurser (tillgångar, enheter, dataflöden).
• Instans – den överordnade resurs som paketar tjänsterna.

Välj din klustertopologi

Innan du distribuerar ska du bestämma om du behöver ett kluster med en nod eller flera noder. Det här beslutet avgör maskinvarukraven och brokerns kardinalitetsinställningar.

Förstå brokerkardinalitet

Kardinalitet är antalet frontend-repliker, frontend-worker-noder, backend-partitioner och backend-worker-noder i driftsättningen av brokern. Kardinalitet styr hur mäklaren skalar horisontellt och hur motståndskraftig den är mot podd- eller nodfel.

MQTT-koordinatorn har en arkitektur på två nivåer: klientdelspoddar hanterar klientanslutningar och protokollbearbetning, medan serverdelspoddar hanterar lagring och leverans av meddelanden. Att förstå hur varje nivå skalar är viktigt för kapacitetsplanering.

Frontend

Klientdelspoddar accepterar MQTT-klientanslutningar och vidarebefordrar meddelanden till serverdelen. Frontend-poddar lagrar inte meddelanden själva. Det finns två huvudinställningar för frontendskiktet:

• Replikor: Antalet frontend-poddar som ska distribueras. Om du lägger till fler repliker av frontend ökar antalet samtidiga klientanslutningar som mäklaren kan hantera och ger hög tillgänglighet om en av frontend-poddarna slutar fungera.
• Arbetare: Antalet logiska arbetare per klientdelspodd. Genom att lägga till fler arbetare kan klientdelspodden använda fler CPU-kärnor. Varje arbetare kan använda upp till en processorkärna.

Serverdelskedja

Backend-poddar hanterar lagring och leverans av meddelanden. Det finns tre huvudinställningar för backendnivån:

• Partitioner: Antalet partitioner som ska distribueras. Partitioner är den vågräta skalningsenheten för meddelandedataflöde. Genom en process som kallas horisontell partitionering hanterar varje partition en del av meddelandena, fragmenterade efter ämne och session. Frontend-poddarna distribuerar meddelandetrafik över partitionerna. Att lägga till fler partitioner ökar den totala meddelandegenomströmning som meddelandeförmedlaren kan hantera.
• Redundansfaktor: Antalet backend-poddar som ska distribueras per partition. Genom att öka redundansfaktorn ökar antalet datakopior, vilket ger motståndskraft mot nodfel i klustret.
• Arbetare: Antalet arbetare per serverdelspodd. Worker-processer är enheten för vertikal skalning inom en partition – om man lägger till fler worker-processer kan backend-podden använda fler processorkärnor på samma nod. Varje arbetare kan använda upp till 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.

Uppskattning av dataflöde

Prestandan för en enskild partition beror mycket på cpu-egenskaperna för den nod som den körs på. Som tumregel kan du förvänta dig ungefär 5 000 till 6 000 QoS 1-meddelanden per sekund per partition med 8 KB nyttolaster på en 2-GHz CPU (~4 GHz turbo). Verkliga prestanda beror på många faktorer, så använd bara det här talet som utgångspunkt för kapacitetsplanering.

Detaljerade prestandadata finns i Prestandamätning för MQTT Broker.

Rekommendationer för en nod

• Frontendrepliker: Ställ in på 1.
• Klientarbetare: Ange hälften av antalet CPU-kärnor per nod.
• Backend-repliker (redundansfaktor): Ange minst 2 så att brokern kan utföra rullande uppdateringar.

Exempel: enskild nod, 4 CPU-kärnor

Rekommendationer för flera noder

Följande värden rekommenderas för optimal prestanda. För stora kluster med låg trafik kan dessa värden anges lägre än rekommendationerna utan att orsaka problem. Fler överväganden som minne (RAM) och prestandaegenskaper beskrivs i följande avsnitt. Testa alltid konfigurationen med den förväntade arbetsbelastningen för att bekräfta prestanda.

• Frontendrepliker: Ange samma värde som antalet noder i klustret.
• Klientarbetare: Ange hälften av antalet CPU-kärnor per nod.
• Backend-repliker (redundansfaktor): Ange till 2 för redundans och löpande uppdateringsstöd.
• Serverdelspartitioner: Ställ in lika med antalet noder i klustret.
• Backend-arbetare: Ange hälften av antalet CPU-kärnor per nod.

Exempel: 3-nodskluster, 8 CPU-kärnor per nod

Exempel: 5-nodskluster, 16 CPU-kärnor per nod

Gränser för CPU-resurser

För att förhindra resurssvält i klustret kan koordinatorn konfigureras för att begära Kubernetes CPU-resursgränser baserat på kardinalitetsinställningarna. När det här är aktiverat ökar proportionell skalning av antalet repliker eller arbetare de processorresurser som krävs.

Standardvärdet för REST API, Bicep och ARM-mallar definieras i API-specifikationen Broker.

MQTT-koordinatorn begär CPU-resurser per podd baserat på antalet konfigurerade arbetare:

• Klientdelspoddar: 1,0 CPU per arbetare
• Serverdelspoddar: 2,0 CPU per arbetare

Använd följande formler för att beräkna de totala CPU-kraven:

Exempel: litet kluster

Överväg ett 2-nodskluster med 4 CPU-kärnor per nod (totalt 8 kärnor) med följande kardinalitet:

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

Mäklaren begär:

• Klientdels-CPU: 2 repliker × 2 arbetare × 1,0 = 4,0 CPU
• Bakgrunds-CPU: 1 partition x 2 RF x 1 worker x 2,0 = 4,0 CPU
• Total CPU för broker: 8.0 CPU

Den här konfigurationen begär 8,0 CPU på ett kluster med endast 8 kärnor, vilket inte lämnar något för andra Azure IoT Operations komponenter (200–300 m) eller för Kubernetes-systempoddar. Broker-poddarna förblir i tillståndet Pending med felen Insufficient cpu.

Lös problemet genom att antingen lägga till fler noder, öka kärnor per nod eller minska mäklarkardinaliteten.

Exempel: större distribution

Följande kardinalitetsförfrågningar kräver betydligt mer CPU-resurser:

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

• Frontend-CPU: 3 repliker × 2 processer × 1,0 = 6,0 CPU
• Serverdels-CPU: 3 partitioner × 2 RF-× 2 arbetare × 2,0 = 24,0 CPU
• Total broker-CPU: 30,0 CPU

Ett kluster behöver minst 30 processorkärnor tillgängliga enbart för koordinatorpoddar, plus utrymme för andra Azure IoT Operations komponenter och Kubernetes-systempoddar.

Konfiguration av cpu-resursgräns

Cpu-resursgränser styrs av fältet generateResourceLimits.cpu i broker-resursen. Den här konfigurationen stöds endast med hjälp av flaggan --broker-config-file när du distribuerar Azure IoT Operations med hjälp av kommandot az iot ops create. Mer information finns i Azure CLI-stöd för avancerad MQTT-koordinatorkonfiguration.

Förbered en Broker-konfigurationsfil genom att följa API-referensen GenerateResourceLimits . Följande exempel visar de två möjliga värdena:

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

Eller

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

Välj din minnesprofil

Minnesprofilen styr den maximala storleken på MQTT-meddelanden som brokern accepterar, minnesanvändning vid inaktivitet och maximal minnesanvändning för varje pod. Bestäm rätt minnesprofil före distribution baserat på dina förväntade meddelandestorlekar och dataflöde.

Inkommande buffert och ryggtryck

Varje minnesprofil definierar en maximal inkommande buffertstorlek för PUBLISH-data per backend worker. När bufferten når 75 % av sin kapacitet aktiverar mäklaren backpressure-mekanismer och börjar avvisa inkommande meddelanden. Avvisade paket får ett PUBACK-svar med felkoden Kvoten har överskridits.

I följande tabell visas de inkommande buffertstorlekarna per arbetare för varje profil:

När du väljer en minnesprofil bör du tänka på:

• Tiny: Endast en frontend bör användas. Skicka endast paket som är mindre än 4 MiB.
• Låg: Endast en eller två frontender bör användas. Skicka endast paket som är mindre än 16 MiB.
• Medel: Lämplig för de flesta produktionsarbetsbelastningar med måttliga meddelandestorlekar.
• Hög: Använd när du behöver hantera stora meddelanden eller högt dataflöde med stora buffertar.

Det totala brokerminnet beror på både minnesprofilen och kardinalitet (antal frontend-repliker, backend-partitioner och redundansfaktor). Fler poddar innebär mer totalt minne. För uppmätt baslinjeresursförbrukning mellan olika konfigurationer, se Baslinjeresursprofiler.

Beräkna total minnesanvändning

Du kan beräkna den totala minnesanvändningen med den här formeln:

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

Where:

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

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

Som jämförelse har Tiny-minnesprofilen en minnesanvändning på klientdelen på 99 MiB och en minnesanvändning för serverdelen på 102 MiB. Med samma brokerkonfiguration är den totala minnesanvändningen:

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

Konfiguration av minnesprofil

När du distribuerar IoT-åtgärder med hjälp az iot ops create av kommandot anger parametern --broker-mem-profile minnesprofilinställningarna.

Följande kommando anger till exempel minnesprofilen till Tiny (andra parametrar utelämnas för korthet):

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

Mer information finns i az iot ops create valfria parametrar.

Valfria inställningar för mäklare

Följande brokerinställningar konfigureras också vid driftsättning och kan inte ändras i efterhand. Granska dessa om de gäller för ditt scenario:

• Diskstödd meddelandebuffert – Buffertmeddelanden till disk när prenumerantköer överskrider tillgängligt minne. Användbart för beständiga sessioner och anslutningsutmaningar.
• Persistens — Skriv kritiska brokerdata till disk för att bevara dem mellan omstarter.
• Diagnostik — Konfigurera mätvärden, loggar och självtestprober för MQTT-brokern.
• Avancerade MQTT-alternativ – Anpassa sessionsförfallodatum, meddelandeförfallodatum, kögränser för prenumeranter och inställningar för att hålla vid liv.
• Kryptering av intern trafik — Konfigurera kryptering av intern trafik mellan brokerns frontend- och backend-poddar (aktiverat som standard).

Nästa steg

• Förbereda klustret
• Distribuera till ett produktionskluster
• Konfigurera observerbarhet
• Säkra din driftsättning