At ORCS Web we use Foundry Server Iron products to perform our webfarm load-balancing. If one of them fails, other instantly takes over (In our testing, it had sub-second fail-over!)

So what is this "Server Iron" thing? In simplest terms, it's a layer 4-7 switch. It has multiple network ports on it and can be used literally like other types of switches. But, it can also load-balancing and traffic distribution. A VIP (virtual IP) can be assigned to SI (Server Iron) and it then handles all traffic sent to that address/VIP. Further configuration is done to tell SI what to actually do with traffic sent to VIP address.

The traffic that hits VIP on Server Iron is of course redistributed to a number of server nodes so client request can be satisfied - that's whole point of a webfarm. If one or more server nodes are not responding, switches are able to detect this and send all new requests to servers that are still online - making failure of a server node almost transparent to client.

The traffic can be distributed based on a couple different logic algorithms. The most common are:

* Round Robin: The switches send requests to each server in rotation, regardless of how many connections each server has or how fast it may reply.

* Fastest response: The switches select server node with fastest response time and sends new connection requests to that server.

* Least connections: The switches send traffic to whichever server node shows as having fewest active connections.

But what about servers and applications? Why spend so much time up front configuring network to make sure it doesn't fail, and then deploy an application to a single server?

Sure, there are ways to make sure individual servers have some redundancy to minimize failures -- things like RAID1, RAID5, or RAID10 (redundant array of inexpensive disks) which will protect against a disk drive failure (and I highly recommend this type of configuration for all production servers - and preferably use of hardware RAID vs. software RAID). But what happens if a file gets corrupt on RAID array? Or a recent configuration change brings application down? Or a newly released patch conflicts with other settings and causes problems? Well, in these situations server will go down and application(s) hosted on that server will be offline.

A good monitoring and alerting process will allow system administrator to detect and address these issues quickly, but still there will be some level of downtime associated with issue. And depending on type of issue, even best system administrator might not be able to immediately resolve issue - it may take time. Time during which your application is unavailable and you may be losing business due to site interruption.

So, what can you do?

A great option - and one that has recently become more affordable - is to host your application on a webfarm. A webfarm consists of two or more web servers with same configuration, and that serve up same content. There are special switches and processes involved that allow each of these servers to respond to a request to a single location. For example, say we have two servers - svr1.orcsweb.com and svr2.orcsweb.com - that have 100% same configuration and content. We could configure a special switch* to handle traffic that is sent to www.orcsweb.com and redirect traffic to either of these nodes depending on some routing logic. All clients visiting main URL (in this case www.orcsweb.com) have no idea whether this is a single server - or ten servers! The balancing between nodes is seamless and transparent.

[*note: There is also software that could handle routing process but experience and test have shown that these types of solutions are generally not as scalable, fast, or efficient as hardware switch solutions]