lan card failover

[Gabriel_23]

I am testing my lan card failover... however when I down the primary lan card interface, the node crash and reboot...and the package on this node fails over to the other node. I don't believe this should happen, if I have a secondary lan card in place. I have made a call to hp also to investigate. Not sure why this is happening.

[John Poff]

Hi,

It sounds like your LAN may not be configured correctly, and your cluster is splitting into two separate nodes when you down the primary LAN card. If that happens, they will use the cluster lock disk to split the tie and the loser will TOC to allow the other node to pick up any applications running on the losing node.

Maybe if you can post some details about your LAN configuration we can see what is happening.

JP

[Sundar_7]

Post the output of

# cmviewconf

and cmviewcl -v command

This could happen

1) if only primary lan card is deginated to handle the heartbeat traffic
2) If the secondary lan card is not configured as the standby lan card for the primary.

cmviewcl -v will tell you the lan card configuration.

Make sure you dont list your secondary lan card in /etc/rc.config.d/netconf file.

[Stephen Doud]

- ifconfig lanX down is NOT a legitimate method to test LAN failure-failover

- pulling the LAN cable is a legitimate test method

To verify that Serviceguard will use the standby NIC that you expect it to, use
# cmviewconf | more

...inspect the LANs on each server to verify the intended standby LAN NIC is on the SAME bridged network as the primary NIC. Example:

Network ID 1:
ppa: 0
old_ppa: 0
mac addr: 0x080009306436
hardware path: 24.1
network interface name: lan0
subnet: 16.113.0.0
subnet mask: 255.255.192.0
ip address: 16.113.9.254
flags: 1 (Heartbeat Network)
bridged net ID: 1

Network ID 2:
ppa: 1
old_ppa: 0
mac addr: 0x0060b05616c0
hardware path: 56.1
network interface name: lan1
subnet: 0.0.0.0
subnet mask: 0.0.0.0
ip address: 0.0.0.0
flags: 0 (Non-Heartbeat Network)
bridged net ID: 1

Note in this example the "bridged net ID" is the same. Also note that the second LAN has NO IP and a 0 subnet mask.

The cluster binary file from which this information is extracted is only good if the network configuration has not changed since the binary was created with a "cmapplyconf".
To determine if it has, use
# cmquerycl -C cluster.ascii -n -n ...

Inspect cluster.ascii, looking at the comments placed below each node section. These comments reveal what Serviceguard now sees for network relationships.

-sd.