Transparent Failover Samba\CTDB

Justin Shafer justinshafer at
Mon Jul 12 01:29:03 MDT 2010

Hi Samba Team!


I have been learning clusters for the past several months and last night I
realized something last night.. I have been testing a program called Dentrix
with Windows Failover-Server 08 R2, and Steel-Eye (and various other
replication software).


And I have been testing Dentrix with SLES11, DRBD, Corosync\Openais.. and
CTDB and Samba.


I read on the mailing list that transparent failover isn't really going to
happen until SMB2 and durable file handles. And I have talked to some guys
it etc, etc. Basically we want a way to have the oplocks transferred from
node1 to node2 if node1 dies. I don't really care too much about having the
tdb files replicated on both nodes, but if that's a pre-requisite then that
make sense if the oplocks are stored in tdb files rather then just ram


But I tested Dentrix 11.0 with Failover Server 08 and Steel-Eye and when I
kill the power on Node 1, the Dentrix Scheduler program hangs for a quick
second and then pulls through fine. Oplocks intact.


With Samba\CTDB.. when I kill the power on a node, I have to kill the
dentrix program and open it back up, without reconnecting my mapped drive,
with LVS Mode for CTDB instead of round-robin. That's good, and really
really close. But I was wondering If transparent failover will ever be
achieved for applications that are going to stay as SMB1 without durable
file handles. In other words, are we ever going to see the oplocks getting
transferred from node1 to node2? Is this something that ctdb is supposed to
do or samba alone?? How does CTDB act with PDC and BDC, vs two standalones?
Does it matter?


I guess something that throws me off is some directions call for the private
directory and secrets.tdb or smbpasswd to be put on a shared filesystem and
others have told me not too. And then I wonder if it's the filesystem..
right now Im using ocfs2 but Im thinking of going torwards Lustre... or
maybe I need NFS???


Any advice?


-Justin Shafer

More information about the samba-technical mailing list