Florian, I have checked the different links you have sent and I am a bit confused with this RRP matter.<br><br>I want to use two machines (primary / secondary) and set up the following interfaces:<br><br>- eth0 : direct link between primary and secondary<br>
- bond0: bonding of eth1 and eth2 (redundant network with two switches).<br><br>Will there be any issues while using these two interfaces for OpenAis communication channels? (especially with the bonding)<br><br>Thank you.<br>
<br><div class="gmail_quote">2009/10/22 Florian Haas <span dir="ltr"><<a href="mailto:florian.haas@linbit.com">florian.haas@linbit.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Steve,<br>
<br>
what has repeatedly come up is that RRP links don't auto-heal (see<br>
thread:<br>
<a href="http://oss.clusterlabs.org/pipermail/pacemaker/2009-May/001784.html" target="_blank">http://oss.clusterlabs.org/pipermail/pacemaker/2009-May/001784.html</a>),<br>
and that passive mode RRP seems to not work at all (see thread:<br>
<a href="https://lists.linux-foundation.org/pipermail/openais/2009-October/013095.html" target="_blank">https://lists.linux-foundation.org/pipermail/openais/2009-October/013095.html</a><br>
-- this was also heavily discussed on IRC; the only approach that fixed<br>
the issue was to change rrp_mode to active). Can you fill us in on the<br>
progress on these issues? Thanks!<br>
<br>
Cheers,<br>
<font color="#888888">Florian<br>
</font><div><div></div><div class="h5"><br>
On 10/22/2009 06:14 AM, Steven Dake wrote:<br>
> You can run with one NIC (and switch) but then your NIC and switch<br>
> become a SPOF (single point of failure).  Vehicles have a spare tire for<br>
> a reason :)  If a NIC fails it may be ok to switch a service to a<br>
> different node.  If a switch fails, The entire cluster becomes disabled<br>
> until the switch returns to operation.<br>
><br>
> Availability is a mathematical equation:<br>
><br>
> A = MTTF / (MTTF+MTTR)<br>
><br>
> Pacemaker improves availability (A) by reducing mean time to repair<br>
> (MTTR) using failover while keeping the mean time to failure (MTTF)<br>
> essentially the same (although it is generally a bit lower because of<br>
> other components in the system required to introduce redundancy).<br>
> Instead of a typical 1 machine MTTR of 4 hours under a typical SLA, MTTR<br>
> may be 5-10 seconds or less (the time to failover the application and<br>
> restart it).  If MTTR is several days to service a switch, your<br>
> availability may not meet your customer SLA obligations.  When<br>
> determining whether to use a redundant switch the risks vs cost have to<br>
> be evaluated based upon your availability requirements.<br>
><br>
> Regards<br>
> -steve<br>
<br>
</div></div><br>_______________________________________________<br>
Pacemaker mailing list<br>
<a href="mailto:Pacemaker@oss.clusterlabs.org">Pacemaker@oss.clusterlabs.org</a><br>
<a href="http://oss.clusterlabs.org/mailman/listinfo/pacemaker" target="_blank">http://oss.clusterlabs.org/mailman/listinfo/pacemaker</a><br>
<br></blockquote></div><br>