What Does a Netreo Deployment Look Like

Appliance Deployment

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

This diagram illustrates a basic deployment of Netreo into a customer environment.

 

Virtual Appliance

Netreo is deployed as a virtual appliance (VA) hosted within the customer’s virtualization environment. All of Netreo'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 Netreo 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 Netreo 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 Netreo Log Collector appliance (OLC) can be deployed. This appliance exclusively collects and processes logs, offloading that work from the main Netreo appliance to itself. However, all the reporting, searching and alerting are still handled directly through the main Netreo 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 Netreo installation. In a high availability (HA) Netreo 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 Netreo to scale horizontally is to add an Netreo Traffic Collector appliance (OTC) to the Netreo 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 Netreo installation. In a high availability (HA) Netreo implementation, an OTC is required, as it protects resources dedicated to active polling.

This diagram illustrates the deployment of Netreo along with a service engine.

 

Remote Pollers

A third type of supplemental appliance that can be added to a Netreo solution is the Netreo 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 Netreo 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 Netreo 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 Netreo appliance. It has been our experience that if inbound logging or traffic data is sourced from less than 30 devices, a core Netreo can handle the entirety of the load. But beyond that point, segmentation is recommended.

High Availability

Netreo deployments also offer a high availability (HA) option. HA for Netreo is implemented as a cluster of multiple, independent appliances. A standard Netreo HA setup consists of three deployed Netreo appliances: A primary license appliance, a replica license appliance, and an arbitrator appliance. The primary is the “main” Netreo appliance that provides production services under normal circumstances. The replica is the “backup” Netreo appliance, that becomes active in the event that the primary fails. The arbitrator is a third Netreo 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.

A Netreo high availability deployment showing the primary and arbitrator co-located at one site and the replica deployed off-site for disaster recovery.

 

 

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. Netreo 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) Netreo implementation, remote log and traffic collectors are required, as they protect resources dedicated to active polling.

Netreo Overview

Netreo Overview is a deployment option used to scale Netreo 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 Netreo Overview appliance (which can be deployed either virtually or physically) can be thought of as an “Netreo of Netreos.” Alert status from all linked Netreo clients are aggregated and rolled up through a single Overview user interface. The Overview appliance also polls and monitors its client Netreo appliances. Overview is not meant to monitor other resources in an infrastructure.

A Netreo Overview deployment for an MSP.

 

Overview Functionality

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

• Pass-through Authentication - Since Netreo Overview is meant to be a single UI to combine multiple Netreo appliances, pass-through authentication can be configured to allow unobstructed access to the client Netreo appliances. Logging into an Overview and navigating to a remote Netreo appliance through the Overview UI will allow access to the client using the Overview credentials.
• Private Cloud Object Libraries - A Netreo 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 Netreo Overview can be configured to mirror the general Netreo software repository that linked Netreo 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 Netreo 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 Netreo 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 Netreo 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 Netreo Overview connects disparate independent Netreo 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 Netreo 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 Netreo appliance. Combining these features with device restrictions and user profiles found in the core of Netreo make Netreo Overview ideal for service provider environments.

Deployment and Implementation

Preparing for Netreo

Netreo uses existing manufacturer APIs to collect data from systems without having to install additional agents. Netreo recommends deploying Netreo on a core network, and inside of any firewalls used for perimeter protection. Because Netreo 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 Netreo 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 Netreo).

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 Netreo.

Netreo 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 Netreo 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 Netreo implementation, Netreo 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 Netreo’s software. The follow table outlines the core aspects of an NMS alerting policy.

Installation and Configuration

There is a standardized methodology that Netreo Operations Engineers follow when implementing Netreo. It follows these steps:

A) Quick Start
In this step, Netreo Ops will assist the customer in getting Netreo licensed and putting the necessary initial configuration information into the Netreo 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 Netreo. 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 Netreo
• Network scan and automatic discovery

C) Basic Categorization This step is the first pass in device organization within Netreo. 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 Netreo 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 Netreo; such as the configuration manager, Web Application Response monitoring, mobile application activation, custom dashboards and other elements.