http://permalink.gmane.org/gmane.linux.highavailability.pacemaker hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17585 <pre> On 22/05/2013, at 9:44 PM, Brian J. Murrell &lt;brian-SquOHqY54CVWr29BmMi2cA&lt; at &gt;public.gmane.org&gt; wrote: Can I take a brief moment to highlight those last two lines... And to also refer you to http://blog.clusterlabs.org/blog/2013/pacemaker-on-rhel6-dot-4/ which talks about issues with fencing for plugin-based clusters. It looks to me like pacemaker shut down... Is the other node in this cluster running the same version of pacemaker? It seems to have started with which led to and This is not a happy cluster. Are these real machines or VMs? Firewall config ok? Also, 1.1.8-7 was not tested with the plugin _at_all_ (and neither will future RHEL builds). I highly recommend moving to cman for RHEL6 Check out the quickstart: http://clusterlabs.org/quickstart-redhat.html _______________________________________________ Pacemaker mailing list: Pacemaker-BSnDWwoz/2aRShoRxXF5/EB+6BGkLq7r&lt; at &gt;public.gmane.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Gett</pre> Andrew Beekhof 2013-05-22T23:05:05 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17584 <pre> On 22/05/2013, at 10:25 PM, Groshev Andrey &lt;greenx-o+MxOtu4lMCHXe+LvDLADg&lt; at &gt;public.gmane.org&gt; wrote: This is the root of your problem. Your config has: So even though you thought you only started corosync, you also started part of pacemaker. Specifically the part of pacemaker that gets loaded into corosync to provides membership and _quorum_ APIs to the other daemons. The output from corosync-quorumtool is completely irrelevant to pacemaker in this kind of setup. Since you're on a RHEL derivative, I highly suggest using Pacemaker with CMAN (and updating to 6.4 while you're there :-). In this case, the pacemaker daemons DO see the same quorum as corosync-quorumtool and your expectations would be correct. Check out the quickstart: http://clusterlabs.org/quickstart-redhat.html _______________________________________________ Pacemaker mailing list: Pacemaker-BSnDWwoz/2aRShoRxXF5/EB+6BGkLq7r&lt; at &gt;public.gmane.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org </pre> Andrew Beekhof 2013-05-22T22:46:01 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17583 <pre> On 23/05/2013, at 1:04 AM, Халезов Иван &lt;i.khalezov&lt; at &gt;rts.ru&gt; wrote: No, it is only needed if you're trying to run pacemaker with corosync 1.x (without cman) _______________________________________________ Pacemaker mailing list: Pacemaker&lt; at &gt;oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org </pre> Andrew Beekhof 2013-05-22T21:55:39 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17582 <pre>My apologies for being unclear on that - I'm using the corosync 1.4.1 rpm provided by CentOS/RHEL 6.4. I'll try using the member objects within the interface block to see if that has my setup behave any better. Thanks! On Wed, May 22, 2013 at 05:12:43PM +0200, Jan Friesse babbled thus: </pre> Mike Edwards 2013-05-22T17:40:39 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17581 <pre>It doesn't appear that either multicast or udpu works for me - I'm just using straight ip-to-ip udp. On Wed, May 22, 2013 at 05:10:05PM +0200, Jan Friesse babbled thus: </pre> Mike Edwards 2013-05-22T17:37:12 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17580 <pre>Hi all, I'm trying to put together a 2 node mysql cluster using drbd as the db backing store. I have 4 interfaces in each node: * 2 nics bonded and x-over cabled between each node for drbd data sync and heartbeats * 1 'public' nic, and * 1 'private' nic The public and private nics each have a non-vip address that should always be running, and their routes should always be set. I have 2 VIPs: * 1 public VIP * 1 private VIP It all *basically* works, but I'm trying to make sure I have everything configured in the best possible way. I would really love to see how others are doing this same basic configuration. And would love to hear lessons learned in the process of making it all work. Thanks, -C _______________________________________________ Pacemaker mailing list: Pacemaker-BSnDWwoz/2aRShoRxXF5/EB+6BGkLq7r&lt; at &gt;public.gmane.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http:/</pre> christopher barry 2013-05-22T17:27:37 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17579 <pre>FYI - I've opened a ticket on the RH bugzilla ( https://bugzilla.redhat.com/show_bug.cgi?id=966150) against the fence_agents component. On Wed, May 22, 2013 at 12:00 PM, John McCabe &lt;john-FvgtlxJFTVNEc5xgUasm0w&lt; at &gt;public.gmane.org&gt; wrote: _______________________________________________ Pacemaker mailing list: Pacemaker-BSnDWwoz/2aRShoRxXF5/EB+6BGkLq7r&lt; at &gt;public.gmane.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org </pre> John McCabe 2013-05-22T15:42:29 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17578 <pre>Actually, I've reviewed that config file again and it looks like you are using corosync 1.x. There nodelist is really not supported, and supported is member object inside of interface (see corosync.conf.example.udpu). For corosync 2.x, member object inside interface object works also, but it's internally converted to recommended version with nodelist (so that's what you've sent). Regards, Honza Mike Edwards napsal(a): _______________________________________________ Pacemaker mailing list: Pacemaker-BSnDWwoz/2aRShoRxXF5/EB+6BGkLq7r&lt; at &gt;public.gmane.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org </pre> Jan Friesse 2013-05-22T15:12:43 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17577 <pre>Mike Edwards napsal(a): As long as UDP (multicast) works for you, it's better solution (better tested, faster, ...). UDPU is targeted for deployments where multicast is problem. Regards, Honza _______________________________________________ Pacemaker mailing list: Pacemaker-BSnDWwoz/2aRShoRxXF5/EB+6BGkLq7r&lt; at &gt;public.gmane.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org </pre> Jan Friesse 2013-05-22T15:10:05 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17576 <pre>Hello everyone! I decided to update my pacemaker installation to the lastest version in CentOS 6.4 repository. For some reasons we need to use corosync 2.3 in our system. So i had to rebuilt pacemaker with corosync 2.3 support. I took pacemaker-1.1.8-7.el6.src.rpm package from CentOS vault repository, and tried to rebuilt it at my system: rpmbuild --rebuild pacemaker-1.1.8-7.el6.src.rpm --with snmp --with profiling --without doc --without cman It built well, but at the end, during packing files into rpm package, I got an error: File not found: .......BUILDROOT/pacemaker-1.1.8-7.el6.x86_64/usr/libexec/lcrso/pacemaker.lcrso I can avoid this error, removing a string "%{_libexecdir}/lcrso/pacemaker.lcrso" from spec-file file section. (then rpmbuild would not try to pack this file to rpm-package) Can anybody tell me is this file really needed for pacemaker? If yes, what shell I do with this error? Thank you in advance! Ivan Khalezov. _______________________________________________ Pacemaker </pre> Халезов Иван 2013-05-22T15:04:52 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17575 <pre>Le 22/05/2013 15:02, Daniel Gullin a écrit : Maybe there are more elegant ways I haven't heard about but you can totally create a lsb resource firing a custom script of yours in the start() section, and by smart usage of group or collocation+ordering, force this resource to be started after all the others. Beware of the lsb compliance of your resource... </pre> Florian Crouzat 2013-05-22T13:29:11 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17574 <pre>Yep. The config I pasted has the bindnetaddr set to 10.10.23.50, which also happens to be defined as node 1. On Wed, May 22, 2013 at 09:28:13AM +0200, Jan Friesse babbled thus: </pre> Mike Edwards 2013-05-22T13:05:40 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17573 <pre>Hi, is there is any possibilities to use a "post-script" when a failover has happened ? I have a corosync/pacemaker installation with two services, filesystem and IP and two nodes. The system should be in passive/active mode. When a failover has happen the passive node should mount the shared disk and migrate the shared IP as well, when that is finished I want pacemake to run a script on the "new" active node. Could I do this ? Thanks Daniel _______________________________________________ Pacemaker mailing list: Pacemaker-BSnDWwoz/2aRShoRxXF5/EB+6BGkLq7r&lt; at &gt;public.gmane.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org </pre> Daniel Gullin 2013-05-22T13:02:35 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17572 <pre>Which would be the recommended trqansport? I'm not tied to any particular method. On Wed, May 22, 2013 at 10:01:37AM +1000, Andrew Beekhof babbled thus: </pre> Mike Edwards 2013-05-22T13:02:10 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17571 <pre>Emmanuel, this bug appears to refer to functionality in cman. We're using pcs to manage corosync/pacemaker. Thanks. On Tue, May 21, 2013 at 10:55:19PM +0200, emmanuel segura babbled thus: </pre> Mike Edwards 2013-05-22T13:00:56 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17570 <pre>Hello, I try build cluster with 2 nodes + one quorum node (without pacemaker). The sequence of actions like the following: 1. setup/start corosync on TREE nodes - all right. # corosync-quorumtool -l|sed 's/\..*$//' Nodeid    Votes  Name 295521290    1  dev-cluster2-node2 312298506    1  dev-cluster2-node3 329075722    1  dev-cluster2-node4 2. start pacemaer on FIRST node. 3. write config with crmsh  .... stonith-enabled="false" 4. .... no-quorum-policy="ignore" 5. write main config ocf:heartbeat:pgsql     Like: https://github.com/t-matsuo/resource-agents/wiki/Resource-Agent-for-PostgreSQL-9.1-streaming-replication     But with one VIP on master PG     Resources are started on first node. 6. Next. Sync PG data with TWO node. 7. start pacemaker on TWO node. Resource started too. 8. no-quorum-policy="stop". Ok. All resources work on two nodes. See # corosync-quorumtool -l|sed 's/\..*$//' Nodeid    Votes  Name 295521290    1  dev-cluster2-node2 312298506    1  dev-cluster2-node3 </pre> Groshev Andrey 2013-05-22T12:25:54 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17569 <pre>Using pacemaker 1.1.8-7 on EL6, I got the following series of events trying to shut down pacemaker and then corosync. The corosync shutdown (service corosync stop) ended up spinning/hanging indefinitely (~7hrs now). The events, including a: May 21 23:47:18 node1 crmd[17598]: error: do_exit: Could not recover from internal error For completeness, I've included the logging from the whole session, from corosync startup until it all went haywire. The badness seems to start at about 23:43:18. May 21 23:42:51 node1 corosync[17541]: [MAIN ] Corosync Cluster Engine ('1.4.1'): started and ready to provide service. May 21 23:42:51 node1 corosync[17541]: [MAIN ] Corosync built-in features: nss dbus rdma snmp May 21 23:42:51 node1 corosync[17541]: [MAIN ] Successfully read main configuration file '/etc/corosync/corosync.conf'. May 21 23:42:51 node1 corosync[17541]: [TOTEM ] Initializing transport (UDP/IP Multicast). May 21 23:42:51 node1 corosync[17541]: [TOTEM ] Initializing transmit/receive secur</pre> Brian J. Murrell 2013-05-22T11:44:58 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17568 <pre>No joy with ipport sadly &lt;nvpair id="st-rhevm-instance_attributes-ipport" name="ipport" value="443"/&gt; &lt;nvpair id="st-rhevm-instance_attributes-shell_timeout" name="shell_timeout" value="10"/&gt; Can you share the changes you made to fence_rhevm for the API change? I've got what *should* be the latest packages from the HA channel on both systems. On Wed, May 22, 2013 at 11:34 AM, Andrew Beekhof &lt;andrew-D/W8/uK7x5LR7s880joybQ&lt; at &gt;public.gmane.org&gt; wrote: _______________________________________________ Pacemaker mailing list: Pacemaker-BSnDWwoz/2aRShoRxXF5/EB+6BGkLq7r&lt; at &gt;public.gmane.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org </pre> John McCabe 2013-05-22T11:00:58 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17567 <pre> On 22/05/2013, at 7:31 PM, John McCabe &lt;john-FvgtlxJFTVNEc5xgUasm0w&lt; at &gt;public.gmane.org&gt; wrote: Mine is: &lt;primitive id="Fencing" class="stonith" type="fence_rhevm"&gt; &lt;instance_attributes id="Fencing-params"&gt; &lt;nvpair id="Fencing-ipport" name="ipport" value="443"/&gt; &lt;nvpair id="Fencing-shell_timeout" name="shell_timeout" value="10"/&gt; &lt;nvpair id="Fencing-passwd" name="passwd" value="{pass}"/&gt; &lt;nvpair id="Fencing-ipaddr" name="ipaddr" value="{ip}"/&gt; &lt;nvpair id="Fencing-ssl" name="ssl" value="1"/&gt; &lt;nvpair id="Fencing-login" name="login" value="{user}&lt; at &gt;{domain}"/&gt; &lt;/instance_attributes&gt; &lt;operations&gt; &lt;op id="Fencing-monitor-120s" interval="120s" name="monitor" timeout="120s"/&gt; &lt;op id="Fencing-stop-0" interval="0" name="stop" timeout="60s"/&gt; &lt;op id="Fencing-start-0" interval="0" name="start" timeout="60s"/&gt; &lt;/operations&gt; &lt;/primitive&gt; Maybe ipport is important? Also, there was a RHEVM A</pre> Andrew Beekhof 2013-05-22T10:34:13 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17566 <pre>Hi, I've been trying to get fence_rhevm (fence-agents-3.1.5-25.el6_4.2.x86_64) working within pacemaker (pacemaker-1.1.8-7.el6.x86_64) but am unable to get it to work as intended, using fence_rhevm on the command line works as expected, as does stonith_admin but from within pacemaker (triggered by deliberately killing corosync on the node to be fenced): May 21 22:21:32 defiant corosync[1245]: [TOTEM ] A processor failed, forming new configuration. May 21 22:21:34 defiant corosync[1245]: [QUORUM] Members[1]: 1 May 21 22:21:34 defiant corosync[1245]: [TOTEM ] A processor joined or left the membership and a new membership was formed. May 21 22:21:34 defiant kernel: dlm: closing connection to node 2 May 21 22:21:34 defiant corosync[1245]: [CPG ] chosen downlist: sender r(0) ip(10.10.25.152) ; members(old:2 left:1) May 21 22:21:34 defiant corosync[1245]: [MAIN ] Completed service synchronization, ready to provide service. May 21 22:21:34 defiant crmd[1749]: notice: crm_update_peer_state: cman_even</pre> John McCabe 2013-05-22T09:31:30 http://permalink.gmane.org/gmane.linux.highavailability.pacemaker/17565 <pre> Ich werde ab 22.05.2013 nicht im Büro sein. Ich kehre zurück am 25.05.2013. Sehr geehrte Damen und Herren, ich bin bis einschließlich 24.05 auf Dienstreise. Trotzdem versuche ich Ihr Anliegen so schnell als möglich zu beantworten. Bitte wenden Sie sich für Netzwerk bezogene Anliegen immer ksi.network-a0DU2FzwCvJfmgfxC/sS/w&lt; at &gt;public.gmane.org Falls es sich um Betriebssystem Punkte handeln sollte, senden Sie Ihre Mail bitte immer an ksi.os-a0DU2FzwCvJfmgfxC/sS/w&lt; at &gt;public.gmane.org Please note, that I am on a business trip until 24.05.13. Always use "ksi.network-a0DU2FzwCvIAvxtiuMwx3w&lt; at &gt;public.gmane.org", which ensures that one of our network adminsitrators takes care of your interest. If you need operating system support please contact ksi.os-rV0RhHQV16O/3pe1ocb+s1+aB/EL+xL/&lt; at &gt;public.gmane.org _______________________________________________ Pacemaker mailing list: Pacemaker-BSnDWwoz/2aRShoRxXF5/EB+6BGkLq7r&lt; at &gt;public.gmane.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.cluste</pre> Patrik.Rapposch-a0DU2FzwCvIAvxtiuMwx3w< at >public.gmane.org 2013-05-22T07:53:19 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.highavailability.pacemaker