Udostępnij za pośrednictwem

Konfigurowanie zachowania buforu komunikatów opartego na dysku

  • Artykuł

Ważne

To ustawienie wymaga zmodyfikowania zasobu brokera i można go skonfigurować tylko w początkowym czasie wdrażania przy użyciu interfejsu wiersza polecenia platformy Azure lub witryny Azure Portal. Nowe wdrożenie jest wymagane, jeśli wymagane są zmiany konfiguracji brokera. Aby dowiedzieć się więcej, zobacz Dostosowywanie domyślnego brokera.

Funkcja buforu komunikatów wspieranego przez dysk służy do wydajnego zarządzania kolejkami komunikatów w ramach brokera rozproszonego MQTT brokera MQTT. Korzyści:

  • Wydajne zarządzanie kolejkami: w brokerze MQTT każdy subskrybent jest skojarzony z kolejką komunikatów. Szybkość przetwarzania komunikatów przez subskrybenta ma bezpośredni wpływ na rozmiar kolejki. Jeśli subskrybent przetwarza komunikaty powoli lub jeśli rozłączają się, ale żądają trwałej sesji MQTT, kolejka może rosnąć większa niż dostępna pamięć.

  • Zachowywanie danych dla sesji trwałych: funkcja buforu komunikatów wspieranego przez dysk gwarantuje, że gdy kolejka przekroczy dostępną pamięć, będzie bezproblemowo buforowana na dysku. Ta funkcja zapobiega utracie danych i obsługuje trwałe sesje MQTT, dzięki czemu subskrybenci mogą wznowić sesje z kolejkami komunikatów bez zmian po ponownym połączeniu. Dysk jest używany jako magazyn efemeryczny i służy jako wyciek pamięci. Dane zapisane na dysku nie są trwałe i są tracone po zakończeniu pracy zasobnika, ale o ile co najmniej jeden zasobnik w każdym łańcuchu zaplecza pozostaje funkcjonalny, broker jako całość nie traci żadnych danych.

  • Obsługa problemów z łącznością: łączniki w chmurze są traktowane jako subskrybenci z trwałymi sesjami, które mogą napotkać problemy z łącznością, gdy nie mogą komunikować się z systemami zewnętrznymi, takimi jak broker MQTT usługi Event Grid z powodu rozłączenia sieci. W takich scenariuszach komunikaty (PUBLISHes) gromadzą się. Broker MQTT inteligentnie buforuje te komunikaty do pamięci lub dysku do czasu przywrócenia łączności, zapewniając integralność komunikatów.

Domyślnie funkcja buforu komunikatów z obsługą dysku jest wyłączona. W takim przypadku komunikaty pozostają w pamięci, a ciśnienie wsteczne jest stosowane do klientów, ponieważ pula czytników lub pula plików tymczasowych osiągnie limit zdefiniowany przez limit kolejki subskrybentów.

Skonfigurowanie buforu komunikatów opartego na dysku jest niezbędne do utrzymania niezawodnego i niezawodnego systemu kolejkowania komunikatów, zwłaszcza w scenariuszach, w których szybkość przetwarzania komunikatów i łączność są krytyczne.

Uwaga

Broker MQTT zapisuje dane na dysku dokładnie tak, jak odebrano od klientów bez dodatkowego szyfrowania. Zabezpieczanie dysku jest niezbędne do ochrony danych przechowywanych przez brokera.

Opcje konfiguracji

Aby skonfigurować bufor komunikatów oparty na dysku, zmodyfikuj sekcję diskBackedMessageBuffer w zasobie brokera. Obecnie jest to obsługiwane tylko przy użyciu flagi --broker-config-file podczas wdrażania operacji usługi Azure IoT przy użyciu az iot ops create polecenia .

Aby rozpocząć, przygotuj plik konfiguracji brokera zgodnie z dokumentacją interfejsu API DiskBackedMessageBuffer .

Na przykład najprostsza konfiguracja obejmuje tylko określenie maksymalnego rozmiaru. W takim przypadku wolumin emptyDir jest zainstalowany. Wartość maxSize jest używana jako limit rozmiaru woluminu emptyDir . Ale jest to najmniej preferowana opcja dająca ograniczenia woluminu emptyDir .

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

Aby uzyskać lepszą konfigurację buforu komunikatów opartego na dysku, określ wolumin efemeryczny lub oświadczenie trwałego woluminu, aby zainstalować dedykowany wolumin magazynu dla buforu komunikatów. Na przykład:

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

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

Dostosuj opcje buforu komunikatów brokera, dostosowując następujące ustawienia:

  • Konfigurowanie woluminu: określ szablon oświadczenia woluminu, aby zainstalować dedykowany wolumin magazynu dla buforu komunikatów.

  • Wybierz klasę magazynu: zdefiniuj żądaną klasęstorageClassName StorageClass przy użyciu właściwości .

  • Definiowanie trybów dostępu: określ tryby dostępu potrzebne dla woluminu. Aby uzyskać więcej informacji, zobacz trwałe tryby dostępu do woluminów.

Skorzystaj z poniższych sekcji, aby zrozumieć różne tryby woluminu:

Zarówno woluminy trwałe, jak i efemeryczne są zwykle dostarczane przez te same klasy magazynu. Jeśli obie opcje są dostępne, wybierz efemeryczny. Należy pamiętać, że woluminy efemeryczne wymagają platformy Kubernetes w wersji 1.23 lub nowszej.

Napiwek

Określenie efemerycznego szablonu oświadczenia woluminu (EVC) lub trwałego oświadczenia woluminu (PVC) umożliwia użycie wybranej klasy magazynu, zwiększając elastyczność niektórych scenariuszy wdrażania. Na przykład woluminy trwałe aprowizowane przy użyciu szablonu PVC są wyświetlane w poleceniach takich jak kubectl get pv, które mogą być przydatne do sprawdzania stanu klastra.

Jeśli węzły kubernetes nie mają wystarczającej ilości miejsca na dysku lokalnym dla buforu komunikatów, użyj klasy magazynu, która zapewnia magazyn sieciowy, taki jak Azure Blobs. Jednak ogólnie lepiej jest używać dysku lokalnego o mniejszej maxSize wartości, ponieważ bufor komunikatów korzysta z szybkiego dostępu i nie wymaga trwałości.

Wdrażanie operacji usługi Azure IoT przy użyciu buforu komunikatów opartego na dysku

Aby użyć buforu komunikatów opartego na dysku, wdróż operacje usługi Azure IoT przy użyciu az iot ops create polecenia z flagą --broker-config-file . Zobacz następujące polecenie (inne parametry pominięte dla zwięzłości):

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

Tego ustawienia nie można zmienić po wdrożeniu. Aby zmienić konfigurację buforu komunikatów opartego na dysku, ponownie wdróż wystąpienie operacji usługi Azure IoT.

Wolumin efemeryczny

Wolumin efemeryczny jest preferowaną opcją buforu komunikatów.

W przypadku woluminu efemerycznego postępuj zgodnie z poradami w sekcji Zagadnienia dotyczące dostawców magazynu.

Wartość ephemeralVolumeClaimSpec właściwości jest używana jako ephemeral.volumeClaimTemplate.spec właściwość woluminu w specyfikacjach StatefulSet łańcuchów zaplecza.

Aby na przykład użyć woluminu efemerycznego z pojemnością 1 gigabajta, określ następujące parametry w zasobie brokera:

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

Wolumin trwały

Wolumin trwały to kolejna preferowana opcja buforu komunikatów po woluminie efemerycznym .

W przypadku woluminu trwałego postępuj zgodnie z poradami w sekcji Zagadnienia dotyczące dostawców magazynu.

Wartość persistentVolumeClaimSpec właściwości jest używana jako volumeClaimTemplates.spec właściwość specyfikacji StatefulSet łańcuchów zaplecza.

Aby na przykład użyć woluminu trwałego z pojemnością 1 gigabajta, określ następujące parametry w zasobie brokera:

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

emptyDir głośność

Wolumin emptyDir jest najmniej preferowaną opcją po woluminie trwałym.

Wolumin emptyDir należy używać tylko w przypadku korzystania z klastra z przydziałami systemu plików. Aby uzyskać więcej informacji, zobacz szczegóły na karcie Limit przydziału projektu systemu plików. Jeśli funkcja nie jest włączona, klaster wykonuje okresowe skanowanie , które nie wymusza żadnego limitu i umożliwia węzłowi hosta wypełnienie miejsca na dysku i oznaczenie całego węzła hosta jako w złej kondycji.

Aby na przykład użyć woluminu emptyDir o pojemności 1 gigabajta, określ następujące parametry w zasobie brokera:

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

Zagadnienia dotyczące dostawców magazynu

Rozważ zachowanie wybranego dostawcy magazynu. Na przykład w przypadku korzystania z dostawców, takich jak rancher.io/local-path. Jeśli dostawca nie obsługuje limitów, wypełnienie woluminu zużywa miejsce na dysku węzła. Może to prowadzić do oznaczania węzła przez platformę Kubernetes i wszystkich skojarzonych zasobników jako w złej kondycji. Ważne jest, aby zrozumieć, jak działa dostawca magazynu w takich scenariuszach.

Disabled

Jeśli nie chcesz używać buforu komunikatów opartego na dysku, nie dołączaj diskBackedMessageBufferSettings właściwości do zasobu brokera. Jest to również zachowanie domyślne.

Trwałość

Ważne jest, aby zrozumieć, że funkcja buforu komunikatów z obsługą dysku nie jest synonimem trwałości. W tym kontekście trwałość odnosi się do danych, które przetrwają po ponownym uruchomieniu zasobnika. Jednak ta funkcja zapewnia tymczasowe miejsce do magazynowania danych do zapisania na dysku, zapobiegając przepełnieniu pamięci i utracie danych podczas ponownego uruchamiania zasobnika.