Lon Hohberger wrote:
Certainly, the 'ssh' agent could automatically recover in a few more
cases than the 'manual' agent ('meatware' in Linux-HA lingo).
And with multi-level fencing, ssh could be tried first, then the
meatware could be stirred...
Someone mentioned recently (elsewhere) that it would be great if we had
a fencing agent which just called some user-specified command to do
things (and could substitute variables if necessary, like %p ->
password, %l -> login, etc.):
I agree that this would be very nice :-)
(a) I do not think this is not a supportable solution, due to the
limitless array of possible configurations for hardware we have never
heard of. All support for this agent would likely be limited to this
mailing list and bugs in the actual agent itself.
I don't think that would be a problem. Most (maybe not all) admins
should be smart enough to understand that you cannot support the command
used within this agent even if the agent is supported.
(b) Rather than developing a proper fence agent for their particular
hardware, people will use this as a means to an end, which will not
improve the linux-cluster project as a whole. That sucks :(
Is there any good documentation on how to make a fencing agent? What
kind of info the agent can get from the cluster service, etc... Would be
great! I would like to automatically find a list of scsi-devices shared
between 2 systems in a 2-node cluster so I could hack up a fencing
device that used scsi reservation. Combine this with the stonith option
in the scsi driver and I would have a nice fence for cheap clusters. If
I have to manually configure the list of devices it would be easier to
use the proposed fence agent to run some existing command-line tool.
So, given that it is not up to me, who else wants this (I'm talking to
you lurkers out there). I am waiting for the flaming mantis to burn me
for even suggesting such a thing...
I certainly want it. It would fill an immediate need to get up and
running with better fencing than the manual one. Something as simple as
ssh would have a better chance at getting the system quickly back to
service than waiting for the meat...
--
birger
--
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
