Skip to content

Commit 846b810

Browse files
authored
Merge pull request #49804 from CarlRabeler/patch-172
Update sql-database-manage-application-rolling-upgrade.md
2 parents 908dbd0 + ec36161 commit 846b810

File tree

1 file changed

+9
-9
lines changed

1 file changed

+9
-9
lines changed

articles/sql-database/sql-database-manage-application-rolling-upgrade.md

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ manager: craigg
77
ms.service: sql-database
88
ms.custom: business continuity
99
ms.topic: conceptual
10-
ms.date: 04/01/2018
10+
ms.date: 08/23/2018
1111
ms.author: sashan
1212

1313
---
@@ -26,10 +26,10 @@ When evaluating the upgrade options you should consider the following factors:
2626
* Total dollar cost. This includes additional redundancy and incremental costs of the temporary components used by the upgrade process.
2727

2828
## Upgrading applications that rely on database backups for disaster recovery
29-
If your application relies on automatic database backups and uses geo-restore for disaster recovery, it is usually deployed to a single Azure region. In this case the upgrade process involves creating a backup deployment of all application components involved in the upgrade. To minimize the end-user disruption you will leverage Azure Traffic Manager (WATM) with the failover profile. The following diagram illustrates the operational environment prior to the upgrade process. The endpoint <i>contoso-1.azurewebsites.net</i> represents a production slot of the application that needs to be upgraded. To enable the ability to roll back the upgrade, you need create a stage slot with a fully synchronized copy of the application. The following steps are required to prepare the application for the upgrade:
29+
If your application relies on automatic database backups and uses geo-restore for disaster recovery, it is usually deployed to a single Azure region. In this case the upgrade process involves creating a backup deployment of all application components involved in the upgrade. To minimize the end-user disruption you will leverage Azure Traffic Manager (ATM) with the failover profile. The following diagram illustrates the operational environment prior to the upgrade process. The endpoint <i>contoso-1.azurewebsites.net</i> represents a production slot of the application that needs to be upgraded. To enable the ability to roll back the upgrade, you need create a stage slot with a fully synchronized copy of the application. The following steps are required to prepare the application for the upgrade:
3030

3131
1. Create a stage slot for the upgrade. To do that create a secondary database (1) and deploy an identical web site in the same Azure region. Monitor the secondary to see if the seeding process is completed.
32-
2. Create a failover profile in WATM with <i>contoso-1.azurewebsites.net</i> as online endpoint and <i>contoso-2.azurewebsites.net</i> as offline.
32+
2. Create a failover profile in ATM with <i>contoso-1.azurewebsites.net</i> as online endpoint and <i>contoso-2.azurewebsites.net</i> as offline.
3333

3434
> [!NOTE]
3535
> Note the preparation steps will not impact the application in the production slot and it can function in full access mode.
@@ -47,7 +47,7 @@ Once the preparation steps are completed the application is ready for the actual
4747

4848
If the upgrade completed successfully you are now ready to switch the end users to the staged copy the application. It will now become the production slot of the application. This involves a few more steps as illustrated on the following diagram.
4949

50-
1. Switch the online endpoint in the WATM profile to <i>contoso-2.azurewebsites.net</i>, which points to the V2 version of the web site (6). It now becomes the production slot with the V2 application and the end-user traffic is directed to it.
50+
1. Switch the online endpoint in the ATM profile to <i>contoso-2.azurewebsites.net</i>, which points to the V2 version of the web site (6). It now becomes the production slot with the V2 application and the end-user traffic is directed to it.
5151
2. If you no longer need the V1 application components so you can safely remove them (7).
5252

5353
![SQL Database geo-replication configuration. Cloud disaster recovery.](media/sql-database-manage-application-rolling-upgrade/Option1-3.png)
@@ -60,7 +60,7 @@ If the upgrade process is unsuccessful, for example due to an error in the upgra
6060
At this point the application is fully functional and the upgrade steps can be repeated.
6161

6262
> [!NOTE]
63-
> The rollback does not require changes in WATM profile as it already points to <i>contoso-1.azurewebsites.net</i> as the active endpoint.
63+
> The rollback does not require changes in ATM profile as it already points to <i>contoso-1.azurewebsites.net</i> as the active endpoint.
6464
>
6565
>
6666
@@ -74,12 +74,12 @@ If your application leverages geo-replication for business continuity, it is dep
7474
* The application remains protected from catastrophic failures at all times during the upgrade process
7575
* The geo-redundant components of the application are upgraded in parallel with the active components
7676

77-
To achieve these goals you will leverage Azure Traffic Manager (WATM) using the failover profile with one active and three backup endpoints. The following diagram illustrates the operational environment prior to the upgrade process. The web sites <i>contoso-1.azurewebsites.net</i> and <i>contoso-dr.azurewebsites.net</i> represent a production slot of the application with full geographic redundancy. To enable the ability to roll back the upgrade, you need create a stage slot with a fully synchronized copy of the application. Because you need to ensure that the application can quickly recover in case a catastrophic failure occurs during the upgrade process, the stage slot needs to be geo-redundant as well. The following steps are required to prepare the application for the upgrade:
77+
To achieve these goals you will leverage Azure Traffic Manager (ATM) using the failover profile with one active and three backup endpoints. The following diagram illustrates the operational environment prior to the upgrade process. The web sites <i>contoso-1.azurewebsites.net</i> and <i>contoso-dr.azurewebsites.net</i> represent a production slot of the application with full geographic redundancy. To enable the ability to roll back the upgrade, you need create a stage slot with a fully synchronized copy of the application. Because you need to ensure that the application can quickly recover in case a catastrophic failure occurs during the upgrade process, the stage slot needs to be geo-redundant as well. The following steps are required to prepare the application for the upgrade:
7878

7979
1. Create a stage slot for the upgrade. To do that create a secondary database (1) and deploy an identical copy of the web site in the same Azure region. Monitor the secondary to see if the seeding process is completed.
8080
2. Create a geo-redundant secondary database in the stage slot by geo-replicating the secondary database to the backup region (this is called "chained geo-replication"). Monitor the backup secondary to see if the seeding process is completed (3).
8181
3. Create a standby copy of the web site in the backup region and link it to the geo-redundant secondary (4).
82-
4. Add the additional endpoints <i>contoso-2.azurewebsites.net</i> and <i>contoso-3.azurewebsites.net</i> to the failover profile in WATM as offline endpoints (5).
82+
4. Add the additional endpoints <i>contoso-2.azurewebsites.net</i> and <i>contoso-3.azurewebsites.net</i> to the failover profile in ATM as offline endpoints (5).
8383

8484
> [!NOTE]
8585
> Note the preparation steps will not impact the application in the production slot and it can function in full access mode.
@@ -98,7 +98,7 @@ Once the preparation steps are completed, the stage slot is ready for the upgrad
9898

9999
If the upgrade completed successfully you are now ready to switch the end users to the V2 version of the application. The following diagram illustrates the steps involved.
100100

101-
1. Switch the active endpoint in the WATM profile to <i>contoso-2.azurewebsites.net</i>, which now points to the V2 version of the web site (9). It now becomes a production slot with the V2 application and end-user traffic is directed to it.
101+
1. Switch the active endpoint in the ATM profile to <i>contoso-2.azurewebsites.net</i>, which now points to the V2 version of the web site (9). It now becomes a production slot with the V2 application and end-user traffic is directed to it.
102102
2. If you no longer need the V1 application so you can safely remove it (10 and 11).
103103

104104
![SQL Database geo-replication configuration. Cloud disaster recovery.](media/sql-database-manage-application-rolling-upgrade/Option2-3.png)
@@ -111,7 +111,7 @@ If the upgrade process is unsuccessful, for example due to an error in the upgra
111111
At this point the application is fully functional and the upgrade steps can be repeated.
112112

113113
> [!NOTE]
114-
> The rollback does not require changes in WATM profile as it already points to <i>contoso-1.azurewebsites.net</i> as the active endpoint.
114+
> The rollback does not require changes in ATM profile as it already points to <i>contoso-1.azurewebsites.net</i> as the active endpoint.
115115
>
116116
>
117117

0 commit comments

Comments
 (0)