The most important parameter related to NAM Probe capacity is the amount of traffic that it can process.
If you are coming to NAM from earlier releases (DC RUM), this is how product and component naming has changed:
|DC RUM 2017 and older||NAM 2018, NAM 2019|
|RUM Console||NAM Console|
|Central Analysis Server (CAS)||NAM Server|
|Advanced Diagnostic Server (ADS)||Advanced Diagnostics on Demand feature of NAM Server|
|Agentless Monitoring Device (AMD)||NAM Probe|
For the analysis of simple traffic, the volume that can be processed is limited mainly by the CPU speed of the NAM Probe. Analysis of complex traffic involving large numbers of distinct sessions and users can use large amounts of memory, which becomes the limiting factor.
A NAM Probe is designed to write a summary analysis to disk every five minutes (subject to configuration), so no substantial backlog or analysis history is lost if the system is forced to restart due to memory overrun.
However, if CPU resources are the bottleneck, no restart occurs, but instead packets are dropped because the CPU does not accept from the network interface card more than the amount of traffic it can cope with.
If the NAM Probe can cope with the traffic for the first few hours of peak time without restarting or dropping packets, it should be able to handle similar traffic all the time.
NAM Probe monitoring interval
By default, NAM works with five-minute monitoring intervals. This means that the NAM Probe monitors all relevant traffic that is directed to the device, but it produces measurement data every five minutes. Then the report servers take the data, process it, and store it in the database for reporting purposes.
NAM Probe load sharing
It is possible to configure two or more NAM Probes to receive the same traffic, with each analyzing only a part of that traffic.
This approach requires that an exact copy of the traffic be sent to each NAM Probe, subject to data center architecture and available hardware. Such load sharing will immediately divide the load by the number of NAM Probes, and thus correspondingly lessen the resource (CPU and memory) usage of each NAM Probe.
Sometimes tapping a mirror port cable is a good solution. Alternatively, you may be able to use Gigamon mirror port sharing. Note that a Gigamon switch can provide load sharing functionality by itself, which is a better solution if more than three or four NAM Probes are to be used in such a setup. However, do not oversubscribe the mirror port. Refer to the vendor documentation for details on checking loads.
Load sharing inside a data center is not useful if there is a small number of monitored client-server pairs or if the distribution of load between the different pairs is very uneven. Automatic load sharing is designed to split the processing evenly if the load distribution is fairly even between a large number of the client-server IP pairs. Therefore, if you have a large number of client-server pairs but the bulk of the traffic is generated for only a few pairs, the statistical load sharing based on IP combinations will not work properly.
To achieve load sharing for a small number of client-servers pairs, you can configure these specific addresses explicitly in the NAM Probe configuration rather than rely on automatic load sharing based on IP combinations.