We are adding a feature to our web app where uploaded files (to app servers) are processed by background workers (other machines).
The nature of the application means these files stick around for a certain amount of time. Code executing on the worker knows when files become irrelevant and should delete the file at that time.
My instinct was to ask our sysadmins to set up a shared folder using NFS. Any webserver can save the file into the NFS, and any worker can pick it up to work on it. Signalling & choreographing work occurs via data in a shared Redis instance.
About the NFS, I was told:
Typically, for this kind of use case, we route all upload requests to a single web server. The server that handles uploads will write the files to a directory, say /data/shared/uploads which is then synchronized in a read-only fashion to all other servers.
It sounded like they didn't like NFS. I asked what the problems were. I was told:
In regards to NFS or any other shared file system, the problem is always the same - it introduces a single point of failure. Not only that, it also tightly couples all servers together. Problems with one server can affect the others, which defeats the purpose of load balancing and de-coupling.
We are currently at the scale where we have multiple web servers and workers, but still single DB and Redis instances. So we already have single points of failure that we are tightly coupled to.
Is NFS so problematic that the above arguments are valid?