Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I need to put together a Drupal instance using Drupal's built-in multisite features, which will allow me to use a single code base for all the sites- a big time-saver and headache-preventer. We're going to be running a couple dozen sites from that single install, though, so we're going to need a high-performance way of transparently sharing files (including user uploads, etc) across these servers. Does that mean we want a SAN and a bunch of local slave databases? Or do I have no idea what I'm talking about?

share|improve this question
up vote 2 down vote accepted

I don't know drupal specifically, but you can generally lump things into three datastore catagories when approaching this problem.

1.) the database - this one is "easy" in that mysql replication is a mature well documented solution. Replication or DRBD can offer HA, but to take advantage of multiple servers at once for performance scaling your application will need the built-in ability to split read (select) and write (insert/update/delete) queries across the master and slave.

2.) the filesystem - this one is trickier. "normal" filesystems (ext3/ntfs) aren't designed for multi-host scaling, and the ones that are (gfs/ocfs) are almost always more complicated than they're worth (especially if you have to ask here). The most common solution is a NAS based approach (nfs on unix, cifs on windows), but that introduces a single point of failure, so its not an availability solution. Its usually not even a performance solution as you're reliant on the performance of the one fileserver. Its main value is in providing coherent read-write access from multiple hosts. If your application is cpu bottlenecked, then NAS will help you scale because your servers will spend their time waiting for the cpu to finish, not for the files to load.

3.) code & configuration - usually this is done on the filesystem, in the database, or both. I separate it here because its usually much smaller in scope and more the sysadmin's problem than the more content-oriented datastores of #1 and #2. Often you can get away with just manual (or scripted) copying of the files.

So with all that in mind you need to evaluate how drupal handles those three catagories, and how you can replicate them. Odds are you'll start with just a NAS and a loadbalancer. Its very unlikely you want a SAN yet.

share|improve this answer
I'm pretty sure I'll have help on the GFS/OCFS side of things from someone who's much more familiar with it, but that's just the sort of advice I need to make an informed decision. "more complicated than they're worth if you have to ask here" sums up plenty of time sinks I've blundered into over the years, so that's a really helpful bit of advice. – jj_aa Oct 19 '09 at 15:16

I'm not sure where the SAN and Slave servers come into it (initially) since you say it's a "single install".

The parameter you want to specify is "File system path". So maybe if you are going to share that directory amongst all your sites you are going to create/specify as a value "sites/all/files" (i.e. each Drupal site's DB will store this value).

If/when you have a scaling problem and you need to share sites/all/files out concurrently to each web node you could use (iSCSI) SAN storage with a cluster file system like OCFS2. (i.e. files becomes a mount to the SAN storage that is an OCFS2 filesystem).

Likewise with the Slave servers. Use for scalability (reads from Slaves) and/or high availability (promote Slave to Master) or do your backups from a Slave but it doesn't really factor into your initial spec with regard to transparently sharing files.

Hope this helps.


share|improve this answer
Sorry, I should have been clearer- I meant "single install" as in "one code base served up by multiple servers". "share sites/all/files out concurrently to each web node" will be my locution of choice going forward, though. – jj_aa Oct 19 '09 at 15:12
ps: I don't have enough reputation, but I'd vote this up if I did. – jj_aa Oct 19 '09 at 21:59

Your Answer


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.