Hantera löpande uppgraderingar av molnprogram med hjälp av aktiv geo-replikering i SQL Database

Gäller för:Azure SQL Database

Lär dig hur du använder aktiv geo-replikering i Azure SQL Database för att aktivera löpande uppgraderingar av ditt molnprogram. Eftersom uppgraderingar är störande åtgärder bör de ingå i planeringen och utformningen av affärskontinuitet. I den här artikeln tittar vi på två olika metoder för att samordna uppgraderingsprocessen och diskuterar fördelarna och kompromisserna med varje alternativ. I den här artikeln refererar vi till ett program som består av en webbplats som är ansluten till en enskild databas som datanivå. Vårt mål är att uppgradera version 1 (V1) av programmet till version 2 (V2) utan någon betydande inverkan på användarupplevelsen.

När du utvärderar uppgraderingsalternativ bör du tänka på följande faktorer:

• Påverkan på programmets tillgänglighet under uppgraderingar, till exempel hur länge programfunktionerna kan begränsas eller försämras.
• Möjlighet att återställa om uppgraderingen misslyckas.
• Programmets sårbarhet om ett orelaterat, oåterkalleligt fel inträffar under uppgraderingen.
• Total dollarkostnad. Den här faktorn omfattar ytterligare databasredundans och inkrementella kostnader för de tillfälliga komponenter som används av uppgraderingsprocessen.

Uppgradera program som förlitar sig på databassäkerhetskopior för haveriberedskap

Om ditt program förlitar sig på automatiska säkerhetskopior av databaser och använder geo-återställning för haveriberedskap distribueras det till en enda Azure-region. För att minimera användarstörningar skapar du en mellanlagringsmiljö i den regionen med alla programkomponenter som ingår i uppgraderingen. Det första diagrammet illustrerar driftsmiljön före uppgraderingsprocessen. Slutpunkten contoso.azurewebsites.net representerar en produktionsmiljö för webbappen. För att kunna återställa uppgraderingen måste du skapa en mellanlagringsmiljö med en fullständigt synkroniserad kopia av databasen. Följ de här stegen för att skapa en mellanlagringsmiljö för uppgraderingen:

1. Skapa en sekundär databas i samma Azure-region. Övervaka sekundären för att se om seeding-processen är klar (1).
2. Skapa en ny miljö för webbappen och kalla den "Mellanlagring". Den registreras i Azure DNS med URL:en contoso-staging.azurewebsites.net (2).

Kommentar

De här förberedelsestegen påverkar inte produktionsmiljön, som kan fungera i läget för fullständig åtkomst.

När förberedelsestegen är klara är programmet redo för den faktiska uppgraderingen. Nästa diagram illustrerar de steg som ingår i uppgraderingsprocessen:

1. Ange den primära databasen till skrivskyddat läge (3). Det här läget garanterar att produktionsmiljön för webbappen (V1) förblir skrivskyddad under uppgraderingen, vilket förhindrar dataavvikelser mellan V1- och V2-databasinstanserna.
2. Koppla från den sekundära databasen med hjälp av det planerade avslutningsläget (4). Den här åtgärden skapar en fullständigt synkroniserad, oberoende kopia av den primära databasen. Den här databasen kommer att uppgraderas.
3. Aktivera den sekundära databasen till läs- och skrivläge och kör uppgraderingsskriptet (5).

Om uppgraderingen har slutförts är du nu redo att byta användare till den uppgraderade kopian av programmet, som blir en produktionsmiljö. Växlingen omfattar några fler steg, vilket visas i nästa diagram:

1. Aktivera en växlingsåtgärd mellan webbappens produktions- och mellanlagringsmiljöer (6). Den här åtgärden växlar URL:erna för de två miljöerna. Pekar nu contoso.azurewebsites.net på V2-versionen av webbplatsen och databasen (produktionsmiljön).
2. Om du inte längre behöver V1-versionen, som blev en mellanlagringskopia efter växlingen, kan du inaktivera mellanlagringsmiljön (7).

Om uppgraderingsprocessen misslyckas (till exempel på grund av ett fel i uppgraderingsskriptet) kan du överväga att mellanlagringsmiljön är komprometterad. Om du vill återställa programmet till föruppgraderingstillståndet återställer du programmet i produktionsmiljön till fullständig åtkomst. Nästa diagram visar omversionsstegen:

1. Ställ in databaskopian i läs- och skrivläge (8). Den här åtgärden återställer den fullständiga V1-funktionen för produktionskopian.
2. Utför rotorsaksanalysen och inaktivera mellanlagringsmiljön (9).

Nu är programmet fullt fungerande och du kan upprepa uppgraderingsstegen.

Kommentar

Återställningen kräver inte DNS-ändringar eftersom du ännu inte utförde någon växlingsåtgärd.

Den största fördelen med det här alternativet är att du kan uppgradera ett program i en enda region genom att följa en uppsättning enkla steg. Dollarkostnaden för uppgraderingen är relativt låg.

Den största kompromissen är att om ett oåterkalleligt fel inträffar under uppgraderingen innebär återställningen till föruppgraderingstillståndet att omdistribuera programmet i en annan region och återställa databasen från säkerhetskopian med hjälp av geo-återställning. Den här processen resulterar i betydande stilleståndstid.

Uppgradera program som förlitar sig på databas-geo-replikering för haveriberedskap

Om ditt program använder aktiv geo-replikering eller redundansgrupper för affärskontinuitet distribueras det till minst två olika regioner. Det finns en aktiv, primär databas i en primär region och en skrivskyddad, sekundär databas i en säkerhetskopieringsregion. Tillsammans med de faktorer som nämns i början av den här artikeln måste uppgraderingsprocessen också garantera att:

• Programmet förblir alltid skyddat mot oåterkalleliga fel under uppgraderingsprocessen.
• De geo-redundanta komponenterna i programmet uppgraderas parallellt med de aktiva komponenterna.

För att uppnå dessa mål kan du, förutom att använda Web Apps-miljöer, dra nytta av Azure Traffic Manager genom att använda en redundansprofil med en aktiv slutpunkt och en slutpunkt för säkerhetskopiering. Nästa diagram illustrerar driftmiljön före uppgraderingsprocessen. Webbplatserna contoso-1.azurewebsites.net och contoso-dr.azurewebsites.net representerar en produktionsmiljö för programmet med fullständig geografisk redundans. Produktionsmiljön innehåller följande komponenter:

• Produktionsmiljön för webbappen contoso-1.azurewebsites.net i den primära regionen (1)
• Den primära databasen i den primära regionen (2)
• En standby-instans av webbappen i säkerhetskopieringsregionen (3)
• Den geo-replikerade sekundära databasen i säkerhetskopieringsregionen (4)
• En Traffic Manager-prestandaprofil med en onlineslutpunkt som heter contoso-1.azurewebsites.net och en offlineslutpunkt med namnet contoso-dr.azurewebsites.net

För att göra det möjligt att återställa uppgraderingen måste du skapa en mellanlagringsmiljö med en helt synkroniserad kopia av programmet. Eftersom du måste se till att programmet snabbt kan återställas om ett oåterkalleligt fel inträffar under uppgraderingsprocessen måste mellanlagringsmiljön också vara geo-redundant. Följande steg krävs för att skapa en mellanlagringsmiljö för uppgraderingen:

1. Distribuera en mellanlagringsmiljö för webbappen i den primära regionen (6).
2. Skapa en sekundär databas i den primära Azure-regionen (7). Konfigurera mellanlagringsmiljön för webbappen för att ansluta till den.
3. Skapa en annan geo-redundant, sekundär databas i säkerhetskopieringsregionen genom att replikera den sekundära databasen i den primära regionen. (Den här metoden kallas för länkad geo-replikering.) (8).
4. Distribuera en mellanlagringsmiljö för webbappinstansen i säkerhetskopieringsregionen (9) och konfigurera den för att ansluta den geo-redundanta sekundära databasen som skapades på (8).

Kommentar

De här förberedelsestegen påverkar inte programmet i produktionsmiljön. Den förblir fullt fungerande i läs- och skrivläge.

När förberedelsestegen är klara är mellanlagringsmiljön redo för uppgraderingen. Nästa diagram illustrerar dessa uppgraderingssteg:

1. Ange den primära databasen i produktionsmiljön till skrivskyddat läge (10). Det här läget garanterar att produktionsdatabasen (V1) inte ändras under uppgraderingen, vilket förhindrar dataavvikelser mellan V1- och V2-databasinstanserna.

-- Set the production database to read-only mode
ALTER DATABASE [<Prod_DB>]
SET READ_ONLY

2. Avsluta geo-replikering genom att koppla från den sekundära (11). Den här åtgärden skapar en oberoende men fullständigt synkroniserad kopia av produktionsdatabasen. Den här databasen kommer att uppgraderas. I följande exempel används Transact-SQL men PowerShell är också tillgängligt.

-- Disconnect the secondary, terminating geo-replication
ALTER DATABASE [<Prod_DB>]
REMOVE SECONDARY ON SERVER [<Partner-Server>]

3. Kör uppgraderingsskriptet mot contoso-1-staging.azurewebsites.net, contoso-dr-staging.azurewebsites.netoch den primära mellanlagringsdatabasen (12). Databasändringarna replikeras automatiskt till den sekundära mellanlagringen.

Om uppgraderingen har slutförts är du nu redo att byta användare till V2-versionen av programmet. Nästa diagram illustrerar de steg som ingår:

1. Aktivera en växlingsåtgärd mellan produktions- och mellanlagringsmiljöer för webbappen i den primära regionen (13) och i säkerhetskopieringsregionen (14). V2 i programmet blir nu en produktionsmiljö med en redundant kopia i säkerhetskopieringsregionen.
2. Om du inte längre behöver V1-programmet (15 och 16) kan du inaktivera mellanlagringsmiljön.

Om uppgraderingsprocessen misslyckas (till exempel på grund av ett fel i uppgraderingsskriptet) bör du överväga att mellanlagringsmiljön är i ett inkonsekvent tillstånd. Om du vill återställa programmet till föruppgraderingstillståndet återgår du till att använda V1 för programmet i produktionsmiljön. De nödvändiga stegen visas i nästa diagram:

1. Ange den primära databaskopian i produktionsmiljön till läs- och skrivläge (17). Den här åtgärden återställer fullständiga V1-funktioner i produktionsmiljön.
2. Utför rotorsaksanalysen och reparera eller ta bort mellanlagringsmiljön (18 och 19).

Nu är programmet fullt fungerande och du kan upprepa uppgraderingsstegen.

Kommentar

Återställningen kräver inte DNS-ändringar eftersom du inte utförde någon växlingsåtgärd.

Den största fördelen med det här alternativet är att du kan uppgradera både programmet och dess geo-redundanta kopia parallellt utan att äventyra affärskontinuiteten under uppgraderingen.

Den största kompromissen är att den kräver dubbel redundans för varje programkomponent och därför medför högre dollarkostnader. Det innebär också ett mer komplicerat arbetsflöde.

Sammanfattning

De två uppgraderingsmetoderna som beskrivs i artikeln skiljer sig åt i komplexitet och dollarkostnad, men båda fokuserar på att minimera hur länge användaren är begränsad till skrivskyddade åtgärder. Den tiden definieras direkt av uppgraderingsskriptets varaktighet. Det beror inte på databasens storlek, vilken tjänstnivå du har valt, webbplatskonfigurationen eller andra faktorer som du inte enkelt kan kontrollera. Alla förberedelsesteg är frikopplade från uppgraderingsstegen och påverkar inte produktionsprogrammet. Uppgraderingsskriptets effektivitet är en viktig faktor som avgör användarupplevelsen under uppgraderingarna. Det bästa sättet att förbättra den upplevelsen är därför att fokusera på att göra uppgraderingsskriptet så effektivt som möjligt.

Relaterat innehåll

• Översikt över affärskontinuitet.
• Skapa läsbara sekundära databaser med aktiv geo-replikering.
• Använd redundansgrupper för att aktivera transparent och samordnad redundansväxling av flera databaser.
• Konfigurera mellanlagringsmiljöer i Azure App Service.
• Hantera en Azure Traffic Manager-profil.