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)
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 for guidance on how to size your infrastructure.
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:
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:
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.
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 100 GB |
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 tables show the disk requirements in GB:
We recommend that you use solid-state drive (SSD) with the following specifications:
RWM throughput and IOPS requirements:
Sizing guidelines for the BMC Discovery
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 |