[Pacemaker] Pacemaker cluster: OpenAis communication channels

[Steven Dake]

On Thu, 2009-10-22 at 08:18 +0200, Florian Haas wrote:
> Steve,
> 
> what has repeatedly come up is that RRP links don't auto-heal (see
> thread:
> http://oss.clusterlabs.org/pipermail/pacemaker/2009-May/001784.html),
> and that passive mode RRP seems to not work at all (see thread:
> https://lists.linux-foundation.org/pipermail/openais/2009-October/013095.html
> -- this was also heavily discussed on IRC; the only approach that fixed
> the issue was to change rrp_mode to active). Can you fill us in on the
> progress on these issues? Thanks!
> 
> Cheers,
> Florian

Passive worked last time I tested, but its been awhile.  Hardening
redundant ring and making it more generally useful is on our community
derived roadmap (targeted for 1.2.0).  Please reference:
ftp://ftp%
40corosync.org:downloads at corosync.org/presentations/corosync-roadmap.pdf

Regards
-steve

> 
> On 10/22/2009 06:14 AM, Steven Dake wrote:
> > You can run with one NIC (and switch) but then your NIC and switch
> > become a SPOF (single point of failure).  Vehicles have a spare tire for
> > a reason :)  If a NIC fails it may be ok to switch a service to a
> > different node.  If a switch fails, The entire cluster becomes disabled
> > until the switch returns to operation.
> > 
> > Availability is a mathematical equation: 
> > 
> > A = MTTF / (MTTF+MTTR)
> > 
> > Pacemaker improves availability (A) by reducing mean time to repair
> > (MTTR) using failover while keeping the mean time to failure (MTTF)
> > essentially the same (although it is generally a bit lower because of
> > other components in the system required to introduce redundancy).
> > Instead of a typical 1 machine MTTR of 4 hours under a typical SLA, MTTR
> > may be 5-10 seconds or less (the time to failover the application and
> > restart it).  If MTTR is several days to service a switch, your
> > availability may not meet your customer SLA obligations.  When
> > determining whether to use a redundant switch the risks vs cost have to
> > be evaluated based upon your availability requirements.
> > 
> > Regards
> > -steve
>