[Gluster-users] Delayed Replication + Realtime Locking
mathew at eisbox.net
Sun Jul 19 10:08:32 UTC 2009
I have been looking for some time for a solution to a storage problem
that I have been trying to solve, and have been experimenting with
Gluster to try and achieve the desired results. The approach that
Gluster uses to distributed storage seems well suited to the task,
however, I am unable to find a translator (or combination thereof)
that will solve the problem.
What I would ultimately like to accomplish would be to have two (or
more) servers that replicate across a WAN, while maintaining near
LAN-like performance at both ends. I am willing to sacrifice perfect
syncronization of the sites for a short time in order to gain the
local performance, so long as the sites eventually catch up with each
It seems to me quite do-able from a technical perspective. What I
envision taking place would be something similar to the following:
1.a Site A: File is opened with an exclusive lock
1.b Site B: File is also locked as open with an exclusive lock
2.a Site A: Necessary reads and writes take place
3.a Site A: Changes to files are synced to Site B at WAN speed; queued
up at some staging location (For performance, an rsync/diff type
solution to replication would be used)
3.b Site B: When all changes to file are copied from Site A, file is
updated at Site B.
4.a Site A: File is closed at unlocked
4.b Site B: File is unlocked
4.a may happen before 3.a, but 4.b does not take place in any case
until 3.b is complete.
In this way, both sites A and B should operate at local LAN speed; the
only performance degredation from a completely local installation
would be at 1.a to 1.b as there would be a delay in confirming the
exclusive lock at all replicated sites, and only if the file was
already not locked. Every other operation should take place at normal
Now lies my questions:
1) Is the above possible with the current Gluster translators? I've
experimented with various combinations of translators, including
replicate, nufa, writebehind, and io-threads, and while I have been
able to improve performance of some operations, many others are still
taking place at WAN speed.
2) If it is not possible, are there plans to implement a translator
(or set of), that could accomplish the above? I've read about the
plans for drsync and writeable-snapshot in GlusterFS 2.2, but even
those don't quite seem to meet the above requirements.
3) If 1 and 2 are not possible or in the roadmap, how do-able would it
be to create the above translator? I have a fair amount experience in
C and C++ beyond just academia, and this is a project that I would
likely be able to be paid to devote some resources to.
4) GlusterFS aside, is there something I'm missing in the scenario
above? It seems to me a relatively simple solution to a fairly complex
problem, yet every time I have brought the issue up with storage
specialists and fellow Linux admins, I've been met with blank stares,
told such a solution isn't really possible, or pointed to some
extremely expensive propriatary solution. It doesn't seem that
complex, but no one has been able to provide much input to a solution.
Am I just naively seeing a small part of the big picture?
Thank you all in advance.
More information about the Gluster-users