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