<div dir="ltr"><div>Hello </div><div><br></div>Thank you for taking the time to respond. <div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>Is this how corosync works ? </div><div><br></div><div>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 ?  </div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 13, 2016 at 12:41 AM, Klaus Wenninger <span dir="ltr"><<a href="mailto:kwenning@redhat.com" target="_blank">kwenning@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/13/2016 09:30 AM, Jan Friesse wrote:<br>
> neeraj ch napsal(a):<br>
>> Hello ,<br>
>><br>
>> We are testing out corosync and pacemaker for DB high availability on<br>
>> the<br>
>> cloud. I was able to set up a cluster with in a DC using corosync 1.4<br>
>> and<br>
>> pacemaker 1.12. It works great and I wanted to try a cross DC cluster. I<br>
>> was using unicast as multicast was disabled by default.<br>
>><br>
>> I was not sure how Corosync behaves with public IP's but I still went<br>
>> ahead<br>
>> and tried it with both public IP's as well as DNS names. These DNS names<br>
>> resolve as local IP when the other node is with in the same subnet.<br>
><br>
> Every node has to be able to see every other node. So mixing of public<br>
> and private ips is not going to work (with exception of special case<br>
> where all private ips are in the same network). Also keep in mind<br>
> config file has to be same on all nodes.<br>
<br>
</span>Guess reason is that corosync derives an ID from the IP.<br>
So the hostname has to resolve to the same IP on all nodes<br>
and under all circumstances.<br></blockquote><div>Oh Got It.  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
>><br>
>> while I was using public IP's both the node inside the same subnet as<br>
>> well<br>
>> as outside were unable to connect, except for itself. While using DNS<br>
>> names<br>
>> the membership information showed the nodes within same subnet being<br>
>> connected to while the nodes outside were not connected<br>
><br>
> This is somehow expected.<br>
>><br>
>><br>
>> My corosync config is as follows.<br>
>><br>
>> totem {<br>
>>        version: 2<br>
>>        secauth: off<br>
>>        threads: 0<br>
>>        interface {<br>
>><br>
>>                 member {<br>
>>                    memberaddr: <public ip><br>
>>                 }<br>
>>                member {<br>
>>                    memberaddr: <public ip><br>
>>                 }<br>
>>                 member {<br>
>>                    memberaddr: <public ip><br>
>>                 }<br>
>>                 ringnumber: 0<br>
>>                 bindnetaddr: 172.31.0.0<br>
>>                 mcastport: 5405<br>
>>                 ttl: 1<br>
>>        }<br>
>>        transport: udpu<br>
>> }<br>
>><br>
>> logging {<br>
>>        fileline: off<br>
>>        to_stderr: no<br>
>>        to_logfile: yes<br>
>>        to_syslog: yes<br>
>>        logfile: /var/log/cluster/corosync.log<br>
>>        debug: on<br>
>>        timestamp: on<br>
>>        logger_subsys {<br>
>>                 subsys: AMF<br>
>>                 debug: on<br>
>>        }<br>
>> }<br>
>><br>
>> service {<br>
>>          # Load the Pacemaker Cluster Resource Manager<br>
>>          name: pacemaker<br>
>>          ver: 1<br>
>> }<br>
>><br>
>> amf {<br>
>>        mode: disabled<br>
>> }<br>
>><br>
>><br>
>> I am checking membership information by using corosync-objctl. I have<br>
>> also<br>
>> tried using public ip as the bind address , that makes the membership<br>
>> from<br>
><br>
> Just to make sure. This "public" ip is really ip of given machine?<br>
><br>
>> 1 to 0 as it doesn't add itself.<br>
>><br>
>> If any one has any suggestion / advice on how to debug or what I am<br>
>> doing<br>
>> wrong . Any help would be very appreciated.<br>
>><br>
>> Thank you<br>
>><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
>> <a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/<wbr>mailman/listinfo/users</a><br>
>><br>
>> Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
>> Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/<wbr>doc/Cluster_from_Scratch.pdf</a><br>
>> Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
>><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
> <a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/<wbr>mailman/listinfo/users</a><br>
><br>
> Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
> Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/<wbr>doc/Cluster_from_Scratch.pdf</a><br>
> Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
<a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/<wbr>mailman/listinfo/users</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/<wbr>doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
</div></div></blockquote></div><br></div></div>