T-Systems-Claim-Logo
Search
Mountain panorama in green-blue tones

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 5 of the series.

October 21 2020

Et voilà – it’s Running

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 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 test the whole solution. 

Let’s stress test again

Bild 1 Screenshot SAP on AWS

Figure 1: List of EC2 instances

As shown, we have started our auto scaling solution by setting desired to 2, minimum to 1, and maximum to 5. We have executed the stress-ng commands on two instances first. We will use them again, it worked so well last time:

stress-ng --cpu 32 --io 2 --vm 1 --vm-bytes 1G --timeout 300s
The auto scaling group reacted and started the maximum number of EC2 instances:

Bild 2 Screenshot SAP on AWS

Figure 2: Instance management of auto scaling groups

In the auto scaling groups console, it also looks good (see figure 2).

Bild 3 Screenshot SAP on AWS

Figure 3: Registered targets

In the target goups console, it looks good as well (see figure 3).

Bild 4 Screenshot SAP on AWS

Figure 4: SAP Transaction OS01

After starting stress-ng on all five instances, the load balancer still routes the traffic to the first healthy instance, final-test-1 (see figure 4).

Bild 5 Screenshot SAP on AWS

Figure 5: Final-test-1 instance is getting unhealthy

Let’s now simulate a fail of the running instance. Thus let’s stop the SAP NetWeaver stack on final-test-1 instance.  No wonder a powerful, healthy instance becomes unhealthy within seconds (see figure 5).   

Bild 6 Screenshot SAP on AWS

Figure 6: Routing traffic to another healthy instance

Accordingly, the Network Load Balancer decides to route the traffic to another healthy instance, which will be final-test-4 in us-east-1e (see figure 6) with its own IP address.

Conclusion

Bild 7 Screenshot SAP on AWS

Figure 7: Final architecture 

Congratulations, the final solution worked! Let’s see what we have built. 

Bild 8 Screenshot SAP on AWS

Figure 8: Scale-in, the fastest way    

Our test was successful. Now let’s scale-in for the last time. We set the desired, minimum, and maximum capacity to 0 as shown in figure 8.

Final Termination

As we are at the end of our blog series, please don’t forget to terminate the instances in SAP Cloud Appliance Library (CAL) by clicking on Terminate, both instances will be terminated. 

In the AWS Console, delete the following:

  • EC2 Dashboard: any running instances should be terminated
  • Launch Template: delete launch template
  • AMIs: delete the created AMI
  • Volumes: delete any EBS volumes, which are not used
  • Load Balancers: delete Network Load Balancer
  • Target Groups: delete target group
  • Auto Scaling Groups: delete auto scaling group
  • IAM: delete user created for SAP CAL

Thank you for being part of our „load balancing of SAP on AWS”-journey. I hope you enjoyed this technical trip.

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