Hi! The misconception that a "node" is an "IP address" originates from the times where each Internet host had one IP address. Hardware was considered to be so expensive that nobody would ever afford a second NIC ;-) Today it's different: No system should try to derive a node id from an ID of an interface, and no system should compare a node ID to the address a message was received on. These are different concepts: a node ID identifies a node (with possibly many interfaces), while an IP address identifies a network access point (basically a network).
I don't know what corosync does, but likely the wrong thing. In a closed world (like a cluster) I think it would be OK to manually(!) base a host ID on a private IP address (YOU assign it, and YOU are responsible for it; don't blame corosync). Regards, Ulrich >>> neeraj ch <nwarrio...@gmail.com> schrieb am 13.10.2016 um 22:14 in Nachricht <CAKvLDn764vEnqasnFDUgPpq7fR=vjovo_jygxjs5nrk8pm8...@mail.gmail.com>: > 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> > 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 >> >> 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 >> >> >> >> _______________________________________________ >> 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