Il 17/10/2019 16:47, Raffaele Pantaleoni ha scritto:
Il 17/10/2019 14:51, Jan Pokorný ha scritto:
On 17/10/19 08:22 +0200, Raffaele Pantaleoni wrote:
I'm rather new to Pacemaker, I'm performing early tests on a set of
three virtual machines.
I am configuring the cluster in the following way:
3 nodes configured
4 resources configured
Online: [ SRVDRSW01 SRVDRSW02 SRVDRSW03 ]
ClusterIP (ocf::heartbeat:IPaddr2): Started SRVDRSW01
CouchIP (ocf::heartbeat:IPaddr2): Started SRVDRSW03
FrontEnd (ocf::heartbeat:nginx): Started SRVDRSW01
ITATESTSERVER-DIP (ocf::nodejs:pm2): Started SRVDRSW01
with the following constraints:
Location Constraints:
Resource: ClusterIP
Enabled on: SRVRDSW01 (score:200)
Enabled on: SRVRDSW02 (score:100)
Resource: CouchIP
Enabled on: SRVRDSW02 (score:10)
Enabled on: SRVRDSW03 (score:100)
Disabled on: SRVRDSW01 (score:-INFINITY)
Resource: FrontEnd
Enabled on: SRVRDSW01 (score:200)
Enabled on: SRVRDSW02 (score:100)
Resource: ITATESTSERVER-DIP
Enabled on: SRVRDSW01 (score:200)
Enabled on: SRVRDSW02 (score:100)
Ordering Constraints:
start ClusterIP then start FrontEnd (kind:Mandatory)
start ClusterIP then start ITATESTSERVER-DIP (kind:Mandatory)
Colocation Constraints:
FrontEnd with ClusterIP (score:INFINITY)
FrontEnd with ITATESTSERVER-DIP (score:INFINITY)
I've configured the cluster with an opt in strategy using the following
commands:
crm_attribute --name symmectric-cluster --update false
pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=172.16.10.126
cidr_netmask=16 op monitor interval=30s
pcs resource create CouchIP ocf:heartbeat:IPaddr2 ip=172.16.10.128
cidr_netmask=16 op monitor interval=30s
pcs resource create FrontEnd ocf:heartbeat:nginx
configfile=/etc/nginx/nginx.conf
pcs resource create ITATESTSERVER-DIP ocf:nodejs:pm2 user=ITATESTSERVER
--force
pcs constraint colocation add FrontEnd with ClusterIP INFINITY
pcs constraint colocation add FrontEnd with ITATESTSERVER-DIP INFINITY
pcs constraint order ClusterIP then FrontEnd
pcs constraint order ClusterIP then ITATESTSERVER-DIP
pcs constraint location ClusterIP prefers SRVRDSW01=200
pcs constraint location ClusterIP prefers SRVRDSW02=100
pcs constraint location CouchIP prefers SRVRDSW02=10
pcs constraint location CouchIP prefers SRVRDSW03=100
pcs constraint location FrontEnd prefers SRVRDSW01=200
pcs constraint location FrontEnd prefers SRVRDSW02=100
pcs constraint location ITATESTSERVER-DIP prefers SRVRDSW01=200
pcs constraint location ITATESTSERVER-DIP prefers SRVRDSW02=100
Everything seems to be ok but when I put vm 02 and 03 in standby I'd
expect
CouchIP not be assigned to vm 01 beacuse of the constraint.
The IPaddr2 resource gets assigned to vm 01 no matter what.
Node SRVDRSW02: standby
Node SRVDRSW03: standby
Online: [ SRVDRSW01 ]
Full list of resources:
ClusterIP (ocf::heartbeat:IPaddr2): Started SRVDRSW01
CouchIP (ocf::heartbeat:IPaddr2): Started SRVDRSW01
FrontEnd (ocf::heartbeat:nginx): Started SRVDRSW01
ITATESTSERVER-DIP (ocf::nodejs:pm2): Started SRVDRSW01
crm_simulate -sL returns the follwoing
---cut---
native_color: CouchIP allocation score on SRVDRSW01: 0
native_color: CouchIP allocation score on SRVDRSW02: 0
native_color: CouchIP allocation score on SRVDRSW03: 0
---cut---
Why is that? I have explicitly assigned -INFINITY to CouchIP resource
related to node SRVDRSW01 (as stated by pcs constraint: Disabled on:
SRVRDSW01 (score:-INFINITY) ).
What am I missing or doing wrong?
I am not that deep into these relationships, proper design
documentation with guided examples is non-existent[*].
But it occurs to me that the situation might be the inverse of what's
been confusing for typical opt-out clusters:
https://lists.clusterlabs.org/pipermail/users/2017-April/005463.html
Have you tried avoiding:
Resource: CouchIP
Disabled on: SRVRDSW01 (score:-INFINITY)
Yes, I already tried that, but I did it again nevertheless since I am a
newbie. I deleted the whole set of resources and commented out the
constraint from the creation script.
The cluster was running, then I put all the nodes in standby and brought
SRVRDSW01 back. The CouchIP resource has been bound to the "forbidden"
node.
crm_simulate -sL still gives a score of 0 to the three nodes when it
should be something like -INFINITY 100 and 200 respectively.
Just to make the whole thing more confusing: I noticed that SRVRDSW03,
that is (implicitly) not allowed to get the ClusterIP resource is marked
(correctly) as -INFINITY from crm_simulate. So the opt in
configuration would seem to be correct, but for the CouchIP resource
that is no special or different from the ClusterIP resource.
I am really disoriented.
Just another bit of information: I put the whole set in stand by then
brought back SRVRDSW03... surprise surprise the ClusterIP resource has
been bound to it even if it shouldn't.
What's wrong?
altogether, since when such explicit edge would be missing, implicit
"cannot" (for opt-in cluster) would apply anyway, and perhaps even
reliably, then?
[*] as far as I know, except for
https://wiki.clusterlabs.org/w/images/a/ae/Ordering_Explained_-_White.pdf
https://wiki.clusterlabs.org/w/images/8/8a/Colocation_Explained_-_White.pdf
probably not revised for giving a truthful model in all details
for years,
and not demonstrating the effect of symmetry requested or avoided
within
the cluster on those, amongst others
(shameless plug: there will be such coverage for upcoming group
based
access control addition [those facilities haven't been terminated in
back-end so far] as a first foray in this area -- also the correct
understanding is rather important here)
_______________________________________________
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users
ClusterLabs home: https://www.clusterlabs.org/
Thank you for your reply.
--
*Raffaele Pantaleoni*
*IOT Design R&D Unit*
Tel. +39 0746 605885
Fax. +39 0746 607072
Mail *r.pantale...@seko.com <mailto:r.pantale...@seko.com>*
Skype r.pantaleoni.seko
*www.seko.com* <https://www.seko.com/> **
/This e-mail (including attachments) is intended only for the
recipient(s) named above. It may contain confidential or privileged
information. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system. E-mail transmission cannot be
guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
contain viruses. The sender therefore does not accept liability for any
errors or omissions in the contents of this message, which arise as a
result of e-mail transmission. If verification is required please
request a hard-copy version. Your personal data will be processed in
compliance with the EU General Data Protection Regulation n. 2016/679
("GDPR"), applicable since May 25th, 2018. For further information,
please see our Privacy Policy <https://www.seko.com/page/privacy-policy>/
_______________________________________________
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users
ClusterLabs home: https://www.clusterlabs.org/
