Manage rolling upgrades of cloud applications
In this we will learn about offline or online strategies and how to use active geo-replication in Azure SQL Database to enable rolling upgrades of your cloud application. Because upgrades are disruptive operations, they should be part of your business-continuity planning and design. However, when evaluating upgrade options, consider these factors:
- Firstly, impact on application availability during upgrades, such as how long application functions might be limited or degraded.
- Secondly, ability to roll back if the upgrade fails.
- Thirdly, vulnerability of the application if an unrelated, catastrophic failure occurs during the upgrade.
- Lastly, total dollar cost. This factor includes additional database redundancy and incremental costs of the temporary components used by the upgrade process.
Upgrade applications that rely on database backups for disaster recovery
If your application relies on automatic database backups and uses geo-restore for disaster recovery, it’s deployed to a single Azure region. In order to minimize user disruption, create a staging environment in that region with all the application components involved in the upgrade. However, the first diagram illustrates the operational environment before the upgrade process. The endpoint contoso.azurewebsites.net represents a production environment of the web app. To be able to roll back the upgrade, you must create a staging environment with a fully synchronized copy of the database. Follow these steps to create a staging environment for the upgrade:
- Firstly, create a secondary database in the same Azure region. Monitor the secondary to see if the seeding process is complete (1).
- Secondly, create a new environment for your web app and call it ‘Staging’. It will be registered in Azure DNS with the URL contoso-staging.azurewebsites.net (2).
Further, when the preparation steps are complete, the application is ready for the actual upgrade. The next diagram illustrates the steps involved in the upgrade process:
- Firstly, set the primary database to read-only mode (3). This mode guarantees that the production environment of the web app (V1) remains read-only during the upgrade, thus preventing data divergence between the V1 and V2 database instances.
- Secondly, disconnect the secondary database by using the planned termination mode (4). This action creates a fully synchronized, independent copy of the primary database. This database will be upgraded.
- Lastly, turn the secondary database to read-write mode and run the upgrade script (5).
However, if the upgrade finishes successfully, you’re now ready to switch users to the upgraded copy the application, which becomes a production environment. Switching involves a few more steps, as illustrated in the next diagram:
- Firstly, activate a swap operation between production and staging environments of the web app (6). This operation switches the URLs of the two environments. Now contoso.azurewebsites.net points to the V2 version of the web site and the database (production environment).
- Next, if you no longer need the V1 version, which became a staging copy after the swap, you can decommission the staging environment (7).
Upgrade applications that rely on database geo-replication for disaster recovery
If your application uses active geo-replication or auto-failover groups for business continuity, it’s deployed to at least two different regions. However, there’s an active, primary database in a primary region and a read-only, secondary database in a backup region. Along with the factors mentioned at the beginning of this article, the upgrade process must also guarantee that:
- Firstly, the application remains protected from catastrophic failures at all times during the upgrade process.
- Secondly, the geo-redundant components of the application are upgraded in parallel with the active components.
Further, to achieve these goals, in addition to using the Web Apps environments, you’ll take advantage of Azure Traffic Manager by using a failover profile with one active endpoint and one backup endpoint. The web sites contoso-1.azurewebsites.net and contoso-dr.azurewebsites.net represent a production environment of the application with full geographic redundancy.
The production environment includes the following components:
- Firstly, the production environment of the web app contoso-1.azurewebsites.net in the primary region (1)
- Secondly, the primary database in the primary region (2)
- Thirdly, a standby instance of the web app in the backup region (3)
- Next, the geo-replicated secondary database in the backup region (4)
- Lastly, a Traffic Manager performance profile with an online endpoint called contoso-1.azurewebsites.net and an offline endpoint called contoso-dr.azurewebsites.net
The following steps are required to create a staging environment for the upgrade:
- Firstly, deploy a staging environment of the web app in the primary region (6).
- Secondly, create a secondary database in the primary Azure region (7). Configure the staging environment of the web app to connect to it.
- Thirdly, create another geo-redundant, secondary database in the backup region by replicating the secondary database in the primary region. (This method is called chained geo-replication.) (8).
- Lastly, deploy a staging environment of the web app instance in the backup region (9) and configure it to connect the geo-redundant secondary database created at (8).
When the preparation steps are complete, the staging environment is ready for the upgrade.
- Firstly, set the primary database in the production environment to read-only mode (10). This mode guarantees that the production database (V1) won’t change during the upgrade, thus preventing the data divergence between the V1 and V2 database instances.
SQL
— Set the production database to read-only mode
ALTER DATABASE
SET (ALLOW_CONNECTIONS = NO)
- Secondly, terminate geo-replication by disconnecting the secondary (11). This action creates an independent but fully synchronized copy of the production database. This database will be upgraded. The following example uses Transact-SQL but PowerShell is also available.
SQL
— Disconnect the secondary, terminating geo-replication
ALTER DATABASE
REMOVE SECONDARY ON SERVER
- Lastly, run the upgrade script against contoso-1-staging.azurewebsites.net, contoso-dr-staging.azurewebsites.net, and the staging primary database (12).
However, if the upgrade finishes successfully, you’re now ready to switch users to the V2 version of the application.
- Firstly, activate a swap operation between production and staging environments of the web app in the primary region (13) and in the backup region (14). V2 of the application now becomes a production environment, with a redundant copy in the backup region.
- Secondly, if you no longer need the V1 application (15 and 16), you can decommission the staging environment.
Or if the upgrade process is unsuccessful (for example, due to an error in the upgrade script), consider the staging environment to be in an inconsistent state. To roll back the application to the pre-upgrade state, revert to using V1 of the application in the production environment.
- Firstly, set the primary database copy in the production environment to read-write mode (17). This action restores full V1 functionality in the production environment.
- Then, perform the root-cause analysis and repair or remove the staging environment (18 and 19).
Reference: Microsoft Documentation