Balance Your Sap Workloads Like Never Before

What happened in part 3? We have set up the auto scaling group and we were able to scale out based on predefined metrics because of a planned stress event with stress-ng. Let’s see how we can combine the Network Load Balancer with the auto scaling group.

Load Balancers in General

In part 3 of this blog series, I announced that we will get back to the load balancing part of the auto scaling group. And here we go: Our journey starts again in the EC2 console. On the left-hand side in the navigation pane, we have selected Load Balancers and clicked on the blue button in the middle Create Load Balancer. At this stage, we can choose from three types of Load Balancers: Application Load Balancer, Network Load Balancer and Classic Load Balancer. The Application Load Balancer provides a flexible feature to balance your HTTP (TCP/port 80) and HTTPS (TCP/port 443) loads between instances in a target group. But, you might remember, in our scenario we are communicating on port 3200 with the SAP dispatcher. Wrong port – so we need another solution. We could use Classic Load Balancer but therefore we need an application running in the EC2 classic network – and AWS recommends not to use it because it is a bit outdated and best fits for previous generations for HTTPS, HTTP and TCP traffic. The best solution for our case is to set up a Network Load Balancer. As the short introduction on figure 1 shows: “It is capable of handling millions of requests per second securely while maintain ultra-low latencies”. This is what we need. 

As shown in figure 2, at first, we will edit the setting load balancing for the auto scaling groups:

It contains two options: Load balancer target groups and Classic Load Balancer. As we will use Network Load Balancer, we will only set the target group. 

We will create the Network Load Balancer, which includes a step to create the target group. In step 1, we define the name and the scheme, which can be internet-facing and internal. We will go for the internal one as all our instances are running within one VPC. Let’s define the listener to TCP on port 3200. This is the port for the SAP dispatcher but we can add more listeners (up to 50) for one load balancer. For more information about limitation, consult the AWS official documentation. 

In this section we define to which targets in which target group our load balancer will route the requests using TCP protocol and 3200 as port. In addition, we have the possibility to set health check settings. We will leave the health check settings as they are for now. 

Our aim is to balance the load between different availability zones. Therefore we have to enable the setting Cross-Zone Load Balancing as shown in figure 5. 

Finally, we need to set the target group for our load balancer. It has been created in blog series part 3 (sap-test-tg), so we will just use that as shown in in figure 6.

First let’s see, whether we can reach our instances in the auto scaling group. We will change the capacities back to the values we used in part 3 (desired: 2, minimum: 1, maximum: 5) to see, whether the load balancer uses the target group, which registers targets in the VPC. 

As figure 7 shows, we have two desired EC2 instances in healthy status. As next step, in SAP Logon (SAP frontend), we have created a new system entry and entered my Network Load Balancer’s DNS name. You can find it in the load balancer console (Description tab/DNS name)). 

Checking SAP transaction OS01, we will see that the Network Load Balancer routed the traffic on TCP/3200 to nlb-test-1 in availability zone us-east-1b as shown in figure 9. 

Congratulations! Our Network Load Balancer works perfectly together with the auto scaling group thanks to the target group. Now let’s scale-in once again. As you already know the easiest way to scale-in is to change the desired, minimum, and maximum capacity to 0 as shown in figure 10.