If you just want to have a cluster where client network can be down infinitely without cluster to take actions, you have to run cluster heartbeat via cross-cable and deny cluster's link monitoring in client interface. Or then start using qdisk and build heuristics. Note, that in RHCS 5 deadnode_timeout doesn't exist anymore in /proc. It's totem token there, but havn't checked where it lives in /proc or maby it's in /sys nowadays. -hjp -----Original Message----- From: linux-cluster-bounces@xxxxxxxxxx on behalf of Andrew Lacey Sent: Thu 4/17/2008 19:55 To: linux clustering Subject: RE: IP-based tie-breaker on a 2-node cluster? > There's an argument that if your switch is down for 30 minutes, you > have bigger problems. If you have a 30 minute switch outage, the chances > are that you can live with the node power-up time on top of that. Point taken, but the problem is that if there is a switch outage and the nodes kill each other, then somebody has to come in, power the nodes back on and make sure everything comes up OK. It would be much easier if the nodes would just detect that the switch is down and wait patiently without doing anything (since there is really nothing wrong with the nodes at all, and if they just wait for the switch to come back, everything will be fine.) We do have a history of flaky network here because we're a college...we have a lot of machines on campus that we don't control (student-owned) and we get weird traffic, rogue machines, etc. more frequently than a locked-down corporate environment. I want to make sure that one of those network events doesn't needlessly bring down our mail service, which is what will be running on this cluster. -Andrew L -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
<<winmail.dat>>
-- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
