Setting Up Centralized Storage (NFS, GlusterFS)

Depending on various factors, consider using something like git or SVN. Most configuration management tools (e.g. chef) will happily deploy stuff from a version control system during their regular runs. And you are using a version control system, right?

The major advantages: 1) it doesn't involve unusual filesystems; 2) stuff flows in only one direction, from the "trusted" repository to the expendable nodes; and 3) if the repository is offline or broken, everything keeps humming along. The major disadvantage: if your application writes files to the local disk and expects to be able to find them again, it sucks. (By policy, "we" use S3 for this sort of storage of images and uploaded files and whatnot; the ease of doing this is inversely proportional to how much PHP is involved. Buy me a few beers and mention vBulletin and I'll be more than happy to explain why you should quit now and become a goat farmer in middle Canada.)

Performance is a relatively minor consideration in most cases (hooray for caching), so don't discount NFS because of that. (And really, it's pretty damn good over a LAN.) However, always always always consider what happens when a server breaks: if you have 10 web servers mounted off of 1 NFS server, and the NFS server dies, you have 1 dead NFS server and 10 dead web servers. GlusterFS would probably be a better choice than NFS for this case, but there are big tradeoffs there too…

@hoopycat:

the ease of doing this is inversely proportional to how much PHP is involved. Buy me a few beers and mention vBulletin and I'll be more than happy to explain why you should quit now and become a goat farmer in middle Canada.
LOL!!!

Another thing you need to take into consideration is the fact that Linode doesn't give you a whole lot of storage per node, and purchasing extra storage is even more expensive. So if you plan to store anything more than ~100 gigabytes of data and you use plain old NFS, you might end up wasting a lot of money on a storage node. A distributed filesystem like GlusterFS might allow you to take advantage of leftover storage in all of your web nodes.

If this isn't about user-uploaded files but only the website code, I second hoopycat's suggestion that a version control system should be involved somewhere in there. This makes it so much easier to separate development branches from the production branch, merge changes between them, and easily roll back to a previous version if something goes wrong.

Thanks guys for the responses. If only deployments would work for us. This is a Wordpress site with lots of users, so files can change, and users upload/delete content.

Maybe though, if we say, all media/uploads go to S3 or CloudFront, that may work. Just as long as any plugings, don't try and write to the local filesystem (face => palm). :)

There is at least one WordPress plugin that does it. It looks like we use tantan-s3-cloudfront… there might be others.

And yes, we deploy WordPress from SVN. Normal static content goes to S3/CloudFront, and any theme changes had better be committed to SVN or else they'll go away (if they even appear at all…). This is a security policy decision and a site reliability decision, and so far has worked out well. (Cool thing is that you can use externals to pull WordPress's repo into your tree, so WordPress upgrades become super easy.)

(The WordPress-via-SVN thing isn't actually specific to this particular setup; I highly recommend it as a normal way to deploy WordPress if you can. But I digress.)

Wait, we have goats? Why wasn't I informed of this?