On Mon, 21 Jun 2010 10:20:34 +0100, Gordan Bobic <gordan@xxxxxxxxxx> wrote: > On 06/21/2010 08:52 AM, Kaloyan Kovachev wrote: >> On Fri, 18 Jun 2010 18:15:09 +0200, brem belguebli >> <brem.belguebli@xxxxxxxxx> wrote: >>> How do you deal with fencing when the intersite interconnects (SAN and >>> LAN) are the cause of the failure ? >>> >> >> GPRS or the good old modem over a phone line? > > That isn't going to work if the whole site is down for whatever reason > (unlikely as it may be). > If the whole site is down because of a power failure - yes (well, then you don't need to actually fence anything) , but if the failure is just in the intersite connection - alternative low speed connection to simply fence the remote nodes and tell the remote SAN to block it's access should be enough. > To protect yourself from the 100% outage of a remote site, the only sane > way I of approaching it I can think of is to do something like the > following: > > 1) Make each node fence itself off from the failed node using iptables > or some other firewalling method. The SAN should also be prevented from > allowing the booted out node back onto it. > then each node should do that kind of fencing, but if a single node blocks the port(s) on the switch (to the remote location) should be easier to do as fencing agent. Again having additional communication channel will help - "if it's just the link, then fence the remote nodes and don't block the port(s)" this would avoid manual intervention to restore the link after the outage is fixed > 2) Fail over the IP address or DNS name of the service. Since it's > across different sites, you are likely to have to use something like RIP > to re-route the IPs, so DNS on short refresh may well be an easier and > possibly safer option. It'll mean some downtime, but probably less than > any manual intervention in an unplanned case. > > It's not entirely ideal, bit it's about as good as it is likely to get. > And you can write a fencing agent to do something like this easily enough. > > Gordan > > -- > Linux-cluster mailing list > Linux-cluster@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
