Co je failover a failback?

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í. Abyste ale porozuměli převzetí služeb při selhání, 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í i replik dat je schopnost provést 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 stanou funkčními, můžete poté provést přepnutí zpět do původní konfigurace.

Role instancí aktivní a pasivní

V kontextu převzetí služeb při selhání může být instance jednou komponentou, jako je databáze, nebo kolekce více komponent, které tvoří nasazení služby v oblasti. U celého řešení mohou různé části selhat různými způsoby a v různých situacích.

Komponenta nebo sada komponent nakonfigurovaná pro přepnutí při selhání a zpětné přepnutí 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.
• Pilotní pohotovostní režimy, které jsou částečně nasazené v minimální konfiguraci a před přijetím provozu vyžadují rozsáhlou přípravu.
• Studené záložní systémy, které nemusí být vůbec aktivovány a spoléhají na to, že komponenty budou nasazeny, než mohou přijímat produkční provoz.

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í pro zotavení při selhání nakonfigurujete tak, že vytvoříte redundantní kopie aplikačního serveru a více kopií 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 oblasti Azure.
• Geografická redundance pomocí globálního nástroje pro vyrovnávání zatížení pro přepnutí 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řevzetí služeb 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 členitost komponent, které převezme služby při selhání:

• Při selhání repliky databáze může dojít k přepnutí na záložní repliku, 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:

  

• Převzetí služeb při selhání zóny dostupnosti může nastat, pokud dojde k výpadku celé zóny dostupnosti. 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 katastrofální 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í. cs-CZ: Microsoft může také odpovídat za některé oblasti 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ším měřítku, jako je například převzetí mezi oblastmi Azure.

Plánování přepnutí služeb a kontinuity provozu

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í systému 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 scénáře havárie se používají různé postupy převzetí služeb při selhání, například v nepravděpodobném případě výpadku celé oblasti. V případě výpadku oblasti můžete přesměrovat příchozí webové požadavky do druhé oblasti a také aktivovat failover 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řevzetí služeb při selhání jsou ty, které se provádějí během výpadku komponenty, abyste mohli službu obnovit pomocí jiné instance. Neplánované převzetí služeb 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 něco ke zjištění selhání a k rozhodnutí o tom, kdy se má převzetí služeb při selhání aktivovat.

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

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

Přepnutí při selhání se obvykle skládá z následujících kroků, které je možné provést ručně nebo automatizovaně. 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 bylo něco schopné detekovat, když je instance nedostupná, což je obvykle založené na nějaké kontrole zdravotního stavu. Různé služby definují jejich stav různými způsoby. Některé služby například aktivně odesílají události prezenčních signálů mezi instancemi. Jiné vyžadují samostatnou komponentu pro sondu každého 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řepnutí při selhání. V určitém okamžiku se rozhodne provést 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 k riziku, můžete se rozhodnout rychle přejít na záložní systém, pokud se objeví jakýkoli náznak problému. Pokud máte vyšší toleranci vůči rizikům, můžete se rozhodnout počkat a zjistit, zda se problém dá vyřešit, předtím než přejdete na režim záložního zabezpečení.

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 konsenzusních algoritmů, včetně těch pro volbu vůdce. Tyto algoritmy se implementují v rámci příslušných služeb, jako jsou databáze. V některýchsystémechch

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í mohou zahrnovat zpoždění, je důležité naplánovat své postupy převzetí služeb při selhání tak, aby splňovaly vaše požadavky na dobu výpadku (váš cíl obnovení do operativního stavu, neboli RTO) a ztrátu dat (váš cíl bodu obnovení, neboli RPO). Další informace najdete v tématu Co jsou provozní kontinuita, vysoká dostupnost a zotavení po havárii?

Obnovení původního stavu

Navrácení je proces obnovení a přesměrování provozu zpět do původní primární instance.

V některých situacích není nutné přepnout zpět vůbec, protože každý exemplář je stejně schopný fungovat jako primární. V některých situacích je ale důležité navrátit služby po obnovení, například když potřebujete spouštět aplikace z konkrétní oblasti Azure a dočasně převzít služby při selhání do jiné oblasti během regionálního výpadku.

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 pravidelného přepnutí při selhání a dokonce i poté mohlo dojít k tomu, že předchozí primární instance stále prováděla určitou práci nebo zapisovala 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ě správy konfliktů a 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.

• Nápravné kroky. Pokud byla před převzetím služeb při selhání provedena některá nápravná opatření na primární instanci, mohlo to zanechat primární instanci ve stavu neznámém.

  Pokud existuje riziko, že primární instance je v nekonzistentním stavu, možná budete muset primární instanci odstranit a znovu nasadit, aby byla ve známém dobrém stavu, než obnovíte původní stav.

• Výpadek navíc. Výpadek během procesu navrácení služeb může být delší než během převzetí služeb při selhání kvůli požadovaným rekonfiguracím nebo operacím k obnovení konzistence dat.

  Tento problém můžete zmírnit spuštěním procesů obnovení služeb během časového období údržby nebo předchozím upozorněním uživatelů na změnu. Kromě toho můžete být schopni provést některé přípravné operace, když je systém online, a minimalizovat potřebné prostoje.

• 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 dobu nečinnosti nebo jiná rizika během navrácení služeb 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ě obeznámeny s potřebou obnovení systému a důsledky těchto postupů. Možná budete moct vyjednat vhodný čas na provedení změn.

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

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

Mnoho služeb Azure zpracovává určité typy převzetí služeb při selhání automaticky. Pokud například používáte služby Azure, 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 průvodci spolehlivostí služeb Azure.

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é oblasti Azure 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 vaše 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íce oblastí aktivní/pasivní architekturu. Během výpadku v primárním regionu je důležité, aby aplikace a databáze společně přešly na sekundární region. V závislosti na konkrétních službách, které používáte, možná budete muset naplánovat vlastní přístup k převzetí služeb při selhání, abyste mohli přepínat mezi nasazeními v jednotlivých oblastech. Azure poskytuje globální směrování provozu a vyrovnávání zatížení prostřednictvím služby Azure Front Door a Azure Traffic Manageru 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.
• Seznamte se s doporučeními pro vysoce dostupný návrh v rámci více oblastí ve službě Azure Well-Architected Framework.