Tobias Appel wrote: > On Fri, 2009-02-06 at 14:52 +0100, Dominik Klein wrote: >> Just guessing, but your cluster does not know about those "external" >> addresses, does it? >> > Well I have an internal ip added to /etc/hosts and a shortcut for the > hostname, like nagios1 192.168.0.1 and then there is the full domain > name like nagios1.hq.xxx.xxx 134.xxx.xxx.xxx and so on. > > Usually the cluster communication uses eth1 and the private IP adresses > only! so when I pull that cable, network connectivity is still there but > no communication between the cluster nodes except if you use the > external ip adress. > > So I gave stonith_ssh as hostlist the full domain name.
So the node name is not in the hostlist. Therefore the cluster cannot find a stonith device capable of managing that node. Regards Dominik >> Sounds like you're only using one connection between the nodes for >> cluster communication, pull that, see split-brain and want the cluster >> to use a connection it does not know about. > > true the cluster doesn't really know about the other connection, but as > long as it uses the fulldomain name it should be able to connect to the > other node using the external ip - at least when I do this manually it > works. > > In the logfiles it looks like it is trying to shoot each other, but like > I said nothing is happening, but at the same time only one node had > active resources - before implementing stonith_ssh both nodes would have > run all resources at the same time. > > And yeah atd is running (did a ps -aux | grep atd). > > >> But even if you configured the cluster to also use the "external" path, >> you'd have to unplug both to force them into a splitbrain scenario and >> ssh stonith wouldnt help again (no useable, known connection left). >> >> Thats exactly why ssh stonith is bad. >> >> The only way stonith ssh "works" is for cluster software failure (like >> pkill -9 heartbeat). >> > Ok that makes kinda sense, but still it should work in a 2-node setup, > and it shouldn't be waiting for more members to vote? > >> Regards >> Dominik >> >> Tobias Appel wrote: >>> Hi, >>> >>> I know I should use it only for development purposes and that's what I >>> am doing right now. >>> >>> I have configured my cluster and a resource stonith_ssh. I configured >>> stonith_ssh to use the external IP address to connect to the other >>> server. When I ran: 'stonith -t ssh -p "nagios1.hq.xxx" -T reset >>> nagios1.hq.xxx' it worked. The other node rebooted immediately. >>> >>> But when I pulled the cross-over cable the results were weird. Each node >>> had the same entry in the logfile which looked like this: >>> >>> Feb 6 12:57:59 nagios2 tengine: [27786]: info: te_fence_node: Executing >>> reboot fencing operation (63) on nagios1 (timeout=30000) >>> Feb 6 12:57:59 nagios2 stonithd: [27368]: info: client tengine [pid: >>> 27786] want a STONITH operation RESET to node nagios1. >>> Feb 6 12:57:59 nagios2 stonithd: [27368]: info: Broadcasting the >>> message succeeded: require others to stonith node nagios1. >>> >>> Then later it said: >>> Feb 6 12:58:29 nagios2 stonithd: [27368]: ERROR: Failed to STONITH the >>> node nagios1: optype=RESET, op_result=TIMEOUT >>> >>> I'm not sure why it did not reboot the other machine. Does 'require >>> others' mean that it won't work in a 2-node setup? >>> >>> The really weird part is that even though no node was rebooted, only one >>> node continued to run the resources, whereas the other was just doing >>> nothing at all. When I reconnected the cross-over cable both nodes went >>> into 'standby' state for a couple of seconds but everything was working >>> fine. >>> >>> Regards, >>> Tobi >>> >>> _______________________________________________ >>> Linux-HA mailing list >>> [email protected] >>> http://lists.linux-ha.org/mailman/listinfo/linux-ha >>> See also: http://linux-ha.org/ReportingProblems >>> >> _______________________________________________ >> Linux-HA mailing list >> [email protected] >> http://lists.linux-ha.org/mailman/listinfo/linux-ha >> See also: http://linux-ha.org/ReportingProblems > > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems > _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
