<br><br>On Monday, January 29, 2024, Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>> wrote:<br>> On Mon, 2024-01-29 at 18:05 +0000, Faaland, Olaf P. via Users wrote:<br>>> Hi,<br>>><br>>> I have configured clusters of node pairs, so each cluster has 2<br>>> nodes.  The cluster members are statically defined in corosync.conf<br>>> before corosync or pacemaker is started, and quorum {two_node: 1} is<br>>> set.<br>>><br>>> When both nodes are powered off and I power them on, they do not<br>>> start pacemaker at exactly the same time.  The time difference may be<br>>> a few minutes depending on other factors outside the nodes.<br>>><br>>> My goals are (I call the first node to start pacemaker "node1"):<br>>> 1) I want to control how long pacemaker on node1 waits before fencing<br>>> node2 if node2 does not start pacemaker.<br>>> 2) If node1 is part-way through that waiting period, and node2 starts<br>>> pacemaker so they detect each other, I would like them to proceed<br>>> immediately to probing resource state and starting resources which<br>>> are down, not wait until the end of that "grace period".<br>>><br>>> It looks from the documentation like dc-deadtime is how #1 is<br>>> controlled, and #2 is expected normal behavior.  However, I'm seeing<br>>> fence actions before dc-deadtime has passed.<br>>><br>>> Am I misunderstanding Pacemaker's expected behavior and/or how dc-<br>>> deadtime should be used?<br>><br>> You have everything right. The problem is that you're starting with an<br>> empty configuration every time, so the default dc-deadtime is being<br>> used for the first election (before you can set the desired value).<br><br>Why would there be fence actions before dc-deadtime expires though?<br><br>><br>> I can't think of anything you can do to get around that, since the<br>> controller starts the timer as soon as it starts up. Would it be<br>> possible to bake an initial configuration into the PXE image?<br>><br>> When the timer value changes, we could stop the existing timer and<br>> restart it. There's a risk that some external automation could make<br>> repeated changes to the timeout, thus never letting it expire, but that<br>> seems preferable to your problem. I've created an issue for that:<br>><br>>   <a href="https://projects.clusterlabs.org/T764">https://projects.clusterlabs.org/T764</a><br>><br>> BTW there's also election-timeout. I'm not sure offhand how that<br>> interacts; it might be necessary to raise that one as well.<br>><br>>><br>>> One possibly unusual aspect of this cluster is that these two nodes<br>>> are stateless - they PXE boot from an image on another server - and I<br>>> build the cluster configuration at boot time with a series of pcs<br>>> commands, because the nodes have no local storage for this<br>>> purpose.  The commands are:<br>>><br>>> ['pcs', 'cluster', 'start']<br>>> ['pcs', 'property', 'set', 'stonith-action=off']<br>>> ['pcs', 'property', 'set', 'cluster-recheck-interval=60']<br>>> ['pcs', 'property', 'set', 'start-failure-is-fatal=false']<br>>> ['pcs', 'property', 'set', 'dc-deadtime=300']<br>>> ['pcs', 'stonith', 'create', 'fence_gopher11', 'fence_powerman',<br>>> 'ip=192.168.64.65', 'pcmk_host_check=static-list',<br>>> 'pcmk_host_list=gopher11,gopher12']<br>>> ['pcs', 'stonith', 'create', 'fence_gopher12', 'fence_powerman',<br>>> 'ip=192.168.64.65', 'pcmk_host_check=static-list',<br>>> 'pcmk_host_list=gopher11,gopher12']<br>>> ['pcs', 'resource', 'create', 'gopher11_zpool', 'ocf:llnl:zpool',<br>>> 'import_options="-f -N -d /dev/disk/by-vdev"', 'pool=gopher11', 'op',<br>>> 'start', 'timeout=805']<br>>> ...<br>>> ['pcs', 'property', 'set', 'no-quorum-policy=ignore']<br>><br>> BTW you don't need to change no-quorum-policy when you're using<br>> two_node with Corosync.<br>><br>>><br>>> I could, instead, generate a CIB so that when Pacemaker is started,<br>>> it has a full config.  Is that better?<br>>><br>>> thanks,<br>>> Olaf<br>>><br>>> === corosync.conf:<br>>> totem {<br>>>     version: 2<br>>>     cluster_name: gopher11<br>>>     secauth: off<br>>>     transport: udpu<br>>> }<br>>> nodelist {<br>>>     node {<br>>>         ring0_addr: gopher11<br>>>         name: gopher11<br>>>         nodeid: 1<br>>>     }<br>>>     node {<br>>>         ring0_addr: gopher12<br>>>         name: gopher12<br>>>         nodeid: 2<br>>>     }<br>>> }<br>>> quorum {<br>>>     provider: corosync_votequorum<br>>>     two_node: 1<br>>> }<br>>><br>>> === Log excerpt<br>>><br>>> Here's an except from Pacemaker logs that reflect what I'm<br>>> seeing.  These are from gopher12, the node that came up first.  The<br>>> other node, which is not yet up, is gopher11.<br>>><br>>> Jan 25 17:55:38 gopher12 pacemakerd          [116033]<br>>> (main)    notice: Starting Pacemaker 2.1.7-1.t4 | build=2.1.7<br>>> features:agent-manpages ascii-docs compat-2.0 corosync-ge-2 default-<br>>> concurrent-fencing generated-manpages monotonic nagios ncurses remote<br>>> systemd<br>>> Jan 25 17:55:39 gopher12 pacemaker-controld  [116040]<br>>> (peer_update_callback)    info: Cluster node gopher12 is now member<br>>> (was in unknown state)<br>>> Jan 25 17:55:43 gopher12 pacemaker-based     [116035]<br>>> (cib_perform_op)  info: ++<br>>> /cib/configuration/crm_config/cluster_property_set[@id='cib-<br>>> bootstrap-options']:  <nvpair id="cib-bootstrap-options-dc-deadtime"<br>>> name="dc-deadtime" value="300"/><br>>> Jan 25 17:56:00 gopher12 pacemaker-controld  [116040]<br>>> (crm_timer_popped)        info: Election Trigger just popped |<br>>> input=I_DC_TIMEOUT time=300000ms<br>>> Jan 25 17:56:01 gopher12 pacemaker-based     [116035]<br>>> (cib_perform_op)  info: ++<br>>> /cib/configuration/crm_config/cluster_property_set[@id='cib-<br>>> bootstrap-options']:  <nvpair id="cib-bootstrap-options-no-quorum-<br>>> policy" name="no-quorum-policy" value="ignore"/><br>>> Jan 25 17:56:01 gopher12 pacemaker-controld  [116040]<br>>> (abort_transition_graph)  info: Transition 0 aborted by cib-<br>>> bootstrap-options-no-quorum-policy doing create no-quorum-<br>>> policy=ignore: Configuration change | cib=0.26.0<br>>> source=te_update_diff_v2:464<br>>> path=/cib/configuration/crm_config/cluster_property_set[@id='cib-<br>>> bootstrap-options'] complete=true<br>>> Jan 25 17:56:01 gopher12 pacemaker-controld  [116040]<br>>> (controld_execute_fence_action)   notice: Requesting fencing (off)<br>>> targeting node gopher11 | action=11 timeout=60<br>>><br>>><br>>> _______________________________________________<br>>> Manage your subscription:<br>>> <a href="https://lists.clusterlabs.org/mailman/listinfo/users">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>>><br>>> ClusterLabs home: <a href="https://www.clusterlabs.org/">https://www.clusterlabs.org/</a><br>>><br>> --<br>> Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>><br>><br>> _______________________________________________<br>> Manage your subscription:<br>> <a href="https://lists.clusterlabs.org/mailman/listinfo/users">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>><br>> ClusterLabs home: <a href="https://www.clusterlabs.org/">https://www.clusterlabs.org/</a><br>><br>><br><br>-- <br><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div>Regards,<br><br></div>Reid Wahl (He/Him)<br></div><div>Senior Software Engineer, Red Hat<br></div>RHEL High Availability - Pacemaker<br></div></div></div></div></div></div></div></div></div></div></div></div></div><br>