Multiple servers vs 1 big server performance

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.

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.

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!

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.