<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 9, 2017 at 6:55 PM, Andrew Beekhof <span dir="ltr">&lt;<a href="mailto:abeekhof@redhat.com" target="_blank">abeekhof@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Dec 16, 2016 at 8:52 AM, Chris Walker<br>
&lt;<a href="mailto:christopher.walker@gmail.com">christopher.walker@gmail.com</a>&gt; wrote:<br>
&gt; Thanks for your response Ken.  I&#39;m puzzled ... in my case node remain<br>
&gt; UNCLEAN (offline) until dc-deadtime expires, even when both nodes are up and<br>
&gt; corosync is quorate.<br>
<br>
</span>I&#39;m guessing you&#39;re starting both nodes at the same time?<br></blockquote><div><br></div><div>The nodes power on at the same time, but hardware discovery can vary by minutes.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The behaviour you&#39;re seeing is arguably a hangover from the multicast<br>
days (in which case corosync wouldn&#39;t have had a node list).<br></blockquote><div><br></div><div>That makes sense. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But since that&#39;s not the common case anymore, we could probably<br>
shortcut the timeout if we know the complete node list and see that<br>
they are all online.<br></blockquote><div><br></div><div>That would be ideal.  It&#39;s easy enough to work around this in systemd, but it seems like the HA stack should be the authority on node status.</div><div><br></div><div>Thanks!</div><div>Chris</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
&gt;<br>
&gt; I see the following from crmd when I have dc-deadtime=2min<br>
&gt;<br>
&gt; Dec 15 21:34:33 max04 crmd[13791]:   notice: Quorum acquired<br>
&gt; Dec 15 21:34:33 max04 crmd[13791]:   notice: pcmk_quorum_notification: Node<br>
&gt; max04[2886730248] - state is now member (was (null))<br>
&gt; Dec 15 21:34:33 max04 crmd[13791]:   notice: pcmk_quorum_notification: Node<br>
&gt; (null)[2886730249] - state is now member (was (null))<br>
&gt; Dec 15 21:34:33 max04 crmd[13791]:   notice: Notifications disabled<br>
&gt; Dec 15 21:34:33 max04 crmd[13791]:   notice: The local CRM is operational<br>
&gt; Dec 15 21:34:33 max04 crmd[13791]:   notice: State transition S_STARTING -&gt;<br>
&gt; S_PENDING [ input=I_PENDING cause=C_FSA_INTERNAL origin=do_started ]<br>
&gt; ...<br>
&gt; Dec 15 21:36:33 max05 crmd[10365]:  warning: FSA: Input I_DC_TIMEOUT from<br>
&gt; crm_timer_popped() received in state S_PENDING<br>
&gt; Dec 15 21:36:33 max05 crmd[10365]:   notice: State transition S_ELECTION -&gt;<br>
&gt; S_INTEGRATION [ input=I_ELECTION_DC cause=C_TIMER_POPPED<br>
&gt; origin=election_timeout_popped ]<br>
&gt; Dec 15 21:36:33 max05 crmd[10365]:  warning: FSA: Input I_ELECTION_DC from<br>
&gt; do_election_check() received in state S_INTEGRATION<br>
&gt; Dec 15 21:36:33 max05 crmd[10365]:   notice: Notifications disabled<br>
&gt; Dec 15 21:36:33 max04 crmd[13791]:   notice: State transition S_PENDING -&gt;<br>
&gt; S_NOT_DC [ input=I_NOT_DC cause=C_HA_MESSAGE<br>
&gt; origin=do_cl_join_finalize_<wbr>respond ]<br>
&gt;<br>
&gt; only after this do the nodes transition to Online.  This is using the<br>
&gt; vanilla RHEL7.2 cluster stack and the following options:<br>
&gt;<br>
&gt; property cib-bootstrap-options: \<br>
&gt;         no-quorum-policy=ignore \<br>
&gt;         default-action-timeout=120s \<br>
&gt;         pe-warn-series-max=1500 \<br>
&gt;         pe-input-series-max=1500 \<br>
&gt;         pe-error-series-max=1500 \<br>
&gt;         stonith-action=poweroff \<br>
&gt;         stonith-timeout=900 \<br>
&gt;         dc-deadtime=2min \<br>
&gt;         maintenance-mode=false \<br>
&gt;         have-watchdog=false \<br>
&gt;         dc-version=1.1.13-10.el7-<wbr>44eb2dd \<br>
&gt;         cluster-infrastructure=<wbr>corosync<br>
&gt;<br>
&gt; Thanks again,<br>
&gt; Chris<br>
&gt;<br>
&gt; On Thu, Dec 15, 2016 at 3:26 PM, Ken Gaillot &lt;<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On 12/15/2016 02:00 PM, Chris Walker wrote:<br>
&gt;&gt; &gt; Hello,<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I have a quick question about dc-deadtime.  I believe that Digimer and<br>
&gt;&gt; &gt; others on this list might have already addressed this, but I want to<br>
&gt;&gt; &gt; make sure I&#39;m not missing something.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; If my understanding is correct, dc-deadtime sets the amount of time that<br>
&gt;&gt; &gt; must elapse before a cluster is formed (DC is elected, etc), regardless<br>
&gt;&gt; &gt; of which nodes have joined the cluster.  In other words, even if all<br>
&gt;&gt; &gt; nodes that are explicitly enumerated in the nodelist section have<br>
&gt;&gt; &gt; started Pacemaker, they will still wait dc-deadtime before forming a<br>
&gt;&gt; &gt; cluster.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; In my case, I have a two-node cluster on which I&#39;d like to allow a<br>
&gt;&gt; &gt; pretty long time (~5 minutes) for both nodes to join before giving up on<br>
&gt;&gt; &gt; them.  However, if they both join quickly, I&#39;d like to proceed to form a<br>
&gt;&gt; &gt; cluster immediately; I don&#39;t want to wait for the full five minutes to<br>
&gt;&gt; &gt; elapse before forming a cluster.  Further, if a node doesn&#39;t respond<br>
&gt;&gt; &gt; within five minutes, I want to fence it and start resources on the node<br>
&gt;&gt; &gt; that is up.<br>
&gt;&gt;<br>
&gt;&gt; Pacemaker+corosync behaves as you describe by default.<br>
&gt;&gt;<br>
&gt;&gt; dc-deadtime is how long to wait for an election to finish, but if the<br>
&gt;&gt; election finishes sooner than that (i.e. a DC is elected), it stops<br>
&gt;&gt; waiting. It doesn&#39;t even wait for all nodes, just a quorum.<br>
&gt;&gt;<br>
&gt;&gt; Also, with startup-fencing=true (the default), any unseen nodes will be<br>
&gt;&gt; fenced, and the remaining nodes will proceed to host resources. Of<br>
&gt;&gt; course, it needs quorum for this, too.<br>
&gt;&gt;<br>
&gt;&gt; With two nodes, quorum is handled specially, but that&#39;s a different topic.<br>
&gt;&gt;<br>
&gt;&gt; &gt; With Pacemaker/Heartbeat, the initdead parameter did exactly what I<br>
&gt;&gt; &gt; want, but I don&#39;t see any way to do this with Pacemaker/Corosync.  From<br>
&gt;&gt; &gt; reading other posts, it looks like people use an external agent to start<br>
&gt;&gt; &gt; HA daemons once nodes are up ... is this a correct understanding?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thanks very much,<br>
&gt;&gt; &gt; Chris<br>
&gt;&gt;<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
&gt;&gt; <a href="http://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.clusterlabs.org/<wbr>mailman/listinfo/users</a><br>
&gt;&gt;<br>
&gt;&gt; Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
&gt;&gt; Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/<wbr>doc/Cluster_from_Scratch.pdf</a><br>
&gt;&gt; Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
&gt; <a href="http://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.clusterlabs.org/<wbr>mailman/listinfo/users</a><br>
&gt;<br>
&gt; Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
&gt; Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/<wbr>doc/Cluster_from_Scratch.pdf</a><br>
&gt; Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
&gt;<br>
<br>
______________________________<wbr>_________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
<a href="http://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.clusterlabs.org/<wbr>mailman/listinfo/users</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/<wbr>doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
</div></div></blockquote></div><br></div></div>