Building a Linux Virtual Server

prostoalex writes "NewsForge (an OSTG site) has an article that discusses the details of building a cluster for a virtual server - an environment where one can add and remove machines as needed, to account for high-traffic Web site of intensive database application: 'The main advantage of using LVS is that unlike Microsoft network load-balancing clusters, the LVS allows you to add a node running any operating system that supports TCP/IP to the cluster.'"

PC's are not for networking

[gtrubetskoy]

First of all, the Linux Virtual Server project is a misnomer, because a Virtual Server these days means a virtualized operating environment similar to what is provided by VMWare, Xen, Linux Vserver, etc.

Second, IP Load Balancing is not new and is much better done by a hardware device such as Cisco CSM, Foundry ServerIron, Nortel Alteon, etc. These things boot in seconds, use ASICs, can process orders of magnitudes more packets per second than a Linux box can, have no moving parts (except for the fans), are aesily configured, can be set up in a fail-over configuration, speak routing protocols, etc, etc.

The Linux Virtual Server is a good project to tinker around with if you would like to understand load-balancing concepts better and do not have the $$$ for a hardware device, but I would not even consider designing a mission-critical solution using LVS instead of a hardware load-balancer.

I remember back in my ISP days we purchased a small provider with a few T1's all running on Linux-based routers. They had a tendency to lock up and were very awkward to manage for many reasons (e.g. upgrading the kernel was a risky procedure that required way more downtime than necessary) and we replaced them with real routers pretty quickly. I kinda suspect that Linux Virtual Server may be a similar type of experience - PC's just don't make good network devices for some reason.

Of course I'll probably get flamed for this comment...

What about transparancy?

[Jailbrekr]

With any load balancing solution, if a server goes down with an active connection, that connection gets reset. It doesn't matter if you are using LVS, pen or pound, the level of transparancy isn't quite there yet.

Personally, I am an advocate of pound for http/s load balancing, because its simple, has central logging, and handles ssl authentication itself (thereby keeping the back end servers simple)

Check it out:

http://www.apsis.ch/pound [apsis.ch]

DEC was leading this field in the late 1980s.

[CyricZ]

DEC did a fair bit of research and development into such composite systems back in the late 1980s. That is why today systems like Tru64 UNIX are so adept at virtual networked systems. It's too bad that HP has squandered the gem it picked up from DEC (via Compaq) in Tru64.

Actually...

[jd]

...A cluster is exactly what you want, as opposed to one of these virtual servers.

A "true" virtual server allows a cluster to be treated as a single machine, from the outside. However, the problem with LVS - and similar technologies - is that they don't do this very well. You often have a single entry point, which means that communication suffers from the bottleneck.

Ideally, what you want is for ALL the machines to be capable of receiving connections, so that connections can be striped across the farm, which means that you aren't slowed by connection limitations.

What you then want is to transfer connections within the farm, so that you can balance load by resources available, rather than by simply giving each machine an equal number of connections.

Finally, the internals of the farm need to use some very good communications systems. GAMMA looks good, and I'd probably advise using Lustre or GFS over SMB or NFS.

WLBS vs LVS

[markclong]

Looking at these images (LVS [newsforge.com] and WLBS [microsoft.com]) it seems with LVS there is a single point of failure with the load balancer box. With Windows load balancing there is no "balancer box" and if any one server fails the cluster continues without missing a beat.

How does LVS work if the balancer box fails?

Re:PC's are not for networking

[SirGeek]

Toss in a 2nd PC, use Mon, and use Linux HA [linux-ha.org] and you've got yourself a high availability cluster that can route almost TCP IP or UDP traffic for far less cost than a "real" load balancer not to mention can do far MORE than a load balancer. We are using LVS and HA at my 9to5 job for load balancing our new Webservers. ITs super reliable. We have it such that within 10 seconds of a web server not being available, its removed from the LB. Once its back up and running, it adds the server back in automatically.

Re:PC's are not for networking

[AtlanticGiraffe]

Many administrators prefer out-of-the-box solutions. There are good reasons for that. Their simplicity makes them secure, because there are fewer opportunities for mistakes. This is a completely valid point that should always be taken into account when choosing a load balancer.

That said, Linux Virtual Server is relatively easy to set up (for your average unix sysadmin), very reliable, fast and scalable. It is not inherently slower, less reliable or more dependent on moving parts than any hardware solution. If you prefer no moving parts, run LVS on a solid state machine. Don't judge it by the hardware others choose to run it on.

With keepalived, eliminating the obvious "single point of failure" is no problem at all and various scripts have been written to facilitate LVS cluster management. We all know that any piece of hardware will eventually fail, be it from Intel, Western Digital or Cisco. Therefore, redundancy is usually a better bet than "reliable" hardware.

When your LVS box gets heavily loaded (meaning that you did something wrong, used hardware from the early nineties or got slashdotted), you can upgrade it at will. Replacing your 1.5GHz Intel chip with a 3.0GHz one should be a lot cheaper than buying a new Cisco box.

And one last point: Having a full-fledged OS running on the frontline can be convenient and may allow for better hardware utilisation. For example your LVS box might run a realserver itself, or other services that have nothing to do with the cluster. Scalability means being able to scale down as well as up.