3

I was listening to Hanselminutes one day and this question came up. Under what circumstances should one separate data from code? For example in one of the systems that I've working on the DB is on the same box that servers web content. In another scenario we had them separated. Which is better any why do you feel that way?

Personally I think separation is good if you can afford it.

Data is better protected from a would be intruder. Separation allows for better failover control. and Separation enables you to manage and load balance traffic better.

Where this does become an issue is with data access times. Latency on the box when both are together is significantly reduced vs over the network.

What are you thoughts?

Kara Marfia
  • 7,892
  • 5
  • 33
  • 57
Middletone
  • 219
  • 1
  • 6
  • 13

12 Answers12

1

Very bad idea for the least. I have had a setup before where we had Apache+MySQL on the same server and it would regularly go over 10 load average and the pages would take forever to load. We split both services and put MySQL on a smaller server. Both servers would never go above 0.35 of load average.

Do the math... There is a lot of loss into putting Web server + DB server on the same server.

Evan also has a good point. Merging things into a machine tends to lead to many shortcuts which make scaling out a lot harder. One service = one OS is a good rule of thumb (would have said one service = one machine but now there is virtualization).

Antoine Benkemoun
  • 7,314
  • 3
  • 42
  • 60
1

The first thought that came to my mind was to not over engineer a solution.

It's okay to put everything on one box. The almighty Stack Overflow started like that too.

When you have suffient demand (and resources) to justify multiple boxes, do it. Building the perfect setup won't happen the first time.

Keep excellent backups regardless of what and how you set it up for quick recovery and restore. Replicate your database off-site so you can rebuild and restore it anywhere (into the cloud, other hosts, etc.)

Good luck!

Jas Panesar
  • 279
  • 2
  • 5
1

From a security point of view it should be on separated boxes. However, depending on budget it should be a business decision to accept the risk or not.

Why is that? First, best practices recommend:

  • Defense in depth.
  • Least privilege and data separation

If your database is on a separated machine, it will require an additional step to attack it. If you follow defense in depth, the web server will not be able to access anything else on the db box besides the db (so, no shell, no running scripts, etc). That's why a firewall is good for internal control too.

If you are really doing security well, your web-2-db user will have minimum privileges on the db, only being able to access/modify what he really needs (so, no drop table, etc). It is funny how often we see GRANT * on a db, for a user that only needs to select and update from a few tables.

So, just because a lot of people run db+web server +mail server + DNS on a single box, doesn't mean it is the best security decision, just an accepted risk based on the $$.

sucuri
  • 2,867
  • 1
  • 23
  • 22
1

One important thing to keep in mind is that when you go from one machine to two, your chances of downtime double - that is, if your site is dependent on the DB to function. If uptime is important to you, you might be looking at 4 (or more) servers - and then you're golden.

I don't think that you need to worry about the speed of the DB communicating with the webserver. The CPU power you gain by adding a machine will speed up the DB queries themselves, and the transmission between servers even at 100Mb should be negligible compared to the speed that you can server web pages on the live internet.

Brent
  • 22,857
  • 19
  • 70
  • 102
1

There are several reasons you'd consider separating database and web server, and some will echo what's already been mentioned.

First, there's the potential performance issue. Generally, a database server loves memory. The more memory it can allocate to caching data, the less access it requires to read from disk. So there's a benefit to having memory. As a result, you can have a memory contention issue between the web server and the database server. With that said, there are plenty of cases where database servers are running on the same box as the web server, such as with MySQL or SQL Server Express or even full blown SQL Server with SQL Server 2005 Reporting Services.

Second, there's the case where your application may use some but not all of the data. This is especially true if internal systems touch the database, too. This isn't a likely scenario in a web hosting environment, which I'm guessing you're looking at based on your tags. But in that case, you can limit the access the web server has to the database to only what is needed. Yes, if the web server is compromised, they can get that access, but if it's a limited set of permissions, they can't get everything. Host it on the same web server and that's a totally different story.

Third is because you can gain some insight in whether or not your web server is compromised by looking at the network traffic between the web server and the database server using IDS/IPS. For instance, if we're talking SQL Server and xp_cmdshell gets sent to the database server, or sp_configure, that should tell the IDS/IPS something is up. And that gives you immediate warning that the web server is compromised.

Fourth is separation of duties. If you have folks responsible for deploying the web application, they probably need escalated rights to the web server to do so. What kind of rights depends on what you're doing, what OS, what web server, etc., but you get the idea. If those folks shouldn't have access to everything that's in the database server, and the updates to the database server are handled by a different set of people (like DBAs), they you can better protect the company by using different servers.

K. Brian Kelley
  • 9,034
  • 32
  • 33
0

I don't think security is significantly better with a separate box. If an attacker compromises the box that does the web serving, that will probably lead to a db compromise regardless. The failover and load-balance/scalability arguments are much better.

But if you have just one web box, I would definitely prefer to keep the data on the same box.

Matthew Flaschen
  • 868
  • 2
  • 7
  • 11
  • 1
    Have you heard of defense in depth? That's what a host-based/internal firewall is for. A web server should have minimum access to the db (so no ssh, ftp, etc), so the vector used to attack the web server is probably not going to be present on the db server. – sucuri Jun 20 '09 at 21:09
  • That's not going to stop them from doing select/delete/update queries that pull sensitive data or wipe out what's in it, though. – ceejayoz Jun 21 '09 at 04:17
  • Exactly, ceejayoz, the web server still must have privileges to manipulate the db, whether from near or afar. – Matthew Flaschen Jun 21 '09 at 05:45
  • There is a big difference between being able to query the db remotely and having direct access to a system. Plus, it is one more place to detect the intrusion (if you see the web server trying to ssh/ftp to the db). – sucuri Jun 22 '09 at 13:46
0

If they have access to your web machine, they can pull the database details from your config files, load up a php shell, and dump the data from there. The one security advantage is if you have more than one DB on the same machine.

However, it allows you to spread the load, and if you need to do this for performance, it's good, as long a you have a fast connection, as stated.

Dentrasi
  • 3,752
  • 1
  • 24
  • 19
0

If your worried about redundancy, then it would be good to have all of the data on one box and backup on the other.

I agree, separation is better if it can be afforded.

MaxDPS
  • 3
  • 5
  • 1
    I hope that by "backup on the other" you mean "Run a backup system on the other box-- one that takes the backup offline when the backup is done", versus the "Backup *TO* the other box" (which is dangerous and isn't really a backup). – Evan Anderson Jun 20 '09 at 19:41
0

If the box can handle the load CPU/RAM - then having them on the same box might be better for performance reasons as there would be no network latency between the web server and database server.

Jeremy Coenen
  • 136
  • 6
0

I don't have a strong opinion one way versus the other. If you're planning to "scale out", though, you might consider making the web server(s) as stateless as possible to allow for scaling without re-architecting the design.

Evan Anderson
  • 141,881
  • 20
  • 196
  • 331
0

If you have a small, relatively static, database that is accessed frequently then storing it on the same server as the web server may be beneficial (since you'll take advantage of in-memory data caching). However, for any other scenarios it is best to split the two roles if you can afford the extra $1-2K for another server.

Beep beep
  • 1,833
  • 2
  • 18
  • 33
0

I think that separating the database and the web server to different machines might add another layer for the intruder to get to, but a very thin one.

If you would like to "trap" intruders that way, you can use a reverse proxy or a web-cache on a separate machine. The intruder will goto this machine and will find no data as well as no details how to get to the database machine. Only the web server will be defined on the reverse proxy and that can be blocked off apart from the port its serving the web pages on.

Security: the proxy server may provide an additional layer of defense by separating or masquerading the type of server that is behind the reverse proxy. This configuration may protect the servers further up the chain - mainly through obfuscation.

http://en.wikipedia.org/wiki/Reverse_proxy

Jonathan
  • 451
  • 3
  • 9