Mailing List Archive

On 27/01/15 15:56, Kostiantyn Ponomarenko wrote:
> Hi all,
>
> Here is a situation - there are two "two-node" clusters.
> They have totally identical configuration.
> Nodes in the clusters are connected directly, without any switches.
>

You can't connect clusters together like that. All nodes in the cluster
have just 1 authkey file. Also, corosync clusters are a ring, even if
you have two nodes. What you have there is not a ring, it's err, a
linked-cross?!

Why do you need to connect the two clusters together - is it for
failover? There must be a better way of achieving what you need, have a
look for 'stretch clusters' (not my speciality TBH) if they are at
separate sites. If you just want to run resources outside of the cluster
then pacemaker_remote might be more useful.

If it's just for isolation of resources then pacemaker can do that
anyway so you don't need to partition the cluster like that.

If you can explain just why you think you need this system we might be
able to come up with something that will work :)

Chrissie

> totem {
> version: 2
>
> cluster_name: mycluster
> transport: udpu
>
> crypto_hash: sha256
> crypto_cipher: none
> rrp_mode: passive
> }
>
> nodelist {
> node {
> name: node-a
> nodeid: 1
> ring0_addr: 169.254.0.2
> ring1_addr: 169.254.1.2
> }
>
> node {
> name: node-b
> nodeid: 2
> ring0_addr: 169.254.0.3
> ring1_addr: 169.254.1.3
> }
> }
>
> The only difference between those two clusters is authentication key (
> /etc/corosync/authkey ) - it is different for both clusters.
>
> QUESTION:
> ------------------
> What will be the behavior if the next mess in connection occurs:
> "ring1_addr" of node-a (cluster-A) is connected to "ring1_addr" of node-b
> (cluster-B)
> "ring1_addr" of node-a (cluster-B) is connected to "ring1_addr" of node-b
> (cluster-A)
>
> I attached a pic which shows the connections.
>
> My actual goal - do not let the clusters work in such case.
> To achieve it, I decided to use "authentication key" mechanism.
> But I don't know the result in the situation which I described ... .
>
> Thank you,
> Kostya
>
>
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
>


_______________________________________________
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Hi Chrissie,

I know that this setup it crazy thing =)
First of all I needed to say - think about each two-node cluster as one box
with two nodes.

> You can't connect clusters together like that.
I know that.

>All nodes in the cluster have just 1 authkey file.
That is true. But in this example there are two clusters, each of them have
its own auth key.

>What you have there is not a ring, it's err, a linked-cross?!
Yep, I showed the wrong way of connecting two clusters.

> Why do you need to connect the two clusters together - is it for failover?
No, it is not. I really don't (and won't) connect them in that way. It
wrong.
But, in real life those two clusters will be standing (physically, in the
same room, in the same rack) pretty close to each other.
And my concern is - if someone do that connection by a mistake. What will
be in that situation?
What I would like to get in that situation, is something which prevent
simultaneous work of two nodes in one cluster - because it will cause data
corruption.

The situation is pretty simple when there is only one "ring_addr" defined
per node.
In this case, when some one cross-linked two separate clusters, it will
lead to 4 clusters each of which is missing one node - because two
connected nodes has different auth keys, and that is why they will not see
each other even when there is a connection.
STONITH always works in the same cluster.
So, STONITH will be rebooting the other one in the cluster.
That will prevent simultaneous access to the data.

I tried to do my best in describing the situation, the problem and the
question.
Looking forward to hear any suggestions =)


Thank you,
Kostya

On 27/01/15 17:20, Kostiantyn Ponomarenko wrote:
> Hi Chrissie,
>
> I know that this setup it crazy thing =)
> First of all I needed to say - think about each two-node cluster as one box
> with two nodes.
>
>> You can't connect clusters together like that.
> I know that.
>
>> All nodes in the cluster have just 1 authkey file.
> That is true. But in this example there are two clusters, each of them have
> its own auth key.
>
>> What you have there is not a ring, it's err, a linked-cross?!
> Yep, I showed the wrong way of connecting two clusters.
>
>> Why do you need to connect the two clusters together - is it for failover?
> No, it is not. I really don't (and won't) connect them in that way. It
> wrong.
> But, in real life those two clusters will be standing (physically, in the
> same room, in the same rack) pretty close to each other.
> And my concern is - if someone do that connection by a mistake. What will
> be in that situation?
> What I would like to get in that situation, is something which prevent
> simultaneous work of two nodes in one cluster - because it will cause data
> corruption.

Oh I see! Sorry, I thought that was a deliberate installation plan - I'm
pleased to hear that it's not :)

What will happen if the clusters do get connected is that you will just
get a lot of errors printed to syslog as corosync rejects the messages
with the wrong authkey. Your data will be safe but you might get some
slowdown. If that slowdown is severe (maybe both clusters are very busy)
there is a small chance that it might cause a fencing action.

I hope this helps

Chrissie


_______________________________________________
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Hi Chrissie,

On Thu, Jan 29, 2015 at 11:44 AM, Christine Caulfield <ccaulfie@redhat.com>
wrote:

> as corosync rejects the messages
> with the wrong authkey
>

And I suppose that it is enough just to use "crypto_hash" option.
I am right?

Thank you,
Kostya

Chrissie, one more thing.

And I also suppose that the key is read only one time at the start-up of
the Corosync.
In other words there is no any check for the presence of the key or its
update, while Corosync is working.
Am I right?

Thank you,
Kostya

On Thu, Feb 5, 2015 at 2:42 PM, Kostiantyn Ponomarenko <
konstantin.ponomarenko@gmail.com> wrote:

> Hi Chrissie,
>
> On Thu, Jan 29, 2015 at 11:44 AM, Christine Caulfield <ccaulfie@redhat.com
> > wrote:
>
>> as corosync rejects the messages
>> with the wrong authkey
>>
>
> And I suppose that it is enough just to use "crypto_hash" option.
> I am right?
>
> Thank you,
> Kostya
>

On 02/05/2015 01:47 PM, Kostiantyn Ponomarenko wrote:
> Chrissie, one more thing.
>
> And I also suppose that the key is read only one time at the start-up of
> the Corosync.
> In other words there is no any check for the presence of the key or its
> update, while Corosync is working.
> Am I right?
>

That's correct, yes :)

Chrissie


> Thank you,
> Kostya
>
> On Thu, Feb 5, 2015 at 2:42 PM, Kostiantyn Ponomarenko <
> konstantin.ponomarenko@gmail.com> wrote:
>
>> Hi Chrissie,
>>
>> On Thu, Jan 29, 2015 at 11:44 AM, Christine Caulfield <ccaulfie@redhat.com
>>> wrote:
>>
>>> as corosync rejects the messages
>>> with the wrong authkey
>>>
>>
>> And I suppose that it is enough just to use "crypto_hash" option.
>> I am right?
>>
>> Thank you,
>> Kostya
>>
>
>
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
>


_______________________________________________
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Chrissie, thank you! =)
It helps!

Thank you,
Kostya

On Thu, Feb 5, 2015 at 3:59 PM, Christine Caulfield <ccaulfie@redhat.com>
wrote:

> On 02/05/2015 01:47 PM, Kostiantyn Ponomarenko wrote:
> > Chrissie, one more thing.
> >
> > And I also suppose that the key is read only one time at the start-up of
> > the Corosync.
> > In other words there is no any check for the presence of the key or its
> > update, while Corosync is working.
> > Am I right?
> >
>
> That's correct, yes :)
>
> Chrissie
>
>
> > Thank you,
> > Kostya
> >
> > On Thu, Feb 5, 2015 at 2:42 PM, Kostiantyn Ponomarenko <
> > konstantin.ponomarenko@gmail.com> wrote:
> >
> >> Hi Chrissie,
> >>
> >> On Thu, Jan 29, 2015 at 11:44 AM, Christine Caulfield <
> ccaulfie@redhat.com
> >>> wrote:
> >>
> >>> as corosync rejects the messages
> >>> with the wrong authkey
> >>>
> >>
> >> And I suppose that it is enough just to use "crypto_hash" option.
> >> I am right?
> >>
> >> Thank you,
> >> Kostya
> >>
> >
> >
> >
> > _______________________________________________
> > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
> > http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> >
> > Project Home: http://www.clusterlabs.org
> > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> > Bugs: http://bugs.clusterlabs.org
> >
>
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
>