Navrhování globálně dostupných služeb pomocí Azure SQL Database

PLATÍ PRO: Azure SQL Database

Při vytváření a nasazování cloudových služeb s Azure SQL Database používáte aktivní geografickou replikaci nebo skupiny s automatickým převzetím služeb při selhání k zajištění odolnosti vůči regionální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 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: Použití dvou oblastí Azure pro nepřetržitou práci s minimálním prostojem

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

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

V takovém případě je topologie nasazení aplikace optimalizovaná pro zpracování místních katastrof, když všechny součásti aplikace potřebují převzetí služeb při selhání společně. Následující diagram znázorňuje tuto topologii. V případě geografické redundance se prostředky aplikace nasadí do oblastí A a B. Zdroje v oblasti B se ale nevyužít, dokud oblast A nevyjde. Skupina převzetí služeb při selhání je nakonfigurovaná mezi oběma oblastmi ke správě připojení databáze, replikace 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í a zápis – název skupiny > .database.windows.net (1). Azure Traffic Manager je nastavená pro použití metody směrování priorit (2).  

Poznámka:

Azure Traffic Manager se v tomto článku používá jenom pro ilustrační účely. Můžete použít libovolné řešení pro vyrovnávání zatížení, které podporuje metodu směrování priorit.

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

Scenario 1. Configuration before the outage.

Po výpadku v primární oblasti zjistí SQL Database, že primární databáze není přístupná, a aktivuje převzetí služeb při selhání do sekundární oblasti na základě parametrů automatických zásad převzetí služeb při selhání (1). V závislosti na vaší aplikaci sla můžete nakonfigurovat období odkladu, které řídí čas mezi zjišťováním 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řed tí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. Opětovná připojení ale budou automaticky úspěšná, jakmile se dokončí převzetí služeb při selhání databáze. Když se neúspěšná oblast obnoví a znovu online, starý primární se automaticky znovu připojí jako nový sekundární. Následující diagram znázorňuje konfiguraci po převzetí služeb při selhání.

Poznámka:

Při opětovném 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í požadavků uživatelů. Webová aplikace i primární databáze jsou teď v oblasti B a zůstávají spolu umístěné.

Scenario 1. Configuration after failover

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 nedotčené (1). Traffic Manager zjistí, že připojení k oblasti B je přerušené, a označí webovou aplikaci koncového bodu 2 jako degradovaný (2). Výkon aplikace není v tomto případě ovlivněný, ale databáze se vystaví, a proto je vystavena vyššímu riziku ztráty dat v případě, že oblast A selže po jednom.

Poznámka:

Pro obnovení 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á jenom dvě oblasti. Tato konfigurace nezachrání vaši aplikaci před souběžnou katastrofickou chybou obou oblastí. V nepravděpodobném případě takového selhání můžete obnovit databáze ve třetí oblasti pomocí operace geografické obnovy.

Po zmírňování výpadku se sekundární databáze automaticky synchronizuje s primárním. 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í zdroj získal od převzetí služeb při selhání.

Poznámka:

Po zmírňování výpadku Traffic Manager začne směrovat připojení k aplikaci v oblasti A jako koncový bod s vyšší prioritou. Pokud chcete zachovat primární hodnotu v oblasti B na chvíli, měli byste odpovídajícím způsobem změnit tabulku priorit v profilu Správce trafic.

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

Scenario 1. Configuration after an outage in the secondary region.

Hlavní výhody tohoto návrhového vzoru jsou:

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

Hlavní kompromis je v tom, že zdroje aplikací v oblasti B jsou většinou nevyužité.

Scénář 2: Oblasti Azure pro nepřetržitou práci s maximálním zachováním dat

Tato možnost se nejlépe hodí pro aplikace s následujícími charakteristikami:

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

V tomto vzoru se aplikace přepne do režimu jen pro čtení, když připojení pro čtení a zápis začnou dosát chyb časového limitu. Webová aplikace se nasadí do obou oblastí a obsahuje připojení ke koncovému bodu naslouchacího procesu pro čtení a zápis a jiné připojení ke koncovému bodu naslouchacího procesu jen pro čtení (1). Profil Traffic Manager by měl používat směrování priority. Monitorování koncových bodů 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:

Scenario 2. Configuration before the outage.

Když Traffic Manager zjistí selhání připojení k oblasti A, automaticky přepne provoz uživatelů na instanci aplikace v oblasti B. S tímto vzorem je důležité nastavit období odkladu se ztrátou dat na dostatečně vysokou hodnotu, například 24 hodin. Zajistí, aby se při zmírňování výpadku v této době předešlo ztrátě dat. Když je webová aplikace v oblasti B aktivovaná, operace čtení a zápisu začnou selhávát. V tomto okamžiku by měl přepnout do režimu jen pro čtení (1). V tomto režimu se žádosti automaticky směrují do sekundární databáze. Pokud je výpadek způsobený katastrofickou chybou, pravděpodobně se v této lhůtě nespravděpodobně nezmírní. Po vypršení platnosti skupiny převzetí služeb při selhání se aktivuje převzetí služeb při selhání. Potom bude k dispozici naslouchací proces pro čtení a zápis 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 zjistí obnovení připojení v primární oblasti a přepne provoz uživatelů zpátky do instance 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 ukazuje předchozí diagram.

Scenario 2. Disaster recovery stages.

Pokud dojde k výpadku v oblasti B, Traffic Manager zjistí selhání koncového bodu webové aplikace-2 v oblasti B a označí ji jako zhoršené (1). Mezitím skupina převzetí služeb při selhání přepne posluchače jen pro čtení do oblasti A (2). Tento výpadk nemá vliv na prostředí koncových uživatelů, ale primární databáze se během výpadku vystaví. Následující diagram znázorňuje selhání v sekundární oblasti:

Scenario 2. Outage of the secondary region.

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

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

  • Zabrání ztrátě dat během dočasných výpadků.
  • Prostoje závisí jenom na tom, jak rychle Traffic Manager zjistí chybu připojení, která je konfigurovatelná.

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

Scénář 3: Přesouvání aplikací do jiné zeměpisné oblasti bez ztráty dat a blízké nule prostojů

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

  • Koncoví uživatelé mají k aplikaci přístup z různých zeměpisných lokalit.
  • Aplikace obsahuje úlohy jen pro čtení, které nezávisí na úplné synchronizaci s nejnovějšími aktualizacemi.
  • Přístup k datům pro zápis by měl být podporován ve stejné zeměpisné oblasti pro většinu uživatelů.
  • Latence čtení je důležitá pro prostředí koncových uživatelů

Abyste mohli tyto požadavky splnit, musíte zaručit, že se uživatelské zařízení vždy připojí k aplikaci nasazené ve stejné zeměpisné oblasti pro operace jen pro čtení, jako jsou údaje o procházení, analýzy atd. Zatímco operace OLTP se většinou zpracovávají ve stejné zeměpisné oblasti. Například během dne se operace OLTP zpracovávají ve stejné zeměpisné oblasti, ale během pracovní doby je možné je zpracovat v jiné zeměpisné oblasti. Pokud k aktivitě koncového uživatele většinou dochází během pracovní doby, můžete většinu času zaručit optimální výkon pro většinu uživatelů. Následující diagram znázorňuje tuto topologii.

Prostředky aplikace by měly být nasazené v každé zeměpisné oblasti, kde máte značné požadavky na využití. Pokud je například vaše aplikace aktivně používána ve Spojených státech, Evropské unii a jihovýchodní Asii, měla by se aplikace nasadit do všech těchto zeměpisných lokalit. Primární databáze by měla být dynamicky přepnuta z jedné zeměpisné oblasti na další na konci pracovní doby. Tato metoda se nazývá "sledujte slunce". Pracovní vytížení OLTP se k databázi vždy připojuje pomocí naslouchacího procesu pro čtení a zápis s názvem skupiny s podporou převzetí služeb při selhání > .database.windows.net (1). Úlohy jen pro čtení se připojí k místní databázi přímo pomocí názvu serveru koncového bodu databáze > .database.windows.net (2). Traffic Manager je nakonfigurovaný pomocí metody směrování výkonu. Zajistí, aby zařízení koncového uživatele bylo připojené k webové službě v nejbližší oblasti. Traffic Manager by mělo být nastavené s povoleným monitorováním koncových bodů pro každý koncový bod webové služby (3).

Poznámka:

Konfigurace skupiny převzetí služeb při selhání definuje, která oblast se používá pro převzetí služeb při selhání. Vzhledem k tomu, že nový primární je v jiné zeměpisné oblasti, výsledkem převzetí služeb při selhání je delší latence pro úlohy OLTP i jen pro čtení, dokud se ovlivněná oblast nevrátí do online režimu.

Scenario 3. Configuration with primary in East US.

Na konci dne, například v 23:00 místního času, by měly být aktivní databáze přepnuty do další oblasti (severní Evropa). Tento úkol je možné plně automatizovat pomocí Azure Logic Apps. Úkol zahrnuje následující kroky:

  • Přepnutí primárního serveru ve skupině s podporou převzetí služeb při selhání do severní Evropy pomocí přívětivé funkce převzetí služeb při selhání (1)
  • Odebrání skupiny převzetí služeb při selhání mezi východem USA a severní Evropou
  • Vytvořte novou skupinu převzetí služeb při selhání se stejným názvem, ale mezi severní a východní Asií (2).
  • Do této skupiny s podporou převzetí služeb při selhání (3) přidejte primární v severní Evropě a sekundární ve východní Asii.

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

Scenario 3. Transitioning the primary to North Europe.

Pokud dojde například k výpadku v severní Evropě, zahájí automatické převzetí služeb při selhání databáze skupina s podporou převzetí služeb při selhání, což efektivně vede k přesunutí aplikace do další oblasti před plánem (1). V takovém případě je východ USA jediným zbývajícím sekundárním regionem, dokud nebude severní Evropa zase online. Zbývající dvě oblasti slouží zákazníkům ve všech třech zeměpisných oblastech přepnutím rolí. Azure Logic Apps je třeba odpovídajícím způsobem upravit. Vzhledem k tomu, že zbývající oblasti čítá další provoz uživatelů z Evropy, ovlivňuje výkon aplikace nejen další latence, ale také zvýšený počet připojení koncových uživatelů. Po zmírňování výpadku v severní Evropě se sekundární databáze okamžitě synchronizuje s aktuálním primárním. Následující diagram znázorňuje výpadky v severní Evropě:

Scenario 3. Outage in North Europe.

Poznámka:

Můžete zkrátit dobu, kdy se prostředí koncového uživatele v Evropě zhoršuje dlouhou latencí. K tomu byste měli aktivně nasadit kopii aplikace a vytvořit sekundární databáze v jiné místní oblasti (západní Evropě) jako náhradu instance offline aplikace v severní Evropě. Až bude tato aplikace zase online, můžete se rozhodnout, jestli budete dál používat západní Evropu nebo jestli tam odeberete kopii aplikace a přepnete zpátky do severní Evropy.

Hlavní výhody tohoto návrhu jsou:

  • Úlohy aplikace jen pro čtení přistupuje k datům v oblasti skříní po celou dobu.
  • Úlohy aplikace pro čtení a zápis přistupuje k datům v nejbližší oblasti během období nejvyšší aktivity v každé zeměpisné oblasti.
  • Vzhledem k tomu, že je aplikace nasazená do několika oblastí, může bez významných prostojů přetrvat ztráta jedné z oblastí.

Existují ale některé kompromisy:

  • Výsledkem regionálního výpadku je geografická oblast, která bude ovlivněna delší latencí. Úlohy pro čtení i zápis i jen pro čtení jsou v aplikaci v jiné zeměpisné oblasti.
  • Úlohy jen pro čtení se musí připojit k jinému koncovému bodu v každé oblasti.

Plánování kontinuity provozu: Volba návrhu aplikace pro cloudové obnovení po havárii

Vaše specifická strategie obnovení cloudové katastrofy může tyto vzory návrhu kombinovat nebo rozšířit tak, aby co nejlépe vyhořely potřebám vaší aplikace. Jak už jsme zmínili dříve, strategie, kterou zvolíte, vychází z smlouvy SLA, kterou chcete zákazníkům nabídnout, a topologie nasazení aplikací. Následující tabulka porovnává volby založené na cíli bodu obnovení (RPO) a odhadované době obnovení (ERT).

Vzor Objekt RPO ERT
Active-passive deployment for disaster recovery with co-located database access Přístup pro čtení a zápis < 5 sekund Doba zjišťování chyb + TTL DNS
Nasazení s aktivním nasazením pro vyrovnávání zatížení aplikací Přístup pro čtení a zápis < 5 sekund Doba zjišťování chyb + TTL DNS
Aktivní pasivní nasazení pro zachování dat Přístup jen pro čtení < 5 sekund Přístup jen pro čtení = 0
Přístup pro čtení i zápis = nula Přístup pro čtení a zápis = Doba zjišťování chyb + období odkladu se ztrátou dat

Další kroky