Návrh geograficky distribuované architektury dat
Poslední část architektonického návrhu naší aplikace, nad kterou se musíme zamyslet, je vrstva úložiště dat. Chceme mít jistotu, že při selhání celé oblasti nedojde k omezení funkčnosti čtení a zápisu dat.
Na portálu pro sledování zásilek jsme se rozhodli použít Azure Front Door k odesílání všech požadavků do App Services v oblasti USA – východ. Pokud oblast USA – východ selže, služba Front Door zjistí selhání a odešle požadavky na duplicitní komponenty služby App Services v oblasti USA – západ. V naší původní architektuře s jednou oblastí jsme relační data ukládali do Azure SQL Database a částečně strukturovaná data do Cosmos DB. Teď chceme pochopit, jak můžeme zajistit, aby obě databáze zůstaly dostupné, pokud oblast USA – východ selže.
Tady se dozvíte, jak replikovat data mezi oblastmi a jak zajistit, aby v případě potřeby mohlo dojít k převzetí služeb při selhání rychle.
Azure SQL Database
Pokud chceme vytvořit multiregionální implementaci Azure SQL Database pro ukládání relačních dat, můžeme použít některou z těchto možností:
- Aktivní geografická replikace
- Skupiny převzetí služeb při selhání
Aktivní geografická replikace
Pomocí funkce aktivní geografické replikace může Azure SQL Database automaticky replikovat databázi a všechny její změny z jedné databáze do jiné. Zapisovatelnou kopii databáze hostí pouze primární logický server. Můžeme vytvořit až čtyři další logické servery, které hostí kopie databáze jen pro čtení.
Pro portál pro sledování zásilek vytvořte sekundární databázi v oblasti USA – západ a nakonfigurujte geografickou replikaci z oblasti USA – východ. Pokud dojde k selhání oblasti, Front Door přesměruje žádosti uživatelů do služby App Services v oblasti USA – západ. App Services a Azure Functions můžou získat přístup k relačním datům, protože kopie se už replikovala do oblasti USA – západ.
Tato změna je automatická, ale pamatujte, že sekundární databáze v oblasti USA – západ je jen pro čtení. Pokud se uživatel pokusí upravit data, například vytvořením nové zásilky, může dojít k chybám. Jakmile na webu Azure Portal zaznamenáme problém, můžeme ručně zahájit převzetí služeb při selhání do OBLASTI USA – západ. Pokud chceme tento proces automatizovat, naši vývojáři mohou v rozhraní REST API Azure SQL Database napsat kód, který volá metodu failover.
Poznámka:
Spravované instance služby Azure SQL Database nepodporují aktivní geografickou replikaci. Spravované instance jsou navrženy tak, aby usnadňovaly migraci dat z místního SQL Serveru při zachování zabezpečení. Pokud používáte spravovanou instanci, zvažte místo toho použití skupin převzetí služeb při selhání.
Skupiny převzetí služeb při selhání
Skupina automatického převzetí služeb při selhání je skupina databází, kde se data automaticky replikují z primárního na jeden nebo více sekundárních serverů. Tento návrh je jako aktivní geografická replikace a používá stejnou metodu replikace dat. Můžeme ale definovat zásady a automatizovat tak odpověď na selhání.
Pro expediční portál vytvoříme sekundární databázi v oblasti USA – západ. Potom přidáme zásadu, která převezme služby při selhání primární repliky databáze do oblasti USA – západ, pokud dojde ke katastrofickému selhání v oblasti USA – východ. V takovém případě se replika v oblasti USA – západ automaticky stane primární databází, do které je možné zapisovat, a plná funkčnost zůstane zachována.
Pokud chcete automatizovat převzetí služeb databáze s možností zápisu při selhání bez psaní vlastního kódu, který převzetí aktivuje, zvažte použití skupiny automatického převzetí služeb při selhání. Pokud se vaše databáze spouští ve spravované instanci Azure SQL Database, použijte také skupiny automatického převzetí služeb při selhání.
Důležité
Replikace, která je základem aktivní geografické replikace i skupin automatického převzetí služeb při selhání, jsou asynchronní. Když se u primární repliky použije změna, odešle se klientovi potvrzení. V tomto okamžiku se transakce považuje za dokončenou a dojde k replikaci. Pokud dojde k selhání, nemusí se poslední změny provedené v primární databázi replikovat do sekundární databáze. Mějte na paměti, že po katastrofě mohlo dojít ke ztrátě posledních změn databáze.
Azure Cosmos DB
Naše konfigurace je s Azure Cosmos DB méně složitá, protože je navržená jako multiregionální cloudový databázový systém. Cosmos DB je vícemodelová databáze, která umožňuje ukládat relační data, částečně strukturovaná data a další formy dat. I když spustíme Cosmos DB v jedné oblasti, data se replikují do více instancí napříč různými doménami selhání, aby se zajistila nejlepší dostupnost.
Při vytváření účtu Cosmos DB jako multiregionálního si můžeme vybrat z následujících režimů:
Multiregionální účty s více oblastmi zápisu
V tomto režimu jsou všechny kopie databáze vždy zapisovatelné. Pokud oblast selže, není nutné provádět převzetí služeb při selhání.
Multiregionální účty s jednou oblastí zápisu
V tomto režimu pouze primární oblast obsahuje databáze s možností zápisu. Data replikovaná do sekundárních oblastí jsou jen pro čtení. Při selhání primární oblasti jsou aktualizace standardně zakázány. Můžeme ale vybrat možnost povolení automatického převzetí služeb při selhání, aby služba Cosmos DB automaticky předala služby primární kopie databáze s možností zápisu do jiné oblasti.
Důležité
V Cosmos DB je replikace dat synchronní. Při použití změny se transakce nepovažuje za dokončenou, dokud není replikována do kvora replik. Potom se klientovi odešle potvrzení. Když dojde k selhání, žádné poslední změny se neztratí, protože replikace už byla provedena.