Dynamic ratios use SNMP queries, which poll the physical servers, gauge system utilisation and automatically reduce traffic sent to overloaded servers. Priority groups can be used to add extra levels of redundancy to virtual servers. For example, in a pool of ten physical servers you can give five a higher group priority, which means only they will have traffic directed at them. If one fails then a server from the lower priority group is brought in to replace it.
For virtual servers you provide an IP address, decide on the type of service on offer and assign a pool to them. The HTTP profile offers traffic optimisation and acceleration, which could be useful for slow WAN links. Along with compression, the blades can also cache HTTP objects in memory to improve web server responses.
For testing we created server farms providing web, mail and FTP services to our test clients, which were located on a different subnet. We found this process simple enough and created virtual servers for each service using the appropriate port numbers and then assigned a pool to them. Resilience was tested by running an FTP transfer from a client to the virtual server and pulling one of the blades out during this. The Viprion barely blinked with the result that the FTP transfer continued unabated we've seen other HA solutions take too long to reconfigure themselves causing FTP transfers to time out.
For basis connection persistence you have Layer 4 inspection, which uses source and destination IP addresses or SSL session IDs to ensure a specific client is always directed to the same server. Layer 7 inspection takes connection persistence up a notch as you can use actual content along with features such as application session IDs, URLs and cookies. It's hardly surprising that cookie based persistence is on the agenda as F5 patented this technique a number of years ago. You also have universal persistence, which maintains a state table using any information gathered from Layer 4 through to Layer 7 inspection
F5's iRules offer some interesting features as these use custom policies to decide how specific traffic should be handled. They can be used to inspect HTTP traffic for data such as credit cards numbers and replace them with hashes. VoIP traffic can be identified and prioritised or you can use iRules to inspect HTTP content and direct clients to specific servers based on information such as URI, cookie or HTTP response codes.
Reporting is the only area where F5 is found wanting. There are plenty of real time graphs showing traffic throughput and blade performance from the web interface but full reporting requires integration with separate third party management packages.
During its stay in the lab the Viprion impressed us mightily with its huge range of features. The automatic blade clustering feature also makes upgrades extremely simple and the well designed web interface makes light work of configuration and management.
Verdict
The Viprion sets new standards for enterprise level application delivery, with seriously good resilience, scalability and performance. Load balancing features don’t get any better either and yet during testing we found it remarkably easy to deploy and manage.
Viprion chassis: 7U rack with four blade slots, 4 x 2000W hot-swap power supplies and hot-swap fan tray
Viprion Performance Blade 100:
CPU: 2 x 2.6GHz AMD Opteron
Memory: 8GB 667MHz DDR2
Storage: IDE hard disk
Acceleration: 2 x Cavium Nitrox-PX
Network: 20 x Gigabit Ethernet (8 x copper, 12 x SFP), 2 x 10GbE XFP, 10/100 management
Management: Web browser, SSH, local console
