Managed Cloud Standard Guidance On Azure Platform Updates


Description

Note: These suggestions are not supported by Sitecore through a formal SLA. The scope of Managed Cloud official support is defined by the Service Catalog (Sitecore Managed Cloud Standard – service catalog on-demand requests) and the Monitoring process (Sitecore Managed Cloud Standard – monitoring metrics). What is included in this article are suggestions independent of Sitecore official support that can address areas where Microsoft Azure features might be tuned to suit certain Sitecore scenarios.

Sitecore Managed Cloud Standard is built on top of the Microsoft Azure platform, which means Azure App Services is a fundamental building block for most solutions. There are periodic updates made by Microsoft to the underlying Azure platform for App Services to improve the overall reliability, performance, and security of the platform infrastructure. Microsoft does not offer advanced notice or scheduled windows for these updates – it is part of the management process in Azure App Services and the PaaS (Platform as a Service) model. Most of these updates are performed without any impact on web applications. Occasionally, these updates do cause a restart of the Azure App Service, which means Sitecore must complete re-initialization on that App Service and a period of unavailability might take place. The underlying platform SLA for Azure App Services is 99.95%, and the platform updates described in this article generally do not violate the SLA.
Note: The Sitecore application run on top of the App Service might experience a slightly longer interruption in availability due to Sitecore’s application start-up routine.

Based on our experience of working with many Managed Cloud Standard projects, we can share some of the best practices other projects have found to be successful in addressing the availability concerns of these Azure platform updates.

Solution

Restart More Quickly The suggestions to complete restarts more quickly include 3 specific measures:

  1. Application Initialization
  2. Azure App Service "Local cache"
  3. Dynamic Cache

Application Initialization

Application Initialization is an IIS feature available in Azure App Services; it is not a feature intrinsic to Sitecore. Some Managed Cloud implementations use the feature to warm up an App Service in Azure before first use. This feature can be useful during automatic scale-outs because new instances are properly warmed-up before receiving traffic. You can add an AppInitialization section to the web.config that points to the warmup page(s) and related properties:

<system.webServer>
   <applicationInitialization doAppInitAfterRestart="true">
       <add initializationPage="/default.aspx" hostName="myhost"/>
    </applicationInitialization>
</system.webServer>

See Application Initialization or Application Initialization to warm up specific pages for more about this. Sitecore App Service Warm-Up Demystified is also a helpful link with suggestions specific to Sitecore.

Azure App Service "Local cache"

The Local Cache feature (Azure App Service Local Cache overview) is a Microsoft Azure App Service feature, not a Sitecore feature. However, some Sitecore Managed Cloud implementations use Local Cache to improve the speed of Sitecore restarting. In cases where the Microsoft Azure platform performs an update that triggers a transient interruption to the Azure App Service, Local Cache can reduce the duration of any related downtime. The feature makes the files for implementation available on the local Azure App Service host, so instead of copying the implementation files from a central location after a service restart down to the host powering the App Service (which can take time), the files in Local Cache are immediately available.

The local cache size is limited to 300 MB by default, but you can increase it up to 2 GB – so see the documentation for this in the link given previously. If the copied files exceed the size of the local cache, App Service silently ignores the local cache and reads from the remote file share. Therefore, reducing the quantity and size of files on disk for the Sitecore implementation can be a part of this solution.

If you have a lot of files with your solution and are up against the 2 GB ceiling, we suggest you consider these standard steps:


Dynamic Cache

Dynamic Cache is like Local Cache, but instead of caching your entire site on the App Service host, only the files that are requested get cached. This is a feature provided by the Azure App Service product and not provided by Sitecore. The reason the files get cached in the first place is that your App Service application files are stored in a single location that supports the ability to scale to multiple instances while having them all pointing to the same content.

This is achieved by making the d:\home directory a symlink to a file server, d:\local is truly on the instance and this is where the cache is stored.  Some Azure App Services show latency when requesting site content from the remote file share, most do not.

We suggest following Solution 1 from Sitecore XP stability issues when using Azure Web Apps to set WEBSITE_DYNAMIC_CACHE to "0" to disable this feature.