Co je převzetí služeb při selhání a obnovení služeb?

Tento článek obsahuje obecný přehled fungování převzetí služeb při selhání i navrácení služeb po obnovení v cloudovém prostředí. Pokud však chcete pochopit failover, měli byste nejprve porozumět redundanci a replikaci. Další informace o těchto konceptech před pokračováním v tomto článku najdete v tématu Redundance, replikace a zálohování.

Běžným důvodem pro zachování redundantních kopií aplikací a replik dat je umožnění provedení převzetí služeb při selhání. Při převzetí služeb při selhání můžete přesměrovat provoz a požadavky z nefunkčních instancí na funkční instance. Jakmile se původní instance znovu stabilizují, můžete provést failback a vrátit se k původní konfiguraci.

Aktivní a pasivní role instance

V kontextu převzetí služeb při selhání může být instance jednou komponentou, jako je databáze, nebo sada více komponent, které tvoří nasazení služby v oblasti. Můžete provádět záložní přepnutí jednotlivých částí řešení různými způsoby a v různých situacích.

Komponenta nebo kolekce komponent nakonfigurovaných pro převzetí služeb při selhání a navrácení služeb po obnovení vyžaduje více instancí. Každá z těchto instancí předpokládá určitou roli:

• Primární nebo aktivní instance aktivně fungují, například obsluha příchozích požadavků od klientů. Obvykle existuje jedna primární instance najednou.
• Sekundární nebo pasivní instance jsou neaktivní, ale jsou v případě potřeby připraveny k přepnutí na primární. Může existovat několik sekundárních instancí.

Existují různé způsoby konfigurace pasivních instancí. Každý způsob zahrnuje kompromisy mezi dobou obnovení a dalšími faktory, jako jsou náklady a provozní složitost:

• Aktivní pohotovostní režim, který je navržený tak, aby byl kdykoli připraven k přijetí produkčního provozu.
• Teplé pohotovostní režimy, které jsou navržené tak, aby byly téměř připravené k přijetí produkčního provozu, ale můžou vyžadovat provedení některých změn konfigurace nebo operací škálování před přijetím provozu.
• Pohotovostní režimy pilotního světla, které jsou částečně nasazené v minimální konfiguraci, a před přijetím produkčního provozu vyžadují podstatnou přípravu.
• Studené pohotovostní režimy, které možná nebudou nasazeny vůbec a před tím, než mohou přijímat produkční provoz, spoléhají na nasazení komponent.

Návod

Některá řešení jsou vytvořená tak, aby používala přístup typu aktivní-aktivní , což znamená, že všechny instance obsluhují všechny požadavky. Systém aktivní-aktivní nevyžaduje převzetí služeb při selhání, protože všechny instance aktivně obsluhují žádosti za všech okolností.

Obory převzetí služeb při selhání

Různé situace vyžadují různé strategie převzetí služeb při selhání. Pro ilustraci těchto možných strategií zvažte ukázkové řešení, které se skládá z aplikace, která přistupuje k datům z databáze. Řešení nakonfigurujete pro zotavení po selhání vytvořením redundantních kopií aplikačního serveru a vytvořením většího počtu replik databáze. Dále nakonfigurujete:

• Redundance zón umístěním kopií a replik do různých zón dostupnosti v rámci Azure oblasti.
• Geografická redundance s využitím globálního vyrovnávače zatížení k převzetí při selhání mezi regiony.

Tady je zjednodušený diagram, který znázorňuje celkovou architekturu v normálních operacích:

Různé situace můžou v tomto řešení aktivovat různé události přepnutí při selhání. Každá z těchto možností odpovídá rozsahu převzetí služeb při selhání, který představuje úroveň komponent, které převezmou služby při selhání.

• Neočekávaná změna repliky databáze může nastat, když se aktivní replika databáze stane nedostupnou. Pasivní replika je povýšena na aktivní repliku. Aplikace obvykle můžou rychle převést své požadavky na novou aktivní repliku:

  

• Selhání zóny dostupnosti může nastat, pokud celá zóna dostupnosti zažije výpadek. Tento typ výpadku vyžaduje, aby veškerý provoz byl směrován na webový server ve zbývající zóně a také zajišťuje, aby replika databáze v přeživší zóně byla aktivní replikou, pokud ještě není:

  

• Převzetí služeb při selhání oblasti může nastat, pokud dojde ke katastrofické ztrátě celé primární oblasti Azure.

  

I když každý z těchto oborů poskytuje typ převzetí služeb při selhání, můžou mít odlišné požadavky a procesy převzetí služeb při selhání. Microsoft může také odpovídat za některé rozsahy převzetí služeb při selhání, například při použití zónově redundantních služeb, zatímco vy můžete být zodpovědní za převzetí služeb při selhání v širších rozsazích, jako je převzetí služeb při selhání mezi oblastmi Azure.

Plánování převzetí služeb při selhání a provozní kontinuity

Součástí plánování kontinuity podnikových procesů je návrh strategií převzetí služeb při selhání, včetně různých rozsahů, ve kterých můžete převzít služby při selhání.

Obecně platí, že plány kontinuity podnikových procesů by měly zahrnovat automatizované postupy převzetí služeb při selhání v rámci zón dostupnosti nebo mezi zónami dostupnosti. Tento typ převzetí služeb při selhání je součástí vaší strategie vysoké dostupnosti. Pokud například aktivní replika databáze selže, může automatizovaný proces zvýšit úroveň pasivní repliky na aktivní repliku. Pak webové servery komunikují s novou aktivní replikou. Podobně platí, že pokud dojde k selhání zóny dostupnosti, řada řešení se sestaví tak, aby se automaticky obnovila pomocí zbývajících zón.

Pro havarijní scénáře se používají různé postupy pro převzetí služeb při selhání, například v nepravděpodobném případě výpadku celého regionu. V případě výpadku oblasti můžete přesměrovat příchozí webové požadavky do druhé oblasti a také provést přesun databáze na repliku v sekundární oblasti.

Mějte na paměti, že zahrnutí postupů převzetí služeb při selhání do plánování kontinuity podnikových procesů vyžaduje, abyste udělali podrobnější návrh a testování. Další informace najdete v tématu Co jsou provozní kontinuita, vysoká dostupnost a zotavení po havárii?.

Plánované a neplánované převzetí služeb při selhání

Neplánované přepnutí v případě selhání jsou akce, které se provádějí během výpadku komponenty, aby se služba mohla obnovit pomocí jiné instance. Neplánované převzetí služeb při selhání někdy vede k výpadkům nebo ztrátě dat v závislosti na tom, jak je řešení navrženo. Neplánované převzetí služeb při selhání vyžaduje automatický mechanismus pro zjištění selhání a rozhodnutí, kdy aktivovat převzetí služeb při selhání.

Naproti tomu plánované přebírání služeb při selhání jsou ty, které aktivujete proaktivně. Můžete to udělat v očekávání toho, že se stane něco, například virtuální počítač, který bude aktualizován a restartován. Plánované převzetí při selhání může mít nižší toleranci pro výpadky a ztrátu dat, protože je součástí běžných postupů údržby.

Jak funguje převzetí služeb při selhání

Převzetí služeb při selhání systému se obvykle skládá z následujících kroků, které lze provést automatizovaným systémem nebo ručně. Konkrétní podrobnosti pro každý z těchto kroků závisí na konkrétním systému.

1. Zjištění selhání (pouze neplánované převzetí služeb při selhání) Automatizované převzetí služeb při selhání vyžaduje, aby něco zjistilo, když je instance nedostupná, což je obvykle založeno na kontrole stavu systému. Různé služby definují jejich stav různými způsoby. Některé služby aktivně například odesílají události heartbeat mezi instancemi. Jiné vyžadují samostatnou komponentu ke zkoumání každé instance v pravidelných intervalech. Často trvá, než monitorování stavu zjistí, že instance selhala, a často je důležité dát období odkladu v případě, že instance byla jednoduše zaneprázdněná a nemohla reagovat.

2. Zvolte převzetí služeb. V určitém okamžiku se rozhodne o provedení převzetí služeb při selhání. Rozhodnutí může provést automatizovaný nástroj nebo ručně. Tolerance rizik vaší organizace může ovlivnit, jak rychle se toto rozhodnutí provede. Pokud máte nízkou toleranci vůči riziku, můžete se rozhodnout rychle přejít na záložní systém, pokud se objeví náznak problému. Pokud máte vyšší toleranci k rizikům, můžete se rozhodnout počkat a zjistit, zda lze problém vyřešit, než přistoupíte k převzetí služeb při selhání.

3. Vyberte novou primární instanci. Jedna z zbývajících instancí by se měla stát novou primární instancí.

   V některých situacích můžete mít předdefinovanou instanci, která by se měla stát novou primární instancí, nebo můžete mít jenom jednu instanci, na kterou se má přepnout.

   V jiných situacích existuje automatizovaný proces, pomocí kterého systém vybere novou primární instanci. V distribuovaných výpočtech se používá řada algoritmů pro konsenzus, včetně algoritmů pro volbu vedoucího. Tyto algoritmy se implementují v rámci příslušných služeb, jako jsou databáze. V některých systémech je důležité, aby každá instance byla informována o nové primární replice, a proto jsou výsledky výběru automaticky oznámeny každé replice.

4. Přesměrujte žádosti. Nakonfigurujte prostředí tak, aby byly požadavky směrovány na instance, které jsou v pořádku, nebo do nové primární instance.

   Abyste toho dosáhli, možná budete muset aktualizovat jiné systémy, aby věděli, kde odesílat požadavky. To může zahrnovat aktualizaci systému vyrovnávání zatížení, aby se vyloučila instance, která není v pořádku. V jiných situacích se systém DNS (Domain Name System) běžně používá jako způsob odesílání požadavků do aktivní instance systému. V rámci procesu převzetí služeb při selhání obvykle potřebujete aktualizovat záznamy DNS tak, aby se požadavky směrovaly do nové primární instance. DNS má koncept TTL ( time-to-live ), který dává klientům pokyn, jak často mají kontrolovat aktualizované záznamy DNS. Pokud je hodnota TTL nastavená na dlouhou hodnotu, může to chvíli trvat, než klienti obdrží informace o převzetí služeb při selhání a můžou pokračovat v odesílání požadavků na původní primární server.

Vzhledem k tomu, že procesy převzetí služeb při selhání můžou zahrnovat zpoždění, je důležité naplánovat postupy převzetí služeb při selhání tak, aby splňovaly vaše požadavky na výpadky (cíl bodu obnovení nebo RTO) a ztrátu dat (cíl bodu obnovení nebo cíl bodu obnovení). Další informace najdete v tématu Co jsou provozní kontinuita, vysoká dostupnost a zotavení po havárii?

Failback

Failback je proces opětovného uvedení a přesměrování provozu zpět do původní instance.

V některých situacích vůbec není nutné přepnout zpět, protože každá instance je schopna fungovat jako primární. Je však několik situací, kdy je důležité vrátit služby zpět, například když potřebujete provozovat aplikace z konkrétní Azure oblasti a při regionálním výpadku jste dočasně přešli na jinou oblast.

Někdy se navrácení služeb po obnovení zpracovává stejným způsobem jako převzetí služeb při selhání. Navrácení služeb po obnovení ale může být také složitější než převzetí služeb při selhání z několika důvodů:

• Problémy se synchronizací dat Během automatického převzetí služeb při selhání, a dokonce i po něm, mohla předchozí primární instance stále provádět určitou práci nebo zapsala některá data do úložiště dat. Součástí procesu obnovení je zajištění konzistence a integrity dat v rámci vašeho řešení, včetně řízení konfliktů a řešení duplicit mezi primárními a sekundárními instancemi.

  Běžné problémy se synchronizací dat vyžadují ruční zásah. Pokud konfliktní data nepotřebujete, můžete se rozhodnout obnovit databázi nebo jiný stav.

• Kroky pro nápravu. Pokud došlo k pokusu o provedení nápravných opatření na primárním před přepnutím při selhání, mohly zanechat primární instanci v neznámém stavu.

  Pokud existuje riziko, že primární instance je v nekonzistentním stavu, možná budete muset primární instanci zničit a znovu nasadit, aby byla ve známém dobrém stavu před přepnutím zpět.

• Výpadek navíc. Výpadek během procesu obnovy může být delší než během přepnutí na záložní systém, kvůli potřebným rekonfiguracím nebo operacím obnovení konzistence dat.

  Tento problém můžete zmírnit spuštěním procesů obnovení provozu během časového období údržby nebo informováním uživatelů o změně předem. Také byste mohli provést některé přípravné operace, když je systém online, a snížit tím nutné prostoje na minimum.

• Odolnost proti rizikům. Pokud k převzetí služeb při selhání došlo kvůli výpadku, může být tolerance organizace pro výpadky nebo jiná rizika během navrácení služeb po obnovení nižší.

  Obchodní zúčastněné strany by měly být informovány o situaci v průběhu procesu a měly by být plně informovány o potřebě obnovení provozu a důsledcích postupů obnovení provozu. Možná budete moct vyjednat vhodný čas na provedení změn.

Převzetí služeb při selhání a obnovení provozu ve službách Azure

I když je důležité pochopit, jak funguje převzetí služeb při selhání obecně, mějte na paměti, že každá služba Azure může přistupovat k převzetí služeb při selhání a navrácení služeb po obnovení jinak. Informace o tom, jak konkrétní služby Azure fungují z hlediska spolehlivosti, pozorujte průvodce spolehlivostí jednotlivých služeb.

Mnoho služeb Azure automaticky řeší některé typy selhání. Když například použijete Azure služby, které jsou nakonfigurované tak, aby byly zónově redundantní, Microsoft automaticky provede převzetí služeb při selhání mezi zónami dostupnosti za vás. Další informace najdete v tématu Co jsou zóny dostupnosti? a Azure průvodci spolehlivostí služeb.

Pokud používáte virtuální počítače, Azure Site Recovery replikuje virtuální počítače a jejich disky mezi zónami dostupnosti nebo do jiné Azure oblasti a může za vás provést převzetí služeb při selhání.

Při návrhu vlastního řešení, které kombinuje více služeb Azure dohromady, můžou být požadavky na převzetí služeb při selhání složitější. Předpokládejme, že navrhujete řešení s aplikační vrstvou a databází a chcete vytvořit víceregionovou aktivní/pasivní architekturu. Během výpadku v primární oblasti je důležité, aby aplikace a databáze spolu přešly do sekundární oblasti. V závislosti na konkrétních službách které používáte, možná budete muset naplánovat vlastní plán pro převzetí služeb při selhání, abyste mohli přepínat mezi jednotlivými nasazeními v každém regionu. Azure poskytuje globální směrování provozu a vyrovnávání zatížení prostřednictvím Azure Front Door a Azure Traffic Manager a můžete vybrat technologii, která splňuje vaše požadavky na převzetí služeb při selhání. Každá služba podporuje monitorování stavu každé regionální instance vaší aplikace a můžete ji nakonfigurovat tak, aby automaticky směrovat provoz do instance, která je v pořádku.

Další kroky

• Seznamte se se sdílenou odpovědností za spolehlivost.
• Přečtěte si o doporučeních pro návrh s více oblastmi s vysokou dostupností v Azure Well-Architected Frameworku.