Udostępnij za pomocą

Konfigurowanie ustawień brokera pod kątem wysokiej dostępności, skalowania i użycia pamięci

Zasób brokera to główny zasób, który definiuje ogólne ustawienia brokera MQTT. Określa również liczbę i typ zasobników, które uruchamiają konfigurację brokera, takie jak frontony i zaplecza. Za pomocą zasobu brokera można również skonfigurować jego profil pamięci. Mechanizmy samonaprawiania są wbudowane w brokera i często mogą automatycznie odzyskiwać dane po awariach składników. Przykładem może być awaria węzła w klastrze Kubernetes skonfigurowanym pod kątem wysokiej dostępności.

Broker MQTT można skalować w poziomie, dodając więcej replik frontonu i partycji zaplecza. Repliki frontonu są odpowiedzialne za akceptowanie połączeń MQTT od klientów i przekazywanie ich do partycji zaplecza. Partycje zaplecza są odpowiedzialne za przechowywanie i dostarczanie komunikatów do klientów. Zasobniki frontonu dystrybuują ruch komunikatów między zasobnikami zaplecza. Współczynnik nadmiarowości zaplecza określa liczbę kopii danych w celu zapewnienia odporności na awarie węzłów w klastrze.

Aby uzyskać listę dostępnych ustawień, zobacz dokumentację interfejsu API brokera .

Konfigurowanie ustawień skalowania

Ważne

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.

Aby skonfigurować ustawienia skalowania brokera MQTT, określ pola kardynalności w specyfikacji zasobu brokera podczas wdrażania operacji usługi Azure IoT.

Kardynalność wdrażania automatycznego

Aby automatycznie określić początkową kardynalność podczas wdrażania, pomiń pole kardynalności w zasobie brokera.

Automatyczna kardynalność nie jest jeszcze obsługiwana podczas wdrażania operacji IoT za pośrednictwem witryny Azure Portal. Tryb wdrażania klastra można określić ręcznie jako pojedynczy węzeł lub wiele węzłów. Aby dowiedzieć się więcej, zobacz Wdrażanie operacji usługi Azure IoT.

Zrzut ekranu pokazujący, gdzie wybrać konfigurację z jednym lub wieloma węzłami w witrynie Azure Portal.

Operator brokera MQTT automatycznie wdraża odpowiednią liczbę zasobników na podstawie liczby dostępnych węzłów w momencie wdrożenia. Ta funkcja jest przydatna w scenariuszach nieprodukcyjnych, w których nie potrzebujesz wysokiej dostępności ani skali.

Ta funkcja nie jest skalowaniem automatycznym. Operator nie skaluje automatycznie liczby zasobników na podstawie obciążenia. Operator określa początkową liczbę zasobników do wdrożenia tylko na podstawie sprzętu klastra. Jak wspomniano wcześniej, kardynalność jest ustawiana tylko w początkowym czasie wdrażania. Nowe wdrożenie jest wymagane, jeśli należy zmienić ustawienia kardynalności.

Konfigurowanie kardynalności bezpośrednio

Aby skonfigurować ustawienia kardynalności bezpośrednio, określ każde z pól kardynalności.

Po zapoznaniu się z przewodnikiem wdrażania operacji IoT w sekcji Konfiguracja zapoznaj się z konfiguracją brokera MQTT. W tym miejscu można określić liczbę replik frontonu, partycji zaplecza i procesów roboczych zaplecza.

Zrzut ekranu pokazujący, gdzie skonfigurować kardynalność brokera bezpośrednio w witrynie Azure Portal.

Omówienie kardynalności

Kardynalność oznacza liczbę wystąpień określonej jednostki w zestawie. W kontekście brokera MQTT kardynalność odnosi się do liczby replik frontonu, partycji zaplecza i procesów roboczych zaplecza do wdrożenia. Ustawienia kardynalności są używane do skalowania brokera w poziomie i poprawy wysokiej dostępności, jeśli występują błędy zasobnika lub węzła.

Pole kardynalności jest polem zagnieżdżonym z polami podrzędnymi frontonu i łańcucha zaplecza. Każde z tych pól podrzędnych ma własne ustawienia.

Fronton

Podpole frontonu definiuje ustawienia zasobników frontonu. Dwa główne ustawienia to:

  • Repliki: liczba replik frontonu (zasobników) do wdrożenia. Zwiększenie liczby replik frontonu zapewnia wysoką dostępność w przypadku awarii jednego z zasobników frontonu.
  • Procesy robocze: liczba logicznych procesów roboczych frontonu na replikę. Każdy proces roboczy może zużywać maksymalnie jeden rdzeń procesora CPU.

Łańcuch zaplecza

Podpole łańcucha zaplecza definiuje ustawienia partycji zaplecza. Trzy główne ustawienia to:

  • Partycje: liczba partycji do wdrożenia. W ramach procesu nazywanego fragmentowaniem każda partycja jest odpowiedzialna za część komunikatów podzieloną przez identyfikator tematu i identyfikator sesji. Zasobniki frontonu dystrybuują ruch komunikatów między partycjami. Zwiększenie liczby partycji zwiększa liczbę komunikatów, które może obsłużyć broker.
  • Współczynnik nadmiarowości: liczba replik zaplecza (zasobników) do wdrożenia na partycję. Zwiększenie współczynnika nadmiarowości zwiększa liczbę kopii danych w celu zapewnienia odporności na awarie węzłów w klastrze.
  • Procesy robocze: liczba procesów roboczych do wdrożenia na replikę zaplecza. Zwiększenie liczby procesów roboczych na replikę zaplecza może zwiększyć liczbę komunikatów obsługiwanych przez zasobnik zaplecza. Każdy proces roboczy może zużywać maksymalnie dwa rdzenie procesora CPU, dlatego należy zachować ostrożność podczas zwiększania liczby procesów roboczych na replikę, aby nie przekraczać liczby rdzeni procesora CPU w klastrze.

Kwestie wymagające rozważenia

Po zwiększeniu wartości kardynalności pojemność brokera do obsługi większej liczby połączeń i komunikatów zwykle poprawia się i zwiększa wysoką dostępność, jeśli występują błędy zasobnika lub węzła. Ta zwiększona pojemność prowadzi również do większego zużycia zasobów. Dlatego podczas dostosowywania wartości kardynalności należy wziąć pod uwagę ustawienia profilu pamięci i żądania zasobów procesora CPU brokera. Zwiększenie liczby procesów roboczych na replikę frontonu może pomóc zwiększyć wykorzystanie rdzeni procesora CPU, jeśli okaże się, że wykorzystanie procesora CPU frontonu jest wąskim gardłem. Zwiększenie liczby procesów roboczych zaplecza może pomóc w przepływności komunikatów, jeśli wykorzystanie procesora CPU zaplecza jest wąskim gardłem.

Jeśli na przykład klaster ma trzy węzły, z których każdy ma osiem rdzeni procesora CPU, ustaw liczbę replik frontonu tak, aby odpowiadał liczbie węzłów (3) i ustawić liczbę procesów roboczych na 1. Ustaw liczbę partycji zaplecza tak, aby odpowiadała liczbie węzłów (3) i ustaw dla procesów roboczych zaplecza wartość 1. Ustaw odpowiedni współczynnik nadmiarowości (2 lub 3). Zwiększ liczbę procesów roboczych frontonu, jeśli okaże się, że wykorzystanie procesora CPU frontonu jest wąskim gardłem. Należy pamiętać, że procesy robocze zaplecza i frontonu mogą konkurować o zasoby procesora CPU ze sobą i innymi zasobnikami.

Konfigurowanie profilu pamięci

Profil pamięci określa użycie pamięci brokera dla środowisk ograniczonych zasobami. Możesz wybrać spośród wstępnie zdefiniowanych profilów pamięci, które mają różne cechy użycia pamięci. Ustawienie profilu pamięci służy do konfigurowania użycia pamięci replik frontendu i zaplecza. Profil pamięci współdziała z ustawieniami kardynalności, aby określić całkowite użycie pamięci brokera.

Ważne

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.

Aby skonfigurować ustawienia profilu pamięci brokera MQTT, określ pola profilu pamięci w specyfikacji zasobu brokera podczas wdrażania operacji IoT.

Jeśli używasz poniższego przewodnika do wdrażania operacji IoT, w sekcji Konfiguracja zapoznaj się z konfiguracjąbrokera MQTT i znajdź ustawienie Profilu pamięci. W tym miejscu możesz wybrać z dostępnych profilów pamięci na liście rozwijanej.

Zrzut ekranu pokazujący, gdzie skonfigurować profil pamięci w witrynie Azure Portal.

Istnieją wstępnie zdefiniowane profile pamięci o różnych cechach użycia pamięci do publikowania komunikatów. Nie ma limitu liczby sesji ani subskrypcji, które broker może obsłużyć. Profil pamięci zarządza tylko użyciem pamięci dla ruchu PUBLISH.

Malutki

Użyj tego profilu, gdy masz ograniczone zasoby pamięci, a ruch publikowania klienta jest niski.

W przypadku korzystania z tego profilu:

  • Maksymalne użycie pamięci dla każdej repliki frontonu wynosi około 99 miB, ale rzeczywiste maksymalne użycie pamięci może być wyższe.
  • Maksymalne użycie pamięci dla każdej repliki zaplecza wynosi około 102 MiB pomnożone przez liczbę procesów roboczych zaplecza, ale rzeczywiste maksymalne użycie pamięci może być wyższe.
  • Maksymalny rozmiar komunikatu to 4 MB.
  • Maksymalny rozmiar buforu przychodzącego dla danych PUBLISH wynosi około 16 MiB na pracownika serwera. Jednak skuteczny rozmiar może być niższy z powodu mechanizmów wstecznych, które aktywują się, gdy bufor osiągnie 75% pojemności, co powoduje, że rozmiar buforu wynosi około 12 MiB. Odrzucone pakiety mają odpowiedź PUBACK z kodem błędu Przekroczono limit przydziału.

Zalecenia dotyczące korzystania z tego profilu:

  • Należy używać tylko jednego frontonu.
  • Klienci nie powinni wysyłać dużych pakietów. Należy wysyłać tylko pakiety mniejsze niż 4 MiB.

Niski

Użyj tego profilu, gdy masz ograniczone zasoby pamięci i klienci publikują małe pakiety.

W przypadku korzystania z tego profilu:

  • Maksymalne użycie pamięci dla każdej repliki frontonu wynosi około 387 MiB, ale rzeczywiste maksymalne użycie pamięci może być wyższe.
  • Maksymalne użycie pamięci każdej repliki zaplecza wynosi około 390 MiB pomnożone przez liczbę procesów roboczych zaplecza, ale rzeczywiste maksymalne użycie pamięci może być wyższe.
  • Maksymalny rozmiar komunikatu to 16 MB.
  • Maksymalny rozmiar buforu przychodzącego dla danych PUBLISH wynosi około 64 MiB na pracownika końcowego. Jednak skuteczny rozmiar może być niższy z powodu mechanizmów backpressure, które aktywują się, gdy bufor osiągnie 75% pojemności, co spowoduje, że rozmiar buforu wyniesie około 48 MiB. Odrzucone pakiety mają odpowiedź PUBACK z kodem błędu Przekroczono limit przydziału.

Zalecenia dotyczące korzystania z tego profilu:

  • Należy użyć tylko jednego lub dwóch frontonów.
  • Klienci nie powinni wysyłać dużych pakietów. Należy wysyłać tylko pakiety mniejsze niż 16 MiB.

Śred.

Użyj tego profilu, jeśli musisz obsługiwać umiarkowaną liczbę komunikatów klienta.

Średni to profil domyślny.

  • Maksymalne użycie pamięci dla każdej repliki frontonu wynosi około 1,9 GiB, ale rzeczywiste maksymalne użycie pamięci może być wyższe.
  • Maksymalne użycie pamięci każdej repliki zaplecza wynosi około 1,5 GiB pomnożone przez liczbę procesów roboczych zaplecza, ale rzeczywiste maksymalne użycie pamięci może być wyższe.
  • Maksymalny rozmiar komunikatu to 64 MB.
  • Maksymalny rozmiar buforu danych PUBLISH przychodzących wynosi około 576 MiB na pracownika zaplecza. Jednak skuteczny rozmiar może być niższy z powodu mechanizmów przeciążeniowych, które aktywują się, gdy bufor osiągnie 75% pojemności, w wyniku czego rozmiar bufora wynosi około 432 MiB. Odrzucone pakiety mają odpowiedź PUBACK z kodem błędu Przekroczono limit przydziału.

Wys.

Użyj tego profilu, jeśli musisz obsługiwać dużą liczbę komunikatów klienta.

  • Maksymalne użycie pamięci dla każdej repliki frontonu wynosi około 4,9 GiB, ale rzeczywiste maksymalne użycie pamięci może być wyższe.
  • Maksymalne użycie pamięci każdej repliki zaplecza wynosi około 5,8 GiB pomnożone przez liczbę procesów roboczych zaplecza, ale rzeczywiste maksymalne użycie pamięci może być wyższe.
  • Maksymalny rozmiar komunikatu to 256 MB.
  • Maksymalny rozmiar buforu przychodzącego dla danych PUBLISH wynosi około 2 GiB na proces roboczy zaplecza. Jednak skuteczny rozmiar może być niższy z powodu mechanizmów wstecznego nacisku, które aktywują się, gdy bufor osiągnie 75% pojemności%, co powoduje, że rozmiar buforu wynosi około 1,5 GiB. Odrzucone pakiety mają odpowiedź PUBACK z kodem błędu Przekroczono limit przydziału.

Obliczanie całkowitego użycia pamięci

Ustawienie profilu pamięci określa użycie pamięci dla każdej repliki frontendu i backendu oraz oddziałuje z ustawieniami kardynalności. Łączne użycie pamięci można obliczyć przy użyciu formuły:

M_total = R_fe * M_fe + (P_be * RF_be) * M_be * W_be

Gdzie:

Zmienna Opis
M_total Łączne użycie pamięci
R_fe Liczba replik frontonu
M_fe Użycie pamięci każdej repliki frontonu
P_be Liczba partycji backendowych
RF_be Współczynnik nadmiarowości zaplecza
M_be Użycie pamięci każdej repliki zaplecza
W_be Liczba pracowników na replikę backendu

Jeśli na przykład wybierzesz profil Średniej pamięci, profil ma użycie pamięci frontonu w wysokości 1,9 GB i użycie pamięci zaplecza w wysokości 1,5 GB. Załóżmy, że konfiguracja brokera obejmuje 2 repliki frontendowe, 2 partycje backendowe i współczynnik redundancji backendu wynoszący 2. Łączne użycie pamięci wynosi:

2 * 1,9 GB + (2 * 2) * 1,5 GB * 2 = 15,8 GB

Dla porównania profil tiny pamięci ma użycie pamięci frontonu 99 MiB i pamięci zaplecza 102 MiB. Zakładając tę samą konfigurację brokera, łączne użycie pamięci wynosi:

2 * 99 MB + (2 * 2) * 102 MB * 2 = 198 MB + 816 MB = 1,014 GB.

Ważne

Broker MQTT rozpoczyna odrzucanie komunikatów, gdy pamięć jest 75% pełna.

Kardynalność i limity zasobów platformy Kubernetes

Aby zapobiec głodu zasobów w klastrze, broker jest domyślnie skonfigurowany do żądania limitów zasobów procesora KUBernetes. Skalowanie liczby replik lub procesów roboczych proporcjonalnie zwiększa wymagane zasoby procesora CPU. Błąd wdrożenia jest emitowany, jeśli w klastrze są niewystarczające zasoby procesora CPU. To powiadomienie pomaga uniknąć sytuacji, w których żądana kardynalność brokera nie ma wystarczającej ilości zasobów do optymalnego uruchomienia. Pomaga również uniknąć potencjalnego rywalizacji o procesor i eksmisji zasobników.

Broker MQTT obecnie żąda jednej (1,0) jednostki procesora CPU na proces roboczy frontonu i dwóch (2,0) jednostek procesora CPU na proces roboczy zaplecza. Aby uzyskać więcej informacji, zobacz Jednostki zasobów procesora CPU platformy Kubernetes.

Na przykład następująca kardynalność zażąda następujących zasobów procesora CPU:

  • W przypadku frontonów: 2 jednostki procesora CPU na zasobnik frontonu, łącznie 6 jednostek procesora CPU.
  • W przypadku zapleczy: 4 jednostki procesora CPU na zasobnik zaplecza (dla dwóch procesów roboczych zaplecza), razy 2 (współczynnik nadmiarowości), 3 (liczba partycji), łącznie 24 jednostki procesora CPU.
{
  "cardinality": {
    "frontend": {
      "replicas": 3,
      "workers": 2
    },
    "backendChain": {
      "partitions": 3,
      "redundancyFactor": 2,
      "workers": 2
    }
  }
}

Aby wyłączyć to ustawienie, ustaw generateResourceLimits.cpu pole na Disabled wartość w zasobie Broker.

generateResourceLimits Zmiana pola nie jest obsługiwana w witrynie Azure Portal. Aby wyłączyć to ustawienie, użyj interfejsu wiersza polecenia platformy Azure.

Wdrażanie z wieloma węzłami

Aby zapewnić wysoką dostępność i odporność przy użyciu wdrożeń obejmujących wiele węzłów, broker MQTT operacji IoT automatycznie ustawia reguły koligacji dla zasobników zaplecza.

Te reguły są wstępnie zdefiniowane i nie można ich modyfikować.

Przeznaczenie reguł anty-koligacji

Reguły ochrony przed koligacją zapewniają, że zasobniki zaplecza z tej samej partycji nie są uruchamiane w tym samym węźle. Ta funkcja ułatwia rozłożenie obciążenia i zapewnia odporność na awarie węzłów. W szczególności zasobniki zaplecza z tej samej partycji mają anty-koligację ze sobą.

Weryfikowanie ustawień anty-koligacji

Aby sprawdzić ustawienia ochrony przed koligacją dla zasobnika zaplecza, użyj następującego polecenia:

kubectl get pod aio-broker-backend-1-0 -n azure-iot-operations -o yaml | grep affinity -A 15

Dane wyjściowe przedstawiają konfigurację anty-koligacji, podobnie jak w poniższym przykładzie:

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: chain-number
            operator: In
            values:
            - "1"
        topologyKey: kubernetes.io/hostname
      weight: 100

Te reguły są jedynymi regułami koligacji ustawionymi dla brokera.

Treści powiązane

  • Last updated on