NFO Central: HA & Distributed Deployment

NFO Central is the management and resilience hub for distributed NetFlow Optimizer deployments. It enables High Availability (HA) and horizontal scalability by coordinating a cluster of NFO instances.

Linux Only

NFO Central and distributed deployment functionality are currently available only for Linux-based NFO installations. Windows deployments currently support Standalone mode only.

The platform operates in three primary modes to support different scale and reliability requirements:

• Standalone: A single NFO instance handling all functions — ingestion, processing, and output.
• NFO Central: Receives all NetFlow traffic from exporters and distributes it across NFO Peer nodes. Acts as the control plane for the cluster — monitoring peer health, orchestrating load rebalancing, and optionally centralizing licensing.
• NFO Peer: Worker nodes that perform flow ingestion, enrichment, and output. Multiple peers operate in an Active-Active configuration to provide both scale and redundancy.

---

Standalone Deployment

In Standalone mode, a single NFO instance handles all collection, processing, and output tasks without external peer distribution. This mode is appropriate for smaller environments or for evaluating NFO before scaling to a distributed architecture.

---

Distributed Deployment

Architecture & HA Considerations

Understanding the role of each component is essential before deploying a distributed NFO architecture.

NFO Central — the ingestion and control point

All NetFlow exporters on your network are configured to send flow data to NFO Central's IP address. NFO Central receives this traffic and distributes it to peer nodes for processing. It also monitors peer health and orchestrates load rebalancing across the pool.

Because all exporter traffic flows through NFO Central, it is the single most critical component in the architecture. If NFO Central goes offline, flow ingestion stops entirely — exporters have nowhere to send data, and peers have nothing to process. This is not a graceful degradation; it is a complete stop of the data pipeline.

Protect NFO Central First

NFO Central must be treated as the primary HA target in any distributed deployment. The Active-Active peer pool provides resilience for the data processing layer — but that resilience is meaningless if Central itself is unavailable. Deploy NFO Central on a platform that provides automatic VM-level recovery on hardware failure.

Recommended platforms for NFO Central HA:

On-premises:

• VMware vSphere HA — automatically restarts VMs on another host when a hardware failure is detected. The most common enterprise choice.
• oVirt / Red Hat Virtualization — KVM-based platform with built-in VM HA. Suitable for organizations running open-source or Red Hat virtualization stacks.
• Proxmox VE — KVM-based with HA cluster support. Common in smaller enterprise environments.

Cloud:

• AWS EC2 Auto Recovery — automatically recovers an instance on the same host or a new host on hardware failure.
• Azure VM Availability Sets or VM Scale Sets — distribute VMs across fault domains to protect against rack-level failures.
• GCP Managed Instance Groups — automatically restart VMs that fail health checks.

NFO Peers — the processing layer

Peers handle all flow processing, enrichment, and output. If a peer becomes unresponsive, NFO Central automatically redistributes its exporters to the remaining healthy peers in the pool. The data pipeline continues without interruption as long as at least one peer remains available.

Peers Do Not Need VM-Level HA

Because NFO Central automatically redistributes traffic when a peer goes offline, adding hypervisor-level HA to peer VMs is redundant. A VM restart typically takes 1–3 minutes — by which time Central has already rebalanced the pool. When the peer recovers and rejoins, Central rebalances again. Two rebalance events with no benefit. Let the pool handle peer failover; reserve VM-level HA for NFO Central.

Minimum requirements for a resilient deployment:

• Deploy at least two peers per pool. A single-peer pool has no failover target. If that peer goes offline, Central has nowhere to redistribute traffic.
• Size peers with headroom. Each peer should be capable of handling the full pool load temporarily. If remaining peers are already at capacity when a peer fails, flows will be dropped during the failover window.
• Deploy NFO Central on a hypervisor HA platform. See recommendations above.

---

Configuring a Distributed Deployment

Setting up a distributed NFO architecture involves the following steps:

1. Deploy NFO Central and generate a secure access token.
2. Deploy two or more NFO Peer nodes.
3. Enter the generated token into each peer to establish authentication and connection.
4. Verify peer connectivity within the NFO Central management interface.
5. Create a Peer Pool under the Load Balancer settings.
6. Assign peer nodes to the pool to begin intelligent traffic distribution.

Configuring NFO Central (The Control Plane)

When selecting the NFO Central operational mode, the interface expands to provide authentication tokens used to secure communication with peer nodes.

• Access Token: A token generated by NFO Central that NFO Peers use to authenticate their connection. Press the Generate button to create a new token.
• Access Token Hash: A secure hash of the access token, displayed for verification purposes.
• Connected Peers: A list showing all peer nodes that have successfully connected to this NFO Central instance, including their status, performance metrics, and data rates.

The Connected Peers table provides essential real-time monitoring statistics for load balancing and health checking:

Metric	Description
Name	The hostname of the connected NFO Peer node.
IP Address	The network address of the connected NFO Peer node.
Version	The software version running on the NFO Peer node.
Last Seen	Timestamp of the last successful communication with the peer.
Pool	The name of the NFO Peer Pool.
Status	Shows the current operational state (e.g., ONLINE, OFFLINE).
NFO Start Time	The timestamp indicating when the NFO Peer process was last started.
CPU Load %	The current system-wide CPU utilization for the peer node.
Mem Used %	The percentage of system memory currently utilized by the peer node.
NFO CPU Load %	The percentage of CPU dedicated specifically to the NFO process on the peer node.
NFO Mem Used...	The amount of memory being used specifically by the NFO process.
Input Rate	The number of packets/messages the peer is currently ingesting.
Processing Rate	The rate at which the peer is processing flows, typically measured in flows per second.
Total Drops	The cumulative number of flows dropped by the peer node due to overload or processing issues.

Configuring NFO Peer (The Worker Node)

When setting a node to the NFO Peer operational mode, you must specify the connection details for the central management hub.

• Peer name: The unique name of the peer node within the deployment.
• NFO Central URL: The full URL (including port) of the central control plane instance (e.g., https://<host>:8443).
• Access Token: The access token generated by the NFO Central instance, used by the peer to authenticate its connection.
• Access token hash (Read-Only): A secure hash of the access token.
• NFO UUID (Read-Only): The unique identifier for the NFO instance.
• Import certificate: Used to secure the connection between the peer and NFO Central.

Verify Peer Connectivity

To ensure your distributed environment is operational, navigate to the Connection Manager tab on the NFO Central instance to review the Connected Peers table.

• Operational Status: Confirm that the Status column displays RUNNING in a green highlight for each active peer.
• Connection Timing: Monitor the Last Seen column to view the timestamp of the most recent communication between NFO Central and the peer node.
• System Health: Review CPU Load % and Mem Used % to identify if any peer is approaching hardware limits.
• Data Throughput: Review the Input Rate and Processing Rate to verify that flow records are being successfully ingested and processed.
• Stability Monitoring: Track the Total Drops column — a growing drop count may indicate a node overload requiring a pool rebalance.

Once peer connectivity is verified, proceed to the Load Balancer tab to create a Peer Pool and assign nodes for distributed processing.

Steps to Assign Peers to a Pool

1. Create the Pool: Navigate to the Load Balancer tab and click Create New Pool.

2. Define the Pool Name: Enter a descriptive name for the pool (e.g., My-Pool1).
3. Select Peers: Use the Select peer to add... dropdown to select from connected peer nodes.
4. Add and Assign: Select the desired peer and click Assign to add it to the pool.
5. Finalize: Once all required peers are listed, click Save.

After the pool is saved, NFO Central begins distributing traffic to the peers in that pool, dynamically balancing the load based on real-time ingestion rates.

Configuring the Rebalancing Interval and Distribution Margin

To fine-tune how NFO Central manages load distribution, configure the Rebalancing time interval (sec) and Distribution Margin (%) in the Load Balancer tab.

Rebalancing time interval (sec) controls how frequently NFO Central monitors the input packet rate per device to determine whether exporters should be shifted between peer nodes. The default is 90 seconds.

Distribution Margin (%) sets the maximum percentage points a peer can exceed its weighted share before NFO Central considers it over-allocated and triggers rebalancing. The default is 5.

Recommended Tuning

For optimal performance, set the rebalancing interval to three times the data collection interval used in your logic modules (such as those configured for aggregation or volume reduction). This ensures the rebalancing logic has sufficient historical data to make informed distribution decisions without reacting to transient traffic spikes, providing the optimal balance between responsive load shifting and reliable data aggregation.