Uitrolplanning - Berichtbuffer op schijf

De berichtbuffer met schijfsteun is een functie waarmee de MQTT-broker berichtenwachtrijen van abonnees naar de schijf kan overlopen wanneer deze het beschikbare geheugen overschrijden. Bepaal vóór de implementatie of u buffering van berichten met schijfsteun nodig hebt voor uw MQTT-broker.

De door schijf ondersteunde berichtbufferfunctie wordt gebruikt voor efficiënt beheer van berichtenwachtrijen binnen de gedistribueerde MQTT-broker. Tot de voordelen behoren onder meer:

• Efficiënt wachtrijbeheer: in een MQTT-broker wordt elke abonnee gekoppeld aan een berichtenwachtrij. De verwerkingssnelheid van berichten van een abonnee is rechtstreeks van invloed op de grootte van de wachtrij. Als een abonnee berichten langzaam verwerkt of als deze de verbinding verbreken, maar een permanente MQTT-sessie aanvraagt, kan de wachtrij groter worden dan het beschikbare geheugen.
• Gegevensbehoud voor permanente sessies: De functie voor berichtbuffer met schijfsteun zorgt ervoor dat wanneer een wachtrij het beschikbare geheugen overschrijdt, deze naadloos wordt gebufferd naar schijf. Deze functie voorkomt gegevensverlies en ondersteunt permanente MQTT-sessies, zodat abonnees hun sessies kunnen hervatten met hun berichtenwachtrijen intact wanneer ze opnieuw verbinding maken. De schijf wordt gebruikt als tijdelijke opslag en fungeert als overloop vanuit het geheugen. Gegevens die naar schijf worden geschreven, zijn niet duurzaam en gaan verloren wanneer de pod wordt afgesloten. Als ten minste één pod in elke back-endketen functioneel blijft, verliest de broker als geheel geen gegevens.
• Connectiviteitsproblemen afhandelen: cloudconnectors worden behandeld als abonnees met permanente sessies die connectiviteitsproblemen kunnen ondervinden wanneer ze niet kunnen communiceren met externe systemen, zoals een Azure Event Grid MQTT-broker vanwege netwerkverbinding. In dergelijke scenario's stapelen berichten (PUBLISHes) zich op. De MQTT-broker buffert deze berichten op intelligente wijze in het geheugen of de schijf totdat de verbinding is hersteld, wat zorgt voor berichtintegriteit.

Standaard is de functie voor berichtbuffer op schijf uitgeschakeld. In dit geval blijven berichten in het geheugen en wordt de terugdruk toegepast op clients wanneer het geheugengebruik de limiet bereikt zoals gedefinieerd door de wachtrijlimiet voor abonnees.

Berichtbuffer op schijf configureren

Als u de schijfgebaseerde berichtbuffer wilt configureren, bewerkt u de sectie diskBackedMessageBuffer in de resource Broker. Deze configuratie wordt momenteel alleen ondersteund door de --broker-config-file vlag te gebruiken wanneer u Azure IoT-bewerkingen implementeert met behulp van de az iot ops create opdracht. Zie Azure CLI ondersteuning voor geavanceerde MQTT-brokerconfiguratie voor meer informatie.

Deze instelling kan niet worden gewijzigd na de implementatie. Als u de configuratie van de berichtbuffer met schijfsteun wilt wijzigen, implementeert u het IoT Operations-exemplaar opnieuw.

Om aan de slag te gaan, bereid u een Broker-configuratiebestand voor aan de hand van de API-referentie voor DiskBackedMessageBuffer.

Implementeer vervolgens IoT-bewerkingen met de --broker-config-file vlag (andere parameters die zijn weggelaten voor beknoptheid):

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

De eenvoudigste configuratie omvat bijvoorbeeld alleen het opgeven van de maximale grootte. In dit geval wordt een emptyDir volume aangekoppeld. De maxSize waarde wordt gebruikt als de groottelimiet van het emptyDir volume. Maar deze optie is de minst voorkeursoptie vanwege de beperkingen van het emptyDir volume.

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

Als u een betere configuratie van een berichtbuffer met schijfsteun wilt krijgen, geeft u een kortstondige volume- of permanente volumeclaim op om een toegewezen opslagvolume voor uw berichtbuffer te koppelen. Voorbeeld:

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

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

Pas de bufferopties voor brokerberichten aan door de volgende instellingen aan te passen:

• Configureer het volume: geef een volumeclaimsjabloon op om een toegewezen opslagvolume voor uw berichtbuffer te koppelen.
• Selecteer een opslagklasse: Definieer de gewenste opslagklasse met behulp van de storageClassName eigenschap.
• Toegangsmodi definiëren: Bepaal de toegangsmodi die u nodig hebt voor uw volume. Zie Permanente volumetoegangsmodi voor meer informatie.

Tijdelijk volume

Kortstondig volume is de voorkeursoptie voor uw berichtbuffer.

Voor kortstondige volumes volgt u het advies in de sectie Overwegingen voor opslagproviders .

De waarde van de eigenschap ephemeralVolumeClaimSpec wordt gebruikt als de eigenschap ephemeral.volumeClaimTemplate.spec van het volume in de specificaties StatefulSet van de backendketens.

Als u bijvoorbeeld een kortstondig volume wilt gebruiken met een capaciteit van 1 gigabyte, geeft u de volgende parameters op in uw Broker-resource:

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

Permanent volume

Permanent volume is de volgende voorkeursoptie voor uw berichtbuffer na kortstondige volumes.

Voor permanente volumes volgt u het advies in de sectie Overwegingen voor opslagproviders .

De waarde van de eigenschap persistentVolumeClaimSpec wordt gebruikt als de eigenschap volumeClaimTemplates.spec van de StatefulSet-specificaties van de backendketens.

Als u bijvoorbeeld een permanent volume wilt gebruiken met een capaciteit van 1 gigabyte, geeft u de volgende parameters op in uw Broker-resource:

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

leegDir-volume

Een emptyDir-volume is de minst aanbevolen optie na een persistent volume.

Gebruik alleen een emptyDir volume wanneer u een cluster met bestandssysteemquota gebruikt. Zie het tabblad Bestandssysteemprojectquotum voor meer informatie. Als de functie niet is ingeschakeld, voert het cluster periodiek scannen uit die geen limiet afdwingt en waarmee het hostknooppunt schijfruimte kan vullen en het hele hostknooppunt als beschadigd markeert.

Als u bijvoorbeeld een emptyDir volume wilt gebruiken met een capaciteit van 1 gigabyte, geeft u de volgende parameters op in uw Broker-resource:

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

Overwegingen voor opslagproviders

Houd rekening met het gedrag van uw gekozen opslagprovider, bijvoorbeeld wanneer u providers zoals rancher.io/local-path. Als de provider geen limieten ondersteunt, verbruikt het vullen van het volume de schijfruimte van het knooppunt. Dit gedrag kan ertoe leiden dat Kubernetes het knooppunt en alle gekoppelde pods als beschadigd markeren. Het is van cruciaal belang om te begrijpen hoe uw opslagprovider zich gedraagt in dergelijke scenario's.

Disabled

Als u de schijfgebaseerde berichtbuffer niet wilt gebruiken, neemt u de eigenschap diskBackedMessageBufferSettings niet op in uw Broker-resource. Dit gedrag is ook de standaardinstelling.

Schijfbuffer versus persistentie

De door schijf ondersteunde berichtbuffer en brokerpersistentie schrijven beide gegevens naar schijf, maar ze dienen verschillende doeleinden:

Volgende stappen 

• Persistentie-instellingen controleren
• Diagnostische instellingen controleren
• Geavanceerde MQTT-opties bekijken
• Uw cluster voorbereiden