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’s performance testing is based on four different system usage profiles: compact, small, medium, and large.

The 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 is not a consideration. All compact systems cited on this page are non-high-availability deployments for BMC Helix Operations Management and the BMC Discovery . We recommend the compact sizing for a POC because it is a single-replica deployment.

If your usage exceeds the maximum numbers for the large sizing, contact BMC Support for guidance on how to size your infrastructure.

• Number of MIs (Monitored Instances) 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 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 cluste r. 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.

Note: 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 

• Profile: Medium
• Components:
  • BMC Helix Operations Management + Intelligent Integration + Intelligent Automation (Core Stack): 67 cores, 370 GB
  • BMC Helix AIOps + AutoAnomaly Add-On: 22 cores, 157 GB

• Total: 89 cores, 527 GB memory

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 BHCO

• Profile: Medium
• Components:
  • BMC Helix Operations Management + BMC Helix Intelligent Integration + BMC Helix Intelligent Automation (Core Stack): 67 cores, 370 GB
  • BMC Helix AIOps + AutoAnomaly Add-On: 22 cores, 157 GB
  • BMC Helix Continuous Optimization (Standalone): 38 cores, 180 GB

• Total: 127 cores, 707 GB memory

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.

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 table represents the minimum amount of computing resources that must be made available by the Kubernetes cluster to the BMC Helix IT Operations Management deployment:

Core stack requirements

BMC Helix AIOPs and Autoanomaly add-ons

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

BMC Helix Log Analytics add-ons

 BMC Helix Log Analytics can be deployed:

• As a standalone product, or
• As an add-on to BMC Helix Operations Management deployment.

Sizing requirements for BMC Helix Continuous Optimization

The following table provides the sizing requirements of BMC Helix Continuous Optimization standalone deployment. If BMC Helix Continuous Optimization is deployed alongside BHOM, ensure shared components (e.g., PCS, Infra) are counted only once.

​​​​