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
>