[DRBD-user] Re: loop device and eth0 loop-back + latest version

Eugene Crosser crosser at rol.ru
Fri Apr 23 22:04:11 CEST 2004

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


On Fri, 2004-04-23 at 23:14, Lars Ellenberg wrote:
> / 2004-04-23 18:54:27 +0100
> \ Nuno Tavares:
> > Em Fri, 23 Apr 2004 19:22:37 +0200, Lars Ellenberg escreveu:
> > 
> > >> I really liked what you are doing here, but I need a solution *fast*.
> 
> > >> What I need is some solution that gets this possible: I have server1
> > >> and server2, both with a local filesystem subtree, which should be
> > >> identical in both servers and sync'ed in real time (as fast as
> > >> possible).
> 
> > >> Suppose this: you login to server1 and "echo SOMETHING > ~/TEST".
> > >> Logout and immediately login to server2. When you do "cat ~/TEST" you
> > >> may see 1) that the file exists and 2) look at its contents
> > >> (SOMETHING).
> > > 
> > > use a shared filesystem, NFS, SMB, anything. put it on a fileserver.
> > > fileserver itself may be a HA-cluster, build with DRBD or any other
> > > shared storage.
> > 
> > That is *exactly* what I'm avoiding - having a 3rd server.
> > Even having server1 exporting to server2 and/or vice-versa is not
> > applicable.
> 
> sorry that I cannot help you.
> 
> but there is always more than one way to do something, so
> maybe if you give a more detailed picture of what you are trying to
> achieve, and *why* you think it has to be that way, someone may come up
> with a good suggestion.

One possible (but not extremely beautiful) way would be to have two
machines making up a HA NFS server (with DRBD or whatever), and at the
same time *both these machines* are clients of this server. 
Applications never access "physical" layer of the storage, only over
NFS.  Note that there is no problem to mount an NFS exported directory
on the same host that exported it.

I actually have such configuration in production, with two Sun machines
sharing a hardware RAID array over FC.

Eugene
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20040424/2409d2ee/attachment.pgp>


More information about the drbd-user mailing list