Re: replicating, balanced web-server with *write* access?
>From the keyboard of Christian,
> Much is written about High-Availability servers but I still didn't find a
> good solution how to build two load-balanced webservers _without_
> connecting them both to one RAID (single point of failure).
> The problem with balancing between two servers is that the might host
> web-servers that could write a file on system A and then reading this file
> (status file or whatever) on system B immediately before e.g. rsync could
> transfer it. In the worst case writing/reading could happen for two different
> connection so that even connection based balancing wouldn't work.
> For now I have three ideas:
> 1. forget about load balancing and do one-way balancing i.e. having one
> primary and one minutely synced backup. In a case of a failure the
> backup would take over the service and even if there's a little loss it
> only occures at failures.
> 2. use network attached storage. To avoid another single point of failure
> you then would have to take two file servers and a protocol (NFS wont
> need) to realize this. Maybe at least IP takeover and forced reconnection
> NFS clients.
> 3. Forget about writing anything to disk - apart from FTP uploads
> everything will have to be written to database. But tell that your
> The ideal solution would be a network filesystem like www.inter-mezzo.org
> but it does not appear to be really mature and tested in real life
> So any idea?
Is drbd what you search for?
Drbd is a block device which is designed to build high availability
clusters. This is done by mirroring a whole block device via (a
dedicated) network. You could see it as a network raid 1
But when I look deeper in it, it seems not to be the right thing:
Currently drbd grants read-write access only to one node at a time,
which is sufficient for the usual fail-over HA cluster. Although it
is currently not on my task list, it would not be a great effort to
allow both nodes read-write access. This would be useful with GFS