<div><span style="font-family: 'lucida Grande', Verdana, 'Microsoft YaHei'; line-height: 23px;">Corosync+Pacemaker error during failover</span></div><div><div><br></div><div><br></div><div style="font-size: 12px;font-family: Arial Narrow;padding:2px 0 2px 0;">------------------&nbsp;Original&nbsp;------------------</div><div style="font-size: 12px;background:#efefef;padding:8px;"><div><b>From: </b>&nbsp;"users-request";&lt;users-request@clusterlabs.org&gt;;</div><div><b>Date: </b>&nbsp;Fri, Oct 9, 2015 02:50 AM</div><div><b>To: </b>&nbsp;"users"&lt;users@clusterlabs.org&gt;; <wbr></div><div></div><div><b>Subject: </b>&nbsp;Users Digest, Vol 9, Issue 21</div></div><div><br></div>Send Users mailing list submissions to<br>        users@clusterlabs.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br>        http://clusterlabs.org/mailman/listinfo/users<br>or, via email, send a message with subject or body 'help' to<br>        users-request@clusterlabs.org<br><br>You can reach the person managing the list at<br>        users-owner@clusterlabs.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Users digest..."<br><br><br>Today's Topics:<br><br>&nbsp;&nbsp; 1. Re: Current DC becomes None suddenly (Ken Gaillot)<br>&nbsp;&nbsp; 2. Re: Corosync+Pacemaker error during failover (emmanuel segura)<br>&nbsp;&nbsp; 3. Re: Corosync+Pacemaker error during failover (Digimer)<br>&nbsp;&nbsp; 4. Re: Corosync+Pacemaker error during failover (Ken Gaillot)<br>&nbsp;&nbsp; 5. Re: Xen Migration/resource cleanup problem in SLES11        SP3<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (Cleber Paiva de Souza)<br>&nbsp;&nbsp; 6. Re: gfs2 crashes when i, e.g., dd to a lvm volume (J. Echter)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Thu, 8 Oct 2015 10:21:50 -0500<br>From: Ken Gaillot &lt;kgaillot@redhat.com&gt;<br>To: Pritam Kharat &lt;pritam.kharat@oneconvergence.com&gt;,        Cluster Labs -<br>        All topics related to open-source clustering welcomed<br>        &lt;users@clusterlabs.org&gt;<br>Subject: Re: [ClusterLabs] Current DC becomes None suddenly<br>Message-ID: &lt;56168A0E.40405@redhat.com&gt;<br>Content-Type: text/plain; charset=utf-8<br><br>On 10/08/2015 09:55 AM, Pritam Kharat wrote:<br>&gt; Hi Ken,<br>&gt; <br>&gt; Thanks for reply.<br>&gt; <br>&gt; On Thu, Oct 8, 2015 at 8:13 PM, Ken Gaillot &lt;kgaillot@redhat.com&gt; wrote:<br>&gt; <br>&gt;&gt; On 10/02/2015 01:47 PM, Pritam Kharat wrote:<br>&gt;&gt;&gt; Hi,<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; I have set up a ACTIVE/PASSIVE HA<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; *Issue 1) *<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; *corosync.conf*&nbsp; file is<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; # Please read the openais.conf.5 manual page<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; totem {<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; version: 2<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # How long before declaring a token lost (ms)<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; token: 10000<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # How many token retransmits before forming a new configuration<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; token_retransmits_before_loss_const: 20<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # How long to wait for join messages in the membership protocol<br>&gt;&gt; (ms)<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; join: 10000<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # How long to wait for consensus to be achieved before starting a<br>&gt;&gt;&gt; new round of membership configuration (ms)<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; consensus: 12000<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # Turn off the virtual synchrony filter<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; vsftype: none<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # Number of messages that may be sent by one processor on receipt<br>&gt;&gt;&gt; of the token<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; max_messages: 20<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # Limit generated nodeids to 31-bits (positive signed integers)<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clear_node_high_bit: yes<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # Disable encryption<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; secauth: off<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # How many threads to use for encryption/decryption<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; threads: 0<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # Optionally assign a fixed node id (integer)<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # nodeid: 1234<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # This specifies the mode of redundant ring, which may be none,<br>&gt;&gt;&gt; active, or passive.<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rrp_mode: none<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; interface {<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # The following values need to be set based on your<br>&gt;&gt;&gt; environment<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ringnumber: 0<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bindnetaddr: 192.168.101.0<br>&gt;&gt;&gt; mcastport: 5405<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; transport: udpu<br>&gt;&gt;&gt; }<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; amf {<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mode: disabled<br>&gt;&gt;&gt; }<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; quorum {<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # Quorum for the Pacemaker Cluster Resource Manager<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; provider: corosync_votequorum<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; expected_votes: 1<br>&gt;&gt;<br>&gt;&gt; If you're using a recent version of corosync, use "two_node: 1" instead<br>&gt;&gt; of "expected_votes: 1", and get rid of "no-quorum-policy: ignore" in the<br>&gt;&gt; pacemaker cluster options.<br>&gt;&gt;<br>&gt;&gt;&nbsp;&nbsp;&nbsp; -&gt; We are using corosync version 2.3.3. Do we above mentioned change<br>&gt; for this version ?<br><br>Yes, you can use two_node.<br><br>FYI, two_node automatically enables wait_for_all, which means that when<br>a node first starts up, it waits until it can see the other node before<br>forming the cluster. So once the cluster is running, it can handle the<br>failure of one node, and the other will continue. But to start, both<br>nodes needs to be present.<br><br>&gt;&gt;&gt; }<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; nodelist {<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; node {<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ring0_addr: 192.168.101.73<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; node {<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ring0_addr: 192.168.101.74<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>&gt;&gt;&gt; }<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; aisexec {<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; user:&nbsp;&nbsp; root<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; group:&nbsp; root<br>&gt;&gt;&gt; }<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; logging {<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fileline: off<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to_stderr: yes<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to_logfile: yes<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to_syslog: yes<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; syslog_facility: daemon<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; logfile: /var/log/corosync/corosync.log<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; debug: off<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; timestamp: on<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; logger_subsys {<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; subsys: AMF<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; debug: off<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tags: enter|leave|trace1|trace2|trace3|trace4|trace6<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>&gt;&gt;&gt; }<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; And I have added 5 resources - 1 is VIP and 4 are upstart jobs<br>&gt;&gt;&gt; Node names are configured as -&gt; sc-node-1(ACTIVE) and sc-node-2(PASSIVE)<br>&gt;&gt;&gt; Resources are running on ACTIVE node<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Default cluster properties -<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;cluster_property_set id="cib-bootstrap-options"&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;nvpair id="cib-bootstrap-options-dc-version" name="dc-version"<br>&gt;&gt;&gt; value="1.1.10-42f2063"/&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;nvpair id="cib-bootstrap-options-cluster-infrastructure"<br>&gt;&gt;&gt; name="cluster-infrastructure" value="corosync"/&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;nvpair name="no-quorum-policy" value="ignore"<br>&gt;&gt;&gt; id="cib-bootstrap-options-no-quorum-policy"/&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;nvpair name="stonith-enabled" value="false"<br>&gt;&gt;&gt; id="cib-bootstrap-options-stonith-enabled"/&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;nvpair name="cluster-recheck-interval" value="3min"<br>&gt;&gt;&gt; id="cib-bootstrap-options-cluster-recheck-interval"/&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;nvpair name="default-action-timeout" value="120s"<br>&gt;&gt;&gt; id="cib-bootstrap-options-default-action-timeout"/&gt;<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/cluster_property_set&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; But sometimes after 2-3 migrations from ACTIVE to STANDBY and then from<br>&gt;&gt;&gt; STANDBY to ACTIVE,<br>&gt;&gt;&gt; both nodes become OFFLINE and Current DC becomes None, I have disabled<br>&gt;&gt; the<br>&gt;&gt;&gt; stonith property and even quorum is ignored<br>&gt;&gt;<br>&gt;&gt; Disabling stonith isn't helping you. The cluster needs stonith to<br>&gt;&gt; recover from difficult situations, so it's easier to get into weird<br>&gt;&gt; states like this without it.<br>&gt;&gt;<br>&gt;&gt;&gt; root@sc-node-2:/usr/lib/python2.7/dist-packages/sc# crm status<br>&gt;&gt;&gt; Last updated: Sat Oct&nbsp; 3 00:01:40 2015<br>&gt;&gt;&gt; Last change: Fri Oct&nbsp; 2 23:38:28 2015 via crm_resource on sc-node-1<br>&gt;&gt;&gt; Stack: corosync<br>&gt;&gt;&gt; Current DC: NONE<br>&gt;&gt;&gt; 2 Nodes configured<br>&gt;&gt;&gt; 5 Resources configured<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; OFFLINE: [ sc-node-1 sc-node-2 ]<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; What is going wrong here ? What is the reason for node Current DC<br>&gt;&gt; becoming<br>&gt;&gt;&gt; None suddenly ? Is corosync.conf okay ? Are default cluster properties<br>&gt;&gt; fine<br>&gt;&gt;&gt; ? Help will be appreciated.<br>&gt;&gt;<br>&gt;&gt; I'd recommend seeing how the problem behaves with stonith enabled, but<br>&gt;&gt; in any case you'll need to dive into the logs to figure what starts the<br>&gt;&gt; chain of events.<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&nbsp;&nbsp;&nbsp; -&gt; We are seeing this issue when we try rebooting the vms<br><br>For VMs, fence_virtd/fence_xvm are relatively easy to set up for<br>stonith. I'd get that going first, then try to reproduce the problem,<br>and show the cluster logs from around the time the problem starts.<br><br>&gt;&gt;<br>&gt;&gt;&gt; *Issue 2)*<br>&gt;&gt;&gt; Command used to add upstart job is<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; crm configure primitive service upstart:service meta allow-migrate=true<br>&gt;&gt;&gt; migration-threshold=5 failure-timeout=30s op monitor interval=15s<br>&gt;&gt;&gt;&nbsp; timeout=60s<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; But still sometimes I see fail count going to INFINITY. Why ? How can we<br>&gt;&gt;&gt; avoid it ? Resource should have migrated as soon as it reaches migration<br>&gt;&gt;&gt; threshold.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; * Node sc-node-2:<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; service: migration-threshold=5 fail-count=1000000 last-failure='Fri<br>&gt;&gt; Oct<br>&gt;&gt;&gt;&nbsp; 2 23:38:53 2015'<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; service1: migration-threshold=5 fail-count=1000000 last-failure='Fri<br>&gt;&gt; Oct<br>&gt;&gt;&gt;&nbsp; 2 23:38:53 2015'<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Failed actions:<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; service_start_0 (node=sc-node-2, call=-1, rc=1, status=Timed Out,<br>&gt;&gt;&gt; last-rc-change=Fri Oct&nbsp; 2 23:38:53 2015<br>&gt;&gt;&gt; , queued=0ms, exec=0ms<br>&gt;&gt;&gt; ): unknown error<br>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; service1_start_0 (node=sc-node-2, call=-1, rc=1, status=Timed Out,<br>&gt;&gt;&gt; last-rc-change=Fri Oct&nbsp; 2 23:38:53 2015<br>&gt;&gt;&gt; , queued=0ms, exec=0ms<br>&gt;&gt;<br>&gt;&gt; migration-threshold is used for monitor failures, not (by default) start<br>&gt;&gt; or stop failures.<br>&gt;&gt;<br>&gt;&gt; This is a start failure, which (by default) makes the fail-count go to<br>&gt;&gt; infinity. The rationale is that a monitor failure indicates some sort of<br>&gt;&gt; temporary error, but failing to start could well mean that something is<br>&gt;&gt; wrong with the installation or configuration.<br>&gt;&gt;<br>&gt;&gt; You can tell the cluster to apply migration-threshold to start failures<br>&gt;&gt; too, by setting the start-failure-is-fatal=false cluster option.<br><br><br><br><br>------------------------------<br><br>Message: 2<br>Date: Thu, 8 Oct 2015 17:22:16 +0200<br>From: emmanuel segura &lt;emi2fast@gmail.com&gt;<br>To: Cluster Labs - All topics related to open-source clustering<br>        welcomed        &lt;users@clusterlabs.org&gt;<br>Subject: Re: [ClusterLabs] Corosync+Pacemaker error during failover<br>Message-ID:<br>        &lt;CAE7pJ3C5D8gd_mScQ18AgN_tZX9yML9p42P1OVjU_Uvd8JGSbw@mail.gmail.com&gt;<br>Content-Type: text/plain; charset=UTF-8<br><br>please check if you drbd is configured to call fence-handler<br>https://drbd.linbit.com/users-guide/s-pacemaker-fencing.html<br><br>2015-10-08 17:16 GMT+02:00 priyanka &lt;priyanka@cse.iitb.ac.in&gt;:<br>&gt; Hi,<br>&gt;<br>&gt; We are trying to build a HA setup for our servers using DRBD + Corosync +<br>&gt; pacemaker stack.<br>&gt;<br>&gt; Attached is the configuration file for corosync/pacemaker and drbd.<br>&gt;<br>&gt; We are getting errors while testing this setup.<br>&gt; 1. When we stop corosync on Master machine say server1(lock), it is<br>&gt; Stonith'ed. In this case slave-server2(sher) is promoted to master.<br>&gt;&nbsp;&nbsp;&nbsp; But when server1(lock) reboots res_exportfs_export1 is started on both<br>&gt; the servers and that resource goes into failed state followed by servers<br>&gt; going into unclean state.<br>&gt;&nbsp;&nbsp;&nbsp; Then server1(lock) reboots and server2(sher) is master but in unclean<br>&gt; state. After server1(lock) comes up, server2(sher) is stonith'ed and<br>&gt; server1(lock) is slave(the only online node).<br>&gt;&nbsp;&nbsp;&nbsp; When server2(sher) comes up, both the servers are slaves and resource<br>&gt; group(rg_export) is stopped. Then server2(sher) becomes Master and<br>&gt; server1(lock) is slave and resource group is started.<br>&gt;&nbsp;&nbsp;&nbsp; At this point configuration becomes stable.<br>&gt;<br>&gt;<br>&gt; PFA logs(syslog) of server2(sher) after it is promoted to master till it is<br>&gt; first rebooted when resource exportfs goes into failed state.<br>&gt;<br>&gt; Please let us know if the configuration is appropriate. From the logs we<br>&gt; could not figure out exact reason of resource failure.<br>&gt; Your comment on this scenario will be very helpful.<br>&gt;<br>&gt; Thanks,<br>&gt; Priyanka<br>&gt;<br>&gt;<br>&gt; _______________________________________________<br>&gt; Users mailing list: Users@clusterlabs.org<br>&gt; http://clusterlabs.org/mailman/listinfo/users<br>&gt;<br>&gt; Project Home: http://www.clusterlabs.org<br>&gt; Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf<br>&gt; Bugs: http://bugs.clusterlabs.org<br>&gt;<br><br><br><br>-- <br>&nbsp; .~.<br>&nbsp; /V\<br>&nbsp;//&nbsp; \\<br>/(&nbsp;&nbsp; )\<br>^`~'^<br><br><br><br>------------------------------<br><br>Message: 3<br>Date: Thu, 8 Oct 2015 11:35:02 -0400<br>From: Digimer &lt;lists@alteeve.ca&gt;<br>To: Cluster Labs - All topics related to open-source clustering<br>        welcomed        &lt;users@clusterlabs.org&gt;<br>Subject: Re: [ClusterLabs] Corosync+Pacemaker error during failover<br>Message-ID: &lt;56168D26.8090500@alteeve.ca&gt;<br>Content-Type: text/plain; charset=windows-1252<br><br>On 08/10/15 11:16 AM, priyanka wrote:<br>&gt;                 fencing resource-only;<br><br>This needs to be 'fencing resource-and-stonith;'.<br><br>-- <br>Digimer<br>Papers and Projects: https://alteeve.ca/w/<br>What if the cure for cancer is trapped in the mind of a person without<br>access to education?<br><br><br><br>------------------------------<br><br>Message: 4<br>Date: Thu, 8 Oct 2015 10:50:04 -0500<br>From: Ken Gaillot &lt;kgaillot@redhat.com&gt;<br>To: users@clusterlabs.org<br>Subject: Re: [ClusterLabs] Corosync+Pacemaker error during failover<br>Message-ID: &lt;561690AC.5030607@redhat.com&gt;<br>Content-Type: text/plain; charset=windows-1252<br><br>On 10/08/2015 10:16 AM, priyanka wrote:<br>&gt; Hi,<br>&gt; <br>&gt; We are trying to build a HA setup for our servers using DRBD + Corosync<br>&gt; + pacemaker stack.<br>&gt; <br>&gt; Attached is the configuration file for corosync/pacemaker and drbd.<br><br>A few things I noticed:<br><br>* Don't set become-primary-on in the DRBD configuration in a Pacemaker<br>cluster; Pacemaker should handle all promotions to primary.<br><br>* I'm no NFS expert, but why is res_exportfs_root cloned? Can both<br>servers export it at the same time? I would expect it to be in the group<br>before res_exportfs_export1.<br><br>* Your constraints need some adjustment. Partly it depends on the answer<br>to the previous question, but currently res_fs (via the group) is<br>ordered after res_exportfs_root, and I don't see how that could work.<br><br>&gt; We are getting errors while testing this setup.<br>&gt; 1. When we stop corosync on Master machine say server1(lock), it is<br>&gt; Stonith'ed. In this case slave-server2(sher) is promoted to master.<br>&gt;&nbsp;&nbsp;&nbsp; But when server1(lock) reboots res_exportfs_export1 is started on<br>&gt; both the servers and that resource goes into failed state followed by<br>&gt; servers going into unclean state.<br>&gt;&nbsp;&nbsp;&nbsp; Then server1(lock) reboots and server2(sher) is master but in unclean<br>&gt; state. After server1(lock) comes up, server2(sher) is stonith'ed and<br>&gt; server1(lock) is slave(the only online node).<br>&gt;&nbsp;&nbsp;&nbsp; When server2(sher) comes up, both the servers are slaves and resource<br>&gt; group(rg_export) is stopped. Then server2(sher) becomes Master and<br>&gt; server1(lock) is slave and resource group is started.<br>&gt;&nbsp;&nbsp;&nbsp; At this point configuration becomes stable.<br>&gt; <br>&gt; <br>&gt; PFA logs(syslog) of server2(sher) after it is promoted to master till it<br>&gt; is first rebooted when resource exportfs goes into failed state.<br>&gt; <br>&gt; Please let us know if the configuration is appropriate. From the logs we<br>&gt; could not figure out exact reason of resource failure.<br>&gt; Your comment on this scenario will be very helpful.<br>&gt; <br>&gt; Thanks,<br>&gt; Priyanka<br>&gt; <br>&gt; <br>&gt; <br>&gt; _______________________________________________<br>&gt; Users mailing list: Users@clusterlabs.org<br>&gt; http://clusterlabs.org/mailman/listinfo/users<br>&gt; <br>&gt; Project Home: http://www.clusterlabs.org<br>&gt; Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf<br>&gt; Bugs: http://bugs.clusterlabs.org<br>&gt; <br><br><br><br><br>------------------------------<br><br>Message: 5<br>Date: Thu, 8 Oct 2015 14:20:54 -0300<br>From: Cleber Paiva de Souza &lt;cleberps@gmail.com&gt;<br>To: Cluster Labs - All topics related to open-source clustering<br>        welcomed        &lt;users@clusterlabs.org&gt;<br>Subject: Re: [ClusterLabs] Xen Migration/resource cleanup problem in<br>        SLES11        SP3<br>Message-ID:<br>        &lt;CAEm4n7ZYv7xb+ZaBHot=ZXA1EA2GJgTsOS7CAS57_XMGrJpo-g@mail.gmail.com&gt;<br>Content-Type: text/plain; charset="utf-8"<br><br>Are both machines identical hardware/version/model? We found that machines<br>with different CPU features crash while migrating from the machine with<br>more features to one with few features.<br>Also are your STONITH ok? STONITH protects from that muti-running behavior.<br><br><br>On Thu, Oct 8, 2015 at 9:29 AM, Ulrich Windl &lt;<br>Ulrich.Windl@rz.uni-regensburg.de&gt; wrote:<br><br>&gt; Hi!<br>&gt;<br>&gt; I'd like to report an "interesting problem" with SLES11 SP3+HAE (latest<br>&gt; updates):<br>&gt;<br>&gt; When doing "rcopenais stop" on node "h10" with three Xen-VMs running, the<br>&gt; cluster tried to migrate those VMs to other nodes (OK).<br>&gt;<br>&gt; However migration failed on the remote nodes, but the cluster thought<br>&gt; migration was successfully. Later the cluster restarted the VMs (BAD).<br>&gt;<br>&gt; Oct&nbsp; 8 13:19:17 h10 Xen(prm_xen_v07)[16537]: INFO: v07: xm migrate to h01<br>&gt; succeeded.<br>&gt; Oct&nbsp; 8 13:20:38 h01 Xen(prm_xen_v07)[9027]: ERROR: v07: Not active<br>&gt; locally, migration failed!<br>&gt;<br>&gt; Oct&nbsp; 8 13:44:53 h01 pengine[18985]:&nbsp; warning: unpack_rsc_op_failure:<br>&gt; Processing failed op migrate_from for prm_xen_v07 on h01: unknown error (1)<br>&gt;<br>&gt; Things are really bad after h10 was rebooted eventually: The cluster<br>&gt; restarted the three VMs again, because it thought those VMs were still<br>&gt; running on h10! (VERY BAD)<br>&gt; During startup, the cluster did nor probe the three VMs.<br>&gt;<br>&gt; Oct&nbsp; 8 14:14:20 h01 pengine[18985]:&nbsp; warning: unpack_rsc_op_failure:<br>&gt; Processing failed op migrate_from for prm_xen_v07 on h01: unknown error (1)<br>&gt;<br>&gt; Oct&nbsp; 8 14:14:20 h01 pengine[18985]:&nbsp;&nbsp; notice: LogActions: Restart<br>&gt; prm_xen_v07 (Started h10)<br>&gt;<br>&gt; Oct&nbsp; 8 14:14:20 h01 crmd[18986]:&nbsp;&nbsp; notice: te_rsc_command: Initiating<br>&gt; action 89: stop prm_xen_v07_stop_0 on h01 (local)<br>&gt;<br>&gt; ...<br>&gt;<br>&gt; Regards,<br>&gt; Ulrich<br>&gt;<br>&gt;<br>&gt;<br>&gt; _______________________________________________<br>&gt; Users mailing list: Users@clusterlabs.org<br>&gt; http://clusterlabs.org/mailman/listinfo/users<br>&gt;<br>&gt; Project Home: http://www.clusterlabs.org<br>&gt; Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf<br>&gt; Bugs: http://bugs.clusterlabs.org<br>&gt;<br><br><br><br>-- <br>Cleber Paiva de Souza<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: &lt;http://clusterlabs.org/pipermail/users/attachments/20151008/0b2d2f01/attachment-0001.html&gt;<br><br>------------------------------<br><br>Message: 6<br>Date: Thu, 8 Oct 2015 20:42:50 +0200<br>From: "J. Echter" &lt;j.echter@echter-kuechen-elektro.de&gt;<br>To: users@clusterlabs.org<br>Subject: Re: [ClusterLabs] gfs2 crashes when i, e.g., dd to a lvm<br>        volume<br>Message-ID: &lt;5616B92A.1070108@echter-kuechen-elektro.de&gt;<br>Content-Type: text/plain; charset=utf-8<br><br>Am 08.10.2015 um 16:34 schrieb Bob Peterson:<br>&gt; ----- Original Message -----<br>&gt;&gt;<br>&gt;&gt; Am 08.10.2015 um 16:15 schrieb Digimer:<br>&gt;&gt;&gt; On 08/10/15 07:50 AM, J. Echter wrote:<br>&gt;&gt;&gt;&gt; Hi,<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; i have a strange issue on CentOS 6.5<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; If i install a new vm on node1 it works well.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; If i install a new vm on node2 it gets stuck.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; Same if i do a dd if=/dev/zero of=/dev/DATEN/vm-test (on node2)<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; On node1 it works:<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; dd if=/dev/zero of=vm-test<br>&gt;&gt;&gt;&gt; Schreiben in ?vm-test?: Auf dem Ger?t ist kein Speicherplatz mehr<br>&gt;&gt;&gt;&gt; verf?gbar<br>&gt;&gt;&gt;&gt; 83886081+0 Datens?tze ein<br>&gt;&gt;&gt;&gt; 83886080+0 Datens?tze aus<br>&gt;&gt;&gt;&gt; 42949672960 Bytes (43 GB) kopiert, 2338,15 s, 18,4 MB/s<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; dmesg shows the following (while dd'ing on node2):<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; INFO: task flush-253:18:9820 blocked for more than 120 seconds.<br>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Not tainted 2.6.32-573.7.1.el6.x86_64 #1<br>&gt;&gt;&gt;&gt; "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br>&gt;&gt;&gt; &lt;snip&gt;<br>&gt;&gt;&gt;&gt; any hint on fixing that?<br>&gt;&gt;&gt; Every time I've seen this, it was because dlm was blocked. The most<br>&gt;&gt;&gt; common cause of DLM blocking is a failed fence call. Do you have fencing<br>&gt;&gt;&gt; configured *and* tested?<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; If I were to guess, given the rather limited information you shared<br>&gt;&gt;&gt; about your setup, the live migration consumed the network bandwidth,<br>&gt;&gt;&gt; chocking out corosync traffic which caused the peer to be declared lost,<br>&gt;&gt;&gt; called a fence which failed and left locking hung (which is by design;<br>&gt;&gt;&gt; better to hang that risk corruption).<br>&gt;&gt;&gt;<br>&gt;&gt; Hi,<br>&gt;&gt;<br>&gt;&gt; fencing is configured and works.<br>&gt;&gt;<br>&gt;&gt; I re-checked it by typing<br>&gt;&gt;<br>&gt;&gt; echo c &gt; /proc/sysrq-trigger<br>&gt;&gt;<br>&gt;&gt; into node2 console.<br>&gt;&gt;<br>&gt;&gt; The machine is fenced and comes back up. But the problem persists.<br>&gt; Hi,<br>&gt;<br>&gt; Can you send any more information about the crash? What makes you think<br>&gt; it's gfs2 and not some other kernel component? Do you get any messages<br>&gt; on the console? If not, perhaps you can temporarily disable or delay fencing<br>&gt; long enough to get console messages.<br>&gt;<br>&gt; Regards,<br>&gt;<br>&gt; Bob Peterson<br>&gt; Red Hat File Systems<br>&gt;<br>&gt; _______________________________________________<br>&gt;<br>Hi,<br><br>i just recognized that gfs2 is probably the wrong candidate.<br><br>I use clustered lvm (drbd), and i experience this on a&nbsp; lvm volume, not<br>formatted to anything.<br><br>What logs would you need to identify the cause?<br><br><br><br>------------------------------<br><br>_______________________________________________<br>Users mailing list<br>Users@clusterlabs.org<br>http://clusterlabs.org/mailman/listinfo/users<br><br><br>End of Users Digest, Vol 9, Issue 21<br>************************************</div>