Auto Scale SAP Application Instances Using AWS

Use Cases –

• Month End & Finical Year End peak loads
• Pay Roll & MRP Run impacts system performance
• Automation  

Purpose 

Customers who run SAP on AWS today take advantage of the broadest and deepest set of native cloud services. These span traditional services like compute, storage, and databases, as well as emerging technologies like IoT and machine learning, on top of a reliable global infrastructure.

One of the main features that we see customers use is the changing of instance types. As the workload changes, customers find that their instances are over utilized (the instance type is too small) or underutilized (the instance type is too large).

This concept of scalability is called vertical scaling. More simply, it is the ability of the system to accommodate additional workloads just by adding resources.

As you know, vertical scalability at the database layer for SAP is important, but what about the application server layer? You can’t create one massive application server to support all your workloads, can you? Maybe you can, but it’s probably not a good idea, and this is why SAP designed application servers to scale horizontally. This is where the concept of auto scaling often comes into play.

For horizontal scalability, customers perform sizing and use historical data to determine how many application servers they require to support their peak workload. This leads to underutilized resources or resource bottlenecks when unplanned events occur, such as marketing-driven sales order spikes or large data volume extracts for reporting.

When horizontal scalability comes into the discussion, someone from your DevOps team or cloud engineering team might suggest Amazon EC2 Auto Scaling. But as we all know, SAP can sometimes be a square peg to a round hole. SAP doesn’t always make it easy to handle scalability given its on-premises origin.

This is where Sapphire Infotech helps customers to build a bridge connecting SAP’s on-premises scalability capabilities to a cloud-native Auto Scaling group.

Solution overview

Traditional automatic scaling uses a range of metrics from CPU utilization to the number of requests to the target of your load balancer. These are both great indicators of workload and the applications use of the underlying resources. However, they don’t reflect some necessary behavior patterns that customers should consider for SAP utilization.

Every SAP application server consists of work processes that are SAP services based on the SAP kernel. This makes SAP unique. Each work process is specialized in a particular task type that runs at the OS layer consuming CPU, memory, network, and more. When sizing SAP application servers, the balance and distribution of these are critical to a healthy SAP system.

For micro services and most modern-day applications, standard automatic scaling metrics like CPU and request counts are often sufficient to handle the application automatically scaling. For SAP, you must consider work processes, especially how many are free or currently consumed.

So, how do you bridge the native automatic scaling capability to consider CPU utilization and request counts as well as work process consumption.

This solution enables enterprises and SAP Customers to automatically detect SAP application server consumption based on SAP-specific workload metrics for dialog, batch, enqueue, and print work processes. This solution can adapt to spikes and dips for concurrent user logins, month-end close, payment runs, and a variety of both predictable and unpredictable workloads.

The solution uses the on-demand cloud model of provisioning only the application servers that you require. It horizontally scales out (new compute is started as application servers) and back in (existing compute as application servers are stopped), based on the metrics that you define. This is similar to the way that your thermostat maintains the temperature of your home—you select a temperature and the thermostat does the rest.

The following diagram shows how this architecture is configured:

But wait. When you say that this solution scales not only out but also back in, are you going to shut down an application server with users and background jobs running on it

Here is another nuanced SAP challenge. Not all SAP traffic is routed through a load balancer for which we can proactively use connection draining. Some of this traffic is end users on the SAPGUI or from other systems calling your system through native SAP RFC.

To handle this natively with SAP, invoke the soft shutdown, or graceful shutdown, capability within SAP all with the server less compute layer, AWS Lambda. This ensures that no requests or data are lost when ending an SAP instance and you minimize the overall TCO of this solution.

A soft shutdown waits for transactions to be completed in a specific order. You then combine this with the API control plane of EC2 to coordinate the application servers’ underlying EC2 instance for a holistic approach to SAP capacity on demand.

Sapphire Infotech solution, using AWS server less computer, storage, and analytics, enables customers bound by on-premises and monolithic SAP architectures to run SAP in a more elastic, scalable, and cost-effective manner.

Conclusion

This offering serves not only as a turnkey solution in the form of native infrastructure as code but also as an accelerator to build highly customized solutions for customer-specific requirements.

With AWS Auto Scaling, you only pay for what you require, helping to reduce operational cost and providing higher service level objectives. Gone are the days of calculating how many application servers you require to over-provision to stay above the SAPS calculated for your new project or the upcoming marketing campaign over the weekend.

Just like a thermostat, you select metrics and the solution does the rest.