Konfigurace nastavení zprostředkovatele pro vysokou dostupnost, škálování a využití paměti
Prostředek Broker 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. Mechanismy samoopravení jsou integrované do zprostředkovatele a často se můžou automaticky zotavit ze selhání komponent. Například uzel selže 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 a faktor redundance back-endu určuje počet kopií dat, které zajistí odolnost proti selhání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 a dá se nakonfigurovat pouze v počáteční době 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í Azure IoT prostřednictvím webu Azure Portal. Režim nasazení clusteru však můžete ručně zadat jako jeden uzel nebo více uzlů. Další informace najdete v tématu Nasazení operací Azure IoT.
Operátor zprostředkovatele MQTT automaticky nasadí odpovídající počet podů na základě počtu dostupných uzlů v době nasazení. To je užitečné v neprodukčních scénářích, kdy nepotřebujete vysokou dostupnost ani škálování.
Nejedná se ale o automatické škálování. Operátor automaticky škáluje počet podů na základě zatížení. Operátor určuje pouze počáteční počet podů, které se mají nasadit na základě hardwaru clusteru. Jak už jsme uvedli dříve, kardinalitu je možné nastavit pouze v počáteční době nasazení a v případě potřeby 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.
Pokud použijete průvodce nasazením operací Azure IoT, podívejte se v části Konfigurace 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ů.
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 backendChain. 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í při zvýšení počtu pracovních procesů na repliku, aby nepřekročil 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. To ale také vede k vyšší spotřebě prostředků. Proto při úpravě hodnot kardinality zvažte nastavení profilu paměti a požadavky na prostředky 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 procesoru back-endu.
Pokud má váš cluster například 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 nastavili počet pracovních procesů na 1. Nastavte počet back-endových oddílů tak, aby odpovídaly počtu uzlů (3) a back-endovým pracovníkům na 1. Nastavte faktor redundance podle potřeby (2 nebo 3). Pokud zjistíte, že front-endový procesor je kritickým bodem, 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
Důležité
Toto nastavení vyžaduje úpravu prostředku zprostředkovatele a dá se nakonfigurovat pouze v počáteční době 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 MQTT zprostředkovatele, zadejte pole profilu paměti ve specifikaci prostředku zprostředkovatele během nasazování operací Azure IoT.
Při použití následujícího průvodce nasazením operací Azure IoT v části Konfigurace vyhledejte v části Konfigurace konfiguraci zprostředkovatele MQTT a najděte nastavení profilu paměti. Tady si můžete vybrat z dostupných profilů paměti z rozevíracího seznamu.
Existuje několik profilů paměti, ze nichž si můžete vybrat, z nichž každý má různé charakteristiky využití paměti.
Maličký
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šší.
Doporučení při 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á
Při použití tohoto profilu:
- Maximální využití paměti každé front-endové repliky 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šší.
Doporučení při použití tohoto profilu:
- Je třeba použít pouze jeden nebo dva front-endy.
- Klienti by neměli posílat velké pakety. Pakety menší než 10 MiB byste měli posílat pouze.
Střední
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šší.
Vysoká
- 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šší.
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í. To pomáhá 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 aktuálně požaduje jednu jednotku procesoru (1,0) na front-endový pracovní proces a dvě jednotky procesoru (2,0) na back-endový pracovní proces. Další podrobnosti najdete v jednotkách 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 Azure 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. To 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 zobrazí 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
Jedná se o jediná pravidla proti spřažení nastavená pro zprostředkovatele.