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