Compact is a special sizing that is the minimum requirements for a functional BMC Helix Innovation Suite system. Compact systems are suitable for POC, development, and QA systems where resilience and system performance under load is not a consideration.
Concurrent users indicates the combined number of users that are logged in and actively working on a system across each of the following BMC Helix IT Service Management applications that are hosted on a single deployment of BMC Helix IT Service Management 21.05:
- BMC Helix ITSM
- BMC Helix ITSM: Smart IT
- BMC Helix ITSM: Smart Reporting
- BMC Digital Workplace
- BMC Digital Workplace Catalog
- BMC Helix Business Workflows
- BMC Live Chat
For real-world deployments, concurrent users might not be the only factor that drives the categorization of a system in the small, medium, or large category.
For example, if you have a high number of integrations that create a high number of system transactions, you need to increase your sizing to accommodate the additional load from integrations.
| Category | Concurrent Users | Maximum Concurrent Users Per Application* | Definition | |
|---|---|---|---|---|
BMC Digital Workplace | ||||
| Compact | NA | NA | NA | Minimum functional deployment. Suitable for POC, development, and QA systems. |
| Small | 730 | 150 | 100 | Suitable for production systems where overall load does not exceed the number of concurrent users. |
| Medium | 2110 | 550 | 225 | |
| Large | TBA | TBA | TBA | |
*Maximum Concurrent Users Per Application: Smart IT and BMC Digital Workplace are resource-intensive applications.
If the number of concurrent users for these applications exceeds the stated maximum, use the higher appropriate sizing. For example, if you have a total number of 600 concurrent users, use small sizing. However, if you have 200 concurrent Smart IT users, use medium sizing.
Other applications on the BMC Helix Innovation Suite platform do not have these restrictions if the total number of concurrent users does not exceed the stated maximums values.
Kubernetes infrastructure sizing requirements
The following table shows the compute requirements for Kubernetes deployments of the containerized BMC Helix IT Service Management 21.05 version. Compute requirements are the combined requirements of CPU, RAM, and Persistent Volume Disk requirements for the Kubernetes compute nodes.
| Category | CPU | RAM (GB) | Persistent Volume Disk (GB) |
|---|---|---|---|
Compact | 118 | 210 | 200 |
Small | 184 | 309 | 200 |
Medium | 189 | 434 | 200 |
Per worker node logging
Combine the overall Kubernetes compute nodes requirement with the following requirement for per worker node logging that runs as a DaemonSet 
on each worker node:
vCPU per worker node | RAM per worker node |
|---|---|
3.1 | 8.2 |
For example, for a compact deployment, calculate the overall compute footprint as follows:
| Compact deployment on | CPU | RAM |
|---|---|---|
| 5 worker nodes | 118 + (5 x 3.1) = 133.5 | 210 + (5 X 8.2) = 251 |
| 3 Worker Nodes | 118 + (3 x 3.1) = 127.3 | 210 + (3 X 8.2) = 243.6 |
CPU requirements
The CPU requirements are as follows:
- CPU size must be minimum 2.4 Gz.
BMC expects future releases of BMC Helix IT Service Management will require CPUs that support Tensorflow 2.x.
Most of the modern chipsets support this capability. For more information, see Hardware requirements
in TensorFlow documentation.
Compute node minimum requirements
Each node in the Kubernetes cluster must have the following minimum configurations:
| Specification | Compute node |
|---|---|
CPU | 8 |
Memory | 32 GB |
Available system disk after OS installation | 150 GB |
For high availability deployments such as production environments, Kubernetes recommends three control nodes.
Best practice
We recommend that you review the vendor documentation for sizing of control nodes. BMC does not have any specific requirements for the sizing of control nodes in a Kubernetes cluster.
For information about recommendations for canonical Kubernetes control nodes, see Size of master and master components in Kubernetes documentation.
Persistent volume disk requirements
High performance of Kubernetes Persistent Volume Disk (PVC) is essential for the overall system performance. Persistent Volume Disk requires block storage. BMC supports a Bring-Your-Own-Storage model for Kubernetes Persistent Volumes. BMC lab testing uses Ceph storage.
We recommend that you use solid-state drive (SSD) with the following configurations:
| PVC | Recommendation |
|---|---|
Write latency | 1 ms |
Read latency | 1 ms |
| Write Throughput | 30 MBPS |
| Read Throughput | 80 MBPS |
| IOPS Write | 20 K |
| IOPS Read | 7 K |
