Provisioning Considerations

• The message data storage class is an important factor in the overall server performance. Especially for the EMS production server groups, it must be carefully selected to balance between cost and performance.

• If the Capability is for production checkbox is selected, provisioning a large EMS server-group requires relatively large underlying Kubernetes nodes. Trying to provision EMS to a small Kubernetes cluster, results in pods stuck in pending state.

• Using shared log storage simplifies support and administration, as the debug logs for all three servers can be viewed from any pod. However, it does not work with all storage classes.

  The examples of storage supporting multi-pod usage are as follows:
  

  • Network File System (NFS version 4.1)

  • Server Message Block (SMB2/SMB3)

  • Elastic File Store (EFS)

  The examples of storage that do not work are as follows:
  

  • Elastic Block Store (EBS)

  • Node local disk

Setting Resources Explicitly

You can override the default resource requests and limits for StatefulSet pods using the optional Custom Configuration tab and a YAML file that contains custom values. For more information, see Provisioning the TIBCO Enterprise Message Service Capability.

If you do not define any resources for a StatefulSet, the default values are applied. When you override only some resources for a StatefulSet, the unspecified resources are not set. For example, if only CPU and memory requests are defined, no limits are applied.

Example Custom Configuration

ems:
    resources:
        requests:
            cpu: 1
            memory: 1Gi
        limits:
            cpu: 5
            memory: 5Gi
toolset:
    resources:
        requests: 
            cpu: 1
            memory: 1Gi
        limits:
            cpu: 4
            memory: 4Gi