[ClusterLabs] Antw: Re: cross DC cluster using public ip?
Ulrich Windl
Ulrich.Windl at rz.uni-regensburg.de
Fri Oct 14 07:45:39 UTC 2016
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 <nwarriorch at gmail.com> schrieb am 13.10.2016 um 22:14 in Nachricht
<CAKvLDn764vEnqasnFDUgPpq7fR=Vjovo_JyGxjs5nRk8pM8bbQ at 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 <kwenning at 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 at 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 at 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 at 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
>>
More information about the Users
mailing list