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.
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:
In the auto scaling groups console, it also looks good (see figure 2).
In the target goups console, it looks good as well (see figure 3).
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).
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).
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.
Congratulations, the final solution worked! Let’s see what we have built.
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.
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:
Thank you for being part of our „load balancing of SAP on AWS”-journey. I hope you enjoyed this technical trip.