Overview
In order to adapt your SAP BTP ABAP Environment system to changing load patterns, you can already manually increase or decrease the ABAP Compute Units (ACUs) and HANA Compute Units (HCUs), which represent the ABAP and HANA compute/memory power of the system. But this is quite static, for example, you would need to change it again when the load pattern changes, and it is not meant for frequent changes.
With release 2402, there is a new feature for automatically adapting the size of the ABAP runtime - the actually allocated ACUs of the system - based on the current load on your application servers. Load is constantly measured, using common metrics like CPU and memory utilization of the ABAP runtime as well as ABAP-specific metrics like the number of used work processes. We call this elastic application server scaling as it dynamically adds or removes application servers to or from the system. When the mechanism detects a high load in your SAP BTP ABAP Environment system, it will add additional application servers up to the instance's ACU configuration, which acts as a maximum. When the load decreases, the additional application serves will slowly be removed again. If the load gets low, the instance scales down to 1 ACU as a minimum.
Customers benefit from this feature by saving costs, since only the provided capacity, also called allocated capacity, is metered and invoiced later in case of consumption-based contracts. Costs for a service instance sized for maximum workload can thus be reduced for times with low utilization, respectively it is possible to allow a capacity buffer for workload peaks which cannot be predicted.
The elastic scaling can be enabled by just changing the configuration of your SAP BTP ABAP Environment system and setting the "elastic" parameter to "true" (see documentation).
Note that the elastic scaling feature only applies to the ACUs of the system. The HCUs still need to be adapted manually.
Manual Scaling
Before we jump into the details of the elastic scaling feature, let's first have a look at the configurations for manual scaling:
It is possible to manually increase or decrease the amount of ACUs of an SAP BTP ABAP Environment system via the SAP BTP Cloud Cockpit (see documentation), for example, you can increase the ACUs (configuration parameter size_of_runtime) from 2 to 3 in order to add additional ABAP compute/memory power to your system. The additional ABAP compute/memory power is added to your system within a few minutes. When you decrease the value, the now superfluous compute/memory power will be removed, for example, ABAP application servers will be shutdown and removed from the system.
In addition, the SAP HANA persistence included in the SAP BTP ABAP Environment system can be scaled manually with regards to the HCUs (configured via parameter size_of_persistence), or regarding the disk capacity (configured via parameter size_of_persistence_disk). See documentation for more details. The overall time for HCU changes depend on the size of the database, small changes are typically in the range of some minutes. Changes to the HCU are carried out in a near-zero-downtime fashion and the ABAP runtime service instance stays operational except for a switch-over time for the database, which is typically in the range of a few minutes.
To check whether your account has enough quota for ACUs and HCUs, please refer to the documentation.
Explanations for the different size_of_... parameters in the instance configuration can be found as well in the documentation.
Elastic Scaling
The elastic scaling feature can be switched on for existing service instances or ordered for new services instances via the "elastic" configuration parameter in the SAP BTP Cloud Cockpit, see documentation on how to use the Update feature.
When switched on, the service instance will automatically scale between 1 ACU, with 2 application servers, as a minimum and the configured amount of ACUs (configured via parameter size_of_runtime) as a maximum. To ensure that defined quotas are not exceeded, the configured amount of ACUs (the maximum) is allocated from the ACU quota for the whole time the service instance is provisioned. Scaling happens by adding or removing individual application servers with the capacity of 0.5 ACUs. There is no vertical scaling to increase the size of a single application server beyond 0.5 ACUs.
When a service instance is scaled up, more ABAP compute/memory power is added automatically. This happens typically within a couple of minutes. When a service instance is scaled down, compute and memory capacity is removed. There is a grace period of a few minutes to allow the completion of short-lived requests before the capacity is reduced.
If you are interested in the currently allocated and used capacity, the Local Health Monitoring app, and the SAP Cloud ALM health monitoring provide insights.
Let's have a look at the embedded Health Monitoring app, it shows a tile for the ACUs which contains the used ACU quota of the instance, the currently allocated ACUs, and the used CPU and memory:
At around 8:15, we created some load in the system, which increased the CPU usage. We can see in the graph, that the elastic scaling feature reacted to this situation and that additional ABAP compute/memory power got added to the system. Around 8:50, the load decreased again, and the systems got back to its minimal ACU allocation after a cool down phase.
We recommend that you test your typical workload patterns and watch the Health Monitoring app before enabling elastic scaling in production, to make sure that your typical workload is well suited for this cost-saving measure. In cases where large sudden spikes need to be handled quickly, it may be better to keep a higher amount of ACUs configured statically.
- SAP Managed Tags:
