listuser at myrealbox.com
Sat Feb 10 10:31:10 MST 2001
On Sat, 10 Feb 2001, Michael Moerz wrote:
OK, I will have a look.
> Actually I am still believing that DRF needs a daemon process that
> knows about all monitors and what they monitor.
Yes, I also think so. So the arch will be some thing like this
individual monitors <-> drfd<-> API <-> heartbeat
I had a much simpler aim while thinking about this API. determine if the
machine is usable, if not switch it off and make the other one
active. This is slightly more advanced than regular ping.
DRF is much more grand, useful and understandably complex.
DRF can find use not only wrt heartbeat but also in many other system
monitoring areas. So what I suggest is that make DRF stand alone with
provisions for API's so that other client programs like heartbeat can use
it for its purpose.
I think that all that heartbeat is concerned is whether a system is
usable (which depends on the use) if not switch on the next machine so
that overall cluster is alive. (please correct me if I am wrong here)
Will we need some kind of load sharing ie like, Hey, my X has failed
will you be able to take over *just* that.
To do that heartbeat can get a simple Yes/No from drfd, This will ensure
that drfd is alive, and all the modules are alive. Heartbeat will also
check that the heartbeat at the other end is also alive. drfd can deal
with all the events that are generated and take appropriate responses to
it to keep the system in Yes state. As far as heartbeat is concerned this
is local to the system and not some thing that needs to be passed to the
network for the other end. If all the efforts of drfd fails and system is
in an unstable state it should give a no so that it can be taken out of
This way we can keep the interfaces clean thus reducing overall complexity
and promoting modularity.
> but I also think that I am not far off the target that I want to reach
> - a functional Diagnost and Repair Framework.
I started off with a much smaller goal :)
More information about the Linux-HA