Scaling

ITX Runtime Server pods run independently of each other and can serve client requests that can be load balanced across them in any pattern. This includes running ITX maps asynchronously, including scenarios when one pod instance processes the REST API POST call request to run the map and another pod subsequently processes the REST API GET call request to return the status of the map execution, even if the two pods are running on different worker nodes. To access the compiled maps, the pods are accessing shared persistent volume where the compiled maps are saved, and to access statuses of the asynchronous map executions the pods are utilizing Redis queues, which is the reason Redis is required when asynchronous map calls are made.

The number of pods running at any time can be controlled through the replicaCount property exposed by the product. When sufficient system resources are available and have been provisioned for the newly added pods to the deployment, it will increase the ability of the deployment to handle additional workload as more pods will be available to process the incoming REST API calls simultaneously.

In addition to supporting multiple pods in a single deployment (ITX Runtime Server instance), multiple deployments can be installed in the cluster, but they need to be installed in separate projects (namespaces), one instance per project. This provides for example the ability to run separate QA and Dev ITX Runtime Server deployments in the same cluster simultaneously.

ITX Runtime Server pods can be auto scaled based on threshold target CPU or Memory utilization on the worker nodes of the cluster. Auto scaling of ITX Runtime Server pods is disabled by default in the Helm Chart for IBM Sterling Transformation Extender for Red Hat OpenShift. Enabling autoscaling option disables replicaCount specified in the configuration. IBM Sterling Transformation Extender for Red Hat OpenShift supports horizontal pod autoscaling. But, it does not support vertical pod autoscaling at this time.