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:
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:
<add initializationPage="/default.aspx" hostName="myhost"/>
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:
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/developers/managed-cloud/en/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.
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.
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.
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.
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.
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).
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.
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: