stonith won&#39;t help with what we&#39;re trying to test.<br><br>using both communications channels seems it won&#39;t solve this issue either.<br><br>we wan&#39;t heartbeat to fail drbd over if the main (or &quot;public&quot;) interface is down.
<br>the machine may still be operational, but the network could be down - for a number of reasons.<br><br>if we monitor both communications channels as you say, it&#39;ll never fail over because the cross-over cable<br>for the drbd data never fails.
<br><br>we currently have heartbeat monitoring the &quot;public&quot; ip of the other server.<br>we can&#39;t have the drbd data on the same interface - because that could end up being too much traffic<br>and would limit our bandwidth to do any real work.
<br><br>monitoring the cross-over (drbd) link is equally pointless. drbd manages that itself quite well.<br>if we disable heartbeat for drbd monitoring, then we lack the ability to umount and remount the partitions if servers fail.
<br><br>it seems that in this instance heartbeat can only be used for a full server failure (lost power).<br><br>Dan.<br><br><div><span class="gmail_quote">On 6/18/07, <b class="gmail_sendername">Lars Ellenberg</b> &lt;<a href="mailto:lars.ellenberg@linbit.com">
lars.ellenberg@linbit.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Thu, Jun 14, 2007 at 01:54:58PM -0400, Dan Gahlinger wrote:
<br>&gt; Lars,<br>&gt;<br>&gt; we found the &quot;fly in the ointment&quot; . we know why it fails, but no idea how to<br>&gt; fix it.<br>&gt; Take this basic setup:<br>&gt;<br>&gt; test1 and test2 running drbd and heartbeat.
<br>&gt; drbd is on a cross-over cable between the two.<br>&gt; heartbeat is on the public interface.<br>&gt; test1 is primary (for the sake of argument)<br>&gt;<br><br>for heartbeat to do its heartbeats you should use every communication
<br>channel available. you should definitely use the drbd replication link<br>as heartbeat comm channel, too.<br><br>&gt; unplug the public ethernet interface from test1.<br>&gt; Nothing changes.<br>&gt;<br>&gt; test2 cannot become primary. it is impossible.
<br>&gt; test1 is already primary.<br>&gt; drbd connection is active.<br>&gt;<br>&gt; heartbeat attempts to run a drbddisk r0 start on test2<br>&gt; which is physically impossible, because drbd is already running.<br>&gt; test2 never gets the virtual ip resource (though I&#39;m not sure why).
<br>&gt; the debug log says &quot;success&quot; but it doesn&#39;t actually do it.<br>&gt; running the command manually for the virtual ip works ok though.<br>&gt;<br>&gt; heartbeat would need to do the following for this to work properly:
<br>&gt; 1. don&#39;t attempt to start drbd - this will never work<br>&gt; 2. do an unmount of the drbd filesystems on test1<br>&gt; 3. do a drbdadm secondary on test1<br>&gt; 4. then do a drbdadm primary all on test2<br>
&gt;<br>&gt; I&#39;m not even sure this is possible.<br><br>there are several options:<br> * stonith<br>&nbsp;&nbsp; when heartbeat detects one box to be dead,<br>&nbsp;&nbsp; it would switch it off using a power switch,<br>&nbsp;&nbsp; just to be sure -- because it might be not dead, after all,
<br>&nbsp;&nbsp; it may be &quot;only&quot; a complete loss of communications...<br><br> * when you have multiple comm channels, and want to trigger a<br>&nbsp;&nbsp; switchover of services when the outside connectivity on the active<br>&nbsp;&nbsp; node breaks, the concept of &quot;ping nodes&quot; or groups thereof helps.
<br><br>&nbsp;&nbsp; choose your ping nodes (and timeouts!) wisely to match your situation<br>&nbsp;&nbsp; (network and outside connectivity), ping nodes should be highly<br>&nbsp;&nbsp; available themselves (chose the upstream router/switch combo,<br>
&nbsp;&nbsp; chose the first hop of the provider network, something like that).<br>&nbsp;&nbsp; otherwise you could get spurious failover/failback.<br><br>--<br>: Lars Ellenberg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Tel +43-1-8178292-0&nbsp;&nbsp;:<br>: LINBIT Information Technologies GmbH&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Fax +43-1-8178292-82 :
<br>: Vivenotgasse 48, A-1120 Vienna/Europe&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://www.linbit.com">http://www.linbit.com</a> :<br>__<br>please use the &quot;List-Reply&quot; function of your email client.<br>_______________________________________________
<br>drbd-user mailing list<br><a href="mailto:drbd-user@lists.linbit.com">drbd-user@lists.linbit.com</a><br><a href="http://lists.linbit.com/mailman/listinfo/drbd-user">http://lists.linbit.com/mailman/listinfo/drbd-user</a>
<br></blockquote></div><br>