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.

  • Provisioning EMS without a message storage class is only appropriate for limited development, proof-of-concept, and demo scenarios. Skipping the selection of the storage class results in breaking some FT features. Hence, you should always select the storage class for a production and qa server-group.

  • 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