Sizing and scalability considerations
The sizing baselines specified in this topic are based on the performance lab benchmark test results performed in BMC’s test labs. You may use these baselines as a reference for your on-premises BMC Helix IT Service Management deployment.
Important
- The Kubernetes cluster and worker node sizing guidelines in this topic do not include BMC Helix ITSM Insights, BMC Helix Business Workflows, and BMC Helix Multi-Cloud Broker requirements.
- The Kubernetes cluster and worker node sizing guidelines in this topic do not include the installation of BMC Helix IT Service Management in a multitenant BMC Helix Platform environment.
- If you are deploying multiple containerized products such as BMC Helix IT Service Management, BMC Helix Operations Management, and BMC Helix Continuous Optimization in your environment, prepare your cluster to match the combined sizing for all products.
For information about BMC Helix Operations Management and BMC Helix Continuous Optimization guidelines, see Sizing considerations
in the
Concurrent user requirements
Sizing requirements are measured in groups of T-shirt sizes such as Small, Medium, and Large. Each group has a considered maximum load of the following users:
- Concurrent users—represent the 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:
- BMC Helix ITSM
- BMC Helix ITSM: Smart IT
- BMC Helix Dashboards
- BMC Digital Workplace
- BMC Digital Workplace Catalog
- BMC Live Chat
- Resilient concurrent users—are the maximum number of users that the deployment should handle from a single failure without service interruption if pods in the deployment become unavailable.
In 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 must increase your sizing to accommodate the additional load from integrations.
The following table lists the concurrent user guidelines for a deployment size:
| Deployment size | Resilient concurrent users | Maximum concurrent users |
|---|---|---|
| Compact | Not applicable | 200 |
| Small | 200 | 400 |
| Medium | 400 | 800 |
| Large | 800 | 1750 |
Important
Compact is the deployment size for nonproduction environments and does not support High Availability (HA).
Kubernetes cluster sizing requirements
Containers are measured and sized during the startup and load phases of an application. An application container requires more resource utilization during startup than at peak measured loads. The difference in resource utilization between startup and load can be used as shared burstable vCPU for workloads with additional cluster limit constraints.
The following table lists the Kubernetes cluster sizing requirements:
Deployment size | Required vCPU | RAM (GB) |
|---|---|---|
Compact | 35 | 140 |
Small | 45 | 200 |
Medium | 75 | 270 |
Large | 75 | 325 |
Important
The Kubernetes cluster sizing requirements listed are for single BMC Helix IT Service Management environment installation in a cluster. To setup multiple environments, based on the number of environments, add the vCPU and RAM requirements for each installation.
The requirements are developed using a consistent distribution of users across all applications. If your environment has a significantly larger number of users for an application, validate the environment performance to make sure that it can handle the load.
Worker node minimum requirements
An application in a highly available architecture must be supported by a minimum of four worker nodes. Data lake services utilize a HA pattern and use four pods per data lake service. Three available nodes in the cluster spread the data lake cluster services out to separate machines and maximize pod availability and effectiveness. A fourth node helps to ensure that data lake cluster services can maintain a spread on separate nodes when one is cordoned off for maintenance.
A worker node must have the following minimum required resources in order to support any portion of the application to be scheduled by Kubernetes:
Important
The total amount of vCPU and RAM resources selected for the worker nodes must match or exceed the required vCPU and RAM specified in the Kubernetes cluster sizing requirements.
| Deployment size | Minimum worker nodes | Minimum node vCPU | Minimum node RAM (GB) |
|---|---|---|---|
| Compact | 3 | 8 | 30 |
| Small | 4 | 8 | 30 |
| Medium | 4 | 8 | 30 |
| Large | 4 | 10 | 35 |
Important
The minimum worker node requirements listed are for single BMC Helix IT Service Management environment installation in a cluster. To setup multiple environments in a cluster, such as a nonproduction cluster, based on the number of environments, add the worker node requirements for each installation.
Database resource requirements
The following table lists the BMC Helix Innovation Suite database resource requirements:
Deployment Size | vCPU | RAM (GB) |
|---|---|---|
Compact (100 users maximum) | 10 | 20 |
Compact (200 users maximum) | 20 | 40 |
Small | 24 | 64 |
Medium | 40 | 64 |
Large | 64 | 80 |
Important
You must set up the database server outside the Kubernetes clusters on a physical or virtual machine.
BMC Helix ITSM Insights resource requirements
BMC Helix ITSM Insights
provides native AI Service Management capabilities with the BMC Helix Platform. BMC Helix ITSM Insights uses NLP (Natural Language Processing) and AI clustering algorithms to deliver use cases such as proactive problem management and real-time incident correlation.
ITSM Insights is an optional component for installation and the resource requirements listed below should be added to the overall infrastructure sizing requirements for your BMC Helix IT Service Management deployment. Sizing for ITSM Insights is based on data volumes rather than concurrent users.
Best practice
The following table lists the additional ITSM Insights resource requirements:
| Category | Concurrent users | Incidents per day | CPU (core) | RAM (GB) |
|---|---|---|---|---|
Compact | 10 | 1000 | 111 | 237 |
Small | 25 | 5000 | 132 | 315 |
Medium | 50 | 10000 | 158 | 409 |
Large | 100 | 15000 | 285 | 756 |
CPU requirements
The CPU size must be minimum 2.4 Gz.
Worker and master node disk requirements
Kubernetes master and worker nodes require the following free disk space allocation for container images:
Requirement | Value |
|---|---|
Worker and master nodes system disk | 150 GB each |
Persistent volume disk requirements
High performance of Kubernetes Persistent Volume Disk 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.
The disk requirement for Compact, Small, Medium, and Large deployment sizes is 1.7 TB.
We recommend that you use solid-state drive (SSD) with the following specifications:
| Specification | Value |
|---|---|
Write latency | 1 ms |
Read latency | 1 ms |
| Write Throughput | 30 MBPS |
| Read Throughput | 80 MBPS |
| IOPS Write | 20 K |
| IOPS Read | 7 K |
Comments
Log in or register to comment.