Today I am going to help you in different aspect of scaled environment in Azure where I will explain what is ARR in scaled Sitecore Azure instances. So without delaying we will start this with below pointer which will explain all the things related to this.
What is ARR Affinity?
Application Request Routing (ARR) is a feature where when a client (or browser) request to any Azure based website, a cookie will be created and stick to the first time request received web site instance.
The same cookie will be used for subsequent requests from this client or browser and these requests will be guided to the same web site instance the one which was served for the first time.
With this feature, we can get an advantage if in case the web site instance is maintaining lots of data in it’s memory and moving the subsequent requests to other instance leads to copy entire data to other instance and this is a more performance and pain to the system.
We can see many disadvantages when compared with advantages. If a client request and unfortunately the sticky instance is not available, this request cannot be guided to any other available instance instead it will send an unavailable message to the client.
Also, In case if an instance is a too much load with other request and this request will be in request queue instead can guide to other instance to balance the load.
How ARR Affinity works?
- Client connects to an Azure Web Sites website
- ARR runs on the front-end Azure server and receives the request
- ARR decides to which of the available instances the request should go
- ARR forwards the request to the selected server, crafts and attaches an ARRAffinity cookie to the request
- The response comes back to the client, holding the ARRAffinity cookie.
- When the client receives the request, it stores the cookie for later use (browsers are designed to do this for cookies they receive from servers)
- When the client submits a subsequent request, it includes the cookie in it
- When ARR receives the request, it sees the cookie, and decodes it.
- The decoded cookie holds the name of the instance that was used earlier, and so ARR forwards the request to the same instance, rather than choosing one from the pool
- The same thing (steps 7-9) repeat upon every subsequent request for the same site, until the user closes the browser, at which point the cookie is cleared
This is how the affinity cookie looks:
Disabling the affinity can be done in different ways: (Every one prefer that last way explained)
- In your application
To control this behavior in an application, you need to write code to send out a special HTTP header, which will tell the Application Request Router to remove the affinity cookie. This header is Arr-Disable-Session-Affinity, and if you set it to true, ARR will strip out the cookie. For example, you could add a line similar to this to your applications’ code:
- In a site configuration
If you prefer to have it completely disabled, you could have ARR remove the cookie always by having IIS itself inject that header directly. This is done with a customHeaders configuration section in web.config. Simply add the following into your web.config, and upload it to the root of the site:
There is one more way yo disable this is which require us to follow below steps.
- Go to Azure App service.
- Then go to Configuration.
- In configurations you will find General settings tab click on it.
- Here in this tab you will find the Sections called Platform settings.
- In this sections you will find the ARR affinity radio button.
- As per requirement you can disable it.(by default this is on)
To test this you need to go into HTTP header and check the value is coming or not. Another simple way is once you disabled it you can clear your browser cookies and load the website again and check in cookies sections and you will find that ARR cookie is not created.
As a part of Sitecore Managed Cloud series this one is last article about adding New or Existing domain to SMC app services.
So let’s start directly on article which tells us, how you can migrate the New/existing domain to your SMC Azure App Service as Custom domain.
Enable the CNAME record mapping in Azure
In the left navigation of the app page in the Azure portal, select Custom domains.
In the Custom domains page of the app, add the fully qualified custom DNS name (
www.contoso.com) to the list.
Select the + icon next to Add custom domain.
Type the fully qualified domain name that you added a CNAME record for, such as
The Add custom domain page is shown.
Make sure that Hostname record type is set to CNAME (www.example.com or any subdomain).
Select Add custom domain.
It might take some time for the new custom domain to be reflected in the app’s Custom domains page. Try refreshing the browser to update the data.
After you added custom domain don’t forget to add this domain entry in to sites configurations in SiteDefinition.config or Sitecore.config files.
Today I will explain DR or considering High Availability options in Sitecore Managed Cloud. So without doing any delay, we are going to touch straight to the point and start with a process for recovering your data in the event of an outage, incorporating:
- Backup technology
- Your secondary environment
- The steps of the recovery process
- The recovery point objective (RPO)
- The recovery time objective (RTO)
Sitecore Managed Cloud offers three different disaster recovery options that differ slightly in cost and specifications, depending on your requirements. The recovery options available are:
- HADR Basic
- HADR Hot-warm
- HADR Hot-hot
Before we go into an explanation of the above three option, I want to explain basic terminologies in the Sitecore high availability disaster recovery (HADR):
- High availability (HA) – A system that aims to ensure an agreed level of operational performance. Usually, the uptime is higher than for the normal period, where the system can failover by itself.
- Disaster recovery (DR) – An area of business continuity planning that aims to protect an organization from the effects of significant negative events. Disaster recovery allows an organization to maintain or quickly resume mission-critical functions following a disaster that requires manual intervention.
Now I will explain all three options mentioned above, on a high level one by one as below.
With HADR basic, the Sitecore Managed Cloud disaster recovery service sets a process into action in the event of an outage. The steps of this process include:
- Scheduling a reoccurring backup, that occurs every 3 hours, of the following assets into the secondary database of the recovery point objective (RPO):
- The databases.
- Web applications.
- The connection strings, (for the credentials).
- The sizes/tiers of the resources.
- Arranging an outage page for customers to see while your site is down.
- Setting the traffic manager to switch between the primary Content Delivery (CD) server and the outage page.
- Setting up email alerts to notify the Managed Cloud Operations team if the availability tests fail.
If you are using the HADR hot-warm option, in the event of an outage the Sitecore Managed Cloud disaster recovery service sets the following process into action:
- Deploy a new Sitecore environment in the secondary data center and shut down your web applications.
- Use active geo-replication to sync the data between the primary and secondary Azure SQL.
- Sync the sizes/tiers of all your Azure resources.
- Sync the file contents of all of your web applications.
- Set up an outage page to ensure your customers are aware that your site is temporarily down.
- Set up a traffic manager to switch between the primary Content Delivery (CD) server and the outage page.
- Set up email alerts to notify the Managed Cloud Operations team whenever an availability test fails.
In the event of an outage, with the HADR hot-hot option, you must set into motion a recovery a process that is similar to the following:
- Enable recovery during a disaster by setting up the necessary environment before the disaster happens.
- Initiate the backup and replication process so that the Sitecore deployment and data are available for a healthy recovery.
- Deploy a passive Sitecore solution into the secondary region.
- Set up and enable the traffic manager to be the public gateway.
To set up your disaster recovery process:
- Ensure you are running your Sitecore solution (9.1 or later), on Azure.
- Install PowerShell with an Azure SDK, version 6.0.0 or later.
- Run your setup script and use the relevant modules.
- Use PowerShell (AzureRM), to log in to Azure and select the relevant subscription.
- Have your Sitecore license file ready.
- Have any scripts that you want to develop for your HADR hot-hot scenario ready.
- Use the Sitecore Azure Toolkit.
- Sitecore supports the following topologies: XM and XP, and the following deployment sizes: Extra Small, Small, Medium, Large, Extra Large.
- You can also use Simple Azure PaaS DR management to create DR of your SMC instances.
Happy Learning !!!!