Planowanie wdrożenia — bufor komunikatów oparty na dysku

Bufor komunikatów na dysku to funkcja, która umożliwia brokerowi MQTT zapisywanie kolejek komunikatów subskrybentów na dysku, gdy przekroczą ilość dostępnej pamięci. Zdecyduj przed wdrożeniem, czy potrzebujesz buforowania komunikatów opartych na dysku dla brokera MQTT.

Important

To ustawienie wymaga zmodyfikowania zasobu brokera. Jest ona konfigurowana tylko podczas początkowego 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 rozproszonego brokera MQTT. Najważniejsze korzyści to:

  • Wydajne zarządzanie kolejkami: w brokerze MQTT każdy subskrybent jest skojarzony z kolejką komunikatów. Szybkość przetwarzania komunikatów subskrybenta bezpośrednio wpływa 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 pamięć nietrwała i służy jako miejsce na dane, które nie mieszczą się w pamięci. Dane zapisane na dysku nie są trwałe i zostają utracone po zakończeniu działania poda. Jeśli co najmniej jeden pod w każdym łańcuchu backendowym pozostanie sprawny, broker jako całość nie utraci żadnych danych.
  • Rozwiązywanie 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 Azure Event Grid z powodu rozłączenia sieci. W takich scenariuszach komunikaty typu PUBLISH gromadzą się. Broker MQTT inteligentnie buforuje te komunikaty do pamięci lub dysku do momentu przywrócenia łączności, co zapewnia integralność komunikatów.

Domyślnie funkcja buforu komunikatów opartego na dysku jest wyłączona. W takim przypadku komunikaty pozostają w pamięci, a ciśnienie wsteczne jest stosowane do klientów, gdy użycie pamięci osiągnie limit zdefiniowany przez limit kolejki subskrybenta.

Uwaga / Notatka

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.

Konfigurowanie buforu komunikatów opartego na dysku

Aby skonfigurować bufor komunikatów oparty na dysku, zmodyfikuj sekcję diskBackedMessageBuffer w zasobie brokera. Obecnie ta konfiguracja jest obsługiwana tylko przy użyciu --broker-config-file flagi podczas wdrażania Operacje Azure IoT za pomocą az iot ops create polecenia . Aby uzyskać więcej informacji, zobacz obsługę zaawansowanej konfiguracji brokera MQTT w Azure CLI.

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

Aby rozpocząć, przygotuj plik konfiguracyjny brokera, postępując zgodnie z dokumentacją referencyjną interfejsu API DiskBackedMessageBuffer.

Następnie wdróż operacje IoT za pomocą --broker-config-file flagi (inne parametry pominięte dla zwięzłości):

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

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 . Jednak ta opcja jest najmniej preferowaną opcją ze względu na ograniczenia woluminu emptyDir .

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

Aby uzyskać lepszą konfigurację bufora komunikatów korzystającego z dysku, określ wolumin efemeryczny lub żądanie woluminu trwałego, aby zamontować dedykowany wolumin pamięci masowej dla bufora komunikatów. Przykład:

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

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

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

  • Skonfiguruj wolumin: Określ szablon deklaracji woluminu, aby zamontować dedykowany wolumin pamięci masowej dla buforu komunikatów.
  • Wybierz klasę magazynu: zdefiniuj żądaną klasę storageClassName magazynu 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 temat Tryby dostępu do woluminu trwałego.

Wolumin efemeryczny

Wolumin nietrwały jest preferowaną opcją dla bufora komunikatów.

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

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

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ść właściwości persistentVolumeClaimSpec jest używana jako wartość właściwości volumeClaimTemplates.spec w specyfikacjach StatefulSet łańcuchów backendu.

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"
      ]
    }
  }
}

wolumin emptyDir

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

Użyj woluminu emptyDir tylko wtedy, gdy używasz klastra z przydziałami systemu plików. Aby uzyskać więcej informacji, zobacz kartę limitu przydziału projektu systemu plików. Jeśli ta funkcja nie jest włączona, klaster wykonuje okresowe skanowanie, które nie egzekwuje żadnego limitu, co może doprowadzić do zapełnienia przestrzeni dyskowej na węźle hosta i oznaczenia całego węzła hosta jako będącego w złym stanie.

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

Weź pod uwagę zachowanie wybranego dostawcy pamięci masowej, na przykład gdy używasz 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. To zachowanie może doprowadzić do oznaczenia przez Kubernetes węzła i wszystkich powiązanych zasobników jako niezdrowych. Ważne jest, aby zrozumieć, jak działa dostawca magazynu w takich scenariuszach.

Tip

Po określeniu efemerycznego szablonu oświadczenia woluminu (EVC) lub trwałego oświadczenia woluminu (PVC) można użyć wybranej klasy magazynu, co zwiększa elastyczność w niektórych scenariuszach wdrażania. Na przykład woluminy trwałe udostępnione przy użyciu szablonu PVC pojawiają się w wynikach poleceń, takich jak kubectl get pv, co jest przydatne podczas 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 Blob Storage. Lepiej użyć dysku lokalnego o mniejszej maxSize wartości, ponieważ bufor komunikatów korzysta z szybkiego dostępu i nie wymaga trwałości.

Wyłączony

Jeśli nie chcesz używać buforu komunikatów opartego na dysku, nie uwzględniaj właściwości diskBackedMessageBufferSettings w zasobie Broker. To zachowanie jest również domyślne.

Bufor dysku a trwałość

Bufor komunikatów oparty na dysku i mechanizm trwałości brokera zapisują dane na dysk, ale pełnią różne funkcje:

Funkcja Bufor komunikatów oparty na dysku Wytrwałość
Cel Przenoszenie kolejek subskrybentów z pamięci na dysk, gdy staną się zbyt duże Zachowanie kluczowego stanu brokera (zachowanych komunikatów, sesji, subskrypcji) podczas ponownych uruchomień poda
Durability Efemeryczny — dane są tracone, gdy zasobnik kończy działanie Trwałe — dane przetrwają ponowne uruchomienie zasobnika
Kiedy stosować Powolni subskrybenci, sesje trwałe offline, przerwy w łączności z chmurą Aby przetrwać ponowne uruchomienia brokera, musisz zachować komunikaty lub stan sesji
Zakres danych Publikowanie komunikatów w kolejkach subskrybentów Zachowywane komunikaty, metadane kolejki subskrybentów, dane magazynu stanów
Configuration diskBackedMessageBuffer w zasobie Brokera Ustawienia trwałości we wdrożeniu lub środowisku uruchomieniowym

Uwaga / Notatka

Bufor dysku i trwałość mogą być używane razem. Trwałość gwarantuje, że stan przetrwa ponowne uruchomienie, podczas gdy bufor dysku uniemożliwia brak pamięci podczas normalnego działania.

Następne kroki

  • Last updated on