NetProfiler and NetExpress Flow Storage

Every NetExpress, NetProfiler, and Enterprise cluster includes some amount of local storage. The following table lists the system storage type.

System Type	Physical Disks	Storage (Raw)
NetExpress (all physical models)	2	3 TB flow/4 TB packet
NetProfiler (all physical models)	12	10 TB
Enterprise NetProfiler per Analyzer, or Expansion module	12	20 TB

The primary advantages to local storage are performance and cost. Because the storage is located within the system, it is extremely fast when performing reads and writes, limited only by the physical disks and bus connecting the disks to the core system. You cannot order or operate the NetProfiler without local storage.

The biggest disadvantage of local storage is that it limits expansion. There is no option to increase the capacity or number of internal disks.

Storage area network (SAN) provides the most robust external storage solution for Standard and Enterprise NetProfiler. SAN is a reliable solution that enables the NetProfiler to very quickly access an extremely large amount of storage—up to 50 TB.

When you connect a SAN to the NetProfiler, the SAN functions as a new disk partition. The NetProfiler treats the SAN as another disk that is part of the appliance, enabling it to easily access the data. You can also offload much of the disk-related processing to the add-in card you use to connect the SAN.

You must use a separate logical unit number (LUN) and fiber connection between each Analyzer or Expansion module and the SAN when you connect a SAN to an Enterprise NetProfiler cluster. This configuration increases the performance drastically, because each analyzer is given its own dedicated channel to the SAN and potentially its own set of drives on the SAN (depending on the SAN configuration). Also, when you deploy a SAN with an Enterprise Cluster you must either deploy the SAN with all Analyzer and Expansion modules or no Analyzer and Expansion modules. You cannot deploy a SAN with part of an Enterprise Cluster.

The most important aspect of system sizing is the number of flows your system receives every minute. To accurately estimate the number of flows, you must know if a host accesses only internal resources or internal and external resources.

You must take into account the following considerations when estimating flows:

In general, you can expect a minimum of 40 flows per host per minute across all internal systems. Because different systems send different numbers of flows, it is probable that some hosts send much more than 40 fpm, while some systems send fewer.

Riverbed recommends that you consider large appliances when the estimate for flow rate approaches the limits of current or planned appliance system: for example, if you estimate 49,000 fpm, consider if a system capable of supporting 50,000 flows is too restrictive.

A network with 10,000 hosts, only 25 percent of which forwards traffic to the NetProfiler, has a very different requirement than a network with 5,000 hosts, that all forward traffic. The network with 10,000 hosts has an estimated 100,000 fpm, and the network with 5,000 hosts has an estimated 200,000 fpm. You must know the total number of hosts on a network and the number of hosts that have their flows forwarded to a collector for accurate sizing.

Sizing a system for 2,000 hosts when an additional 500 seats will be added over the next year (or conversely 500 seats will be removed) might result in a significant missizing of the system. While you might not know detailed plans for an enterprise over the lifetime of the deployed system, Riverbed recommends that you make estimates based on as much information as is possible. Additionally, if you are performing a proof of concept (PoC) on a small portion of a network, ensure that the final solution is sized for the actual implementation and not the PoC implementation.

Another primary sizing decision factor is how long you want to keep the stored flows available for retrieval. The amount of space occupied by each flow is dynamic depending on the number of hops being stored. Theoretically, you can store up to tens of billions of individual unique flows if each flow represents only data from a single hop. In a more realistic scenario, flows can represent data from up to ten hops, which is an eight times increase in the flow size (and a corresponding decrease in space available to store flows).

Note: This estimation assumes that you have 50 percent of available flow storage dedicated to storing flow records. On normal implementations, half of the storage is dedicated to storing the minute-by-minute flows and half is used to store presummarized data, called rollups.

If a NetExpress receives one flow per minute, it can store flows covering a time span of more than 4,500 years. On a more realistic network sending 50,000 fpm, the same NetExpress can store more than 60 days worth of flow data.

If you must store flows (at the realistic flow rate) for at least 180 days, then the storage included on the NetExpress is inadequate. If you have not yet purchased your appliances, make sure you choose a larger system (for example, a Standard NetProfiler) that has the amount of storage or supports a SAN storage option that meets your needs.

If you have already installed the system, you might need to upgrade to a larger capacity appliance to meet the desired storage capacity. In the example above, because NetExpress does not support a SAN alternative, you must upgrade to a larger system (such as a Standard NetProfiler) with additional storage capacity. When you determine the upgrade path to take, ensure that the path you choose is the most logical approach. You can move up from one system to another but not backwards. For example, you can move from a NetExpress to Standard NetProfiler or from Standard NetProfiler to Enterprise NetProfiler cluster. You cannot move from Enterprise NetProfiler cluster to a Standard NetProfiler.

When you choose the appropriate upgrade path, take into account the desired flow storage capacity and the cost of the system. While the Enterprise NetProfiler cluster might meet the storage needs of the network in the example above, unless you expect significant growth in the near future, it is unlikely to be as cost effective as a Standard NetProfiler with the SAN option.