Odolnost platformy Azure

Návod

Tento obsah je výňatek z eBooku, Architekting Cloud Native .NET Applications for Azure, který je k dispozici na webu Docs pro .NET nebo jako soubor PDF zdarma ke stažení, který si můžete přečíst offline.

Stáhnout PDF

Vytvoření spolehlivé aplikace v cloudu se liší od tradičního vývoje místních aplikací. I když jste dříve zakoupili hardware vyšší kategorie pro vertikální navýšení kapacity, v cloudovém prostředí můžete vertikálně navýšit kapacitu. Místo toho, abyste se pokusili zabránit selháním, je cílem minimalizovat jejich účinky a udržovat systém stabilní.

To znamená, že spolehlivé cloudové aplikace zobrazují odlišné charakteristiky:

• Jsou odolné, bezproblémově se zotavují z problémů a nadále fungují.
• Jsou vysoce dostupné (HA) a běží tak, jak jsou navržené v dobrém stavu bez významného výpadku.

Pochopení toho, jak tyto charakteristiky spolupracují – a jak ovlivňují náklady – je nezbytné k vytvoření spolehlivé aplikace nativní pro cloud. Dále se podíváme na způsoby, jak do aplikací nativních pro cloud vytvořit odolnost a dostupnost s využitím funkcí z cloudu Azure.

Návrh s odolností

Řekli jsme, že odolnost umožňuje vaší aplikaci reagovat na selhání a přesto zůstat funkční. Dokument white paper, resilience in Azure white paper, poskytuje pokyny k dosažení odolnosti na platformě Azure. Tady je několik klíčových doporučení:

• Selhání hardwaru. Zabudujte do aplikace redundanci nasazením komponent napříč různými doménami selhání. Pomocí skupin dostupnosti se například ujistěte, že jsou virtuální počítače Azure umístěné v různých rackech.

• Selhání datacentra. Zabudujte do aplikace redundanci pomocí zón izolace chyb napříč datovými centry. Pomocí azure Zóny dostupnosti se například ujistěte, že jsou virtuální počítače Azure umístěné v různých datových centrech izolovaných proti chybám.

• Regionální selhání. Replikujte data a komponenty do jiné oblasti, aby bylo možné rychle obnovit aplikace. Pomocí Azure Site Recovery můžete například replikovat virtuální počítače Azure do jiné oblasti Azure.

• Těžké zatížení. Vyrovnávání zatížení mezi instancemi za účelem zvládnutí špiček využití Můžete například umístit dva nebo více virtuálních počítačů Azure za nástroj pro vyrovnávání zatížení, aby se provoz distribuuje do všech virtuálních počítačů.

• Náhodné odstranění nebo poškození dat Zálohujte data, aby bylo možné je obnovit, pokud dojde k odstranění nebo poškození. Například pomocí služby Azure Backup můžete pravidelně zálohovat virtuální počítače Azure.

Návrh s redundancí

Selhání se liší v rozsahu dopadu. Selhání hardwaru, například selhání disku, může mít vliv na jeden uzel v clusteru. Selhání síťového přepínače může mít vliv na celý serverový rack. Méně časté chyby, jako je ztráta napájení, by mohly narušit celé datové centrum. Zřídka se stane, že celá oblast nebude dostupná.

Redundance je jedním ze způsobů, jak zajistit odolnost aplikací. Přesná úroveň redundance závisí na vašich obchodních požadavcích a ovlivní náklady i složitost vašeho systému. Například nasazení s více oblastmi je dražší a složitější pro správu než nasazení v jedné oblasti. Ke správě převzetí služeb při selhání a navrácení služeb po obnovení budete potřebovat provozní postupy. Další náklady a složitost můžou být odůvodněné pro některé obchodní scénáře, ale ne pro jiné.

Pokud chcete vytvořit architekturu redundance, musíte identifikovat kritické cesty v aplikaci a pak určit, jestli v každém bodě cesty dojde k redundanci? Pokud má subsystém selhat, aplikace převezme služby při selhání na něco jiného? Nakonec potřebujete jasný přehled o těchto funkcích integrovaných do cloudové platformy Azure, kterou můžete využít ke splnění požadavků na redundanci. Tady jsou doporučení pro navrhování redundance:

• Nasaďte několik instancí služeb. Pokud vaše aplikace závisí na jedné instanci služby, vytvoří jediný bod selhání. Zřizování více instancí zlepšuje odolnost i škálovatelnost. Při hostování ve službě Azure Kubernetes Service můžete deklarativní konfigurovat redundantní instance (sady replik) v souboru manifestu Kubernetes. Hodnotu počtu replik je možné spravovat prostřednictvím kódu programu, na portálu nebo prostřednictvím funkcí automatického škálování.

• Využití nástroje pro vyrovnávání zatížení Vyrovnávání zatížení distribuuje požadavky vaší aplikace do instancí služby, které jsou v pořádku, a automaticky odebere instance, které nejsou v pořádku, z obměny. Při nasazování do Kubernetes je možné vyrovnávání zatížení zadat v souboru manifestu Kubernetes v části Služby.

• Plánování nasazení ve více oblastech Pokud nasadíte aplikaci do jedné oblasti a tato oblast přestane být k dispozici, aplikace bude také nedostupná. To může být nepřijatelné podle podmínek smluv o úrovni služeb vaší aplikace. Místo toho zvažte nasazení aplikace a jejích služeb napříč několika oblastmi. Například cluster Azure Kubernetes Service (AKS) se nasadí do jedné oblasti. Pokud chcete chránit systém před regionálním selháním, můžete aplikaci nasadit do několika clusterů AKS v různých oblastech a pomocí funkce Spárované oblasti koordinovat aktualizace platformy a určovat prioritu úsilí o obnovení.

• Povolte geografickou replikaci. Geografická replikace služeb, jako je Azure SQL Database a Cosmos DB, vytvoří sekundární repliky vašich dat napříč několika oblastmi. I když obě služby automaticky replikují data ve stejné oblasti, geografická replikace vás chrání před výpadkem oblasti tím, že vám umožní převzít služby při selhání do sekundární oblasti. Dalším osvědčeným postupem pro centra geografické replikace kolem ukládání imagí kontejnerů. Pokud chcete nasadit službu v AKS, musíte uložit a vyžádat image z úložiště. Azure Container Registry se integruje s AKS a dokáže bezpečně ukládat image kontejnerů. Pokud chcete zvýšit výkon a dostupnost, zvažte geografickou replikaci imagí do registru v každé oblasti, kde máte cluster AKS. Každý cluster AKS pak načítá image kontejneru z místního registru kontejneru ve své oblasti, jak je znázorněno na obrázku 6–4:

Obrázek 6–4 Replikované prostředky napříč oblastmi

• Implementujte nástroj pro vyrovnávání zatížení provozu DNS.Azure Traffic Manager poskytuje vysokou dostupnost pro důležité aplikace vyrovnáváním zatížení na úrovni DNS. Může směrovat provoz do různých oblastí na základě zeměpisné polohy, doby odezvy clusteru a dokonce i stavu koncového bodu aplikace. Azure Traffic Manager může například směrovat zákazníky na nejbližší cluster AKS a instanci aplikace. Pokud máte více clusterů AKS v různých oblastech, pomocí Traffic Manageru můžete řídit toky provozu do aplikací, které běží v každém clusteru. Obrázek 6–5 ukazuje tento scénář.

Obrázek 6–5 AKS a Azure Traffic Manager

Návrh pro zajištění škálovatelnosti

Cloud se úspěšně škáluje. Schopnost zvýšit nebo snížit systémové prostředky, aby se vyřešilo zvýšení nebo snížení zatížení systému, je klíčovou sadou cloudů Azure. K efektivnímu škálování aplikace ale potřebujete vědět o funkcích škálování každé služby Azure, kterou do své aplikace zahrnete. Tady jsou doporučení pro efektivní implementaci škálování ve vašem systému.

• Návrh pro škálování Aplikace musí být navržená pro škálování. Aby bylo možné začít, měly by být služby bezstavové, aby bylo možné požadavky směrovat na libovolnou instanci. Bezstavové služby také znamenají, že přidání nebo odebrání instance nemá nepříznivý vliv na aktuální uživatele.

• Rozdělte úlohy. Rozdělení domén do nezávislých, samostatných mikroslužeb umožňuje každé službě škálovat nezávisle na ostatních. Služby mají obvykle různé potřeby a požadavky na škálovatelnost. Dělení umožňuje škálovat jenom to, co je potřeba škálovat bez zbytečných nákladů na škálování celé aplikace.

• Upřednostnění horizontálního navýšení kapacity. Cloudové aplikace upřednostňují horizontální navýšení kapacity prostředků místo vertikálního navýšení kapacity. Horizontální navýšení kapacity (označované také jako horizontální škálování) zahrnuje přidání dalších prostředků služeb do existujícího systému, aby bylo možno splnit a sdílet požadovanou úroveň výkonu. Vertikální navýšení kapacity (označované také jako vertikální škálování) zahrnuje nahrazení stávajících prostředků výkonnějším hardwarem (více disků, paměti a procesorových jader). Horizontální navýšení kapacity se dá vyvolat automaticky pomocí funkcí automatického škálování dostupných v některých cloudových prostředcích Azure. Horizontální navýšení kapacity napříč více prostředky také zvyšuje redundanci celkového systému. Vertikální navýšení kapacity jednoho prostředku je obvykle dražší než horizontální navýšení kapacity napříč mnoha menšími prostředky. Obrázek 6–6 znázorňuje dva přístupy:

Obrázek 6–6 Vertikální navýšení kapacity a horizontální navýšení kapacity

• Proporcionálně škálovat. Při škálování služby se zamyslete nad sadami prostředků. Pokud byste chtěli výrazně škálovat konkrétní službu, jaký dopad by to mělo na back-endová úložiště dat, mezipaměti a závislé služby? Některé prostředky, jako je Cosmos DB, se můžou škálovat úměrně, ale mnoho dalších to nedokáže. Chcete zajistit, abyste prostředek nepřešli na více instancí na místo, kde vyčerpá další přidružené prostředky.

• Vyhněte se spřažení. Osvědčeným postupem je zajistit, aby uzel nevyžaduje místní spřažení, často označované jako lepivé relace. Požadavek by měl být schopný směrovat do jakékoli instance. Pokud potřebujete zachovat stav, měli byste ho uložit do distribuované mezipaměti, jako je Azure Redis Cache.

• Využijte výhod funkcí automatického škálování platformy. Pokud je to možné, používejte integrované funkce automatického škálování místo vlastních mechanismů nebo mechanismů třetích stran. Pokud je to možné, pomocí pravidel plánovaného škálování zajistěte, aby byly prostředky dostupné bez zpoždění při spuštění, ale podle potřeby přidejte do pravidel reaktivní automatické škálování, abyste se mohli vypořádat s neočekávanými změnami v poptávce. Další informace najdete v doprovodných materiálech k automatickému škálování.

• Agresivně navyšte kapacitu. Posledním postupem by bylo agresivně navyšovat kapacitu, abyste mohli rychle dosáhnout okamžitých špiček v provozu bez ztráty podnikání. A pak škálujte (tj. odeberte nepotřebné instance) konzervativně, aby byl systém stabilní. Jednoduchým způsobem, jak to implementovat, je nastavit období studeného snížení kapacity, což je doba čekání mezi operacemi škálování, až pět minut pro přidání prostředků a až 15 minut pro odebrání instancí.

Integrované opakování ve službách

Doporučujeme osvědčené postupy implementace programových operací opakování v předchozí části. Mějte na paměti, že mnoho služeb Azure a jejich odpovídajících klientských sad SDK také zahrnuje mechanismy opakování. Následující seznam shrnuje funkce opakování v mnoha službách Azure, které jsou popsány v této knize:

• Azure Cosmos DB. Třída DocumentClient z rozhraní API klienta automaticky opakuje neúspěšné pokusy. Počet opakování a maximální doba čekání je možné konfigurovat. Výjimky vyvolané klientským rozhraním API jsou buď požadavky, které překračují zásady opakování, nebo ne přechodné chyby.

• Azure Redis Cache. Klient Redis StackExchange používá třídu správce připojení, která zahrnuje opakování při neúspěšných pokusech. Počet opakování, konkrétní zásady opakování a doba čekání jsou všechny konfigurovatelné.

• Azure Service Bus. Klient služby Service Bus zveřejňuje třídu RetryPolicy, která může být nakonfigurována s intervalem zpětného vypnutí, počtem opakování a TerminationTimeBuffer, který určuje maximální dobu, kterou může operace trvat. Výchozí zásada je devět pokusů o opakování s 30sekundovým obdobím opakování mezi pokusy.

• Azure SQL Database Podpora opakování se poskytuje při použití knihovny Entity Framework Core .

• Azure Storage Klientská knihovna úložiště podporuje operace opakování. Strategie se liší mezi tabulkami úložiště Azure, objekty blob a frontami. Alternativní opakování se také při povolení funkce geografické redundance přepne mezi umístěními primárního a sekundárního úložiště.

• Azure Event Hubs. Klientská knihovna centra událostí obsahuje vlastnost RetryPolicy, která zahrnuje konfigurovatelnou exponenciální funkci zpětného odpojení.

PředchozíDalší