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

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 planning en ontwerp voor bedrijfscontinuïteit. In dit artikel bekijken we twee verschillende methoden om het upgradeproces te orkestreren 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 de gegevenslaag. Ons doel is om versie 1 (V1) van de toepassing te upgraden naar versie 2 (V2) zonder dat dit van invloed is op de gebruikerservaring.

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

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

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

Als uw toepassing afhankelijk is van automatische databaseback-ups en geo-herstel gebruikt voor herstel na noodherstel, wordt deze geïmplementeerd in één Azure-regio. Als u de onderbreking van de gebruiker wilt minimaliseren, maakt u een faseringsomgeving in die regio met alle toepassingsonderdelen die bij de upgrade betrokken zijn. 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 voor de upgrade te maken:

1. Maak een secundaire database in dezelfde Azure-regio. Controleer de secundaire om te zien of het seeding-proces 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).

Wanneer de voorbereidingsstappen zijn voltooid, is de toepassing gereed voor de daadwerkelijke upgrade. In het volgende diagram ziet u de stappen die nodig 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 gegevensdupgrade tussen de V1- en V2-database-exemplaren wordt voorkomen.
2. Verbreed de secundaire database met behulp van de modus voor geplande beëindiging (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 uit (5).

Als de upgrade is voltooid, bent u er klaar voor om gebruikers over te schakelen naar de bijgewerkte kopie van de toepassing, die een productieomgeving wordt. Om over te schakelen, moeten nog enkele stappen worden doorlopen, 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 gewisseld. Wijst contoso.azurewebsites.net nu naar de V2-versie van de website en de database (productieomgeving).
2. Als u de versie V1, die na het wisselen een faseringskopie werd, niet meer nodig hebt, kunt u de faseringsomgeving buiten gebruik stellen (7).

Als het upgradeproces mislukt (bijvoorbeeld vanwege een fout in het upgradescript), kunt u de faseringsomgeving als gecompromitteerd beschouwen. Als u de toepassing wilt terugdraaien naar de status vóór de upgrade, keert u de toepassing in de productieomgeving terug naar volledige toegang. In het volgende diagram ziet u de stappen voor omkering:

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 voer de faseringsomgeving uit (9).

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

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

Het belangrijkste verschil is dat als er een onherstelbare fout optreedt tijdens de upgrade, het herstel naar de status vóór de upgrade betrekking heeft op het opnieuw toepassen van de toepassing in een andere regio en het herstellen van de database 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 noodherstel

Als uw toepassing gebruikmaakt van actieve geo-replicatie of groepen voor automatische failover 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 het volgende garanderen:

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

Om deze doelen te bereiken, kunt u niet alleen de Web Apps-omgevingen gebruiken, maar ook profiteren van Azure Traffic Manager door een failoverprofiel te gebruiken met één actief eindpunt en één back-up-eindpunt. Het volgende diagram illustreert de operationele omgeving vóór het upgradeproces. De websites en contoso-1.azurewebsites.net 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 naamcontoso-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 worden hersteld in het geval 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 nog een 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 om (8).

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

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

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

2. Beëindig geo-replicatie door de verbinding met de secundaire replicatie te verbreken (11). Met deze actie maakt u een onafhankelijke maar volledig gesynchroniseerde kopie van de productiedatabase. Deze database wordt bijgewerkt. In het volgende voorbeeld wordt 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 , en de primaire contoso-dr-staging.azurewebsites.net faseringsdatabase (12). De databasewijzigingen worden automatisch gerepliceerd naar de secundaire fasering.

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

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 u de faseringsomgeving als inconsistent beschouwen. Als u de toepassing wilt terugdraaien naar de status vóór de upgrade, keert u terug naar 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 wordt de volledige V1-functionaliteit in de productieomgeving hersteld.
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.

Het belangrijkste voordeel van deze optie is dat u zowel de toepassing als de geografisch redundante kopie parallel kunt upgraden zonder dat dit ten koste gaat van uw bedrijfscontinuïteit tijdens de upgrade.

De belangrijkste afweging is dat hiervoor dubbele redundantie van elk toepassingsonderdeel is vereist en daarom hogere kosten met zich meebrengt. Het omvat ook een complexere werkstroom.

Samenvatting

De twee upgrademethoden die in het artikel worden beschreven, verschillen in complexiteit en in dollars, maar ze zijn beide gericht op het minimaliseren van de tijd die de gebruiker beperkt is tot alleen-lezenbewerkingen. Deze tijd wordt rechtstreeks gedefinieerd door de duur van het upgradescript. Dit is niet afhankelijk van de grootte van de database, de servicelaag die u hebt gekozen, de websiteconfiguratie of andere factoren die u niet eenvoudig kunt controleren. 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.

Volgende stappen

• Raadpleeg Overzicht van bedrijfscontinuïteit voor een bedrijfscontinuïteitsoverzicht en bedrijfscontinuïteitsscenario's.
• Zie Leesbare Azure SQL Database maken met actieve geo-replicatie voor meer informatie over actieve geo-replicatie.
• Zie Voor meer Azure SQL Database van groepen voor automatische failover,zie Groepen voor automatische failover gebruiken om transparante en gecoördineerde failover van meerdere databases mogelijk te maken.
• Zie Faseringsomgevingen instellen in Azure App Service voor meer informatie over faseringsomgevingen in Azure App Service.
• Zie Een Azure Traffic Manager beheren voor meer informatie over Azure Traffic Manager profielen.