Thanks for replying, Lars. >so what you are asking for is a way to externally mark a node down (and >clean/fenced too), because you have additional out-of-band knowledge?
Yes, I think so. I'm trying to understand why this is very different from the hbaping module. The function of that, as I understand it, is to ping an hba device to determine if the node can reach the back end device. If it cannot, does it declare the node dead? >A single HBcomm plugin can't deliver, because heartbeat will try to use >the other channels (as intended; otherwise, redundancy between comm >media would be pointless). I do have an alternative channel for the nodes to communicate. Are you saying that having this other channel will prevent resources from failing over? If a node's hba adapter fails, I would expect an action to occur, not just fall back to using a network-based ping. >ping nodes need to be shared between all nodes, and don't do what you >want. If a network "ping" could be replaced by a poll of another signal, pingd sounded promising. I guess not. :( >You would need to modify the node liveness layer - either heartbeat or >preferably openAIS, as we try to shift active development away from the >heartbeat layer - to accept such async outside notifications. My original email to you mentioned an asynchronous indication that the peer node was dead. However, if the problem is solvable by polling something (again, like hbaping) I'm ok with that. I think the issue is determining that the OTHER node is dead, and trying to fail all of the resources to THIS node. Am I correct? And my apologies for mentioning ipfail - I was reading about that and pingd, and got them confused. We're running a v2 cluster. Thanks again. Mark ------------------ >On 2008-07-22T11:58:31, tsombakos_mark[at]emc.com wrote: > >Hi Mark, > >so what you are asking for is a way to externally mark a node down (and >clean/fenced too), because you have additional out-of-band knowledge? > >We don't yet have a way of doing this. > >A single HBcomm plugin can't deliver, because heartbeat will try to use >the other channels (as intended; otherwise, redundancy between comm >media would be pointless). > >ping nodes need to be shared between all nodes, and don't do what you >want. > >ipfail is v1-style, which we no longer actively develop. Also, ipfail >merely determined which side should take the resources, not declare the >other node dead. > >You would need to modify the node liveness layer - either heartbeat or >preferably openAIS, as we try to shift active development away from the >heartbeat layer - to accept such async outside notifications. > >Regards, >Lars >> >>On Tue, Jul 22, 2008 at 17:58, <tsombakos_mark[at]emc.com> wrote: > Put more simply ... I have modified the hbaping HBcomm plugin to simply > stat a file on the local filesystem (instead of checking an hba). My > hope was when I removed the file, the other node would be declared dead > and the resources would fail over. > > Needless to say, it didn't work the way I hoped. > > When I start both nodes with the line > > myping othernodename > > in ha.cf, I end up split brain, each node saying the other is "not in > our membership list". > > Theoretically, SHOULD this work? It's certainly possible I fat-fingered > something. Or do I need something like a modified ipfail module instead > of an HBcomm plugin? _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
