Managed Cloud Standard Best Practice Suggestions

  • 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
    2. App Service
    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
    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
    • 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 not a 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 built on Azure Automation, but it is not officially part of the Service Catalog at the time of writing this article. It is suggested for Sitecore Managed Cloud implementations interested in this solution to work through their Customer Success Manager to coordinate the timing and other details of this Azure SQL tuning work.

    • 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
         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:

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

      See Application Initialization or 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

      Managed Cloud Standard deployments make use of Azure App Services as the webserver component. HTTP requests are handled through the App Service engine, which supports ASP.NetASP.Net.

      Depending on the version of ASP.Net a customer is using, they might find explicitly setting the "fcnMode" in the definition in web.config can provide better performance. FcnMode is an ASP.Net feature, not a Sitecore one.
      The documentation on FcnMode establishes the default behavior is the one where every directory in the solution is independently monitored for changes. If the implementation includes a lot of directories, there is overhead in tracking all those separate locations. In some cases where a Sitecore implementation does a lot of file manipulation, this overhead can increase and, in extreme cases, cause Sitecore to restart and record a diagnostic message such as:
      Shutdown message: IIS configuration change
      HostingEnvironment initiated shutdown
      Change Notification for critical directories.

      If customers notice this activity during testing, it might be necessary to correct a pattern of file system updates that is causing too much strain on the App Service. If addressing the root cause of the file changes is not feasible, it might be useful to add the flag fcnMode = "Disabled" to the httpRuntime definition in web.config. This stops the monitoring of the file system for changes but must be used with care because it might mask a more significant problem with the implementation use of files. For more about fcnMode, please see File Change Notification.

    • 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 33 GB/day for most customer scenarios. Production applications often generate more diagnostic data than 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:

Applies to:

Managed Cloud 1+

September 16, 2020
September 16, 2020


  • Managed Cloud