This documentation supports an earlier version of BMC Helix IT Service Management on-premises deployment.

To view the documentation for the latest version, select 22.1.06 from the Product version picker.

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 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 Service Management in a multitenant BMC Helix Platform environment.
  • If you are deploying multiple containerized products such as BMC Helix 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 Open link in the BMC Helix IT Operations Management deployment documentation.

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 usersrepresent the number of users that are logged in and actively working on a system across each of the following BMC Helix Service Management applications that are hosted on a single deployment of BMC Helix 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 usersare 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 sizeResilient concurrent usersMaximum concurrent users
Compact
Not applicable200
Small200400
Medium400800
Large8001750


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 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 sizeMinimum worker nodesMinimum node vCPUMinimum node RAM (GB)
Compact3830
Small4830
Medium4830
Large41035

Important

The minimum worker node requirements listed are for single BMC Helix 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 Open link 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 Service Management deployment. Sizing for ITSM Insights is based on data volumes rather than concurrent users.

Best practice

BMC recommends that you use the matching category for your overall deployment. For example, if you have a Large size BMC Helix Service Management deployment you must use the Large ITSM Insights category, even if your concurrent users are below the maximum supported.

The following table lists the additional ITSM Insights resource requirements:

CategoryConcurrent usersIncidents per day

CPU (core)

RAM (GB)

Compact

101000

111

237

Small

255000

132

315

Medium

5010000

158

409

Large

10015000

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:

SpecificationValue

Write latency

1 ms

Read latency

1 ms

Write Throughput30 MBPS
Read Throughput80 MBPS
IOPS Write20 K
IOPS Read7 K


Was this page helpful? Yes No Submitting... Thank you

Comments