SAP Datasphere: How Elastic Compute Nodes help to manage peak-loads

With a standard SAP Datasphere setup, you have the option to select a pre-defined base configuration where you can setup your storage and memory. Based on the selected memory, a number of virtual CPUs are assigned to your tenant (see picture).

In practice, this means you always will oversize your system. In the end you want to make sure that at moments that most people use your system it keeps performing, in order to prevent end-users from experiencing long waiting times to receive answers to their queries. This means that basically, you size for the peak-moments. This entails that on non-peak moments (weekends, nights) you have to pay for an almost idle system. This is not what you would expect from a cloud solution.

Luckily, SAP also realized this and in July 2024 they have introduced the Elastic Compute Node concept. This allows you to purchase additional Compute blocks for a certain amount of hours per month (see picture).

You have the option to choose the type of performance class, and based on that, you will get an additional 1, 2 or 4 CPUs assigned to you. You can also define the amount of block hours you want to purchase. Within one hour, you can assign a maximum of 4 block hours.

This option will only be available in case you have at least a base configuration that has 128GB of memory.

Before you purchase these elastic nodes, you, of course, need to determine whether or not this situation applies to your system. You need to see if there are patterns in your memory and CPU consumption that you can identify. Are there certain moments in the day, week or month that are showing max CPU consumption? For this, you can use the Performance Monitor in the HANA Cockpit:

In the picture above, you see an example of the CPU usage of an SAP Datasphere tenant. You can see a pattern that shows that during the night, there is a maximum CPU consumption. In this case, this is not an issue since these are batch jobs that are loading data overnight. No end users are impact and the loads are finished in time. In case these peaks would have happened during the day and were caused by end-users querying your SAP Datasphere system, you could decide to assign elastic compute nodes during this time period.

Before you decide to do so, it is also important to see if, during these peak moments, rejections and queueing occur around the same time. This can be checked in the Admission Control Monitor in the Hana Cockpit. If you see this happen in combination with maximum CPU usage, it can be an indicator to assign elastic nodes.

As a last step, you need to identify which spaces and/or objects are using most of the resources in these time windows. The Workload Analysis tool in the Hana Cockpit can help you with that investigation. It is key to know what is causing the high demand since these are typically the objects that you want to assign to your elastic nodes.

Once you have identified that elastic nodes can help you solve performance issues during certain time windows, you must create these nodes in the system. This can only be done by System administrators. You can create Elastic Compute Nodes in the Space Management area:

When creating the Elastic Compute nodes, you can set the number of compute blocks. If you have chosen 4 compute blocks, it means that for each hour that node runs, you have to ‘pay’ 4 block hours. This is then subtracted from the amount of available block hours that you have purchased in the initial configuration.

Once the node is created, you can assign spaces or individual objects to it. These are the spaces and objects you identified in the previous step via the Workload Analysis tool. These objects will be shown in the ‘Exposed Objects’ tab.

You need to be aware that data from remote tables cannot be replicated to the Elastic Compute Node. If you need this data to be available, you will need to persist this data in a view (best practice is to use the fact-view).

Now that the node is created, you need to schedule this node. It is good to understand the actions that take place when an elastic node is started and stopped. That is depicted in the picture below.

You can either start/stop a node manually via Space Management, or you can schedule this on a given time window. For example, each workday between 9 am and 11 am, or each first two days of the month between 9 am and 5 pm. You will need to make sure that the amount of block-hours that will be consumed by this schedule matches the amount of block-hours that were purchased in the tenant configuration.

For the cost calculation we make use of the Datasphere Pricing Calculator.

Let’s take an example in which you have an environment with 512GB of storage and 128GB of memory of performance class Compute. This environment will cost you 4946 Capacity Units per month. This is, in general, enough to cover your reporting requests; however, during the Month End Close period, end-users are complaining about long response times. You have done your investigation and indeed see that specific queries on Financial Data take a lot of CPU time during the first two working days of the new month. As a consequence, requests are put in a queue and sometimes rejected, which explains the issues that end-users are experiencing.

In order to solve this, you would need to increase your memory with another 64GB (8 CPUs). In case you do this via your base configuration and set your memory to 64GB permanently, your monthly Capacity Units would increase to 7045. With a one-on-one ration to euro’s this would be an additional 2100 EUR per month.

In case you decide to use the elastic compute nodes instead, you would require 80 hours of High Compute. These 80 hours can be assigned to elastic nodes on the first two days a week that run every day between 8:00-18:00 and use 4 compute blocks (2days*10hrs*4 blocks = 80 block hours). These 80 hours would cost you only 93 Capacity Units in total. This would save 2000 EUR/month compared to increasing your overall memory size.

The ability to assign Elastic Compute Nodes is definitely a step forward compared to the fixed approach that SAP had until now. It is not as flexible as we see with hyperscalers like AWS, and Microsoft, but it is definitely going to give you options to more appropriately size your system based on the observed (required) demand. It would be nice if this option would also be made available to some smaller-sized systems (below 128GB of memory) and that remote tables would also be taken into account in the replication towards the Elastic Compute nodes, but it is a big step into the right direction.