Strategieën voor herstel na noodgevallen voor toepassingen die elastische Pools van Azure SQL Database gebruiken

van toepassing op:Azure SQL Database-

Azure SQL Database biedt verschillende mogelijkheden voor de bedrijfscontinuïteit van uw toepassing wanneer zich catastrofale 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 bedrijfscontinuïteit van Azure SQL Database.

In dit artikel wordt het volgende canonieke SaaS-toepassingspatroon van onafhankelijke SaaS-leveranciers (ISV) gebruikt:

Met een moderne webtoepassing in de cloud wordt één database ingericht 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, maakt de ISV gebruik van een elastische pool om de database gedurende langere tijd zeer voorspelbaar te maken. 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 dr-strategieën besproken die betrekking hebben op een reeks scenario's van kostengevoelige opstarttoepassingen tot scenario's met strenge beschikbaarheidsvereisten.

Notitie

Als u Premium- of Bedrijfskritieke 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 uiterst 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.

Als u wilt voldoen aan de eenvoudsvereiste, implementeert u alle tenantdatabases in één elastische pool in de Azure-regio van uw keuze en implementeert u beheerdatabases als geografisch gerepliceerde individuele databases. Voor de noodherstel van tenants gebruikt u geo-herstel, dat zonder extra kosten beschikbaar is. Om de beschikbaarheid van de beheerdatabases te garanderen, repliceert u ze naar een andere regio met behulp van een failovergroep (stap 1). De doorlopende 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.

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.

• De failovergroep initieert automatische failover van de beheerdatabase naar de DR-regio. De toepassing wordt automatisch opnieuw verbonden met de nieuwe primaire server en alle nieuwe accounts en tenantdatabases worden gemaakt in de rampherstelregio. De bestaande klanten zien hun gegevens tijdelijk niet beschikbaar.
• 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 door de verbindingen van eindgebruikers of een ander toepassingsspecifiek prioriteitsschema te gebruiken.

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

Als de storing tijdelijk was, is het mogelijk dat de primaire regio wordt hersteld door Azure voordat alle databaseherstelbewerkingen zijn voltooid in de dr-regio. Coördineer in dit geval het terugverplaatsen van de toepassing naar de primaire regio. Het proces voert de stappen uit die in het volgende diagram worden geïllustreerd.

• 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 secundair. Nu wisselen ze weer van rol.
• Wijzig de verbindingsreeks 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 hun gegevens tijdelijk niet beschikbaar.
• 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 of verwijdert u de bijbehorende databases in de primaire pool (7).
• Kopieer de bijgewerkte databases van de DR-pool naar de primaire pool (8).
• De DR-pool verwijderen (9)

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

Voordeel

Het belangrijkste voordeel van deze strategie is lage doorlopende kosten voor redundantie van gegevenslagen. Azure SQL Database maakt automatisch een back-up van databases zonder opnieuw schrijven van toepassingen zonder extra kosten. De kosten worden alleen gemaakt wanneer de elastische databases worden hersteld.

Compromis

De afweging is dat het volledige herstel van alle tenantdatabases veel tijd in beslag neemt. De tijdsduur is afhankelijk van het totale aantal herstelbewerkingen dat u initieert in de dr-regio en de totale grootte van de tenantdatabases. Zelfs als u prioriteit geeft aan de herstelbewerkingen van sommige tenants boven andere, concurreert u met alle andere herstelbewerkingen die in dezelfde regio worden gestart, terwijl de service reguleert en beperkt om de algehele impact op de databases van bestaande klanten te minimaliseren. Bovendien kan het herstel van de tenantdatabases pas beginnen wanneer de nieuwe elastische pool in de DR-regio 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 voor betalende klanten. Voor de proefklanten moet ik de kosten zoveel mogelijk verlagen. Proefklanten kunnen uitvaltijd nemen, maar ik wil de kans verkleinen. Voor de betalende klanten is downtime een vluchtrisico. Ik wil er dus voor zorgen dat betalende klanten altijd toegang hebben tot hun gegevens.

Om dit scenario te ondersteunen, 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.

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

De tenantdatabases van betalende klanten hebben actieve databases in de betaalde pool ingericht in de primaire regio. Richt een secundaire pool in met dezelfde naam in de DR-regio. 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:

• Voer onmiddellijk een failover uit van de beheerdatabases naar de dr-regio (3).
• Wijzig de verbindingsreeks van de toepassing zodat deze verwijst naar de dr-regio. Nu worden alle nieuwe accounts en tenantdatabases gemaakt in de DR-regio. De bestaande proefklanten zien hun gegevens tijdelijk niet beschikbaar.
• 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 metagegevensniveau is, kunt u een optimalisatie overwegen 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 ze secundair waren, verhoogt u de poolcapaciteit onmiddellijk om de volledige workload van alle tenants (5) te kunnen verwerken.
• Maak de nieuwe elastische pool met dezelfde naam en configuratie in de DR-regio voor de databases van de proefklanten (6).
• Zodra de pool van de proefklanten is gemaakt, gebruik dan geo-herstel om de individuele proeftenantdatabases te herstellen in de nieuwe pool. 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 regio dr. Alle betalende klanten hebben toegang tot hun gegevens terwijl de proefklanten vertraging ondervinden bij het openen van hun gegevens.

Wanneer de primaire regio wordt hersteld door Azure nadat u de toepassing hebt hersteld in de regio herstel na noodgeval, kunt u doorgaan met het uitvoeren van de toepassing in die regio of u kunt 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 worden geïllustreerd in het volgende diagram:

• 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 tenant-databases (9). Op dezelfde manier worden de oude primaire kopieën na het herstel van de regio automatisch de secundaire kopieën. Nu worden ze weer de voorverkiezingen.
• Stel de herstelde testdatabases die in de DR-regio zijn gewijzigd, in op alleen-lezen (10).
• Voor elke database in de DR-pool van proefklanten die zijn gewijzigd sinds het herstel, hernoemt of verwijdert u de bijbehorende database in de primaire pool van proefklanten (11).
• Kopieer de bijgewerkte databases van de DR-pool naar de primaire pool (12).
• Verwijder de DR-pool (13).

Notitie

De failoverbewerking is asynchroon. Om de hersteltijd te minimaliseren, is het belangrijk dat u de failoveropdracht van de tenantdatabase 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 vrijgegeven zodra de DR-pool is gemaakt.

Compromis

De afweging is dat deze configuratie de totale kosten van de tenantdatabases verhoogt door de kosten van de secundaire DR-pool voor betalende klanten. Bovendien, als de secundaire pool een andere grootte heeft, ervaren betalende klanten lagere prestaties na een failover totdat de poolupgrade in de rampenherstelregio is voltooid.

Scenario 3. Geografisch gedistribueerde toepassing met gelaagde service

Ik heb een volwassen SaaS-toepassing met gelaagde serviceaanbiedingen. Ik wil een zeer agressieve SLA aanbieden aan mijn betaalde klanten en het risico op impact minimaliseren wanneer er storingen optreden, omdat zelfs korte onderbrekingen tot ontevreden klanten kunnen 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 om dit scenario te ondersteunen. Richt twee groepen met gelijke grootte in met hoge eDTU's of vCores per database in twee verschillende regio's om de tenantdatabases van de betaalde klanten te 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. Als een regio offline is, worden maar 50% van de databases van betalende klanten beïnvloed en moet er een failover plaatsvinden. De andere databases blijven intact. Deze configuratie wordt geïllustreerd in het volgende diagram:

Net als in de vorige scenario's zijn de beheerdatabases vrij actief, dus configureer ze als individuele geo-gerepliceerde databases (1). Dit zorgt voor de 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 herstel van de beheerdatabases.

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

Het volgende diagram illustreert de herstelstappen die moeten worden uitgevoerd als er een storing optreedt in regio A.

• Voeren onmiddellijk een failover uit van de beheerdatabases naar regio B (3).
• Wijzig de verbindingsreeks 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 hun gegevens tijdelijk niet beschikbaar.
• Voer een failover uit 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 metagegevensniveau is, kunt u een optimalisatie overwegen waarbij de afzonderlijke failovers op aanvraag worden geactiveerd door de verbindingen van de eindgebruiker.
• Omdat 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 worden verhoogd.
• Maak de nieuwe elastische pool met dezelfde naam en dezelfde configuratie in de regio B voor de databases van de proefklanten (6).
• Zodra de pool is aangemaakt, herstelt u met geo-herstel de individuele proefdatabase van de tenant in de pool (7). U kunt overwegen om de afzonderlijke herstelbewerkingen te activeren door de verbindingen van eindgebruikers 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 om terug te vallen op de pool met proefklanten in regio A. Een van de criteria kan de % zijn van proeftenantdatabases die zijn gewijzigd sinds het herstel. Ongeacht deze beslissing moet u de betaalde tenants tussen twee pools opnieuw verdelen. Het volgende diagram illustreert het proces wanneer de databases van de proeftenant een failback uitvoeren naar regio A.

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

Voordeel

De belangrijkste voordelen van deze strategie zijn:

• Het biedt ondersteuning voor de meest agressieve SLA voor de betalende klanten, omdat deze 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 efficiënter gebruik van de poolcapaciteit mogelijk omdat 50% secundaire databases in pool 1 en pool 2 gegarandeerd minder actief zijn dan de primaire databases.

Compromissen

De belangrijkste afwegingen zijn:

• De CRUD-bewerkingen op basis van 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 van de beheerdatabases.
• Hiervoor is een complexer ontwerp van de beheerdatabase vereist. Elke tenantrecord heeft bijvoorbeeld een locatietag die moet worden gewijzigd tijdens de 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 geeft een overzicht van de voordelen en afwegingen, zodat u een weloverwogen beslissing kunt nemen. Uw specifieke toepassing bevat waarschijnlijk ook andere Azure-onderdelen. U controleert dus de richtlijnen voor bedrijfscontinuïteit en organiseert het herstel van de databaselaag met hen. Raadpleeg Cloudoplossingen ontwerpen voor herstel na noodgevallenvoor meer informatie over het beheren van herstel van databasetoepassingen in Azure.

Volgende stappen

• Zie geautomatiseerde back-ups van Azure SQL Databasevoor meer informatie over geautomatiseerde back-ups van Azure SQL Database.
• Zie Overzicht van bedrijfscontinuïteitvoor een overzicht van bedrijfscontinuïteit en scenario's.
• Zie een database herstellen vanuit de door de service geïnitieerde back-upsvoor meer informatie over het gebruik van geautomatiseerde back-ups voor herstel.
• Zie Actieve geo-replicatie en Failover-groepenvoor meer informatie over snellere herstelopties.
• Zie databasekopievoor meer informatie over het gebruik van geautomatiseerde back-ups voor archivering.