Network Computingwww.networkcomputing.com

It's All Inside

With dual fiber gigabit connectivity driven by a Free-BSD core, this 2U form factor load-balancing appliance is a scalable, high-availability solution that can reduce the need for additional servers in the farm. Traditional load-balancing, even at Layer 7, doesn't always manage HTTP requests beyond examining the URL/host header and directing the traffic to an appropriate farm. The Request Switch 6500 effectively balances distribution of those HTTP requests.

The switch offers industry standard load-balancing support for round-robin and weighted round-robin algorithms, least connections, response time, hashing (URL, domain, source or destination IP) and cookie, source IP, SSL (Secure Sockets Layer) session ID and server-based persistence. It provides server health checks via customizable HTTP requests or TCP connectivity. You can limit connections to a given server to ensure the server is never pushed past its limits. In addition, the Request Switch 6500 detects SYN attacks to protect against flooding and provides packet filtering via access-control lists to offer flexibility in controlling access to the device and its services.

NetScaler distributes the product as a redundant pair, with a price that's comparable to the cost of a single unit from its competitors: An entry-level pair of Request Switch 6500s starts at $15,000, and a high-end duo tops out at $35,000. By consolidating logging capabilities and including its now standard SureConnect technology--a sort of hold music for the Internet in case of a busy site--NetScaler has made the Request Switch 6500 a well-rounded, content-aware load-balancing solution.

Management Features

I tested a beta version of the product in our Green Bay, Wis., Real World-Labs®. Two of the most significant updates in the switch are the inclusion of a Web-based GUI and the integration of the CLI (command-line interface). In prior versions of NetScaler's management tools, the CLI and the Java-based GUI were accessed remotely. Unfortunately, the updates were not available in time for my testing, so I used the existing remote GUI for configuration and management. NetScaler assures me that the Web-based GUI is laid out like the Java GUI and that the integrated CLI is the same as the remote CLI. After working with the GUI for a few days, I'm not entirely certain that's a good thing. I wasn't able to pinpoint what I disliked about the user interface--it just felt clunky.

To begin testing, I inserted the Request Switch 6500 into the network and powered it on. Initial configuration via the console is required and was a simple process. Some of the terminology threw me off--"mapped IP," for example, is the local IP used to communicate with servers--but with the help of NetScaler's excellent documentation it took me only moments to do the initial configuration.

Once I finished setting up the product for network connectivity (in a reverse proxy configuration), I was faced with the real configuration work. The three Microsoft Internet Information Server Web servers in my farm had to be added, as did services for each. HTTP or HTTPS (HTTP Secure) can be specified, and each service is tied to a single server. I also added three additional Web servers and their respective services, which were provided by Caw Networks' WebReflector.

The Request Switch 6500 applies switching logic to a content virtual server, with each rule being bound to a server. The binding logic is quite flexible and offers the ability to build a complex infrastructure based on combinations of virtual services, single services, rules, policies and URL parsing.

Performance

From this point, I began to hammer at the virtual site with Caw's WebAvalanche stress-testing appliance, directing half my sessions to get index.html and half to get default.asp. The Request Switch 6500's performance was acceptable; it handled an average of 9,000 HTTP transactions per second. The requests were evenly distributed, which was expected given that I had requested only a single object for a single TCP connection. I reconfigured the WebAvalanche to request more than one object per session and returned to the test. Giving credence to NetScaler's claims, the requests were still evenly distributed across the servers.

I then reconfigured the Request Switch 6500 to use a policy for the virtual server fronting the IIS servers, denying all requests for objects with an .exe extension. No Nimda for me! I quickly reconfigured the WebAvalanche, and the Request Switch 6500 performed well once again, denying the requests for root.exe and serving up all other content.

Cool Tool

The aforementioned SureConnect feature can display coupons, ads, pictures and other distractions to users whenever content is not immediately available. Although this is definitely a cool feature, you might be wondering why it's necessary if the product scales and performs as advertised. While surges of sudden traffic may not render a site unavailable, they may increase response times beyond what most users are willing to accept. Notifying a user that a page is taking a bit longer to load than expected may encourage that user to hang around and wait--especially if the notification comes with a coupon or a free gift, or a really funny cartoon. Or the promise of free Mountain Dew.