I'll outline a couple of options, to show alternatives to the live code via NFS approach.
The "best" strategy depends on your chosen code deployment strategy, possibly one of these:
- Editing on live system - developer changes/updates application in one central place, live machines then pick up the change (which sounds like your scenario)
- Code exported from source control - developer makes changes to a source control system, then runs a program to export the code to all machines in the load balancing pool (or waits for the machines perform the update themselves)
- Code deployed via package system - developer makes changes to a source control system and creates software packages (e.g. via APT or YUM) stored in a repository. Developer runs a program to force the load balanced machines to install the new software from the repository.
The "best" strategy also depends on the availability requirements for the application:
- Theoretical 100% uptime - the application is still available while software updates are made (works with your suggested approach, but watch for atomicity problems: during an update, your PHP application may include_once() an mixture of old and new files)
- Scheduled maintenance accepted - the application is briefly taken offline while software updates are made (no atomicity problems)
Out of the above options, I would personally choose the package deployment approach. However, for web requests, sharing a small number of files over NFS can work well: The latency introduced by NFS is small compared to the Internet. But before you do this, consider the disadvantages:
- Consider which system resources are being balanced: If you are using multiple machines to balance CPU usage, then the setup may work well. However, if you're using multiple machines to balance IO, then shifting it onto one machine via NFS (or otherwise) may not be sensible.
- Consider failure of the fileserver: If the machine holding the files dies, it may take your whole application offline (as the webservers are unable to read the files). In this case, the webservers would tend to lock up waiting, for NFS to recover.
Because of these possible snags (IO bound fileserver, failure of the webserver), I'd also suggest periodically sync'ing the webservers with the application. Pushing changes to several machines should only take a couple of seconds. If required, you could setup some logic like: if (time() > 23:59:00) {use software in dir B} else {use software in dir A}). This could be useful if all machines must should run the same software version, e.g. if you've just changed a database schema.
A couple of seconds delay during deployment really isn't too bad. A developer working on a live system would certainly notice the delay, but then developers shouldn't edit live systems anyway.
What you want is called Microsoft Application Request Routing 2 (ARR). (Maybe the clumsy name is part of why so few people know of its existence?)
Microsoft ARR is a free-of-charge HTTP layer load balancer, implemented as a module for IIS 7+. (ARR itself is gratis, but the Windows Server license is of course required for the underlying OS.)
Since ARR is just a thin shim on top of IIS, it is quite fast and absolutely robust. And administrating ARR will be familiar for you guys, since you're already an IIS shop. ARR just installs itself in the IIS Manager GUI.
For a true high-availability setup, you should combine NLB and ARR, so that NLB keeps the ARR server tier highly available, and ARR keeps the backend web server tier highly available. See Microsoft's docs, and see the long list of documentation at the end of the ARR overview page linked at the top.
The only real downside to ARR is that if you do true high-availability, then you will require at least 2 Windows Server licenses & physical servers. Given that, and given the time it takes to set up, then low-end load balancer appliances like Coyote Point or loadbalancer.org can sometimes be a cost-effective alternative (Or Kemp, Barracuda Networks, or any of the other low-end vendors).
ability to seamlessly take a web server out of the load-balanced mix for maintenance without interrupting users.
That will depend on how session state is handled, i.e. how your backend servers share or not share the "this user is logged in" information.
If the webapp tier is stateless (i.e. placing session state in a shared datastore, fx a shared RAM cache or MSSQL), then you can just pull a server out of the pool. If not, then you can use "sticky sessions" on the load balancer, and remove a backend server from the load balancer pool, and then wait until all users have 'drained off' the server in question.
Willy Tarreau, the author of HAProxy, has a nice overview of load balancing techniques and issues here.
Best Answer
GlusterFS will provides a full POSIX filesystem export that can be mounted just as most other local filesystems. It will replicate to a configured degree for redundancy and otherwise will only pull data on request. As long as each server is configured so that the files created have unique paths even in a blind situation, you should be in a very good spot.