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 grote 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 noodherstel

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

Notitie

Deze voorbereidingsstappen hebben geen invloed op de productieomgeving, die kan functioneren in de modus voor volledige toegang.

Diagram met de configuratie SQL Database geo-replicatie voor herstel na noodherstel in de cloud.

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

Diagram met SQL Database geo-replicatieconfiguratie voor herstel na noodherstel in de cloud, die het upgradescript wordt uitgevoerd.

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

SQL Database geo-replicatieconfiguratie voor herstel na noodherstel in de cloud.

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.

Notitie

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

Diagram met SQL Database geo-replicatieconfiguratie voor herstel na noodherstel in de cloud met de faseringsomgeving buiten gebruik gesteld.

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, profiteert u naast het gebruik van de Web Apps-omgevingen, van Azure Traffic Manager door een failoverprofiel met één actief eindpunt en één back-up-eindpunt te gebruiken. 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 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 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).

Notitie

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

Diagram met SQL Database geo-replicatieconfiguratie voor herstel na noodherstel in de cloud met een volledig gesynchroniseerde kopie van de toepassing.

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 (ALLOW_CONNECTIONS = NO)
  1. 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 gebruikt, maar PowerShell is ook beschikbaar.
-- Disconnect the secondary, terminating geo-replication
ALTER DATABASE <Prod_DB>
REMOVE SECONDARY ON SERVER <Partner-Server>
  1. 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.

Diagram met SQL Database geo-replicatieconfiguratie voor herstel na noodherstel in de cloud met databasewijzigingen gerepliceerd naar 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.

Diagram toont SQL Database geo-replicatieconfiguratie voor herstel na noodherstel in de cloud met optioneel buiten gebruik stellen van de faseringsomgeving.

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.

Notitie

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

Diagram met SQL Database geo-replicatieconfiguratie voor herstel na noodherstel in de cloud met het upgradeproces teruggedraaid.

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 in dollars met zich meebrengt. Het omvat ook een complexere werkstroom.

Samenvatting

De twee upgrademethoden die in het artikel worden beschreven, verschillen in complexiteit en dollarkosten, maar ze zijn beide gericht op het minimaliseren van de duur van alleen-lezenbewerkingen. Deze tijd wordt rechtstreeks gedefinieerd door de duur van het upgradescript. Het 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 bepalen. 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 Groepen voor Azure SQL Database automatische failover gebruiken om transparante en gecoördineerde failover van meerdere databases mogelijk te maken voor meer informatie over het gebruik van groepen voor automatische failover.
  • 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.