Hello Lars,
> If the node fails, and the other side needs STONITH, the resource will
> be started in that partition automatically. The location constraints
> don't hurt, but you don't need them. STONITH resources get started
> before any STONITH operation is performed, which has roughly the same
> effect.
I see. Okay than I remove them. I just did them because I did not
understand what happens but scratched on the uppest layer. :-)
> And yes, on a stop failure, a node might decide to fence itself too. As
> stonithd is network aware, it doesn't matter where exactly in the
> cluster the STONITH resource runs.
Good point. During my dozens of test setup at the beginning I had in
fact heartbeat instances that locked themselfes on a 'reboot' but I
never seen this problem again.
Thanks for the elaboration on this topic. I hope that I have a good
stonith implementation but I thought about making stonith high available
itself:
# # # # # # # # # # # # # #
/# Switch 01 #-----# Switch 02 #\
/ # # # # # # # # # # # # # # \
| | | |
| # # # # # # # # # # # # # # |
| # Stonith 1 #\ /# Stonith 2 # |
| # # # # # # # \ / # # # # # # # |
| | / | |
\ # # # # # # # / \ # # # # # # # /
\# apache 01 #/ \# apache 02 #/
# # # # # # # # # # # # # #
A Stonith Device would like this: Atmel + Ethernet Controller + a few
optocoupler. It would get a broadcast or multicast udp frame, resets a
component and sends an acknowldege back. On the heartbeat site there
would be an application written n c which opens a udp socket, sends the
request and waits 5 Seconds for one asnwer. If it receives it, the
stonith worked, otherwise not. A friend of mine could build the hardware
in 5 days from scratch and I could write the software in 2 hours or so.
Just a thought. Let's see if it gets reality. One stonith device has ~
10 reset lines.
Thomas
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
