CTDB in Samba4

[tridge at samba.org]

Abhijith,

 > 1. As I understand it, ctdb is being included in Samba4. Is there an 
 > effort to backport it to Samba3?

The plan is to make it available in both. It was initially prototyped
as a standalone library and test suite without being linked to either
Samba3 or Samba4. I'm now working on integrating it in Samba4, and I
hope it will also be integrated in Samba3 at some stage. That depends
on the availability of someone to do the work, plus there are some
additional features in ctdb that are needed before it can be used in
Samba3 (in particular the dispatcher daemon split must be done).

 > 2. Are ctdb and tdb inter-changeable as far as samba is concerned? i.e 
 > can we plug in one or the other into Samba with ease?

no, the API is quite different. The link to tdb is that ctdb uses tdb
as its local storage mechanism, and uses tdb data structures. It
wasn't possible to reach the level of efficiency we wanted (in terms
of packet roundtrips) while keeping the tdb API.

What I've done for the locking backend is that you can choose either
the "brlock tdb" or "brlock ctdb" locking backend at runtime. I expect
to the do the same for the other databases.

Recoding the brlock database code to use ctdb took me about 2 days of
initial work, then about 5 days of debugging :-)

Now that I've learned some more debugging tricks with ctdb I hope it
will take less time with the other databases.

 > 3. Transparent failover of samba services: As I'd understood it before, 
 > transparent failover of a samba service from one node to another was not 
 > possible without the client reconnecting (as active connections to smbd 
 > are severed). Does ctdb (or any other current clustering effort) allow 
 > for transparent failover of samba services across nodes?

Transparent failover in terms of the tcp connection being undisturbed
is not an aim of the ctdb clustering code, and doesn't really make
sense anyway. The CIFS protocol is based around an idea of the client
keeping sufficient state to allow it to reestablish its open resources
on the server when it reconnects. So with ctdb we will make that
easier as the client can reconnect to any of the nodes when its
current node goes down, but we don't attempt to do any TCP level magic
to avoid the client reconnect.

Cheers, Tridge