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) 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) -- Jan (Poki)
pgpbiSVttiBML.pgp
Description: PGP signature
_______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/