Rolling upgrades van cloudtoepassingen beheren met behulp van actieve geo-replicatie van SQL Database

Van toepassing op: Azure SQL Database

Meer informatie over het gebruik van actieve geo-replicatie in Azure SQL Database om rolling upgrades van uw cloudtoepassing mogelijk te maken. Omdat upgrades verstorende bewerkingen zijn, moeten ze deel uitmaken van uw bedrijfscontinuïteitsplanning en -ontwerp. In dit artikel kijken we naar twee verschillende methoden voor het organiseren van het upgradeproces en bespreken we de voordelen en afwegingen van elke optie. Voor de doeleinden van dit artikel verwijzen we naar een toepassing die bestaat uit een website die is verbonden met één database als gegevenslaag. Ons doel is om versie 1 (V1) van de toepassing te upgraden naar versie 2 (V2), zonder dat dit van grote invloed is op de gebruikerservaring.

Houd bij het evalueren van upgradeopties rekening met de volgende factoren:

• Invloed op de beschikbaarheid van toepassingen tijdens upgrades, zoals hoe lang toepassingsfuncties mogelijk beperkt of verslechterd zijn.
• Mogelijkheid om terug te draaien als de upgrade mislukt.
• Beveiligingsprobleem van de toepassing als er een ongerelateerde, onherstelbare fout optreedt tijdens de upgrade.
• Totale dollarkosten. Deze factor omvat extra databaseredundantie en incrementele kosten van de tijdelijke onderdelen die door het upgradeproces worden gebruikt.

Toepassingen upgraden die afhankelijk zijn van databaseback-ups voor herstel na noodgevallen

Als uw toepassing afhankelijk is van automatische databaseback-ups en geo-herstel gebruikt voor herstel na noodgevallen, wordt deze geïmplementeerd in één Azure-regio. Als u de onderbreking van gebruikers wilt minimaliseren, maakt u een faseringsomgeving in die regio met alle toepassingsonderdelen die betrokken zijn bij de upgrade. Het eerste diagram illustreert de operationele omgeving vóór het upgradeproces. Het eindpunt contoso.azurewebsites.net vertegenwoordigt een productieomgeving van de web-app. Als u de upgrade wilt terugdraaien, moet u een faseringsomgeving maken met een volledig gesynchroniseerde kopie van de database. Volg deze stappen om een faseringsomgeving te maken voor de upgrade:

1. Maak een secundaire database in dezelfde Azure-regio. Controleer de secundaire om te zien of het seedingproces is voltooid (1).
2. Maak een nieuwe omgeving voor uw web-app en noem deze fasering. Deze wordt geregistreerd in Azure DNS met de URL contoso-staging.azurewebsites.net (2).

Notitie

Deze voorbereidingsstappen hebben geen invloed op de productieomgeving, die in de modus volledig toegankelijk kan zijn.

Wanneer de voorbereidingsstappen zijn voltooid, is de toepassing gereed voor de daadwerkelijke upgrade. In het volgende diagram ziet u de stappen die betrokken zijn bij het upgradeproces:

1. Stel de primaire database in op de modus Alleen-lezen (3). Deze modus garandeert dat de productieomgeving van de web-app (V1) alleen-lezen blijft tijdens de upgrade, waardoor gegevensverschillen tussen de V1- en V2-database-exemplaren worden voorkomen.
2. Verbreek de secundaire database met behulp van de geplande beëindigingsmodus (4). Met deze actie maakt u een volledig gesynchroniseerde, onafhankelijke kopie van de primaire database. Deze database wordt bijgewerkt.
3. Zet de secundaire database in de lees-/schrijfmodus en voer het upgradescript (5) uit.

Als de upgrade is voltooid, bent u nu klaar om gebruikers over te schakelen naar de bijgewerkte kopie van de toepassing, die een productieomgeving wordt. Voor het overschakelen zijn nog enkele stappen nodig, zoals wordt geïllustreerd in het volgende diagram:

1. Activeer een wisselbewerking tussen productie- en faseringsomgevingen van de web-app (6). Met deze bewerking worden de URL's van de twee omgevingen overgeschakeld. Verwijst nu contoso.azurewebsites.net naar de V2-versie van de website en de database (productieomgeving).
2. Als u de V1-versie, die na de wissel een faseringskopie werd, niet meer nodig hebt, kunt u de faseringsomgeving (7) buiten gebruik stellen.

Als het upgradeproces mislukt (bijvoorbeeld vanwege een fout in het upgradescript), kunt u overwegen de faseringsomgeving in gevaar te komen. Als u de toepassing wilt terugdraaien naar de status van de pre-upgrade, herstelt u de toepassing in de productieomgeving naar volledige toegang. In het volgende diagram ziet u de stappen voor het terugkeren:

1. Stel de databasekopie in op de lees-/schrijfmodus (8). Met deze actie wordt de volledige V1-functionaliteit van de productiekopie hersteld.
2. Voer de hoofdoorzaakanalyse uit en ontruim de faseringsomgeving (9).

Op dit moment is de toepassing volledig functioneel en kunt u de upgradestappen herhalen.

Notitie

Voor het terugdraaien zijn geen DNS-wijzigingen vereist omdat u nog geen wisselbewerking hebt uitgevoerd.

Het belangrijkste voordeel van deze optie is dat u een toepassing in één regio kunt upgraden door een set eenvoudige stappen te volgen. De dollarkosten van de upgrade zijn relatief laag.

Het belangrijkste nadeel is dat als er een catastrofale fout optreedt tijdens de upgrade, het herstel naar de status van de pre-upgrade de toepassing opnieuw implementeert in een andere regio en de database herstelt vanuit een back-up met behulp van geo-herstel. Dit proces resulteert in aanzienlijke downtime.

Toepassingen upgraden die afhankelijk zijn van geo-replicatie van databases voor herstel na noodgevallen

Als uw toepassing actieve geo-replicatie of failovergroepen gebruikt voor bedrijfscontinuïteit, wordt deze geïmplementeerd in ten minste twee verschillende regio's. Er is een actieve, primaire database in een primaire regio en een alleen-lezen secundaire database in een back-upregio. Naast de factoren die aan het begin van dit artikel worden genoemd, moet het upgradeproces ook garanderen dat:

• De toepassing blijft altijd beschermd tegen onherstelbare fouten tijdens het upgradeproces.
• De geografisch redundante onderdelen van de toepassing worden parallel met de actieve onderdelen bijgewerkt.

Als u deze doelen wilt bereiken, profiteert u naast het gebruik van de Web Apps-omgevingen van Azure Traffic Manager met behulp van een failoverprofiel met één actief eindpunt en één back-upeindpunt. In het volgende diagram ziet u de operationele omgeving vóór het upgradeproces. De websites contoso-1.azurewebsites.net en contoso-dr.azurewebsites.net vertegenwoordigen een productieomgeving van de toepassing met volledige geografische redundantie. De productieomgeving bevat de volgende onderdelen:

• De productieomgeving van de web-app contoso-1.azurewebsites.net in de primaire regio (1)
• De primaire database in de primaire regio (2)
• Een stand-by-exemplaar van de web-app in de back-upregio (3)
• De secundaire database met geo-replicatie in de back-upregio (4)
• Een Traffic Manager-prestatieprofiel met een online-eindpunt met de naam contoso-1.azurewebsites.net en een offline-eindpunt met de naam contoso-dr.azurewebsites.net

Als u de upgrade wilt terugdraaien, moet u een faseringsomgeving maken met een volledig gesynchroniseerde kopie van de toepassing. Omdat u ervoor moet zorgen dat de toepassing snel kan herstellen als er een onherstelbare fout optreedt tijdens het upgradeproces, moet de faseringsomgeving ook geografisch redundant zijn. De volgende stappen zijn vereist voor het maken van een faseringsomgeving voor de upgrade:

1. Implementeer een faseringsomgeving van de web-app in de primaire regio (6).
2. Maak een secundaire database in de primaire Azure-regio (7). Configureer de faseringsomgeving van de web-app om er verbinding mee te maken.
3. Maak een andere geografisch redundante secundaire database in de back-upregio door de secundaire database in de primaire regio te repliceren. (Deze methode wordt geketende geo-replicatie genoemd.) (8).
4. Implementeer een faseringsomgeving van het web-app-exemplaar in de back-upregio (9) en configureer deze om verbinding te maken met de geografisch redundante secundaire database die is gemaakt op (8).

Notitie

Deze voorbereidingsstappen hebben geen invloed op de toepassing in de productieomgeving. Het blijft volledig functioneel in de lees-/schrijfmodus.

Wanneer de voorbereidingsstappen zijn voltooid, is de faseringsomgeving gereed voor de upgrade. In het volgende diagram ziet u de volgende upgradestappen:

1. Stel de primaire database in de productieomgeving in op de modus Alleen-lezen (10). Deze modus garandeert dat de productiedatabase (V1) niet wordt gewijzigd tijdens de upgrade, waardoor de gegevensverschillen tussen de V1- en V2-databaseinstanties worden voorkomen.

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

2. Beëindig geo-replicatie door de secundaire verbinding (11) te verbreken. Met deze actie wordt een onafhankelijke maar volledig gesynchroniseerde kopie van de productiedatabase gemaakt. Deze database wordt bijgewerkt. In het volgende voorbeeld wordt Gebruikgemaakt van Transact-SQL, maar PowerShell is ook beschikbaar.

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

3. Voer het upgradescript uit op contoso-1-staging.azurewebsites.net, contoso-dr-staging.azurewebsites.neten de primaire faseringsdatabase (12). De databasewijzigingen worden automatisch gerepliceerd naar de secundaire fasering.

Als de upgrade is voltooid, kunt u nu overschakelen naar de V2-versie van de toepassing. In het volgende diagram ziet u de stappen die nodig zijn:

1. Activeer een wisselbewerking tussen productie- en faseringsomgevingen van de web-app in de primaire regio (13) en in de back-upregio (14). V2 van de toepassing wordt nu een productieomgeving, met een redundante kopie in de back-upregio.
2. Als u de V1-toepassing (15 en 16) niet meer nodig hebt, kunt u de faseringsomgeving buiten gebruik stellen.

Als het upgradeproces mislukt (bijvoorbeeld vanwege een fout in het upgradescript), moet de faseringsomgeving een inconsistente status hebben. Als u de toepassing wilt terugdraaien naar de status van de pre-upgrade, gaat u terug naar het gebruik van V1 van de toepassing in de productieomgeving. De vereiste stappen worden weergegeven in het volgende diagram:

1. Stel de primaire databasekopie in de productieomgeving in op de lees-/schrijfmodus (17). Met deze actie herstelt u de volledige V1-functionaliteit in de productieomgeving.
2. Voer de hoofdoorzaakanalyse uit en herstel of verwijder de faseringsomgeving (18 en 19).

Op dit moment is de toepassing volledig functioneel en kunt u de upgradestappen herhalen.

Notitie

Voor het terugdraaien zijn geen DNS-wijzigingen vereist omdat u geen wisselbewerking hebt uitgevoerd.

Het belangrijkste voordeel van deze optie is dat u zowel de toepassing als de geografisch redundante kopie parallel kunt upgraden zonder de bedrijfscontinuïteit tijdens de upgrade in gevaar te brengen.

Het belangrijkste nadeel is dat er dubbele redundantie van elk toepassingsonderdeel nodig is en daarom hogere dollarkosten in rekening worden gebracht. Het omvat ook een complexere werkstroom.

Samenvatting

De twee upgrademethoden die in het artikel worden beschreven, verschillen in complexiteit en dollarkosten, maar beide richten zich op het minimaliseren van hoe lang de gebruiker beperkt is tot alleen-lezenbewerkingen. Deze tijd wordt rechtstreeks gedefinieerd door de duur van het upgradescript. Dit is niet afhankelijk van de databasegrootte, de servicelaag die u hebt gekozen, de websiteconfiguratie of andere factoren die u niet eenvoudig kunt beheren. Alle voorbereidingsstappen worden losgekoppeld van de upgradestappen en hebben geen invloed op de productietoepassing. De efficiëntie van het upgradescript is een belangrijke factor die de gebruikerservaring tijdens upgrades bepaalt. De beste manier om die ervaring te verbeteren, is door uw inspanningen te richten op het zo efficiënt mogelijk maken van het upgradescript.

Gerelateerde inhoud

• Overzicht van bedrijfscontinuïteit.
• Leesbare secundaire databases maken met actieve geo-replicatie.
• Gebruik failovergroepen om transparante en gecoördineerde failover van meerdere databases mogelijk te maken.
• Faseringsomgevingen instellen in Azure-app Service.
• Een Azure Traffic Manager-profiel beheren.