|
|
|
Unsupported Hardware/Configurations:
- VMware
- SAN (Storage Area Networks)
Server hardware requirements depend entirely on the size of the network being
monitored and the type and volume of data being collected, stored and processed.
Monitoring a small number of SNMP objects (e.g. a 10,000 interface network) and a
couple of low volume NetFlow collectors will only require a current model
commodity PC.
For best performance we recommend the following:
Up to 20,000 network interfaces and minimal NetFlow collection requirements:
- 64 bit Dual Core CPU, with 2MB of L2 cache for each core
- 2GB RAM
- 500GB Hard Drive
- Gigabit capable NIC
Up to 50,000 network interfaces and average NetFlow collection requirements:
- 64 bit Quad Core CPU, with 2MB of L2 cache for each core
- 8GB RAM
- 1TB Hard Drive
- Gigabit capable NIC
For more than 50,000 network interfaces or large NetFlow deployments, please contact
Statseeker Technical Support for assistance.
For a detailed list of supported chipsets go to:
FreeBSD Supported Hardware.
Statseeker does NOT recommend RAID 5 or 6 due to their relatively slow access speeds.
Statseeker RECOMMENDS the use of a single large disk or disks configured as RAID 0 or RAID 1.
Click here for more examples of Hardware Configurations.
A detailed discussion on hardware requirements follows:
- CPU Type
-
Number of CPU cores
There are many different CPU types, clock speeds and cache configurations available today. Statseeker's
pollers, packet capture and analysis modules, NetFlow collectors and databases use concurrent
real time processing which can make use of multi core CPUs.
Multiple CPU cores allow user initiated reports to be generated without effecting the real time
data collection and processing.
Virtual CPUs were available in many older Intel CPUs via the hyperthreading feature.
Hyperthreading is not a real CPU core and provides no benefit to Statseeker. Make sure hyperthreading
is turned OFF in the BIOS. Note: Your BIOS may use the term "Logical Processor" when refering
to hyperthreading.
-
64bit vs 32bit
Statseeker is designed, coded, profiled and tested on 64bit architecture. We do release a 32bit
version but place a heavier focus on our 64bit stream.
One of the major problems with the 32bit architecture is that it has a maximum physical memory
addressable limit of 4GB. In practice, a 32bit PC is limited to 2 to 3GB of
addressable RAM because peripheral devices such as video cards and disk controllers use chunks
of the address space below 4GB and the RAM is remapped by the BIOS to above 4GB, which is out of
the reach of a 32bit operating system. 64bit architectures do not have this severe limitation.
Note: Many of the internal data types and structures in Statseeker are 64bit, and therefore the
software will run faster when loaded on a 64bit operating system.
-
CPU speed, cache size and memory speed
The fastest CPU is not necessarily the highest clocked chip, but more a combination of CPU clock,
cache size and main memory speed. L1 cache is small, but a lot faster than L2 cache, which in turn
is a lot faster than accessing main memory. Code written to run mostly in L1/L2 cache can be orders
of magnitude faster than code accessing main memory. Much of Statseeker's code is tuned to utilize
CPU cache efficiently.
- Memory Size
Statseeker requires an ample amount of free memory to operate efficiently. Many of the modules
allocate large amounts of memory.
For example:
- database processes map large files directly into active memory
- the ping/SNMP pollers allocate ICMP/UDP socket buffers so bursts of incoming responses are not dropped
- the pollers build all requests once at start up and leave them in memory
- SNMP processes load the entire set of compiled MIBs into memory
- processes which communicate via pipes allocate large read/write buffers
- user requests load all the necessary data into memory before producing the relevant reports/graphs
- the timeseries database performs its own background preemptive file read-aheads, which fill inactive
memory with useful content before it is needed
- netflow collectors allocate large UDP socket buffers so bursts of incoming packets are not dropped
- each LAN Analyzer allocates large kernel and user process buffers
If Statseeker runs short of free memory it will swap memory contents out to disk which will have
a drastic effect on performance.
- Disk Space
Statseeker requires an ample amount of free disk space to operate efficiently. The various databases
are made up of extremely large files and it is important that these files are written to the file
system in a sequential order. When these files become fragmented, disk seek times will and database
performance both drop off dramatically.
It is important to note that the Statseeker time series database will utilize three times its
maximum daily disk allocation size as part of its daily validate, compact, and backup processes.
It is also important to note that the main consumer of disk space is NetFlow. Monitoring NetFlow
on a busy core router that has many unique IP conversations/protocol combinations can consume
an enormous amount of disk space quickly. Be sure to have a large amount of free disk space if
you wish to deploy NetFlow.
- Disk Speed
For optimum performance, Statseeker prefers a disk with fast seek speed and a large on disk
cache (16-32MB) to assist with large sequential reads and writes. The raw sequential read/write
speed is determined by how fast the disk spins and the bit density on the platters. A larger
disk (ie higher bit density) can read/write more data per revolution than a smaller disk (which
needs to spin a lot faster to make up for the performance loss). There may be no performance
improvement by selecting a smaller, often more expensive disk with faster transfer speeds.
The two modern interface types are SATA (serial ATA) and SAS (serial SCSI). Statseeker runs
and performs extremely well on a SATA disk so there is no need to buy expensive SAS disks.
Note: A SAS controller is backwards compatible with SATA, so you should be able to plug a SATA II
disk into a SAS controller without a problem. Vendors rarely mention this as they prefer to sell
you the more expensive SAS disks.
In practice, a SATA disk is as reliable as a SAS disk. Refer to the following Google disk
reliability study: http://storagemojo.com/2007/02/19/googles-disk-failure-experience/
- RAID
Statseeker has done extensive research into various file system and RAID configuration combinations
to determine optimum performance criteria and therefore recommend the following:
- Do NOT use any of the parity RAID configurations (such as RAID 5 or 6) as their performance can be
ten to fifteen times slower. Statseeker will not operate correctly while a RAID
5/6 system is rebuilding itself due to its dismal disk performance.
- For pure performance, a striped (RAID 0) configuration with a 128KB stripe size will give a
fairly optimal performance. Note: Many controllers appear to default to a 64KB stripe size.
- For redundancy, a mirrored (RAID 1) configuration will perform well. Depending on the controller,
read performance will be better than a single disk as the controller can read different parts
of a file from each disk.
- For both performance and redundancy, a striped/mirrored combination (RAID 1+0 or 0+1) with a
128K stripe size is best.
Statseeker developers have performed a great deal of RAID testing using a single core 500Mhz LSI
MegaRAID controller (Dell Perc 6 equivalent) and a dual core 1.2GHZ Adaptec controller, with batteries
installed and write caching enabled. Both controllers performed well, but the cheaper LSI
controller was a performance bottle neck in large six disk RAID configurations. All testing
was performed using commodity 7200RPM 500GB SATA II disks.
- Ethernet Controllers
Use a Gigabit capable NIC. Do NOT use a 10/100Mb NIC. Our testing has shown that the
performance of the pollers deteriorates when running on 10/100Mb NICs.
The ping pollers maximum rate is reduced from more than 60,000 per second to 3,000 per second,
a 20 times drop in performance.
- Hardware Configuration Examples
(Large Networks)
This specification should scale to 50,000 interfaces and a moderate amount of NetFlow collection.
- Motherboard
- Intel DQ35JO Desktop motherboard with onboard Intel Gigabit NIC
- CPU
- Intel Core2 Quad Processor Q6600 with 2MB L2 cache per core
- RAM
- 8GB
- 4 * 2GB 667Mhz DDR2 modules
- Installed in pairs for 1066Mhz memory bandwidth
- Disk
- 750GB Seagate 7200RPM SATA II
- 32MB on disk cache
- raw sequential read performance of ~105MB per sec
|