Description

Sitecore Managed Cloud Standard is a combination of technologies and services on top of the Microsoft Azure platform. There are a wide variety of optimizations available, and Managed Cloud Standard is a fundamentally open product where customers adapt the starting topologies (Sitecore Managed Cloud Standard – topologies and tiers for Sitecore) to suit their implementation patterns. Based on our experience of working with many Managed Cloud Standard projects, Sitecore would like to share some of the best practices other projects have found to be successful. These suggestions are not supported by Sitecore through a formal SLA. The scope of Managed Cloud official support is defined by Sitecore Managed Cloud Standard – service catalog on-demand requests and 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.

The suggestions cover 6 specific components:

1. SQL Database
   
   • Regular Azure SQL database health routine
   • Backup (see Azure SQL Database Backup Schedule Request Form)
2. App Service
   
   • Enable Azure "local cache" feature
   • Enable Asp.Net "Application Initialization" feature
   • Disable Azure Proactive Auto-heal
   • Disable "fcnMode" for ASP.Net
   • Disable Dynamic Cache
   • Sitecore application "security hardening" (see Security guide)
   • Sitecore application cache tuning (see Recommended initial cache values)
   • Backup (see Azure App service Backup Schedule request Form)
3. App Service Plan
   
   • Out of the Box topologies are a starting point
   • Microsoft can update without notice
   • Azure App Service Plan consideration – P2V3 vs S3
   • Using the Basic App Service plan is not recommended
4. Application Insight
   
   • Application Insight as a logging mechanism
   • Application Insights "Daily Cap" on data storage
5. Azure Networking
   
   • Consider IP restrictions for CM, and note Application Insights IP ranges for ping checks
   • Set up a Web Application Firewall (WAF) before go-live
6. Resource Group
   
   • "Tags" can identify Azure resources

Solution

Apply the following settings:

• Regular Azure SQL database health routine
  For conventional Microsoft SQL Server in IaaS, a routine Maintenance Plan can be a vital way of completing routine updates and optimizations to databases. For more details, refer to Maintenance Plans. For Azure SQL, there is no feature like the Maintenance Plan. You must take special steps to do the recurring index defragmentation and internal reorganization with Azure SQL. The Sitecore Managed Cloud team has a standard solution for this that is built on Azure Automation, it is a part of the Service Catalog corresponding ServiceNow service request is called "Set up SQL Maintenance Plan".
• Enable Azure "local cache" feature
  The Local Cache feature is a Microsoft Azure App Service feature, not a Sitecore one. 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 the central location after the 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 note the documentation for this in the link given previously. If the copied files exceed the size of the local cache, App Service silently ignores local cache and reads from the remote file share. Therefore, reducing the quantity and size of files on the 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:
  1. Disable writing screenshots and scripts by Content Testing if this feature is not used in your project. For this purpose, you can change the value of the ContentTesting.GenerateScreenshots setting to none.
  2. You can also enable the ContentTesting.PhantomJS.RemoveAbandonedJS setting to ensure that the old script files are removed in a timely way.
  3. Disable Application Logging to the file system as described in Enable diagnostics logging for apps in Azure App Service.
  4. Decrease expiration time for the files stored in the temp folder and App_Data folder. For this purpose you can modify the maxAge value of all folders under the node <agent type="Sitecore.Tasks.CleanupAgent" method="Run" interval="06:00:00"> in your configuration.
  5. Disable Azure fallback appender. The easiest way to do this is to open the \App_Config\Sitecore\ExperienceContentManagement.Administration
     \Sitecore.ExperienceContentManagement.Administration.config file and remove the "logDisabled4net" node.
• Enable Asp.Net "Application Initialization" feature

  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 <applicationInitialization> feature to warm up an App Service in Azure before the first use. This feature can be useful during automatic scale-outs as 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 for more on it. Sitecore App Service Warm-Up Demystified is also a helpful link with suggestions specific to Sitecore.

• Disable Azure Proactive Auto-heal

  Azure App Services have a feature called Proactive Auto-heal. This is designed to proactively restart a system when the Azure runtime determines the system is too busy or unhealthy. When an App Service runs above 90% memory for 30 seconds, the Azure runtime intervenes and restarts it. Sometimes this is desirable for Azure App Services, but for some Sitecore implementations that run close to capacity (high memory usage), disabling the Proactive Auto-heal feature in Azure can improve site availability and allow heavy workloads to run without interruption.
  To disable the Proactive Auto-heal feature:

  1. Navigate to the Azure App Service Diagnose and Solve problems section.
  2. Select the AutoHeal options under Diagnostic Tools.
  3. On the Proactive Auto_Heal tab, click off:
  
• Disable "fcnMode" for ASP.Net

  When FcnMode feature is enabled, it restarts the Web App when certain files are changed (.dll, .config). In certain cases, unexpected App Pool restarts might be attributed to this feature being enabled. For example, some challenges have been observed when application logic creates rapid file modifications or there is a directory structure with many subdirectories that each requires separate FcnMode monitoring. Implementations may choose to disable the FcnMode as a precaution. This is a tuning suggestion from https://doc.sitecore.com/xp/en/developers/100/managed-cloud/recommendations--sitecore-tuning-in-azure.html

  You can raise a support request to better understand the issue that you are currently facing to better gauge the need to disable this feature.

• Disable Dynamic Cache

  Dynamic Cache is like Local Cache. However, 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 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 you follow "Solution 1" from Sitecore XP stability issues when using Azure Web Apps to set "WEBSITE_DYNAMIC_CACHE" to "0" to disable this feature.

• Azure App Service Plan consideration

  Customers scaling their Managed Cloud environment might compare the Azure tier for "S3" vs "P2v2". At the time of writing, the pricing from Microsoft Azure is the same for these two tiers but the performance of the P2v2 tier is generally better, except for when you need the 4 cores provided by S3 over the 2 cores provided by P2v2. Different applications will have different requirements, so each project should test to determine for themselves, but it’s common for Managed Cloud customers to choose the P2v2 over the S3 as the Premium v2 series supports higher specification components for the same cost and that often means better Sitecore performance.

• Storing application logging in Azure Blob storage

  Note that The Application Logging (Blob) setting in the Azure App Service explains how storing Sitecore application logging in Azure Blob Storage is not recommended for Sitecore Managed Cloud instances due to the impact on performance. Using Azure Application Insights is the recommended method of collecting and storing this data.

• Application Insights "Daily Cap" on data storage
  

  Sitecore Managed Cloud deployments use Azure Application Insights to collect application diagnostics and related telemetry. Since you pay for any data collected in Application Insights, a limit is defined on how much data to store each day; the default limit, known as the "Daily Cap", is 0.33 GB/day for most customer scenarios. Production applications often generate more diagnostic data than 0.33 GB/day, so to avoid losing that valuable data we suggest customers increase the Daily Cap to a value suitable for their specific implementation. Exact values depend on many details but Managed Cloud implementations often settle on a value between 5 GB - 10 GB for the Daily Cap. Note that storing additional data increases the Azure cost to the project.

• IP Restrictions
  

  You can control access to Azure App Services, the main component of Sitecore Managed Cloud environments, by defining specific IPs that can access the endpoints. This is done in the "Networking" settings of the Azure App Service; Microsoft’s documentation on this is at Azure App Service access restrictions. Note that if a Managed Cloud customer only grants specific IPs access to their resources, it can prevent Azure Application Insights from testing the health of the endpoints. Application Insights health checks are one key method the Sitecore Managed Cloud team has of monitoring system availability, and if these checks cannot connect, the Managed Cloud support SLAs will be impacted. See Sitecore Managed Cloud Standard — monitoring metrics for all the monitoring metrics.

  According to the Managed Cloud scope of service (Sitecore Managed Cloud Standard – service aspects and embedded operations), it is the client's responsibility to ensure the availability of the application to monitoring services. The IP addresses used by Application Insights monitoring are found in the Availability tests section of IP addresses used by Application Insights and Log Analytics; the locations used by Sitecore Managed Cloud are Australia East, North Europe, Southeast Asia, West US, and North Central US. If a customer needs help with these IP restrictions, they must work through their Customer Success Manager or the Support Portal (see How to use the Sitecore Support Portal).

• Setup a Web Application Firewall (WAF) before go-live
  

  The Sitecore Managed Cloud team will set up and integrate a WAF for customer environments; this is part of our service catalog Sitecore Managed Cloud Standard – service catalog. Experience shows us due to delays in DNS propagation or other networking complications, it is best to complete the WAF implementation in advance of going live with the Sitecore Managed Cloud environment. Projects must allow plenty of time to test and deliberately evaluate all the connectivity changes after the WAF has been deployed, so we suggest you incorporate this early in the life cycle of the project.

• "Tags" can identify Azure resources
  

  Microsoft Azure supports "Tags" as a way of identifying resources. Microsoft’s documentation on tags is Use tags to organize your Azure resources and management hierarchy. We suggest Managed Cloud customers consider tagging their Azure Resource Groups to help communicate metadata on the environment. The following example shows how Tags appear in the Azure Portal: