Zálohování a zotavení po havárii pro aplikace Azure

Zotavení po havárii je proces obnovení funkčnosti aplikace při probuzení závažné ztráty.

V cloudu potvrzuji, že dojde k selhání. Místo snahy kompletně zabránit selháním je cílem minimalizace dopadu selhání jedné komponenty. Testování je jedním ze způsobů, jak tyto efekty minimalizovat. Testování aplikací, pokud je to možné, byste měli provádět, ale při selhání musíte být připraveni. V takovém případě se strategie zálohování a obnovení budou důležité.

Vaše tolerance pro omezenou funkčnost během havárie je obchodní rozhodnutí, které se liší od jedné aplikace po další. Může být přijatelné, aby některé aplikace byly nedostupné nebo byly částečně dostupné s omezenou funkčností nebo opožděným zpracováním po určitou dobu. U ostatních aplikací se neakceptuje žádné omezené funkce.

Klíčové body

  • V pravidelných intervalech Vytvářejte a testujte plán zotavení po havárii s využitím scénářů selhání klíčů.
  • Navrhněte strategii zotavení po havárii, která spustí většinu aplikací s omezenou funkčností.
  • Navrhněte strategii zálohování, která je přizpůsobená obchodním požadavkům a okolnostem aplikace.
  • Automatizace kroků a procesů převzetí služeb při selhání a navrácení služeb po obnovení
  • Otestujte a ověřte, jestli úspěšně převzetí služeb při selhání a navrácení služeb po obnovení proběhlo aspoň jednou

Plán zotavení po havárii

Začněte vytvořením plánu obnovení. Plán se považuje za dokončený poté, co byl plně testován. Zahrňte lidi, procesy a aplikace potřebné k obnovení funkčnosti v rámci smlouvy SLA (Service-level agreement), kterou jste definovali pro vaše zákazníky.

Při vytváření a testování plánu zotavení po havárii Vezměte v úvahu následující návrhy:

  • Zahrňte proces pro kontaktování podpory a zvýšení problémů. Tyto informace vám pomůžou zabránit dlouhotrvajícímu výpadku při prvním použití procesu obnovení.
  • Vyhodnoťte obchodní dopad selhání aplikace.
  • Vyberte architekturu obnovení mezi jednotlivými oblastmi pro klíčové aplikace.
  • Identifikujte konkrétního vlastníka plánu zotavení po havárii, včetně automatizace a testování.
  • Zdokumentujte proces, zejména ruční kroky.
  • Automatizujte proces co nejvíce.
  • Vytvořte strategii zálohování pro všechny referenční a transakční data a pravidelně provádějte obnovu záložního zálohování.
  • Nastavte výstrahy pro zásobník služeb Azure spotřebovaných vaší aplikací.
  • Školením provozních pracovníků proveďte plán.
  • K ověření a vylepšení plánu Provádějte pravidelné simulace havárie.

Pokud používáte Azure Site Recovery k replikaci virtuálních počítačů, vytvořte plně automatizovaný plán obnovení pro převzetí služeb při selhání celou aplikaci.

Testování provozní připravenosti

Proveďte test provozní připravenosti pro převzetí služeb při selhání do sekundární oblasti a pro navrácení služeb po obnovení do primární oblasti. Řada služeb Azure podporuje postupy zotavení po havárii s využitím ručního převzetí služeb při selhání nebo testovacího převzetí služeb při selhání. Alternativně můžete simulovat výpadky vypnutím nebo odebráním služeb Azure.

Automatizované provozní odpovědi by se měly často testovat v rámci normálního životního cyklu aplikace, aby se zajistila provozní efektivita.

Převzetí služeb při selhání a testování po obnovení

Otestujte převzetí služeb při selhání a navrácení služeb po obnovení, abyste ověřili, že se závislé služby vaší aplikace při zotavení po havárii synchronizují. Změny systémů a operací mohou mít vliv na funkce převzetí služeb při selhání a navrácení služeb po obnovení, ale dopad nemusí být zjištěn, dokud nedojde k selhání hlavního systému nebo dojde k jeho přetížení. Otestujte možnosti převzetí služeb při selhání, než se budou muset kompenzovat při živém problému. Ujistěte se také, že ve správném pořadí převzetí služeb při selhání závislých služeb a navrácení služeb po obnovení.

Pokud k replikaci virtuálních počítačů používáte Azure Site Recovery , spusťte při testování převzetí služeb při selhání pravidelné procházení po havárii, abyste ověřili strategii pro replikaci. Testovací převzetí služeb při selhání nemá vliv na probíhající replikaci virtuálních počítačů nebo na vaše produkční prostředí. Další informace najdete v tématu spuštění postupu zotavení po havárii do Azure.

Výpadek závislé služby

U každé závislé služby byste měli pochopit důsledky přerušení služby a způsob, jakým bude aplikace reagovat. Mnohé služby zahrnují funkce, které podporují odolnost a dostupnost, takže vyhodnocování každé služby nezávisle může zlepšit plán zotavení po havárii. Například Azure Event Hubs podporuje převzetí služeb při selhání sekundárním oborem názvů.

Výpadek sítě

Pokud jsou části sítě Azure nedostupné, možná nebudete mít přístup k vaší aplikaci nebo datům. V této situaci doporučujeme navrhnout strategii zotavení po havárii, aby se spouštěla většina aplikací s omezenou funkčností.

Pokud omezení funkcí není možnost, zbývající možnosti jsou výpadky aplikace nebo převzetí služeb při selhání do alternativní oblasti.

Ve scénáři se sníženou funkčností:

  • Pokud vaše aplikace nemá přístup k datům z důvodu výpadku sítě Azure, může být možné spustit místně s omezenou funkčností aplikace pomocí dat uložených v mezipaměti.
  • Dokud nebude připojení obnoveno, může být možné ukládat data do alternativního umístění.

Automatizaci obnovení

Kroky potřebné k obnovení nebo převzetí služeb při selhání aplikace v sekundární oblasti Azure v situacích selhání by měly být kodifikováné, nejlépe v automatizovaných způsobech, aby se zajistilo, že možnosti existují k účinné reakci na výpadky způsobem, který omezuje dopad. Pro zachycení procesu potřebného k navrácení služeb po obnovení do primární oblasti by se měly také provést podobné kodifikováné kroky, jakmile bude vyřešen problém s aktivací převzetí služeb při selhání.

Při automatizaci postupů převzetí služeb při selhání se ujistěte, že nástroj používaný pro orchestraci převzetí služeb při selhání se taky považuje za v strategii převzetí služeb při selhání Pokud například spustíte převzetí služeb při selhání z Jenkinse běžícího na VIRTUÁLNÍm počítači, dojde k problémům, pokud je tento virtuální počítač součástí výpadku. Azure DevOps Projekty jsou vymezeny také v oblasti.

Strategie zálohování

K dispozici je řada alternativních strategií pro implementaci distribuovaných výpočtů napříč oblastmi. Ty musí být upraveny na konkrétní obchodní požadavky a podmínky aplikace. V nejvyšší úrovni je možné tyto přístupy rozdělit do následujících kategorií:

  • Opětovné nasazení při havárii: v tomto postupu se aplikace znovu nasadí od začátku v době havárie. To je vhodné pro nekritické aplikace, které nevyžadují garantovanou dobu obnovení.

  • Volná (aktivní/pasivní): sekundární hostovaná služba se vytvoří v alternativní oblasti a role se nasadí, aby se zaručila Minimální kapacita. role ale neobdrží provozní provoz. Tento přístup je užitečný pro aplikace, které nejsou navržené pro distribuci provozu napříč oblastmi.

  • Vyměnitelné za chodu (aktivní/aktivní): aplikace je navržená tak, aby přijímala provozní zatížení ve více oblastech. Cloudové služby v jednotlivých oblastech můžou být nakonfigurované pro větší kapacitu, než je potřeba pro účely zotavení po havárii. Cloudové služby se případně můžou v případě havárie a převzetí služeb při selhání škálovat podle potřeby. Tento přístup vyžaduje značné investice do návrhu aplikací, ale má významné výhody. Mezi ně patří nízká a zaručená doba obnovení, nepřetržité testování všech umístění obnovení a efektivní využití kapacity.

Plánování regionálních selhání

Azure je rozdělen fyzicky a logicky do jednotek nazývaných oblasti. Oblast se skládá z jednoho nebo více datových center v těsné blízkosti. Řada oblastí a služeb také podporuje zóny dostupnosti, které se dají použít k zajištění větší odolnosti proti výpadkům v jednom datovém centru. Zvažte použití oblastí se zónami dostupnosti ke zlepšení dostupnosti řešení.

Ve výjimečných případech je možné, že zařízení v celé zóně dostupnosti nebo oblasti můžou být nepřístupná, například kvůli selháním sítě. Nebo můžete zařízení zcela ztratit, například kvůli přirozené havárii. Azure obsahuje možnosti pro vytváření aplikací, které jsou distribuované napříč zónami a oblastmi. Tato distribuce pomáhá minimalizovat možnost, že selhání v jedné zóně nebo oblasti může ovlivnit jiné zóny nebo oblasti.

Další krok

Vraťte se k hlavnímu článku: testování