Wereldwijd beschikbare services ontwerpen met 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 tegen regionale storingen en catastrofale fouten. 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, inclusief de voordelen en afwegingen van elke optie.

Notitie

Als u Premium- of Bedrijfskritiek-databases en elastische pools gebruikt, kunt u ze tolerant maken voor regionale storingen door ze te converteren naar zone-redundante implementatieconfiguratie. Zie Zone-redundante databases.

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

In dit scenario hebben de toepassingen de volgende kenmerken:

  • Toepassing is actief in één Azure-regio
  • Voor alle databasesessies is lees- en schrijftoegang (RW) tot gegevens vereist
  • Web- en gegevenslaag moeten in een collolocatie worden geplaatst om de latentie en de verkeerskosten te verminderen
  • Downtime 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 rampen wanneer alle toepassingsonderdelen samen een failover moeten uitvoeren. 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 mislukt. Er wordt een failovergroep geconfigureerd tussen de twee regio's om databaseconnectiviteit, replicatie en failover te beheren. De webservice in beide regio's is geconfigureerd voor toegang tot de database via de read-write listener< failover-group-name.database.windows.net> (1). Azure Traffic Manager is ingesteld voor het gebruik van de routeringsmethode met prioriteit (2).  

Notitie

Azure Traffic Manager wordt in dit artikel alleen ter illustratie gebruikt. U kunt elke taakverdelingsoplossing gebruiken die ondersteuning biedt voor prioriteitsrouteringsmethode.

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

Scenario 1. Configuratie vóór de 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 geactiveerd op basis van de parameters van het beleid voor automatische failover (1). Afhankelijk van de SLA van uw toepassing kunt u een respijtperiode configureren waarmee de tijd tussen de detectie van de storing en de failover zelf wordt bepaald. Het is mogelijk dat Azure Traffic Manager de eindpuntfailover 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 het opnieuw verbinden lukt automatisch zodra de databasefailover is voltooid. Wanneer de mislukte regio wordt hersteld en weer online is, wordt de oude primaire regio automatisch opnieuw verbonden als een nieuwe secundaire regio. In het onderstaande diagram ziet u de configuratie na een failover.

Notitie

Alle transacties die na de failover zijn doorgevoerd, gaan verloren tijdens het opnieuw verbinden. Nadat de failover is voltooid, kan de toepassing in regio B opnieuw verbinding maken en de gebruikersaanvragen opnieuw verwerken. Zowel de webtoepassing als de primaire database bevinden zich nu in regio B en blijven co-locatie.

Scenario 1. Configuratie na failover

Als er een storing optreedt in regio B, wordt het replicatieproces tussen de primaire en de secundaire database onderbroken, 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 heeft daarom een hoger risico op gegevensverlies als regio A achter elkaar uitvalt.

Notitie

Voor herstel na noodgevallen raden we de configuratie aan met toepassingsimplementatie beperkt tot twee regio's. Dit komt omdat de meeste Azure-geografische gebieden slechts twee regio's hebben. Deze configuratie beschermt uw toepassing niet tegen een gelijktijdige catastrofale fout in beide regio's. In een onwaarschijnlijk geval van een dergelijke fout kunt u uw databases in een derde regio herstellen met behulp van een geo-herstelbewerking.

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 het nieuwe primaire exemplaar heeft verkregen sinds de failover.

Notitie

Nadat de storing is opgelost, begint Traffic Manager met het routeren van de verbindingen naar de toepassing in regio A als eindpunt met een hogere prioriteit. Als u van plan bent om de primaire in regio B een tijdje te bewaren, moet u de prioriteitstabel in het Trafic Manager-profiel dienovereenkomstig wijzigen.

In het volgende diagram ziet u een storing in de secundaire regio:

Scenario 1. Configuratie na een storing in de secundaire regio.

De belangrijkste voordelen van dit ontwerppatroon zijn:

  • Dezelfde webtoepassing wordt geïmplementeerd in beide regio's zonder regiospecifieke configuratie en vereist geen aanvullende logica om failover te beheren.
  • De prestaties van toepassingen worden niet beïnvloed door failover, omdat de webtoepassing en de database zich altijd naast elkaar bevinden.

Het belangrijkste nadeel is dat de toepassingsresources in regio B meestal te weinig worden gebruikt.

Scenario 2: Azure-regio's voor bedrijfscontinuïteit met maximale gegevensbehoud

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

  • Gegevensverlies is een hoog bedrijfsrisico. De databasefailover kan alleen worden gebruikt als laatste redmiddel als de storing wordt veroorzaakt door een catastrofale fout.
  • De toepassing ondersteunt bewerkingen met het kenmerk Alleen-lezen en lezen/schrijven en kan gedurende een bepaalde periode in de modus Alleen-lezen werken.

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 listener-eindpunt voor lezen/schrijven en een andere verbinding met het alleen-lezen listener-eindpunt (1). Het Traffic Manager-profiel moet prioriteitsroutering gebruiken. Eindpuntbewaking moet zijn ingeschakeld voor het toepassingseindpunt in elke regio (2).

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

Scenario 2. Configuratie vóór de storing.

Wanneer Traffic Manager een verbindingsfout met regio A detecteert, wordt gebruikersverkeer automatisch overgeschakeld naar het toepassingsexemplaar in regio B. Bij dit patroon is het belangrijk dat u de respijtperiode met gegevensverlies instelt op een voldoende hoge waarde, bijvoorbeeld 24 uur. Het zorgt ervoor dat gegevensverlies wordt voorkomen als de storing binnen die tijd wordt verzacht. Wanneer de webtoepassing in regio B is geactiveerd, mislukken de lees-schrijfbewerkingen. Op dat moment moet deze overschakelen naar de modus Alleen-lezen (1). In deze modus worden de aanvragen automatisch doorgestuurd naar de secundaire database. Als de storing wordt veroorzaakt door een catastrofale fout, kan deze waarschijnlijk niet worden verzacht binnen de respijtperiode. Wanneer de failover is verlopen, wordt de failover geactiveerd door de failovergroep. Daarna wordt de listener voor lezen/schrijven beschikbaar en mislukken de verbindingen met de listener (2). In het volgende diagram ziet u de twee fasen van het herstelproces.

Notitie

Als de storing in de primaire regio binnen de respijtperiode wordt beperkt, detecteert Traffic Manager het herstel van de connectiviteit in de primaire regio en wordt gebruikersverkeer teruggeschakeld naar het toepassingsexemplaar in regio A. Dit toepassingsexemplaar wordt hervat en wordt uitgevoerd in de lees-schrijfmodus met behulp van de primaire database in regio A, zoals geïllustreerd in het vorige diagram.

Scenario 2. Fasen voor herstel na noodgevallen.

Als er een storing optreedt in regio B, 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 ervaring van de eindgebruiker, maar de primaire database wordt weergegeven tijdens de storing. In het volgende diagram ziet u een fout in de secundaire regio:

Scenario 2. Storing van de secundaire regio.

Zodra de storing is opgelost, wordt de secundaire database onmiddellijk gesynchroniseerd met de primaire database en wordt de alleen-lezenlistener 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 storingen.
  • Downtime is alleen afhankelijk van hoe snel Traffic Manager de verbindingsfout detecteert, die configureerbaar is.

Het nadeel is dat de toepassing in de modus Alleen-lezen moet kunnen werken.

Scenario 3: Een toepassing verplaatsen naar verschillende geografische gebieden om de vraag te volgen

In dit scenario heeft de toepassing de volgende kenmerken:

  • De eindgebruikers hebben toegang tot de toepassing vanuit verschillende geografische gebieden.
  • De toepassing bevat alleen-lezenwerkbelastingen die niet afhankelijk zijn van volledige synchronisatie met de meest recente updates.
  • Schrijftoegang tot gegevens moet voor de meeste gebruikers in dezelfde geografie worden ondersteund.
  • 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 alleen-lezenbewerkingen, zoals browsen in gegevens, analyses, enzovoort. OlTP-bewerkingen (Online Transactional Processing) worden daarentegen meestal in dezelfde geografie verwerkt. Bijvoorbeeld, overdag worden OLTP-bewerkingen verwerkt in dezelfde geografie, maar ze kunnen buiten kantooruren in een andere geografie worden verwerkt. Als de activiteit van de eindgebruiker meestal tijdens normale werkuren plaatsvindt, kunt u de meeste gebruikers in de meeste tijd optimale prestaties garanderen. In het volgende diagram ziet u deze topologie.

De resources van de toepassing moeten worden geïmplementeerd in elke regio waar u een aanzienlijke gebruiksvraag hebt. Als uw toepassing bijvoorbeeld actief wordt gebruikt in de Verenigde Staten, Oost-Azië en Europa, moet de toepassing worden geïmplementeerd in al deze geografische gebieden (bijvoorbeeld VS - west, Japan en VK). De primaire database moet aan het einde van normale werkuren dynamisch van de ene geografie naar de andere worden overgeschakeld. Deze methode wordt 'volg de zon' genoemd. De OLTP-workload maakt altijd verbinding met de database via de read-write listener< failover-group-name.database.windows.net> (1). De alleen-lezen workload maakt rechtstreeks verbinding met de lokale database met behulp van de <servernaam.database.windows.net> (2). 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 eindpunt van de webservice (3).

Notitie

De configuratie van de failovergroep definieert welke regio wordt gebruikt voor failover. Omdat de nieuwe primaire locatie zich in een andere geografie bevindt, resulteert de failover in een langere latentie voor zowel OLTP- als alleen-lezenworkloads totdat de getroffen regio weer online is.

Diagram van de configuratie met primair in US - west.

Aan het einde van de werkdag in US - west, bijvoorbeeld om 16:00 uur lokale tijd, moeten de actieve databases worden overgeschakeld naar de volgende regio, Azië - Oost (Japan), waar het 8:00 uur is. Vervolgens, om 16:00 uur in Oost-Azië, moet de primaire overschakelen naar Europa (VK), waar het 8:00 uur is. Deze taak kan volledig worden geautomatiseerd met behulp van Azure Logic Apps. De taak bestaat uit de volgende stappen:

  • Schakel de primaire server in de failovergroep over naar Azië - oost met behulp van een beschrijvende failover (1).
  • Verwijder de failovergroep tussen US - west en Azië - oost.
  • Maak een nieuwe failovergroep met dezelfde naam, maar tussen Azië en Europa (2).
  • Voeg de primaire in Oost-Azië en secundaire in Europa toe aan deze failovergroep (3).

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

Scenario 3. De primaire overgang naar Oost-Azië.

Als er bijvoorbeeld een storing optreedt in Azië - oost, wordt de automatische databasefailover gestart door de failovergroep, wat er effectief toe leidt dat de toepassing eerder naar de volgende regio wordt verplaatst dan gepland (1). In dat geval is US - west de enige resterende secundaire regio totDat Azië - oost weer online is. De overige twee regio's bedienen de klanten in alle drie de regio's door van rol te wisselen. Azure Logic Apps moet dienovereenkomstig worden aangepast. Omdat de resterende regio's extra gebruikersverkeer uit Oost-Azië ontvangen, worden de prestaties van de toepassing niet alleen beïnvloed door extra latentie, maar ook door een toenemend aantal verbindingen van eindgebruikers. Zodra de storing is opgelost, wordt de secundaire database onmiddellijk gesynchroniseerd met de huidige primaire database. In het volgende diagram ziet u een storing in Oost-Azië:

Scenario 3. Storing in Oost-Azië.

Notitie

U kunt de tijd verkorten wanneer de ervaring van de eindgebruiker in Oost-Azië wordt verminderd door de lange latentie. Hiervoor moet u proactief een toepassingskopie implementeren en een secundaire database(s) maken in een nabijgelegen regio (bijvoorbeeld het Azure Korea - centraal-datacenter) als vervanging van het offlinetoepassingsexemplaar in Japan. Wanneer de laatste weer online is, kunt u beslissen of u korea - centraal wilt blijven gebruiken of de kopie van de toepassing daar wilt verwijderen en weer overschakelt naar het gebruik van Japan.

De belangrijkste voordelen van dit ontwerp zijn:

  • De workload van de alleen-lezentoepassing heeft altijd toegang tot gegevens in de dichtstbijzijnde regio.
  • De workload van de toepassing lezen/schrijven 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 wordt geïmplementeerd, kan deze een verlies van een van de regio's overleven zonder enige aanzienlijke downtime.

Maar er zijn enkele compromissen:

  • Een regionale storing leidt ertoe dat de geografie wordt beïnvloed door een langere latentie. Zowel lezen-schrijven- als alleen-lezenworkloads 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: kies een toepassingsontwerp voor herstel na noodgevallen in de cloud

Uw specifieke strategie voor herstel na noodgevallen in de cloud kan deze ontwerppatronen combineren of uitbreiden om zo goed mogelijk te voldoen aan de behoeften van uw toepassing. Zoals eerder vermeld, is de strategie die u kiest gebaseerd op de SLA die u aan uw klanten wilt aanbieden en de implementatietopologie van de toepassing. De volgende tabel vergelijkt de keuzes op basis van RPO (Recovery Point Objective) en de geschatte hersteltijd (ERT) om u te helpen bij uw beslissing.

Patroon RPO Ert
Actief-passieve implementatie voor herstel na noodgevallen met databasetoegang op dezelfde locatie Lees-schrijftoegang < 5 sec. Foutdetectietijd + DNS TTL
Actief-actief-implementatie voor toepassingstaakverdeling Lees-schrijftoegang < 5 sec. Foutdetectietijd + DNS TTL
Actief-passieve implementatie voor gegevensbehoud Alleen-lezentoegang < 5 sec. Alleen-lezentoegang = 0
Lees-schrijftoegang = nul Lees-schrijftoegang = Foutdetectietijd + respijtperiode met gegevensverlies

Volgende stappen