Mountain panorama in pastel colors

Balance Your Sap Workloads Like Never Before

A series of five blogposts in which we outline how to set up enterprise-grade SAP systems on AWS Cloud. This is part 3 of the series.

October 07 2020Norbert Putz

Auto Scaling Group Setup with Launch Templates

This blog post series is based on a proof of concept to demonstrate how easy it is to connect SAP Application Servers to a Network Load Balancer, which also has a connection to an AWS Auto Scaling Group to use the elastic feature of the cloud. With the help of this architecture, it is possible to scale in and out based on scaling policies in multiple availability zones (AZ). In this part we will focus on the Auto Scaling group. 


Screenshot von AWS SAP

Figure 1: Create launch template 

What happened in part 2? With the help of a custom shell script, we are able to set the correct private IP address to our hostnames. The mentioned script will run at every boot up. After that we have created a so called “golden” AMI, which will be used as basis for our launch template.  

The Launch Template

In general launch templates enable you to store launch parameters so that you don’t have to specify it every time manually when you launch an instance. This is the feature we need because we would like to automate the whole scaling process. You can find more information about Launch Templates in AWS official documentation. Let’s get started with our own custom launch template. In the EC2 console on the left-hand size in the navigation pane, you can find the feature to create Launch Template (third one under Instances).

Abbildung 2 Screenshot von AWS SAP

Figure 2:  Choose AMI

In the first section, we define the name and description. In addition, we have the possibility to add tags and to select if we like to create a template from another existing template (“source template”). It is out of scope now, as we create our first one. As figure 2 shows, the next step is to choose the golden AMI, which we have created in blog series part 2. You will find it under my AMIs, or you can directly enter the AMI ID starting with “ami-“.

Screenshot 3 von AWS SAP

Figure 3:  Instance type 

The next step is to select the instance type. As we used r4.8xlarge before, we will select that:

Abbildung 4 Screenshot von AWS SAP

Figure 4: Security group 

Also enter your key pair (fig. 2 bottom). We need it if we like to logon to the created EC2 instances (which will be quite useful later). We can use the same as for the SAP CAL instances or create a new one – on the hand this creates some additional effort, but on the other hand raises security level considerably. 

The next section is about to define the security group. As SAP CAL already created the correct inbound and outbound rules, we will reuse that security group created for the SAP backend. You can check the technical name of the security group assigned to the instance in EC2 console. It starts with „sg-“.

Abbildung 5 Screenshot von AWS SAP

Figure 5: User data

The storage (volumes), resource tags, and network interfaces settings will remain unchanged. In the Advanced details section at the bottom, we will find a text box, which will be used to set our magic script as “user data” as shown in figure 5. 

Abbildung 6 Screenshot von AWS SAP

Figure 6: Launch template with details 

That’s all, after clicking on Create launch template button, we are good to go and setup the auto scaling group.

Setup of Auto Scaling Group

With the help of Amazon EC2 Auto Scaling service, we can ensure that we have the correct number of EC2 instances available to handle the load of our SAP application. You can find more details about the service in AWS official documentation. Let’s have a look at the setup. 

First, we have to define the name of our auto scaling group and the launch template, which we have created in the previous section. We again receive an overview about the selected version (in case you modify it, a new version will be created), the AMI ID, instance type, key pair name and security group ID – in other words: everything we defined previously as shown in figure 6. A good moment to check if everything is correctly in place.  

Screenshot von AWS SAP

Figure 7: Auto scaling terms 

On the next screen, we leave purchase options and instance type as default on “Adhere to launch template” as it is currently out of scope. More in focus is the network setup. We would like to build a Multi-AZ solution, so we select the correct VPC (I’m using the same, created by SAP CAL) including all available subnets, in our case five in us-east-1 region. The screen following that one gives us three optional settings. As we will set up the load balancing in part 4 of this blog series, we will skip this one for the moment. Health checks and additional settings will be left as they are. Back to our current subject, the next step gives us the option to set the group size with the parameters desired, minimum, and maximum capacity. Figure 7 shows an example for better understanding.

Abbildung 8 Screenshot von AWS SAP

Figure 8: Group size of Auto Scaling Group

In this example, we have set minimum capacity to 1, which means that one SAP backend will always be available. As we defined a multi availability zone setup, each and every instance in our maximum scenario will be started in a different availability zone (five subnets) in our case.  If for instance the health check on the original instance in us-east-1a fails, we still have instances in other availability zones, so the SAP backend system will be reachable. Desired capacity will define the number of EC2 instances, which we would like to have. As we want to define a load balancing setup, we have defined two as desired capacity. The maximum size defines – just as the name points out – the maximum number of EC2 instances, which our auto scaling group is allowed to start. As mentioned, this is only an example. Please keep in mind to set up a higher number, but not too high. It is always a question of architecture. We will go with the setup shown in figure 8.  

Abbildung 9 Screenshot von AWS SAP

Figure 9: Target tracking policy 

In our proof of concept we will set the same values and in addition we will set up a target tracking scaling policy as shown in figure 9. The following values are for test purpose only. Our plan is to stress the SAP backend with stress-ng and utilize high CPU utilization, so we can test our landscape and the scaling policy. We have set relatively small target values, so we can see the reaction of the AWS services earlier and don’t have to wait too long. Please always consider and discuss the values with your solution architect. Let’s have a closer look: My scaling policy checks the average CPU utilization of the instances and is intended to scale out when the maximum capacity reaches an average CPU utilization of 10 percent. The warm up value is given in seconds and means in our case that it takes 60 seconds for a newly launched instance to warm up. In case of scale out, AWS does not consider instances that are warming up as part of the current capacity of the group. This ensures that no additional instance will be added than those you really need. In case of scale-in, instances will be terminated. They count as part of the current capacity. It is important to mention that a scale-in activity cannot start while a scale-out activity is in progress.

Screenshot von AWS SAP

Figure 10: The “desired” setup of two EC2 instances

Instance scale-in protection is out of scope, so we leave it as it is. In the next screen, we can set a Simple Notification Service (SNS) topic to receive notifications in case of certain events. We will also skip this for now. The next step would be to set tags, however, it is a test environment, so I will skip this one as well. On the review page, I have all my settings. After checking whether we set the correct values, we can push the Create an Auto Scaling group button. 

Review our setup 

As figure 10 shows, we have two instances based on our launch template in different availability zones (us-east-1a and us-east-1f):

Abbildung 11 Screenshot von AWS SAP

Figure 11: 32 vCPU on almost 100 % utilization

Let’s stress the instances with stress-ng. It is an updated version of stress tool and it will stress test a server for the following features:

  • CPU compute
  • Cache thrashing
  • Drive stress
  • I/O syncs
  • VM stress
  • Socket stressing
  • Context switching
  • Process creation and termination

It includes over 60 different stress tests, over 50 CPU specific stress tests. With this tool, we will simulate high loads on the instances just like in the real world of an SAP landscape. The installation of the tool is easy on SUSE Linux, we will do the following:

  1. SUSEConnect -p PackageHub/12.3/x86_64
  2. zypper install stress-ng-0.10.14-2.1

SUSEConnect is a command line tool for connecting a client system to the SUSE Customer Center. As the SAP CAL solution uses SUSE Linux Enterprise Server 12 SP 3, we connect the instance with the PackageHUB 12.3 for architecture x86_64. After that with zypper install stress-ng-0.10.14-2.1 the package will be installed. 

Let’s stress it 

Please note that in this section we will stress our instances for testing purpose. As we know, we have an r4.8xlarge instance, which means 32 vCPU under the hood, let’s utilize all of them with the following command:
stress-ng --cpu 32 --io 2 --vm 1 --vm-bytes 1G --timeout 300s 
The command will run for 300 seconds utilizing 32 cpu stressors, 2 io stressors and 1 vm stressor using 1GB of virtual memory.
We are curious about the CPU utilization as we have set the target tracking policy to check the average CPU utilization. We expect really high values, let’s see it with command mpstat -P ALL 1 to get real-time values.

Abbildung 12 Screenshot von SAP AWS

Figure 12: Instance management 

It looks good, let’s see how our auto scaling group reacts:

Abbildung 13 Screenshot von AWS SAP

Figure 13: Five EC2 instances in five availability zones

As expected, the auto scaling group tries to balance the CPU utilization and starts the maximum number of EC2 instances, in our case five, utilizing all five availability zones in region Northern Virginia (see figure 12). At the moment, our infrastructure reached the limit, we cannot scale out anymore. Figure 13 shows the instances in EC2 console, all up and running. 

Abbildung 14 Screenshot von AWS SAP

Figure 14: SAP Logon – new system entry

Let’s make a test with our SAP frontend instance, whether we can access the SAP application server from the SAP GUI. We create a new entry and randomly chose asg-3 as test. It would work with each of the five instances. In SAP Logon, we’ve created a new system entry specifying the private IP address of the SAP backend. As SAP frontend and SAP backend are in the same VPC and the security group allows the SAP frontend to communicate with SAP backend on port 3200, we can reach the newly created EC2 instance based on our launch template and custom script as user data. We will use instance number 00 and System ID A4H just like before (see figure 14). 

Abbildung 15 Screenshot von AWS SAP

Figure 15: SAP transaction OS01 output as evidence

Let’s double check the IP address of the application server in SAP transaction OS01 (see figure 15). Indeed, it is the same as we were connected to asg-3, which is an EC2 instance created by an auto scaling group based on our launch template. It acts like A4H; however, we might remember that the original SAP application server had the private IP address (see part 2). 

Abbildung 16 Screenshot von AWS SAP

Figure 16: Scale-in, the fastest way 

Congratulations, it works! But now let’s scale-in immediately, we are just playing around, we don’t really have that high load and we don’t want to waste our money. The easiest way to scale-in is to change the desired, minimum, and maximum capacity to 0 as shown in figure 16.

Abbildung 17 Screenshot AWS SAP

Figure 17: Terminated instances  

What do we expect from this operation? As shown in figure 17, all five instances will be terminated immediately.


Let’s see, what we have reached in this part. I think, this part was the most interesting one. We have created a launch template, an auto scaling group with target tracking scaling policy. The latter dynamically scales-in and scales-out based on average CPU utilization. We have stressed our instances to utilize 100 percent of all the 32 vCPUs assigned to the instances. It was extreme, so the auto scaling group reacted immediately and started the maximum number of instances, as the utilization went back to normal, the auto scaling group scaled-in and terminated three instances from the maximum five to reach the desired capacity of 2. At the end of the demonstration I have set desired capacity to 0, minimum capacity to 0, and maximum capacity to 0. This is a kind of “suspend”. We have not deleted the group because we will need it in part 4 for load balancing. 

Cost Optimization – Best Practices

If you try out this proof of concept “live”, it is important that you take care of the costs. With SAP Cloud Appliance Library (CAL) you can suspend the landscape anytime, if you don’t need it at the moment. In the SAP CAL console, by clicking on Suspend, both instances will be stopped (not terminated). With this, it is possible to save money, if the trial is not in use. Costs don’t go to zero – as you can see in the cost example above also suspended instances will lead to costs. If the landscape is not used for days, it is worth to terminate it, so that even costs during suspend status are also eliminated. The SAP solution can be deployed again at any time. 

Appetizer for Part 4

„And next week you’ll see ...” – just like in TV series, this concluding section is about to provide a short introduction about what will happen in part 4. In our fourth part we will focus on load balancing. Currently we have five instances but we will resolve that I don’t have to specify five entries in SAP Logon but defining only the Fully Qualified Domain Name (FQDN) of the Network Load Balancer, and it will do the trick.

Stay tuned, part 4 will be published soon! Happy architecting!

About the author
Norbert Putz, Cloud Architect

Norbert Putz

Cloud Architect, T-Systems International GmbH

Show profile and articles
Do you visit t-systems.com outside of Germany? Visit the local website for more information and offers for your country.