Corosync does not work with NAT. At least I tried for AGES and could not get it to.
Easiest is to set up a VPN between the sites or servers for just the corosync traffic. On 13.10.2016 22:14, neeraj ch wrote: > Hello > > Thank you for taking the time to respond. > > In my setup the public IP is not on the box , the box is attached to a > private network and packets to the public IP I think are just forwarded > to the private IP. > > When I tried using the local private address as the bind address , > public address as the member address and ran a tcp dump , both nodes are > sending packets to each other over the public IP but they are responding > to each other's private address Instead of just responding back to the > address the packet arrived from. It looks like corosync is sending the > IP its listening on , and the other node is trying to respond to it , > and hence if corosync binds to a private address a node not in the same > DC will not be able to respond to it. > > Is this how corosync works ? > > Is there a way to force the node to respond to the IP its receiving > packets from ? or to broad cast its public IP rather than the private IP > ? Would it be any better if I used corosync 2.X , for the same setup ? > > On Thu, Oct 13, 2016 at 12:41 AM, Klaus Wenninger <kwenn...@redhat.com > <mailto:kwenn...@redhat.com>> wrote: > > On 10/13/2016 09:30 AM, Jan Friesse wrote: > > neeraj ch napsal(a): > >> Hello , > >> > >> We are testing out corosync and pacemaker for DB high availability on > >> the > >> cloud. I was able to set up a cluster with in a DC using corosync 1.4 > >> and > >> pacemaker 1.12. It works great and I wanted to try a cross DC cluster. > I > >> was using unicast as multicast was disabled by default. > >> > >> I was not sure how Corosync behaves with public IP's but I still went > >> ahead > >> and tried it with both public IP's as well as DNS names. These DNS > names > >> resolve as local IP when the other node is with in the same subnet. > > > > Every node has to be able to see every other node. So mixing of public > > and private ips is not going to work (with exception of special case > > where all private ips are in the same network). Also keep in mind > > config file has to be same on all nodes. > > Guess reason is that corosync derives an ID from the IP. > So the hostname has to resolve to the same IP on all nodes > and under all circumstances. > > Oh Got It. > > > > > > > >> > >> while I was using public IP's both the node inside the same subnet as > >> well > >> as outside were unable to connect, except for itself. While using DNS > >> names > >> the membership information showed the nodes within same subnet being > >> connected to while the nodes outside were not connected > > > > This is somehow expected. > >> > >> > >> My corosync config is as follows. > >> > >> totem { > >> version: 2 > >> secauth: off > >> threads: 0 > >> interface { > >> > >> member { > >> memberaddr: <public ip> > >> } > >> member { > >> memberaddr: <public ip> > >> } > >> member { > >> memberaddr: <public ip> > >> } > >> ringnumber: 0 > >> bindnetaddr: 172.31.0.0 > >> mcastport: 5405 > >> ttl: 1 > >> } > >> transport: udpu > >> } > >> > >> logging { > >> fileline: off > >> to_stderr: no > >> to_logfile: yes > >> to_syslog: yes > >> logfile: /var/log/cluster/corosync.log > >> debug: on > >> timestamp: on > >> logger_subsys { > >> subsys: AMF > >> debug: on > >> } > >> } > >> > >> service { > >> # Load the Pacemaker Cluster Resource Manager > >> name: pacemaker > >> ver: 1 > >> } > >> > >> amf { > >> mode: disabled > >> } > >> > >> > >> I am checking membership information by using corosync-objctl. I have > >> also > >> tried using public ip as the bind address , that makes the membership > >> from > > > > Just to make sure. This "public" ip is really ip of given machine? > > > >> 1 to 0 as it doesn't add itself. > >> > >> If any one has any suggestion / advice on how to debug or what I am > >> doing > >> wrong . Any help would be very appreciated. > >> > >> Thank you > >> > >> > >> > >> _______________________________________________ > >> Users mailing list: Users@clusterlabs.org > <mailto:Users@clusterlabs.org> > >> http://clusterlabs.org/mailman/listinfo/users > <http://clusterlabs.org/mailman/listinfo/users> > >> > >> Project Home: http://www.clusterlabs.org > >> Getting started: > http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > <http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf> > >> Bugs: http://bugs.clusterlabs.org > >> > > > > > > _______________________________________________ > > Users mailing list: Users@clusterlabs.org > <mailto:Users@clusterlabs.org> > > http://clusterlabs.org/mailman/listinfo/users > <http://clusterlabs.org/mailman/listinfo/users> > > > > Project Home: http://www.clusterlabs.org > > Getting started: > http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > <http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf> > > Bugs: http://bugs.clusterlabs.org > > > > _______________________________________________ > Users mailing list: Users@clusterlabs.org <mailto:Users@clusterlabs.org> > http://clusterlabs.org/mailman/listinfo/users > <http://clusterlabs.org/mailman/listinfo/users> > > Project Home: http://www.clusterlabs.org > Getting started: > http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > <http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf> > Bugs: http://bugs.clusterlabs.org > > > > > _______________________________________________ > Users mailing list: Users@clusterlabs.org > http://clusterlabs.org/mailman/listinfo/users > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org > _______________________________________________ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org