Wereldwijd beschikbare services ontwerpen met behulp van Azure SQL Database

VAN TOEPASSING OP: Azure SQL Database

Wanneer u cloudservices bouwt en implementeert met Azure SQL Database, gebruikt u actieve geo-replicatie of groepen voor automatische failover om tolerantie te bieden voor regionale storingen en onherstelbare storingen. Met dezelfde functie kunt u wereldwijd gedistribueerde toepassingen maken die zijn geoptimaliseerd voor lokale toegang tot de gegevens. In dit artikel worden algemene toepassingspatronen besproken, met inbegrip van de voordelen en afwegingen van elke optie.

Scenario 1: Twee Azure-regio's gebruiken voor bedrijfscontinuïteit met minimale downtime

In dit scenario hebben de toepassingen de volgende kenmerken:

• De toepassing is actief in één Azure-regio
• Voor alle databasesessies is lees- en schrijftoegang (RW) tot gegevens vereist
• De weblaag en de gegevenslaag moeten samen worden gebruikt om latentie en verkeerskosten te verminderen
• Uitvaltijd is in principe een hoger bedrijfsrisico voor deze toepassingen dan gegevensverlies

In dit geval is de topologie van de toepassingsimplementatie geoptimaliseerd voor het afhandelen van regionale noodgeval wanneer alle toepassingsonderdelen samen een fail over moeten zetten. In het onderstaande diagram ziet u deze topologie. Voor geografische redundantie worden de resources van de toepassing geïmplementeerd in regio A en B. De resources in regio B worden echter pas gebruikt als regio A uitvalt. Er wordt een failovergroep geconfigureerd tussen de twee regio's om de databaseconnectiviteit, replicatie en failover te beheren. De webservice in beide regio's is geconfigureerd voor toegang tot de database via de < failover-group-name > read-write .database.windows.net (1). Azure Traffic Manager is ingesteld voor het gebruik van routeringsmethode met prioriteit (2).

In het volgende diagram ziet u deze configuratie vóór een storing:

Na een storing in de primaire regio detecteert SQL Database dat de primaire database niet toegankelijk is en wordt failover naar de secundaire regio uitgevoerd op basis van de parameters van het automatische failoverbeleid (1). Afhankelijk van de SLA van uw toepassing kunt u een respijtperiode configureren die de tijd bepaalt tussen de detectie van de storing en de failover zelf. Het is mogelijk dat Azure Traffic Manager de failover van het eindpunt initieert voordat de failovergroep de failover van de database activeert. In dat geval kan de webtoepassing niet onmiddellijk opnieuw verbinding maken met de database. Maar de nieuwe verbindingen worden automatisch voltooid zodra de database-failover is voltooid. Wanneer de mislukte regio is hersteld en weer online is, maakt de oude primaire regio automatisch opnieuw verbinding als een nieuwe secundaire regio. In het onderstaande diagram ziet u de configuratie na een failover.

Als er een storing plaatsvindt in regio B, wordt het replicatieproces tussen de primaire en de secundaire database tijdelijk opgeschort, maar blijft de koppeling tussen de twee intact (1). Traffic Manager detecteert dat de verbinding met regio B is verbroken en markeert de eindpuntweb-app 2 als Gedegradeerd (2). De prestaties van de toepassing worden in dit geval niet beïnvloed, maar de database wordt blootgesteld en loopt daarom een hoger risico op gegevensverlies in het geval regio A achter elkaar uitvalt.

Zodra de storing is opgelost, wordt de secundaire database automatisch opnieuw gesynchroniseerd met de primaire database. Tijdens de synchronisatie kunnen de prestaties van de primaire worden beïnvloed. De specifieke impact is afhankelijk van de hoeveelheid gegevens die de nieuwe primaire heeft verkregen sinds de failover.

Het volgende diagram illustreert een storing in de secundaire regio:

De belangrijkste voordelen van dit ontwerppatroon zijn:

• Dezelfde webtoepassing wordt geïmplementeerd in beide regio's zonder een regiospecifieke configuratie en vereist geen extra logica voor het beheren van failover.
• De prestaties van toepassingen worden niet beïnvloed door failover, omdat de webtoepassing en de database zich altijd op dezelfde locatie bevinden.

Het belangrijkste verschil is dat de toepassingsbronnen in regio B de meeste tijd te veel worden gebruikt.

Scenario 2: Azure-regio's voor bedrijfscontinuïteit met maximale behoud van gegevens

Deze optie is het meest geschikt voor toepassingen met de volgende kenmerken:

• Gegevensverlies is een hoog bedrijfsrisico. De failover van de database kan alleen worden gebruikt als laatste redmiddel als de storing wordt veroorzaakt door een onherstelbare fout.
• De toepassing ondersteunt de modus alleen-lezen en lezen/schrijven voor bewerkingen en kan voor een bepaalde periode worden uitgevoerd in de modus Alleen-lezen.

In dit patroon schakelt de toepassing over naar de modus Alleen-lezen wanneer er time-outfouten optreden bij de lees-/schrijfverbindingen. De webtoepassing wordt geïmplementeerd in beide regio's en bevat een verbinding met het eindpunt van de listener voor lezen/schrijven en een andere verbinding met het alleen-lezen listener-eindpunt (1). Het Traffic Manager moet prioriteitsroutering gebruiken. Eindpuntbewaking moet zijn ingeschakeld voor het toepassings-eindpunt in elke regio (2).

Het volgende diagram illustreert deze configuratie vóór een storing:

Wanneer Traffic Manager een connectiviteitsfout in regio A detecteert, wordt gebruikersverkeer automatisch overschakelt naar het toepassings exemplaar in regio B. Met dit patroon is het belangrijk dat u de respijtperiode met gegevensverlies in stelt op een voldoende hoge waarde, bijvoorbeeld 24 uur. Het zorgt ervoor dat gegevensverlies wordt voorkomen als de storing binnen die tijd wordt vereenigd. Wanneer de webtoepassing in regio B wordt geactiveerd, mislukken de lees-/schrijfbewerkingen. Op dat moment moet deze overschakelen naar de modus alleen-lezen (1). In deze modus worden de aanvragen automatisch doorgeleid naar de secundaire database. Als de storing wordt veroorzaakt door een onherstelbare fout, kan deze waarschijnlijk niet binnen de respijtperiode worden opgelost. Wanneer deze is verlopen, activeert de failovergroep de failover. Daarna wordt de lees-/schrijf-listener beschikbaar en mislukken de verbindingen ermee (2). Het volgende diagram illustreert de twee fasen van het herstelproces.

Als er een storing in regio B is, detecteert Traffic Manager de fout van het eindpunt web-app-2 in regio B en markeert deze gedegradeerd (1). In de tussentijd schakelt de failovergroep de alleen-lezen listener over naar regio A (2). Deze storing heeft geen invloed op de eindgebruikerservaring, maar de primaire database wordt wel blootgesteld tijdens de storing. In het volgende diagram ziet u een fout in de secundaire regio:

Zodra de storing is vereenwisseld, wordt de secundaire database onmiddellijk gesynchroniseerd met de primaire database en wordt de alleen-lezen listener teruggeschakeld naar de secundaire database in regio B. Tijdens de synchronisatie kunnen de prestaties van de primaire functie enigszins worden beïnvloed, afhankelijk van de hoeveelheid gegevens die moet worden gesynchroniseerd.

Dit ontwerppatroon heeft verschillende voordelen:

• Het voorkomt gegevensverlies tijdens de tijdelijke uitval.
• Downtime is alleen afhankelijk van hoe snel Traffic Manager connectiviteitsfout detecteert, wat configureerbaar is.

Het afweging is dat de toepassing in de alleen-lezenmodus moet kunnen werken.

Scenario 3: Herlocatie van toepassing naar een andere geografie zonder gegevensverlies en bijna geen downtime

In dit scenario heeft de toepassing de volgende kenmerken:

• De eindgebruikers hebben toegang tot de toepassing vanuit verschillende geografische gebieden
• De toepassing bevat alleen-lezenworkloads die niet afhankelijk zijn van volledige synchronisatie met de nieuwste updates
• Schrijftoegang tot gegevens moet worden ondersteund in dezelfde geografie voor de meeste gebruikers
• Leeslatentie is essentieel voor de eindgebruikerservaring

Om aan deze vereisten te voldoen, moet u garanderen dat het gebruikersapparaat altijd verbinding maakt met de toepassing die in dezelfde geografie is geïmplementeerd voor de alleen-lezenbewerkingen, zoals browsegegevens, analyses, enzovoort. Terwijl de OLTP-bewerkingen meestal in dezelfde geografie worden verwerkt. Tijdens de dag worden OLTP-bewerkingen bijvoorbeeld verwerkt in dezelfde geografie, maar tijdens de off-uren kunnen ze worden verwerkt in een andere geografie. Als de activiteit van de eindgebruiker voornamelijk tijdens de werkuren gebeurt, kunt u de optimale prestaties voor de meeste gebruikers in de meeste tijd garanderen. In het volgende diagram ziet u deze topologie.

De resources van de toepassing moeten worden geïmplementeerd in elke geografie waar u een aanzienlijke gebruiksvraag hebt. Als uw toepassing bijvoorbeeld actief wordt gebruikt in de Verenigde Staten, de Europese Unie en zuid Azië - oost moet de toepassing worden geïmplementeerd in al deze geografische gebieden. De primaire database moet aan het einde van de werkuren dynamisch worden overgeschakeld van de ene geografie naar de andere. Deze methode wordt 'follow the sun' genoemd. De OLTP-workload maakt altijd verbinding met de database via de < failover-group-name > .database.windows.net (1) van de listener voor lezen/schrijven. De alleen-lezen workload maakt rechtstreeks verbinding met de lokale database met behulp van de servernaam < > .database.windows.net (2) van de databaseserver. Traffic Manager is geconfigureerd met de routeringsmethode voor prestaties. Het zorgt ervoor dat het apparaat van de eindgebruiker is verbonden met de webservice in de dichtstbijzijnde regio. Traffic Manager moet worden ingesteld met eindpuntbewaking ingeschakeld voor elk webservice-eindpunt (3).

Aan het einde van de dag, bijvoorbeeld om 23:00 uur lokale tijd, moeten de actieve databases worden overgeschakeld naar de volgende regio (Europa - noord). Deze taak kan volledig worden geautomatiseerd met behulp van Azure Logic Apps. De taak bestaat uit de volgende stappen:

• Primaire server in de failovergroep overschakelen naar Europa - noord gebruiksvriendelijke failover (1)
• Verwijder de failovergroep tussen VS - oost en Europa - noord
• Maak een nieuwe failovergroep met dezelfde naam, maar tussen Europa - noord en Azië - oost (2).
• Voeg de primaire en secundaire Europa - noord in Azië - oost aan deze failovergroep (3).

In het volgende diagram ziet u de nieuwe configuratie na de geplande failover:

Als er bijvoorbeeld in Europa - noord een storing is, wordt de automatische database-failover geïnitieerd door de failovergroep, waardoor de toepassing ineffectief wordt verplaatst naar de volgende regio vóór schema (1). In dat geval is US - oost de enige resterende secundaire regio totdat Europa - noord weer online is. De overige twee regio's bedienen de klanten in alle drie de geografische gebieden door van rol te wisselen. Azure Logic Apps moeten dienovereenkomstig worden aangepast. Omdat de resterende regio's extra gebruikersverkeer van Europa krijgen, worden de prestaties van de toepassing niet alleen beïnvloed door extra latentie, maar ook door een groter aantal verbindingen voor eindgebruikers. Zodra de storing in de Europa - noord is vereend, wordt de secundaire database daar onmiddellijk gesynchroniseerd met de huidige primaire database. In het volgende diagram ziet u een storing in Europa - noord:

De belangrijkste voordelen van dit ontwerp zijn:

• De alleen-lezen toepassingsworkload heeft te allen tijde toegang tot gegevens in de regio voor het opruimen van gegevens.
• De workload lees-/schrijftoepassing heeft toegang tot gegevens in de dichtstbijzijnde regio tijdens de periode van de hoogste activiteit in elke geografie
• Omdat de toepassing in meerdere regio's is geïmplementeerd, kan deze zonder aanzienlijke downtime een verlies van een van de regio's overleven.

Maar er zijn enkele afwegingen:

• Een regionale storing heeft tot gevolg dat de geografie wordt beïnvloed door een langere latentie. Zowel workloads voor lezen/schrijven als alleen-lezen worden door de toepassing in een andere geografie bediend.
• De alleen-lezen workloads moeten verbinding maken met een ander eindpunt in elke regio.

Planning van bedrijfscontinuïteit: Een toepassingsontwerp kiezen voor herstel na noodherstel in de cloud

Uw specifieke strategie voor noodherstel in de cloud kan deze ontwerppatronen combineren of uitbreiden om het beste te voldoen aan de behoeften van uw toepassing. Zoals eerder vermeld, is de strategie die u kiest, gebaseerd op de SLA die u wilt aanbieden aan uw klanten en de topologie van de toepassingsimplementatie. In de volgende tabel worden de keuzes vergeleken op basis van RPO (Recovery Point Objective) en geschatte hersteltijd (ERT).

Volgende stappen

• Zie Overzicht van bedrijfscontinuïteit voor een overzicht van bedrijfscontinuïteit en scenario's
• Zie Actieve geo-replicatie voor meer informatie over actieve geo-replicatie.
• Zie Groepen voor automatische failover voor meer informatie over groepen voor automatische failover.
• Zie Strategieën voor herstel na noodherstel voor elastische pools voor meer informatie over actieve geo-replicatie met elastische pools.