Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 May 2001 18:12:11 +0200
From:      Gabriel Ambuehl <gabriel_ambuehl@buz.ch>
To:        freebsd-questions@FreeBSD.ORG
Subject:   Realtime HD mirroring / network block devices
Message-ID:  <1431044285272.20010508181211@buz.ch>

next in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----

Hello,
I'm searching for a solution that would allow us to replicate [1] the
FS
of our servers in realtime or at least close, up to 30 minutes lag are
acceptable. Ideally, this could be used with vinum like the Linux
crowd does with their network block device but I couldn't find
anything
similar for FreeBSD and I've never done any Kernel level coding so I
doubt this would be a success if I tryed it. Any plans to add such a
beast into FreeBSD
(http://atrey.karlin.mff.cuni.cz/~pavel/nbd/nbd.html is Linux but
BSDL, there is a Winport of the server so I suppose porting it to
FreeBSD should possible)?

http://www.complang.tuwien.ac.at/reisner/drbd/ is probably
exactly what I need but I don't want to run Linux which is too much of
a moving target, IMHO.

vinum doesn't appear to be supporting any distributed operation at
all.
vinumvm.org
"This isn't too difficult, but it doesn't bring the advantages you
might expect:
it wouldn't be possible, for example, for different systems to access
the closest
plex to them, since there would be no way to ensure data consistency."

I wouldn't care for this as long as my data is being replicated...

I've spent several days trying to get Coda to work but finally came up
to the point where I had to say that its architecture isn't really
suited for webservers anyway but rather for fileservers providing
central homedirs and the like. Available bandwith is at least 100
Mbit, more if needed, so bandwith isn't a problem but CPU resource
usage sure is. I don't currently need a setup where multiple machines
may change the data as the involved locking headaches would probably
eat way more CPU than an additional machine would add, a classical
master/slave(s) implementation is enough.

In general, I'd be ok with something that just watches for changed
files
and copies them to the hot standby machine if it only works fast
enough without too much impact on system performance.

I had a look at both rsync and cpdup but both need way too much CPU
resources to scan the drives for changes. I'm not sure whether/how
this could
be solved. Is there a possibility to have the whole "FAT" (or TOC or
whatever, you know what I mean ;-),  cached in RAM to save the disk
accesses? RAM is cheap nowadays...). The NFSv4 drafts have some
sparse information about possible replication of read only filesystems
(whatever this may mean. cp -R can do this on read only filesystems.),
is any information about the state of NFS4 in general and this very
feature in particular available?




Best regards,
 Gabriel

[1] No, I don't feel external dual Server RAID is an option. While
RAID solves the worry about replicating the data, those devices are
still a single point of failure. I won't even think about running a
whole group of webservers out of essentially one device which can take
them down all at the same time. And pricing is just rip off in the
very most cases. Local RAID is fine but still doesn't prevent the data
from getting inaccessible when the server crashes.

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2i

iQEVAwUBOvgM18Za2WpymlDxAQGSYwf8DmyVFr2wslbHvwNcf9FDepUgGyS9jGHL
uqYiQXEQOjUuLOZx/ioEdbbpUVowCuGa49XDOFvbD0A81Ua92oNbNVcNbvnIXHdI
QHddM69wzNrX8aE2mrZRmvSJ+tT1Boc9B6dEIBMu3Or/q3O/Tdd0FPVhU+Jg/RD0
s5xZ3EmlYz4UOR+YmLMCR7DjSQ7uc940csZmHtDOolhv++H2+biOnVJ3yX+/0ONY
JkaIs+iAcTz5CzcY0/WfoQT2VABuAe0sLLvnoGJKEumftTgpyiIBvd+uzJlYRI+E
5ThRgqd9Ygys+uDR0FJPU+dIViZi0TbA2mGmKskiGDjug+DifWxgsg==
=H8B9
-----END PGP SIGNATURE-----



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1431044285272.20010508181211>