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ć po awariach składników. Na przykład węzeł kończy się niepowodzeniem 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, a 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 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.

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.

Portal

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

Interfejs wiersza polecenia platformy Azure

Przygotuj plik konfiguracji brokera w formacie JSON zawierający żądane właściwości zasobu usługi Azure Resource Manager microsoft.iotoperations/instances/brokers i pamiętaj, aby pominąć cardinality pole. Na przykład ustaw tylko profil pamięci:

{
  "memoryProfile": "<MEMORY_PROFILE>"
}

Następnie wdróż operacje usługi Azure IoT przy użyciu az iot ops create polecenia z flagą --broker-config-file , podobnie jak następujące polecenie (inne parametry pominięte dla zwięzłości):

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

Aby dowiedzieć się więcej, zobacz Obsługa interfejsu wiersza polecenia platformy Azure na potrzeby zaawansowanej konfiguracji brokera MQTT.

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

Jednak nie jest to skalowanie automatyczne. Operator nie skaluje automatycznie liczby zasobników na podstawie obciążenia. Operator określa tylko początkową liczbę zasobników do wdrożenia na podstawie sprzętu klastra. Jak wspomniano wcześniej, kardynalność można ustawić tylko w czasie początkowego wdrażania, a 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.

Portal

Korzystając z poniższego przewodnika po wdrażaniu operacji usługi Azure IoT, w sekcji Konfiguracja zapoznaj się z sekcją Konfiguracja brokera MQTT. W tym miejscu można określić liczbę replik frontonu, partycji zaplecza i procesów roboczych zaplecza.

Interfejs wiersza polecenia platformy Azure

Podczas wdrażania operacji usługi Azure IoT przy użyciu az iot ops create polecenia użyj --broker-frontend-replicasparametrów , --broker-frontend-workers, --broker-backend-part, --broker-backend-rfi --broker-backend-workers , aby określić ustawienia kardynalności.

Aby na przykład określić jedną replikę frontonu, jeden proces roboczy frontonu, jedną partycję zaplecza, dwie repliki zaplecza na partycję i jeden proces roboczy zaplecza na replikę, zobacz następujące polecenie (inne parametry pominięte w celu zwięzłości):

az iot ops create ... --broker-frontend-replicas 1 --broker-frontend-workers 1  --broker-backend-part 1  --broker-backend-workers 1 --broker-backend-rf 2

Możesz też użyć flagi --broker-config-file , aby określić plik JSON zawierający ustawienia kardynalności. Przykładowy plik JSON dla tych samych ustawień:

{
  "cardinality": {
    "frontend": {
      "replicas": 1,
      "workers": 1
    },
    "backendChain": {
      "partitions": 1,
      "redundancyFactor": 2,
      "workers": 1
    }
  }
}

Następnie wdróż operacje usługi Azure IoT przy użyciu az iot ops create polecenia z flagą --broker-config-file , podobnie jak następujące polecenie (inne parametry pominięte dla zwięzłości):

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

Opis 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 to zagnieżdżone pole z polami podrzędnymi frontonu i backendChain. 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. Jednak prowadzi to również do wyższego uż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 procesor 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 procesom roboczym zaplecza na 1. Ustaw współczynnik nadmiarowości zgodnie z potrzebami (2 lub 3). Zwiększ liczbę procesów roboczych frontonu, jeśli okaże się, że procesor frontonu jest wąskim gardłem. Należy pamiętać, że pracownicy zaplecza i frontonu mogą konkurować o zasoby procesora CPU ze sobą i innymi zasobnikami.

Konfigurowanie profilu pamięci

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.

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

Portal

Korzystając z poniższego przewodnika po wdrażaniu operacji usługi Azure IoT, w sekcji Konfiguracja zapoznaj się z konfiguracją brokera MQTT i znajdź ustawienie Profil pamięci. W tym miejscu możesz wybrać z listy rozwijanej dostępne profile pamięci.

Interfejs wiersza polecenia platformy Azure

Podczas wdrażania operacji usługi Azure IoT przy użyciu polecenia użyj parametru az iot ops create --broker-mem-profile , aby określić ustawienia profilu pamięci.

Aby na przykład określić profil pamięci jako Tiny, zobacz następujące polecenie (inne parametry pominięte dla zwięzłości):

az iot ops create ... --broker-mem-profile Tiny

Aby dowiedzieć się więcej, zobacz az iot ops create parametry opcjonalne.

Istnieje kilka profilów pamięci do wyboru, z których każdy ma różne cechy użycia pamięci.

Malutki

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.

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

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.

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ż 10 MiB.

Śred.

Ś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.

Wys.

• 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.

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. Pomaga to 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 jednostki procesora CPU (1.0) 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 poniższa 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.

Portal

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

Interfejs wiersza polecenia platformy Azure

Przygotuj plik konfiguracji brokera w formacie JSON zawierający żądane właściwości zasobu usługi Azure Resource Manager microsoft.iotoperations/instances/brokers i ustaw generateResourceLimits.cpu pole na Disabledwartość . Na przykład:

{
  "generateResourceLimits": {
    "cpu": "Disabled"
  }
}

Następnie wdróż operacje usługi Azure IoT przy użyciu az iot ops create polecenia z flagą --broker-config-file , podobnie jak następujące polecenie (inne parametry pominięte dla zwięzłości):

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

Aby dowiedzieć się więcej, zobacz Obsługa interfejsu wiersza polecenia platformy Azure na potrzeby zaawansowanej konfiguracji brokera MQTT.

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 usługi Azure 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. Ułatwia to 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

W danych wyjściowych zostanie wyświetlona konfiguracja anty-koligacji, podobna do następującej:

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

Są to jedyne reguły koligacji ustawione dla brokera.

Następne kroki

• Konfigurowanie odbiorników dla brokera MQTT