Strategieën voor herstel na noodgevallen voor toepassingen die gebruikmaken van elastische pools van Azure SQL Database

Van toepassing op: Azure SQL database

Azure SQL Database biedt verschillende mogelijkheden voor de bedrijfscontinuïteit van uw toepassing wanneer zich onherstelbare incidenten voordoen. Elastische pools en individuele databases bieden ondersteuning voor dezelfde mogelijkheden voor herstel na noodgevallen. In dit artikel worden verschillende DR-strategieën beschreven voor elastische pools die gebruikmaken van deze functies voor Azure SQL Database-bedrijfscontinuïteit.

In dit artikel wordt het volgende canonieke SaaS ISV-toepassingspatroon gebruikt:

Een moderne cloudgebaseerde webtoepassing richt één database in voor elke eindgebruiker. De ISV heeft veel klanten en maakt daarom gebruik van veel databases, ook wel tenantdatabases genoemd. Omdat de tenantdatabases doorgaans onvoorspelbare activiteitspatronen hebben, gebruikt de ISV een elastische pool om de databasekosten zeer voorspelbaar te maken over langere perioden. De elastische pool vereenvoudigt ook het prestatiebeheer wanneer de gebruikersactiviteit piekt. Naast de tenantdatabases gebruikt de toepassing ook verschillende databases voor het beheren van gebruikersprofielen, beveiliging, het verzamelen van gebruikspatronen, enzovoort. De beschikbaarheid van de afzonderlijke tenants heeft geen invloed op de beschikbaarheid van de toepassing als geheel. De beschikbaarheid en prestaties van beheerdatabases zijn echter essentieel voor de functie van de toepassing en als de beheerdatabases offline zijn, is de hele toepassing offline.

In dit artikel worden strategieën voor herstel na noodgeval besproken die betrekking hebben op een reeks scenario's, van kostengevoelige opstarttoepassingen tot toepassingen met strenge beschikbaarheidsvereisten.

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. Kostengevoelig opstarten

Ik ben een startup bedrijf en ben zeer kostengevoelig. Ik wil de implementatie en het beheer van de toepassing vereenvoudigen en ik kan een beperkte SLA hebben voor individuele klanten. Maar ik wil ervoor zorgen dat de toepassing als geheel nooit offline is.

Om aan de eenvoudsvereiste te voldoen, implementeert u alle tenantdatabases in één elastische pool in de Azure-regio van uw keuze en implementeert u beheerdatabases als geo-gerepliceerde individuele databases. Gebruik geo-herstel voor het herstel na noodgevallen van tenants, zonder extra kosten. Om de beschikbaarheid van de beheerdatabases te garanderen, moet u ze geo-repliceren naar een andere regio met behulp van een groep voor automatische failover (stap 1). De lopende kosten van de configuratie voor herstel na noodgevallen in dit scenario zijn gelijk aan de totale kosten van de secundaire databases. Deze configuratie wordt geïllustreerd in het volgende diagram.

Afbeelding 1

Als er een storing optreedt in de primaire regio, worden de herstelstappen voor het online brengen van uw toepassing geïllustreerd door het volgende diagram.

  • De failovergroep initieert automatische failover van de beheerdatabase naar de regio voor herstel na noodgeval. De toepassing wordt automatisch opnieuw verbonden met de nieuwe primaire en alle nieuwe accounts en tenantdatabases worden gemaakt in de regio herstel na noodgeval. De bestaande klanten zien dat hun gegevens tijdelijk niet beschikbaar zijn.
  • Maak de elastische pool met dezelfde configuratie als de oorspronkelijke pool (2).
  • Gebruik geo-herstel om kopieën van de tenantdatabases te maken (3). U kunt overwegen om de afzonderlijke herstelbewerkingen te activeren via de verbindingen van de eindgebruiker of een ander toepassingsspecifiek prioriteitsschema te gebruiken.

Op dit moment is uw toepassing weer online in de regio voor herstel na noodgeval, maar sommige klanten ondervinden vertraging bij het openen van hun gegevens.

Afbeelding 2

Als de storing tijdelijk was, is het mogelijk dat de primaire regio door Azure wordt hersteld voordat alle databaseherstelbewerkingen in de herstel na noodgeval zijn voltooid. In dit geval moet u het verplaatsen van de toepassing terug naar de primaire regio indelen. Het proces voert de stappen uit die in het volgende diagram worden weergegeven.

  • Annuleer alle openstaande aanvragen voor geo-herstel.
  • Failover van de beheerdatabases naar de primaire regio (5). Na het herstel van de regio worden de oude primaries automatisch secundaire bestanden. Nu veranderen ze weer van rol.
  • Wijzig de connection string van de toepassing om terug te verwijzen naar de primaire regio. Nu worden alle nieuwe accounts en tenantdatabases gemaakt in de primaire regio. Sommige bestaande klanten zien dat hun gegevens tijdelijk niet beschikbaar zijn.
  • Stel alle databases in de DR-pool in op alleen-lezen om ervoor te zorgen dat ze niet kunnen worden gewijzigd in de DR-regio (6).
  • Voor elke database in de DR-pool die is gewijzigd sinds het herstel, wijzigt u de naam of verwijdert u de bijbehorende databases in de primaire pool (7).
  • Kopieer de bijgewerkte databases van de DR-pool naar de primaire groep (8).
  • De DR-groep verwijderen (9)

Op dit moment is uw toepassing online in de primaire regio met alle tenantdatabases die beschikbaar zijn in de primaire pool.

Afbeelding 3

Voordeel

Het belangrijkste voordeel van deze strategie is lage doorlopende kosten voor redundantie van gegevenslagen. Azure SQL Database maakt automatisch en zonder extra kosten back-ups van databases zonder dat de toepassing opnieuw wordt geschreven. De kosten worden alleen gemaakt wanneer de elastische databases worden hersteld.

Trade-off

De afweging is dat het volledige herstel van alle tenantdatabases veel tijd kost. De tijdsduur is afhankelijk van het totale aantal herstelbewerkingen dat u initieert in de REGIO voor herstel na noodgeval en de totale grootte van de tenantdatabases. Zelfs als u prioriteit geeft aan herstelbewerkingen van sommige tenants boven andere, concurreert u met alle andere herstelbewerkingen die in dezelfde regio worden gestart als de service bemiddelaars en beperkingen om de algehele impact op de databases van de bestaande klanten te minimaliseren. Bovendien kan het herstel van de tenantdatabases pas worden gestart als de nieuwe elastische pool in de regio herstel na noodgeval is gemaakt.

Scenario 2. Volwassen toepassing met gelaagde service

Ik ben een volwassen SaaS-toepassing met gelaagde serviceaanbiedingen en verschillende SLA's voor proefklanten en betalende klanten. Voor de proefklanten moet ik de kosten zoveel mogelijk verlagen. Proefklanten kunnen downtime in beslag nemen, maar ik wil de kans verkleinen. Voor de betalende klanten is uitvaltijd een vluchtrisico. Daarom wil ik ervoor zorgen dat betalende klanten altijd toegang hebben tot hun gegevens.

Ter ondersteuning van dit scenario scheidt u de proeftenants van betaalde tenants door ze in afzonderlijke elastische pools te plaatsen. De proefklanten hebben een lagere eDTU of vCores per tenant en een lagere SLA met een langere hersteltijd. De betalende klanten bevinden zich in een pool met een hogere eDTU of vCores per tenant en een hogere SLA. Om de laagste hersteltijd te garanderen, worden de tenantdatabases van de betalende klanten geo-gerepliceerd. Deze configuratie wordt geïllustreerd in het volgende diagram.

Diagram met een primaire regio en een D R-regio die gebruikmaken van geo-replicatie tussen de beheerdatabase en de primaire groep van betaalde klanten en de secundaire pool zonder replicatie voor de groep met proefklanten.

Net als in het eerste scenario zijn de beheerdatabases vrij actief, dus u gebruikt hiervoor één geo-gerepliceerde database (1). Dit zorgt voor voorspelbare prestaties voor nieuwe klantabonnementen, profielupdates en andere beheerbewerkingen. De regio waarin de primaire databases van de beheerdatabases zich bevinden, is de primaire regio en de regio waarin de secundaire databases van de beheerdatabases zich bevinden, is de regio voor herstel na noodgeval.

De tenantdatabases van de betalende klanten hebben actieve databases in de betaalde pool die zijn ingericht in de primaire regio. Richt een secundaire pool in met dezelfde naam in de regio herstel na noodgeval. Elke tenant wordt geo-gerepliceerd naar de secundaire pool (2). Hierdoor kunnen alle tenantdatabases snel worden hersteld met behulp van failover.

Als er een storing optreedt in de primaire regio, worden de herstelstappen voor het online brengen van uw toepassing geïllustreerd in het volgende diagram:

Diagram toont een storing voor de primaire regio, met failover naar de beheerdatabase, betaalde secundaire klantpool en het maken en herstellen van proefklanten.

  • Onmiddellijk een failover uitvoeren van de beheerdatabases naar de DR-regio (3).
  • Wijzig de connection string van de toepassing zodat deze verwijst naar de regio voor herstel na noodgeval. Nu worden alle nieuwe accounts en tenantdatabases gemaakt in de regio herstel na noodgeval. De bestaande proefklanten zien dat hun gegevens tijdelijk niet beschikbaar zijn.
  • Voer een failover uit van de databases van de betaalde tenant naar de pool in de dr-regio om de beschikbaarheid onmiddellijk te herstellen (4). Aangezien de failover een snelle wijziging op het niveau van metagegevens is, kunt u overwegen een optimalisatie te maken waarbij de afzonderlijke failovers op aanvraag worden geactiveerd door de verbindingen van de eindgebruiker.
  • Als de eDTU-grootte of vCore-waarde van uw secundaire pool lager was dan de primaire omdat de secundaire databases alleen de capaciteit nodig hadden om de wijzigingslogboeken te verwerken terwijl het secundaire databases waren, verhoogt u de poolcapaciteit nu onmiddellijk om de volledige workload van alle tenants te kunnen verwerken (5).
  • Maak de nieuwe elastische pool met dezelfde naam en dezelfde configuratie in de regio voor herstel na noodgeval voor de databases van de proefklanten (6).
  • Zodra de pool van de proefklanten is gemaakt, gebruikt u geo-herstel om de afzonderlijke proeftenantdatabases te herstellen in de nieuwe pool (7). Overweeg om de afzonderlijke herstelbewerkingen te activeren door de verbindingen van de eindgebruiker of een ander toepassingsspecifiek prioriteitsschema te gebruiken.

Op dit moment is uw toepassing weer online in de dr-regio. Alle betalende klanten hebben toegang tot hun gegevens, terwijl de proefklanten vertraging ondervinden bij het openen van hun gegevens.

Wanneer de primaire regio door Azure wordt hersteld nadat u de toepassing in de DR-regio hebt hersteld, kunt u doorgaan met het uitvoeren van de toepassing in die regio of kunt u besluiten om een failback naar de primaire regio uit te voeren. Als de primaire regio wordt hersteld voordat het failoverproces is voltooid, kunt u direct een failback uitvoeren. De failback voert de stappen uit die in het volgende diagram worden weergegeven:

Diagram met failbackstappen die moeten worden geïmplementeerd na het herstellen van de primaire regio.

  • Annuleer alle openstaande aanvragen voor geo-herstel.
  • Failover van de beheerdatabases (8). Na het herstel van de regio wordt de oude primaire automatisch de secundaire. Nu wordt het weer de primaire.
  • Failover van de betaalde tenantdatabases (9). Op dezelfde manier worden na het herstel van de regio de oude primaries automatisch de secundaire bestanden. Nu worden ze weer de primaries.
  • Stel de herstelde proefdatabases die zijn gewijzigd in de regio voor herstel na noodgeval in op alleen-lezen (10).
  • Voor elke database in de dr-groep van proefklanten die is gewijzigd sinds het herstel, wijzigt u de naam of verwijdert u de bijbehorende database in de primaire groep van proefklanten (11).
  • Kopieer de bijgewerkte databases van de DR-pool naar de primaire groep (12).
  • Verwijder de DR-groep (13).

Notitie

De failoverbewerking is asynchroon. Om de hersteltijd te minimaliseren, is het belangrijk dat u de failoveropdracht van de tenantdatabases uitvoert in batches van ten minste 20 databases.

Voordeel

Het belangrijkste voordeel van deze strategie is dat deze de hoogste SLA biedt voor de betalende klanten. Het garandeert ook dat de nieuwe proefversies worden gedeblokkeerd zodra de dr-testpool wordt gemaakt.

Trade-off

De afweging is dat deze instelling de totale kosten van de tenantdatabases verhoogt met de kosten van de secundaire DR-pool voor betaalde klanten. Als de secundaire pool een andere grootte heeft, ervaren de betalende klanten bovendien lagere prestaties na een failover totdat de upgrade van de pool in de DR-regio is voltooid.

Scenario 3. Geografisch gedistribueerde toepassing met gelaagde service

Ik heb een volwassen SaaS-toepassing met gelaagde serviceaanbiedingen. Ik wil mijn betaalde klanten een zeer agressieve SLA bieden en het risico op impact bij storingen minimaliseren, omdat zelfs een korte onderbreking tot ontevredenheid bij klanten kan leiden. Het is essentieel dat de betalende klanten altijd toegang hebben tot hun gegevens. De proefversies zijn gratis en er wordt geen SLA aangeboden tijdens de proefperiode.

Gebruik drie afzonderlijke elastische pools ter ondersteuning van dit scenario. Richt twee pools van gelijke grootte in met hoge eDTU's of vCores per database in twee verschillende regio's, zodat deze de tenantdatabases van de betaalde klanten bevatten. De derde pool met de proeftenants kan lagere eDTU's of vCores per database hebben en worden ingericht in een van de twee regio's.

Om de laagste hersteltijd tijdens storingen te garanderen, worden de tenantdatabases van de betalende klanten geo-gerepliceerd met 50% van de primaire databases in elk van de twee regio's. Op dezelfde manier heeft elke regio 50% van de secundaire databases. Op deze manier wordt, als een regio offline is, slechts 50% van de databases van betaalde klanten beïnvloed en moet er een failover worden uitgevoerd. De andere databases blijven intact. Deze configuratie wordt geïllustreerd in het volgende diagram:

Diagram toont een primaire regio met de naam Regio A en een secundaire regio met de naam Regio B, die gebruikmaken van geo-replicatie tussen de beheerdatabase en de primaire en secundaire groep van betaalde klanten, zonder replicatie voor de groep met proefklanten.

Net als in de vorige scenario's zijn de beheerdatabases vrij actief, dus configureer ze als individuele geo-gerepliceerde databases (1). Dit zorgt voor voorspelbare prestaties van de nieuwe klantabonnementen, profielupdates en andere beheerbewerkingen. Regio A is de primaire regio voor de beheerdatabases en de regio B wordt gebruikt voor het herstellen van de beheerdatabases.

De tenantdatabases van de betalende klanten worden ook geo-gerepliceerd, maar met primaries en secundaire bestanden die zijn gesplitst tussen regio A en regio B (2). Op deze manier kunnen de primaire tenantdatabases die worden beïnvloed door de storing een failover uitvoeren naar de andere regio en beschikbaar worden. De andere helft van de tenantdatabases wordt helemaal niet beïnvloed.

In het volgende diagram ziet u de herstelstappen die moeten worden uitgevoerd als er een storing optreedt in regio A.

Diagram toont een storing voor de primaire regio, met failover naar de beheerdatabase, betaalde secundaire klantenpool en het maken en herstellen van proefklanten naar regio B.

  • Onmiddellijk failover van de beheerdatabases naar regio B (3).
  • Wijzig de connection string van de toepassing zodat deze verwijst naar de beheerdatabases in regio B. Wijzig de beheerdatabases om ervoor te zorgen dat de nieuwe accounts en tenantdatabases worden gemaakt in regio B en dat de bestaande tenantdatabases daar ook worden gevonden. De bestaande proefklanten zien dat hun gegevens tijdelijk niet beschikbaar zijn.
  • Failover-overschakeling van de databases van de betaalde tenant naar pool 2 in regio B om de beschikbaarheid onmiddellijk te herstellen (4). Omdat de failover een snelle wijziging op het niveau van metagegevens is, kunt u een optimalisatie overwegen waarbij de afzonderlijke failovers op aanvraag worden geactiveerd door de verbindingen van de eindgebruiker.
  • Aangezien pool 2 nu alleen primaire databases bevat, neemt de totale workload in de pool toe en kan de eDTU-grootte (5) of het aantal vCores onmiddellijk toenemen.
  • Maak de nieuwe elastische pool met dezelfde naam en dezelfde configuratie in regio B voor de databases van de proefklanten (6).
  • Zodra de pool is gemaakt, gebruikt u geo-herstel om de afzonderlijke tenantdatabase voor proefversies te herstellen in de pool (7). U kunt overwegen om de afzonderlijke herstelbewerkingen te activeren via de verbindingen van de eindgebruiker of een ander toepassingsspecifiek prioriteitsschema te gebruiken.

Notitie

De failoverbewerking is asynchroon. Om de hersteltijd te minimaliseren, is het belangrijk dat u de failoveropdracht van de tenantdatabases uitvoert in batches van ten minste 20 databases.

Op dit moment is uw toepassing weer online in regio B. Alle betalende klanten hebben toegang tot hun gegevens, terwijl de proefklanten vertraging ondervinden bij het openen van hun gegevens.

Wanneer regio A is hersteld, moet u beslissen of u regio B wilt gebruiken voor proefklanten of een failback naar het gebruik van de groep met proefklanten in regio A. Een criterium kan het percentage van de proeftenantdatabases zijn die zijn gewijzigd sinds het herstel. Ongeacht die beslissing moet u de betaalde tenants opnieuw verdelen over twee pools. het volgende diagram illustreert het proces wanneer de proeftenantdatabases failback uitvoeren naar regio A.

Diagram toont failbackstappen die moeten worden geïmplementeerd na het herstellen van regio A.

  • Annuleer alle openstaande aanvragen voor geo-herstel naar de dr-testgroep.
  • Failover van de beheerdatabase (8). Na het herstel van de regio werd de oude primaire automatisch de secundaire. Nu wordt het weer de primaire.
  • Selecteer welke betaalde tenantdatabases failback uitvoeren naar pool 1 en een failover naar hun secundaire databases initiëren (9). Na het herstel van de regio worden alle databases in pool 1 automatisch secundaire databases. Nu wordt 50% weer primaries.
  • Verklein de grootte van pool 2 tot de oorspronkelijke eDTU (10) of het aantal vCores.
  • Stel alle herstelde proefdatabases in regio B in op alleen-lezen (11).
  • Voor elke database in de evaluatie-herstelgroep die is gewijzigd sinds het herstel, wijzigt u de naam of verwijdert u de bijbehorende database in de primaire groep van de proefversie (12).
  • Kopieer de bijgewerkte databases van de DR-pool naar de primaire groep (13).
  • Verwijder de DR-groep (14).

Voordeel

De belangrijkste voordelen van deze strategie zijn:

  • Het ondersteunt de meest agressieve SLA voor de betalende klanten, omdat het ervoor zorgt dat een storing niet meer dan 50% van de tenantdatabases kan beïnvloeden.
  • Het garandeert dat de nieuwe proefversies worden gedeblokkeerd zodra de trail DR-pool wordt gemaakt tijdens het herstel.
  • Het maakt een efficiënter gebruik van de poolcapaciteit mogelijk, omdat 50% van de secundaire databases in groep 1 en groep 2 gegarandeerd minder actief is dan de primaire databases.

Afwegingen

De belangrijkste afwegingen zijn:

  • De CRUD-bewerkingen voor de beheerdatabases hebben een lagere latentie voor de eindgebruikers die zijn verbonden met regio A dan voor de eindgebruikers die zijn verbonden met regio B, omdat ze worden uitgevoerd op basis van de primaire beheerdatabases.
  • Hiervoor is een complexer ontwerp van de beheerdatabase vereist. Elke tenantrecord heeft bijvoorbeeld een locatietag die moet worden gewijzigd tijdens failover en failback.
  • De betalende klanten kunnen lagere prestaties ervaren dan normaal totdat de upgrade van de pool in regio B is voltooid.

Samenvatting

Dit artikel is gericht op de strategieën voor herstel na noodgevallen voor de databaselaag die wordt gebruikt door een SaaS ISV-toepassing met meerdere tenants. De strategie die u kiest, is gebaseerd op de behoeften van de toepassing, zoals het bedrijfsmodel, de SLA die u aan uw klanten wilt aanbieden, budgetbeperkingen, enzovoort. Elke beschreven strategie bevat een overzicht van de voordelen en afwegingen, zodat u een weloverwogen beslissing kunt nemen. Uw specifieke toepassing bevat waarschijnlijk ook andere Azure-onderdelen. U bekijkt dus de richtlijnen voor bedrijfscontinuïteit en organiseert het herstel van de databaselaag met hen. Raadpleeg Cloudoplossingen ontwerpen voor herstel na noodgevallen voor meer informatie over het beheren van herstel van databasetoepassingen in Azure.

Volgende stappen