Foundry Targets Midsize Switch Market

ServerIron brings corporate-class content networking to the masses.

February 3, 2003

5 Min Read
Network Computing logo

I tested a beta version of an SI 100 model 8GC02GF (eight gigabit copper ports, two gigabit fiber ports) in our Green Bay, Wis., Real-World Labs® and found it not only flexible in its deployment options but straightforward to configure and manage. The model I tested does not provide tristate support--the gigabit copper ports are gigabit only. If you need 10/100 support, check out the SI 100-2402, which offers 24 10/100 ports and two gigabit fiber uplinks. A third option, the SI 100-8G, provides eight gigabit fiber ports.

Foundry will distribute the SI 100 series with the newest version of its OS, 8.1.00. The Cisco IOS-like CLI (command-line interface) provides a familiar environment for configuration and management. For those who prefer a GUI, the SI 100 also offers a robust, Web-based interface.

Attack of the Clones

I began with a Layer 4 HTTP load-balancing scenario, using Spirent Communications' WebReflector to emulate six Web servers. After configuring the first real server, I cloned it to configure the remaining real servers. This one-step process for adding new machines to the server farm not only saves time, it binds each real server to the appropriate virtual server.

Good

• Fixed-configuration bundles offer midmarket choices
• Competitive pricing
• Standard redundant power supplies
Bad
• Vague rule creation
• Rack hog: 5U chassis for limited port density (eight gigabit copper ports, two gigabit fiber ports)
• Gigabit copper ports are not tristate; GB connectivity only
Vendor Info
ServerIron 100 Series, starts at $34,995. Foundry Networks, (408) 586-1700. www.foundrynetworks.com

Content-aware switches typically require that at least one group be configured in a Layer 4 load-balancing scenario. SI 100 does not require any groups to be configured at Layer 4. Rather, binding all real servers to the virtual server eliminates the need to create a group. This makes it a breeze to configure a simple Layer 4 SLB (server load-balancer). Groups must be created for load-balancing at Layer 7 for both the SI 100 and competing switches. My only complaint is that groups are assigned numerical IDs and cannot be given descriptive names. I find it intuitive to use string-based names, such as "images" or "cgi_content."Rule creation is more complex than it is with some of SI 100's competitors, but it's by no means difficult. Rules are called "policies" and can be nested, making it easy to configure even a complex Layer 7 load-balancing scenario. A policy can include a default, which allows rule chaining.



URL Switching Types
click to enlarge

Client Tests

Once I configured the real servers, I fired up a WebAvalanche to emulate clients, and I performed several tests in the Layer 4 configuration. The SI 100 was able to process 13,000 HTTP 1.1 gets per second.

Next I reconfigured the device for Layer 7 SLB by creating three separate groups--one for text (HTML), one for images and one for CGI-based content. Industry-standard Layer 7 options are available, including switching based on cookies, SSL session ID and host name, and by URL. The Layer 7 configuration binds servers to groups and lets a server be bound to multiple groups. Therefore, you can bind a real server to a range of groups and have the option of configuring a maximum of 2,048 real servers and 1,024 groups. This should be more than acceptable for a midsize enterprise.



Performance Results
click to enlarge

Changing LayersAfter switching from a Layer 4 to a Layer 7 configuration, I ran the WebAvalanche again. Results showed the expected increase in response time--14 ms at Layer 4 to 5,870 ms at Layer 7--and a decrease in the number of gets per second served--10,000 at Layer 7 versus 13,000 at Layer 4 (see "Performance Results," above).

Although the SI 100's $34,995 starting price puts it in the same field as F5 Networks' competing devices, the series will appeal to the midmarket enterprise in need of an affordable, high-availability Layer 2-7 switching solution. The advantage of not having to configure groups at Layer 4 and the ability to clone servers give this content switch an edge. Still, Foundry may want to address the complexity involved in building rules and group/VLAN identification issues before it goes head-to-head with F5.

Technology editor Lori MacVittie has been a software developer and a network administrator. Write to her at [email protected].

SLB Down and Dirty

Here's the skinny on server load-balancing. A server load-balancer is typically a switch or appliance whose purpose is to distribute client requests to one of several real servers, increasing the capacity of a particular network service, such as Web or FTP servers. A real server is a real machine in the infrastructure processing client requests as directed by the SLB. In many load-balancing scenarios, the virtual IP is the public address of the service--the address used by the client to make requests.

The diagram at right shows a typical SLB network configuration. Other scenarios are possible, but none would change the basic flow of data.Server Load-Balancing Step-by-Step

1. The client makes a request to the VIP serviced by the SLB.

2. The SLB determines which real server should respond using an administrator-specified algorithm, such as round-robin, least connections or fastest response time. This algorithm may include Layer 7 rule information. For example, requests for images may always be directed by the SLB to Group 2 while all other requests are sent to Group 1.

3. The SLB usually will track the session between the client and the target real server and direct subsequent requests from the client, where possible, to the same real server. This quality--persistence in load-balancing parlance--is necessary for many types of Web applications to function correctly--especially those involved in e-commerce or those utilizing cookies for personalization. This also means less interruption of service in a failover situation: The sessions are mirrored on a secondary SLB so if the primary SLB fails, the secondary continues to direct clients to the proper server.

4. The real server processes the request and returns the response to the client.

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox
More Insights