The Aruba Flow Collector captures a robust set of statistics from Cisco IOS NetFLow enabled routers and switches. This data is used in support of the Aruba Flow application to determine which users are accessing what resources to run which applications. When combined with Aruba network performance data, you get a true picture of how your networked infrastructure is supporting your critical business applications.

The Flow Collectors, a part of the (multi-tiered collection layer), automatically gather, clean, normalize and store raw data, as well as aggregating and aging historical data. A single Flow Collector can be fully integrated into a single system along with the Aruba Server and Aruba Poller as in our Aruba SMB version for Mid-Sized organizations. Alternatively, single or multiple Flow Collectors can be deployed in a distributed architecture. This flexibility allows the efficient retrieval of data in an optimized fashion, to limit bandwidth consumption on retrieval and maximize performance. The distributed architecture provides an advantage in increasing scalability.

Why a multi-tiered, distributed, collection architecture?

A monolithic approach, a data collection engine and reporting engine both hosted on a single platform, will eventually be limited by processor performance, available bandwidth, and storage capacity. And long before these thresholds are reached, the user experience is impacted - continuous polling and database processing will consume much of the available machine cycles. Just adding more machines introduces a new problem - each machine now has its own collection and reporting domain. The user must know which machine is responsible for each device, and groups of devices can not span the domains.

An alternative approach is to separate the administrative and reporting functions from the data collection engines. This still gives the user a single machine to access for a holistic view of the entire network, for both reporting and administration. The CPU/bandwidth-intensive collection functionality is distributed across as many machines as needed. An additional benefit is that a collector can now be located close to the data sources, reducing SNMP polling across the WAN.

The downside of this approach, if the collectors rely on the server layer to actually process and store all the data that is collected, is the problem has not been solved. In fact, this only makes it worse, since the data is essentially moved twice. Many solutions which started with a monolithic architecture have been "scalability enhanced" by adding a "server layer" using this approach and must manipulate the data across platforms.

Valencia System feels the optimal solution must minimize data movement by pre-processing the data at the collectors - only summarized data is sent up to the server layer. Granular data (for example, raw polled data) is retained in the collector database, and is only moved to the server if user requested.

Reducing the ongoing maintenance burden is a major factor in a solution's scalability. To reduce maintenance burden the client layer must be distributed as well. The administrators console should tear away, and multiple administrators must be able to simultaneously make changes. In addition, grouping must be integrated into the administrative functions as well as the reports.