|
Actually, I was thinking about ways to automatically and safely replicate
the data across the various servers, and, well, I've noticed that nobody
ever mentions using the network block device support -- which is already
partially in the kernel.
Once you can export a block device over the network, you can include that
device in a software RAID-1 array, which will handle all the replication
for you.
I tinkered with it a bit, and it seems to have a few limitations/issues:
1. The server-side daemon is handled in user-space. This is
slow, and causes other problems -- for example, the buffer cache
doesn't get updated when you change the underlying disk directly.
Not good :)
2. The author recommends that exactly one side is read/write, and
the other side be read-only at best.
3. I have no idea how you would communicate file locks to the
other members. (I imagine that for the most part, this problem
goes away if you follow #2, though)
4. How is a live system going to react if someone is writing to
it's block device, and the write gets interrupted? ie - if the
network cable gets cut, or something. Maybe it could hold the
command until the transmission is finished?
However, I think that this has much potential, as it has some major
advantages:
1. It appears to be relatively simple to implement. Most of the
core functionality is already there -- only the server in the
kernel (and thus, the ability to manipulate the buffer cache)
seems to be missing.
2. It provides 100% redundancy. Even if the master disk dies,
all of the other ones ought to have
Is there any particular reason why nobody seems to be trying this?
Kyle Sparger
|
