Delen via

Gedrag van berichtbuffer met schijfsteun configureren

  • Artikel

Belangrijk

Deze instelling vereist het wijzigen van de Broker-resource en kan alleen worden geconfigureerd tijdens 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 van de MQTT-broker. Tot de voordelen behoren onder meer:

  • Efficiënt wachtrijbeheer: in een MQTT-broker wordt elke abonnee gekoppeld aan een berichtenwachtrij. De snelheid die een abonnee heeft, verwerkt berichten 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 verlies van gegevens 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, maar zolang 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 kunnen krijgen met connectiviteitsproblemen wanneer ze niet kunnen communiceren met externe systemen zoals 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, waardoor de integriteit van berichten wordt gewaarborgd.

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 extra versleuteling. Het beveiligen van de schijf is essentieel voor het beveiligen van de gegevens die door de broker zijn opgeslagen.

Configuratieopties

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

Bereid om aan de slag te gaan een Broker-configuratiebestand voor volgens de Naslaginformatie over de DiskBackedMessageBuffer-API .

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 dit is de minst voorkeursoptie die de beperkingen van emptyDir volume geeft.

{
  "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 StorageClass 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:

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

Tip

Als u een tijdelijke volumeclaim (EVC) of PVC-sjabloon (Persistent Volume Claim) opgeeft, kunt u een opslagklasse van uw keuze gebruiken, waardoor u meer flexibiliteit hebt voor sommige implementatiescenario's. Permanente volumes (CSV's) die zijn ingericht met behulp van een PVC-sjabloon, worden bijvoorbeeld weergegeven in opdrachten zoals kubectl get pv, wat handig kan zijn 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 Blobs. Over het algemeen is het echter beter om lokale schijven met een kleinere maxSize waarde te gebruiken, omdat de berichtenbuffer profiteert van snelle toegang en geen duurzaamheid vereist.

Azure IoT-bewerkingen implementeren met een berichtbuffer met schijfsteun

Als u een berichtbuffer met schijfsteun wilt gebruiken, implementeert u Azure IoT-bewerkingen met behulp van de az iot ops create opdracht met de --broker-config-file vlag. Zie de volgende opdracht (andere parameters die zijn 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 Azure 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 StatefulSet-specificaties van de 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"
      ]
    }
  }
}

emptyDir volume

Een leegDir-volume is de minst voorkeursoptie na permanent volume.

Gebruik alleen een leegDir-volume wanneer u een cluster met bestandssysteemquota gebruikt. Zie de details op 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 leegDir-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 bij het gebruik van providers zoals rancher.io/local-path. Als de provider geen limieten ondersteunt, verbruikt het vullen van het volume de schijfruimte van het knooppunt. Dit 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 is ook het standaardgedrag.

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 echter tijdelijke opslagruimte voor het opslaan van gegevens op schijf, waardoor geheugenoverloop en gegevensverlies tijdens het opnieuw opstarten van de pod worden voorkomen.