Sdílet prostřednictvím

Konfigurace nastavení zprostředkovatele pro vysokou dostupnost, škálování a využití paměti

Prostředek zprostředkovatele je hlavní prostředek, který definuje celkové nastavení pro zprostředkovatele MQTT. Určuje také počet a typ podů, které spouští konfiguraci zprostředkovatele, jako jsou front-endy a back-endy. Prostředek zprostředkovatele můžete také použít ke konfiguraci profilu paměti. Mechanismus samoopravení je integrovaný do zprostředkovatele a často se může automaticky zotavit ze selhání komponent. Příkladem je selhání uzlu v clusteru Kubernetes nakonfigurovaného pro zajištění vysoké dostupnosti.

Zprostředkovatele MQTT můžete horizontálně škálovat přidáním dalších front-endových replik a back-endových oddílů. Front-endové repliky zodpovídají za přijímání připojení MQTT od klientů a jejich předávání do back-endových oddílů. Back-endové oddíly zodpovídají za ukládání a doručování zpráv klientům. Front-endové pody distribuují provoz zpráv mezi back-endové pody. Faktor redundance back-endu určuje počet kopií dat, které zajistí odolnost proti chybám uzlů v clusteru.

Seznam dostupných nastavení najdete v referenčních informacích k rozhraní API zprostředkovatele .

Konfigurace nastavení škálování

Důležité

Toto nastavení vyžaduje úpravu prostředku zprostředkovatele. Konfiguruje se pouze při počátečním nasazení pomocí Azure CLI nebo webu Azure Portal. Pokud jsou potřeba změny konfigurace zprostředkovatele, vyžaduje se nové nasazení. Další informace najdete v tématu Přizpůsobení výchozího zprostředkovatele.

Pokud chcete nakonfigurovat nastavení škálování zprostředkovatele MQTT, zadejte pole kardinality ve specifikaci prostředku zprostředkovatele během nasazování operací Azure IoT.

Kardinalita automatického nasazení

Chcete-li automaticky určit počáteční kardinalitu během nasazení, v prostředku zprostředkovatele vy vynecháte pole kardinality.

Automatická kardinalita se zatím nepodporuje při nasazování operací IoT prostřednictvím webu Azure Portal. Režim nasazení clusteru můžete ručně zadat jako jeden uzel nebo více uzlů. Další informace najdete v tématu Nasazení operací Azure IoT.

Snímek obrazovky znázorňující, kde vybrat nastavení s jedním nebo více uzly na webu Azure Portal

Operátor zprostředkovatele MQTT automaticky nasadí odpovídající počet podů na základě počtu dostupných uzlů v době nasazení. Tato funkce je užitečná pro neprodukční scénáře, kdy nepotřebujete vysokou dostupnost ani škálování.

Tato funkce není automatické škálování. Operátor automaticky škáluje počet podů na základě zatížení. Operátor určuje počáteční počet podů, které se mají nasadit pouze na základě hardwaru clusteru. Jak jsme si poznamenali dříve, kardinalita se nastavuje jenom v počáteční době nasazení. Pokud je potřeba změnit nastavení kardinality, je potřeba nové nasazení.

Přímá konfigurace kardinality

Pokud chcete nakonfigurovat nastavení kardinality přímo, zadejte všechna pole kardinality.

Když budete postupovat podle průvodce nasazením operací IoT, v části Konfigurace se podívejte do konfigurace zprostředkovatele MQTT. Tady můžete zadat počet front-endových replik, back-endových oddílů a back-endových pracovních procesů.

Snímek obrazovky znázorňující, kde nakonfigurovat kardinalitu zprostředkovatele přímo na webu Azure Portal

Principy kardinality

Kardinalita znamená počet instancí konkrétní entity v sadě. V kontextu zprostředkovatele MQTT kardinalita odkazuje na počet front-endových replik, back-endových oddílů a back-endových pracovních procesů, které se mají nasadit. Nastavení kardinality se používají k horizontálnímu škálování zprostředkovatele a ke zlepšení vysoké dostupnosti v případě selhání podu nebo uzlů.

Pole kardinality je vnořené pole s dílčími poli pro front-end a back-endový řetězec. Každé z těchto dílčích polí má vlastní nastavení.

Front-end

Front-endové dílčí pole definuje nastavení pro front-endové pody. Mezi dvě hlavní nastavení patří:

  • Repliky: Počet front-endových replik (podů) k nasazení. Zvýšení počtu front-endových replik poskytuje vysokou dostupnost v případě selhání jednoho z podů front-endu.
  • Pracovní procesy: Počet logických front-endových pracovních procesů na repliku. Každý pracovní proces může využívat maximálně jedno jádro procesoru.

Back-endový řetězec

Dílčí pole back-endového řetězce definuje nastavení back-endových oddílů. Tři hlavní nastavení jsou:

  • Oddíly: Počet oddílů, které se mají nasadit. Prostřednictvím procesu označovaného jako horizontální dělení zodpovídá každý oddíl za část zpráv vydělený ID tématu a ID relace. Front-endové pody distribuují provoz zpráv napříč oddíly. Zvýšení počtu oddílů zvyšuje počet zpráv, které může zprostředkovatel zpracovat.
  • Faktor redundance: Počet replik back-endu (podů) k nasazení na oddíl. Zvýšení faktoru redundance zvyšuje počet kopií dat, aby se zajistila odolnost proti chybám uzlů v clusteru.
  • Pracovní procesy: Počet pracovních procesů, které se mají nasadit na back-endovou repliku. Zvýšení počtu pracovních procesů na repliku back-endu může zvýšit počet zpráv, které může back-endový pod zpracovat. Každý pracovní proces může maximálně spotřebovávat až dvě jádra procesoru, proto buďte opatrní, když zvýšíte počet pracovních procesů na repliku, abyste nepřekročili počet jader procesoru v clusteru.

Důležité informace

Když zvětšíte hodnoty kardinality, kapacita zprostředkovatele pro zpracování většího počtu připojení a zpráv se obecně zlepšuje a zvyšuje vysokou dostupnost v případě selhání podu nebo uzlu. Tato zvýšená kapacita také vede k vyšší spotřebě prostředků. Při úpravě hodnot kardinality zvažte nastavení profilu paměti a požadavky prostředků procesoru zprostředkovatele. Zvýšení počtu pracovních procesů na repliku front-endu může pomoct zvýšit využití jader procesoru, pokud zjistíte, že využití procesoru front-endu je kritickým bodem. Zvýšení počtu back-endových pracovních procesů může pomoct s propustností zpráv, pokud je kritickým bodem využití procesoru back-endu.

Pokud má například váš cluster tři uzly, každý s osmi jádry procesoru, nastavte počet front-endových replik tak, aby odpovídal počtu uzlů (3) a nastavte počet pracovních procesů na 1. Nastavte počet back-endových oddílů tak, aby odpovídaly počtu uzlů (3) a nastavte back-endové pracovní procesy na 1. Nastavte faktor redundance podle potřeby (2 nebo 3). Pokud zjistíte, že využití procesoru front-endu představuje kritický bod, zvyšte počet front-endových pracovních procesů. Mějte na paměti, že back-endové a front-endové pracovní procesy můžou vzájemně soutěžit o prostředky procesoru a další pody.

Konfigurace profilu paměti

Profil paměti určuje využití paměti zprostředkovatele pro prostředí s omezenými prostředky. Můžete si vybrat z předdefinovaných profilů paměti, které mají různé charakteristiky využití paměti. Nastavení profilu paměti slouží ke konfiguraci využití paměti front-endových a back-endových replik. Profil paměti komunikuje s nastavením kardinality a určuje celkové využití paměti zprostředkovatele.

Důležité

Toto nastavení vyžaduje, abyste upravili prostředek zprostředkovatele. Konfiguruje se pouze při počátečním nasazení pomocí Azure CLI nebo webu Azure Portal. Pokud jsou potřeba změny konfigurace zprostředkovatele, vyžaduje se nové nasazení. Další informace najdete v tématu Přizpůsobení výchozího zprostředkovatele.

Chcete-li nakonfigurovat nastavení profilu paměti zprostředkovatele MQTT, zadejte pole profilu paměti ve specifikaci prostředku zprostředkovatele během nasazení operací IoT.

Pokud k nasazení operací IoT použijete následující průvodce, v části Konfigurace vyhledejte konfiguraci zprostředkovatele MQTT a najděte nastavení profilu paměti. Tady si můžete vybrat z dostupných profilů paměti v rozevíracím seznamu.

Snímek obrazovky znázorňující, kde nakonfigurovat profil paměti na webu Azure Portal

Existují předdefinované profily paměti s různými charakteristikami využití paměti pro publikování zpráv. Počet relací nebo předplatných, které může zprostředkovatel zpracovat, není omezený. Profil paměti řídí pouze využití paměti pro provoz publikování.

Maličký

Tento profil použijte, pokud máte omezené prostředky paměti a publikační provoz klienta je nízký.

Při použití tohoto profilu:

  • Maximální využití paměti každé repliky front-endu je přibližně 99 MiB, ale skutečné maximální využití paměti může být vyšší.
  • Maximální využití paměti každé repliky back-endu je přibližně 102 MiB vynásobené počtem pracovních procesů back-endu, ale skutečné maximální využití paměti může být vyšší.
  • Maximální velikost zprávy je 4 MB.
  • Maximální velikost příchozí vyrovnávací paměti pro data PUBLISH je přibližně 16 MiB na backendového pracovníka. Efektivní velikost však může být nižší kvůli mechanismům zpětného tlaku, které se aktivují, když vyrovnávací paměť dosáhne 75% kapacity, což vede k velikosti vyrovnávací paměti přibližně 12 MiB. Odmítnuté pakety mají odpověď PUBACK s kódem chyby Překročení kvóty .

Doporučení pro použití tohoto profilu:

  • Použít by se měl jenom jeden front-end.
  • Klienti by neměli posílat velké pakety. Pakety byste měli posílat jenom menší než 4 MiB.

Nízká

Tento profil použijte, pokud máte omezené prostředky paměti a klienti publikují malé pakety.

Při použití tohoto profilu:

  • Maximální využití paměti každé repliky front-endu je přibližně 387 MiB, ale skutečné maximální využití paměti může být vyšší.
  • Maximální využití paměti každé back-endové repliky je přibližně 390 MiB vynásobené počtem pracovních procesů back-endu, ale skutečné maximální využití paměti může být vyšší.
  • Maximální velikost zprávy je 16 MB.
  • Maximální velikost příchozí vyrovnávací paměti pro data PUBLISH je přibližně 64 MiB na backendového pracovníka. Efektivní velikost však může být nižší kvůli mechanismům zpětného tlaku, které se aktivují, když vyrovnávací paměť dosáhne 75% kapacity, což vede k velikosti vyrovnávací paměti přibližně 48 MiB. Odmítnuté pakety mají odpověď PUBACK s kódem chyby Překročení kvóty .

Doporučení pro použití tohoto profilu:

  • Je třeba použít pouze jeden nebo dva front-endy.
  • Klienti by neměli posílat velké pakety. Pakety byste měli odesílat jenom menší než 16 MiB.

Střední

Tento profil použijte, když potřebujete zpracovat střední počet klientských zpráv.

Střední je výchozí profil.

  • Maximální využití paměti každé front-endové repliky je přibližně 1,9 GiB, ale skutečné maximální využití paměti může být vyšší.
  • Maximální využití paměti každé repliky back-endu je přibližně 1,5 GiB vynásobené počtem back-endových pracovních procesů, ale skutečné maximální využití paměti může být vyšší.
  • Maximální velikost zprávy je 64 MB.
  • Maximální velikost příchozí vyrovnávací paměti pro data PUBLISH je přibližně 576 MiB na pracovníka na pozadí. Efektivní velikost však může být nižší kvůli mechanismům zpětného tlaku, které se aktivují, když vyrovnávací paměť dosáhne 75% kapacity, což vede k velikosti vyrovnávací paměti přibližně 432 MiB. Odmítnuté pakety mají odpověď PUBACK s kódem chyby Překročení kvóty .

Vysoká

Tento profil použijte, když potřebujete zpracovat velký počet klientských zpráv.

  • Maximální využití paměti každé repliky front-endu je přibližně 4,9 GiB, ale skutečné maximální využití paměti může být vyšší.
  • Maximální využití paměti každé back-endové repliky je přibližně 5,8 GiB vynásobené počtem back-endových pracovních procesů, ale skutečné maximální využití paměti může být vyšší.
  • Maximální velikost zprávy je 256 MB.
  • Maximální velikost příchozí vyrovnávací paměti pro data PUBLISH je přibližně 2 GiB na každého backendového pracovníka. Efektivní velikost však může být nižší kvůli mechanismům zpětného tlaku, které se aktivují, když vyrovnávací paměť dosáhne 75% kapacity, což vede k velikosti vyrovnávací paměti přibližně 1,5 GiB. Odmítnuté pakety mají odpověď PUBACK s kódem chyby Překročení kvóty .

Výpočet celkového využití paměti

Nastavení profilu paměti určuje využití paměti pro každou front-endovou a back-endovou repliku a komunikuje s nastavením kardinality. Celkové využití paměti můžete vypočítat pomocí vzorce:

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

Kde:

Proměnná Popis
M_total Celkové využití paměti
R_fe Počet frontendových replik
M_fe Využití paměti každé front-endové repliky
P_be Počet backendových částí
RF_be Faktor redundance zásobníku
M_be Využití paměti každé back-endové repliky
W_be Počet pracovníků na repliku back endu

Pokud například zvolíte profil střední paměti, má profil využití front-endové paměti 1,9 GB a využití back-endové paměti 1,5 GB. Předpokládejme, že konfigurace zprostředkovatele je 2 frontendové repliky, 2 backendové oddíly a redundanční faktor backendu 2. Celkové využití paměti je:

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

Ve srovnání s profilem malé paměti má front-endové využití paměti 99 MiB a využití back-endové paměti 102 MiB. Pokud předpokládáte stejnou konfiguraci zprostředkovatele, celkové využití paměti je:

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

Důležité

Zprostředkovatel MQTT začne odmítat zprávy, když je paměť 75% plná.

Omezení prostředků Kardinalita a Kubernetes

Aby se zabránilo hladovění prostředků v clusteru, je zprostředkovatel ve výchozím nastavení nakonfigurovaný tak, aby požadoval omezení prostředků procesoru Kubernetes. Škálování počtu replik nebo pracovních procesů úměrně zvyšuje požadované prostředky procesoru. Pokud v clusteru není k dispozici dostatek prostředků procesoru, vygeneruje se chyba nasazení. Toto oznámení vám pomůže vyhnout se situacím, kdy požadovaná kardinalita zprostředkovatele nemá dostatek prostředků pro optimální spuštění. Pomáhá také vyhnout se potenciálním kolizím procesoru a vyřazení podů.

Zprostředkovatel MQTT v současné době požaduje jednu (1,0) jednotku procesoru na front-endový pracovní proces a dvě jednotky procesoru (2,0) na back-endový pracovní proces. Další informace najdete v tématu Jednotky prostředků procesoru Kubernetes.

Například následující kardinalita by požadovala následující prostředky procesoru:

  • Pro front-endy: 2 jednotky procesoru na pod front-endu, celkem 6 jednotek procesoru.
  • Pro back-endy: 4 jednotky procesoru na pod back-endu (pro dva back-endové pracovní procesy), krát 2 (faktor redundance), krát 3 (počet oddílů), celkem 24 jednotek procesoru.
{
  "cardinality": {
    "frontend": {
      "replicas": 3,
      "workers": 2
    },
    "backendChain": {
      "partitions": 3,
      "redundancyFactor": 2,
      "workers": 2
    }
  }
}

Pokud chcete toto nastavení zakázat, nastavte generateResourceLimits.cpu pole v Disabled prostředku zprostředkovatele.

generateResourceLimits Změna pole není na webu Azure Portal podporovaná. Pokud chcete toto nastavení zakázat, použijte Azure CLI.

Nasazení s více uzly

Aby se zajistila vysoká dostupnost a odolnost při nasazeních s více uzly, zprostředkovatel IoT Operations MQTT automaticky nastaví pravidla spřažení pro back-endové pody.

Tato pravidla jsou předdefinovaná a nelze je upravit.

Účel pravidel ochrany proti spřažení

Pravidla ochrany proti spřažení zajišťují, že back-endové pody ze stejného oddílu neběží na stejném uzlu. Tato funkce pomáhá distribuovat zatížení a poskytuje odolnost proti selháním uzlů. Konkrétně back-endové pody ze stejného oddílu mají protispřažení mezi sebou.

Ověření nastavení spřažení

K ověření nastavení spřažení back-endového podu použijte následující příkaz:

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

Výstup ukazuje konfiguraci spřažení, podobně jako v následujícím příkladu:

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

Tato pravidla jsou jediná pravidla proti spřažení nastavená pro zprostředkovatele.

Související obsah

  • Last updated on