This document outlines a complete Netreo deployment. It includes details about every component involved in a full implementation.
Netreo is packaged as an appliance-based solution. Therefore, everything necessary for a complete solution is packaged and bundled together. There are no agents, probes, or additional components to deploy.
The Netreo appliance is available in two forms:
Netreo can be 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 (OCVA).
|Devices Monitored||vCPUs||Memory||Storage Requirements*|
|Less than 100||4||8 GB||100 GB|
|Up to 300||8||8 GB||100 GB|
|Up to 1,000||16||32 GB||200 GB (SSD strongly recommended)|
|Up to 3,000||32||64 GB||600 GB (SSD required)|
|Up to 5,000||64||128 GB||1 TB (SSD required)|
|Up to 20,000||136||256 GB||2 TB (SSD required) Dedicated hardware recommended|
*Disks should be thin-provisioned if possible.
Deploying Netreo as a physical appliance is also an option. However, the overall design is the same. Similar to the virtual appliance, a complete solution is packaged and bundled together. Hardware appliance guidelines can be found in the table below.
|Devices Monitored||Hardware Platform|
|Less than 500||200|
|Up to 1,500||300|
|Up to 2,000||400|
|Up to 3,500||500|
|Up to 5,000||600|
|Up to 10,000||1000|
|Up to 20,000||2000|
These figures are based on 2016 or later hardware platforms which use solid-state drives exclusively.
The recommendations in the above table are based on Netreo best practices and an average customer deployment. Customers with specialized environments that require large amounts of monitoring, rapid monitoring intervals, large numbers of simultaneous users, or that collect traffic flow data will require more resources. Likewise, some limited environments may be able to reach higher values before performance becomes problematic.
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.
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.
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.
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 master, an arbitrator and a slave. The master is the “main” Netreo appliance that provides production services under normal circumstances. The slave is the “backup” Netreo appliance, that becomes active in the event that the master 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 slave should take over, based on the prevailing circumstances. The arbitrator also helps to reduce the stress on the master of database replication 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 master and the slave appliances. Netreo high availability configurations do not provide virtual IP functionality. Both the master and the slave must have static and permanent IP addresses. In the event of a failover, end-users must access the slave 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 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.
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.
There are two possible methods for connecting/linking a remote Netreo client to an Overview appliance.
- 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.)
- 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.
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.
|charon.netreo.net||TCP/443 or UDP/1194||Remote technical support VPN tunnel|
|activation.netreo.net||TCP/443||Allows for automatic licensing of Netreo|
|updates.netreo.net||TCP/80 or TCP/443||Allows for software updates|
|*.api.netreo.com||TCP/443||Allows for Netreo Cloud Services|
|rr.netreo.com||TCP/443||Allows for Netreo Cloud Services|
|*.rr.netreo.com||TCP/443||Allows for Netreo Cloud Services|
|api.geonames.org||TCP/443||Allows for geocoding in Netreo geographic map|
|dev.virtualearth.net||TCP/443||Allows for geocoding in Netreo geographic map|
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.
|Alert Generation||What variables should and/or need to be alerted on?|
|Alert Handling||When an alert condition occurs, who and how should the recipient be alerted?|
|Alert Escalation||When a condition has been CRITICAL for a long period of time, who and how should the next alert get transmitted?|
|Planned Outage Handling||How should planned outages be addressed within the NMS?|
|Distributed Reports||What kind of “tear away” reports need to be created, and who should receive them?|
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.
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.