<div style="font-family: Arial; font-size: 13;">The dual machine is equipped with a syncro controller LSI 3008 MPT SAS3.</div><div style="font-family: Arial; font-size: 13;">Both nodes can see the same jbod disks (10 at the moment, up to 24).</div><div style="font-family: Arial; font-size: 13;">Systems are XStreamOS / illumos, with ZFS.</div><div style="font-family: Arial; font-size: 13;">Each system has one ZFS pool of 5 disks, with different pool names (data1, data2).</div><div style="font-family: Arial; font-size: 13;">When in active / active, the two machines run different zones and services on their pools, on their networks.</div><div style="font-family: Arial; font-size: 13;">I have custom resource agents (tested on pacemaker/heartbeat, now porting to pacemaker/corosync) for ZFS pools and zones migration.</div><div style="font-family: Arial; font-size: 13;">When I was testing pacemaker/heartbeat, when ssh-fencing discovered the other node to be down (cleanly or abrupt halt), it was automatically using IPaddr and our ZFS agents to take control of everything, mounting the other pool and running any configured zone in it.</div><div style="font-family: Arial; font-size: 13;">I would like to do the same with pacemaker/corosync.</div><div style="font-family: Arial; font-size: 13;">The two nodes of the dual machine have an inernal lan connecting them, a 100Mb ethernet: maybe this is enough reliable to trust ssh-fencing? Or is there anything I can do to ensure at the controller level that the pool is not in use on the other node?</div><div style="font-family: Arial; font-size: 13;"><br></div><div style="font-family: Arial; font-size: 13;">Gabriele</div><div style="font-family: Arial; font-size: 13;"><br><div id="wt-mailcard"><div style="font-family: Arial;">----------------------------------------------------------------------------------------<br></div><div style="font-family: Arial;"><b>Sonicle S.r.l. </b>: <a href="http://www.sonicle.com/" target="_new">http://www.sonicle.com</a></div><div style="font-family: Arial;"><b>Music: </b><a href="http://www.gabrielebulfon.com/" target="_new">http://www.gabrielebulfon.com</a></div><div style="font-family: Arial;"><b>Quantum Mechanics : </b><a href="http://www.cdbaby.com/cd/gabrielebulfon" target="_new">http://www.cdbaby.com/cd/gabrielebulfon</a></div></div><tt><br><br><br>----------------------------------------------------------------------------------<br><br>Da: Ken Gaillot <kgaillot@redhat.com><br>A: gbulfon@sonicle.com Cluster Labs - All topics related to open-source clustering welcomed <users@clusterlabs.org> <br>Data: 1 settembre 2016 15.49.04 CEST<br>Oggetto: Re: [ClusterLabs] ip clustering strange behaviour<br><br></tt><blockquote style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"><tt>On 08/31/2016 11:50 PM, Gabriele Bulfon wrote:<br>> Thanks, got it.<br>> So, is it better to use "two_node: 1" or, as suggested else where, or<br>> "no-quorum-policy=stop"?<br><br>I'd prefer "two_node: 1" and letting pacemaker's options default. But<br>see the votequorum(5) man page for what two_node implies -- most<br>importantly, both nodes have to be available when the cluster starts<br>before it will start any resources. Node failure is handled fine once<br>the cluster has started, but at start time, both nodes must be up.<br><br>> About fencing, the machine I'm going to implement the 2-nodes cluster is<br>> a dual machine with shared disks backend.<br>> Each node has two 10Gb ethernets dedicated to the public ip and the<br>> admin console.<br>> Then there is a third 100Mb ethernet connecing the two machines internally.<br>> I was going to use this last one as fencing via ssh, but looks like this<br>> way I'm not gonna have ip/pool/zone movements if one of the nodes<br>> freezes or halts without shutting down pacemaker clean.<br>> What should I use instead?<br><br>I'm guessing as a dual machine, they share a power supply, so that rules<br>out a power switch. If the box has IPMI that can individually power<br>cycle each host, you can use fence_ipmilan. If the disks are shared via<br>iSCSI, you could use fence_scsi. If the box has a hardware watchdog<br>device that can individually target the hosts, you could use sbd. If<br>none of those is an option, probably the best you could do is run the<br>cluster nodes as VMs on each host, and use fence_xvm.<br><br>> Thanks for your help,<br>> Gabriele<br>> <br>> ----------------------------------------------------------------------------------------<br>> *Sonicle S.r.l. *: http://www.sonicle.com <http://www.sonicle.com/><br>> *Music: *http://www.gabrielebulfon.com <http://www.gabrielebulfon.com/><br>> *Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon<br>> <br>> <br>> <br>> ----------------------------------------------------------------------------------<br>> <br>> Da: Ken Gaillot <kgaillot@redhat.com><br>> A: users@clusterlabs.org<br>> Data: 31 agosto 2016 17.25.05 CEST<br>> Oggetto: Re: [ClusterLabs] ip clustering strange behaviour<br>> <br>>     On 08/30/2016 01:52 AM, Gabriele Bulfon wrote:<br>>     > Sorry for reiterating, but my main question was:<br>>     ><br>>     > why does node 1 removes its own IP if I shut down node 2 abruptly?<br>>     > I understand that it does not take the node 2 IP (because the<br>>     > ssh-fencing has no clue about what happened on the 2nd node), but I<br>>     > wouldn't expect it to shut down its own IP...this would kill any<br>>     service<br>>     > on both nodes...what am I wrong?<br>> <br>>     Assuming you're using corosync 2, be sure you have "two_node: 1" in<br>>     corosync.conf. That will tell corosync to pretend there is always<br>>     quorum, so pacemaker doesn't need any special quorum settings. See the<br>>     votequorum(5) man page for details. Of course, you need fencing in this<br>>     setup, to handle when communication between the nodes is broken but both<br>>     are still up.<br>> <br>>     ><br>>     ----------------------------------------------------------------------------------------<br>>     > *Sonicle S.r.l. *: http://www.sonicle.com <http://www.sonicle.com/><br>>     > *Music: *http://www.gabrielebulfon.com<br>>     <http://www.gabrielebulfon.com/><br>>     > *Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon<br>>     ><br>>     ><br>>     ------------------------------------------------------------------------<br>>     ><br>>     ><br>>     > *Da:* Gabriele Bulfon <gbulfon@sonicle.com><br>>     > *A:* kwenning@redhat.com Cluster Labs - All topics related to<br>>     > open-source clustering welcomed <users@clusterlabs.org><br>>     > *Data:* 29 agosto 2016 17.37.36 CEST<br>>     > *Oggetto:* Re: [ClusterLabs] ip clustering strange behaviour<br>>     ><br>>     ><br>>     > Ok, got it, I hadn't gracefully shut pacemaker on node2.<br>>     > Now I restarted, everything was up, stopped pacemaker service on<br>>     > host2 and I got host1 with both IPs configured. ;)<br>>     ><br>>     > But, though I understand that if I halt host2 with no grace shut of<br>>     > pacemaker, it will not move the IP2 to Host1, I don't expect host1<br>>     > to loose its own IP! Why?<br>>     ><br>>     > Gabriele<br>>     ><br>>     ><br>>     ----------------------------------------------------------------------------------------<br>>     > *Sonicle S.r.l. *: http://www.sonicle.com <http://www.sonicle.com/><br>>     > *Music: *http://www.gabrielebulfon.com<br>>     <http://www.gabrielebulfon.com/><br>>     > *Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon<br>>     ><br>>     ><br>>     ><br>>     ><br>>     ----------------------------------------------------------------------------------<br>>     ><br>>     > Da: Klaus Wenninger <kwenning@redhat.com><br>>     > A: users@clusterlabs.org<br>>     > Data: 29 agosto 2016 17.26.49 CEST<br>>     > Oggetto: Re: [ClusterLabs] ip clustering strange behaviour<br>>     ><br>>     > On 08/29/2016 05:18 PM, Gabriele Bulfon wrote:<br>>     > > Hi,<br>>     > ><br>>     > > now that I have IPaddr work, I have a strange behaviour on my test<br>>     > > setup of 2 nodes, here is my configuration:<br>>     > ><br>>     > > ===STONITH/FENCING===<br>>     > ><br>>     > > primitive xstorage1-stonith stonith:external/ssh-sonicle op<br>>     > monitor<br>>     > > interval="25" timeout="25" start-delay="25" params<br>>     > hostlist="xstorage1"<br>>     > ><br>>     > > primitive xstorage2-stonith stonith:external/ssh-sonicle op<br>>     > monitor<br>>     > > interval="25" timeout="25" start-delay="25" params<br>>     > hostlist="xstorage2"<br>>     > ><br>>     > > location xstorage1-stonith-pref xstorage1-stonith -inf: xstorage1<br>>     > > location xstorage2-stonith-pref xstorage2-stonith -inf: xstorage2<br>>     > ><br>>     > > property stonith-action=poweroff<br>>     > ><br>>     > ><br>>     > ><br>>     > > ===IP RESOURCES===<br>>     > ><br>>     > ><br>>     > > primitive xstorage1_wan1_IP ocf:heartbeat:IPaddr params<br>>     > ip="1.2.3.4"<br>>     > > cidr_netmask="255.255.255.0" nic="e1000g1"<br>>     > > primitive xstorage2_wan2_IP ocf:heartbeat:IPaddr params<br>>     > ip="1.2.3.5"<br>>     > > cidr_netmask="255.255.255.0" nic="e1000g1"<br>>     > ><br>>     > > location xstorage1_wan1_IP_pref xstorage1_wan1_IP 100: xstorage1<br>>     > > location xstorage2_wan2_IP_pref xstorage2_wan2_IP 100: xstorage2<br>>     > ><br>>     > > ===================<br>>     > ><br>>     > > So I plumbed e1000g1 with unconfigured IP on both machines and<br>>     > started<br>>     > > corosync/pacemaker, and after some time I got all nodes online and<br>>     > > started, with IP configured as virtual interfaces (e1000g1:1 and<br>>     > > e1000g1:2) one in host1 and one in host2.<br>>     > ><br>>     > > Then I halted host2, and I expected to have host1 started with<br>>     > both<br>>     > > IPs configured on host1.<br>>     > > Instead, I got host1 started with the IP stopped and removed (only<br>>     > > e1000g1 unconfigured), host2 stopped saying IP started (!?).<br>>     > > Not exactly what I expected...<br>>     > > What's wrong?<br>>     ><br>>     > How did you stop host2? Graceful shutdown of pacemaker? If not ...<br>>     > Anyway ssh-fencing is just working if the machine is still<br>>     > running ...<br>>     > So it will stay unclean and thus pacemaker is thinking that<br>>     > the IP might still be running on it. So this is actually the<br>>     > expected<br>>     > behavior.<br>>     > You might add a watchdog via sbd if you don't have other fencing<br>>     > hardware at hand ...<br>>     > ><br>>     > > Here is the crm status after I stopped host 2:<br>>     > ><br>>     > > 2 nodes and 4 resources configured<br>>     > ><br>>     > > Node xstorage2: UNCLEAN (offline)<br>>     > > Online: [ xstorage1 ]<br>>     > ><br>>     > > Full list of resources:<br>>     > ><br>>     > > xstorage1-stonith (stonith:external/ssh-sonicle): Started<br>>     > xstorage2<br>>     > > (UNCLEAN)<br>>     > > xstorage2-stonith (stonith:external/ssh-sonicle): Stopped<br>>     > > xstorage1_wan1_IP (ocf::heartbeat:IPaddr): Stopped<br>>     > > xstorage2_wan2_IP (ocf::heartbeat:IPaddr): Started xstorage2<br>>     > (UNCLEAN)<br>>     > ><br>>     > ><br>>     > > Gabriele<br>>     > ><br>>     > ><br>>     ><br>>     ----------------------------------------------------------------------------------------<br>>     > > *Sonicle S.r.l. *: http://www.sonicle.com<br>>     > <http://www.sonicle.com/><br>>     > > *Music: *http://www.gabrielebulfon.com<br>>     > <http://www.gabrielebulfon.com/><br>>     > > *Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon<br><br><br><br></tt></blockquote></div>