Hardware and Software requirements for Stingray Traffic Manager

[#1]

Stingray Traffic Manager is supported on any modern Linux operating system, running on standard x86 (32 and 64 bit) platforms.  Riverbed develops and routinely tests the Stingray software on various systems, including RedHat Linux, CentOS, Debian, Ubuntu and SuSE, and on a range of hardware and virtualized platforms (VMware, Xen, OracleVM, KVM and HyperV).

Stingray’s requirements on the operating system (OS) are light and there are no non-standard dependencies between the software and the OS.  We recommend a modern kernel (2.6.39 or later, or 3.0 or later), and very strongly recommend a 64-bit variant of that kernel for performance and scalability (memory size) reasons.  You should select the OS based on your preferred supplier and your internal expertise.

Stingray will operate on any industry-standard x86 server hardware that is supported by the operating system vendor.  If you intend to use any non-standard hardware (third-party network cards for example), you should verify that they are adequately supported by your chosen OS vendor.  Riverbed does not publish a preferred hardware list, and we test with a range of components on HP, Dell, IBM, Sun/Oracle and other hardware.

Minimum hardware requirements

• CPU: CPU-bound operations such as SSL decryption depend on available CPU resource and they typically scale linearly with the number of cores available and the clock speed.  A minimum of 4 cores is recommended for a moderate workload, depending on configuration.  Stingray scales comfortably on 12-16 core systems.
• Memory: A minimum of 2 GB memory is recommended, although Stingray will function comfortably in 512 MB or less with low traffic levels.  Additional memory will increase the number of concurrent connections that can be sustained (approximately 50,000 concurrent connections per Gb memory), and additional memory may also be used for content caching and other internal traffic manager caches.
• NICs: Stingray is typically deployed in a 2-armed fashion (a front-end and a back-end NIC), sometimes with an additional management interface.  There are no software limits on the numbers or types of physical interfaces that can be supported.  Routing, tagging and interface bonding are performed by operating system configuration and do not affect the operation of the Stingray software.

Security configuration

Stingray has a strong security model.  The software is installed and run as the root user and the processes that handle network traffic explicitly drop privileges and run in a local chroot jail.

You may use additional security measures such as SELinux and iptables if desired.

Expected performance

Riverbed publish performance data that is based on benchmark testing of Stingray software on a range of hardware platforms.  This data will give an indication of what is possible, but real-world throughput and requests-per-second data is very dependent on latency, packet loss and traffic types and will deviate from what was achieved in ideal conditions.  If you have firm performance requirements, you should validate that Stingray can meet them with real-world traffic (just as you would with any ADC device – software, virtual appliance or hardware).

Note that Stingray software is licensed on real performance, not on theoretical performance.  You are free to select the hardware that best meets your needs, and upgrade at any point.

 

Installing the Stingray software on the target host

Stingray software should be installed and run as root.  Root privileges allow the software to bind to low ports (e.g. port 80) and to allocate additional operating system resources (e.g. file descriptors).  For detailed installation instructions, refer to the Software Getting Started guide.

Installing additional software components on the target host

Stingray software can take advantage of two Riverbed-supplied kernel modules that extend the packet-handling capability of the Linux kernel (see Stingray Kernel Modules for Linux Software):

ztrans

The ztrans kernel module exposes a hook into the IP stack’s NAT capability, allowing Stingray to control source-NAT for outgoing traffic.  This capability is used by Stingray’s IP Transparency functionality to force the source IP address of traffic to the back-end servers so that the connection appears to originate from the remote client’s IP address (or another non-default address if desired).  ztrans depends on standard kernel modules (nat, conntrack, ip_tables) which are loaded automatically if required.

NAT and connection tracking adds a significant load to the kernel as all ingress traffic that is not addressed to a local interface must be matched against the kernel NAT table, and entries in that table must be managed.

You can safely compile and register the kernel module.  It is only loaded if you enable IP Transparency on one or more pools, but the performance hit is incurred against all traffic processed by the kernel.

zcluster

The zcluster kernel module applies a low-level filter to the IP stack.  This filter is used by Stingray’s multi-hosted IP address capability; a multi-hosted Traffic IP address is raised by several Stingray devices using a common multicast MAC address.  Traffic destined for that IP address is multi-casted to all the Stingray devices and the zcluster module filters the packets so that each UDP datagram or TCP connection is handled by a unique traffic manager in the cluster.

The zcluster module does not add a significant load to the kernel, but the use of a multicast address means that ingress network traffic is replicated across two or more Stingray devices, increasing the traffic volume that each Stingray must process.

In practice, the effect is generally low.  The total volume of ingress traffic to each Stingray is capped by the available upstream bandwidth, and in the majority of cases, ingress traffic is significantly lower than the egress traffic (protocols like HTTP are generally very asymmetric).  The zcluster kernel module can be safely compiled and registered; it is only loaded and activated if multi-hosted IP addresses are in use.

You can download the source for these kernel modules here: Stingray Kernel Modules for Linux Software  Note that these modules are pre-installed in Stingray Virtual Appliances and they are not available for Solaris.

Stingray Traffic Manager does not require any other specialized kernel modules.