Ah, it's a HANA.<div><br></div><div>Last HANA I did had something like this:</div><div><br></div><div>colocation constraint-> VIP with Master HANA</div><div>order constraint -> First HANA clone (don't specify master role) -> then IP</div><div><br></div><div>That way ,when the standby HANA joins and the master is demoted (kind of challanged) and afterwards samo old primary is promoted back, the IP never disappeared while it always started on the correct side (where the master is).</div><div><br></div><div><br></div><div>Best Regards,</div><div>Strahil Nikolov</div><div> <br> <blockquote style="margin: 0 0 20px 0;"> <div style="font-family:Roboto, sans-serif; color:#6D00F6;"> <div>On Fri, Feb 11, 2022 at 10:38, Jonno</div><div><jstk888@gmail.com> wrote:</div> </div> <div style="padding: 10px 0 0 20px; margin: 10px 0 0 0; border-left: 1px solid #6D00F6;"> <div id="yiv6960727488"><div><div dir="ltr">Hello all,<div><br clear="none"></div><div>Thank you for your assistance.</div><div><br clear="none"></div><div>Below is the config from my lab environment. By the way, I just tried Strahil's suggestions, but it didn't seem to have any effect on the behaviour.</div><div><br clear="none"></div><div>Regards,</div><div>Jonathan</div><div><br clear="none"></div><div>node 1: senzhana3 \<br clear="none"> attributes hana_abc_op_mode=logreplay hana_abc_vhost=senzhana3 hana_abc_site=SITEA hana_abc_srmode=sync lpa_abc_lpt=10 hana_abc_remoteHost=senzhana4<br clear="none">node 2: senzhana4 \<br clear="none"> attributes lpa_abc_lpt=1644568482 hana_abc_op_mode=logreplay hana_abc_vhost=senzhana4 hana_abc_site=SITEB hana_abc_srmode=sync hana_abc_remoteHost=senzhana3<br clear="none">primitive rsc_SAPHanaTopology_ABC_HDB96 ocf:suse:SAPHanaTopology \<br clear="none"> operations $id=rsc_sap2_ABC_HDB96-operations \<br clear="none"> op monitor interval=10 timeout=600 \<br clear="none"> op start interval=0 timeout=600 \<br clear="none"> op stop interval=0 timeout=300 \<br clear="none"> params SID=ABC InstanceNumber=96<br clear="none">primitive rsc_SAPHana_ABC_HDB96 ocf:suse:SAPHana \<br clear="none"> operations $id=rsc_sap_ABC_HDB96-operations \<br clear="none"> op start interval=0 timeout=3600 \<br clear="none"> op stop interval=0 timeout=3600 \<br clear="none"> op promote interval=0 timeout=3600 \<br clear="none"> op monitor interval=60 role=Master timeout=700 \<br clear="none"> op monitor interval=61 role=Slave timeout=700 \<br clear="none"> params SID=ABC InstanceNumber=96 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=false<br clear="none">primitive rsc_hsr_quiesce lsb:hsr_quiesce<br clear="none">primitive rsc_hsr_resume lsb:hsr_resume<br clear="none">primitive rsc_ip_ABC_HDB96 IPaddr2 \<br clear="none"> operations $id=rsc_ip_ABC_HDB96-operations \<br clear="none"> op monitor interval=10s timeout=20s \<br clear="none"> params ip=192.168.178.166<br clear="none">primitive stonith-sbd stonith:external/sbd \<br clear="none"> params pcmk_delay_max=30 \<br clear="none"> meta target-role=Started<br clear="none">ms msl_SAPHana_ABC_HDB96 rsc_SAPHana_ABC_HDB96 \<br clear="none"> meta clone-max=2 clone-node-max=1 interleave=true target-role=Master<br clear="none">clone cln_SAPHanaTopology_ABC_HDB96 rsc_SAPHanaTopology_ABC_HDB96 \<br clear="none"> meta clone-node-max=1 interleave=true<br clear="none">location cli-prefer-rsc_hsr_quiesce rsc_hsr_quiesce role=Started inf: senzhana3<br clear="none">location cli-prefer-rsc_ip_ABC_HDB96 rsc_ip_ABC_HDB96 role=Started inf: senzhana4<br clear="none">colocation col_saphana_ip_ABC_HDB96 2000: rsc_ip_ABC_HDB96:Started msl_SAPHana_ABC_HDB96:Master rsc_hsr_quiesce rsc_hsr_resume<br clear="none">order ord_SAPHana_ABC_HDB96 Optional: cln_SAPHanaTopology_ABC_HDB96 msl_SAPHana_ABC_HDB96<br clear="none">order ord_failover_ABC_HDB96 rsc_hsr_quiesce rsc_ip_ABC_HDB96 msl_SAPHana_ABC_HDB96:promote rsc_hsr_resume<br clear="none">property cib-bootstrap-options: \<br clear="none"> have-watchdog=true \<br clear="none"> dc-version="2.0.4+20200616.2deceaa3a-3.12.1-2.0.4+20200616.2deceaa3a" \<br clear="none"> cluster-infrastructure=corosync \<br clear="none"> cluster-name=hacluster \<br clear="none"> stonith-enabled=true \<br clear="none"> stonith-action=reboot \<br clear="none"> stonith-timeout=150s \<br clear="none"> last-lrm-refresh=1644567089<br clear="none">rsc_defaults rsc-options: \<br clear="none"> resource-stickiness=1000 \<br clear="none"> migration-threshold=5000<br clear="none">op_defaults op-options: \<br clear="none"> timeout=600 \<br clear="none"> record-pending=true \<br clear="none"></div><div> no-quorum-policy=ignore<br clear="none"></div></div><br clear="none"><div class="yiv6960727488gmail_quote"><div id="yiv6960727488yqt91308" class="yiv6960727488yqt6414830366"><div dir="ltr" class="yiv6960727488gmail_attr">On Fri, 11 Feb 2022 at 21:29, Klaus Wenninger <<a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:kwenning@redhat.com" target="_blank" href="mailto:kwenning@redhat.com">kwenning@redhat.com</a>> wrote:<br clear="none"></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;" class="yiv6960727488gmail_quote"><div dir="ltr"><div dir="ltr"><br clear="none"></div><br clear="none"><div class="yiv6960727488gmail_quote"><div dir="ltr" class="yiv6960727488gmail_attr">On Fri, Feb 11, 2022 at 9:13 AM Strahil Nikolov via Users <<a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:users@clusterlabs.org" target="_blank" href="mailto:users@clusterlabs.org">users@clusterlabs.org</a>> wrote:<br clear="none"></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;" class="yiv6960727488gmail_quote">Shouldn't you use kind ' Mandatory' and simetrical TRUE ?<div><br clear="none"></div><div>If true, the reverse of the constraint applies for the opposite action (for example, if B starts after A starts, then B stops before A stops). </div></blockquote><div>If the script should be run before any change then it sounds as if an asymmetric order would be desirable.</div><div>So you might create at least two order constraints explicitly listing the actions.</div><div>But I doubt that this explains the unexpected behavior described.</div><div>As Ulrich said a little bit more info about the config would be helpful.</div><div><br clear="none"></div><div>Regards,</div><div>Klaus </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;" class="yiv6960727488gmail_quote"><div><br clear="none"></div><div>Best Regards,</div><div>Strahil Nikolov<br clear="none"> <br clear="none"> <blockquote style="margin:0px 0px 20px;"> <div style="font-family:Roboto, sans-serif;color:rgb(109,0,246);"> <div>On Fri, Feb 11, 2022 at 9:11, Ulrich Windl</div><div><<a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:Ulrich.Windl@rz.uni-regensburg.de" target="_blank" href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-regensburg.de</a>> wrote:</div> </div> <div style="padding:10px 0px 0px 20px;margin:10px 0px 0px;border-left:1px solid rgb(109,0,246);"> >>> Jonno <<a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:jstk888@gmail.com" target="_blank" href="mailto:jstk888@gmail.com">jstk888@gmail.com</a>> schrieb am 10.02.2022 um 20:43 in Nachricht<br clear="none"><CADGLmTe311U71NKSEBoeogkk+WcCHpt44MH1T-4hy-=<a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:J-NL8Tw@mail.gmail.com" target="_blank" href="mailto:J-NL8Tw@mail.gmail.com">J-NL8Tw@mail.gmail.com</a>>:<br clear="none">> Hello,<br clear="none">> <br clear="none">> I am having some trouble getting my 2 node active/passive cluster to do<br clear="none">> what I want. More specifically, my cluster is removing the VIP from the<br clear="none">> cluster whenever I attempt a failover with a command such as "crm resource<br clear="none">> move rsc_cluster_vip node2".<br clear="none">> <br clear="none">> When running the command above, I am asking the cluster to migrate the VIP<br clear="none">> to the standby node, but I am expecting the cluster to honour the order<br clear="none">> constraint, by first running the script resource named "rsc_lsb_quiesce".<br clear="none">> The order constraint looks like:<br clear="none">> <br clear="none">> "order order_ABC rsc_lsb_quiesce rsc_cluster_vip msl_ABC:promote<br clear="none">> rsc_lsb_resume"<br clear="none">> <br clear="none">> But it doesn't seem to do what I expect. It always removes the VIP entirely<br clear="none">> from the cluster first, then it starts to follow the order constraint. This<br clear="none">> means my cluster is in a state where the VIP is completely gone for a<br clear="none">> couple of minutes. I've also tried doing a "crm resource move <br clear="none">> rsc_lsb_quiesce<br clear="none">> node2" hoping to trigger the script resource first, but the cluster always<br clear="none">> removes the VIP before doing anything.<br clear="none">> <br clear="none">> My question is: How can I make the cluster follow this order constraint? I<br clear="none"><br clear="none">I'm very sure you just made a configuration mistake.<br clear="none">But nobody can help you unless you show your configuration and example execution of events, plus the expected order of execution.<br clear="none"><br clear="none">Regards,<br clear="none">Ulrich<div id="yiv6960727488gmail-m_9154264649476211921gmail-m_862185805832560133yqtfd57036"><br clear="none"><br clear="none">> need the cluster to run the "rsc_lsb_quiesce" script against a remote<br clear="none">> application server before any other action is taken. I especially need the<br clear="none">> VIP to stay where it is. Should I be doing this another way?<br clear="none">> <br clear="none">> Regards,<br clear="none">> Jonathan<br clear="none"><br clear="none"><br clear="none"><br clear="none"><br clear="none">_______________________________________________<br clear="none">Manage your subscription:<br clear="none"><a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="https://lists.clusterlabs.org/mailman/listinfo/users">https://lists.clusterlabs.org/mailman/listinfo/users</a><br clear="none"><br clear="none">ClusterLabs home: <a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="https://www.clusterlabs.org/">https://www.clusterlabs.org/</a><br clear="none"></div> </div> </blockquote></div>_______________________________________________<br clear="none">
Manage your subscription:<br clear="none">
<a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="https://lists.clusterlabs.org/mailman/listinfo/users">https://lists.clusterlabs.org/mailman/listinfo/users</a><br clear="none">
<br clear="none">
ClusterLabs home: <a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="https://www.clusterlabs.org/">https://www.clusterlabs.org/</a><br clear="none">
</blockquote></div></div>
_______________________________________________<br clear="none">
Manage your subscription:<br clear="none">
<a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="https://lists.clusterlabs.org/mailman/listinfo/users">https://lists.clusterlabs.org/mailman/listinfo/users</a><br clear="none">
<br clear="none">
ClusterLabs home: <a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="https://www.clusterlabs.org/">https://www.clusterlabs.org/</a><br clear="none">
</blockquote></div></div>
</div></div> </div> </blockquote></div>