But virtual hosting of Web sites had already been there and done that. While six or more Web host addresses might resolve to the same IP, somehow the Web server determined to which host the request was destined and got it to the site. How? By examining the host header in the request, of course.
Then (probably at 2 in the morning) someone decided that putting this function in a load-balancer would be a good idea. After all, load-balancers, unfettered by the need to perform other processing, could perform this function more efficiently than a Web server burdened by a plethora of processes unrelated to Web-based services.
However, the folks at Cisco Systems (with its acquisition of ArrowPoint Communications), F5 Networks, Foundry Networks and Nortel Networks (with its purchase of Alteon WebSystems) came up with a different idea, and it was a good one. Content switches offer the ability to route traffic based on Layer 7--the application layer of the OSI model--paving the way for optimization of server farms by routing requests based on the content and services offered.
OK, so you know the advantages of a content switch, but how do you choose one switch over another? Today's market is flooded with offerings not only from Cisco, F5, Foundry and Nortel, but from ClickArray Networks, Extreme Networks, HydraWeb Technologies, Intel, NetScaler--the list goes on. So what's the method to the madness of choosing?
You'll need to consider three basic features: the device's logic set, fault tolerance and management. After that, ponder all the additional features found in today's devices--support for 802.1p QoS (Quality of Service), SSL acceleration and cache-redirection capabilities. Then, as always, take into account the number and type of interfaces provided to your network. Finally, factor in the price.
Logic
A content switch's logic- and rule-set capabilities are at the heart of the device. Without these features, the device is simply a load-balancer. Rules bind specific URL or URL patterns to a cluster, or pool, of servers. One such rule might be "everything with the extension .cgi should be routed to Cluster X while everything else should be directed to Cluster Y."
The method for configuring this particular rule set varies greatly from switch to switch. In our experience, F5's Big-IP HA+ controller offers the most control over rule configuration. You can create two rules or a single rule using a simple if-then-else syntax. Other vendors provide alternative methods for defining rules, such as suffix/prefix matching and regular expressions, while others offer rules based on a deeper level of packet examination. With Intel's XML Director you can define rules based on the URL, as well as on the tags found within an XML (Extensible Markup Language) file.
Two other logic-set features to look for are the ability to use the not operand to negate a rule and the ability to set precedence on rules. Precedence lets you designate the order in which rules are applied to a request. And so the above example uses two rules--first apply the rule that catches requests containing a .cgi extension and then apply the "catch all" rule. Without precedence, the rule set for this simple configuration would be larger and more complicated.
Persistence is often required by the applications being front-ended by a load-balancer. If a shopping cart were started on Server X in Cluster Y, the client must return to the Server X to preserve the session. Many content-switch vendors offer persistence via cookies.
Most switches simply examine server-inserted cookies, but Nortel's release of WebOS 9.0 provides a mechanism for the switch to insert the cookies instead. SSL session ID was once used in commerce-oriented environments, but recent releases of Microsoft Internet Explorer--which by default renegotiates the SSL session every two minutes, and subsequently the session ID--have made the use of this for persistent connections to servers moot.
SIP (Source IP) can be used, but proxy servers and NAT (network address translation) present issues since multiple customers will be bound to a single server in the cluster and the load will be distributed unevenly.
Once rules are configured they must be bound to a cluster or server, or vice versa. Three methods are generally used to bind rules to clusters. Two methods involve the rule and a cluster: Either a rule is bound to a cluster or a cluster is bound to a rule. F5 uses the former, Foundry the latter. A third method, used by Intel and Nortel, is unwieldy and time-consuming: It binds rules directly to individual servers. If your cluster is large, this could be painful. However, this method lets you easily add or remove a server for processing particular requests, which can be advantageous in circumstances requiring a quick change of configuration.
Fault Tolerance
No vendor likes admitting its product might fail, but this happens. Circumstances beyond your control can drop a box quicker than a klutzy kid drops ice cream off a cone. But unlike ice-cream vendors, content-switch vendors offer redundancy and failover processes to ensure that if a device fails, another is waiting.
Failover configuration comes in two flavors (hey, it ain't Baskin Robbins): active-standby mode and active-active mode. In active-standby mode, one device is designated primary, the other secondary. The secondary device does nothing until the primary fails, at which point it jumps in. In an active-active scenario, one device is still the primary, but the secondary device is allowed to participate actively, aiding the primary and ensuring availability even under high loads and added capacity.
Failover topologies are performed via a serial connection directly linking the primary device with the secondary, or more commonly via the network. The former method provides almost instantaneous failover, since the secondary recognizes failure in a microsecond.
Network-based failover is more complicated and often involves the use of OSPF (Open Shortest Path First), making the failover process longer as the router adjusts the routes when the primary device no longer responds. Network-based failover is advantageous in a global load-balancing architecture because it offers continuing services in the face of disaster (blackouts, tornadoes, forgetting to pay the electric bill). Many vendors support only one or the other. Alteon and Radware use the network; HydraWeb uses a serial connection. F5 offers both types of failover.
Fault tolerance not only applies to the device, but takes into account the ability to designate backup servers in the clusters. These servers may simply wait for a failure, or they may do other processing that can be pre-empted by a fault in another machine. The switch must provide this ability since machines do fail--often when they're needed most.
RSS
