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 IT 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 and scalability considerations 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 users—represent the number of users who are logged in and actively working on a system across each of the following 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 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

1800

Extra large

1250

2500

 The following table lists the supported deployment sizes for BMC Helix ITSM Insights, including the number of concurrent users and the incidents per day that each size can handle:

Deployment size

Concurrent users

Incidents per day

Compact

10

1000

Small

25

5000

Medium

50

10000

Large

100

15000

Extra large

200

20000

Important

Compact is the deployment size for nonproduction environments and does not support High Availability (HA).

Considerations when building a Kubernetes cluster

There are several considerations when building a Kubernetes cluster regarding sizing before considering the application requirements. The application requirements are meant to be included in addition to your other resource requirements. This could include but not be limited to:

  • Kubernetes control plane nodes
  • Host operating system requirements of worker nodes
  • Kubernetes management software requirements
  • Additional software (for example: monitoring software) that is deployed on the cluster

It is important to refer to your distributors and vendors to make sure additional requirements are also included in any cluster planning.

Kubernetes cluster requirements

For a successful deployment and operation of BMC Helix Service Management, with and without BMC Helix ITSM Insights, make sure that specific hardware resources are available to all applications.

The following table lists the minimum amount of available compute resource requirements for the Service Management applications with BMC Helix Platform Common Services:   

Deployment size

Required vCPU

RAM (GB)

Compact

25

126

Small

36

204

Medium

37

252

Large

49

274

Extra large

68

443

Kubernetes cluster requirements with BMC Helix ITSM Insights

BMC Helix ITSM Insights provides native AI Service Management capabilities as part of the BMC Helix Platform. It uses Natural Language Processing (NLP) and AI clustering algorithms to support use cases such as proactive problem management and real-time incident correlation.

Installation of BMC Helix ITSM Insights is optional. However, if installed, make sure that the following requirements are met. These requirements are based on data volumes rather than concurrent users.

Best practice
We recommend 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: 

Deployment size

Required vCPU

RAM (GB)

Compact

4

36

Small

22

64

Medium

29

95

Large

33

82

Extra large

29

95

BMC HelixGPT requirements

If you plan to deploy BMC HelixGPT, ensure that your Kubernetes cluster includes the following additional resource allocations. These requirements are separate from the overall Kubernetes cluster sizing recommendations and must be accounted for to support BMC HelixGPT services.

Deployment size

Required vCPU

RAM (GB)

Compact

0.05

2

Small

0.05

2

Medium

0.05

2

Large

0.05

2

Extra large

0.05

2

Important

These additional BMC HelixGPT-specific resources must be available in the cluster in addition to the base resource requirements for the BMC Helix Service Management.

Kubernetes quotas

Set up quotas on the cluster namespaces to enforce maximum scheduled requests and limits. If you schedule additional workloads beyond the configured quotas, the Kubernetes cluster might prevent the scheduling and affect operations in the namespace.

Important

To avoid issues related to scaling and consumption of microservices, it's important to follow recommended namespace quota settings based on your deployment size.

The following table lists the recommended settings:

BMC Helix Service Management namespace quotas 

Deployment size

CPU requests

(milli core) 

CPU limits

(milli core) 

Memory requests

(GB) 

Memory limits

(GB) 

Compact 

11,270105,948

62

238

Small 

20,850193,698

127

433

Medium 

21,320

232,698

176

534

Large 

33,620

252,798

198

556

Extra large

49,820

277,798

307

680

BMC Helix Platform namespace quotas

Deployment size

CPU requests

(milli core) 

CPU limits

(milli core) 

Memory requests

(GB) 

Memory limits

(GB) 

itsmcompact 13,220

62,700

63

132

itsmsmall 14,72087,000

76

156

itsmxlarge17,630105,050136

275

Kubernetes quotas with BMC Helix ITSM Insights

The following table lists the additional recommended settings for environments with BMC Helix ITSM Insights:

BMC Helix Service Management namespace quotas 

Deployment size

CPU requests

(milli core) 

CPU limits

(milli core) 

Memory requests

(GB) 

Memory limits

(GB) 

Compact 

2,0002,500

6

2

Small 

13,5006,000

6

6

Medium 

20,760

7,000

36

31

Large 

24,560

9,000

24

20

Extra large

16,160

5,000

16

24

BMC Helix Platform namespace quotas

Deployment size

CPU requests

(milli core) 

CPU limits

(milli core) 

Memory requests

(GB) 

Memory limits

(GB) 

itsmcompact 1,800

5,800

30

74

itsmsmall 8,51016,150

58

146

itsmxlarge12,40026,10079

169

Use the BMC Helix Platform itsmcompact deployment size with BMC Helix Service Management Compact size. You can use the BMC Helix Platform itsmsmall size with BMC Helix Service Management Small, Medium, and Large sizes. Use the BMC Helix Platform itsmxlarge size with BMC Helix Service Management Extra Large size.

Kubernetes node requirements

Make sure that your cluster maintains a minimum number of worker nodes to provide a high availability environment for the application data lakes. 

To support the loss of worker nodes in your cluster, you must provide extra worker nodes with resources equal to your largest worker node. As a result, if one worker node goes down, you will still maintain the minimum number of resources required to recover the application.

For example, if you have six worker nodes of 10 vCPU and 50 GB RAM, you will need a 7th worker node of 10 vCPU and 50 GB RAM to recover an application without having any impact due to the loss of a worker node. 

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

Compact

4

Small

6

Medium

6

Large

6

Extra large

6

For details regarding the specifications of the pod, refer to the Pod Specifications section.

Database resource requirements

The following table lists the BMC Helix Innovation Suite database resource requirements:

Important

Database resources are significantly dependent on integrations and customizations. Even with a small number of users, the resource requirement numbers can increase.

If you are migrating from Remedy on-premises to BMC Helix Service Management, we recommend using your existing database size.

The recommendations are for a fresh installation of BMC Helix Service Management. However, the requirements can increase based on the nonuser based usage.

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

Extra large

80

160

Important

You must set up the database server outside the Kubernetes clusters on a physical or virtual machine.

Persistent volume 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. 

Important

Your storage class for the Kubernetes persistent volumes must support volume expansion and dynamic provisioning.

The following tables lists the disk requirements:

Deployment size

Block storage (GB)

Compact

1400

Small

1700

Medium

1700

Large

1700

Extra large

2500

We recommend that you use solid-state drive (SSD) with the following specifications:

Specification 

Deployment size

Compact 

Small 

Medium 

Large 

Extra large

Average latency 

< 100ms 

< 100ms  

< 100ms 

< 100ms  

< 100ms 

Write throughput 

20 MB/s 

150 MB/s 

165 MB/s 

200 MB/s 

200 MB/s 

Read throughput 

100 MB/s 

800 MB/s 

1 GB/s 

1.2 GB/s 

1.2 GB/s 

IOPS Write 

1K 

3K 

3.2K 

3.5K 

3.5K 

IOPS Read 

3K 

10K 

11K 

12K 

12K 

Multi-instance deployments

BMC Helix Service Management supports multi-instance deployments. You can deploy new instances of BMC Helix Service Management in multiple namespaces that utilize the same BMC Helix Platform.
For multi-instance deployments, consider the following points:

  • Load profile requirements are the combined requirements of BMC Helix Service Management and BMC Helix Platform Common Services load profiles. 
    If your requirements exceed a combined load profile, contact BMC Support to confirm the required cluster resources.

  • Disk space requirements are increased by approximately 250 GB times the number of instances connecting to the BMC Helix Platform.
    This number might vary depending on the individual instances. 
  • Cluster resource requirements are in addition to the BMC Helix Service Management namespace and BMC Helix Platform namespace quota.
  • Database requirements are the combined requirements based on the deployment size.

CPU requirements

The CPU speed must be 2.4 GHz or higher.

Worker and master node disk requirements

Kubernetes master and worker nodes require a free disk space allocation of 150 GB each for container images.

 Pod specifications

To determine the appropriate pod specifications for your environment, refer to the following Pod specification spreadsheets:

Cluster architects can use the information to help determine the node sizes and cluster width.

When reviewing the specification spreadsheet, check the large replica counts to ensure that your cluster width is sufficient.

BMC Helix Logging (EFK) requirements

To maintain performance and reliability of the logging infrastructure, it’s important to size the EFK stack based on your deployment size.

Important
  • The cluster used for sizing had a minimum of 4 nodes; therefore, the efk-fluent-bit DaemonSet ran with 4 replicas. The actual number of replicas depends on the number of nodes in your environment.
  • The EFK configurations listed below are based on settings from the previous version.

The following table provides the recommended resource requests and limits for different deployment sizes:

BMC Helix Logging quotas 

Deployment size

CPU requests

(milli core) 

CPU limits

(milli core) 

Memory requests

(MB) 

Memory limits

(MB) 

Compact 

5807,300

6,208

16,384

Small 

58012,300

7,168

19,456

Medium 

58012,3007,16819,456

Large 

58012,3007,16819,456

Extra large

85017,3007,16819,456

Disaster recovery requirement

If you enable disaster recovery, you will need an additional processor, memory, and disk space to operate successfully. The following guidance is based on using the default disaster recovery configurations. Any modification to these settings might impact the amount of disk storage that is necessary and must be recalculated.   
The following tables list the additional resources required in the Kubernetes cluster (per data center):  

Category  

vCPU 

RAM (GB)  

PVC (GB)  

Compact  

5  

10  

500 

Small  

9  

16  

500 

Medium  

9  

16  

500 

Large  

9  

16  

500 

Extra large

9

16

1000

The following tables list the additional recommendations to add to the namespace quotas (per data center):  

BMC Helix Service Management Namespace Quotas (DR Additions)  

Category  

CPU requests (milli core)  

CPU limits (milli core)  

Memory requests (GB)  

Memory limits (GB)  

Compact  

5100  

12200  

10  

26  

Small  

8400  

25400  

16 

53 

Medium  

8400  

25400  

16 

53 

Large  

8400  

25400  

16 

53 

Extra large

8400

25400

16

53

Sizing guidelines to upgrade BMC Helix Platform Common Services

When you upgrade to BMC Helix Platform Common Services version, consider the following additional resource requirements:

Sizing considerations for migrating from Open Distro to OpenSearch

If you are upgrading BMC Helix Platform Common Services version from 25.1.00 to 25.2.00, consider the following additional resource requirements for migrating the PostgreSQL database.

To migrate data from PostgreSQL database 15.x to 17.x you must run the PostgreSQL migration utility.

For the migration to be successful, in addition to the resources listed in this topic, the following processor, memory, and storage are required.

Kubernetes quotas requirements

The following table lists additional quota requirements for Postgres 15.x to 17.x migration:

Category

CPU (milli core) requests

MEM (Gi) requests

CPU (milli core) limits

MEM (Gi) limits

Compact  

2000

5.5

9000

14.5

Small  

2000

5.5

900014.5

Medium  

2000

5.5

900014.5

Large  

2000

5.5

900014.5

Extra Large

2000

5.5

900020.5

Kubernetes cluster requirements

The following table lists additional Kubernetes cluster hardware requirements for Postgres 15.x to 17.x migration:

Category

Required vCPU

RAM (GB)

PVC (GB)

Compact  

2

5.5

90

Small  

2

5.5

90

Medium  

2

5.5

90

Large  

2

5.5

90

Extra Large

2

5.5

90

You can reclaim the resources after the upgrade.

 

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*