Sterling Openshift Certified
Containers in the Cloud series - Autoscaling

Make your business more agile, efficient and resilient with IBM Sterling OpenShift Certified Containers - Autoscaling

This blog article describe the different use cases and set up for the Sterling Red Hat OpenShift (RHOS) Certified containers. This series will provide you with an overview of the different technology aspects of these containers, and how you can take advantage of the new capabilities provided by the RHOS platform for Sterling B2B Integrator (B2Bi) and Sterling File Gateway (SFG).

This is the second part of two posts that focus on Autoscaling, which is one of the major advantages of running Sterling solutions in a Kubernetes environment. In the previous post, we focused on how to set up Openshift to auto-scale B2Bi/SFG. In this post we will focus on how to configure B2Bi/SFG to enable auto-scalability, the different methods to test the auto-scale functionality with Kubernetes; and summarize what is the business value of using this functionality.

Let’s start this blog post by configuring B2Bi to enable auto-scaling, which is very easy to do.

Sterling B2B Integrator configuration

OpenShift’s HPA (Horizontal Pod Autoscalers) allow us to auto scale the B2Bi containers. In addition, with Sterling B2B Integrator version 6.1.0.0 you get the added Autoscaling support for the server adapters, including the FTP; FTPS; SFTP and C:D adapters. To pre-configure autoscaling on the communication protocol server adapters you need to do the following:

Simulating the High Volumes Usage scenarios

The main driver of this Autoscaling exercise is the ability to send a stimulus to the B2BI RHOC Cluster CPU usage with a conditioned response (Scale Up or Scale Down pods).

Sending this controlled stimulus can be achieved in different ways. This document describes four different approaches to demonstrate OpenShift’s auto scalability functionality with B2Bi containers. The autoscaling method that we’re using is based on CPU utilization, as this is easier to simulate. The four approaches we used to simulate high volumes are the following:

Here’s a general description on how to implement each of these methods:

1. Satya’s Endless Loop Method

This is a very effective and simple way to increase the CPU usage.  By just accessing the terminal in one of the B2Bi pods, and issuing the following endless loop command:

				
					yes > /dev/null &


				
			

Usually calling these commands 3 or 4 times combined with lowering the threshold in the horizontal auto scale configuration to a 40% of CPU time, will allow the pods to scale up within a couple of minutes. Make sure to configure a reasonable number of maximum pods in your Openshift’s HPA.

To allow your system to scale down, you can use the following commands to get the PIDs of the endless loop processes and then stop them. Once the CPU utilization goes down, OpenShift will reduce the number of pods, back to the original number, within a few minutes.

				
					ps -ef grep yes

kill -9 <# Process ID>
				
			

Note: Be very cautious while using this method, as it will result in 100% CPU utilization and could potentially affect your whole cluster, so make sure that you terminate these processes or pods.

2. JMeter stress testing method

Using a stress testing tool like Apache’s Open-Source JMeter helps simulate the calls for both file transfer and EDI dvelopment processes, running to simulate high volumes of data and observe how the system reallocates resources internally. This simulation helps  establish benchmarks for auto scaling with data and processes that are similar to what the current system is processing. Through this process, ideally, you will create an SFTP Server adapter along with a corresponding user (SFG Partner) and Mailbox. If you need to  replicate more intensive CPU usage, you can configure a business process that is triggered as files are uploaded into the SFTP mailbox (Figure 1). This business process can be a simple passthrough or can re-route or transform a file.

Openshift, Sterling Integrator, IBM, Pragmaedge, Sterling Openshift Certified Containers,
JMeter SFTP Stress Test UI

3. Arif’s Autoscaling setting method

</