Haveriberedskap för ett SaaS-program med flera klientorganisationer med hjälp av databas-geo-replikering

Gäller för:Azure SQL Database

I den här självstudien utforskar du ett fullständigt haveriberedskapsscenario för ett SaaS-program för flera innehavare som implementeras med hjälp av modellen database-per-tenant. För att skydda appen från ett avbrott använder du geo-replikering för att skapa repliker för katalogen och klientdatabaserna i en alternativ återställningsregion. Om ett avbrott inträffar redundansväxlar du snabbt till dessa repliker för att återuppta normala affärsåtgärder. Vid redundans blir databaserna i den ursprungliga regionen sekundära repliker av databaserna i återställningsregionen. När replikerna är online igen kommer de automatiskt ikapp databasernas tillstånd i återställningsregionen. När avbrotten har lösts kan du återställa till databaserna i den ursprungliga produktionsregionen.

Den här självstudien utforskar både arbetsflöden för redundans och återställning efter fel. Du lär dig att:

• Synkronisera databas- och elastisk poolkonfigurationsinformation till klientkatalogen
• Konfigurera en återställningsmiljö i en alternativ region som består av program, servrar och pooler
• Använd geo-replikering för att replikera katalogen och klientdatabaserna till återställningsregionen
• Redundansväst program- och katalog- och klientdatabaser till återställningsregionen
• Senare redundansväxlar du program-, katalog- och klientdatabaserna tillbaka till den ursprungliga regionen efter att avbrottet har lösts
• Uppdatera katalogen när varje klientdatabasreds för att spåra den primära platsen för varje klientorganisations databas
• Se till att programmet och den primära klientdatabasen alltid är samlokaliserade i samma Azure-region för att minska svarstiden

Innan du påbörjar den här självstudien kontrollerar du att följande krav har slutförts:

• Wingtip Tickets SaaS-databasen per klientapp distribueras. Information om hur du distribuerar på mindre än fem minuter finns i Distribuera och utforska Wingtip Tickets SaaS-databasen per klientprogram
• Azure PowerShell ska ha installerats. Mer information finns i Komma igång med Azure PowerShell

Introduktion till återställningsmönstret för geo-replikering

Haveriberedskap (DR) är ett viktigt övervägande för många program, oavsett om det gäller efterlevnadsskäl eller affärskontinuitet. Om det skulle uppstå ett långvarigt avbrott i tjänsten kan en väl förberedd DR-plan minimera avbrott i verksamheten. Med geo-replikering får du det lägsta RPO och RTO genom att underhålla databasrepliker i en återställningsregion som kan redundas över till med kort varsel.

En DR-plan baserad på geo-replikering består av tre olika delar:

• Konfiguration – skapande och underhåll av återställningsmiljön
• Återställning – redundansväxling av appen och databaserna till återställningsmiljön om ett avbrott inträffar,
• Repatriering – redundansväxling av appen och databaserna tillbaka till den ursprungliga regionen när programmet har lösts

Alla delar måste övervägas noggrant, särskilt om de används i stor skala. Planen måste totalt sett uppnå flera mål:

• Installationen
  • Upprätta och underhålla en spegelbildsmiljö i återställningsregionen. När du skapar elastiska pooler och replikerar databaser i den här återställningsmiljön reserveras kapaciteten i återställningsregionen. Att underhålla den här miljön omfattar replikering av nya klientdatabaser när de etableras.
• Återhämtning
  • Om en nedskalad återställningsmiljö används för att minimera de dagliga kostnaderna måste pooler och databaser skalas upp för att hämta fullständig driftskapacitet i återställningsregionen
  • Aktivera ny klientetablering i återställningsregionen så snart som möjligt
  • Optimeras för att återställa klienter i prioritetsordning
  • Optimeras för att få klienter online så snabbt som möjligt genom att utföra åtgärder parallellt där det är praktiskt
  • Vara motståndskraftig mot fel, omstartsbar och idempotent
  • Det går att avbryta processen mitt under flygning om den ursprungliga regionen kommer tillbaka online.
• Repatriering
  • Redundansväxla databaser från återställningsregionen till repliker i den ursprungliga regionen med minimal påverkan på klientorganisationer: ingen dataförlust och minsta period utanför linjen per klientorganisation.

I den här självstudien hanteras dessa utmaningar med hjälp av funktionerna i Azure SQL Database och Azure-plattformen:

• 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 produktionsservrarna och elastiska pooler i återställningsregionen.
• Geo-replikering för att skapa asynkront replikerade skrivskyddade sekundärfiler för alla databaser. Under ett avbrott redundansväxlar du till replikerna i återställningsregionen. När avbrottet har lösts växlar du tillbaka till databaserna i den ursprungliga regionen utan dataförlust.
• Asynkrona redundansåtgärder som skickas i klientprioritetsordning för att minimera redundanstiden för ett stort antal databaser.
• Återställningsfunktioner för horisontell hantering för att ändra databasposter i katalogen under återställning och repatriering. Med de här funktionerna kan appen ansluta till klientdatabaser oavsett plats utan att konfigurera om appen.
• SQL Server DNS-alias för att möjliggöra sömlös etablering av nya klienter oavsett vilken region appen arbetar i. DNS-alias används också för att tillåta att katalogsynkroniseringsprocessen ansluter till den aktiva katalogen oavsett var den finns.

Hämta skript för haveriberedskap

Viktigt!

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

Återställningsskripten som används i den här självstudien och Wingtip-programmets källkod ä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.

Översikt över självstudier

I den här självstudien använder du först geo-replikering för att skapa repliker av Wingtip Tickets-programmet och dess databaser i en annan region. Sedan redundansväxlar du till den här regionen för att simulera återställning från ett avbrott. När det är klart fungerar programmet fullt ut i återställningsregionen.

Senare, i ett separat repatrieringssteg, redundansväxlar du katalogen och klientdatabaserna i återställningsregionen till den ursprungliga regionen. Programmet och databaserna är tillgängliga under hela repatrieringen. När det är klart fungerar programmet fullt ut i den ursprungliga regionen.

Kommentar

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

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-biljetter (http://events.wingtip-dpt.<user.trafficmanager.net> – ersätt <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. TIPS: Hovra musen över platsen för att förstora skärmen.

2. Klicka på Contoso Concert Hall-klientorganisationen och öppna dess evenemangssida.

   • Lägg märke till klientserverns namn i sidfoten. Platsen kommer att vara samma som katalogserverns plats.

3. I Azure-portalen öppnar du resursgruppen där appen distribueras

   • Observera den region där servrarna distribueras.

Synkronisera klientkonfiguration till katalog

I den här uppgiften startar du en process som synkroniserar konfigurationen av servrar, elastiska pooler och databaser till klientkatalogen. Processen håller den här informationen uppdaterad i katalogen. Processen fungerar med den aktiva katalogen, oavsett om den finns i den ursprungliga regionen eller i återställningsregionen. Konfigurationsinformationen används som en del av återställningsprocessen för att säkerställa att återställningsmiljön överensstämmer med den ursprungliga miljön och sedan senare under repatrieringen för att säkerställa att den ursprungliga regionen överensstämmer med eventuella ändringar som görs i återställningsmiljön. Katalogen används också för att hålla reda på återställningstillståndet för klientresurser

Viktigt!

För enkelhetens skull implementeras synkroniseringsprocessen och andra tidskrävande återställnings- och repatrieringsprocesser i dessa självstudier 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-FailoverToReplica\Demo-FailoverToReplica.ps1 och anger:

   • $DemoScenario = 1 startar du ett bakgrundsjobb som synkroniserar klientservern och information om poolkonfiguration i katalogen

3. Tryck på F5 för att köra synkroniseringsskriptet. En ny PowerShell-session öppnas för att synkronisera konfigurationen av klientresurser.

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

Kommentar

Synkroniseringsprocessen ansluter till katalogen via ett DNS-alias. Det här 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.

Skapa sekundära databasrepliker i återställningsregionen

I den här uppgiften startar du en process som distribuerar en duplicerad appinstans och replikerar katalogen och alla klientdatabaser till en återställningsregion.

Kommentar

Den här självstudien lägger till geo-replikeringsskydd i exempelprogrammet Wingtip Tickets. I ett produktionsscenario för ett program som använder geo-replikering etableras varje klientorganisation med en geo-replikerad databas från början. Se Designa tjänster med hög tillgänglighet med Hjälp av Azure SQL Database

1. I PowerShell ISE öppnar du skriptet ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 och anger följande värden:

   • $DemoScenario = 2, Skapa spegelbildsåterställningsmiljö och replikera katalog- och klientdatabaser

2. Tryck F5 för att köra skriptet. En ny PowerShell-session öppnas för att skapa replikerna.

Granska det normala programtillståndet

Nu körs programmet normalt i den ursprungliga regionen och skyddas nu av geo-replikering. Skrivskyddade sekundära repliker finns i återställningsregionen för alla databaser.

1. I Azure-portalen tittar du på dina resursgrupper och noterar att en resursgrupp har skapats med suffixet -recovery i återställningsregionen.

2. Utforska resurserna i återställningsresursgruppen.

3. Klicka på Contoso Concert Hall-databasen på servern tenants1-dpt-user-recovery<>. Klicka på Geo-Replikering till vänster.

   

Observera geo-replikeringslänken mellan den primära i den ursprungliga regionen och den sekundära i återställningsregionen på kartan över Azure-regioner.

Redundansvä redundansvävent programmet till återställningsregionen

Översikt över återställningsprocessen för geo-replikering

Återställningsskriptet utför följande uppgifter:

1. Inaktiverar 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. Använder en tvingad redundansväxling av katalogdatabasen i återställningsregionen för att göra den till den primära databasen och uppdaterar activecatalog-aliaset så att det pekar på återställningskatalogservern.

3. Uppdateringar det nya aliaset för att peka på klientservern i återställningsregionen. Om du ändrar det här aliaset ser du till att databaserna för alla nya klienter etableras i återställningsregionen.

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

5. Uppdateringar konfigurationen av alla elastiska pooler och replikerade enskilda databaser i återställningsregionen för att spegla deras konfiguration i den ursprungliga regionen. (Den här uppgiften behövs bara om pooler eller replikerade databaser i återställningsmiljön skalas ned under normala åtgärder för att minska kostnaderna).

6. 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.

7. Skickar batchar med begäranden för att tvinga redundansväxla databaser i prioritetsordning.

   • Batchar ordnas så att databaser redväxlar parallellt över alla pooler.
   • Redundansbegäranden skickas med asynkrona åtgärder så att de skickas snabbt och flera begäranden kan bearbetas samtidigt.

   Kommentar

   I ett avbrottsscenario är de primära databaserna i den ursprungliga regionen offline. Framtvinga redundansväxling på den sekundära bryter anslutningen till den primära utan att försöka tillämpa några kvarvarande köade transaktioner. Om det finns någon uppdateringsaktivitet vid tidpunkten för redundansväxlingen kan data gå förlorade i ett dr-testscenario som den här självstudien. Senare, under repatriering, när du redundansväxlar databaser i återställningsregionen tillbaka till den ursprungliga regionen, används en normal redundansväxling för att säkerställa att inga data går förlorade.

8. Övervakar tjänsten för att avgöra när databaser har redväxats. När en klientdatabas har red växlats över uppdateras katalogen för att registrera återställningstillståndet för klientdatabasen och markera klientorganisationen som online.

   • Klientdatabaser kan nås av programmet så snart de har markerats online i katalogen.
   • En summa av radversionsvärden i klientdatabasen lagras i katalogen. Det här värdet fungerar som ett fingeravtryck som gör att repatrieringsprocessen kan avgöra om databasen har uppdaterats i återställningsregionen.

Kör skriptet för att redundansväsna till återställningsregionen

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

1. I PowerShell ISE öppnar du skriptet ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1 och anger följande värden:

   • $DemoScenario = 3 återställer du appen till en återställningsregion genom att växla över till repliker

2. Tryck F5 för att köra skriptet.

   • Skriptet öppnas i ett nytt PowerShell-fönster och startar sedan en serie PowerShell-jobb som körs parallellt. De här jobben redundansväxlar klientdatabaser 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-FailoverToReplica\RecoveryJobs.

Granska programtillståndet under återställningen

Programslutpunkten är inaktiverad i Traffic Manager, men programmet är inte tillgängligt. När katalogen har redväxlar till återställningsregionen och alla klienter har markerats offline tas programmet tillbaka online igen. Även om programmet är tillgängligt visas varje klientorganisation offline i händelsehubben tills dess databas har redväxlar över. Det är viktigt att utforma programmet så att det hanterar offlineklientdatabaser.

1. När katalogdatabasen har återställts 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.

     Kommentar

     Med bara ett fåtal databaser att återställa kanske du inte kan uppdatera webbläsaren innan återställningen har slutförts, så du kanske inte ser klienterna när de är offline.

     

   • Om du öppnar en offlineklients händelsesida direkt visas meddelandet "klient offline". Om Contosos konserthus 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 alla befintliga klientdatabaser har redväxlar kan du etablera nya klienter i återställningsregionen.

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

   • $DemoScenario = 4 etablerar du en ny klientorganisation i återställningsregionen

2. Tryck på F5 för att köra skriptet och etablera den nya klientorganisationen.

3. Sidan Hawthorn Hall-evenemang öppnas i webbläsaren när den är klar. Observera från sidfoten att Hawthorn Hall-databasen etableras 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. Hyresgästerna kommer alla att visas online, inklusive den nya hyresgästen Hawthorn Hall.

   

2. Ö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.

3. Ö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.

   • App Service med namnet events-wingtip-dpt-recoveryregion-user<<>>, som är återställningsinstansen för appen Händelser.

     

4. Ö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 pool1 elastisk pool.

5. Gå tillbaka till resursgruppen och klicka på Contoso Concert Hall-databasen på servern tenants1-dpt-user-recovery><. Klicka på Geo-Replikering till vänster.

   

Ändra klientdata

I den här uppgiften uppdaterar du en av klientdatabaserna.

1. I webbläsaren letar du upp händelselistan för Contosos konserthus och noterar namnet på den sista händelsen.
2. I PowerShell ISE anger du följande värde i skriptet ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1:
   • $DemoScenario = 5 Ta bort en händelse från en klientorganisation i återställningsregionen
3. Tryck på F5 för att köra skriptet
4. Uppdatera sidan Contoso Concert Hall-evenemang (http://events.wingtip-dpt.<user.trafficmanager.net/contosoconcerthall> – ersätt <användaren> med din distributions användarvärde) och observera att den senaste händelsen har tagits bort.

Skicka tillbaka programmet till den ursprungliga produktionsregionen

Den här uppgiften skickar tillbaka programmet till den ursprungliga regionen. I ett verkligt scenario initierar du repatriering när avbrottet har lösts.

Översikt över repatrieringsprocessen

Repatrieringsprocessen:

1. Avbryter eventuella utestående eller pågående begäranden om databasåterställning.
2. Uppdateringar det nya aliaset så att det pekar på klientorganisationens server i ursprungsregionen. Om du ändrar det här aliaset ser du till att databaserna för alla nya klienter nu etableras i ursprungsregionen.
3. Frön alla ändrade klientdata till den ursprungliga regionen
4. Redundansväxlar klientdatabaser i prioritetsordning.

Redundans flyttar databasen till den ursprungliga regionen. När databasen redundansväxlar tas alla öppna anslutningar bort och databasen är inte tillgänglig i några sekunder. Program ska skrivas med logik för återförsök för att säkerställa att de ansluter igen. Även om den här korta frånkopplingen ofta inte märks kan du välja att skicka tillbaka databaser från kontorstid.

Kör repatrieringsskriptet

Nu ska vi föreställa oss att avbrottet är löst och kör repatrieringsskriptet.

1. I PowerShell ISE går du till skriptet ...\Learning Modules\Business Continuity and Disaster Recovery\DR-FailoverToReplica\Demo-FailoverToReplica.ps1.

2. Kontrollera att katalogsynkroniseringsprocessen fortfarande körs i powershell-instansen. Om det behövs startar du om den genom att ange:

   • $DemoScenario = 1, Börja synkronisera klientserver, pool och databaskonfigurationsinformation i katalogen
   • Tryck F5 för att köra skriptet.

3. Starta sedan repatrieringsprocessen genom att ange:

   • $DemoScenario = 6 skickar du tillbaka appen till den ursprungliga regionen
   • Tryck på F5 för att köra återställningsskriptet i ett nytt PowerShell-fönster. Repatriering tar flera minuter och kan övervakas i PowerShell-fönstret.

4. När skriptet körs uppdaterar du sidan Händelsehubb (http://events.wingtip-dpt.<user.trafficmanager.net>)

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

5. När repatrieringen är klar uppdaterar du evenemangshubben och öppnar evenemangssidan för Hawthorn Hall. Observera att databasen har skickats tillbaka till den ursprungliga regionen.

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

Programmet är utformat så att det alltid ansluter från en instans i samma region som klientdatabasen. 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. I SQL Database är servernamnet 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. Omdirigering till instans i samma region som databasen minimerar svarstiden mellan app och databas.

Nästa steg

I den här guiden lärde du dig hur man:

• Synkronisera databas- och elastisk poolkonfigurationsinformation till klientkatalogen
• Konfigurera en återställningsmiljö i en alternativ region som består av program, servrar och pooler
• Använd geo-replikering för att replikera katalogen och klientdatabaserna till återställningsregionen
• Redundansväst program- och katalog- och klientdatabaser till återställningsregionen
• Återställa program-, katalog- och klientdatabaserna till den ursprungliga regionen efter att driftstoppet har lösts

Du kan lära dig mer om de tekniker som Azure SQL Database tillhandahåller för att möjliggöra affärskontinuitet i dokumentationen översikt över affärskontinuitet.

Ytterligare resurser

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