Cloud Pak for Business Automation CP4BA

 View Only

New in BTS 3.17.0: Scaling with Deployment Profiles

By Benjamin Wende posted Mon April 11, 2022 10:03 AM

  
Author: Benjamin Wende
Reviewer: Torsten Wilms

Introduction
With IBM Business Teams Service (BTS) release 3.17.0, a new feature called Deployment Profiles is introduced. These pre-defined sets of pod replica count and Kubernetes resource requests and limits enable easy scaling of BTS and it's database pods. Further it is now possible to manually scale BTS by using replica count and resources.

The following chapters shows how to exploit the new feature using the BTS Custom Resource in Openshift.

Built-in Deployment Profiles and Sizes

BTS 3.17.0 introduces built-in Deployment Profiles using new properties in the BTS Custom Resource. The new properties deploymentProfile and deploymentProfileSize can be used to scale BTS without the need to further learn about Kubernetes resources and replicas. The built-in profiles were determined using sophisticated performance profiling and measurements.

The table shows the new properties and their values:
Property
Values
Notes
spec.deploymentProfile
Starter, Production
Starter not supported for production deployments
spec.deploymentProfileSize
Small, Medium, Large
Not available for Starter
Note: The values are case-insensitive, so production or Production means the same.

Below is an example of a BTS Custom Resource that contains the new properties:

apiVersion: operator.ibm.com/v1alpha1
kind: BusinessTeamsService
metadata:
name: bts
namespace: cp4ba
spec:
  deploymentProfile: Production
  deploymentProfileSize: Medium

The presence of these properties has an impact on the BTS deployment. The BTS-Operator will deploy the BTS and PostgreSQL pods requesting a certain amount of CPU and Memory, as well different limits for these resources. 

Further the it affects the number of pods that get deployed, the so called replica count. Requests to the BTS pods get distributed round-robin via the Kubernetes service. In contrast, the requests to the PostgreSQL database pods only ready the primary pod. All further pods are secondaries and will be used only if the primary experiences a service interruption.

The tables below describes this in detail:

Replica Count
Deployment Profile / Size
BTS Replica Count
DB Replica Count
Starter - n/a
1
1
Production - Small
2
2
Production - Medium
3
2
Production - Large
4
2

BTS CPU and Memory
Deployment Profile / Size
BTS Requests
BTS Limits
Starter - n/a
150m / 256Mi
500m / 512Mi
Production - Small
100m / 256Mi
400m / 512Mi
Production - Medium
100m / 256Mi
400m / 512Mi
Production - Large
100m / 256Mi
400m / 512Mi

PostgreSQL CPU and Memory
Deployment Profile / Size
DB Requests
DB Limits
Starter - n/a
50m / 768Mi
100m / 1Gi
Production - Small
50m / 768Mi
200m / 1Gi
Production - Medium
100m / 768Mi
300m / 2Gi
Production - Large
200m / 768Mi
400m / 3Gi
Note that CPU requests and limits are given in Milli-CPUs (e.g. 100m means 1/10th of a CPU core) and Memory either in Mi or Gi, which stands for Megabyte or Gigabyte). All resource requests and limits are per pod. More information can be found in the Kubernetes documentation [1].

As you can see, the BTS pods scale mainly with their Replica Count, while the PostgreSQL database pods scale through increase in CPU and Memory.


Custom scaling using Replicas and Resources

When it comes to scenarios where the built-in Deployment Profiles do not match the requirements anymore, it can be an option to manually scale BTS using Replica Counts and Resource Requests and Limits. 

It is possible to assign Replica Counts and Resource Requests and Limits using properties in the BTS Custom Resource. It is also possible to use these custom values together with the built-in Deployment Profiles. In this case the explicitly assigned value will overwrite the respective value from the Deployment Profile. For example it is possible to increase the replicas of the database to 3, while retaining the Production / Small Deployment Profile and Size values for all other values.

The table below contains the properties for Replicas and Resources:
Property
Example Value
Notes
spec.replicas
2
Requests are distributed round-robin to all pods.
spec.replicasDatabase
3
Requests are sent to the one primary pod, secondary pods are used if the primary experiences a service interruption.
spec.resources
resources:
requests:
   cpu: 300m
   memory: 512Mi
limits:
   cpu: 1000m
    memory: 1024Mi
resources consists of:
resources.requests.cpu
resources.requests.memory
resources.limits.cpu
resources.limits.memory
spec.resourcesPostgres
resourcesPostgres:
requests:
    cpu: 100m
   memory: 512Mi
limits:
    cpu: 500m
    memory: 2Gi
resourcesPostgres consists of:
resourcesPostgres.requests.cpu
resourcesPostgres.requests.memory
resourcesPostgres.limits.cpu
resourcesPostgres.limits.memory

Below is an example of a BTS Custom Resource that contains a combination of Deployment Profile and explicit resources for the database pods:

apiVersion: operator.ibm.com/v1alpha1
kind: BusinessTeamsService
metadata:
name: bts
namespace: cp4ba
spec:
  deploymentProfile: Production
  deploymentProfileSize: Medium
  replicasDatabase: 3
  resourcesPostgres:
    requests:
      cpu: 100m
     memory: 512Mi
   limits:
      cpu: 500m
      memory: 2Gi

Reference


#Kubernetes
#RedHat
#Openshift

Permalink