[LinuxFailSafe] Questions about Failsafe internal architecture

[Lars Marowsky-Bree]

On 2002-07-03T12:07:57,
   Yuval Yeret <yuval@exanet.com> said:

> My company is pondering the use of Linux Failsafe as a clustering
> solution for an application HA cluster ranging in size from 4 nodes to
> 30 nodes. 

Great! However, FailSafe will not work with more than 8 nodes - for a typical
failover scenario, even 3 or 4 nodes is plenty; this is of course different
from a load-balancing cluster.

> The documentation available describes quite clearly the failover schemes
> and functionalities, but I could not get a good picture of the internal
> architecture (CHAOS?), especially in respect to the group services
> implementation and API available, and the cluster database.

I am afraid the API is very badly documented; SGI has some external
documentation on it, which is rather good, but which I only have in printed
form.

Maybe Paddy could help you get access to it?

Otherwise, I would recommend looking at Ensemble et al for a group
communication layer - see http://www.lcic.org/ for a list.

> Is the group services scalable ? I understood that at least in the beginning
> it was point-to-point based and not multicast - has that changed ? Is there
> work in progress on that area - maybe something we can help achieve ? 

It doesn't scale too well right now, it is limitted to 8 nodes.

The entire algorithms would probably need rewriting to work well with more.

> Is the cluster DB available for use in our own applications, both as a
> parameters database and as an operational repository of information used
> by various processes ? 

Yes; the CDB does have external APIs. For an example of how to use it, look at
any of the FailSafe command-line tools, which basically manipulate only the
CDB.

You might also care for the Open Clustering Framework effort (see the
rudimentary website at http://www.opencf.org/), which tries to standarize such
APIs for the Linux platform.


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
Immortality is an adequate definition of high availability for me.
	--- Gregory F. Pfister