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
BMC Helix’s performance testing is based on four different system usage profiles: compact, small, medium, and large.
| Profile | Description |
| Compact | Minimal 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. |
| Small | Suitable for limited production workloads |
| Medium | Recommended for standard enterprise deployments |
| Large | For high-scale, high-throughput environments |
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
Select your profile size (Compact, Small, Medium, Large).
Identify the product components you plan to deploy.
Use the sizing tables to sum the CPU and memory requirements for each component.
If deploying multiple components, add their values together.
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.
Example 1: BMC Helix Operations Management and BMC Helix AIOps Deployment
Profile: Small
Components:
BMC Helix Operations Management (Core Stack): 78 cores, 401 GB. For more information, see Kubernetes cluster requirements for BMC Helix Operations Management.
BMC Helix AIOps + Autoanomaly Add-On: 12 cores, 98 GB. For more information, see Additional Kubernetes cluster requirements for BMC Helix AIOPs and Autoanomaly.
Total: 90 cores, 499 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 BMC Helix Continuous Optimization
Profile: Medium
Components:
BMC Helix Operations Management (Core Stack) + BMC Helix Continuous Optimization: 135 cores, 253 GB. For more information, see Kubernetes cluster requirements for BMC Helix Continuous Optimization with BMC Helix Operations Management.
BMC Helix Log Analytics: 11 cores, 54 GB. For more information, see Additional Kubernetes cluster requirements for BMC Helix AIOPs and Autoanomaly.
Total: 146 cores, 307 GB memory
Example 3: BMC Helix Continuous Optimization (Standalone)
Profile: Small
Components:
BMC Helix Continuous Optimization (Standalone): 108 cores, 464 GB. For more information, see Kubernetes cluster requirements for BMC Helix Continuous Optimization.
Total: 108 cores, 464 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.
Sizing parameters and respective profile values
The following table provides information about the sizing parameters and their profile values:
| Parameters | Compact | Small | Medium | Large |
Total number of 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 | 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 | 100 | 200 | 200 | 200 |
Events per day (Alarm, Anomalies and External Events) | 5,000 | 30,000 | 75,000 | 1,500,000 |
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
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 size | CPU (Core) | RAM (GB) |
| Compact | 28 | 182 |
| Small | 78 | 401 |
| Medium | 99 | 580 |
| Large | 266 | 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 size | CPU (Core) | RAM (GB) |
| Compact | 4 | 35 |
| Small | 12 | 98 |
| Medium | 22 | 157 |
| Large | 62 | 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 size | CPU (Core) | RAM (GB) |
| Compact | 2 | 35 |
| Small | 10 | 46 |
| Medium | 11 | 54 |
| Large | 25 | 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 size | CPU (Core) | RAM (GB) |
| Small | 108 | 464 |
| Medium | 130 | 643 |
| Large | 299 | 1,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.
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 size | CPU (Core) | RAM (GB) |
| Small | 60 | 123 |
| Medium | 135 | 253 |
| Large | 193 | 817 |
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
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 Size | CPU requests (Millicore) | CPU limits | MEM requests GB | MEM limits GB |
| Compact | 23,354 | 118,496 | 118 | 250 |
| Small | 59,774 | 202,870 | 245 | 445 |
| Medium | 70,514 | 263,846 | 378 | 667 |
| Large | 186,984 | 467,646 | 960 | 1,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 Size | CPU requests (Millicore) | CPU limits | MEM requests GB | MEM limits GB |
| Compact | 3,970 | 24,950 | 35 | 60 |
| Small | 12,350 | 65,250 | 98 | 157 |
| Medium | 21,750 | 98,150 | 157 | 276 |
| Large | 61,700 | 184,500 | 326 | 485 |
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 Size | CPU requests (Millicore) | CPU limits | MEM requests GB | MEM limits GB |
| Compact | 2,150 | 19,000 | 35 | 60 |
| Small | 10,150 | 33,100 | 47 | 84 |
| Medium | 10,600 | 42,500 | 54 | 113 |
| Large | 25,000 | 65,500 | 93 | 169 |
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 Size | CPU requests (Millicore) | CPU limits (Millicore) | Memory requests GB | Memory limit GB |
|---|---|---|---|---|
| Small | 55,470 | 182,400 | 222 | 412 |
| Medium | 71,620 | 294,900 | 361 | 646 |
| Large | 162,440 | 474,150 | 862 | 1,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 Size | CPU requests (Millicore) | CPU limits | MEM requests GB | MEM limits GB |
| Small | 3,830 | 60,000 | 35 | 123 |
| Medium | 16,580 | 135,000 | 90 | 253 |
| Large | 22,350 | 193,000 | 158 | 817 |
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.
| Deployment Size | Minimum worker nodes available |
|---|---|
| Compact | 4 |
| Small | 6 |
| Medium | 6 |
| Large | 9 |
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 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.
The following table shows the disk requirements in Block Storage (GB):
| Deployment Size | Block 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 Size | Read 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 size | CPU (Core) | RAM (GB) | PVC (with 3 days retention) |
| Compact | 2 | 19 | 200 GB |
| Small | 6 | 19 | 500 GB |
| Medium | 10 | 20 | 1,100 GB |
| Large | 12 | 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 | MEM Requests (GB) | CPU Limits (Millicore) | MEM Limits (GB) |
|---|---|---|---|---|
| Compact | 1,600 | 10 | 11,500 | 23 |
| Small | 1,600 | 10 | 14,500 | 23 |
| Medium | 2,200 | 10 | 16,500 | 23 |
| Large | 7,280 | 31 | 32,500 | 35 |
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 size | CPU Requests (Millicore) | CPU Limits (Millicore) | MEM Requests (GB) | MEM Limits (GB) |
|---|---|---|---|---|
| Compact | 50 | 60 | 0.15 | 0.18 |
| Small | 50 | 60 | 0.15 | 0.18 |
| Medium | 210 | 250 | 0.15 | 0.18 |
| Large | 210 | 250 | 0.28 | 0.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 |
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 |
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:
A Windows VM for BMC Discovery Outpost. For more information, see BMC Discovery Outpost system requirements in the BMC Discovery documentation.
- To accommodate BMC Helix Monitoring Agents, the following additional resources are needed in the production cluster:
- Memory: 8 GB
- CPU: 2500 Millicore