Konfigurera asynkrona instä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 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älvåterställningsmekanismer är inbyggda i koordinatorn och kan ofta automatiskt återställas från komponentfel. En nod misslyckas till exempel i ett Kubernetes-kluster som konfigurerats för hög tillgänglighet.

Du kan skala MQTT-koordinatorn vågrätt genom att lägga till fler klientdelsrepliker och serverdelspartitioner. Klientdelsreplikerna ansvarar för att acceptera MQTT-anslutningar från klienter och vidarebefordra dem till serverdelspartitionerna. Serverdelspartitionerna ansvarar för att lagra och leverera meddelanden till klienterna. Klientdelspoddarna distribuerar meddelandetrafik över serverdelspoddarna, och 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

Viktigt!

Den här inställningen kräver att du ändrar Broker-resursen och kan endast konfigureras vid den första distributionen med hjälp av Azure CLI eller Azure-portalen. En ny distribution krävs om konfigurationsändringar i Broker behövs. Mer information finns i Anpassa standard broker.

Om du vill konfigurera skalningsinställningarna för MQTT Broker 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.

Portal

Automatisk kardinalitet stöds ännu inte vid distribution av Azure IoT-åtgärder via Azure Portal. Du kan dock manuellt ange klusterdistributionsläget som enskild nod eller multinod. Mer information finns i Distribuera Azure IoT-åtgärder.

Azure CLI

Förbered en Broker-konfigurationsfil i JSON-format som innehåller önskade egenskaper för Azure Resource Manager-resursen microsoft.iotoperations/instances/brokers och se till att utelämna fältetcardinality. Ange till exempel endast minnesprofilen:

{
  "memoryProfile": "<MEMORY_PROFILE>"
}

Distribuera sedan Azure IoT Operations med kommandot az iot ops create med --broker-config-file flaggan, till exempel följande kommando (andra parametrar utelämnas för korthet):

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

Mer information finns i Azure CLI-stöd för avancerad MQTT-koordinatorkonfiguration.

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

Detta är dock inte automatisk skalning. Operatorn skalar inte automatiskt antalet poddar baserat på belastningen. Operatorn avgör endast det ursprungliga antalet poddar som ska distribueras baserat på klustermaskinvaran. Som tidigare nämnts kan kardinaliteten endast anges vid den första distributionstiden och 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.

Portal

I följande guide för att distribuera Azure IoT Operations går du till avsnittet Konfiguration och tittar under MQTT-koordinatorkonfiguration. Här kan du ange antalet klientdelsrepliker, serverdelspartitioner och serverdelsarbetare.

Azure CLI

När du distribuerar Azure IoT Operations med kommandot az iot ops create använder du parametrarna --broker-frontend-replicas, --broker-frontend-workers, --broker-backend-part, --broker-backend-rfoch för --broker-backend-workers att ange kardinalitetsinställningarna.

Om du till exempel vill ange en klientdelsreplik, en klientdelsarbetare, en serverdelspartition, två serverdelsrepliker per partition och en serverdelsarbetare per replik läser du följande kommando (andra parametrar utelämnas för korthet):

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

Du kan också använda --broker-config-file flaggan för att ange en JSON-fil som innehåller kardinalitetsinställningarna. Ett exempel på en JSON-fil för samma inställningar:

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

Distribuera sedan Azure IoT Operations med kommandot az iot ops create med --broker-config-file flaggan, till exempel följande kommando (andra parametrar utelämnas för korthet):

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-koordinatorn refererar kardinaliteten till antalet klientdelsrepliker, serverdelspartitioner och serverdelsarbetare som ska distribueras. Kardinalitetsinställningarna används för att skala koordinatorn vågrätt och förbättra hög tillgänglighet om det uppstår podd- eller nodfel.

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

Klientdel

Klientdelsunderfältet definierar inställningarna för klientdelspoddarna. De två huvudinställningarna är:

• Repliker: Antalet klientdelsrepliker (poddar) som ska distribueras. Om du ökar antalet klientdelsrepliker får du hög tillgänglighet om någon av klientdelspoddarna misslyckas.

• Arbetare: Antalet logiska klientdelsarbetare 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. Klientdelspoddarna distribuerar meddelandetrafik över partitionerna. Om du ökar antalet partitioner ökar antalet meddelanden som asynkron meddelandekö kan hantera.

• Redundansfaktor: Antalet serverdelsrepliker (poddar) som ska distribueras per partition. Om du ökar redundansfaktorn ökar antalet datakopior för att ge återhämtning mot nodfel i klustret.

• Arbetare: Antalet arbetare som ska distribueras per serverdelsreplik. Om du ökar antalet arbetare per serverdelsreplik kan antalet meddelanden som serverdelspodden kan hantera öka. Varje arbetare kan använda högst två processorkärnor, så var försiktig när du ökar antalet arbetare per replik för 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. Detta leder dock 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 klientdelsreplik kan du öka processorkärnans användning om du upptäcker att processoranvändningen i klientdelen är en flaskhals. Om du ökar antalet serverdelsarbetare kan du hjälpa till med dataflödet för meddelanden om serverdelsprocessorn ä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 som ska matcha antalet noder (3) och serverdelsarbetare till 1. Ange redundansfaktor som önskat (2 eller 3). Öka antalet klientdelsarbetare om du upptäcker att klientdels-CPU är en flaskhals. Kom ihåg att serverdels- och klientdelsarbetare kan konkurrera om CPU-resurser med varandra och andra poddar.

Konfigurera minnesprofil

Viktigt!

Den här inställningen kräver att du ändrar Broker-resursen och kan endast konfigureras vid den första distributionen med hjälp av Azure CLI eller Azure-portalen. En ny distribution krävs om konfigurationsändringar i Broker behövs. Mer information finns i Anpassa standard broker.

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

Portal

I följande guide för att distribuera Azure IoT-åtgärder går du till avsnittet Konfiguration och tittar under MQTT-koordinatorkonfiguration och letar upp inställningen Minnesprofil. Här kan du välja från tillgängliga minnesprofiler från en listruta.

Azure CLI

När du distribuerar Azure IoT Operations med kommandot az iot ops create använder du parametern --broker-mem-profile för att ange minnesprofilinställningarna.

Om du till exempel vill ange minnesprofilen som Tinyläser du följande kommando (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.

Det finns några minnesprofiler att välja mellan, var och en med olika minnesanvändningsegenskaper.

Pytteliten

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.

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

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

Låg

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.

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

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

Medium

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.

Högt

• 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.

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. Detta hjälper till att undvika situationer där den begärda kardinaliteten för asynkron meddelandekö saknar tillräckligt med resurser för att köras optimalt. Det hjälper också till att undvika potentiella CPU-konkurrens och poddavhysningar.

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

Kardinaliteten nedan 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.

Portal

Det går inte att generateResourceLimits ändra fältet i Azure Portal. Om du vill inaktivera den här inställningen använder du Azure CLI.

Azure CLI

Förbered en Broker-konfigurationsfil i JSON-format som innehåller önskade egenskaper för Azure Resource Manager-resursen microsoft.iotoperations/instances/brokers och ange fältet generateResourceLimits.cpu till Disabled. Till exempel:

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

Distribuera sedan Azure IoT Operations med kommandot az iot ops create med --broker-config-file flaggan, till exempel följande kommando (andra parametrar utelämnas för korthet):

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

Mer information finns i Azure CLI-stöd för avancerad MQTT-koordinatorkonfiguration.

Distribution med flera noder

För att säkerställa hög tillgänglighet och motståndskraft med distributioner med flera noder anger Azure IoT Operations MQTT-asynkrona asynkrona regler för tillhörighet mot serverdelspoddar.

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

Syftet med regler mot tillhörighet

Reglerna mot tillhörighet ser till att serverdelspoddar från samma partition inte körs på samma nod. Detta 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 inställningar för tillhörighetsskydd

Använd följande kommando för att verifiera inställningarna för antitillhörighet för en serverdelspodd:

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

Utdata visar konfigurationen mot tillhörighet, ungefär så här:

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

Det här är de enda reglerna för tillhörighetsutjämning som angetts för asynkron meddelandekö.

Nästa steg

• Konfigurera lyssnare för MQTT-koordinatorn