On Thu, Apr 19, 2007 at 10:51:56PM +0100, Stuart Henderson wrote:
> > I don't think NFS/AFS is that good an idea; you'll need very beefy
> > fileservers and a fast network.
>
> NFS may actually be useful; if you really need the files in one
> directory space for management/updates that's a way to do it (i.e.
> mount all the various storage servers by NFS on a management
> station/ftp server/whatever).
Something like that might be a very good idea, yes. Just don't try to
serve everything directly off NFS.
(An even better idea might be setting up a repository for your favourite
version control system and making partial checkouts. Gets you most of
the benefit of a unified filesystem, at the cost of complex - and thus
fragile - checkin hooks. On the other hand, version control is likely to
be a big plus.)
> For serving content some HTTP-based scheme to get the requests to hit
> the right server is probably in order. Proxies are useful if you have
> special requirements (for example SSL, where it doesn't make sense to
> have the CPU and the disk in the same place), but it normally makes
> more sense to distribute the requests to the correct server/s in the
> first place (either by front-ends that know the location of content
> sending a Location: header if you want to give out URLs with a single
> server name) or by the html pointing clients to the files on the
> right servers.
I think doing that in HTML will quickly become an administration
nightmare.
> > various SANs come to mind
>
> TFMotD: fsck(8) (-: Relying on black-box vendors for fixes is an
> additional bonus. Works for some people, though. Allegedly.
Yeah, they seem to work. It wouldn't be my first choice, either, but
I've never tried to run OpenBSD in this kind of environment. At least a
good, expen$$$ive SAN is good for covering your backside.
JOachim
--
TFMotD: perl561delta (1) - what's new for perl v5.6.x
