The Azure platform gives you the ability to scale SAP applications on-demand as required. In broad terms scaling can be achieved in 2 ways:
In this blog we will look at an approach to achieve Auto Scaling of SAP application servers in Azure based on Horizontal scaling method.
Autoscaling strategy typically involves the following pieces:
For detailed guidance on best practices of autoscaling in general refer this document
Azure monitor provides out of the box capability to capture key performance metrics of a VM which are then stored in a Log Analytics Workspace. However, to accurately measure the load on an SAP application server, SAP specific performance metrics like work process utilization, user sessions, SAP application memory usage etc. are required. SAP provides a snapshot monitoring utility SMON (or /SDF/MON) which collects this information and stores it in a transparent table (header table) within the SAP database. One way of getting this data into Log Analytics Workspace is to use Logic App for ingestion.
In this architecture Logic App is used to ingest the SAP performance metrics data from /SDF/MON_HEADER (or /SDF/SMON_HEADER depending on what is scheduled) into a custom log table in log analytics workspace. The Logic app can be scheduled to run periodically with a recurrence trigger to pull the data from SAP based on time filter and push it into Log analytics workspace. In addition to forming the basis for autoscaling, getting /SDF/MON data into Log Analytics has other advantages.
Sample implementation of this can be found in this GitHub repo https://github.com/karthikvenkat17/sapautoscaling
Once the required performance is data collected the next step is to setup a detection mechanism on one or more of the collected attributes. As the required telemetry data is available in Log Analytics Workspace, Azure monitor can be used to initiate actions using the Log alerts. Log alerts allow users to use a query to evaluate resources logs at set frequency and fire an alert based on the results. Rules can trigger one or more actions using Action Groups.
For Example in an SAP application server with 10 dialog work process and maximum user sessions to be restricted to 60, sample query for high load would look like below
SAPPerfmon_CL
| where No__of_free_RFC_WPs_d <= 1 or Active_Dia_WPs_d >= 8 or Users_d > 50
| summarize count() by Servername_s
Similarly sample query for Low load will look like below
SAPPerfmon_CL
| where No__of_free_RFC_WPs_d >= 7 and Active_Dia_WPs_d <= 2 and Users_d < 50
| summarize count() by Servername_s
Once you have defined the query use Threshold, Frequency and Period to control when the alerts need to be fired. Note that Log alerts are stateless. Alerts fire each time the condition is met, even if fired previously. Use the Suppress Alert feature within the Azure Monitor to prevent alerts from continuously getting triggered for a period after the first occurrence.
Now that the alert triggering mechanism is finalized, the next step is to carry out the Scaling (Scale Out or Scale In) action as required. There are couple of ways of approaching this.
Detailed explanation of this architecture and sample implementation can be found in this GitHub repo https://github.com/karthikvenkat17/sapautoscaling
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.