- 21 Mar 2024
- 9 Minutes to read
- Print
- DarkLight
- PDF
On-premise Deployment Hardware Guide
- Updated on 21 Mar 2024
- 9 Minutes to read
- Print
- DarkLight
- PDF
Deployment Options
Netreo is offered in a variety of deployment types, to allow you to choose the deployment that best suits your needs.
- SaaS - Your Netreo 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 Netreo virtual appliance on your own private Cloud-based server. (This is similar to SaaS, but the server on which Netreo 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 Netreo virtual appliance on your own physical server, located within your organization’s infrastructure. (All Netreo 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 Netreo in its high availability (HA) configuration also requires all node appliances to be deployed using the on-premises deployment option, as does Netreo Overview.
SaaS Deployments
If you intend to monitor only cloud-based resources, no resource allocation is required, as Netreo SaaS includes a primary appliance hosted by Netreo in the Netreo 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, Netreo is typically deployed in the form of an individual virtual appliance (VA) running the Netreo core application. (If deploying Netreo 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 Netreo’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 Netreo 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
Operating System |
|
CPU |
|
Storage |
|
Datastore |
|
Netreo 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, Netreo 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 Netreo 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.
Netreo 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 Netreo Performance
Netreo'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 Netreo must collect and keep track of.
A managed device is the basic unit of licensing Netreo, 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 Netreo.
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 Netreo 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 Netreo for monitoring are 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 Netreo'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 Netreo 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 Netreo 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 Netreo appliance to act as the primary appliance in your environment, or as the replica appliance in a high availability cluster.
Recommended Minimums
Device Count | Metric Count | Flows/sec | Logs/sec | vCPU Cores | RAM | Disk Space | Service Engine |
Up to 500 | 100,000 | 2,500 | 2,500 | 8 | 16 GB | 200 GB | Optional |
Up to 1000 | 400,000 | 10,000 | 10,000 | 16 | 32 GB | 500 GB | Preferred |
Up to 3000 | 700,000 | n/a | n/a | 32 | 64 GB | 1 TB* | Required |
Up to 5000 | 1,200,000 | n/a | n/a | 64 | 128 GB | 2 TB* | Required |
Up to 30,000 | 2,700,000 | n/a | n/a | 160 | 256 GB | 2 TB** | Required |
* 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
Devices | vCPU Cores | RAM | Storage Type | |
Customer A | 1,269 | 32 | 64 GB | SSD |
Customer B | 3,677 | 76 | 240 GB | SSD |
Customer C | 8,759 | 70 | 108 GB | SSD |
Customer D | 12,390 | 135 | 200 GB | SSD |
Recorded Performance
Dash Load | Netreo Polling Queue* | Netreo Availability Monitor Latency** | |
Customer A | 3.26 s | not available | not available |
Customer B | 3.26 s | 0 | 42.3 s |
Customer C | 3.66 s | 0 | 18.1 s |
Customer D | 2.95 s | 0 | 2.6 s |
* Effectively, the number of devices queued for polling. Numbers higher than 0 may 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 Netreo appliance to act as an arbitrator appliance in a high availability cluster. (Used with primary and replica appliances in an HA arrangement.)
Recommended Minimums
Device Count | vCPU Cores | RAM | Disk Space |
Up to 500 | 8 | 16 GB | 200 GB |
Up to 1,000 | 16 | 32 GB | 200 GB |
Up to 5,000 | 32 | 64 GB | 500 GB* |
* SSD preferred.
The table below shows actual customer configurations for this deployment type in use today.
Examples of Actual Customer Configurations
Devices | vCPU Cores | RAM | Storage Type | |
Customer A | 1,269 | 16 | 16 GB | HDD |
Customer B | 3,677 | 16 | 16 GB | HDD |
Customer C | 8,759 | 7 | 19 GB | SSD |
Customer D | 12,390 | 29 | 58 GB | SSD |
Overview Appliance
The resource requirements for a Netreo 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 Netreo.
All service engines should have a minimum interface speed of 100Mb/s when connecting to the primary appliance to ensure best performance.
Remote Poller/Collector
Refer to the table below when deploying a Netreo appliance as a service engine to monitor and alert on availability and performance data from devices in your environment.
Recommended Minimums
Device Count | vCPU Cores | RAM | Disk Space |
Up to 500 | 8 | 16 GB | 200 GB |
Up to 1,000 | 16 | 32 GB | 200 GB |
Up to 5,000 | 32 | 32 GB | 300 GB* |
* SSD preferred.
The table below shows actual customer configurations for this deployment type in use today.
Examples of Actual Customer Configurations
Devices | vCPU Cores | RAM | Storage Type | |
Customer A | ||||
Service Engine 1 | 227 | 16 | 16 GB | HDD |
Service Engine 2 | 1,423 | 16 | 16 GB | HDD |
Service Engine 3 | 6,672 | 32 | 32 GB | HDD |
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 Netreo 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
Logs/sec | vCPU Cores | RAM | Disk Space |
Up to 2000/s | 8 | 16 GB | 200 GB |
The table below shows actual customer configurations for this deployment type in use today.
Examples of Actual Customer Configurations
Devices | vCPU Cores | RAM | Storage Type | |
Customer A | ||||
Log Collector 1 | 27 | 20 | 27 GB | HDD |
Log Collector 2 | 602 | 20 | 27 GB | HDD |
Log Collector 3 | 1,977 | 20 | 27 GB | SSD |
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 Netreo 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 implementation). 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
Flows/sec | vCPU Cores | RAM | Disk Space |
Up to 2,500/s | 8 | 16 GB | 200 GB |
Up to 5,000/s | 16 | 32 GB | 200 GB |
Up to 10,000/s | 32 | 32 GB | 300 GB* |
* SSD required.
The table below shows actual customer configurations for this deployment type in use today.
Examples of Actual Customer Configurations
Devices | vCPU Cores | RAM | Storage Type | |
Customer A | ||||
Flow Collector 1 | 42 | 16 | 16 GB | HDD |
Customer B | ||||
Flow Collector 1 | 15 | 20 | 27 GB | HDD |
Flow Collector 2 | 170 | 20 | 27 GB | HDD |
Flow Collector 3 | 895 | 20 | 27 GB | SSD |
Customer B above is an example of an individual customer utilizing multiple flow collectors in different environments.