[Linux-ha-dev] Re: Flow control in heartbeat
lmb at suse.de
Wed Jul 14 05:10:43 MDT 2004
"Zhao, Forrest" <forrest.zhao at intel.com> said:
> If we integrate a comm. layer, which include membership service in its
> own, we may face with a situation that we have duplicated membership
> service: one is in comm. layer, one is CCM.I think we should avoid
> this situation.
Right, it must be ensured that there's only one membership service, and
every other component should agree with that.
> Also membership is a basic service in cluster, it should not bind to
> comm. layer. Because many other services will use membership service.
> Am I right?
So the membership service may use the "communication primitives" below -
ie, sending and receiving raw messages via the cluster links. But that's
different (raw comm) from the group services & comm layer.
> I have a basic opinion for this topic: it's more reasonable to put
> comm. layer on the top of heartbeat instead of under heartheat.
> As I said in the last mail, I think the functionality of heartbeat
> is simply "heartbeat": periodically broadcast keepalive message and
> notify CCM daemon when it thinks some neighbor is dead.
Well, heartbeat also offers the raw communication channels and a media
abstraction which includes multipath (as the data is sent across all
channels at once), and for most configurations (excluding serial links)
transforms the network into a generic broadcast style topology.
> From down to top, it's heartbeat, membership, comm. layer. I think
> this architecture is quite clear and clean.
This is still true though.
Lars Marowsky-Brée <lmb at suse.de>
High Availability & Clustering \ ever tried. ever failed. no matter.
SUSE Labs, Research and Development | try again. fail again. fail better.
SUSE LINUX AG - A Novell company \ -- Samuel Beckett
More information about the Linux-HA-Dev