We have released a new white paper detailing how to size SAP solutions on Microsoft Azure public cloud. The document is attached to this blog.
Initial work on this topic is mentioned in this blog: How to Size SAP Systems Running on Azure VMs.
Microsoft is Executing and Publishing SAP SD Standard Application Benchmark on Azure
Sizing is an important topic when deploying a SAP solution since we want to make sure we have enough computing resources to guarantee us the performance needed.
As Microsoft is a cloud provider, we are responsible for executing and publishing official SAP 2-tier and 3-tier benchmarks. All the SAP benchmarks certified and released on Azure can be found here: http://www.sap.com/benchmark and are also listed in SAP Note 1928533 – SAP Applications on Azure:Supported Products and Azure VM types
Each benchmark specifies the exact configuration, VM size, and storage type used for the benchmark.
The sizing process is nevertheless a complex topic. To help our customers and partners with this process, we have developed this document as a set of guidelines to help in the sizing process.
This document provides “T-shirt” sizing primary for 3-tier SAP Solutions running on Azure, as 3-tier is more suitable for the productive SAP use case. The document also discusses 2-tier configurations for SAP solutions on Azure.
Picture 1: T-shirt Sizing
Covered SAP Applications and Components
As different SAP applications and components can have very different workload characteristics and requirements, the document also reflects these different applications, such as SAP ECC 6.0, SAP Business Objects, SAP liveCache, SAP Content Server, SAP Solution Manager, SAP BI Java and Enterprise Portal, SAP XI/PI, SAP NetWeaver Gateway, CTM Optimizer, SAP TREX etc. The document also reflects different components of the SAP NetWeaver technology stack, such as SAP application servers, SAP database server, and SAP ASCS/SCS instance.
Azure Premium Storage
A special chapter is dedicated to Azure fast SSD premium storage since as fast storage is crucial for performant storage-intensive IO workloads like database servers.
Advantages of Dynamic SAP Resizing on Azure Public Cloud
Many customers who run their SAP systems on-premises are oversizing their infrastructure to make sure they can cover the peak load. Peak time can happen for example once in three months (during the quarter close) and can last for a few days. But most of the time, there is a much lower load on the system compared to peak time, which means that infrastructure resources dedicated to SAP system are underutilized.
One huge advantage of Azure cloud compared to on-premises infrastructure is the ability to dynamically increase resources (to cater for increased demand) or decrease resources if resources are underutilized (to save money). Either way, you are only paying for what is used and when it is used.
Here is an example of scaling out the SAP NetWeaver ABAP application server component, where the SAP workload is based on interactive SAP user workload, which is running on two SAP application servers running on two Azure VMs (the same principle can be applied on SAP batch, RFC, and update workload). SAP user workload is automatically balanced by logon (SMLG) groups.
As new users are added to an SAP application server, after a certain point the performance starts to degrade. Additional new workload further degrades application server performance, as the servers are too busy serving currently logged-on users. In extreme cases the application server appears to hang.
Picture 2: Scale Out of SAP Application Server (AS) – Initial State
The solution for this problem is to dynamically scale out SAP application server layer, e.g. to add an additional new third SAP application to handle new SAP users. We have already prepared additional application servers (AS3 and AS4), which are pre-deployed on two VMs. These two VMs are initially in an offline state and are not generating cost (except a very minor storage cost).
We can start the new VM with SAP AS either manually or using Azure Autoscale in Azure for automatic scale out.
Picture 3: Scale Out of SAP Application Server (AS) – End State after the scale out
In a similar way, when SAP user load drops, we can scale in SAP application server(s), e.g. we can stop some SAP application server(s) and shut down VM(s), so reducing infrastructure costs.
Generally speaking, it is recommended to review utilization on infrastructure about every three months to determine whether the Azure resources provisioned match the demand from the SAP workload.
You can also actively monitor utilization, try to recognize the utilization patterns and identify peaks, and proactively resize Azure infrastructure for your SAP system.