[Pacemaker] authentication in the cluster

Discussion:

Kostiantyn Ponomarenko

2015-01-27 15:56:01 UTC

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.

Here is a part of corosync.comf file:

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

Christine Caulfield

2015-01-27 16:32:48 UTC

Permalink

Post by Kostiantyn Ponomarenko
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

Post by Kostiantyn Ponomarenko
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.
------------------
"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
_______________________________________________
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: ***@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

Kostiantyn Ponomarenko

2015-01-27 17:20:58 UTC

Permalink

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.

Post by Christine Caulfield
You can't connect clusters together like that.

I know that.

Post by Christine Caulfield
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.

Post by Christine Caulfield
What you have there is not a ring, it's err, a linked-cross?!

Yep, I showed the wrong way of connecting two clusters.

Post by Christine Caulfield
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

Christine Caulfield

2015-01-29 09:44:41 UTC

Permalink

Post by Kostiantyn Ponomarenko
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.

Post by Christine Caulfield
You can't connect clusters together like that.

I know that.

Post by Christine Caulfield
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.

Post by Christine Caulfield
What you have there is not a ring, it's err, a linked-cross?!

Yep, I showed the wrong way of connecting two clusters.

Post by Christine Caulfield
Why do you need to connect the two clusters together - is it for failover?

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: ***@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

Kostiantyn Ponomarenko

2015-02-05 12:42:31 UTC

Permalink

Hi Chrissie,

Post by Christine Caulfield
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

Kostiantyn Ponomarenko

2015-02-05 12:47:22 UTC

Permalink

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 <

Post by Kostiantyn Ponomarenko
Hi Chrissie,

Post by Christine Caulfield
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

Christine Caulfield

2015-02-05 13:59:36 UTC

Permalink

Post by Kostiantyn Ponomarenko
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

Post by Kostiantyn Ponomarenko
Thank you,
Kostya
On Thu, Feb 5, 2015 at 2:42 PM, Kostiantyn Ponomarenko <

Post by Kostiantyn Ponomarenko
Hi Chrissie,

Post by Christine Caulfield
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

_______________________________________________
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

Kostiantyn Ponomarenko

2015-02-05 14:30:32 UTC

Permalink

Chrissie, thank you! =)
It helps!

Thank you,
Kostya

Post by Christine Caulfield

That's correct, yes :)
Chrissie

Post by Kostiantyn Ponomarenko
Thank you,
Kostya
On Thu, Feb 5, 2015 at 2:42 PM, Kostiantyn Ponomarenko <

Post by Kostiantyn Ponomarenko
Hi Chrissie,
On Thu, Jan 29, 2015 at 11:44 AM, Christine Caulfield <

Post by Christine Caulfield
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