CTDB by default in Debina lenny? (was: [Pkg-samba-maint] Situation of various samba packages)

Mathieu PARENT math.parent at gmail.com
Fri Jul 11 18:35:09 GMT 2008


> 90.ipmux is obsolete so dont bother with that one.
> 91.lvs is a way to make the entire cluster act as one single ip
> address. This replaces 90.ipmux
> (lvs used to emulate a layer-4 loadbalancing switch)
> Please see the docs for what lvs is and how to set it up in the
> manpages of the latest 1.0.46 version.

I put this on my TODO list, but won't test it soon. Maybe someone else
can take it?

> One critical thing is in /etc/ctdb/functions. That is to ensure that
> the "tcp socketkiller" works correctly.
> This is a tool that kills off tcp connections  when we do fast ip
> failover between nodes.
> A similar approach is also used to "kickstart" tcp connections that
> may be in a retransmission timeout state
> while we do failover (we call this tickle-ack)
> Can you please verify that the socketkiller works?
> This is how to do it :
> 1, Startup ctdb/samba.
> 2, Create a TCP connection to samba.   Just do "telnet <public address> 445"
> 3, On the ctdb node that is currently hosting this public address,
> check with netstat -a -n and find this TCP connection.
> 4a, On this node, run "ctdb killtcp <srcip:port> <dstip:port>" for
> that TCP connection.
>     Now check with netstat -a -n on both this node and also on the client.
>     On one of the sides, either the client or the node,  that TCP
> connection should be killed and no longer in ESTABLISHED state.
> 4b, Do the same as before but this time run it as "ctdb killtcp
> <dstip:port> <src:ip>"
>     This time the other end of the TCP connection should have been killed.

I've tested both 4& and 4b and it works! Great...

> This is the most important part. So if this work, there is nothing
> else very vital that needs to be checked.
> I tried to fixup the paths to executables a while ago    but that was
>>6months ago  so there might have crept in some paths
> to executables either in the eventscripts or in /etc/ctdb/functions
> that are only valid on RHEL which i use.

They seems to be valid. Just note that I had problem with ipv6 (solved
this by disabling the unneeded ipv6 interfaces).

> 70.iscsi only works with the STGT iscsi target. So if you dont ship
> with an iSCSI target or you ship one of the other targets and not STGT
> it wont work and you wont have to worry about that script.
> (STGT is nice since it can emulate a huge jukebox with burnable DVD+R
> disks in it.   Yeeehaaa)
I don't have STGT iscsi, and even any iscsi. I use FC channel SAN
which doesn't seems to require a ctdb managgement.

> Please also test that the NFS stuff works in some capacity.
> Just configure it according to ctdb.samba.org and make sure that ctdb
> does start and stop the nfs service correctly.
This one will probably take more time...

> I dont have any systems running debian, but If someone sends me a DVD
> with debian i can build a virtual cluster and test.
> Othervise, to make sure NFS should work reasonably,  this needs a
> cluster with at least 2 nodes and one nfs client.
> 1, Set up NFS with CTDB
> 2, Start a network trace on the client.
> 3, Mount an export from a public address of the cluster.
> 4, Do an ls on the client to make sure NFS works
> 5, check with netstat on the client and also on all the nodes that the
> connection is ESTABLISHED on the correct node.
> 6, disable the node that is currently hosting that public address
> ("ctdb -n all ip" will tell you which node is holding that ip)
>    by   "ctdb disable -n <nodeid>"
> 7, Use ls again and it should hopefully still work
> 8, Check with netstat -a -n again on the nodes,   the TCP connection
> should now have moved to a different node.
> Send the network trace to me and I can verify it looks good. I also
> need the mac addresses for the public interface on all the ctdb nodes
> to verify.

Will do this after a complete test of samba.

> regards
> ronnie sahlberg

Mathieu Parent

More information about the samba-technical mailing list