| title: | Re Linux cluster Re cgl discussion Re |
|
On Wednesday 11 August 2004 17:24, Daniel McNeil wrote:
IMHO, for the time being only failure detection and failover really
has to be unified, and that is CMAN, including interaction with
other bits and pieces, i.e., Magma and fencing, and hopefully other
systems like Lars SCRAT. As far as CMAN goes, Lars and Alan seem
to be the main parties outside Red Hat. Lon and Patrick are most
active inside Red Hat. I think wed advance fastest if they start
hacking each others code (anybody I just overlooked, please
bellow).
I not sure what you mean by "failure detection and failover".
Do you mean node failure detection and consensus membership change?
I mean anything in the cluster that can fail and be reinstantiated.
This would include server processes for cluster block devices such as
the ones Ive designed, as well as whole nodes. It would also include
communication paths, such as socket connections. But by now you may
have detected a bias against trying to deal with the latter in a
one-size-fits-all automagic, never-stop-never-give-up cluster
communications thingamajig layer. What we really need is just a
framework for failure detection, including methods supplied by various
cluster components, and methods for re-instantiating failed components.
Note note note: while a "cluster component" could conceivably be a whole
node, thats a special case and we really need to cater to the case
that will eventually be much more common, where cluster nodes may be
doing all kinds of other things besides just participating in clusters.
So by "cluster component" I really mean something closer to "task".
I thought Magma is just redhats backward compatibility layer.
What "interaction" are you worried about?
You might want to ask Lon about that...
How fencing integrates and when it occurs might be issues we
will need to think about more.
Understatement of the day.
How can the DLM go to Andrew without a membership layer to
provide membership?
By having a simple registration api that allows one to register a
membership layer, in place of what is there now, i.e., function links
between modules.
So you can call the core service "membership", but what we really
need is membership/communication, which is what cman provides.
Do you have another suggestion for this? TIPC + membership?
I think you really mean "connection manager", not "communication
service" Ill step back from this now and watch you guys sort it
out :-)
I think John really does mean communication. For high availability,
the cluster should have no single point of failure. This usually
means multiple ethernet links.
But its not the business of the cluster framework to operate the links,
only to know when they have failed and to be able to arrange for new
connections. So John really does mean "connection" and not
"communication", I hope.
(I assume CMAN supports multiple
links). To determine membership there needs to be a way of sending
messages between the nodes to determine membership. Ideally, losing
one ethernet link could/would be handle without causing any
membership change.
"Ideally" is not a strong enough word, imho.
This kind of intra-cluster communication would be valuable for
other cluster components as well. Example: a cluster snapshot :)
or cluster mirror device should be able to send messages to
other nodes in the cluster without having to worry about which
specific link to use and what to do if a link fails. This would
also be valuable for the DLM.
OK, weve seen lots of warnings about not getting derailed by trying to
invent the perfect cluster communication system, we should heed those
warnings. Instead, lets get down to precise specification of the
methods we need to have, and compare it to what already exists, for
establishing and re-establishing connections.
Does CMAN provide this kind of functionality? If so, then it
really is a communication service.
people.redhat.com/~teigland/sca.pdf people.redhat.com/~teigland/sca.pdf
Regards,
Daniel
|
