Azure for SAP SAPMNT & General Purpose share high-availability solution (SOFS use-case)

by Contributed | Jan 12, 2021 | Technology

This article is contributed. See the original author and article here.

Background: SAP requirement of Highly Available share.

There are several possible solutions to achieve highly available SAPMNT for SAP Instance as listed here. On Azure, SOFS is one of the solutions for consideration, being the Microsoft technology and it works well with SAP Global share. I have not come across a recommendation from SAP for General purpose file share on the cloud, but there is a recommendation from Microsoft Azure when using SOFS share for SAPMNT & general purpose share. The consideration is mainly around the potential performance impact and feature supportability.

In general, there are two types of shares required on SAP Solution.

1. SAP Global share: Starting SAP Kernel 749, SAP has updated the Central service architect to be a more cloud-friendly [ share-nothing model] architect. SAP central services ( message and enqueue processes) are separate from the SAP global host files. SAP Global share hosts the physical location of SAP kernel binaries and is critical for SAP System availability.


2. General Purpose File share: The general file share is used by the SAP systems based on the business requirement and related application usage. It can be an interface directory used by the SAP systems to transfer data between SAP/Non-SAP systems or images/HTTP files used by the SAP portal system or different file formats used by the applications within the solution including non-SAP. It is not a SPOF for SAP system availability but can be critical for SAP business processes based on the application usage. We need to understand the usage of the share in our environment, but in general, these type of shares host multiple smaller files with higher change rate and that result in potential performance overhead because of the large number of changes when used with CA feature enabled.

SOFS & General Purpose share on Azure for SAP:

1. Scale-Out File Share: Active-Active mode, ReFs File system with CSV & CA feature enabled.

• There are the prerequisites to using SOFS for SAP Global share, attached here.


• CA feature must be enabled to ensure a transparent failover functionality is activated, it avoids batch failure due to the (A)SCS failover, SAP Note 1911507


• Multi-SOFS configuration with independent CSV’s for SAP Systems safeguards against single share corruption scenario.


• DFS Namespace can be used for simplicity of //<Logical>/sapmnt/<SID>, it helps with Production and DR use case.

2. General/Generic purpose File Share: Active-Passive mode, CA feature adds overhead resulting in a potential performance issue.

• SOFS is not recommended with workload with a high rate of file operations on the share, official doc here


• With the CA feature, the application will lose around 40% I/O performance. SAP Note 2287140


• A use case of General File share is active-passive to host general files with multiple formats for SAP/Non-SAP Application.


• Blog shares further detail with regards to the SOFS usage.

Considerations for high load scenarios:

1. S2D-SOFS [ReFs_csv] recommended for hosting sapmnt share with CA feature to activate application transparent failover.


2. S2D-FS [ReFs] recommended for general purpose share [ Archive, Interface, Trans, Trex, BOBJ].

Microsoft invests heavily in R&D to bring new features to support SAP On Azure customers, there are options for customers looking for alternatives to S2D technology on Azure.

Technology options on Azure for High-Available SAPMNT Share

@hdamecharla  thank you for providing a summarized view of the highly available SAPMNT options available in Azure

Refer blog for Azure Files – NFS use-case.

Deploy SAP ASCS/ERS with Azure Files NFS v4.1 shares – Microsoft Tech Community

For Azure Shared Disk -SMB use-case.

Azure Shared Disk Support for Clustered SAP ASCS/SCS on Windows Cluster – Microsoft Tech Community

Azure Service Fabric Application upgrade time

by Contributed | Jan 12, 2021 | Technology

This article is contributed. See the original author and article here.

Have you ever wondered why your Service Fabric application upgrade is taking more time or have you observed deploying a new application is faster than doing upgrade to an existing app with the same code package? Then the following details may help with some insights.

When you deploy a new application to a Service Fabric cluster, it’s fast as it doesn’t do rolling upgrade and doesn’t do health checks whereas application upgrade to an existing application goes by UD(Upgrade domain) to UD walk and with health policy checks.  The upgrade time for an app upgrade in service fabric is determined by multiple factors like, app package size, upgrade mode and the upgrade parameters etc. In this article I’m listing few common upgrade parameters here with their default values which play a role in the overall upgrade time.

HealthCheckStableDurationSec: The duration (in seconds) to verify that the application is stable before moving to the next upgrade domain or completing the upgrade. This wait duration is used to prevent undetected changes of health right after the health check is performed. The default value is 120 seconds, and should be customized appropriately for your application.

HealthCheckWaitDurationSec: The time to wait (in seconds) after the upgrade has finished on the upgrade domain before Service Fabric evaluates the health of the application. This duration can also be considered as the time an application should be running before it can be considered healthy. If the health check passes, the upgrade process proceeds to the next upgrade domain. If the health check fails, Service Fabric waits for UpgradeHealthCheckInterval before retrying the health check again until the HealthCheckRetryTimeoutSec is reached. The default and recommended value is 0 seconds.

UpgradeHealthCheckInterval: The frequency of health status checks during a monitored application upgrades. This is service fabric level setting and can be updated with an update to the SF cluster resource update. Please find details here.

To see the above parameters in effect, take an example of a monitored upgrade where the HealthCheckStableDurationSec is set to default 2 mins and you have 5 UDs(Upgrade domain) in your cluster, then 10 mins (2 mins X 5 UDs) spent here during upgrade irrespective of the size of the app package. Similarly, every parameter plays role in your upgrade time and hence choose the parameter values which will be more appropriate for the application. Anytime you believe the application upgrade time takes longer, then inspect these parameters first to understand the expected upgrade time.

You can view values of these common upgrade parameters for an ongoing app upgrade or recently completed app Upgrade in SF explorer as below:

All these health checks and its wait time is applicable if the application upgrade is in a monitored mode.

As monitored application upgrade automates the upgrade and does application health check, the upgrade will include the health check and its wait time whereas in UnmonitoredAuto upgrade mode, the upgrade is automated, but skips the application health check. While with UnmonitoredAuto mode, the upgrade will happen faster, it’s useful for performing fast upgrade iterations during service development or testing and not recommended for production deployment. The Monitored upgrade mode is recommended for all Service Fabric upgrades.

You can pass the upgrade mode while initiating the application upgrade.

For complete list of upgrade parameters for each deployment mode (like for Visual Studio, PowerShell, sfctl),  you can refer here.

With this, I would like to put forward the following key points to keep in mind whenever you’re concerned with app upgrade time in SF cluster:

1. Compress the code package


2. Adjust the upgrade parameters well as per your application for optimum upgrade time


3. If possible, do a diff code package deployment instead of complete application package deployment