Slave share (or SMB caching proxy) suggestion

[ronnie sahlberg]

Another thing you could try ontop of the other suggestions.


I have in the past tried to use CTDB for solving a very similar problem with
very promising results.

Essentially you build a 2 node CTDB cluster, one node being the "datacentre"
and the other node being the "remote site".
CTDB can handle "remote sites" reasonably well (for some definition of
"well") if you set the options for the remote site in /etc/sysconfig/ctdb to
:
CTDB_CAPABILITY_RECMASTER=no
CTDB_CAPABILITY_LMASTER=no

This would create a ctdb "cluster" that spans across the wan link. Its
obviously not a wan accelerator per-se but rather a samba server that spans
both site.
The setting above are to make the cluster know that the remote node is
"expensive" to shift data onto so that should be avoided if possible. The
idea is that the existence of a remote node should not harm performance on
the datacentre node and that the cost in latency for first access would be
paid always by the remote node and never the datacentre node.


In ad-hoc testing a long time ago this did work surprisingly well. With
surprisingly good results.


It would be interesting to see results from more serious testing of this
ctdb trick.

regards
ronnie sahlberg




On Wed, Feb 18, 2009 at 10:46 PM, Aleksander Budzynowski <
budzynowski at gmail.com> wrote:

> Hi all,
>
> Forgive me if something like this has been suggested before or already
> implemented, or was deemed unfeasible for some reason. I briefly ran my
> idea past Tridgell at LCA last month but I don't think I explained it very
> well.
> The idea is to have a share in one location that works essentially as a
> real-time replica of another share, which is located say across the WAN.
>
> The approach, to me, seems simple: the "slave" server pretends to be just
> another ordinary client of the "master", and requests locks and oplocks as
> appropriate, to ensure that concurrent access is fairly safe. Since the
> server needs no modification (could be a Windows box), and we
> already have SMB client code, I believe this would be fairly simple to
> implement.
>
> I'm not sure if it would provide acceptable performance in general, but I'm
> sure there are *some* applications where this would work very well, or at
> least be better than the, um, alternatives.
>
> While the details could vary, this is the picture in my mind:
>
> The slave server stores a local copy of the entire share, checking if files
> are up-to-date each time they are accessed. So it could double as a simple
> off-site backup, and could be accessed even if the link to the master is
> down. You might have a script or some such which ensures that everything is
> up-to-date weekly.
>
> My understanding of SMB is not extensive, but here's how I imagine a
> typical
> request will flow:
>
> -Local client wants to get a file (and oplock it)
> -Slave gets an oplock for the file from the master
> -Slave checks if local copy has same date as master copy (if not, local
> copy
> is updated)
> -File is sent to client
> -If client modifies file, slave can cache changes locally, or immediately
> send them on to master
> -If master breaks oplock with slave, slave breaks oplock with client
>
> So. Does this idea have merit? Has it already been done? Is there some
> fatal
> flaw?
>
>
> Cheers,
>
> Aleksander Budzynowski
>