corosync behind a NAT or within docker

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm been looking at the corosync source code to see if I could figure
out a way to get it to run behind a NAT (or in my case, within a docker
container). I'm only interested in the unicast UDP case. It looks like
corosync is sending commit tokens to all discovered nodes, and these
commit tokens include the IP addresses of all discovered nodes,
including the 'this' node. That is, in a two node case, if node A is a
machine with an interface with IP 192.168.0.1, and machine B is on the
WAN with IP 7.7.7.7, node A sends a commit token like this:
dest: 7.7.7.7
  nodeid: 0   ip: 192.168.0.1

node B sees this token, updates it's own commit token with the IP
192.168.0.1 and in turn tries to contact 192.168.0.1, which of course
fails because there is no corosync host running on B's network. I'm a
little fuzzy on the details because I've only just started to look at
this, but it looks like node B forgets about the configured WAN address
of A and overwrites it with A's internal IP.

Why would a node on a corosync cluster send its own IP address as part
of a commit token? Why wouldn't each node implicitly know there was a
sender node in addition to the list of nodes that already exists in the
received commit token?

I'm guessing I'm not the first person to want to run corosync behind a
NAT, but a google search hasn't turned up much as to why this isn't
supported. I can't think of a technical reason, and it bothers me.

Thanks,
Chris
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss



[Index of Archives]     [Linux Clusters]     [Corosync Project]     [Linux USB Devel]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Linux Kernel]     [Linux SCSI]     [X.Org]

  Powered by Linux