Oh wow, I'm having flashbacks to a past job, where GFS was used for the exact rationale you're describing. The scenario: in excess of 2000 customers running their apps on a number of large-scale clouds.
Basically, you can't do what you think you want to do. You cannot get a clustered or network filesystem that will work at anywhere near the speed of a local filesystem. Let me emphasise that for a second: CANNOT. If you think you can, you're deluding yourself. If someone else says they can, they're lying. It's simple mathematics: disk speed + controller IO + network latency + cluster fu must be greater than disk speed + controller IO.
Now, down to the reasons you might be building this, and why what you want to do is useless:
- Simplicity of deployment: It's not simpler to deploy to one machine and have it automatically run everywhere, because -- get this -- it's not one machine you're deploying to. Sure, you might think it's convenient to only have to copy one instance of the code, but there are plenty of per-appserver things you'll need to do in various situations. In many cases I've personally had to deal with, installing onto a shared filesystem ended up making the deployment process more complicated than it would have been. The correct answer to the question "how do I deploy to multiple machines" is "automate deployment".
- Clustering for reliability: This one borders on a joke for me. Modern hardware is so reliable, and clustering technologies so unreliable, that clustering (especially clustering filesystems) INCREASE your downtime. I've got enough data for a white paper on that topic. Now, some people will say "I've had an EMC SAN running for four years without a production outage", but how much did they pay for that reliability? I've never heard of anyone get that sort of reliability for less than 7 figures (on a TCO basis), and there was plenty of expertise cost in there, too. The fact that you're asking this question says you don't have that expertise, and I'll bet you're not looking to put 7 figures down, either.
- Clustering for capacity: This goes back to my opening statements -- any sort of clustered filesystem is slower than a local one. Trying to extract large amounts of performance out of a clustered or network filesystem is a lost cause. It will drive you mad (it certainly did the trick for me).
Now that I've been a negative nelly for a screen or so, what can you do? Well, it basically comes down to helping your customers on an individualised level.
You can't build a cookie-cutter, one-size-fits-all hosting infrastructure for infinite scale. That's what my GFS-loving past employer tried to do, and by gum it didn't work then, and I'm confident it cannot be done with currently available development and operational technologies.
Instead, take a bit of time to assess your customers' requirements and help them towards a solution that meets their requirements. You don't necessarily have to do a full analysis of every customer; after the first few, you'll (hopefully) start to see patterns emerge, which will guide you towards a range of "standard" solutions. It becomes "OK, you've got requirements F, P, and Aleph-1, so you'd be best off with solution ZZ-23-plural-Z-alpha -- and here's our comprehensive set of documentation on deploying this solution, and our prices for custom consulting on this solution if you can't implement it yourself are at the bottom".
As far as specifics go, there's too many to list, but I'll give you a few hints:
- Deploy code to each appserver individually.
- If you really have to go shared dynamic assets, use NFS. It's stupidly simple, and has by far the lowest breakage rate. Note that I said shared ASSETS -- not the code, not the config, not the logs, nothing but customer-provided assets.
- NFS doesn't scale forever though (NetApp propaganda notwithstanding); at some point, your customers will need to move to something else (an example of which I've given before), and you can assist them in moving to a more scalable solution with good documentation and other ready-made assistance.
- If you're thinking this can be a fire-and-forget business, you're wrong. You've got commodity web hosting (with all of the good points -- low maintenance -- and bad points -- no margins -- that that implies), and specialised web hosting (which is what you're trying to do), and the latter is high maintenance (but with correspondingly high margins).