Sdílet prostřednictvím

Dokumentace ke spolehlivosti Azure

  • Článek

Spolehlivost se skládá ze dvou principů: odolnosti a dostupnosti. Cílem odolnosti je vyhnout se selháním a v případě, že k nim stále dochází, vrátit aplikaci do plně funkčního stavu. Cílem dostupnosti je poskytnout konzistentní přístup k vaší aplikaci nebo úloze. Je důležité naplánovat proaktivní spolehlivost na základě požadavků vaší aplikace.

Azure zahrnuje integrované služby spolehlivosti, které můžete používat a spravovat na základě vašich obchodních potřeb. Ať už jde o selhání jednoho hardwarového uzlu, selhání na úrovni racku, výpadek datacentra nebo velký regionální výpadek, Azure poskytuje řešení, která zlepšují spolehlivost. Skupiny dostupnosti například zajišťují distribuci virtuálních počítačů nasazených v Azure napříč několika izolovanými hardwarovými uzly v clusteru. Zóny dostupnosti chrání aplikace a data zákazníků před selháním datacentra napříč několika fyzickými umístěními v rámci oblasti. Oblasti a zóny dostupnosti jsou centrální pro strategii návrhu a odolnosti vaší aplikace a jsou podrobněji popsány dále v tomto článku.

Dokumentace ke spolehlivosti Azure nabízí pokyny pro spolehlivost služeb Azure. Tyto pokyny zahrnují informace o podpoře zón dostupnosti, pokynech k zotavení po havárii a dostupnosti služeb.

Podrobné pokyny ke spolehlivosti specifické pro službu, včetně zón dostupnosti, zotavení po havárii nebo vysoké dostupnosti, najdete v přehledu pokynů ke spolehlivosti specifické pro službu Azure.

Informace o principech spolehlivosti a spolehlivosti a architektuře ve službách Microsoft Azure najdete v tématu Microsoft Azure Well-Architected Framework: Spolehlivost.

Požadavky na spolehlivost

Požadovaná úroveň spolehlivosti pro jakékoli řešení Azure závisí na několika aspektech. Smlouva SLA o dostupnosti a latenci a další obchodní požadavky řídí výběr architektury a úroveň odolnosti a měla by být považována za první. Požadavky na dostupnost se liší od toho, kolik výpadků je přijatelné – a kolik stojí vaše firma – až po množství peněz a času, které můžete realisticky investovat do zajištění vysoké dostupnosti aplikace.

Vytváření systémů spolehlivosti v Azure je sdílená odpovědnost. Microsoft zodpovídá za spolehlivost cloudové platformy, včetně globální sítě a datových center. Zákazníci a partneři Azure zodpovídají za odolnost svých cloudových aplikací s využitím osvědčených postupů architektury na základě požadavků jednotlivých úloh. Azure se sice neustále snaží dosáhnout nejvyšší možné odolnosti ve smlouvách SLA pro cloudovou platformu, ale pro každou úlohu ve vašem řešení musíte definovat vlastní cílové smlouvy SLA. SLA umožňuje vyhodnotit, zda architektura splňuje obchodní požadavky. Když se snažíte dosáhnout vyšších procent zaručené doby provozu ve sla, náklady a složitost pro dosažení této úrovně dostupnosti se rozrůstá. Doba provozu 99,99 % znamená přibližně pět minut celkového výpadku za měsíc. Stojí za to větší složitost a náklady na dosažení daného procenta? Odpověď závisí na individuálních obchodních požadavcích. Při rozhodování o konečných závazcích SMLOUVY SLA se seznamte s podporovanými smlouvami SLA od Microsoftu. Každá služba Azure má vlastní smlouvu SLA.

Diagram showing the shared responsibility model for Azure business continuity.

V tradičním místním modelu je na vás celá odpovědnost za správu hardwaru pro výpočetní prostředky, úložiště a sítě až po aplikaci. Musíte naplánovat různé typy selhání a způsob jejich řešení vytvořením strategie zotavení po havárii. U IaaS zodpovídá poskytovatel cloudových služeb za odolnost základní infrastruktury, včetně úložiště, sítí a výpočetních prostředků. Když přecházíte z IaaS na PaaS a pak na SaaS, zjistíte, že zodpovídáte za méně a poskytovatel cloudových služeb zodpovídá za více.  

Další informace o principech spolehlivosti najdete v dokumentaci ke spolehlivosti dobře navržená architektura.  

Budování spolehlivosti

Na začátku plánování byste měli definovat požadavky vaší aplikace na spolehlivost. Pokud víte, které aplikace během určitých časových období nepotřebují 100% vysokou dostupnost, můžete optimalizovat náklady během těchto nekritičtějších období. Identifikujte typ selhání, ke které může aplikace docházet, a potenciální účinek jednotlivých selhání. Plán obnovení by měl pokrýt všechny důležité služby dokončením strategie obnovení na jednotlivých komponentách a celkové úrovni aplikace. Navrhněte strategii obnovení pro ochranu před zónovým, regionálním a aplikačním selháním. Proveďte testování kompletního aplikačního prostředí pro měření spolehlivosti a obnovení aplikace proti neočekávanému selhání.

Následující kontrolní seznam se zabývá rozsahem plánování spolehlivosti.

Plánování spolehlivosti
Definujte cíle dostupnosti a obnovení tak, aby splňovaly obchodní požadavky.
Navrhněte funkce spolehlivosti aplikací na základě požadavků na dostupnost.
Zarovnejte aplikace a datové platformy tak, aby splňovaly vaše požadavky na spolehlivost.
Nakonfigurujte cesty připojení pro zvýšení dostupnosti.
Pokud je to možné, použijte zóny dostupnosti a plánování zotavení po havárii, abyste zlepšili spolehlivost a optimalizovali náklady.
Ujistěte se, že je vaše aplikační architektura odolná vůči chybám.
Zjistěte , co se stane, když nejsou splněné požadavky smlouvy SLA.
Identifikujte možné body selhání v systému. Návrh aplikace by měl tolerovat selhání závislostí nasazením přerušení okruhu.
Vytvářejte aplikace, které pracují bez jejich závislostí.

RtO a RPO

Dvě důležité metriky, které je třeba vzít v úvahu, jsou plánovaná doba obnovení a cíl bodu obnovení, protože obě souvisejí se zotavením po havárii.  Další informace o požadavcích na funkční a nefunkční návrh naleznete v tématu Dobře navržená architektura funkční a nefunkční požadavky.

  • Plánovaná doba obnovení (RTO, Recovery Time Objective) je maximální přijatelná dobu, po kterou může být aplikace po incidentu nedostupná.

  • Cíl bodu obnovení (RPO, Recovery Point Objective) je maximální období ztráty dat, které je při havárii přijatelné.

RtO a RPO jsou nefunkční požadavky systému a měly by být diktovány obchodními požadavky. K odvození těchto hodnot je vhodné provést vyhodnocení rizik a dobře pochopit náklady na prostoje nebo ztrátu dat.  

Oblasti a zóny dostupnosti

Oblasti a zóny dostupnosti jsou velkou součástí rovnice spolehlivosti. Oblasti mají více fyzicky oddělených zón dostupnosti. Tyto zóny dostupnosti jsou propojeny vysoce výkonnou sítí s nižší latencí než 2 min. mezi fyzickými zónami. Nízká latence pomáhá vašim datům zůstat synchronizovaná a přístupná, když se něco pokazí. Tuto infrastrukturu můžete strategicky používat při navrhování aplikací a datové infrastruktury, které automaticky replikují a poskytují nepřerušované služby mezi zónami a napříč oblastmi.

Služby Microsoft Azure podporují zóny dostupnosti a umožňují řídit vaše cloudové operace v optimální vysoké dostupnosti a zároveň podporovat potřeby zotavení mezi oblastmi a strategie provozní kontinuity.

V případě plánování zotavení po havárii nabízejí oblasti spárované s jinými oblastmi replikaci mezi oblastmi a poskytují ochranu asynchronní replikací dat napříč ostatními oblastmi Azure. Oblasti bez páru dodržují pokyny k rezidenci dat a nabízejí vysokou dostupnost se zónami dostupnosti a místně redundantním nebo zónově redundantním úložištěm. Zákazníci budou muset naplánovat zotavení po havárii napříč oblastmi na základě potřeb RTO/RPO.

Na základě technických a regulačních aspektů – možností služeb, rezidence dat, požadavků na dodržování předpisů, latence – zvolte nejvhodnější oblast pro vaše potřeby a začněte postupovat podle strategie spolehlivosti. Další informace najdete v oblastech Azure a zónách dostupnosti.

Závislosti služeb Azure

Služby Microsoft Azure jsou dostupné globálně pro řízení cloudových operací na optimální úrovni.

Služby Azure nasazené do oblastí Azure jsou uvedené na stránce produktů globální infrastruktury Azure. Pokud chcete lépe porozumět oblastem a Zóny dostupnosti v Azure, podívejte se na oblasti a Zóny dostupnosti v Azure.

Služby Azure jsou vytvořené pro spolehlivost, včetně vysoké dostupnosti a zotavení po havárii. Neexistují žádné služby, které jsou závislé na jednom logickém datovém centru (aby se zabránilo kritickým bodům selhání). Jiné než regionální služby uvedené v produktech globální infrastruktury Azure jsou služby, pro které není závislé na konkrétní oblasti Azure. Služby, které nejsou regionální, se nasazují do dvou nebo více oblastí a pokud dojde k selhání oblasti, instance služby v jiné oblasti bude dál obsluhovat zákazníky. Některé služby mimo oblast umožňují zákazníkům určit oblast, ve které se bude nasazovat základní virtuální počítač, na kterém se bude služba spouštět. Azure Virtual Desktop například umožňuje zákazníkům zadat umístění oblasti, ve které se virtuální počítač nachází. Všechny služby Azure, které ukládají zákaznická data, umožňují zákazníkovi zadat konkrétní oblasti, ve kterých se budou data ukládat. Výjimkou je ID Microsoft Entra, které má geografické umístění (například Evropa nebo Severní Amerika). Další informace o rezidenci úložiště dat najdete v mapě rezidence dat.

Pokud potřebujete porozumět závislostem mezi službami Azure, abyste mohli lépe navrhovat aplikace a služby, můžete požádat o dokumentaci závislostí služeb Azure kontaktováním prodejce nebo zástupce zákazníka Microsoftu. Tento dokument obsahuje seznam závislostí pro služby Azure, včetně závislostí na všech běžných hlavních interních službách, jako jsou služby roviny řízení. Pokud chcete získat tuto dokumentaci, musíte být zákazníkem Microsoftu a s Microsoftem musíte mít příslušnou smlouvu o nezveřejnění (NDA).

Další kroky