Strategie zotavení po havárii pro aplikace používající Azure SQL Database fondy

PLATÍ PRO: Azure SQL Database

Azure SQL Database poskytuje několik funkcí, které umožňují zajistit kontinuitu provozu vaší aplikace v případě katastrofických incidentů. Elastické fondy a jednotlivé databáze podporují stejný druh funkcí zotavení po havárii. Tento článek popisuje několik strategií využití prostředků pro využití prostředků pro práci s fondy, které využívají Azure SQL Database funkcí kontinuity provozu.

Tento článek používá následující kanonický vzor aplikace SaaS ISV:

Moderní cloudová webová aplikace obsahuje pro každého koncového uživatele jednu databázi. Isv má mnoho zákazníků, a proto používá mnoho databází, označované jako databáze tenantů. Vzhledem k tomu, že databáze tenantů obvykle mají nepředvídatelné vzory aktivit, používá funkce ISV elastický fond k tomu, aby byla databáze po delší dobu velmi předvídatelná. Elastický fond také zjednodušuje správu výkonu, když se aktivita uživatele zvyšuje. Kromě databází tenantů aplikace taky používá několik databází ke správě profilů uživatelů, zabezpečení, shromažďování vzorců využití atd. Dostupnost jednotlivých tenantů nemá vliv na dostupnost aplikace jako celku. Dostupnost a výkon databází pro správu je ale důležitá pro funkci aplikace a pokud jsou databáze pro správu offline, je celá aplikace offline.

Tento článek se zabývá strategiemi dr. pojednání o řadě scénářů, od aplikací, které jsou citlivé na náklady, až po ty, které mají přísné požadavky na dostupnost.

Poznámka:

Pokud používáte databáze Premium důležité pro firmy a elastické fondy, můžete je nastavit tak, aby byly odolné vůči regionálním výpadkům, a to tak, že je převedete na konfiguraci redundantního nasazení zóny. Viz Zónově redundantní databáze.

Scénář 1. Spuštění citlivé na náklady

Jsem startupová firma a velmi citlivá na náklady. Chci zjednodušit nasazení a správu aplikace a můžu mít omezenou sla pro jednotlivé zákazníky. Chci ale zajistit, aby aplikace jako celek nikdy nebyla offline.

Abyste vyhovli požadavkům na jednoduchost, nasaďte všechny databáze tenantů do jednoho pružného fondu v oblasti Azure podle vašeho výběru a nasaďte databáze pro správu jako geograficky replikované jednotlivé databáze. Pro obnovení po havárii tenantů použijte geografické obnovení, které je k dispozici bez dalších nákladů. Abyste zajistili dostupnost databází pro správu, geograficky je replikovat do jiné oblasti pomocí skupiny s automatickým převzetím služeb při selhání (krok 1). Průběžné náklady na konfiguraci obnovení po havárii v tomto scénáři se rovnají celkovým nákladům sekundárních databází. Tato konfigurace je znázorněná na následujícím diagramu.

Figure 1

Pokud dojde k výpadku v primární oblasti, postup obnovení aplikace online znázorňuje další diagram.

  • Skupina s podporou převzetí služeb při selhání zahájí automatické převzetí služeb při selhání databáze pro správu do oblasti správy. Aplikace se automaticky znovu připojí k novému primárnímu účtu a vytvoří se všechny nové účty a databáze tenantů v oblasti dr. Stávající zákazníci vidí data dočasně nedostupná.
  • Vytvořte elastický fond se stejnou konfigurací jako původní fond (2).
  • Geografické obnovení použijte k vytvoření kopií databází tenanta (3). Můžete zvážit aktivaci jednotlivých obnovení pomocí připojení koncových uživatelů nebo použít jiné schéma priority specifické pro aplikaci.

V tuto chvíli je vaše aplikace zpátky online v oblasti dr. Ale někteří zákazníci mají při přístupu ke svým datům zpoždění.

Figure 2

Pokud byl výpadk dočasný, je možné, že azure primární oblast obnoví před dokončením všech obnovení databáze v oblasti zotavení po obnovení. V takovém případě se přesouvání aplikace zpátky do primární oblasti zkrátí. Tento proces se bude odehrát v následujícím diagramu.

  • Zrušte všechny nevyřízené žádosti o geografické obnovení.
  • Převzetí služeb při selhání databází správy do primární oblasti (5). Po obnovení oblasti se ze starých primárek automaticky stanou sekundáři. Teď zase přechádne role.
  • Změňte připojovací řetězec aplikace tak, aby odkazl zpátky na primární oblast. Teď se v primární oblasti vytvářejí všechny nové účty a databáze tenantů. Někteří stávající zákazníci vidí data dočasně nedostupná.
  • Nastavte všechny databáze ve fondu dr. na jen pro čtení, aby se zajistilo, že je v oblasti dr. dr. (6) nemůžete změnit.
  • Pro každou databázi ve fondu zotavení po havárii, která se změnila od obnovení, přejmenujte nebo odstraňte odpovídající databáze v primárním fondu (7).
  • Zkopírujte aktualizované databáze z fondu dr. dr. do primárního fondu (8).
  • Odstranění fondu DR (9)

V tuto chvíli je vaše aplikace online v primární oblasti se všemi databázemi tenantů dostupnými v primárním fondu.

Figure 3

Výhoda

Hlavní výhodou této strategie jsou nízké průběžné náklady na redundanci datové vrstvy. Azure SQL Database automaticky zálohuje databáze bez přepsání aplikace bez dalších nákladů. Náklady vzniknou jenom v případě, že se obnoví elastické databáze.

Trade-off

Řešení je v tom, že úplné obnovení všech databází tenanta trvá velmi dlouho. Délka času závisí na celkovém počtu obnovení, které zahájíte v oblasti dr. I když upřednostňujete obnovení některých tenantů před ostatními, soutěžíte se všemi ostatními obnoveními, která jsou zahájena ve stejné oblasti jako rozhodčí řízení a omezení služeb, aby se minimalizoval celkový dopad na databáze stávajících zákazníků. Obnovení databází tenanta navíc nelze spustit, dokud se nevytáčí nový elastický fond v oblasti zotavení po havárii.

Scénář 2. Starší aplikace se službou vrstvené vrstvy

Jsem dospělá aplikace SaaS s nabídkami vrstvené služby a různými slanámi pro zkušební zákazníky a platící zákazníky. Pro zákazníky se zkušební verzí musím co nejvíce snížit náklady. Zákazníci zkušební verze mohou trvat prostoje, ale chci snížit jeho pravděpodobnost. Pro platící zákazníky je jakékoli prostoje riziko letu. Chci se proto ujistit, že platící zákazníci budou mít vždy přístup ke svým datům.

Pokud chcete tento scénář podporovat, oddělte zkušební tenanty od placených tenantů jejich umístěním do samostatných elastických fondů. Zákazníci zkušební verze mají nižší eDTU nebo virtuálnícore na tenanta a nižší sla s delším časem obnovení. Platící zákazníci jsou ve fondu s vyššími eDTU nebo virtuálnímicoremi na tenanta a vyšší sla. Aby byla zaručena nejnižší doba obnovení, databáze tenanta platících zákazníků se geograficky replikují. Tato konfigurace je znázorněná na následujícím diagramu.

Diagram shows a primary region and a D R region which employ geo-replication between the management database and paid customers primary pool and secondary pool with no replication for the trial customers pool.

Stejně jako v prvním scénáři jsou databáze pro správu docela aktivní, takže pro něj použijete jednu geografickou replikovanou databázi (1). Tím zajistíte předvídatelný výkon pro nová předplatná zákazníků, aktualizace profilů a další operace správy. Oblast, ve které jsou primární databáze správy, je primární oblast a oblast, ve které se nacházejí sekundární databáze správy, oblast dr.

Databáze tenantů platících zákazníků mají aktivní databáze v "placené" fondu zřízené v primární oblasti. Zřízení sekundárního fondu se stejným názvem v oblasti dr. Každý tenant se geograficky replikuje do sekundárního fondu (2). To umožňuje rychlé obnovení všech databází tenantů pomocí převzetí služeb při selhání.

Pokud dojde k výpadku v primární oblasti, postup obnovení aplikace online je znázorněný v následujícím diagramu:

Diagram shows an outage for the primary region, with failover to the management database, paid customer secondary pool, and creation and restore for trial customers.

  • Okamžitě převzetí služeb při selhání databází správy do oblasti dr. dr. (3).
  • Změňte připojovací řetězec aplikace tak, aby odkazl na oblast dr. Teď se v oblasti DR vytvářejí všechny nové účty a databáze tenantů. Stávající zákazníci zkušební verze vidí data dočasně nedostupná.
  • Převzetím služeb při selhání databází placeného tenanta do fondu v oblasti dr. Vzhledem k tomu, že převzetí služeb při selhání je rychlá změna úrovně metadat, zvažte optimalizaci, při které se jednotlivá převzetí služeb při selhání aktivuje na vyžádání prostřednictvím připojení koncových uživatelů.
  • Pokud byla velikost nebo hodnota virtuálníhocore sekundárního fondu eDTU nižší než primární, protože sekundární databáze vyžadovaly ke zpracování protokolů změn jenom v době, kdy byly sekundárními soubory, okamžitě zvyšte kapacitu fondu, aby se vyhověla celé zátěži všech tenantů (5).
  • Vytvořte nový elastický fond se stejným názvem a stejnou konfigurací v oblasti DR pro databáze zákazníků zkušební verze (6).
  • Po vytvoření fondu zkušebních zákazníků použijte geografické obnovení k obnovení databází jednotlivých zkušebních tenantů do nového fondu (7). Zvažte aktivaci jednotlivých obnovení pomocí připojení koncových uživatelů nebo použijte jiné schéma priority specifické pro aplikaci.

V tuto chvíli je vaše aplikace zpátky online v oblasti dr. Všichni platící zákazníci mají přístup ke svým datům, zatímco zkušební zákazníci mají při přístupu ke svým datům zpoždění.

Když Azure obnoví primární oblast po obnovení aplikace v oblasti zotavení po obnovení, můžete pokračovat ve spouštění aplikace v této oblasti nebo se můžete rozhodnout, že se vrátíte k primární oblasti. Pokud se primární oblast obnoví před dokončením procesu převzetí služeb při selhání, zvažte, jestli se hned nevrátí zpět. Obnovení trvá kroky uvedené v následujícím diagramu:

Diagram shows failback steps to implement after restoring the primary region.

  • Zrušte všechny nevyřízené žádosti o geografické obnovení.
  • Převzetí služeb při selhání databází pro správu (8). Po obnovení oblasti se ze starého primárního souboru automaticky stane sekundární. Teď se z něj stane znovu primární.
  • Převzetí služeb při selhání placených databází tenantů (9). Stejně tak se po obnovení oblasti ze starých primárek automaticky stanou sekundáři. Teď se z nich stávají primárci znovu.
  • Nastavte obnovené zkušební databáze, které se změnily v oblasti Dr. Nastavte jen pro čtení (10).
  • U každé databáze ve fondu dr. zkušebních verzí, které se od obnovení změnily, přejmenujte nebo odstraňte odpovídající databázi v primárním fondu zákazníků zkušební verze (11).
  • Zkopírujte aktualizované databáze z fondu dr. dr. do primárního fondu (12).
  • Odstraňte fond dr. dr. (13).

Poznámka:

Operace převzetí služeb při selhání je asynchronní. Abyste minimalizovali dobu obnovení, je důležité provést příkaz převzetí služeb při selhání databází tenanta v dávkách nejméně 20 databází.

Výhoda

Hlavní výhodou této strategie je, že poskytuje nejvyšší sla pro platící zákazníky. Zaručuje také, že nové zkušební verze se odblokují hned po vytvoření fondu zkušebních verzí dr.

Trade-off

Řešení je v tom, že toto nastavení zvyšuje celkové náklady na databáze tenantů o náklady sekundárního fondu dr. Kromě toho platí, že pokud má sekundární fond jinou velikost, po převzetí služeb při selhání budou mít platící zákazníci nižší výkon, dokud upgrade fondu v oblasti dr.

Scénář 3. Geograficky distribuované aplikace s vrstvenou službou

Mám zralou aplikaci SaaS s nabídkami služeb s vyšší úrovní. Chci svým placenám zákazníkům nabídnout velmi agresivní sla a minimalizovat riziko vzniku výpadků, protože i krátké přerušení může způsobit nespokojenost zákazníků. Je velmi důležité, aby platící zákazníci měli vždy přístup ke svým datům. Zkušební verze jsou bezplatné a smlouva SLA se během zkušebního období nenabídá.

Pokud chcete tento scénář podpořit, použijte tři samostatné elastické fondy. Zřídit dva fondy stejné velikosti s vysokými eDTU nebo virtuálními tržnicemi pro každou databázi ve dvou různých oblastech tak, aby obsahovaly databáze tenantů placených zákazníků. Třetí fond, který obsahuje tenanty zkušební verze, může mít nižší počet eDTU nebo virtuálních jadét na databázi a může být zřízen v jedné ze dvou oblastí.

Aby byla zaručena nejnižší doba obnovení během výpadků, databáze tenantů platících zákazníků se geograficky replikují s 50 % primárních databází v každé ze dvou oblastí. Podobně má každá oblast 50 % sekundárních databází. Pokud je oblast offline, ovlivní se tím jenom 50 % databází placených zákazníků a musí se převzetí služeb při selhání. Ostatní databáze zůstanou nedotčené. Tato konfigurace je znázorněná v následujícím diagramu:

Diagram shows a primary region called Region A and secondary region called Region B which employ geo-replication between the management database and paid customers primary pool and secondary pool with no replication for the trial customers pool.

Stejně jako v předchozích scénářích jsou databáze pro správu poměrně aktivní, takže je nakonfigurujte jako jednu geograficky replikovanou databázi (1). Tím se zajistí předvídatelný výkon nových předplatných zákazníků, aktualizací profilů a dalších operací správy. Oblast A je primární oblast pro databáze správy a oblast B se používá k obnovení databází pro správu.

Databáze tenantů platících zákazníků se také geograficky replikují, ale primárky a sekundáry jsou rozdělené mezi oblast A a oblast B (2). Primární databáze tenanta ovlivněné výpadkem tak selžou do jiné oblasti a stávají se dostupnými. Na druhou polovinu databází tenanta to nemá žádný vliv.

Další diagram znázorňuje kroky obnovení, které je dobré provést, pokud dojde k výpadku v oblasti A.

Diagram shows an outage for the primary region, with failover to the management database, paid customer secondary pool, and creation and restore for trial customers to region B.

  • Okamžitě převzetí služeb při selhání databází správy do oblasti B (3).
  • Změňte připojovací řetězec aplikace tak, aby odkazl na databáze pro správu v oblasti B. Změňte databáze pro správu tak, aby se v oblasti B vytvořily nové účty a databáze tenantů a že tam najdete i existující databáze tenantů. Stávající zákazníci zkušební verze vidí data dočasně nedostupná.
  • Převzetím služeb při selhání databází placeného tenanta s fondem 2 v oblasti B okamžitě obnovíte jejich dostupnost (4). Vzhledem k tomu, že převzetí služeb při selhání je rychlá změna úrovně metadat, můžete zvážit optimalizaci, při které se jednotlivá převzetí služeb při selhání aktivuje na vyžádání prostřednictvím připojení koncových uživatelů.
  • Vzhledem k tomu, že fond 2 teď obsahuje jenom primární databáze, zvyšuje se celkové zatížení fondu a může okamžitě zvětšit jeho velikost eDTU (5) nebo počet virtuálníchcore.
  • Vytvořte nový elastický fond se stejným názvem a stejnou konfigurací v oblasti B pro databáze zákazníků zkušební verze (6).
  • Po vytvoření fondu použijte geografické obnovení k obnovení databáze tenanta individuální zkušební verze do fondu (7). Můžete zvážit aktivaci jednotlivých obnovení pomocí připojení koncových uživatelů nebo použít jiné schéma priority specifické pro aplikaci.

Poznámka:

Operace převzetí služeb při selhání je asynchronní. Abyste minimalizovali dobu obnovení, je důležité spustit příkaz převzetí služeb při selhání databází tenanta v dávkách nejméně 20 databází.

V tomto okamžiku je vaše aplikace zpátky online v oblasti B. Všichni platící zákazníci mají přístup ke svým datům, zatímco zkušební zákazníci mají při přístupu ke svým datům zpoždění.

Když se oblast A obnoví, musíte se rozhodnout, jestli chcete pro zkušební zákazníky použít oblast B nebo obnovit fond zkušebních zákazníků v oblasti A. Jedním z kritérií může být % databází zkušebního tenanta změněných od obnovení. Bez ohledu na toto rozhodnutí musíte znovu vyvážit placené tenanty mezi dvěma fondy. Následující diagram znázorňuje proces, kdy se databáze zkušebního tenanta vrátí zpět do oblasti A.

Diagram shows failback steps to implement after restoring Region A.

  • Zrušte všechny nevyřízené žádosti o geografické obnovení fondu dr. zkušební verze.
  • Převzetí služeb při selhání databáze pro správu (8). Po obnovení oblasti se původní primární automaticky stal sekundárním. Teď se z něj stane znovu primární.
  • Vyberte, které placené databáze tenanta se daří vrátit do fondu 1, a iniciovat převzetí služeb při selhání do jejich secondaries (9).Select which paid tenant databases fail back to pool 1 and initiate failover to their secondaries (9). Po obnovení oblasti se všechny databáze ve fondu 1 automaticky staly sekundáři. Z 50 % z nich se teď stávají primárky.
  • Zmenšete velikost fondu 2 na původní eDTU (10) nebo počet virtuálníchcore.
  • Nastavte všechny obnovené zkušební databáze v oblasti B na jen pro čtení (11).
  • Pro každou databázi ve zkušebním fondu zotavení po havárii, která se změnila od obnovení, přejmenujte nebo odstraňte odpovídající databázi v primárním fondu zkušební verze (12).
  • Zkopírujte aktualizované databáze z fondu dr. dr. do primárního fondu (13).
  • Odstraňte fond dr. dr. (14).

Výhoda

Hlavní výhody této strategie jsou:

  • Podporuje nejagresivnější sla pro platící zákazníky, protože zajišťuje, že výpadky nesmí mít vliv na víc než 50 % databází tenantů.
  • Zaručuje, že nové zkušební verze se odblokují hned po vytvoření fondu zotavení po havárii během obnovení.
  • Umožňuje efektivnější využití kapacity fondu, protože 50 % sekundárních databází ve fondu 1 a fondu 2 je zaručeno, že bude méně aktivní než primární databáze.

Trade-offs

Hlavní obchody jsou:

  • Operace CRUD s databázemi pro správu mají nižší latenci pro koncové uživatele připojené k oblasti A než u koncových uživatelů připojených k oblasti B, protože jsou prováděny s primárními databázemi správy.
  • Vyžaduje složitější návrh databáze pro správu. Každý záznam tenanta má třeba značku umístění, kterou je potřeba změnit během převzetí služeb při selhání a obnovení po obnovení.
  • Platící zákazníci mohou do dokončení upgradu fondu v oblasti B zaznamenat nižší výkon než obvykle.

Souhrn

Tento článek se zaměřuje na strategie obnovení po havárii pro úroveň databáze, kterou používá aplikace SaaS ISV s více tenanty. Strategie, kterou zvolíte, je založená na potřebách aplikace, jako je obchodní model, smlouva SLA, kterou chcete zákazníkům nabídnout, omezení rozpočtu atd. Každá popsaná strategie popisuje výhody a obchod, abyste mohli učinit informované rozhodnutí. Vaše konkrétní aplikace pravděpodobně zahrnuje i další součásti Azure. Proto si prohlédněte pokyny pro zachování kontinuity jejich provozu a zosnovat s nimi obnovení úrovně databáze. Další informace o správě obnovení databázových aplikací v Azure najdete v tématu Návrh cloudových řešení pro obnovení po havárii.

Další kroky