On-premise Deployment Hardware Guide

Deployment Options

BMC Helix Network Management is offered in a variety of deployment types to allow you to choose the deployment that best suits your needs.

• SaaS - Your BMC Helix Network Management instance is hosted by us in the Cloud. (If you require service engines to monitor on-premises infrastructure, those will need to be deployed using the on-premises option below.)
• Bring-your-own-cloud - You deploy the BMC Helix Network Management virtual appliance on your own private Cloud-based server. (This is similar to SaaS, but the server on which BMC Helix Network Management is deployed is under your control. If you require service engines to monitor on-premises infrastructure, those will need to be deployed using the on-premises option below.)
• On-premises - You deploy the BMC Helix Network Management virtual appliance on your own physical server located within your organization’s infrastructure. (All BMC Helix Network Management service engines and high availability configurations must be deployed this way.)

Since service engines are designed to be deployed behind your organization’s security perimeter, they must be deployed using the on-premises deployment option.

Deploying BMC Helix Network Management in its high availability (HA) configuration also requires all node appliances to be deployed using the on-premises deployment option, as does BMC Helix Network Management Overview.

SaaS Deployments

If you intend to monitor only cloud-based resources, no resource allocation is required, as BMC Helix Network Management SaaS includes a primary appliance hosted by BMC Helix Network Management in the BMC Helix Network Management Cloud.

If you intend to monitor any devices within your own infrastructure, the deployment of a remote collector service engine appliance within that infrastructure is required. (See the Service Engines section below for resource allocation recommendations.)

If you intend to monitor any traffic flows within your own infrastructure, the deployment of a traffic collector service engine appliance within that infrastructure is required. (See the Service Engines section below for resource allocation recommendations.)

If you intend to monitor any device logs within your own infrastructure, the deployment of a log collector service engine appliance within that infrastructure is required. (See the Service Engines section below for resource allocation recommendations.)

On-premises Deployments

For on-premises and private cloud deployments, BMC Helix Network Management is typically deployed in the form of an individual virtual appliance (VA) running the BMC Helix Network Management core application. (If deploying BMC Helix Network Management within a private cloud to monitor devices within the customer’s infrastructure, the customer is responsible for providing secure communication between the private cloud and their infrastructure.) All of BMC Helix Network Management’s functions and features are fully supported when deployed as a VA.

For customers with larger environments or multiple domains, additional service engine appliances are typically deployed in addition to the BMC Helix Network Management primary appliance. (See the Service Engine section below for resource allocation recommendations.)

However, separate service engine appliances are recommended for polling, traffic flow and log collection in all but the smallest environments.

General Guidelines for All Deployments

BMC Helix Network Management uses a Linux-based core for basic hardware support and OS functions and is designed to make maximum use of the available hardware resources. For this reason, BMC Helix Network Management does not recommend deploying the VA in virtual environments that are heavily oversubscribed, as performance may be adversely affected.

You should also consider carefully the merits of monitoring your VM environment from a guest inside the environment, as under those circumstances a virtual environment outage could disable BMC Helix Network Management and prevent you from being alerted. If your VM environment is not highly redundant and stable, the use of dedicated hardware is recommended.

Due to constant database updates during data collection, most environments will have a 90%-write, 10%-read disk I/O profile—which may require special configuration of your datastore for optimal performance.

BMC Helix Network Management is extremely disk write intensive and is not tolerant of high latency or unstable storage environments. If you have concerns about your storage performance or stability, dedicated hardware is recommended.

Understanding BMC Helix Network Management Performance

BMC Helix Network Management's performance in any given arrangement is determined largely by the number of instances of metrics, traffic flows and logs that it has to process. The number of managed devices being monitored, and the device types and subtypes assigned to them, determine the number of instances BMC Helix Network Management must collect and keep track of.

A managed device is the basic unit of licensing in BMC Helix Network Management and is defined as any single, logical entity or operating system (such as a VM guest, VM host, single switch, or “stack” of switches managed as a single entity).

The device type assigned to a managed device specifies the standard and device-specific metrics collected from it by BMC Helix Network Management.

Any device subtypes assigned to a managed device specify additional metrics to be collected beyond the standard metrics for the type. For example, BGP statistics from a BGP-configured Cisco IOS router. Adding subtypes to your monitored devices can have a significant impact on the number of instance metrics collected. Keep that in mind when considering resource allocation for BMC Helix Network Management deployments.

The collected metrics are generally grouped into categories such as CPU, Network Interfaces, Memory, and Disk. For each of these groups, one or more instance metrics may be collected, such as CPU-core01 utilization, CPU-core02 utilization, CPU-core03 utilization, and Overall CPU utilization.

The number of instances of traffic flows and logs sent to BMC Helix Network Management for monitoring is controlled directly on the monitored devices themselves by their administrators. The large volumes frequently associated with these types of instances can have a significant impact on BMC Helix Network Management's performance. That is why it is always recommended to use a service engine when processing these instance types.

Suggested Hardware Minimums

The guide below outlines suggested hardware minimums to ensure stability and reasonable performance from deployed appliances filling the following roles:

• Primary - In this role, a single BMC Helix Network Management appliance runs on a dedicated server which and is intended to handle all monitoring and alerting duties. (This also includes the primary appliance in a high availability (HA) cluster arrangement.)
• Replica - In this role, the appliance acts as a backup to the primary appliance in a high availability arrangement. Its hardware requirements are identical to the primary appliance requirements.
• Arbitrator - In this role, the appliance provides third-party arbitration for the primary/replica appliances in a high availability cluster arrangement. It also provides data replication support during the initial HA setup.
• Overview - In this role, the appliance acts as the primary appliance as well as a central management and alerting tool for multiple BMC Helix Network Management primary appliances connected as clients.
• Service Engine - In this role, the appliance is deployed as a lightweight, specialized version of the primary appliance, deployed on a separate server and used to reduce the workload of the primary when collecting traffic and log data, or when monitoring a very high number of devices within your environment. Each service engine type will have its own hardware requirements depending on the type of work its doing.

The recommendations provided in this guide are based on internal load testing and real-world customer data. Each section provides a table with our tested recommendations and a table with actual customer configuration examples that are known to have acceptable performance.

Primary Appliance (or Replica Appliance for HA)

Refer to the table below when deploying a BMC Helix Network Management appliance to act as the primary appliance in your environment, or as the replica appliance in a high availability cluster.

Recommended Minimums

* SSD required.
** SSD with dedicated bandwidth required.

The table below shows actual customer configurations for this deployment type in use today.

Examples of Actual Customer Configurations

Recorded Performance

* Effectively, the number of devices queued for polling. Numbers higher than 0 can indicate performance issues.
** The calculated average of how long devices are taking to respond to service checks from the availability engine.

Arbitrator Appliance (High Availability)

Refer to the table below when deploying a BMC Helix Network Management appliance to act as an arbitrator appliance in a high availability cluster. (Used with primary and replica appliances in an HA arrangement.)

Recommended Minimums

* SSD recommended.
* SSD recommended. Should match the storage volume of the primary appliance.

The table below shows actual customer configurations for this deployment type in use today.

Examples of Actual Customer Configurations

Overview Appliance

The resource requirements for a BMC Helix Network Management Overview appliance deployment are identical to those for a primary appliance deployment (see above).

Service Engine Appliances

Service engines are required for polling or data collection within specific on-prem security domains/DMZ and are always required for SaaS tenant deployments. They are typically deployed within private infrastructure, private data centers, or VPCs to data connections that are not permitted across public transit. They are used to collect data within private infrastructures and, in turn, publish it to BMC Helix Network Management.

All service engines should have a minimum interface speed of 100Mb/s when connecting to the primary appliance to ensure the best performance.

Remote Poller/Collector

Refer to the table below when deploying a BMC Helix Network Management appliance as a service engine to monitor and alert on availability and performance data from devices in your environment.

Recommended Minimums

* SSD preferred.

The table below shows actual customer configurations for this deployment type in use today.

Examples of Actual Customer Configurations

The above is an example of an individual customer utilizing multiple monitoring service engines in different environments.

Log Collector

Refer to the table below when deploying a BMC Helix Network Management appliance as a service engine to collect, process, and alert on logs from devices in your environment. It is not recommended to collect logs from more than 2000 devices per service engine deployment. A log collector service engine is required when using an HA cluster.

Syslog/event log collection can have a large impact on system performance, especially disk usage. Device counts assume a reasonable volume of logs from a mix of servers and network devices. Large volumes of log data may create many times more traffic with a corresponding decrease in the number of devices supported per appliance.

Recommended Minimums

The table below shows actual customer configurations for this deployment type in use today.

Examples of Actual Customer Configurations

Customer A above is an example of an individual customer utilizing multiple log collectors in different environments.

Traffic Flow Collector

Refer to the table below when deploying a BMC Helix Network Management appliance as a service engine to collect, process, and alert on traffic flow data from devices in your environment. It is not recommended to collect traffic flow data from more than 1000 devices per service engine deployment. Traffic flow is a particularly I/O-intensive application, so solid-state disks (SSD) are strongly recommended (and required for larger implementations). A traffic flow collector is required when using a high availability (HA) cluster.

Flow technologies can have a large impact on system performance, especially disk I/O, and usage. Device counts assume edge devices with 4 or fewer interfaces. Exporting flow data from core devices or firewalls may create many times more load with a corresponding decrease in the number of devices supported per appliance.

Recommended Minimums

* SSD required.

The table below shows actual customer configurations for this deployment type in use today.

Examples of Actual Customer Configurations

Customer B above is an example of an individual customer utilizing multiple flow collectors in different environments.