Antipattern okolního protokolu přes vysokou úroveň
Víceklientské systémy sdílejí prostředky mezi klienty. To znamená, že aktivita jednoho tenanta může mít negativní dopad na použití systému jiného tenanta.
Popis problému
Když vytváříte službu, kterou chcete sdílet s více zákazníky nebo klienty, můžete ji sestavit, aby byla víceklientské. Výhodou víceklientské systémů je, že prostředky je možné ve fondu a sdílet mezi klienty. To často vede ke snížení nákladů a lepší efektivity. Pokud však jeden tenant používá neúměrný objem prostředků dostupných v systému, může to mít za následek celkový výkon systému. K problému s vysokou dostupností sousedů dochází, když je u jednoho tenanta snížen výkon z důvodu aktivit jiného tenanta.
Vezměte v úvahu ukázkový víceklientské systém se dvěma klienty. Vzorce využití a vzory využití tenanta B se shodují, což znamená, že v časech špičky je celkové využití prostředků vyšší než kapacita systému:
Je pravděpodobnější, že bude mít přednost jeho přijatý požadavek, a druhý tenant bude mít problémy s okolním sousedem. Případně můžou oba klienti najít svůj výkon.
K problému s vysokou dostupností sousedů dochází i v případě, že každý jednotlivec pracuje s relativně malým množstvím kapacity systému, ale kolektivní využití prostředků mnoha tenantů má za následek nejvyšší využití ve špičce:
K tomu může dojít, když máte více tenantů, které mají podobné vzorce používání, nebo kde jste nezřídili dostatečnou kapacitu pro kolektivní zatížení systému.
Jak problém vyřešit
Problémy s hlučnými sousedními systémy jsou v rámci víceklientské architektury podstatou rizikou a není možné úplně eliminovat možnost ovlivnění sousedním směrovačem s vysokou pravděpodobností. Existují však některé kroky, které mohou oba klienti i poskytovatelé služeb snížit pravděpodobnost problémů s navýšení sousedního zpomalení nebo zmírnit jejich účinky, když jsou pozorovány.
Akce, které mohou klienti provádět
- Koupit rezervovanou kapacitu, je-li k dispozici. například při použití Cosmos DB, zakoupení rezervované propustnostia při použití ExpressRoute můžete zřídit samostatné okruhy pro prostředí, která jsou citlivá na výkon.
- Migrujte na jednu instanci služby nebo na úroveň služby se silnějšími zárukami izolace. například při použití Service Bus, migraci na úroveň premiuma při použití Azure Cache pro Redis, zřiďte mezipaměť úrovně standard nebo premium.
- Ujistěte se, že vaše aplikace zpracovává omezování služby, aby se snížilo poskytování zbytečných požadavků na službu.
Akce, které mohou poskytovatelé služeb provádět
- Monitorujte využití prostředků pro váš systém, a to celkově i pro každého tenanta. Nakonfigurujte výstrahy pro detekci špiček využití prostředků a pokud je to možné, nakonfigurujte automatizaci tak, aby automaticky zmírnila známé problémy pomocí vertikálního navýšeníkapacity.
- Použijte zásady správného řízení prostředků, abyste se vyhnuli jednomu klientovi, který zahlcen systém a snížili kapacitu dostupnou ostatním uživatelům. To může mít formu vynucení kvót, prostřednictvím vzoru omezení nebo vzorce omezení četnosti.
- Zvažte zřizování více infrastruktur. To může zahrnovat horizontální navýšení kapacity tím, že se upgradují některé součásti vašeho řešení, nebo to může zahrnovat horizontální navýšení kapacity tím, že provedete vzor horizontálního dělení, nebo razítka, pokud použijete vzor razítka nasazení.
- Zvažte možnost Povolit klientům nákup předem zřízené nebo rezervované kapacity. Díky tomu jsou klienti s větší jistotou, že vaše řešení odpovídajícím způsobem zpracovává jejich zatížení.
- Zvažte přístup k vyhlazení využití prostředků:
- Pokud hostete víc instancí svého řešení, zvažte opětovné vyvážení klientů napříč instancemi nebo razítky. Zvažte například umístění klientů s předvídatelnými a podobnými vzorci použití napříč více razítky k sloučení Špičk v jejich využití.
- Vezměte v úvahu, jestli máte procesy na pozadí nebo úlohy náročné na prostředky, které nejsou citlivé na čas. Spouštějte je asynchronně v době mimo špičku, abyste zachovali kapacitu prostředků ve špičce pro časově citlivá zatížení.
- Vezměte v úvahu, jestli vaše služby poskytují ovládací prvky pro zmírnění problémů s vysokou dostupností sousedů. pokud například používáte Kubernetes, zvažte použití omezení poda při použití Service Fabric zvažte použití vestavěných funkcí zásad správného řízení.
- V případě potřeby zvažte omezení operací, které mohou klienti provádět. Například zabráníte klientům ve spouštění operací, které budou spouštět velmi velké databázové dotazy. Tím se snižuje riziko, že klienti přebírají akce, které můžou negativně ovlivnit ostatní klienty.
- V případě potřeby zvažte poskytnutí systému QoS (Quality of Service). Když použijete QoS, určíte prioritu některých procesů nebo úloh před ostatními. Využitím technologie QoS v rámci návrhu a architektury můžete zajistit, aby operace s vysokou prioritou měly přednost při tlaku na prostředky.
Požadavky
- Ve většině případů nezpůsobí, že jednotliví klienti způsobují problémy s hlučnými sousedními směrovači. Jednotliví klienti nemusí ani vědět, že jejich úlohy způsobují problémy s hlučnými sousedními uživateli pro ostatní.
- Je ale také možné, že klienti používají chyby zabezpečení ve sdílených součástech k útoku na službu, a to buď jednotlivě, nebo spuštěním útoku DDoS (Distributed Denial of Service).
- Bez ohledu na příčinu je důležité tyto problémy nakládat jako problémy se zásadami správného řízení prostředků a uplatňovat kvóty využití, omezování a řízení zásad správného řízení pro zmírnění problému.
Poznámka
Ujistěte se, že jste klientům informovali o jakémkoli omezení, které použijete, nebo o všech kvótách využití vaší služby. Je důležité, aby spolehlivě zpracovávala neúspěšné požadavky a nepřekvapeny se všemi případnými omezeními a kvótami.
Jak zjistit problém
V perspektivě klienta dochází k problému s vysokou přenositelností, obvykle se jedná o neúspěšné požadavky na server nebo dokončení požadavků, které trvají dlouhou dobu. Zejména pokud je stejný požadavek úspěšný v jinou dobu a zdá se, že dojde k chybě náhodně, může dojít k problému s vysokou úrovní potíží. Klientské aplikace by měly zaznamenat telemetrii pro sledování míry úspěšnosti a výkonu požadavků na služby a aplikace by měly také zaznamenávat metriky výkonu směrného plánu pro účely porovnání.
V perspektivě služby se může problém s hlučným sousedním směrovačem zobrazit několika způsoby:
- Špičky využití prostředků. Je důležité mít jasné informace o využití normálního základního prostředku a ke konfiguraci monitorování a výstrah pro detekci špiček využití prostředků. Ujistěte se, že máte v úvahu všechny prostředky, které by mohly ovlivnit výkon nebo dostupnost vaší služby. patří mezi ně metriky, jako je využití procesoru serveru a paměti, v/v, využití databáze, síťový provoz a metriky, které jsou vystavené spravovanými službami, jako je třeba počet požadavků a syntetická a abstraktní metrika výkonu, například Azure Cosmos DB jednotky žádostí.
- Selhání při provádění operace pro tenanta, a to i v případě, že tenant nepoužívá velkou část prostředků systému. Takový vzor může znamenat, že se jedná o oběti problému s vysokou dostupností sousedů. Zvažte sledování spotřeby prostředků v tenantovi. například při použití Azure Cosmos DB zvažte protokolování jednotek požadavků použitých pro každý požadavek a přidejte identifikátor klienta jako dimenzi k telemetrie, abyste mohli agregovat spotřebu jednotek požadavků pro každého tenanta.