What does a BMC Helix Network Management deployment look like

Appliance Deployment

BMC Helix Network Management is packaged as an appliance-based solution.This document outlines a complete BMC Helix Network Management deployment. It includes details about every component involved in a full implementation.

Virtual Appliance

BMC Helix Network Management is deployed as a virtual appliance (VA) hosted within the customer’s virtualization environment. All of BMC Helix Network Management's functions and features are fully supported in this VA.

Performance guidelines shown in the following table will assist customers in allocating the appropriate amount of resources to BMC Helix Network Management VAs. This guide is not comprehensive. Rather, it is intended to give a general idea of the performance levels expected based on the amount of resources allocated to a BMC Helix Network Management VA.

*Disks should be thin-provisioned if possible.

Additional Components

Depending on the size, scope, and other circumstances particular to the implementation, other components can be included in a solution. These components are detailed below.

Log Collectors

To make log collection and processing more efficient in very large environments, a BMC Helix Network Management Log Collector appliance (OLC) can be deployed. This appliance exclusively collects and processes logs, offloading that work from the main BMC Helix Network Management appliance to itself. However, all the reporting, searching, and alerting are still handled directly through the main BMC Helix Network Management appliance. So, the only difference a user will notice is increased performance.  An OLC is typically deployed as a virtual appliance, so there is no limitation on the number of OLC appliances that can be added to a BMC Helix Network Management installation. In a high availability (HA) BMC Helix Network Management implementation, an OLC is required, as it protects resources dedicated to active polling.

Traffic Flow Collectors

In addition to the ancillary logging collector, another way to allow BMC Helix Network Management to scale horizontally is to add an BMC Helix Network Management Traffic Collector appliance (OTC) to the BMC Helix Network Management deployment. The idea behind this appliance is identical to the OLC appliance, except the data being collected and processed are traffic statistics from layer 3 devices. Like the OLC, an OTC is typically deployed as a virtual appliance, so there is no limitation on the number of OLC appliances that can be added to an BMC Helix Network Management installation. In a high availability (HA) BMC Helix Network Management implementation, an OTC is required, as it protects resources dedicated to active polling.

Remote Pollers

A third type of supplemental appliance that can be added to a BMC Helix Network Management solution is the BMC Helix Network Management Remote Poller appliance (ORP). The primary use case for this type of appliance would be to deploy it into a portion of your infrastructure where traditional monitoring protocols, such as SNMP and WMI/WinRM, are not allowed to traverse in or out. As with the OLC and OTC appliances all of the work of data collection and processing is handled on the local appliance and then retrieved from the ORP (via RESTFul API calls) for integration into the main BMC Helix Network Management UI. Generally speaking, only a single ORP would need to be deployed per restricted section of network—as the deployment specifications of the ORP match those of a standard BMC Helix Network Management appliance.

Scaling for Ancillary Servers

Determining the number of remote appliances to add to a solution is a function of two variables: The number of devices transmitting data in the network, and the volume of data sent by those devices to the managing BMC Helix Network Management appliance. It has been our experience that if inbound logging or traffic data is sourced from less than 30 devices, a core BMC Helix Network Management can handle the entirety of the load. But beyond that point, segmentation is recommended.

High Availability

BMC Helix Network Management deployments also offer a high availability (HA) option. HA for BMC Helix Network Management is implemented as a cluster of multiple, independent appliances. A standard BMC Helix Network Management HA setup consists of three deployed BMC Helix Network Management appliances: a primary license appliance, a replica license appliance, and an arbitrator appliance. The primary is the “main” BMC Helix Network Management appliance that provides production services under normal circumstances. The replica is the “backup” BMC Helix Network Management appliance, that becomes active in the event that the primary fails. The arbitrator is a third BMC Helix Network Management appliance that acts to provide quorum for the cluster in the event of a failure, casting the deciding vote on whether or not the replica should take over, based on the prevailing circumstances. The arbitrator also helps to reduce the stress of database replication on the primary during initial HA data synchronization.

In order for the HA cluster nodes to communicate properly, they must be able to connect with each other using the ports noted in the table below. For HA to function properly, all managed devices in the customer environment must allow access from the IP addresses of both the primary and the replica appliances. BMC Helix Network Management high availability configurations do not provide virtual IP functionality. Both the primary and the replica must have static and permanent IP addresses. In the event of a failover, end-users must access the replica system via its natural IP address. VIP functionality is possible. However, the setup and configuration of that architecture are purely the responsibility of the customer. In any high availability (HA) BMC Helix Network Management implementation, remote log and traffic collectors are required, as they protect resources dedicated to active polling.

BMC Helix Network Management Overview

BMC Helix Network Management Overview is a deployment option used to scale BMC Helix Network Management vertically rather than horizontally—as with remote collectors or pollers. This type of deployment is intended for service-provider environments where multi-tenancy is required, but can still be used in any situation. A BMC Helix Network Management Overview appliance (which can be deployed either virtually or physically) can be thought of as an “BMC Helix Network Management of Netreos.” Alert status from all linked BMC Helix Network Management clients are aggregated and rolled up through a single Overview user interface. The Overview appliance also polls and monitors its client BMC Helix Network Management appliances. Overview is not meant to monitor other resources in an infrastructure.

Overview Functionality

The purpose of an BMC Helix Network Management Overview deployment is to tie together multiple BMC Helix Network Management appliances, where each client BMC Helix Network Management is individually deployed and polling/monitoring its own set of devices. In addition to alert aggregation from client BMC Helix Network Management appliances to the Overview appliance, the following functions are also available:

• Pass-through Authentication - Since BMC Helix Network Management Overview is meant to be a single UI to combine multiple BMC Helix Network Management appliances, pass-through authentication can be configured to allow unobstructed access to the client BMC Helix Network Management appliances. Logging into an Overview and navigating to a remote BMC Helix Network Management appliance through the Overview UI will allow access to the client using the Overview credentials.
• Private Cloud Object Libraries - A BMC Helix Network Management Overview can be configured to host authoritative versions of device types, device subtypes, device templates, alert templates, incident management rules and a local users list in its private cloud libraries.
• Private Software Release Repository - A BMC Helix Network Management Overview can be configured to mirror the general BMC Helix Network Management software repository that linked BMC Helix Network Management appliances look to for updates, thus limiting what version/patch-releases can be installed on the clients.

Connectivity

There are two possible methods for connecting/linking a remote BMC Helix Network Management client to an Overview appliance.

1. The first option is the use the Overview appliance as an OpenSSL VPN server. A tunnel connection can be configured that will initiate from the client BMC Helix Network Management appliance and connect to the Overview appliance. Default communication requires bidirectional outbound TCP/443 access between the client and the Overview. (This configuration is adjustable based on customer requirements.)
2. The second option is for the customer to configure their network connections via routing (or some other method) to be able to reach an accessible Overview server.

Linked client BMC Helix Network Management appliances have a listening API that allows the Overview server to make calls to the remote system and pull in its aggregated alert status. This API call is made every five minutes and updates the main Overview landing page.

Federation features in the Overview (Private Cloud Object Libraries) are only updated on demand. There is no automatic synchronization.

Considerations

An BMC Helix Network Management Overview connects disparate independent BMC Helix Network Management client appliances. Aside from federation settings which can be pushed down (or pulled in) they are controlled and administered as stand-alone entities. The ideal use case for an Overview/client deployment is a widely dispersed network where local-perspective statistics are required, there will be IP address conflicts, or multi-tenancy is required (or any combination thereof). The primary contrast between this architecture and a BMC Helix Network Management Remote Poller deployment is that in the latter, only the time-series data is sourced from the local instance. All other elements are controlled and administered via the central BMC Helix Network Management appliance. Combining these features with device restrictions and user profiles found in the core of BMC Helix Network Management make BMC Helix Network Management Overview ideal for service provider environments.

Deployment and Implementation

Preparing for BMC Helix Network Management

BMC Helix Network Management uses existing manufacturer APIs to collect data from systems without having to install additional agents.  We recommend deploying BMC Helix Network Management on a core network, and inside of any firewalls used for perimeter protection. Because BMC Helix Network Management uses a wide variety of protocols for management (including direct connections to applications for monitoring and management), implementation is greatly simplified by this approach.

Having the necessary credentials for your network handy while configuring BMC Helix Network Management will make the initial setup go much more quickly and smoothly. Here’s a list of credentials to gather before you begin:

• Any relevant SNMP read-only strings for devices on your network.
• WMI/WinRM credentials to access Windows devices.
• SSH/Telnet credentials for configuration management.

SNMP (Simple Network Management Protocol) is the main protocol used for Linux servers and network devices (routers, switches, firewalls, load balancers, etc.). SNMP uses port UDP/161 for polled data collection and port UDP/162 for Trap messages (originating from the device to BMC Helix Network Management).

Either WMI or WSMAN protocols can be used to collect data from Windows servers. Communication using WMI requires TCP/135 and all high ports (1024-65535), bidirectionally.  To use WSMAN enable TCP/5985 originating from BMC Helix Network Management.

BMC Helix Network Management can operate without Internet access; however, licensing, software updates, and remote support are greatly simplified with basic Internet access. The following is a list of IP addresses and ports that can be configured on your outbound firewall to safely allow BMC Helix Network Management the access it needs.

Alerting Policy

An alerting policy is a collection of practices and procedures centered on the alerting of non-optimal conditions in the IT infrastructure. Prior to any BMC Helix Network Management implementation,BMC Helix will work with the client to understand their business needs and various requirements. These requirements can help dictate a policy that can be put into place via BMC Helix Network Management’s software. The follow table outlines the core aspects of an NMS alerting policy.

Installation and Configuration

There is a standardized methodology that BMC Helix Operations Engineers follow when implementing BMC Helix Network Management. It follows these steps:

A) Quick Start
In this step, BMC Helix Ops will assist the customer in getting BMC Helix Network Management licensed and putting the necessary initial configuration information into the BMC Helix Network Management setup wizard (device authentication information, alert contacts and other variables).

B) Device Population
The next step is to get target devices that need to be monitored into BMC Helix Network Management. This process can be completed in one of four ways:

• Manual device addition
• Import of a device list via CSV upload
• A “device addition” API call to BMC Helix Network Management
• Network scan and automatic discovery

C) Basic Categorization This step is the first pass in device organization within BMC Helix Network Management. It is a precursor to additional setup activities.

D) Baselining and Templating
After roughly two weeks of data polling, a base of data exists such that reports can be run to determine “normal” operating levels. Exception thresholds can then be altered appropriately.

E) Organization
Complete BMC Helix Network Management organization by defining functional categories, geographic sites and strategic/application groups. The classifications defined here will largely be governed by what was dictated in the alerting policy.

F) Additional Configuration
This step is the completion of additional features found in BMC Helix Network Management; such as the configuration manager, Web Application Response monitoring, mobile application activation, custom dashboards, and other elements.