Availability

Overview

Sitefinity Cloud has been designed to ensure the best uptime, performance and scalability of your website. Utilizing various Microsoft Azure services and mechanisms like Load balancing, Autoscaling, Geo replication and Failover clusters, Sitefinity Cloud intelligently distributes your website visitors load to the available web server nodes, hosting your website and scales resources up or down depending on the current load. Moreover, utilization of failover clusters and geo-replication guarantees that failed deployments to the production environment can be safely reverted without affecting the live website performance.

Load balancing and Autoscaling

Thanks to the utilization of Load Balancing and autoscaling mechanisms, Sitefinity Cloud ensures that your websites can handle up to 1200 page views per second. 

All Sitefintiy Cloud instances have Multisite management enabled, letting you manage up to 1000 websites from your Sitefinity Cloud instance.

Deployment failure protection

The following steps describe the stages that your Sitefinity Cloud instance goes through during the deployment process. It also visualizes the mechanisms that ensure continuous operation of the website, in case of a failed deployment. 

In its initial state, a Sitefinity Cloud production instance is configured with a Production slot, Deployment slot, and a Failover slot. Users browse the website from the Production slot, while the Deployment slot is open to receive any deployment packages, promoted from the Staging environment via the Sitefintiy Cloud continuous delivery (CD) pipeline. Both the Production and Deployment slots are connected to a Primary database.

To ensure failover protection in case a deployment goes wrong, a Failover slot is designated for each instance. 
The following diagram demonstrates the initial state of a Production instance:

S1

When you start deployment to Production, the CD pipeline is engaged. Under the hood, the Production database (Primary DB) is cloned. The Deployment slot is configured to use the new database (Secondary DB).

Step1

As a next step, the actual deployment is executed. The Deployment slot accepts the new package and is now running the latest version of the website code. The Production slot to continues operating with the Primary database

Step2

Once the new package has been successfully deployed to the Deployment slot, page precompilation is triggered. This ensures that Sitefinity pages will render much quicker when the Deployment slot starts serving requests. The Deployment slot is connected to the database replica to ensure that there is no performance impact to the Production slot.

Step3

After page precompilation is executed, a check is done to see whether there are any database schema changes that are applied with the new package. Database schema changes are usually part of Sitefinity upgrades, or when dynamic modules or custom fields are created and deployed using Export for deployment. After it is clear whether the new package carries database schema changes, the Secondary database is removed.

Step4

No Database schema changes

In the case where there are no database schema changes, the deployment process is simpler, because there is no danger for the database to get corrupted after the deployment.

The next step is to connect the Deployment slot to the Primary database.

Step5

At this point in the process, Sitefinity Cloud enables you to plug automated logic to verify whether the application is healthy and can serve customer requests. In case of successful deployment, the Deployment slot and Production slot are swapped. The swap operation ensures that there is no downtime during deployment.

Step6

After the swap operation is complete, the new package is deployed on the Failover slot. This ensures that the failover slot has the same code version as the Production slot and will be available for failover on the next deployment.

Step7

Finally, a successful deployment process ends with a setup identical to the initial state. The difference is that the Production and Failover slots are running the newly deployed website code, and the Primary database is upgraded accordingly. The Deployment slot contains the old copy of the website code, which will be replaced during the next deployment.

Step8

Database schema changes

In the case where there are database schema changes, the deployment process ensures that there is a Rollback option in case the new website has issues. If there is a rollback to the previous version of the website, there also needs to be a previous version of the database that has not been affected by the schema changes.

The next step is to create a Secondary database which is a replica of the Production database and configure the Failover slot to use it. This way, there is an option to switch to the Failover slot, in case something goes wrong.

Step5-1

The next step is to connect the Deployment slot to the Primary database.

Step6-1

At this point in the process, Sitefinity Cloud enables you to plug automated logic to verify whether the application is healthy and can serve customer requests. In case of successful deployment, the Deployment slot and Production slot are swapped. The swap operation ensures that there is no downtime during deployment.

Step7-1

Successful deployment

After the swap operation is complete, the new package is deployed on the Failover slot. This ensures that the failover slot has the same code version as the Production slot and will be available for failover on the next deployment.

Step8-1

Once the new version is deployed on the Failover slot, the Secondary database is removed.

Step9-1

Finally, a successful deployment process ends with a setup identical to the initial instance state. The difference is that the Production and Failover slots are running the newly deployed website code, and the Primary database is upgraded accordingly. The Deployment slot contains the old copy of the website code, which will be replaced during the next deployment.

StepF

Failed deployment

If Sitefinity Cloud detects that the application health is affected, for example the website cannot start after the deployment of the new package, a rollback procedure is initiated.

First, Production and Failover slots are swapped. The Failover slot contains the last healthy version of the website code and is connected to the Secondary database, which holds the original, pre-deployment version of the website database. This way, website traffic is not affected by the failed deployment. Data integrity and uptime are guaranteed. The next steps will ensure the setup is returned in a state that enables future deployments.

StepR

Next, the ex-Production slot, which runs the non-healthy copy of the website code, and after the swap in the previous step is now designated as a Failover slot, is removed. A new Failover slot is created from the now healthy Production slot. The Deployment slot and the new Failover slot are disconnected from the Primary database, that has been affected by the non-healthy application code.

Step9-2

The affected (broken) Primary database is removed from the setup. It is preserved for root cause analysis, but is no longer part of the production instance setup. The Secondary database becomes the Primary database.

Step10

This is also the final step of the rollback process. It leaves the application in a final state that is identical to the initial state and allows for future deployments to be executed. 

StepF-1

Was this article helpful?

Next article

Performance