[Pacemaker] colocation and ordering

[Andrew Beekhof]

On 26 Jun 2014, at 11:27 pm, Xzarth <xzarth at gmail.com> wrote:

> I have a pacemaker cluster with following config:
> 
>    crm(live)configure# show
>    node node1
>    node node2
>    primitive ClusterIP ocf:heartbeat:IPaddr2 \
>            params ip="192.168.56.111" cidr_netmask="32" nic="eth1"
>    iflabel="1" \
>            op monitor interval="30s"
>    primitive apache2 lsb:apache2 \
>            meta priority="1000" failure-timeout="60s"
>    migration-threshold="3" \
>            op start interval="0" timeout="20s" \
>            op stop interval="0" timeout="20s" \
>            op monitor interval="1s" timeout="20s" start-delay="10"
>    primitive drbd ocf:linbit:drbd \
>            params drbd_resource="r0" \
>            op monitor interval="29s" role="Master" \
>            op monitor interval="31s" role="Slave"
>    primitive fs_drbd ocf:heartbeat:Filesystem \
>            params device="/dev/drbd0" directory="/mnt/drbd0"
>    fstype="ext3" \
>            meta failure-timeout="60s"
>    primitive sym_apache2 ocf:heartbeat:symlink \
>            params target="/mnt/drbd0/var/www" link="/var/www"
>    backup_suffix=".crm"
>    group services sym_apache2 apache2 \
>            meta migration-threshold="1"
>    ms ms_drbd drbd \
>            meta master-max="1" master-node-max="1" clone-max="2"
>    clone-node-max="1" notify="true"
>    colocation fs_colocation inf: ms_drbd:Master fs_drbd
>    colocation ip_loc inf: fs_drbd ClusterIP
>    colocation service_loc inf: ClusterIP services
>    order fs_order inf: ms_drbd:promote fs_drbd:start
>    order ip_ord inf: fs_drbd:start ClusterIP:start
>    order service_ord inf: ClusterIP:start services:start
>    property $id="cib-bootstrap-options" \
>            dc-version="1.1.10-42f2063" \
>            cluster-infrastructure="classic openais (with plugin)" \
>            no-quorum-policy="ignore" \
>            stonith-enabled="false" \
>            stonith-action="poweroff" \
>            expected-quorum-votes="2" \
>            last-lrm-refresh="1403783847"
> 
> This cluster works as expected. If apache fails, everything is migrated
> to another node. But i would expect the colocation statements to be
> different. As far as i understand "colocation loc inf: X Y" puts Y
> somewhere then puts X in the same place.

You missed an important word: "decides"
We _decide_ where to put Y and then put X in the same place.

Y isn't running there when we decide where to put X.

step 1 - decide where everything should live
step 2 - figure out how to get things from where they are to where they should be
step 3 - do it

As for why "X with Y" works when "Y with X" doesn't, its to do with how the algorithm processes the hints.
Unfortunately its not as smart as you or I, and it can end up choosing a node on which Y can't run depending on what other constraints affect X and/or Y.

> And "order ord inf: X Y" starts
> X and then Y. So when i have both i would expect them to look like this:
> colocation loc inf: Y X

The start order and placement order don't have to be connected.
The best practice is to do "${least_important} with ${most_important}"

> order ord inf: X Y
> So start X and then Y, and put X somewhere and then Y on the same node.
> 
> But in my config it's clearly the oposite of that:
> colocation fs_colocation inf: ms_drbd:Master fs_drbd
> order fs_order inf: ms_drbd:promote fs_drbd:start
> So promote drbd then start fs, and promote master where fs is (which
> makes no sense to me).
> 
> I can reverse the colocation and do:
> colocation fs_colocation inf: fs_drbd ms_drbd:Master
> colocation ip_loc inf: ClusterIP fs_drbd
> colocation service_loc inf: services ClusterIP
> 
> But then when apache fails on one node it's just stopped and nothing
> else happens.
> 
> What part of ordering and colocation do i have wrong?
> 
> _______________________________________________
> Pacemaker mailing list: Pacemaker at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20140627/85570993/attachment-0003.sig>