Multiple servers or one big one?

@iobright:

The problem with this seems to be that processing power, ram, and transfer are not transferable between servers.

Surely Microsoft can do this using Vista somehow, can't they?

James

It really depends, if you have a low-impact server you can get away with doing everyone on one server. Once a particular part of the website/server/whatever gets "out-of-hand" you might want to look to giving it a special server and have it connect to things (ie, mysql, reverse proxy lighttpd/nginx) to server things. I'd say, open a support ticket to get some questions answered. I don't think linode would rule out special instances, but I'm not them, so I don't know.

@freedomischaos:

It really depends, if you have a low-impact server you can get away with doing everyone on one server. Once a particular part of the website/server/whatever gets "out-of-hand" you might want to look to giving it a special server and have it connect to things (ie, mysql, reverse proxy lighttpd/nginx) to server things. I'd say, open a support ticket to get some questions answered. I don't think linode would rule out special instances, but I'm not them, so I don't know.
caker's mentioned on IRC that they'd be willing to carve out custom linodes - but only if you rent out a whole host to yourself for something like $800/mo (then you'd be able to create linodes from it in whatever configuration you want).

There are several advantages to multiple servers.

The obvious is redundancy - two (or more) web servers can talk to a single SQL server over private IP so that the SQL port is not public, and the SQL server can replicate over private to another SQL server for it's backup.

In fact, you can even run the sql servers without any public interface allowing them to serve several front ends without the security risk of the exposed ports.

Running multiple servers also reduces the impact if any one service is compromised, as the compromise would be restricted to that one server.

So if your http server is rooted - your database server should be inspected but very well may be OK.

@FunkyRes:

In fact, you can even run the sql servers without any public interface allowing them to serve several front ends without the security risk of the exposed ports.
But if you run everything on a single server, your mysql "port" can be filesystem socket, which also eliminates the exposed msyql ports.

Multiple systems (virtual or not) mean multiple systems to keep patched. One big system means less duplication of resources and efforts. A lot depends on whether the various services you want to support are independent (which would lead me towards multiple servers) or heavily interdependent (might as well run them on one big server, IMHO). Dealing with trade-offs is a basic design problem, and always sucks :-)

@SteveG:

@FunkyRes:

In fact, you can even run the sql servers without any public interface allowing them to serve several front ends without the security risk of the exposed ports.
But if you run everything on a single server, your mysql "port" can be filesystem socket, which also eliminates the exposed msyql ports.

True, but if you have two web front ends to deal with redundancy and load balancing during peak hits, you have to have some means of both front ends talking to the same database.

It would still be better to go like this:

Web -- / -- DB2
       \ _ DB1

And use mysql clustering for the larger web hits.