Sizing and scalability considerations

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

The following applications were tested in the BMC test labs for BMC Helix IT Operations Management sizing considerations:

  • BMC Helix Continuous Optimization
  • 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)


Important

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

BMC’s performance testing is based on five 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 are not considered. 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 Open link for guidance on how to size your infrastructure.

ParametersCompact (POC)SmallMediumLarge

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

Important: Make sure that you do not exceed the number of MI (Monitored instances) per device. 

100


3,000


7,500


15,000


Monitored instances (Other sources, such as Prometheus and Rest API)1000100,000250,000500,000
Number of MI per device10333333
Monitored attributes (Other sources, such as Prometheus and Rest API)10,000600,0001,500,0003,000,000
Number of Attributes per device100200200200
Events per day (Alarm, Anomalies and External Events)5,00030,00075,0001,500,000
Configuration policies1001,0001,50010,000
Number of policies per device1221
Number of groups up to501,5002,5004,500
Number of concurrent users550100150
BMC Helix AIOps
Services255001,0003,000
Situations103005001,000

BMC Helix Continuous Optimization

Ingestion of samples per day in million50 mil50 mil100 mil500 mil
BMC Helix Log Analytics
Log ingestion per day500MB30GB100GB250GB
Number of Logstash151050
Number of days for retention3333

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.

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:

CategoryCPU (Core)RAM (GB)
Compact29181
Small56320
Medium100533
Large152942

Important

The total sizing does not include the requirements for BMC Discovery.

Kubernetes quotas

Quotas may be set up on the cluster namespaces to enforce maximum scheduled requests and limits. Any attempt to schedule additional workloads beyond configured quotas will result in Kubernetes preventing the scheduling which may complicate successful software operations in the namespace. The following table shows the recommended settings to allow a BMC Helix IT Operations Management suite deployment:

BMC Helix Platform namespace quotas

CategoryCPU requests (Millicore) CPU limits (Millicore) MEM requests (GB) MEM limits (GB) 
Compact

29,000 

196,000

181

389

Small

56,000 

326,000

320

655

Medium

100,000

500,000

533

1,094

Large

152,000

731,000 

942

1,658

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 Size 

Minimum worker nodes available 

Compact 

4 

Small 

4 

Medium 

6 

Large 

6 

Persistent volume requirements

High performance of Kubernetes Persistent Volume Disk is essential for the overall system performance. BMC supports a Bring-Your-Own-Storage model for Kubernetes Persistent Volumes.

The following tables shows the disk requirements in GB:

Block Storage (GB)

Compact 

Small 

Medium 

Large 

1,220

3,940

8,495

17,270

Read Write Many Storage (GB)

Compact 

Small 

Medium 

Large 

91 

91 

91 

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 

< 100ms 

< 100ms  

< 100ms 

< 100ms  

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 

RWM throughput and IOPS requirements: 

Specification 

Value 

Read throughput 

10 MBPS 

Write throughput 

5 MBPS 

IOPS Read 

3K 

IOPS Write 

1K 

Sizing guidelines for the BMC Discovery

CategoryCPURAM (GB)Disk (GB)Number of servers per environment
Compact (not in high availability)241001
Small483003
Medium8165003
Large8641,0005

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

Category 

CPU (Core) 

RAM (GB) 

PVC (GB) 

Compact 

5 

11 

2,080

Small 

9 

17 

4,799 

Medium 

12 

34

6,920

Large 

13 

61 

34,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) 

Category 

CPU Requests (Millicore) 

CPU Limits (Millicore) 

MEM Requests (GB) 

MEM Limits (GB) 

Compact 

5,000 

13,000

11 

27 

Small 

9,000 

25,000 

17 

51 

Medium 

12,000 

29,000 

34 

78

Large 

13,000 

27,000 

61 

99 


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

Comments

  1. Sharvan Singh

    PVC For Disaster Recovery for Large environment, is the number 34TB correct and do we need 51TB at each site ?

    Dec 27, 2023 03:56
    1. Ashwini Sawanth

      Hi Sharvan,

      Thank you for reaching out to us. Here is the information:

      If you have not enabled disaster recovery, PVC requirement is 17.2 TB for Large deployment.

      If you have enabled disaster recovery then 17 TB + 34 TB (additional requirement) for each site is needed.

      Best regards,

      Ashwini Sawanth

      Jan 09, 2024 11:57
  2. Nigel Leach

    In the past there was an Extra Large option in the sizing's. What is the explanation for this being removed?

    Mar 26, 2024 07:10
    1. Ashwini Sawanth

      Hi Leach,

      Our team responsible for Performance, Scalability, and Reliability (PSR) is constantly working to improve the sizing requirements for OnPrem versions of our software. During our review of the XL category, we noticed variances in the numbers and have decided to temporarily remove them from our documents. We will be retesting this category and updating the numbers as soon as possible. In the meantime, if you require information on XL footprints, we suggest that you contact BMC support for assistance.

      Regards,

      Ashwini Sawanth

      Mar 28, 2024 12:54