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.'"
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...
http://www.keepalived.org/
...
What is Keepalived ?
So in short keepalived is a userspace daemon for LVS cluster nodes healthchecks and LVS directors failover.
2 years and no mod points. Join reddit. Because openness is good.
The article seems to suggest placing a large number of real servers behind a single virtual server. Surely this is putting a point of weakness in front of a potentially redundant cluster. Load balancing has been done better by specific hardware made by Foundry and the like. I'm not seeing the benefit over 'traditional' clustering with this solution.
Business Voyeur
Do you need to buy special glasses ?
Great for http. Bad for nfs and smb/cifs.
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
Feed the need: Digitaladdiction.net
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.
Cyric Zndovzny at your service.
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Looking at these images (LVS and WLBS) 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?
Now if someone came out with a good embedded linux running lvs with a nice web and cli interface, on solid state hardware, that was a decent amount cheaper than brand name equipment, put up a respectably proffessional looking site, and develop a loyal following, I'd consider it.
LVS is not really new news and it is a nice hack and has some good use cases. But in the real world 'dictated and redundant ' load balancers (such as BigIP, etc..) are the only way you are going to run a 24/7 large dynamic web site. Would you REALLY place ONE box (Linux or not) as the gateway/proxy to your web farm, if so, then make so it is a fully redundant box (including CPU) otherwise on the day after the melt down start looking for another job. And if you really place one fully redundant box as your web farm proxy the money you spent on it is going to 10x the cost of a few BigIPs and that big box is not going to be running Linux anyway.... And a warm LVS spare is not really an option either if you are running a 24/7 site, setting up a keep-alive response system to determine if your LVS box croaked and automatically re-writing some IOS routing to use the warm spare is wrought with issues (I've seen some great setups and hacks, but not something that I would use in any type of business at is counting on revenue from their web site).
And as far as 'intensive database application' as quoted in the article, LVS does nothing for you in terms of database synchronization. If you are running a site generated from fairly static data that is synced once in a blue moon then OK you can roll a SQL engine onto each box in the farm and sync them via remote scripts, but that is not what I would call a 'intensive database application'.
They have different configurations explained here:
o verview.html
http://www.ultramonkey.org/3/topologies/
They even have an example where 2 machines act as both real servers and directors:
http://www.ultramonkey.org/3/topologies/sl-ha-lb-
keepealived allows for hot standby and even active-active setups. Plus LVS syncs state via multicast. Also, no hacking of routing tables needs to be done, the standard IP takeover works. I've used it in production, taken down the primary, failed over seemlessly, state was synced, no lost connections. It worked fine at 1000 connections/second. Have you done this?
2 years and no mod points. Join reddit. Because openness is good.
Unlike most of the posters sharing their 'wisdom' on the merits (or lack thereof) of using PC's for networking ... I can say that I recently setup a load balancer using LVS in front of my Web cluster (of 6 dual Opteron's). It rocks!
:)
You can easily avoid it becoming a single point of failure by using 2 directors with realtime syncronization and failover. Keepalived works well in this regard, giving subsecond failover performance, and even uses VRRP, Cisco's own hot standby protocol.
As for the level hardware that you need, a low end or older PC, such as a P3-700 for instance, can easily saturate a 100 mbit connection.
I used 2 x P4 2.4G systems. So for less than a fraction of the cost of even 1 hardware based boxes, I get hot standby and should be good for way more throughput than I can afford to provide.
The best feature that LVS brings to the table that the hardware based implementations miss out on, is flexibility. This software is being enhanced all the time and nothing is impossible with it. The same cannot be said for the hardware solutions.
Unfortuneately the article does not touch on any of the nice add-ons, like keepalived, ldirectord, etc., that make LVS a manageable solution. I know that they are trying to keep the examples simple, but showing servers being configured using solely ipvsadm is not too realistic for the average person and make it look undeservedly complicated, which it is not.
Give LVS a look an see if it might not give you the features you need without paying the big iron prices.
DC
Here's another approach: put Linux on a CompactFlash card instead of a hard drive. Keep the filesystem mounted read-only for normal operation. Test upgrades on a different computer and CF card. Upgrade by swapping out CF cards. If you can build a PC that doesn't need fans, then you've removed all moving parts from the equation. For smaller installations, single-board computers such as the Soekris are very reliable. For larger installations, you can usually find a 1U system with the level of performance you need.
It was always just so much simpler to get a more expensive Cisco box in the long run due to its design, documentation, an performance.
It always depends on what you're doing, of course, and also what you're familiar with, but for my routing/firewalling/VPN/load balancing/ etc needs I've simply found Linux to be more flexible.