Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Some collegues are suggesting a web load balancing schema with multiple web servers (IIS7) on different virtual machines all running on the same hardware.

Is this a truly advantageous setup? All machines are 64 bit so memory addressing shouldn't be an issue.

share|improve this question

4 Answers 4

up vote 8 down vote accepted

The way I see it is this: With the virtualization, you sandbox some of the processing resources. You separate out into discrete units the web servers; you can upgrade a server while having another to take over, and can redirect requests if there's a problem.

You can snapshot the VM's to roll back from production problems.

You can more easily migrate the VM's to separate hardware when/if you get it, so instead of migrating bare metal setups (configure a whole new web server) you can just move the VM to a new machine, or if you set up a "proper" cluster your VM's will be a in a good position to just roll into production rather than reconfigure from scratch.

You can set up separate VSwitches to the NICs to control traffic flow, if need be.

I think it provides some greater flexibility and options down the road to have multiple machines on the VM host handling your website.

On the other hand, if you have only one host, you can have problems with point of failure. If you have at least two NICs this helps mitigate it (you can dedicate the NIC to a particular VM, depending on your needs and setup, for example) and depending on your host's configuration some problems will be more pronounced. For example, if your disk volume isn't optimal, you're going to suffer reduced performance because of I/O contention, and your processor of course is going to have to split resources among the VM's.

Really the strength for me in virtualizing this is the easier management and migration path down the road. I think it's a lot easier to abstract the hardware from the machine, then when something better/bigger/faster is purchased, you can migrate your established working setup to that hardware with less downtime and configuration hassle. Or you can balance the machines between hosts. And in our case, if we have a problem there is still a possibility, if we absolutely had to do it run the servers as VM's on workstations until repair parts came in for our host servers using the hypervisor in a temporary setup, without the users really noticing a difference.

And snapshotting (in our use case) has been great for making sure updates don't turn our systems unto paperweights on reboot. Snapshot, update (or alter the configuration), reboot, test, and delete the snap if all goes well.

So does it make sense? If your site is heavily trafficked, maybe not, because you'll have I/O contention. If your site is lesser loaded and you think you'll get another host in the future, I'd strongly consider it. I think the abstraction from virtualization helps make it easier to add machines and alter the configuration over time, but if you're hurting for performance that overhead that virtualizing incurs can hurt a little.

share|improve this answer
    
Best answer ever! –  Joe Apr 13 '12 at 16:27
2  
It's a good answer, but best ever? –  ceejayoz Apr 13 '12 at 16:30
3  
Hey, if he wants to declare it such, let him! :-) –  Bart Silverstrim Apr 13 '12 at 16:31
    
Well, It's just that I agree with 100% of the points that Bart makes for the endorsement of virtualization for this question. –  Joe Apr 13 '12 at 16:47

You will incur more overhead than running only one instance. The only benefit will be that if one VM goes down you will have another ready to act as a failover. Your reliability would be better if you had more hardware, of course.

One possible advantage of this is that later on you could move the VMs onto other hardware and subscribe more resources, but you could get the same benefit by just adding more servers to the load balancing as you add capacity.

share|improve this answer

I say yes, as this will also gives you an ability to bring one of VMs down to do some maintenance while the other one is up and serving up a content to end-users.

share|improve this answer

Not that simple to answer... It relies on a thousands of things ;-)

Leaving out all the IO(shared mem, disk, network, cpu) bottlenecks really slimed down to the last part:

For your Apache it might be more efficient running "5 instances on 100 connections" than "1 instance on 500 connections" But this might be also archived just starting multiple apaches, or might be better addressed sorting out apache there, put an nginx or so in front (a lot better connection polling, still have the apache behind running your app) ;-)...

Apart from that: Having "one virtual server" on the hostnode makes cloning, backups & failover more simple, sure.

Multiple virtuals doing the same thing most likely no benefit (or benefit you can archive better in another ways)

One exception is fault-tolerance, therefor having 2 virtual machines on the same hardware can help against SoftwareFails (segfault on one apache only), but that would need a decent setup.

--

General:

'vitalization' YES! backups, clones, moving

'running the same image multiple times on the same hardware' NO (yes there are also cases where that could make sense)

Performance: there are better things to do

FaultTolerance: softwareFails only, nothing that cant be done my monint

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.