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

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 din planering och design för affärskontinuhet. 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 enkel databas som datanivå. Vårt mål är att uppgradera version 1 (V1) av programmet till version 2 (V2) utan att påverka användarupplevelsen avsevärt.

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 programfunktioner kan vara begränsade eller degraderade.
• 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 databassäkerhetskopior och använder geo-återställning för haveriberedskap, distribueras det till en enda Azure-region. Om du vill minimera störningar för användaren 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 helt 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 den sekundära 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 url:en contoso-staging.azurewebsites.net (2).

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

1. Ställ in den primära databasen på skrivskyddade läge (3). Det här läget garanterar att webbappens (V1) produktionsmiljö förblir skrivskyddade under uppgraderingen, vilket förhindrar dataskillnader mellan databasinstanserna V1 och V2.
2. Koppla från den sekundära databasen med hjälp av det planerade avslutningsläget (4). Den här åtgärden skapar en helt synkroniserad, oberoende kopia av den primära databasen. Den här databasen kommer att uppgraderas.
3. Omvandla den sekundära databasen till läs-/skrivläge och kör uppgraderingsskriptet (5).

Om uppgraderingen slutförs ä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, som du ser i nästa diagram:

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

Om uppgraderingen misslyckas (till exempel på grund av ett fel i uppgraderingsskriptet) bör mellanlagringsmiljön vara 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 stegen för omversion:

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

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

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 huvudsakliga kompromissen är att om ett oåterkalleligt fel inträffar under uppgraderingen måste återställningen till tillståndet före uppgraderingen omdistribuera programmet i en annan region och återställa databasen från en säkerhetskopia med hjälp av geo-återställning. Den här processen resulterar i betydande driftstopp.

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

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

• Programmet förblir skyddat från oåterkalleliga fel hela tiden under uppgraderingsprocessen.
• Programmets geo-redundanta komponenter uppgraderas parallellt med de aktiva komponenterna.

För att uppnå dessa mål, utöver att använda Web Apps-miljöerna, använder du Azure Traffic Manager genom att använda en redundansprofil med en aktiv slutpunkt och en slutpunkt för säkerhetskopiering. Nästa diagram illustrerar driftsmiljön före uppgraderingsprocessen. Webbplatserna och contoso-1.azurewebsites.net representerar contoso-dr.azurewebsites.net 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 väntelägesinstans av webbappen i säkerhetskopieringsregionen (3)
• Den geo-replikerade sekundära databasen i säkerhetskopieringsregionen (4)
• En Traffic Manager med en onlineslutpunkt med namnet contoso-1.azurewebsites.net och en offlineslutpunkt som hetercontoso-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 (8).

När förberedelsestegen är klara är mellanlagringsmiljön redo för uppgraderingen. Nästa diagram illustrerar de här uppgraderingsstegen:

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

-- 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 helt synkroniserad kopia av produktionsdatabasen. Den här databasen kommer att uppgraderas. I följande exempel används Transact-SQL 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 , och den primära contoso-dr-staging.azurewebsites.net mellanlagringsdatabasen (12). Databasändringarna replikeras automatiskt till den sekundära mellanlagringsplatsen.

Om uppgraderingen slutförs ä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 av 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 uppgraderingen misslyckas (till exempel på grund av ett fel i uppgraderingsskriptet) bör mellanlagringsmiljön vara 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. Ställ in den primära databaskopian i produktionsmiljön på läs-/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 funktionellt och du kan upprepa uppgraderingsstegen.

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ärskontinuitet under uppgraderingen.

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

Sammanfattning

De två uppgraderingsmetoderna som beskrivs i artikeln skiljer sig åt vad gäller komplexitet och dollarkostnader, men båda fokuserar på att minimera hur länge användaren är begränsad till skrivskyddade åtgärder. Den tiden definieras direkt av varaktigheten för uppgraderingsskriptet. 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 fristående från uppgraderingsstegen och påverkar inte produktionsprogrammet. Effektiviteten i uppgraderingsskriptet är en viktig faktor som avgör användarupplevelsen under uppgraderingar. Det bästa sättet att förbättra upplevelsen är därför att fokusera på att göra uppgraderingsskriptet så effektivt som möjligt.

Nästa steg

• En översikt över affärskontinuuier och scenarier finns i Översikt över affärskontinuhet.
• Mer information om hur Azure SQL Database aktiv geo-replikering finns i Skapa läsbara sekundära databaser med aktiv geo-replikering.
• Mer information om Azure SQL Database för automatisk redundans finns i Använda automatiska redundansgrupper för att aktivera transparent och koordinerad redundans för flera databaser.
• Mer information om mellanlagringsmiljöer i Azure App Service finns i Konfigurera mellanlagringsmiljöer i Azure App Service.
• Mer information om Azure Traffic Manager finns i Hantera en Azure Traffic Manager profil.