Utforma en geografiskt distribuerad dataarkitektur
Det vi slutligen bör tänka på när det gäller vårt programs arkitekturdesign är datalagringsnivån. Vi vill se till att datan är både läsbar och skrivbar med fullständig funktionalitet efter att ett regionsomfattande fel har inträffat.
I leveransspårningsportalen valde vi att använda Azure Front Door för att skicka alla begäranden till App Services i regionen USA, östra. Om regionen USA, östra misslyckas identifierar Front Door felet och skickar begäranden om att duplicera App Services-komponenter i regionen USA, västra. I vår ursprungliga arkitektur för en region lagrade vi relationsdata i Azure SQL Database och halvstrukturerade data i Cosmos DB. Nu vill vi förstå hur vi kan se till att båda databaserna förblir tillgängliga om regionen USA, östra misslyckas.
Här lär vi oss hur du replikerar data mellan regioner och hur du ser till att redundansväxlingen kan ske snabbt, om det behövs.
Azure SQL Database
Om vi ska skapa en implementering för flera regioner av Azure SQL Database som lagrar relationsdata kan vi använda:
- Aktiv geo-replikering
- Automatiska redundansgrupper
Aktiv geo-replikering
Azure SQL Database kan replikera en databas och alla dess ändringar från en databas till en annan automatiskt med hjälp av aktiv geo-replikering. Det är endast den primära logiska servern som är värd för en skrivbar kopia av databasen. Vi kan skapa upp till fyra andra logiska servrar som är värdar för skrivskyddade kopior av databasen.
För leveransspårningsportalen skapar du en sekundär databas i regionen USA, västra och konfigurerar geo-replikering från regionen USA, östra. När ett regionalt fel inträffar omdirigerar Front Door användarbegäranden till App Services i regionen USA, västra. App Services och Azure Functions kan få åtkomst till relationsdata eftersom en kopia redan har replikerats till regionen USA, västra.
Den här ändringen sker automatiskt, men kom ihåg att den sekundära databasen i USA, västra är skrivskyddad. Om en användare försöker ändra data, till exempel genom att skapa en ny leverans, kan fel uppstå. Vi kan initiera en redundansväxling till USA, västra manuellt så fort vi märker problemet i Azure Portal. Om vi vill automatisera den här processen kan våra utvecklare skriva kod som anropar metoden failover i Azure SQL Database REST API.
Kommentar
Hanterade instanser av Azure SQL Database saknar stöd för aktiv geo-replikering. Hanterade instanser är utformade för att göra det enkelt att migrera data från en lokal SQL Server, samtidigt som säkerheten bibehålls. Om du använder en hanterad instans bör du överväga att använda redundansgrupper i stället.
Automatiska redundansgrupper
En automatisk redundansgrupp är en grupp med databaser där data replikeras automatiskt från en primär server till en eller flera sekundära servrar. Den här designen fungerar som aktiv geo-replikering och använder samma metod för datareplikering. Vi kan dock automatisera hanteringen av ett fel genom att definiera en princip.
För leveransportalen skapar vi en sekundär databas i regionen USA, västra. Sedan lägger vi till en princip som redundansväxlar den primära repliken av databasen till USA, västra om ett oåterkalleligt fel inträffar i regionen USA, östra. Om detta händer blir den repliken i USA, västra automatiskt den skrivbara primära databasen och alla funktioner upprätthålls.
Du kan fundera på att använda en automatisk redundansgrupp om du vill automatisera redundansen av den skrivbara databasen, utan att behöva skriva anpassad kod som utlöser den. Använd även automatiska redundansgrupper om databasen körs i en hanterad instans av Azure SQL Database.
Viktigt!
Replikeringen som ligger till grund för både aktiva geo-replikeringsgrupper och automatiska redundansgrupper är asynkrona. En bekräftelse skickas till klienten när en ändring tillämpas på den primära repliken. I det här läget anses transaktionen vara slutförd och replikeringen sker. Om ett fel inträffar kanske de senaste ändringarna i den primära databasen inte har hunnit replikeras till den sekundära repliken. Kom ihåg att efter ett haveri kan de senaste databasändringarna ha gått förlorade.
Azure Cosmos DB
Vår konfiguration är mindre komplex med Azure Cosmos DB eftersom den är utformad som ett multiregionalt molndatabassystem. Cosmos DB är en databas för flera modeller som kan lagra relationsdata, halvstrukturerade data och andra datatyper. Även om vi kör Cosmos DB i en enda region, replikeras data till flera instanser i olika feldomäner för att få bästa möjliga tillgänglighet.
När vi skapar ett Cosmos DB-konto för flera regioner kan vi välja mellan följande lägen:
Konton för flera regioner med flera skrivregioner.
I det här läget är alla kopior av databasen alltid skrivbara. Om ett fel uppstår i en region kommer ingen redundans att behövas.
Konton för flera regioner med en enda skrivregion.
I det här läget innehåller bara den primära regionen skrivbara databaser. De data som replikeras till de sekundära regionerna är skrivskyddade. Uppdateringar inaktiveras som standard om fel uppstår i den primära regionen. Vi kan dock välja att aktivera automatisk redundans så att Cosmos DB automatiskt redundansväxlar den primära, skrivbara kopian av databasen till en annan region.
Viktigt!
I Cosmos DB är datareplikeringen synkron. När en ändring tillämpas, anses inte transaktionen vara slutförd förrän den har replikerats till ett kvorum med repliker. Därefter skickas en bekräftelse till klienten. Om ett fel uppstår går inga nya ändringar förlorade eftersom replikeringen redan har utförts.