Dela via

Konfigurera beteende för diskstödd meddelandebuffert

  • Artikel

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.

Den diskstödda meddelandebuffertfunktionen används för effektiv hantering av meddelandeköer i MQTT-broker distribuerad MQTT-asynkron meddelandekö. Exempel på fördelar:

  • Effektiv köhantering: I en MQTT-asynkron meddelandekö associeras varje prenumerant med en meddelandekö. Hastigheten som en prenumerant bearbetar meddelanden påverkar direkt köns storlek. Om en prenumerant bearbetar meddelanden långsamt eller om de kopplar från men begär en beständig MQTT-session kan kön växa sig större än det tillgängliga minnet.

  • Databevarande för beständiga sessioner: Den diskstödda meddelandebuffertfunktionen säkerställer att när en kö överskrider det tillgängliga minnet buffrar den sömlöst till disken. Den här funktionen förhindrar dataförlust och stöder MQTT-beständiga sessioner, vilket gör att prenumeranter kan återuppta sina sessioner med sina meddelandeköer intakta vid återanslutning. Disken används som tillfällig lagring och fungerar som en spillover från minnet. Data som skrivs till disken är inte varaktiga och går förlorade när podden avslutas, men så länge minst en podd i varje serverdelskedja förblir funktionell förlorar inte asynkrona data.

  • Hantera anslutningsutmaningar: Molnanslutningar behandlas som prenumeranter med beständiga sessioner som kan möta anslutningsutmaningar när de inte kan kommunicera med externa system som Event Grid MQTT-koordinator på grund av nätverksfrånkoppling. I sådana scenarier ackumuleras meddelanden (PUBLISHes). MQTT-koordinatorn buffrar intelligent dessa meddelanden till minne eller disk tills anslutningen återställs, vilket säkerställer meddelandeintegriteten.

Som standard är den diskstödda meddelandebuffertfunktionen inaktiverad. I det här fallet finns meddelanden kvar i minnet och tillbakatryck tillämpas på klienter när läsarpoolen eller den tillfälliga poolen når gränsen enligt definitionen av gränsen för prenumerantkö.

Det är viktigt att konfigurera den diskstödda meddelandebufferten för att upprätthålla ett robust och tillförlitligt system för meddelandeköer, särskilt i scenarier där meddelandebearbetningshastighet och anslutning är viktiga.

Kommentar

MQTT-koordinatorn skriver data till disken exakt som mottagna från klienter, utan ytterligare kryptering. Det är viktigt att skydda disken för att skydda data som lagras av asynkron meddelandekö.

Konfigurationsalternativ

Om du vill konfigurera den diskstödda meddelandebufferten diskBackedMessageBuffer redigerar du avsnittet i Broker-resursen. För närvarande stöds detta endast med hjälp av --broker-config-file flaggan när du distribuerar Azure IoT Operations med hjälp av az iot ops create kommandot .

Kom igång genom att förbereda en Broker-konfigurationsfil efter API-referensen DiskBackedMessageBuffer .

Den enklaste konfigurationen innebär till exempel att endast ange maxstorleken. I det här fallet monteras en emptyDir volym . Värdet maxSize används som storleksgräns för emptyDir volymen. Men det här är det minst föredragna alternativet som ger volymbegränsningarna emptyDir .

{
  "diskBackedMessageBuffer": {
    "maxSize": "<SIZE>"
  }
}

Om du vill få en bättre konfiguration av en diskstödd meddelandebuffert anger du en tillfällig volym eller ett beständigt volymanspråk för att montera en dedikerad lagringsvolym för meddelandebufferten. Till exempel:

{
  "diskBackedMessageBuffer": {
    "maxSize": "<SIZE>",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "<NAME>",
      "accessModes": [
        "<MODE>"
      ]
    }
  }
}

{
  "persistentVolumeClaimSpec": {
    "maxSize": "<SIZE>",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "<NAME>",
      "accessModes": [
        "<MODE>"
      ]
    }
  }
}

Anpassa buffertalternativen för meddelandeköer genom att justera följande inställningar:

  • Konfigurera volymen: Ange en volymanspråksmall för att montera en dedikerad lagringsvolym för meddelandebufferten.

  • Välj en lagringsklass: Definiera önskad StorageClass med hjälp storageClassName av egenskapen .

  • Definiera åtkomstlägen: Bestäm vilka åtkomstlägen du behöver för volymen. Mer information finns i beständiga volymåtkomstlägen.

Använd följande avsnitt för att förstå de olika volymlägena:

Både beständiga och tillfälliga volymer tillhandahålls vanligtvis av samma lagringsklasser. Om båda alternativen är tillgängliga väljer du tillfälliga. Observera att tillfälliga volymer kräver Kubernetes 1.23 eller senare.

Dricks

Om du anger en EVC-mall (Ephemeral Volume Claim) eller EN PVC-mall (Persistent Volume Claim) kan du använda valfri lagringsklass, vilket ökar flexibiliteten för vissa distributionsscenarier. Till exempel visas beständiga volymer (PV:er) som etablerats med hjälp av en PVC-mall i kommandon som kubectl get pv, vilket kan vara användbart för att inspektera klustertillståndet.

Om kubernetes-noderna saknar tillräckligt med lokalt diskutrymme för meddelandebufferten använder du en lagringsklass som tillhandahåller nätverkslagring som Azure Blobs. Det är dock i allmänhet bättre att använda en lokal disk med ett mindre maxSize värde, eftersom meddelandebufferten drar nytta av snabb åtkomst och inte kräver hållbarhet.

Distribuera Azure IoT-åtgärder med diskbaserad meddelandebuffert

Om du vill använda en diskbaserad meddelandebuffert distribuerar du Azure IoT Operations med az iot ops create kommandot med --broker-config-file flaggan . Se följande kommando (andra parametrar utelämnas för korthet):

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

Det går inte att ändra den här inställningen efter distributionen. Om du vill ändra konfigurationen av den diskstödda meddelandebufferten distribuerar du om Azure IoT Operations-instansen.

Tillfällig volym

Tillfällig volym är det föredragna alternativet för meddelandebufferten.

För tillfälliga volymer följer du råden i avsnittet Överväganden för lagringsproviders .

Värdet för ephemeralVolumeClaimSpec egenskapen används som ephemeral.volumeClaimTemplate.spec egenskapen för volymen i StatefulSet-specifikationerna för serverdelskedjorna.

Om du till exempel vill använda en tillfällig volym med en kapacitet på 1 gigabyte anger du följande parametrar i din Broker-resurs:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

Beständiga volymer

Beständiga volymer är nästa föredragna alternativ för meddelandebufferten efter den tillfälliga volymen.

För beständiga volymer följer du råden i avsnittet Överväganden för lagringsproviders .

Värdet för persistentVolumeClaimSpec egenskapen används som volumeClaimTemplates.spec egenskap för StatefulSet-specifikationerna för serverdelskedjorna.

Om du till exempel vill använda en beständiga volym med en kapacitet på 1 gigabyte anger du följande parametrar i din Broker-resurs:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "persistentVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

emptyDir volym

En emptyDir-volym är det minst föredragna alternativet efter beständiga volymer.

Använd endast emptyDir-volym när du använder ett kluster med filsystemkvoter. Mer information finns i information på fliken Projektkvot för Filsystem. Om funktionen inte är aktiverad gör klustret regelbunden genomsökning som inte framtvingar någon gräns och gör att värdnoden kan fylla diskutrymmet och markera hela värdnoden som felfri.

Om du till exempel vill använda en emptyDir-volym med en kapacitet på 1 gigabyte anger du följande parametrar i din Broker-resurs:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G"
  }
}

Överväganden för lagringsprovidrar

Överväg beteendet hos den valda lagringsprovidern. Till exempel när du använder leverantörer som rancher.io/local-path. Om providern inte stöder gränser förbrukar fyllningen av volymen nodens diskutrymme. Detta kan leda till att Kubernetes markerar noden och alla associerade poddar som felaktiga. Det är viktigt att förstå hur lagringsleverantören beter sig i sådana scenarier.

Inaktiverad

Om du inte vill använda den diskstödda meddelandebufferten diskBackedMessageBufferSettings ska du inte ta med egenskapen i din Broker-resurs. Detta är också standardbeteendet.

Bevarande

Det är viktigt att förstå att den diskstödda meddelandebuffertfunktionen inte är synonym med beständighet. I det här sammanhanget refererar beständighet till data som överlever över poddomstarter. Den här funktionen ger dock tillfälligt lagringsutrymme för data som ska sparas på disken, vilket förhindrar minnesspill och dataförlust under omstarter av poddar.