Sizing and scalability considerations


The sizing baselines specified are based on the performance lab benchmark test results performed in BMC Helix's test labs. You can use these baselines for your on-premises BMC Helix IT Operations Management (BMC Helix ITOM) deployment. 

The following applications were tested for BMC Helix ITOM sizing considerations:

  • BMC Helix Dashboards
  • BMC Helix Intelligent Automation
  • BMC Helix Developer Tools
  • BMC Helix Log Analytics
  • BMC Helix Operations Management
  • BMC Helix Portal
  • BMC Helix Service Monitoring (BMC Helix AIOps)
  • BMC Helix Continuous Optimization

Important

  • If you use a combination of some of the products such as BMC Helix Operations Management, BMC Helix Continuous Optimization, and BMC Helix IT Service Management in your environment, contact BMC Support for the sizing guidelines.

  • If you are deploying BMC Helix Operations Management in a multitenant environment, contact BMC Support for specific sizing guidelines.

BMC Helix’s performance testing is based on four different system usage profiles: compact, small, medium, and large.

ProfileDescription
CompactMinimal footprint for small-scale environments. 

Compact is a special sizing that is the minimum requirement for a functional BMC Helix Platform  system. Compact systems are recommended only for POC systems, where resilience and system performance under load are not a consideration. All compact systems cited on this page are non-high-availability deployments for BMC Helix Operations Management and BMC Discovery. We recommend the compact sizing for a POC because it is a single-replica deployment.

SmallSuitable for limited production workloads
MediumRecommended for standard enterprise deployments
LargeFor high-scale, high-throughput environments

Important

  • If your usage exceeds the maximum numbers for the large sizing, contact BMC Support for guidance on how to size your infrastructure.
  • In cases where usage parameters fall into different sizing categories, use the higher sizing category for all parameters to make sure that the system is provisioned to handle peak load conditions effectively.

Kubernetes infrastructure sizing requirements

Compute requirements are the combined requirements of CPU, RAM, and Persistent Volume Disk requirements for the Kubernetes worker nodes.   

These compute requirements are shared between all the worker nodes in your Kubernetes cluster. The worker nodes in your Kubernetes cluster must have CPU and RAM that matches or exceeds the total infrastructure sizing requirement plus the per worker node logging requirement. This is required to support the anticipated load for the benchmark sizing category for a BMC Helix IT Operations Management deployment.  

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

  • Kubernetes management software requirements

  • Host operating system 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.

Calculate Your Deployment Sizing

  1. Select your profile size (Compact, Small, Medium, Large).

  2. Identify the product components you plan to deploy.

  3. Use the sizing tables to sum the CPU and memory requirements for each component.

  4. If deploying multiple components, add their values together.

  5. Do not attempt to deduct shared infrastructure like BMC Helix Platform Common Services and Infra services, unless you have explicit sizing data for those components.

The sizing tables for BMC Helix Operations Management and BMC Helix Continuous Optimization are designed to reflect the full load of each product, including shared services. When combining BMC Helix Operations Management and BMC Helix Continuous Optimization, the total sizing already accounts for the infrastructure needed to support both products. Therefore, reducing or subtracting shared components may result in under-provisioning and is not recommended.

In such cases:

  • Use the larger profile between the two products.

  • Add the CPU and memory values from each table without deduction.

  • If your deployment is resource-constrained or highly customized, contact BMC Support for optimization guidance.

Important

The sizing tables are intentionally conservative to ensure performance and scalability. Overestimating slightly is preferable to underestimating.

Example 1: BMC Helix Operations Management and BMC Helix AIOps Deployment 

This configuration excludes Log Analytics and BMC Helix Continuous Optimization. Use this when deploying the core BMC Helix IT Operations Management stack with BMC Helix AIOps capabilities.

Example 2: Full Stack Deployment with BMC Helix Continuous Optimization

Example 3: BMC Helix Continuous Optimization (Standalone)

When deploying BMC Helix Operations Management and BMC Helix Continuous Optimization together, do not attempt to subtract shared infrastructure (BMC Helix Platform Common Services and Infra services). The sizing tables already account for the full load of each product. Use the larger profile and sum the values conservatively to ensure performance.

Sizing parameters and respective profile values

The following table provides information about the sizing parameters and their profile values: 

ParametersCompactSmallMediumLarge

Total number of devices.
Includes PATROL Agents and/or custom devices.

Important: Make sure that you do not exceed the number of monitored instances per device. 

100

 

3,000

 

7,500

 

15,000

 

Monitored instances (Other sources, such as Prometheus and Rest API)

1,000

100,000

250,000

500,000

Number of monitored instances per device
For more information, see Number of Monitored Instances (MIs) per device.

10

33

33

33

Monitored attributes (Other sources, such as Prometheus and Rest API)

10,000

600,000

1,500,000

3,000,000

Number of Attributes per device
For more information, see Number of Attributes per device.

100

200

200

200

Events per day (Alarm, Anomalies and External Events)

5,000

30,000

75,000

1,500,000

Configuration policies
For more information, see Configuration policies.

100

1,000

1,500

10,000

Number of policies per device

1

2

2

2

Number of groups up to

50

1,500

2,500

4,500

Number of concurrent users

5

50

100

150

BMC Helix AIOps

Services

25

500

1,000

3,000

Situations

10

300

500

1,000

BMC Helix Continuous Optimization

Ingestion of samples per day in million

50 mil

50 mil

100 mil

500 mil

BMC Helix Log Analytics

Log ingestion per day

Important: BMC has certified 250 connectors for a single tenant.

500 MB

30 GB

100 GB

250 GB

Number of Logstash

1

5

10

50

Number of days for retention

3

3

3

3

  • Number of Monitored Instances (MIs) per device:
    The values shown are based on internal standard benchmarks and may appear consistent across Small, Medium, and Large, but in practice, the number of MIs per device varies from agent to agent depending on the type and complexity of the monitored device.
    As a reference, an agent can support up to 40,000 MIs. The current number (33 MIs per device) is a standardized baseline we use internally for sizing calculations, and it reflects a conservative estimate derived from real-world deployments.
  • Number of Attributes per device:
    Similar to MIs, this number is standardized based on internal data. While actual numbers may vary, 200 attributes per device is a safe average used for capacity planning purposes.
  • Configuration Policies:
    The configuration policies include:
    • Monitoring policies
    • Alarm policies
    • Event policies
    • Blackout policies
    • Multivariate policies
  • Example of a Monitoring Instance (MI):
    A Monitoring Instance refers to an individual metric or component being monitored—such as CPU usage, memory, disk partition, or interface status. For example, if a device has CPU, memory, and two disks being monitored, it would result in 4 MIs.

 

Kubernetes cluster requirements

The application must have specific hardware resources made available to it for successful deployment and operation. Any competing workloads (such as your Kubernetes management or monitoring software) on the cluster and host operating system requirements must be considered in addition to the BMC Helix IT Operations Management suite requirements when building your Kubernetes cluster.

The following are the deployment categories for Kubernetes cluster requirements:

  • Kubernetes cluster requirements for BMC Helix Operations Management
  • Additional Kubernetes cluster requirements for BMC Helix AIOPs and Autoanomaly with BMC Helix Operations Management
  • Additional Kubernetes cluster requirements for BMC Helix Log Analytics with BMC Helix Operations Management
  • Kubernetes cluster requirements for BMC Helix Continuous Optimization
  • Additional Kubernetes cluster requirements for BMC Helix Continuous Optimization with BMC Helix Operations Management ​​​​

Important

By default, the sizing for BMC Helix Operations Management includes the sizing for BMC Helix Intelligent Integration, BMC Helix Intelligent Automation, BMC Helix Platform Common Services, and BMC Helix Dashboards.

Kubernetes cluster requirements for BMC Helix Operations Management

The following table represents the minimum amount of computing resources that must be made available by the Kubernetes cluster to the BMC Helix Operations Management deployment:

Deployment sizeCPU (Core)RAM (GB)
Compact28182
Small78401
Medium99580
Large266

1,350

Additional Kubernetes cluster requirements for BMC Helix AIOPs and Autoanomaly with BMC Helix Operations Management

This must be added on top of BMC Helix Operations Management deployment.

Deployment sizeCPU (Core)RAM (GB)
Compact435
Small1298
Medium22157
Large62

326

Additional Kubernetes cluster requirements for BMC Helix Log Analytics with BMC Helix Operations Management

​BMC Helix Log Analytics can be deployed:

  • As a standalone product, or
  • As an add-on to BMC Helix Operations Management deployment.
Deployment sizeCPU (Core)RAM (GB)
Compact235
Small1046
Medium1154
Large25

92

Kubernetes cluster requirements for BMC Helix Continuous Optimization

BMC Helix Continuous Optimization includes the sizing for BMC Helix Platform Common Services. The following table represents the minimum amount of computing resources that must be made available by the Kubernetes cluster to the BMC Helix Continuous Optimization deployment:

Deployment sizeCPU (Core)RAM (GB)
Small108464
Medium130643
Large2991,468

Additional Kubernetes cluster requirements for BMC Helix Continuous Optimization with BMC Helix Operations Management

When determining sizing requirements for (BHCO) and BMC Helix Operations Management (BHOM), first identify the sizing categories for each. If your BMC Helix Continuous Optimization category is the same as or one size smaller than your BMC Helix Operations Management category, you can add the requirements for BMC Helix Continuous Optimization to those of BMC Helix Operations Management in the table below. If the sizing category of BMC Helix Operations Management is small and the sizing category of BMC Helix Continuous Optimization is medium, you must deploy BMC Helix Operations Management with a medium sizing category. 

For example, if you use the small sizing category (78 Core) for BMC Helix Operations Management and want to use the medium sizing category (135 Core) of BMC Helix Continuous Optimization, you must replace the sizing category of BMC Helix Operations Management with medium, that is, 99 Core.

Important

BMC Helix Continuous Optimization must not be more than one size category smaller than BMC Helix Operations Management, and the BMC Helix Operations Management category must not be smaller than the BMC Helix Continuous Optimization category.

The following table represents the minimum amount of computing resources that must be made available by the Kubernetes cluster to the BMC Helix Operations Management and BMC Helix Continuous Optimization deployment:

Deployment sizeCPU (Core)RAM (GB)
Small60123
Medium135253
Large193817

​​​​

Kubernetes quotas

Quotas may be set up on a cluster namespace to enforce maximum scheduled requests and limits. Setting quotas below what the application needs will result in deployment scheduling failures and ultimately lead to deployment issues. This is particularly important during the software installation and upgrade, which will require at least the specified quotas mentioned in this document.

The following are the deployment categories:

  • Kubernetes quota requirements for BMC Helix Operations Management
  • Additional Kubernetes quota requirements for BMC Helix AIOPs and Autoanomaly with BMC Helix Operations Management
  • Additional Kubernetes quota requirements for BMC Helix Log Analytics with BMC Helix Operations Management
  • Kubernetes quota requirements for BMC Helix Continuous Optimization
  • Additional Kubernetes quota requirements for BMC Helix Continuous Optimization with BMC Helix Operations Management

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.
  • By default, the sizing for BMC Helix Operations Management includes the sizing for BMC Helix Intelligent Integration, BMC Helix Intelligent Automation, BMC Helix Platform Common Services, and BMC Helix Dashboards.

Kubernetes quota requirements for BMC Helix Operations Management

The following table shows the recommended settings to allow a BMC Helix Operations Management ​​​​​suite deployment:

Deployment SizeCPU requests 
(Millicore)

CPU limits
(Millicore)

MEM requests
GB
MEM limits
GB
Compact23,354118,496118250
Small59,774202,870245445
Medium70,514263,846378667
Large186,984467,6469601,309

Additional Kubernetes quota requirements for BMC Helix AIOPs and Autoanomaly with BMC Helix Operations Management

The following table shows the recommended settings to allow BMC Helix AIOPs and Autoanomaly add-ons:

Deployment SizeCPU requests 
(Millicore)

CPU limits
(Millicore)

MEM requests
GB
MEM limits
GB
Compact3,97024,9503560
Small12,350 65,250 98157
Medium21,750 98,150 157276
Large61,700 184,500 326485

Additional Kubernetes quota requirements for BMC Helix Log Analytics with BMC Helix Operations Management

The following table shows the recommended settings to allow  BMC Helix Log Analytics add-ons:

Deployment SizeCPU requests 
(Millicore)

CPU limits
(Millicore)

MEM requests
GB
MEM limits
GB
Compact2,15019,0003560
Small10,15033,1004784
Medium10,60042,50054113
Large25,00065,50093169

Kubernetes quota requirements for BMC Helix Continuous Optimization

BMC Helix Continuous Optimization includes the sizing for BMC Helix Platform Common Services. The following table shows the recommended settings to allow a BMC Helix Continuous Optimization​​ suite deployment:

Deployment SizeCPU requests (Millicore)CPU limits (Millicore)Memory requests GBMemory limit GB
Small55,470182,400222412
Medium71,620294,900361646
Large162,440474,1508621,663

Additional Kubernetes quota requirements for BMC Helix Continuous Optimization ​​​​​​with BMC Helix Operations Management

The following table shows the recommended settings to allow BMC Helix Continuous Optimization with BMC Helix Operations Management suite deployment:

Deployment SizeCPU requests 
(Millicore)

CPU limits
(Millicore)

MEM requests
GB
MEM limits
GB
Small3,83060,00035123
Medium16,580135,00090253
Large22,350193,000158817

Kubernetes node requirements

Your cluster must maintain a minimum number of worker nodes to provide an HA-capable 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. This way, if a worker node goes down you will maintain the minimum number of resources required in the cluster to recover the application.
For example: If you have 4 nodes of 10 vCPU and 50GB RAM, you will need a 5th node of 10 vCPU and 50GB RAM to not have recovery impacted by the loss of one 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 SizeMinimum worker nodes available
Compact4
Small6
Medium6
Large9

Worker node disk requirements

Kubernetes worker nodes require the following free disk space allocation for container images:

Requirement

Value

Worker node system disk

At least 150 GB

Pod specifications

The BMC Helix ITOM Pod specifications spreadsheet provides detailed information for sizing your environment. Cluster architects can use the information to help determine the node sizes and cluster width.

Consider the following resource requirements of the largest pod:

  • In a large deployment, the largest pod requires 13 CPUs and 34 GB of RAM.
  • In a medium deployment, the largest pod requires 7 CPUs and 17 GB of RAM.
  • In a small deployment, the largest pod requires 7 CPUs and 8 GB of RAM.
  • In a compact deployment, the largest pod requires 3 CPUs and 7 GB of RAM.

When reviewing the specification spreadsheet, pay attention to workloads with high replica counts. Make sure your cluster has enough nodes (cluster width) to schedule all replicas without resource contention.

Persistent volume requirements

The high performance of Kubernetes Persistent Volume Disk is essential for the overall system performance. BMC supports a Bring-Your-Own-Storage class for Kubernetes persistent volumes.

Important

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

The following table shows the disk requirements in Block Storage (GB):

Deployment SizeBlock Storage (GB)
Compact  2,454
Small  4,842
Medium  7,102
Large  23,242​​​

The following table shows the disk requirements in Read Write Many Storage (GB):

Deployment SizeRead Write Many Storage (GB)
Compact  91
Small  91
Medium  91
Large  91

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

Block Storage SSD Recommendations

Specification  

Compact  

Small  

Medium  

Large  

Average latency  

< 100 ms  

< 100 ms  

< 100 ms  

< 100 ms  

Write throughput  

20 MB/s  

150 MB/s  

165 MB/s  

200 MB/s  

Read throughput  

100 MB/s  

800 MB/s  

1 GB/s  

1.2 GB/s  

IOPS Write  

1K  

3K  

3.2K  

3.5K  

IOPS Read  

3K  

10K  

11K  

12K  

Read, Write, and Many (RWM) throughput and Input/Output Operations Per Second (IOPS) requirements:  

Specification  

Value  

Read throughput  

10 MBPS  

Write throughput  

5 MBPS  

IOPS Read  

3K  

IOPS Write  

1K  

Sizing guidelines for BMC Discovery 

BMC Discovery is deployed externally to the cluster as an appliance. The following table shows the additonal requirements to allow BMC Discovery deployment:

Deployment Size

CPU

RAM (GB)

Disk (GB)

Number of servers per environment

Compact (not in high availability)

4

8

100

1

Small

16

32

300

3

Medium

16

32

500

3

Large

20

64

1,000

5

For BMC Discovery sizing guidelines, refer to the Sizing and scalability considerations topic in the BMC Discovery documentation.

BMC Helix Logging (EFK) stack requirements

Use BMC Helix Logging to collect, store, and view logs by using Elasticsearch, Fluent Bit, and Kibana (EFK). Deploying the BMC Helix Logging stack comes with additional hardware requirements that the Kubernetes cluster must be able to provide as well as the expected namespace quotas. For more information, Preparing to collect logs from external log sources. The following table shows the additional stack requirements to allow BMC Helix Logging deployment:

Deployment sizeCPU (Core)RAM (GB)PVC (with 3 days retention)
Compact219200 GB
Small619500 GB
Medium10201,100 GB
Large12

31

2,100 GB

BMC Helix Logging (EFK) stack quota requirements

The following table shows the additional stack quota requirements to allow BMC Helix Logging deployment:

Deployment size

CPU Requests
(Millicore)

MEM Requests (GB)CPU Limits (Millicore)MEM Limits (GB)
Compact1,6001011,50023
Small1,6001014,50023
Medium2,2001016,50023
Large7,2803132,50035

FluentBit Daemonset

The Helix logging stack utilizes FluentBit collectors as a daemonset to access logs on the worker nodes. Requirements for the collectors are in addition to the previous requirements and depend on the number of worker nodes that are in the cluster. Use the table below to determine the size of the pod in your deployment and multiply the requirements by the number of pods in your cluster. The cluster will additionally require the value of requests calculated.

Deployment sizeCPU Requests
(Millicore)
CPU Limits (Millicore)MEM Requests (GB)MEM Limits (GB)
Compact50600.150.18
Small50600.150.18
Medium2102500.150.18
Large2102500.280.32

​​For example, to get the total quota value, multiply your worker node count with a value in Fluent Bit Daemonset table, and add a value in the EFK Logging Quota table.

Assume that you have 4 worker nodes in your compact size cluster. Your total CPU requests quota calculation will be:

4 * 50 + 1,600 = 1,800 (Millicore)

Similarly, you can do the calculation for memory requests. 

Disaster recovery requirement

If you enable disaster recovery, you will need 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): 

Deployment size 

CPU (Core)  

RAM (GB)  

MinIO storage per PVC

Total MinIO storage requirement (4 PVC)

Compact  

6

30

900

3,600

Small  

10 

38  

1,050

4,200

Medium  

11

49

2,225

8,900

Large  

12

62

10,625

42,501

Important

  • The values in the table provide information about the resources required to store data for a single day.
  • To retain data for more than a day, multiply the resource requirement (R) by the number of days (N) you want to retain it. For example, if you use a large deployment size and want to keep PVC data for three days, you will need 26,700 GB (8,900 x 3).

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

BMC Helix IT Operations Management Namespace Quotas (DR Additions)  

Deployment size  

 CPU Requests (Millicore)  

CPU Limits (Millicore)  

MEM Requests (GB)  

MEM Limits (GB)  

Compact  

6,000  

26,000

30

85  

Small  

10,000  

30,000  

38

86

Medium  

11,000

36,000  

49 

91

Large  

12,000

55,000  

62 

112

RPO and RTO measurements 

Recovery Point Objective (RPO) is the time-based measurement of tolerated data loss. Recovery Time Objecting (RTO) is the targeted duration between an event failure and the point where the operations resume.  

The following table lists the RPO and RTO measurements:

Deployment size

Recovery Point Objective (RPO) 

Recovery Time Objecting (RTO)

Loss in productivity

Compact

24 hours 

1 hour 30 minutes

3 hours

Small

24 hours 

1 hour 30 minutes

3 hours

Medium

24 hours

2 hours

4 hours 

Important

  • You will need the bootstrap timing when you start the first full backup. You must use the information from the next full backup to calculate the RPO numbers. Full backups are performed every 24 hours. 
  • The RPO, RTO, and backup storage size might vary based on the storage size of your stack's data lake.
  • We recommend you perform a trial run of your disaster recovery operation to give you personalized expectations of how your setup and environment will measure at RPO and RTO metrics.

Sizing considerations for migrating from PostgreSQL database 15.x to 17.x

To migrate data from PostgreSQL database 15.9 to 17.x you must run the PostgreSQL migration utility. Starting with the BMC Helix IT Operations Management version 25.2, we only support PostgreSQL database version 17.x.

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

Deployment size  

CPU (Core) request 

MEM (Gi) Requests  

CPU (Cores) Limits  

MEM (Gi) Limits

PVC (Gi)

Compact  

4

5

13

33

140

Small  

4

6

13

35

140

Medium  

4

6

21

34

195

Large  

7

8

60

115

250

You can reclaim the resources after the upgrade.

The following table gives information about the time to migrate data from PostgreSQL database 15.x to 17.x:

Deployment size  

Time taken (Minute) 

Compact  

7

Small  

11

Medium  

36

Large  

22

​​​​

Sizing requirements to configure the Self-monitoring solution

Self-monitoring refers to the system's ability to monitor its own infrastructure health, performance, and availability. The sizing requirements to set up the monitoring solution for your BMC Helix IT Operations Management environment are as follows:

  • To accommodate BMC Helix Monitoring Agents, the following additional resources are needed in the production cluster:
    • Memory: 8 GB
    • CPU: 2500 Millicore
       

 

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