Gedrag van berichtbuffer met schijfsteun configureren

Artikel
02/14/2025

Belangrijk

Voor deze instelling moet u de Broker-resource wijzigen. Deze wordt alleen geconfigureerd bij de eerste implementatie met behulp van de Azure CLI of Azure Portal. Er is een nieuwe implementatie vereist als brokerconfiguratiewijzigingen nodig zijn. Zie Standaardbroker aanpassen voor meer informatie.

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 te maken hebben met connectiviteitsproblemen wanneer ze niet kunnen communiceren met externe systemen zoals een Azure Event Grid MQTT-broker vanwege de netwerkverbinding. In dergelijke scenario's verzamelen berichten (PUBLISHes). 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 met schijfsteun uitgeschakeld. In dit geval blijven berichten in het geheugen en wordt back-druk toegepast op clients als de lezersgroep of scratchpool de limiet bereikt zoals gedefinieerd door de wachtrijlimiet voor abonnees.

Het configureren van de door schijf ondersteunde berichtbuffer is essentieel voor het onderhouden van een robuust en betrouwbaar systeem voor berichtenwachtrijen, met name in scenario's waarin de snelheid en connectiviteit van berichtenverwerking essentieel zijn.

Notitie

De MQTT-broker schrijft gegevens exact zoals ontvangen van clients, zonder dat er versleuteling is toegevoegd. Het beveiligen van de schijf is essentieel om de gegevens te beveiligen die door de broker worden opgeslagen.

Configuratieopties

Als u de berichtbuffer met schijfsteun wilt configureren, bewerkt u de diskBackedMessageBuffer sectie in de Broker-resource. Deze configuratie wordt momenteel alleen ondersteund met behulp van de --broker-config-file vlag wanneer u Azure IoT-bewerkingen implementeert met behulp van de az iot ops create opdracht.

Om aan de slag te gaan, bereidt u een Broker-configuratiebestand voor door de Naslaginformatie over de DiskBackedMessageBuffer-API te volgen.

De eenvoudigste configuratie omvat bijvoorbeeld alleen het opgeven van de maximale grootte. In dit geval wordt een emptyDir volume gekoppeld. 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": "<SIZE>"
  }
}

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": "<SIZE>",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "<NAME>",
      "accessModes": [
        "<MODE>"
      ]
    }
  }
}

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

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.

Gebruik de volgende secties om inzicht te hebben in de verschillende volumemodi:

Kortstondig volume is de voorkeursoptie.
Permanent volume is de volgende voorkeursoptie.
leegDir-volume is de minst voorkeursoptie.

Zowel permanente als tijdelijke volumes worden doorgaans geleverd door dezelfde opslagklassen. Als beide opties beschikbaar zijn, kiest u kortstondig. Tijdelijke volumes vereisen Kubernetes 1.23 of hoger.

Tip

Wanneer u een tijdelijke volumeclaim (EVC) of PVC-sjabloon (Persistent Volume Claim) opgeeft, kunt u een opslagklasse van uw keuze gebruiken, waardoor sommige implementatiescenario's flexibeler worden. Permanente volumes die zijn ingericht met behulp van een PVC-sjabloon, worden bijvoorbeeld weergegeven in opdrachten zoals kubectl get pv, wat handig is voor het inspecteren van de clusterstatus.

Als uw Kubernetes-knooppunten onvoldoende lokale schijfruimte voor de berichtbuffer hebben, gebruikt u een opslagklasse die netwerkopslag biedt, zoals Azure Blob Storage. Het is beter om een lokale schijf met een kleinere maxSize waarde te gebruiken, omdat de berichtbuffer profiteert van snelle toegang en geen duurzaamheid vereist.

IoT-bewerkingen implementeren met een berichtbuffer met schijfsteun

Als u een berichtbuffer met schijfsteun wilt gebruiken, implementeert u IoT-bewerkingen met behulp van de az iot ops create opdracht met de --broker-config-file vlag. Zie de volgende opdracht. (Andere parameters worden weggelaten voor beknoptheid.)

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

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.

Kortstondig 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 ephemeralVolumeClaimSpec eigenschap wordt gebruikt als de ephemeral.volumeClaimTemplate.spec eigenschap van het volume in de StatefulSet specificaties van de back-endketens.

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 persistentVolumeClaimSpec eigenschap wordt gebruikt als de volumeClaimTemplates.spec eigenschap van de specificaties van de StatefulSet back-endketens.

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 leegDir-volume is de minst voorkeursoptie na permanent 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.

Uitgeschakeld

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

Persistentie

Het is belangrijk om te weten dat de functie voor berichtbuffer met schijfsteun niet synoniem is met persistentie. In deze context verwijst persistentie naar gegevens die overleven tijdens het opnieuw opstarten van pods. Deze functie biedt tijdelijke opslagruimte voor het opslaan van gegevens op schijf, waardoor geheugenoverloop en gegevensverlies tijdens het opnieuw opstarten van de pod worden voorkomen.

Delen via