Brion raised the question the other day about the possibility of storing the images directly in the database. Part or all of the motivation was to make it easy for multiple webservers to serve consistent images on the site in our new configuration.
I've been thinking of other ways to do this.
1. NFS -- all the webservers could have read/write access to an NFS partition, probably on the new machine. This is easy to setup, but there are questions about the security and stability of NFS, and at least a few years ago, it was considered by some to be bad mojo to try to serve web content off of NFS-mounted partitions -- performance is bad.
2. AFS - Andrew File System, or DRBD - Distributed Replicated Block Device --- These sound to me like things that hold forth great promise, but I also regard them as fairly esoteric technologies. We're probably better off doing something more boring.
Am I wrong? Too conservative? Not up to date?
3. Apache reverse proxying -- this is a boring and good solution that I'm confident would work well, but it does have some drawbacks. Essentially, the way it works is this: for image uploads and downloads, we mod_rewrite to transparently reverse proxy the requests to apache running on the backend (database) machine.
One possible drawback is the overhead of apache running on the backend, and the fact that it might become a bottleneck. However, since almost all the backend machine would be doing is static requests, and since those could be shunted to something faster than apache, it really wouldn't be all that hard.
--------
Hybrid approaches are possible -- the webservers could NFS mount the /images/ directory from the db machine but only use the NFS mountpoints for writing -- for reads, we'd go through the reverse proxying mechanism.
--Jimbo