On Tue, Jul 15, 2008 at 11:40 AM, Chase Simms <[EMAIL PROTECTED]> wrote: > If it is the link between locations, the server that is not located with > the 3rd party address used by pingd would no longer be able to reach it.
pingd has nothing to do with STONITH. pingd can control where resource shall be started but it can't control what server has to die. > > >>>> "Serge Dubrouski" <[EMAIL PROTECTED]> 7/15/2008 11:34 AM >>> > On Tue, Jul 15, 2008 at 9:04 AM, Chase Simms <[EMAIL PROTECTED]> > wrote: >> I have a cluster set up and working except STONITH. Which means > it's >> unmanageable and not fault tolerant. I have multiple fibre > connections >> between two geographically separated locations. I want to have one > node >> at each location for disaster recovery. This means I cannot use a >> cross-over or serial connection. I'm really hoping to parlay this > into >> a proof of concept to sell the idea of using the other site as a hot >> site for critical systems. >> >> Right now I have them set up as: >> >> server 1 vlan 7 -> server 2 vlan 7 (public interface, shared IP) >> server 1 vlan 8 -> server 2 vlan 8 (DRBD replication, heartbeat) >> >> How can I configure STONITH to suicide when a connection goes down? > > I don't think that this is possible. How would you know which one of > the servers has to suicide if your network connection dies? > >> Right now, when I take down one interface, the ping still gets > through >> the other interface. >> >> It occurred to me to create a VLAN that will not route for the > private >> interfaces. But that will be very difficult to push through. Is > there >> another way? >> >> Thank you, >> Chase >> >> >> >> The information in this email is intended for the sole use of the >> addressees and may be confidential and subject to protection under > the >> law. If you are not the intended recipient, you are hereby notified > that >> any distribution or copying of this email is strictly prohibited. If > you >> have received this message in error, please reply and delete your > copy. >> >> _______________________________________________ >> Linux-HA mailing list >> [email protected] >> http://lists.linux-ha.org/mailman/listinfo/linux-ha >> See also: http://linux-ha.org/ReportingProblems >> > > > > -- > Serge Dubrouski. > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems > > > The information in this email is intended for the sole use of the > addressees and may be confidential and subject to protection under the > law. If you are not the intended recipient, you are hereby notified that > any distribution or copying of this email is strictly prohibited. If you > have received this message in error, please reply and delete your copy. > > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems > -- Serge Dubrouski. _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
