Feedback
Did this article resolve your question/issue?

   

Article

How to upgrade a Sitefinity project in load balanced scenario

« Go Back

Information

 
TitleHow to upgrade a Sitefinity project in load balanced scenario
URL NameHow-to-upgrade-a-Sitefinity-project-in-load-balanced-scenario
Article Number000185433
EnvironmentProduct: Sitefinity
Version: 6.x, 7.x, 8.x, 9.x, 10.x, 11.x, 12.x
OS: All supported OS versions
Database: All supported database server versions
Question/Problem Description
How to upgrade a Sitefinity project in load balanced scenario?
Steps to Reproduce
Clarifying Information
Error Message
Defect/Enhancement Number
Cause
When the Sitefinity project runs in a load balanced environment use the below suggestions when upgrading the project and moving it to production.
Resolution

 For Sitefinity 9.2 and above versions:
Prepare for the upgrade following the upgrade documentation - (see link 1 in the notes)

        1. Backup production environment database
        2. Restore the database from step 1 to the test/staging/UAT/other environment. Test the upgrade in this environment.
        3. Deploy a copy of the site source code (in the state before the upgrade, not upgraded source code) to the live environment by adding “ IgnoreDowngradeExceptions=”true” ” parameter to the Sitefinity connection string (by default it is located in App_Data/Sitefinity/Configuration/DataConfig.config). More info on IgnoreDowngradeExceptions can be found in the notes - link 3. Sample:
<add connectionString="data source=.\SQL2014;Integrated Security=SSPI;initial catalog=Database"
name="Sitefinity" IgnoreDowngradeExceptions="true" />
       4. With this step the site runs as in the state before the upgrade prepared for the actual upgrade to occur against the live database.
       5. Upload the upgraded source code and Sitefinity configuration files to a single node of the load balanced environment by first disconnecting this node from the load balancer so it is not served to site visitors (drainstop one node) this action is specific to the environment where the site runs.Having this node with upgraded Sitefinity site files it will upgrade the site database shared by all nodes in the load balancing setup. The rest of the nodes will operate with the upgraded database because of the IgnoreDowngradeExceptions parameter added in step 3 (Note the limitations to the IgnoreDowngradeExceptions parameter which does prevent downgrade exceptions to occur, but Sitefinity functionality that has database model breaking changes will error out until all server node get upgraded).Ensure the IgnoreDowngradeExceptions parameter added in step 3 is set to false in all nodes that already have deployed upgraded source code! Sample:
<add connectionString="data source=.\SQL2014;Integrated Security=SSPI;initial catalog=Database"
name="Sitefinity" IgnoreDowngradeExceptions="false" />
        While the database is in process of being upgraded all other nodes will serve the site and be operational.

       6. Warmup the node, run precompilation and any tooling specific to your site needs to prepare this node to serve visitors. Once this completes attach this node to the load balancer. (See link 4 in the notes)
       7. Repeat the process from step 4 to the rest of the nodes until they are all upgraded.

User-added image
FAQ:

Q1: Why is a backup of the live site database taken at step 1 and then used in dev/staging/test environments to test the upgrade?
A: It is a good practice to always test against live data to avoid unexpected problems

Q2: Why in step 3 the whole site source code is deployed with a single update that adds IgnoreDowngradeExceptions parameter to the connection string?
A: This is following the good practice for doing deployment, deploy the whole code instead of small chunks of changes here and there which makes it hard/impossible to track and version the deployed data for the deployment.
Q3: Why is the upgrade executed node by node and not by drain stopping three nodes and upgrading them to save time?
A: Following the best practices to keep the site performance at the best it can be executing the upgrade at a node by node basis. Taking more than one node at a time will take away more of the resources that the site has and may cause slowdowns for site visitors depending on the load.
Q4: Why the upgraded site needs to be warmed up?
A: There are many benefits to warmup and the most important one for Sitefinity is that the cache for pages is saved in the memory of the server that runs the site. There is no distributed cache shared by all servers, each server needs to build cache for the most commonly visited site pages.
Refer to this KB article for additional info on utilizing Sitefinity precompilation tool - Link 4 in the notes.

For Sitefinity versions lower that Sitefinity 9.2
There approaches described here are not the only approaches available, use an approach that will match the requirements for the site and any acceptable downtime.

Approach 1:

       1. Download a copy of the project files and database from the production environment and upgrade it following the steps in Sitefinity upgrade documentation (See link 1 in the notes)
       2. Configure the load balancer to use only to one of the nodes, the site will run on one node at this time.
       3. On the detached one upload a copy of the upgraded project files and restore the upgraded database in SQL Server.
       4. As a result, the detached node will be running on the upgraded project.
       5. After this is done, switch the traffic to this node only so that the second node can be detached.
       6. Then upload a copy of the upgraded project to the second node and configure it to point to the upgraded database.

After this enable the traffic on both nodes. Both will be running the upgraded project and database.

Limitation: There is a data loss at the time between taking database backup to upgrade the site. To limit the data loss take a backup right after the upgraded Sitefinity project files have been uploaded to one of the nodes and the upgrade process has been tested in a test environment to execute without issues.

Approach 2:

Taking the same steps from Approach 1 but adopting SQL Server replication (SEE LINK 2 in the notes) in order to merge the data from the live DB over the upgraded DB.

Workaround
Notes
Link 1 Sitefinity Documentation, Upgrade Procedure
https://www.progress.com/documentation/sitefinity-cms/upgrade

Link 2 Microsoft Documentation, SQL Server Replication
https://docs.microsoft.com/en-us/sql/relational-databases/replication/sql-server-replication

Link 3 Sitefinity Documentation, Upgrades and database,
https://www.progress.com/documentation/sitefinity-cms/upgrades-and-database

Link 4: 000078830, How to use Sitefinity page precompiler for sites deployed in load balanced setup

The same steps do apply for the setup where the site runs in Azure environment with deployment slots. A site can serve the frontend traffic with one slot while the other slots are upgraded and connected to the upgraded database.
Last Modified Date5/12/2020 2:00 PM
Attachment 
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.