ctdb, haproxy, and ip_nonlocal_bind

Martin Schwenke martin at meltin.net
Thu Jan 30 05:15:36 UTC 2020


On Wed, 29 Jan 2020 16:43:07 -0500, Wyllys Ingersoll via
samba-technical <samba-technical at lists.samba.org> wrote:

> I have a cluster in which I want to use both haproxy AND ctdb on the same
> nodes - haproxy to manage NFSv4 (ganesha) and CTDB to manage SMB.  The
> reason for doing this is that I've read several warnings about NOT using
> NFSv4 with CTDB.
> 
> haproxy + keepalived require that the net.ipv4.ip_nonlocal_bind flag be set
> to 1 which breaks ctdb's ability to manage the virtual public IP addresses
> (among other things).
> 
> If I do not configure any public_addresses and just let haproxy configure
> the virtual public IP addresses, CTDB is still unable to startup on both of
> the nodes in my test cluster.  It will start on one or the other, but they
> never sync up and come to an "OK" state on both nodes.
> 
> I have the "node address" value set in the [cluster] section of ctdb.conf
> on each node to be the private address of that node and both private
> addresses are listed in the nodes configuration file and the nodes are
> connecting to each other privately, but they don't stay connected and the
> 2nd ctdb node never fully initializes and starts up.  At some point it just
> begins flooding the logs with messages like this "node 192.168.113.14:4379
> is already marked disconnected: 0 connected" and pegging the CPU at almost
> 100% until the disk with the logging completely fills up (which sounds like
> a bug, btw).
> 
> Does anyone know of any way to make this sort of configuration work ?
> 
> Currently running Samba 4.10.10, haproxy 1.6.3, and Linux Kernel 4.19.34 on
> Ubuntu 16.04.4
> 
> Any help would be much appreciated.

Using "node address" should make this work.

However, you're being bitten this bug:

  https://bugzilla.samba.org/show_bug.cgi?id=14175

This is fixed in Samba 4.10.13.

I hope that upgrading makes this work for you.  Please let us know if
it doesn't...

peace & happiness,
martin



More information about the samba-technical mailing list