Multiple servers vs 1 big server performance

Question

My team of developers has suggested a server structure for an upcoming project we are developing. Our structure is "logical", meaning that the various logical components of the application (it is a distributed one) relies on different servers. Some components are more critical than others and will be subjected to more load.

Our proposal was to have 1 server per component but the hardware guys suggested to replace the various machines with a single, bigger one with virtual servers. They're gonna use Blade Servers.

Now, I'm not an expert at all, but my question to the guys was: so if we need, for example, 3 2GHz CPU / 2GB RAM machines and you give me 1 machine with 3 2GHz CPUs and 6 GB of RAM it is the same? They told me it is.

Is this accurate? What are the advantages or disadvantages of both the solutions? What are the generally accepted best practices? Could you point out some URL reference dealing with the problem?

EDIT:

Some more info. The (internet / intranet) application is already layered. We have some servers on the DMZ that will expose pages to the internet and the databases are on their own machines. What we want to split (and they want to join) are some webservers that mainly expose webservices. One is a DAL that communicates with the database layer, one is our Single Sign On / User Profile application that gets called once per page and one is a clone of what seen on the Internet to be used on our lan.

Solution 1

Given their requirements sound a bit 'wooly' and are actually quite low I'd be strongly tempted to virtualise this. I'd start with just two blades and some shared storage, then you can create, modify and delete their VMs as required, you'll lose very performance and gain a huge degree of flexibility, plus you can scale-out linearly and with no user impact.

Solution 2

I think that the sane way would be to identify where the crucial bottlenecks are or may occur. VMs are great for isolation and depending on the kind of hypervisor used, it may have little impact on the actual performance. Virtual networking would probably work better than physical networking as well.

However, I would recommend having a few physical machines due to redundancy. If you have one physical server with a million VMs in it, when that one physical server dies (and it will) it will take a million VMs down with it.

Never put all your eggs in one basket!

Solution 3

3 2GHz CPU / 2GB RAM machines and you give me 1 machine with 3 2GHz CPUs and 6 GB of RAM it is the same? They told me it is.

No It's not the same. depending on the virtualization platform there will be overhead (anywhere from 5-30%) from the hypervisor layer.

What are the advantages or disadvantages of both the solutions?

It's tough without more specifics but here are a few generalities

Advantages:

1. OS licensing could be cheaper-many of the vendors either do not charge or charge less for VM OS licenses
2. Portability- Since it's a VM should there be a scaling problem or a hardware change required, its trivial to change out or add hardware
3. Efficiency - if not all of the VMs are utilizing all of the resources available on physical boxes, that CPU and ram is wasted, if another machine requires more resources it's time to buy a new system. With virtual machines, the system that requires more resources can be allocated more resources from the pool of resources available (again depending on the hypervisor this may happen automatically)
4. Test/Dev environments can be exactly like production- most platforms allow you to clone a machine to a new network allowing patches etc tested in the "real" environment before deployment to the production environment

Disadvantages:

1. Performance troubleshooting is more problematic- Simply put there are more moving parts that affect one another. Is the issue in the hypervisor, are there other machines causing issues on the host. With any luck IOPS are the bottleneck which means buy more disks or more cache
2. Systems requirements get a little higher- typically you are virtualizing because you have underutilized systems and want to save some cash (long term ) in power etc. however due to the hypervisor overhead if you needed MHz before you might need MHz after- it depends on the hypervisor
3. Extra management- after virtualizing you have the same management burden that you did before plus the hypervisor. Depending on the hypervisor choice and the tolls yo have this may not be a problem
4. Cost - short term it's probably going to be more expensive. I would not take 3 systems and put them onto 1 physical box, simply because if that single box fails, my service is totally dead. Typically you want 3 systems (for cost purposes- it's usually cheaper to budget for an extra 1/3 overhead than having to have double the resources).

In your particular case 1 system might be OK if your service will be dead should any one of these systems be down. You haven't added any risk in that case. It also sounds like those systems will not need 6Ghz of processing power, in which case consolidation will certainly save money since you wouldn't buy 6ghz just for those 3 machines. The other thing you need to watch for is (and certainly not least in consideration) are I/O requirements and potential I/O contention.

As an alternative, if these web services can co-exist on the same machine you might also consider making 2 VMs with the same services and either use clustering or simply keep one on standby should the be an issue.

For URLs take a look at

Windows Server Virtualization Guide

The Shortcut Guide to Implementing Virtualization in the Small Environment

Solution 4

Are they talking about providing you with a single blade chassis? Because if so, that's still lots of individual servers, just contained in a housing unit. If they're literally talking about one beefy server to run the lot, they (probably) wouldn't be talking about blades.

Anyway ignoring the blade thing,here's my perspective: If your app scales happily across multiple smaller servers, do that. Smaller servers are cheaper to purchase, you can easily scale sideways by adding more servers, and the individual apps will tend to work more reliably if they have a server pretty much to themselves.

However, there are extremes. It's pretty common to split architecture into at least 2 layers (front-end and database), or 3 layers (front-end, application, database), but unless you're creating an absolute monster of a system, you don't often need to go beyond that.

Can you provide any more info about the system you're developing? What kind of platform you're using, OS, language, user base, development lifecycle?

EDIT: Based on your edit a further question comes up - What's the limiting factor of your current configuration? Are you running out of RAM, or are the disks not reading fast enough, or are you having trouble pulling records out of the DB quick enough? maxed out CPU? The limiting factor on what you have right now, should be the main steer for where you need to go with this.

View more solutions

Comments

[pistacchio]

we don't have limits right now as the whole structure is not up yet, we're on the development phase.

[pistacchio]

i think i missed the crucial point that they are talking about virtualizing it

[Chopper3]

ah, in that case I'd be tempted to go for two or more machines rather than one big one, that way you can take one down with zero user impact.