Använd geoåterställning för att återställa en multitenant SaaS-applikation från databassäkerhetskopior.

gäller för:Azure SQL Database

Den här handledningen utforskar ett fullständigt katastrofåterställningsscenario för ett multitenant SaaS-program som implementerats med en databas-per-hyresgäst-modell. Du använder geo-återställning för att återställa katalog- och klientdatabaserna från automatiskt underhållna geo-redundanta säkerhetskopior till en alternativ återställningsregion. När avbrottet har lösts använder du geo-replikering för att skicka tillbaka ändrade databaser till den ursprungliga regionen.

Geo-återställning är den billigaste haveriberedskapslösningen för Azure SQL Database. Men att återställa från geo-redundanta säkerhetskopior kan potentiellt leda till dataförlust i vissa scenarier eftersom Azure Geo-Redundant Storage (GRS) replikerar data asynkront till en sekundär region. Det innebär att replikeringsprocessen har viss fördröjning, men den exakta svarstiden kan variera beroende på flera faktorer, inklusive avståndet mellan de primära och sekundära regionerna och de aktuella nätverksvillkoren. Replikeringsfördröjningen för GRS ligger vanligtvis inom intervallet minuter, men det är inte säkert att den ligger inom en viss tidsram. Det kan ta lång tid, beroende på storleken på varje databas.

Not

Återställ program med lägsta möjliga RPO och RTO med hjälp av geo-replikering i stället för geo-återställning.

I den här handledningen utforskas arbetsflöden för både återställning och repatriering. Du lär dig att:

• Synkronisera databas- och elastisk poolkonfigurationsinformation till klientkatalogen.
• Konfigurera en spegelbildsmiljö i en återställningsregion som innehåller program, servrar och pooler.
• Återställa katalog- och klientdatabaser med hjälp av geo-återställning.
• Använd geo-replikering för att återföra klientkatalogen och klientdatabaser som ändrats efter att avbrottet har lösts.
• Uppdatera katalogen när varje databas återställs (eller skickas tillbaka) för att spåra den aktuella platsen för den aktiva kopian av varje klientorganisations databas.
• Se till att program- och klientdatabasen alltid finns i samma Azure-region för att minska svarstiden.

Slutför följande krav innan du påbörjar den här självstudien:

• Distribuera Wingtip Tickets SaaS-databasen för varje hyresgästprogram. Om du vill implementera på mindre än fem minuter, läs Implementera och utforska Wingtip Tickets SaaS-databas för varje klientapplikation.
• Installera Azure PowerShell. Mer information finns i Komma igång med Azure PowerShell.

Introduktion till strategin för geo-återställning

Haveriberedskap (DR) är ett viktigt övervägande för många program, oavsett om det gäller efterlevnadsskäl eller affärskontinuitet. Om det uppstår ett långvarigt avbrott i tjänsten kan en väl förberedd DR-plan minimera avbrott i verksamheten. En DR-plan baserad på geografisk återställning måste uppnå flera mål:

• Reservera all kapacitet som behövs i den valda återställningsregionen så snabbt som möjligt för att säkerställa att den är tillgänglig för att återställa klientdatabaser.
• Upprätta en spegelbildsåterställningsmiljö som återspeglar den ursprungliga pool- och databaskonfigurationen.
• Tillåt annullering av återställningsprocessen mitt under flygning om den ursprungliga regionen är online igen.
• Aktivera klientetablering snabbt så att ny klientregistrering kan startas om så snart som möjligt.
• Optimeras för att återställa hyresgäster i prioritetsordning.
• Optimeras för att få hyresgäster online så fort som möjligt genom att utföra åtgärder parallellt när det är möjligt.
• Var motståndskraftig mot fel, omstartsbar och idempotent.
• Återföra databaser till deras ursprungliga region med minimal påverkan på hyresgäster när avbrottet har lösts.

Not

Programmet återställs till den kopplade regionen i den region där programmet distribueras. Mer information finns i azure-kopplade regioner.

I den här självstudien används funktioner i Azure SQL Database och Azure-plattformen för att hantera dessa utmaningar:

• Azure Resource Manager-mallarför att reservera all kapacitet som behövs så snabbt som möjligt. Azure Resource Manager-mallar används för att etablera en speglingsbild av de ursprungliga servrarna och elastiska poolerna i återställningsregionen. En separat server och pool skapas också för tillhandahållande av nya klienter.
• Elastic Database Client Library (EDCL) för att skapa och underhålla en klientdatabaskatalog. Den utökade katalogen innehåller regelbundet uppdaterad information om pool- och databaskonfiguration.
• Återställningsfunktioner för shardhantering i EDCL för att underhålla databasplatsposter i katalogen under återställning och repatriering.
• Geo-restoreför att återställa katalog- och klientdatabaserna från automatiskt underhållna geo-redundanta säkerhetskopior.
• Asynkrona återställningsåtgärder, som skickas i prioritetsordning för klientorganisationen, placeras i kö för varje pool av systemet och bearbetas i batchar så att poolen inte överbelastas. Dessa åtgärder kan avbrytas före eller under körningen om det behövs.
• Geo-replikering, för att återföra databaser till den ursprungliga regionen efter avbrott. Det finns ingen dataförlust och påverkan på hyresgästen är minimal när du använder geo-replikering.
• DNS-alias för SQL-server, så att katalogsynkroniseringsprocessen kan ansluta till den aktiva katalogen oavsett var den finns.

Hämta skript för återställning vid katastrof

DR-skripten som används i den här självstudien är tillgängliga i Wingtip Tickets SaaS-databasen för varje hyresgäst i GitHub-repositoriet. Se allmänna vägledningen för steg för att ladda ned och avblockera hanteringsskripten för Wingtip-biljetter.

Viktig

Precis som alla hanteringsskript för Wingtip-biljetter är DR-skripten av demonstrationskvalitet och ska inte användas i produktion.

Granska programmets felfria tillstånd

Innan du påbörjar återställningsprocessen bör du granska programmets normala felfria tillstånd.

1. Öppna händelsehubben Wingtip Tickets i webbläsaren (http://events.wingtip-dpt.<user>.trafficmanager.net, ersätt <user> med distributionens användarvärde).

   Rulla längst ned på sidan och lägg märke till katalogserverns namn och plats i sidfoten. Platsen är den region där du distribuerade appen.

   Tips

   Hovra musen över platsen för att förstora skärmen.

   

2. Välj hyresgästen Contoso Concert Hall och öppna dess evenemangssida.

   Lägg märke till klientorganisationens servernamn i sidfoten. Platsen är samma som katalogserverns plats.

   

3. I Azure-portalengranskar och öppnar du resursgruppen där du distribuerade appen.

   Observera de resurser och den region där App Service-komponenterna och SQL Database distribueras.

Synkronisera klientkonfigurationen till katalogen

I den här uppgiften startar du en process för att synkronisera konfigurationen av servrar, elastiska pooler och databaser till klientkatalogen. Den här informationen används senare för att konfigurera en spegelbildsmiljö i återställningsregionen.

Viktig

För enkelhetens skull implementeras synkroniseringsprocessen och andra tidskrävande återställnings- och repatrieringsprocesser i dessa exempel som lokala PowerShell-jobb eller sessioner som körs under din klientanvändarinloggning. Autentiseringstoken som utfärdas när du loggar in upphör att gälla efter flera timmar och jobben misslyckas sedan. I ett produktionsscenario bör långvariga processer implementeras som tillförlitliga Azure-tjänster av något slag, som körs under ett huvudnamn för tjänsten. Se Använd Azure PowerShell för att skapa ett tjänstehuvudnamn med ett certifikat.

1. Öppna filen ...\Learning Modules\UserConfig.psm1 i PowerShell ISE. Ersätt <resourcegroup> och <user> på raderna 10 och 11 med det värde som användes när du distribuerade appen. Spara filen.

2. Öppna skriptet ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 i PowerShell ISE.

   I den här självstudien kör du var och en av scenarierna i det här PowerShell-skriptet, så håll filen öppen.

3. Ange följande:

   $DemoScenario = 1: Start a background job that syncs tenant server and pool configuration info into the catalog.

4. Om du vill köra synkroniseringsskriptet väljer du F5.

   Den här informationen används senare för att säkerställa att återställningen skapar en speglingsbild av servrar, pooler och databaser i återställningsregionen.

   

Låt PowerShell-fönstret vara igång i bakgrunden och fortsätt med resten av den här självstudien.

Not

Synkroniseringsprocessen ansluter till katalogen via ett DNS-alias. Aliaset ändras under återställning och repatriering så att det pekar på den aktiva katalogen. Synkroniseringsprocessen håller katalogen uppdaterad med alla ändringar i databas- eller poolkonfigurationen som görs i återställningsregionen. Under repatrieringen tillämpas dessa ändringar på motsvarande resurser i den ursprungliga regionen.

Översikt över återställningsprocessen för geoåterställning

Återställningsprocessen för geoåterställning distribuerar programmet och återställer databaser från säkerhetskopior i återställningsregionen.

Återställningsprocessen gör följande:

1. Inaktiverar Azure Traffic Manager-slutpunkten för webbappen i den ursprungliga regionen. Genom att inaktivera slutpunkten förhindras användare från att ansluta till appen i ett ogiltigt tillstånd om den ursprungliga regionen skulle bli online under återställningsprocessen.

2. Etablerar en återställningskatalogserver i återställningsregionen, geo-återställer katalogdatabasen och uppdaterar activecatalog-aliaset så att det pekar på den återställde katalogservern. Om du ändrar katalogaliaset ser du till att katalogsynkroniseringsprocessen alltid synkroniseras till den aktiva katalogen.

3. Markerar alla befintliga klienter i återställningskatalogen som offline för att förhindra åtkomst till klientdatabaser innan de återställs.

4. Etablerar en instans av appen i återställningsregionen och konfigurerar den för att använda den återställde katalogen i den regionen. För att hålla svarstiden till ett minimum är exempelappen utformad för att alltid ansluta till en klientdatabas i samma region.

5. Etablerar en server och elastisk pool där nya klienter etableras. Att skapa dessa resurser säkerställer att tillhandahållandet av nya klienter inte stör återställningen av befintliga klienter.

6. Uppdaterar det nya klientaliaset så att det pekar på servern för nya klientdatabaser i återställningsregionen. Om du ändrar det här aliaset ser du till att databaser för alla nya klienter etableras i återställningsregionen.

7. Etablerar servrar och elastiska pooler i återställningsregionen för återställning av klientdatabaser. Dessa servrar och pooler är en speglingsbild av konfigurationen i den ursprungliga regionen. Att tilldela pooler i förväg reserverar den kapacitet som krävs för att återställa alla databaser.

   Ett avbrott i en region kan innebära ett betydande tryck på de resurser som är tillgängliga i den kopplade regionen. Om du förlitar dig på geo-återställning för dr rekommenderas att du reserverar resurser snabbt. Överväg geo-replikering om det är viktigt att ett program återställs i en viss region.

8. Aktiverar Traffic Manager-slutpunkten för webbappen i återställningsregionen. Genom att aktivera den här slutpunkten kan programmet tillhandahålla nya klienter. I det här skedet är befintliga klienter fortfarande offline.

9. Skickar batchar med begäranden för att återställa databaser i prioritetsordning.

   • Batchar ordnas så att databaser återställs parallellt i alla pooler.

   • Återställningsbegäranden skickas asynkront så att de skickas snabbt och placeras i kö för körning i varje pool.

   • Eftersom återställningsbegäranden bearbetas parallellt mellan alla pooler är det bättre att distribuera viktiga klienter mellan många pooler.

10. Övervakar tjänsten för att avgöra när databaser återställs. När en klientdatabas har återställts markeras den som online i katalogen, och en radversionssumma för klientdatabasen registreras.

    • Klientdatabaser kan nås av programmet så snart de har markerats online i katalogen.

    • En summa av radversionsvärden i klientdatabasen lagras i katalogen. Den här summan fungerar som ett fingeravtryck som gör att repatrieringsprocessen kan avgöra om databasen uppdaterades i återställningsregionen.

Kör återställningsskriptet

Viktig

Den här handledningen återställer databaser från geo-redundanta säkerhetskopior. Även om dessa säkerhetskopior vanligtvis är tillgängliga inom 10 minuter kan det ta längre tid. Skriptet pausar tills de är tillgängliga.

Anta att det finns ett avbrott i regionen där programmet distribueras och kör återställningsskriptet:

1. I PowerShell ISE anger du följande värde i skriptet ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1:

   $DemoScenario = 2: Recover the app into a recovery region by restoring from geo-redundant backups.

2. Om du vill köra skriptet väljer du F5.

   • Skriptet öppnas i ett nytt PowerShell-fönster och startar sedan en uppsättning PowerShell-jobb som körs parallellt. Dessa jobb återställer servrar, pooler och databaser till återställningsregionen.

   • Återställningsregionen är den parkopplade region som är associerad med den Azure-region där du distribuerade programmet. För mer information, se Azure ihopkopplade regioner.

3. Övervaka status för återställningsprocessen i PowerShell-fönstret.

   

Not

Om du vill utforska koden för återställningsjobben granskar du PowerShell-skripten i mappen ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\RecoveryJobs.

Granska programtillståndet under återställningen

Programslutpunkten är inaktiverad i Traffic Manager, men programmet är inte tillgängligt. Katalogen återställs, och alla hyresgäster markeras offline. Programslutpunkten i återställningsregionen aktiveras sedan och programmet är online igen. Även om applikationen är tillgänglig visas hyresgäster offline i händelsehubben tills deras databaser har återställts. Det är viktigt att utforma programmet så att det hanterar offlineklientdatabaser.

• När katalogdatabasen har återställts men innan klienterna är online igen, uppdaterar du Wingtip Tickets Events Hub i webbläsaren.

  • Observera att katalogservernamnet nu har ett -recovery suffix i sidfoten och att det finns i återställningsregionen.

  • Observera att klienter som ännu inte har återställts markeras som offline och inte kan väljas.

    

  • Om du öppnar en hyresgästs händelsesida direkt när hyresgästen är offline visas ett offline-meddelande. Om Contoso Concert Hall till exempel är offline kan du försöka öppna http://events.wingtip-dpt.<user>.trafficmanager.net/contosoconcerthall.

    

Skapa en ny klient i återställningsregionen

Även innan klientdatabaserna återställs kan du etablera nya klienter i återställningsregionen. Nya klientdatabaser som etableras i återställningsregionen skickas tillbaka med de återställda databaserna senare.

1. I PowerShell ISE anger du följande egenskap i skriptet ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1:

   $DemoScenario = 3: Provision a new tenant in the recovery region.

2. Om du vill köra skriptet väljer du F5.

3. Evenemangssidan för Hawthorn Hall öppnas i webbläsaren när provisioneringen är klar.

   Observera att Hawthorn Hall-databasen finns i återställningsregionen.

   

4. I webbläsaren uppdaterar du sidan Wingtip Tickets events hub för att se Hawthorn Hall inkluderad.

   Om du ställde i ordning Hawthorn Hall utan att vänta på att de andra hyresgästerna skulle återställas kan andra hyresgäster fortfarande vara offline.

Granska programmets återställda tillstånd

När återställningsprocessen är klar fungerar programmet och alla klienter fullt ut i återställningsregionen.

1. När visningen i PowerShell-konsolfönstret anger att alla klienter har återställts uppdaterar du händelsehubben.

   Alla hyresgäster syns online, inklusive den nya hyresgästen Hawthorn Hall.

   

2. Klicka på Contosos konserthus och öppna dess evenemangssida.

   Observera att databasen finns på återställningsservern i återställningsregionen i sidfoten.

   

3. Öppna listan över resursgrupper i Azure-portalen.

   Observera resursgruppen som du distribuerade, plus återställningsresursgruppen, med suffixet -recovery. Återställningsresursgruppen innehåller alla resurser som skapades under återställningsprocessen, plus nya resurser som skapades under driftstoppet.

4. Öppna återställningsresursgruppen och lägg märke till följande:

   • Återställningsversionerna av katalog- och hyresgäster1-servrarna med suffixet -recovery. De återställde katalog- och klientdatabaserna på dessa servrar har alla de namn som används i den ursprungliga regionen.

   • Den tenants2-dpt-<user>-recovery SQL-servern. Den här servern används för att etablera nya klienter under driftstoppet.

   • Apptjänsten med namnet events-wingtip-dpt-<recoveryregion>-<user>, som utgör återställningsinstansen för händelseappen.

     

5. Öppna tenants2-dpt-<user>-recovery SQL-servern. Observera att den innehåller databasen hawthornhall och den elastiska poolen Pool1. Hawthornhall-databasen konfigureras som en elastisk databas i den elastiska poolen Pool1.

Ändra hyresgästdetaljer

I den här uppgiften uppdaterar du en av de återställde klientdatabaserna. Repatrieringsprocessen kopierar återställda databaser som har ändrats tillbaka till den ursprungliga regionen.

1. Leta reda på händelselistan för Contosos konserthus i webbläsaren, bläddra igenom händelserna och lägg märke till den sista händelsen, Seriously Strauss.

2. I PowerShell ISE anger du följande värde i skriptet ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1:

   $DemoScenario = 4: Delete an event from a tenant in the recovery region.

3. Om du vill köra skriptet väljer du F5.

4. Uppdatera evenemangssidan för Contoso Concert Hall (http://events.wingtip-dpt.<user>.trafficmanager.net/contosoconcerthall) och observera att händelsen Seriously Strauss saknas.

Vid denna punkt i självstudien har du återställt programmet, som nu körs i återställningsregionen. Du har etablerat en ny kundorganisation i återställningsregionen och ändrat data för en av de återställda kundorganisationerna.

Obs

Andra självstudier i exemplet är inte utformade för att köras med appen i återställningstillståndet. Om du vill utforska andra självstudier måste du skicka tillbaka programmet först.

Översikt över repatrieringsprocessen

Repatrieringsprocessen återställer programmet och dess databaser till den ursprungliga regionen efter att ett avbrott har lösts.

Processen:

1. Stoppar pågående återställningsaktiviteter och avbryter eventuella utestående eller pågående begäranden om databasåterställning.

2. Återaktiverar hyresgästernas databaser i den ursprungliga regionen som inte har ändrats sedan driftstoppet. Dessa databaser inkluderar de som inte har återställts ännu och de som har återställts men inte ändrats efteråt. De återaktiverade databaserna är exakt så som de senast används av sina klienter.

3. Etablerar en speglingsbild av den nya klientorganisationens server och elastiska pool i den ursprungliga regionen. När den här åtgärden är klar uppdateras det nya klientaliaset så att det pekar på den här servern. Om du uppdaterar aliaset sker ny klientregistrering i den ursprungliga regionen i stället för återställningsregionen.

4. Använder geo-replikering för att flytta katalogen till den ursprungliga regionen från återställningsregionen.

5. Uppdaterar poolkonfigurationen i den ursprungliga regionen så att den överensstämmer med ändringar som gjordes i återställningsregionen under driftstoppet.

6. Skapar de servrar och pooler som krävs för att vara värd för alla nya databaser som skapas under driftstoppet.

7. Använder geo-replikering för att repatriera återställda klientdatabaser som har uppdaterats efter återställningen och alla nya klientdatabaser som etablerats under driftstoppet.

8. Rensar resurser som skapats i återställningsregionen under återställningsprocessen.

För att begränsa antalet klientdatabaser som behöver skickas tillbaka görs steg 1 till 3 omgående.

Steg 4 görs endast om katalogen i återställningsregionen har ändrats under driftstoppet. Katalogen uppdateras om nya klienter skapas eller om någon databas- eller poolkonfiguration ändras i återställningsregionen.

Det är viktigt att steg 7 orsakar minimala störningar för klientorganisationer och att inga data går förlorade. För att uppnå det här målet använder processen geo-replikering.

Innan varje databas geo-replikeras tas motsvarande databas i den ursprungliga regionen bort. Databasen i återställningsregionen är sedan geo-replikerad och skapar en sekundär replik i den ursprungliga regionen. När replikeringen är klar anges klientorganisationen i offline-läge i katalogen, vilket bryter alla kopplingar till databasen i återställningsregionen. Databasen växlar sedan över, vilket gör att väntande transaktioner bearbetas på den sekundära servern så att inga data går förlorade.

Vid redundansväxling är databasrollerna omvända. Den sekundära i den ursprungliga regionen blir den primära läs- och skrivdatabasen, och databasen i återställningsregionen blir en skrivskyddad sekundär. Klientposten i katalogen uppdateras för att referera till databasen i den ursprungliga regionen och klientorganisationen är markerad online. Nu är repatrieringen av databasen klar.

Program ska skrivas med logik för återförsök för att säkerställa att de återansluts automatiskt när anslutningarna bryts. När de använder katalogen för att ordna återanslutningen ansluter de till den repatrierade databasen i ursprungliga regionen. Även om den korta frånkopplingen ofta inte märks kan du välja att skicka tillbaka databaser från kontorstid.

När en databas har skickats tillbaka kan den sekundära databasen i återställningsregionen tas bort. Databasen i den ursprungliga regionen förlitar sig sedan igen på geo-återställning för DR-skydd.

I steg 8 tas resurser i återställningsregionen, inklusive återställningsservrar och pooler, bort.

Kör repatrieringsskriptet

Anta att avbrottet är löst och kör repatrieringsskriptet.

Om du har följt handledningen reaktiverar skriptet omedelbart Fabrikam Jazz Club och Dogwood Dojo i den ursprungliga regionen eftersom de är oförändrade. Sedan återlämnas den nya hyresgästen Hawthorn Hall och Contoso Concert Hall eftersom de har modifierats. Skriptet återför också katalogen, som uppdaterades när Hawthorn Hall färdigställdes.

1. I PowerShell ISE kontrollerar du i ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 skriptet att katalogsynkroniseringsprocessen fortfarande körs i powershell-instansen. Om det behövs, gör en omstart genom att ställa in:

   $DemoScenario = 1: Start synchronizing tenant server, pool, and database configuration info into the catalog.

   Om du vill köra skriptet väljer du F5.

2. Starta sedan repatrieringsprocessen genom att ange:

   $DemoScenario = 5: Repatriate the app into its original region.

   Om du vill köra återställningsskriptet i ett nytt PowerShell-fönster väljer du F5. Repatriering tar flera minuter och kan övervakas i PowerShell-fönstret.

3. När skriptet körs uppdaterar du händelsehubbens sida (http://events.wingtip-dpt.<user>.trafficmanager.net).

   Observera att alla klienter är online och tillgängliga under hela den här processen.

4. Välj Fabrikam Jazz Club för att öppna den. Om du inte har modifierat den här klientorganisationen ser du från sidfoten att servern redan har återställts till den ursprungliga servern.

5. Öppna eller uppdatera evenemangssidan för Contosos konserthus. Observera från sidfoten att databasen till en början fortfarande finns på -recovery-servern.

6. Uppdatera sidan Contoso Concert Hall-evenemang när repatrieringsprocessen är klar och observera att databasen nu finns i din ursprungliga region.

7. Uppdatera händelsehubben igen och öppna Hawthorn Hall. Observera att databasen också finns i den ursprungliga regionen.

Rensa resurser i återställningsregionen efter repatriering

När repatrieringen är klar är det säkert att ta bort resurserna i återställningsregionen.

Viktig

Ta bort dessa resurser omgående för att stoppa all fakturering för dem.

Återställningsprocessen skapar alla återställningsresurser i en återställningsresursgrupp. Rensningsprocessen tar bort den här resursgruppen och tar bort alla referenser till resurserna från katalogen.

1. I PowerShell ISE, i skriptet ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1, ställ in:

   $DemoScenario = 6: Delete obsolete resources from the recovery region.

2. Om du vill köra skriptet väljer du F5.

När du har rensat skripten är programmet tillbaka där det startade. Nu kan du köra skriptet igen eller prova andra självstudier.

Utforma programmet för att säkerställa att appen och databasen finns tillsammans

Programmet är utformat för att alltid ansluta från en instans i samma region som klientorganisationens databas. Den här designen minskar svarstiden mellan programmet och databasen. Den här optimeringen förutsätter att interaktionen mellan appar och databaser är chattigare än interaktionen mellan användare och app.

Hyresgästdatabaser kan spridas över både återställnings- och ursprungsregioner under en tid medan de återgår till ursprungsplatsen. För varje databas letar appen upp den region där databasen finns genom att göra en DNS-sökning på klientserverns namn. Servernamnet är ett alias. Det aliaserade servernamnet innehåller regionnamnet. Om programmet inte finns i samma region som databasen omdirigeras det till instansen i samma region som servern. Om du omdirigerar till instansen i samma region som databasen minimeras svarstiden mellan appen och databasen.

Nästa steg

I den här handledningen lär du dig att:

• Använd klientkatalogen för att lagra regelbundet uppdaterad konfigurationsinformation, vilket gör att en spegelbildsåterställningsmiljö kan skapas i en annan region.
• Återställ databaser till återställningsregionen genom att använda geo-restore.
• Uppdatera klientkatalogen så att den återspeglar återställde klientdatabasplatser.
• Använd ett DNS-alias för att aktivera ett program för att ansluta till klientkatalogen utan omkonfiguration.
• Använd geo-replikering för att repatriera återställda databaser till den ursprungliga regionen efter att ett avbrott har lösts.

Prova självstudiekursen Katastrofåterställning för en SaaS-applikation med många företag med hjälp av databasgeoreplikering för att lära dig hur du använder georeplikering för att avsevärt minska den tid som krävs för att återställa en storskalig applikation för många företag.

Ytterligare resurser

Ytterligare handledningar som bygger på Wingtip SaaS-applikationen