On 2 December 2010 08:27, Nikita Michalko <[email protected]> wrote: > Hi Pavlos! > > Am Dienstag, 30. November 2010 22:28 schrieb Pavlos Parissis: >> Hi Nikita, >> >> On 30 November 2010 08:42, Nikita Michalko <[email protected]> > wrote: >> > Hi Pavlos, >> > >> > Am Dienstag, 30. November 2010 05:59 schrieb Pavlos Parissis: >> >> On 29 November 2010 23:43, Lars Ellenberg <[email protected]> > wrote: >> >> > On Mon, Nov 29, 2010 at 10:24:17PM +0800, Mia Lueng wrote: >> >> >> Hi: >> >> >> I have configured a cluster with two nodes. Lan setting is >> >> >> A >> >> >> eth0: 192.168.10.110 >> >> >> eth1: 172.16.0.1 >> >> >> >> >> >> B >> >> >> eth0:192.168.10.111 >> >> >> eth1: 172.16.0.2 >> >> >> >> >> >> I have configured a resource ip_0 192.168.10.100 on eth0. But when >> >> >> I unplug the eth0 link on A, the resource can not be taken over to B >> >> >> and no any log output. >> >> >> >> >> >> I've checked the /usr/lib/ocf/resource.d/heartbeat/IPaddr2 script and >> >> >> found there are no codes for nic link status checking. >> >> >> >> >> >> How can i monitor the nic link status to protect the virtual ip >> >> >> address? Thanks. >> >> > >> >> > http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Expl >> >> >ain ed/ch09s03s03.html >> >> >> >> I am sorry this is not the expected behaviour, at least to me. I >> >> expect from the IPaddr2 to report a failure in a case the interface is >> >> not available. What is the point to maintain an IPaddr2 resource on >> >> interface which is not up? Furthermore, using the ping resource adds >> >> more complexity and basically utilizes Layer 3 protocol in order to >> >> monitor a layer 2 device ( the NIC). Using ip link show on the device >> >> should a very easy way to check link status on the NIC, ip tool >> >> supports also LOWER_UP. >> > >> > - what about configure monitor operation of IP in cib.xml - sth. like >> > this: <resources> >> > <primitive id="IPaddr_194_37_40_42" class="ocf" provider="heartbeat" >> > type="IPaddr"> >> > <meta_attributes id="primitive-IPaddr_194_37_40_42meta"/> >> > <operations> >> > <op name="monitor" interval="60s" id="IPaddr_194_37_40_42_mon" >> > timeout="60s"/> >> > </operations> >> > >> > - it works for me very well ;-) >> >> Mia has reported on this thread that having monitor enabled is not >> enough for reporting problems on the link. >> What do you mean works for you? Have you tried to pull out the network >> cable from an interface on which you have an IPaddr2 resource running? > > - I use the "IPaddr" RA, not IPaddr2. And of course did I test it thoroughly - > succesfully ;-) > You can also use "ifconfig ethx down " to simulate cable pull out ... > >> Does that action cause a failure on the IPaddr2 resource? > > - on IPaddr YES!
I've just done a quick test. Since I don't have physical access on systems, I shutdown the port on the switch and run ping on the IP assigned to the interface, which has NO-CARRIER flag on and flag LOWER_UP was gone. The ping was successful! I am not 100% sure that shut-downing the port on the switch simulates 100% the removal of the cable but I don't think pinging the IP of the interface is the best option for identifying layer1 and layer 2 problems. May be that is the reason the ping functionality is not on IPaddr2. Regards, Pavlos _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
