Návrh globálně dostupných služeb pomocí Azure SQL Database

  • Článek
  • 11 min ke čtení

PLATÍ PRO: Azure SQL Database

Při sestavování a nasazování cloudových služeb s Azure SQL Database využíváte aktivní geografickou replikaci nebo skupiny automatického převzetí služeb při selhání, které zajišťují odolnost proti oblastním výpadkům a katastrofickým selháním. Stejná funkce umožňuje vytvářet globálně distribuované aplikace optimalizované pro místní přístup k datům. Tento článek popisuje běžné vzory aplikací, včetně výhod a výhod jednotlivých možností.

Poznámka

Pokud používáte databáze Premium Pro důležité obchodní informace elastické fondy, můžete je odolné vůči oblastním výpadkům tím, že je převedete na konfiguraci zónově redundantního nasazení. Viz Zónově redundantní databáze.

Scénář 1: Použití dvou oblastí Azure pro zajištění kontinuity podnikových prostředí s minimálními výpadky

V tomto scénáři mají aplikace následující vlastnosti:

  • Aplikace je aktivní v jedné oblasti Azure.
  • Všechny databázové relace vyžadují přístup ke čtení a zápisu (RW) k datům.
  • Aby se snížila latence a náklady na provoz, musí se sbalovat webová a datová vrstva.
  • V podstatě je pro tyto aplikace prostoje vyšší obchodní riziko než ztráta dat.

V takovém případě je topologie nasazení aplikace optimalizovaná pro zpracování místních havárií, když všechny komponenty aplikace potřebují převzetí služeb při selhání společně. Tuto topologii znázorňuje následující diagram. Kvůli geografické redundanci se prostředky aplikace nasadí do oblastí A a B. Prostředky v oblasti B se ale nevyužít, dokud se nepodaří oblast A. Mezi oběma oblastmi je nakonfigurovaná skupina převzetí služeb při selhání, která spravuje připojení k databázi, replikaci a převzetí služeb při selhání. Webová služba v obou oblastech je nakonfigurovaná pro přístup k databázi prostřednictvím naslouchacího procesu pro čtení i zápis s názvem skupiny převzetí služeb při selhání < > .database.windows.net (1). Azure Traffic Manager je nastavená pro použití metody prioritního směrování (2).

Poznámka

Azure Traffic Manager se v tomto článku používá pouze pro ilustraci. Můžete použít libovolné řešení vyrovnávání zatížení, které podporuje metodu prioritního směrování.

Následující diagram znázorňuje tuto konfiguraci před výpadkem:

1. scénář: Konfigurace před výpadkem.

Po výpadku v primární oblasti zjistí SQL Database, že primární databáze není přístupná, a na základě parametrů zásad automatického převzetí služeb při selhání (1) aktivuje převzetí služeb při selhání sekundární oblastí. V závislosti na sla vaší aplikace můžete nakonfigurovat období odkladu, které řídí dobu mezi detekcí výpadku a samotným převzetím služeb při selhání. Je možné, že Azure Traffic Manager převzetí služeb při selhání koncového bodu předtím, než skupina převzetí služeb při selhání aktivuje převzetí služeb při selhání databáze. V takovém případě se webová aplikace nemůže okamžitě znovu připojit k databázi. Jakmile se ale převzetí služeb při selhání databáze dokončí, opětovná připojení budou automaticky úspěšná. Když se neúspěšná oblast obnoví a znovu online, stará primární oblast se automaticky znovu připojí jako nová sekundární oblast. Následující diagram znázorňuje konfiguraci po převzetí služeb při selhání.

Poznámka

Během opětovného připojení dojde ke ztrátě všech transakcí potvrzených po převzetí služeb při selhání. Po dokončení převzetí služeb při selhání se aplikace v oblasti B může znovu připojit a restartovat zpracování žádostí uživatelů. Webová aplikace i primární databáze jsou teď v oblasti B a zůstávají spolu umístěné.

1. scénář: Konfigurace po převzetí služeb při selhání

Pokud dojde k výpadku v oblasti B, proces replikace mezi primární a sekundární databází se pozastaví, ale propojení mezi těmito dvěma databázemi zůstane beze změny (1). Traffic Manager zjistí, že připojení k oblasti B je přerušené, a označí webovou aplikaci koncového bodu 2 jako snížený výkon (2). Výkon aplikace není v tomto případě ovlivněný, ale databáze se vystaví, a proto hrozí vyšší riziko ztráty dat v případě selhání oblasti A po sledu.

Poznámka

Pro zotavení po havárii doporučujeme konfiguraci s nasazením aplikace omezenou na dvě oblasti. Je to proto, že většina zeměpisných oblastí Azure má pouze dvě oblasti. Tato konfigurace neochrání vaši aplikaci před souběžně katastrofálním selháním obou oblastí. V nepravděpodobném případě takového selhání můžete obnovit databáze ve třetí oblasti pomocí operace geografické obnovení.

Jakmile je výpadek zmírněn, sekundární databáze se automaticky znovu synchronizuje s primární databází. Během synchronizace může být ovlivněn výkon primárního serveru. Konkrétní dopad závisí na množství dat, která nový primární server získal od převzetí služeb při selhání.

Poznámka

Po zmírnění výpadku začne Traffic Manager připojení k aplikaci v oblasti A jako koncový bod s vyšší prioritou. Pokud máte v úmyslu zachovat primární oblast v oblasti B na chvíli, měli byste tabulku priorit v profilu Trafic Manager odpovídajícím způsobem změnit.

Následující diagram znázorňuje výpadky v sekundární oblasti:

1. scénář: Konfigurace po výpadku v sekundární oblasti

Hlavní výhody tohoto vzoru návrhu:

  • Stejná webová aplikace se nasazovat do obou oblastí bez jakékoli konfigurace specifické pro oblast a nevyžaduje další logiku pro správu převzetí služeb při selhání.
  • Převzetí služeb při selhání nemá vliv na výkon aplikace, protože webová aplikace a databáze jsou vždy umístěné ve spolupráci.

Hlavním kompromisem je, že prostředky aplikace v oblasti B jsou většinu času nevyužité.

Scénář 2: Oblasti Azure pro zajištění provozní kontinuity s maximálním zachováním dat

Tato možnost je nejlepší pro aplikace s následujícími charakteristikami:

  • Jakákoli ztráta dat je vysoké obchodní riziko. Převzetí služeb při selhání databáze je možné použít jako poslední možnost, pouze pokud je výpadek způsoben katastrofálním selháním.
  • Aplikace podporuje režimy operací jen pro čtení a zápis a může po určitou dobu pracovat v režimu jen pro čtení.

V tomto modelu aplikace přepne do režimu jen pro čtení, když připojení pro čtení i zápis začnou dochádovat chyby časového limitu. Webová aplikace je nasazená v obou oblastech a zahrnuje připojení ke koncovému bodu naslouchacího procesu pro čtení i zápis a jiné připojení ke koncovému bodu naslouchacího procesu jen pro čtení (1). Profil Traffic Manager měl používat směrování podle priority. Monitorování koncového bodu by mělo být povolené pro koncový bod aplikace v každé oblasti (2).

Následující diagram znázorňuje tuto konfiguraci před výpadkem:

2. scénář: Konfigurace před výpadkem.

Když Traffic Manager zjistí selhání připojení k oblasti A, automaticky přepne uživatelský provoz na instanci aplikace v oblasti B. U tohoto modelu je důležité nastavit období odkladu se ztrátou dat na dostatečně vysokou hodnotu, například na 24 hodin. Zajišťuje, aby v případě zmírnění výpadku během této doby nedošlo ke ztrátě dat. Když je webová aplikace v oblasti B aktivovaná, operace čtení a zápisu začnou selhávají. V tomto okamžiku by se měl přepnout do režimu jen pro čtení (1). V tomto režimu se požadavky automaticky směrují do sekundární databáze. Pokud je výpadek způsoben katastrofickým selháním, pravděpodobně ho během období odkladu není možné zmírnit. Po vypršení platnosti skupina převzetí služeb při selhání aktivuje převzetí služeb při selhání. Potom bude naslouchací proces pro čtení i zápis dostupný a připojení k ní přestanou selhávající (2). Následující diagram znázorňuje dvě fáze procesu obnovení.

Poznámka

Pokud je výpadek v primární oblasti v období odkladu zmírněn, Traffic Manager detekuje obnovení připojení v primární oblasti a přepne uživatelský provoz zpět na instanci aplikace v oblasti A. Tato instance aplikace pokračuje a funguje v režimu čtení i zápisu pomocí primární databáze v oblasti A, jak je znázorněno v předchozím diagramu.

2. scénář: Fáze zotavení po havárii:

Pokud dojde k výpadku v oblasti B, Traffic Manager detekuje selhání koncové aplikace web-app-2 v oblasti B a označí ji jako sníženou (1). Do té doby skupina převzetí služeb při selhání přepne naslouchací proces jen pro čtení do oblasti A (2). Tento výpadk nemá vliv na prostředí koncového uživatele, ale během výpadku je zveřejněna primární databáze. Následující diagram znázorňuje selhání v sekundární oblasti:

2. scénář: Výpadky sekundární oblasti.

Po zmírnění výpadku se sekundární databáze okamžitě synchronizuje s primární databází a naslouchací proces jen pro čtení se přepne zpět na sekundární databázi v oblasti B. Během synchronizace může být výkon primárního serveru mírně ovlivněný v závislosti na množství dat, která je potřeba synchronizovat.

Tento vzor návrhu má několik výhod:

  • Zabrání ztrátě dat během dočasných výpadků.
  • Výpadek závisí jenom na tom, Traffic Manager rychle zjistí selhání připojení, což je konfigurovatelné.

Kompromis je v tom, že aplikace musí být schopná pracovat v režimu jen pro čtení.

Scénář 3: Přemístění aplikace do jiné geografické oblasti bez ztráty dat a bez nulového výpadku

V tomto scénáři má aplikace následující vlastnosti:

  • Koncoví uživatelé přistupuje k aplikaci z různých geografických lokalit.
  • Aplikace obsahuje úlohy jen pro čtení, které nezávisí na úplné synchronizaci s nejnovějšími aktualizacemi.
  • Pro většinu uživatelů by měl být přístup pro zápis k datům podporovaný ve stejné geografické oblasti.
  • Latence čtení je pro koncové uživatele kritická.

Aby bylo možné tyto požadavky splnit, musíte zajistit, aby se uživatelské zařízení vždy připojoval k aplikaci nasazené ve stejné geografické oblasti pro operace jen pro čtení, jako je procházení dat, analýza atd. Zatímco operace OLTP se většinu času zpracovávají ve stejné geografické oblasti. Například během dne se operace OLTP zpracovávají ve stejné zeměpisné oblasti, ale mimo pracovní dobu je možné je zpracovat v jiné geografické oblasti. Pokud se aktivita koncového uživatele většinou stane během pracovní doby, můžete zajistit optimální výkon pro většinu uživatelů v většinu času. Tato topologie je znázorněna na následujícím obrázku.

Prostředky aplikace by se měly nasadit v každé geografické oblasti, kde máte významné nároky na využití. Například pokud se vaše aplikace aktivně používá v USA, Evropské unii a Jižní Východní Asie aplikace by měla být nasazená do všech těchto zeměpisných oblastí. Primární databáze by se měla dynamicky přepínat mezi jednotlivými geografickými oblastmi na konci pracovní doby. Tato metoda se nazývá "následovat na Sun". Úloha OLTP se vždy připojuje k databázi prostřednictvím naslouchacího procesu pro čtení i zápis < převzetí služeb při selhání-Group-name > . Database.Windows.NET (1). Úloha jen pro čtení se připojuje k místní databázi přímo pomocí serveru koncového bodu serveru databáze < -name > . Database.Windows.NET (2). Traffic Manager je nakonfigurována pomocí metody směrování výkonu. Zajišťuje, aby bylo zařízení koncového uživatele připojeno k webové službě v nejbližší oblasti. Traffic Manager by měl být nastaven s povoleným monitorováním koncových bodů pro každý koncový bod webové služby (3).

Poznámka

Tato oblast se používá pro převzetí služeb při selhání konfigurace skupiny převzetí služeb při selhání. Vzhledem k tomu, že nový primární objekt je v jiné geografické úrovni, jsou výsledky převzetí služeb při selhání v delší době pro OLTP i pro úlohy jen pro čtení, dokud se ovlivněná oblast znovu nevrátí do režimu online.

Scénář 3. Konfigurace s primárním v Východní USA.

Na konci dne, například v 11 místního času, by měly být aktivní databáze přepnuty do další oblasti (Severní Evropa). tato úloha se dá plně automatizovat pomocí Azure Logic Apps. Úkol zahrnuje následující kroky:

  • Přepnutí primárního serveru ve skupině převzetí služeb při selhání na Severní Evropa s použitím popisného převzetí služeb při selhání (1
  • Odebrání skupiny převzetí služeb při selhání mezi Východní USA a Severní Evropa
  • Vytvoří novou skupinu převzetí služeb při selhání se stejným názvem, ale mezi Severní Evropa a Východní Asie (2).
  • Do této skupiny převzetí služeb při selhání přidejte primární Severní Evropa a sekundární Východní Asie.

Následující diagram znázorňuje novou konfiguraci po plánovaném převzetí služeb při selhání:

Scénář 3. Převod primárního na Severní Evropa.

Pokud dojde k výpadku v Severní Evropa například automatické převzetí služeb při selhání databáze je iniciováno skupinou převzetí služeb při selhání, což efektivně vede k přesunu aplikace do další oblasti před plánem (1). V takovém případě je USA – východ jedinou zbývající sekundární oblastí, dokud Severní Evropa znovu nepřejdete do režimu online. Zbývající dvě oblasti slouží zákazníkům ve všech třech zeměpisných oblastech přepínáním rolí. Azure Logic Apps musí být upraveny odpovídajícím způsobem. Vzhledem k tomu, že zbývající oblasti získají další uživatelský provoz z Evropy, výkon aplikace bude mít vliv nejen na další latenci, ale také na zvýšený počet připojení koncových uživatelů. Po omezení výpadku v Severní Evropa je sekundární databáze okamžitě synchronizovaná s aktuální primární databází. Následující diagram znázorňuje výpadek Severní Evropa:

Scénář 3. Výpadek v Severní Evropa.

Poznámka

Můžete zkrátit čas, kdy se činnost koncového uživatele v Evropě sníží o dlouhou latenci. K tomu byste měli proaktivně nasadit kopii aplikace a vytvořit sekundární databáze v jiné místní oblasti (Západní Evropa) jako náhradu offline instance aplikace v Severní Evropa. Když je znovu online, můžete se rozhodnout, jestli chcete i nadále používat Západní Evropa nebo odebrat kopii aplikace a přepnout zpátky na použití Severní Evropa.

Klíčové výhody tohoto návrhu:

  • Úloha aplikace jen pro čtení přistupuje k datům v oblasti skříní.
  • Úloha čtení a zápisu aplikací přistupuje k datům v nejbližší oblasti během období nejvyšší aktivity v jednotlivých geografických oblastech.
  • Vzhledem k tomu, že aplikace je nasazena do více oblastí, může dojít ke ztrátě jedné z oblastí bez jakéhokoli významného výpadku.

Existují však některé kompromisy:

  • Oblastní výpadek má za následek, že by to ovlivnilo delší latenci. Aplikace v jiném geografickém programu obsluhuje úlohy pro čtení i zápis i pro čtení.
  • Úlohy jen pro čtení se musí připojit k jinému koncovému bodu v každé oblasti.

Plánování kontinuity podnikových aplikací: volba návrhu aplikace pro zotavení po havárii v cloudu

Vaše konkrétní strategie cloudového zotavení po havárii může tyto vzory návrhu zkombinovat nebo roztáhnout tak, aby co nejlépe splňovala požadavky vaší aplikace. Jak už bylo zmíněno dříve, strategie, kterou zvolíte, je založená na smlouvě SLA, kterou chcete nabídnout vašim zákazníkům a topologii nasazení aplikace. Následující tabulka porovnává tyto možnosti podle rozhodnutí bodu obnovení (RPO) a odhadované doby obnovení (ERT), které vám pomůžou s vaším rozhodnutím.

Vzor RPO ERT
Aktivní – pasivní nasazení pro zotavení po havárii s společně umístěným přístupem k databázi Přístup pro čtení i zápis < 5 sec Čas detekce selhání + hodnota TTL systému DNS
Aktivní – aktivní nasazení pro vyrovnávání zatížení aplikace Přístup pro čtení i zápis < 5 sec Čas detekce selhání + hodnota TTL systému DNS
Aktivní – pasivní nasazení pro zachování dat Přístup jen pro čtení < 5 sec Přístup jen pro čtení = 0
Přístup pro čtení i zápis = nula Přístup pro čtení i zápis = doba detekce selhání + období odkladu s ztrátou dat

Další kroky