Använda geo-återställning för att återställa ett SaaS-program med flera klientorganisationer från databassäkerhetskopior

Gäller för:Azure SQL Database

Den här självstudien utforskar ett fullständigt haveriberedskapsscenario för ett SaaS-program med flera klienter som implementerats med databasen per klientorganisationsmodell. 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. Återställning från geo-redundanta säkerhetskopior kan dock leda till dataförlust på upp till en timme. Det kan ta lång tid, beroende på storleken på varje databas.

Kommentar

Å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 självstudien går vi igenom arbetsflöden för både återställning och repatriering. 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 repatriera klientkatalogen och ändrade klientdatabaser 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 per klientapp. Information om hur du distribuerar på mindre än fem minuter finns i Distribuera och utforska Wingtip Tickets SaaS-databasen per klientprogram.
• Installera Azure PowerShell. Mer information finns i Komma igång med Azure PowerShell.

Introduktion till återställningsmönstret 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å geo-å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 klienter i prioritetsordning.
• Optimeras för att få klienter online så snart som möjligt genom att utföra åtgärder parallellt där det är praktiskt.
• Var motståndskraftig mot fel, omstartsbar och idempotent.
• Skicka tillbaka databaser till den ursprungliga regionen med minimal påverkan på klientorganisationer när avbrotten har lösts.

Kommentar

Programmet återställs till den kopplade regionen i den region där programmet distribueras. Mer information finns i Länkade Azure-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-mallar fö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 etablering 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-återställning för att återställa katalogen 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 skicka databaser till den ursprungliga regionen efter driftstoppet. Det finns ingen dataförlust och minimal påverkan på klientorganisationen när du använder geo-replikering.
• SQL Server DNS-alias för att tillåta katalogsynkroniseringsprocessen att ansluta till den aktiva katalogen oavsett var den finns.

Hämta skript för haveriberedskap

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

Viktigt!

Precis som alla Hanteringsskript för Wingtip-biljetter är DR-skripten exempelkvalitet 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. I webbläsaren öppnar du händelsehubben Wingtip Tickets (http://events.wingtip-dpt.<user.trafficmanager.net> och ersätter <användaren> 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.

   Dricks

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

   

2. Välj Contoso Concert Hall-klientorganisationen och öppna dess händelsesida.

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

   

3. I Azure-portalen granskar 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.

Viktigt!

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ända Azure PowerShell för att skapa ett huvudnamn för tjänsten 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. I PowerShell ISE öppnar du skriptet ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1.

   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: Starta ett bakgrundsjobb som synkroniserar information om klientserver och poolkonfiguration i katalogen.

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.

Kommentar

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 till återställningsregionen.

Återställningsprocessen gör följande:

1. Inaktiverar Azure Traffic Manager-slutpunkten för webbappen i den ursprungliga regionen. Om du inaktiverar slutpunkten förhindras användare från att ansluta till appen i ett ogiltigt tillstånd om den ursprungliga regionen är online under återställningen.

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. Om du skapar dessa resurser ser du till att etableringen 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. Etableringspooler 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 etablera 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 online i katalogen och en rowversionssumma 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

Viktigt!

Den här självstudien återställer databaser från geo-redundanta säkerhetskopior. Även om dessa säkerhetskopior vanligtvis är tillgängliga inom 10 minuter kan det ta upp till en timme. Skriptet pausas 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: Återställa appen till en återställningsregion genom att återställa från geo-redundanta säkerhetskopior.

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. Mer information finns i Länkade Azure-regioner.

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

   

Kommentar

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 klienter markeras offline. Programslutpunkten i återställningsregionen aktiveras sedan och programmet är online igen. Även om programmet är tillgängligt visas klientorganisationer 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 händelsehubben Wingtip Tickets 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 klients händelsesida direkt när klientorganisationen är offline visas ett offlinemeddelande för en klientorganisation. Om Contoso Concert Hall till exempel är offline kan du försöka öppna http://events.wingtip-dpt.<user.trafficmanager.net/contosoconcerthall>.

    

Etablera en ny klientorganisation 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: Etablera en ny klientorganisation i återställningsregionen.

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

3. Sidan Hawthorn Hall-evenemang öppnas i webbläsaren när etableringen ä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 etablerade Hawthorn Hall utan att vänta på att de andra klienterna skulle återställas kan andra klienter 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 visas 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 katalogen och klientservrarna1 med suffixet -recovery. De återställde katalog- och klientdatabaserna på dessa servrar har alla de namn som används i den ursprungliga regionen.

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

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

     

5. Öppna SQL-servern tenants2-dpt-user-recovery<>. 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 klientdata

I den här uppgiften uppdaterar du en av de återställde klientdatabaserna. Repatrieringsprocessen kopierar återställde databaser som har ändrats 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: Ta bort en händelse från en klientorganisation i återställningsregionen.

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

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

Nu i självstudien har du återställt programmet, som nu körs i återställningsregionen. Du har etablerat en ny klientorganisation i återställningsregionen och ändrat data för en av de återställda klienterna.

Kommentar

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. Reactivates i den ursprungliga regionens klientdatabaser 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 markeras klientorganisationen offline i katalogen, vilket bryter alla anslutningar till databasen i återställningsregionen. Databasen rededs sedan över, vilket gör att väntande transaktioner bearbetas på den sekundära 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 skrivskyddade databasen och databasen i återställningsregionen blir 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 asynkrona återanslutningen ansluter de till den repatrierade databasen i den 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 självstudien reagerar skriptet omedelbart Fabrikam Jazz Club och Dogwood Dojo i den ursprungliga regionen eftersom de är oförändrade. Den repatrierar sedan den nya hyresgästen Hawthorn Hall och Contoso Concert Hall eftersom den har ändrats. Skriptet repatrierar också katalogen, som uppdaterades när Hawthorn Hall etablerades.

1. I PowerShell ISE kontrollerar du i skriptet ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 att katalogsynkroniseringsprocessen fortfarande körs i powershell-instansen. Om det behövs startar du om den genom att ange:

   $DemoScenario = 1: Börja synkronisera information om klientserver, pool och databaskonfiguration i katalogen.

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

2. Starta sedan repatrieringsprocessen genom att ange:

   $DemoScenario = 5: Skicka tillbaka appen till den ursprungliga regionen.

   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 sidan för händelsehubben (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.

Viktigt!

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 anger du i skriptet ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1:

   $DemoScenario = 6: Ta bort föråldrade resurser från återställningsregionen.

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.

Klientdatabaser kan spridas över återställning och ursprungliga regioner under en tid under repatriering. 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 självstudiekursen lärde 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älla databaser till återställningsregionen med hjälp av geo-återställning.
• 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älvstudien Haveriberedskap för ett SaaS-program med flera klientorganisationer med hjälp av självstudiekursen om geo-replikering för att lära dig hur du använder geo-replikering för att dramatiskt minska den tid som krävs för att återställa ett storskaligt flertenantprogram.

Ytterligare resurser

Ytterligare självstudier som bygger på Wingtip SaaS-programmet