May 18

[原]Oracle RAC VIP 属性不正确导致丢失网关的问题 雷阵雨

linuxing , 00:13 , 基础知识 » 故障处理 , 评论(1) , 引用(0) , 阅读(15246) , Via 本站原创 | |
    还是之前的项目,在进行Oracle 的切换测试时,当把已经绑定成bond0的两个网卡上的网线都拔掉,发现系统会丢失网关,并增加了一条指向心跳网卡bond1的新路由,必须手动调整才能恢复。经过多方面的排查,最后发现是Oracle RAC 中VIP(浮动IP)属性设置不正确导致的问题,经用srvctl modify nodeapps调整后,问题解决。

一、系统环境
引用
硬件: 4 x IBM x3950 M2 (两台堆叠 8 x Xeon E7420四核(共32个) 64G内存)
操作系统: 红旗 DC Server 5.0 for x86_64 SP2
应用: Oracle RAC 10.2.0.4
外网: 两块 Broadcom 5706 绑定为 bond0
内网心跳: 两块 InfiniBand: Mellanox Technologies MT25204 卡 绑定为 bond1

外网是普通的以太网卡,以标准的ifcfg-bond0 方式,把eth0、eth1绑定成bong0设备;
内网心跳是InfiniBand卡,因系统核心为2.6.9-42.7AXlargesmp,根据The OpenFabrics Alliance上的说明,该核心只能使用OFED-1.4版本。在/etc/rc.local 中,以下面的方式进行绑定:

ib-bond --bond-name bond1 --stop
ib-bond --bond-name bond1 --bond-ip 192.168.1.11/24 --slaves ib0,ib1

※ 注意:
根据OFED-1.4的说明,ib-bond支持ifcfg-bond1的方式绑定,但经测试1.4实际并不支持这种方式,只能以ib-bond命令来实现。
(OFED-1.5支持ifcfg-bond1 方式的绑定,但OFED-1.5必须在DC 5.0 SP3以上运行。)

二、故障现象
进行Oracle RAC 切换测试前,路由表如下:
引用
# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.242.1.0      0.0.0.0         255.255.255.128 U     0      0        0 bond0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 bond1
0.0.0.0         10.242.1.52     0.0.0.0         UG    0      0        0 bond0

把已经绑定成bond0的两个网卡上的网线都拔掉,发现会丢失网关,及增加了一条指向心跳网卡的新路由:
引用
# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.242.1.0      0.0.0.0         255.255.255.128 U     0      0        0 bond1
10.242.1.0      0.0.0.0         255.255.255.128 U     0      0        0 bond0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 bond1

三、问题分析及故障解决
1、临时方法
出现问题后,执行以下命令可临时恢复正常的路由表:

route del -net 10.242.1.0 netmask 255.255.255.128 dev bond1
route add default gw 10.242.1.52

2、驱动问题
根据1.4版本的说明,编辑生成ib-bonding包,安装后会自动替换系统上自带的bonding:
引用
# rpm -ql ib-bonding
/lib/modules/2.6.9-42.7AXlargesmp/updates/kernel/drivers/net/bonding/bonding.ko
/usr/bin/ib-bond
/usr/share/doc/ib-bonding-0.9.0/ib-bonding.txt
# find /lib/modules/2.6.9-42.7AXlargesmp/ -name 'bonding.ko'
/lib/modules/2.6.9-42.7AXlargesmp/kernel/drivers/net/bonding/bonding.ko
/lib/modules/2.6.9-42.7AXlargesmp/updates/kernel/drivers/net/bonding/bonding.ko

# modinfo bonding
filename:       /lib/modules/2.6.9-42.7AXlargesmp/updates/kernel/drivers/net/bonding/bonding.ko
author:         Thomas Davis, tadavis@lbl.gov and many others
description:    Ethernet Channel Bonding Driver, v3.2.3
version:        3.2.3 A55A046AA99EE9DFBE71CAB
license:        GPL
parm:           fail_over_mac:For active-backup, do not set all slaves to the same MAC.  0 of off (default), 1 for on.
parm:           arp_ip_target:arp targets in n.n.n.n form
parm:           arp_interval:arp interval in milliseconds
parm:           xmit_hash_policy:XOR hashing method: 0 for layer 2 (default), 1 for layer 3+4
parm:           lacp_rate:LACPDU tx rate to request from 802.3ad partner (slow/fast)
parm:           primary:Primary network device to use
parm:           mode:Mode of operation : 0 for balance-rr, 1 for active-backup, 2 for balance-xor, 3 for broadcast, 4 for 802.3ad, 5 for balance-tlb, 6 for balance-alb
parm:           use_carrier:Use netif_carrier_ok (vs MII ioctls) in miimon; 0 for off, 1 for on (default)
parm:           downdelay:Delay before considering link down, in milliseconds
parm:           updelay:Delay before considering link up, in milliseconds
parm:           miimon:Link check interval in milliseconds
parm:           num_grat_arp:Number of gratuitous ARP packets to send on failover event
parm:           max_bonds:Max number of bonded devices
depends:
vermagic:       2.6.9-42.7AXlargesmp SMP gcc-3.4

可见,当前核心有两个bonding.ko模块,正在使用的是由ib-bonding包提供的,已经替换kernel 包自带的bonding.ko文件。
因为从故障现象分析,问题应该是断开两外网网卡的网线后,bond0设备所触发的动作,故怀疑与bonding.ko模块有关。手动修改updates目录下的bonding.ko文件,令当前模块恢复kernel 的bonding.ko,重新测试,故障消失。(注意:这时ib-bond不能使用该模块来绑定为bond1)

3、Oracle RAC VIP 属性
由于(1)的方式使用的是kernel 提供的bonding.ko模块,不支持InfiniBand 卡的绑定,所以不能彻底解决问题。后经过仔细的测试和分析,发现Oracle RAC 的VIP属性设置有问题:

$ srvctl modify nodeapps -n gdracdb1 -A 10.242.1.78/255.255.255.128/bond0\/eth0\/eth1

即同时监控bond0、eth0、eth1。
后修改为:
$ srvctl modify nodeapps -n gdracdb1 -A 10.242.1.78/255.255.255.128/bond0

再进行拔网线的测试,问题彻底解决。
综合分析,bonding.ko模块只是一个更新,并不是根源,Oracle RAC VIP 的属性才是导致故障的根本原因。

三、遗留问题
测试时发现,使用OFED-1.4(包括1.5)提供的bonding.ko模块,虽可支持以太网设备:
引用
# ib-bond --status-all
bond0: e4:1f:13:1e:2a:1c 10.242.1.78/25
slave0: eth0
slave1: eth1 *
bond1: 80:00:04:04:fe:80:00:00:00:00:00:00:00:02:c9:02:00:29:99:75 192.168.1.11/24
slave0: ib0 *
slave1: ib1

但是,当重启网络服务时,不会自动重新激活bondx设备的子网卡:

# service network restart

日志显示:
引用
May 18 00:18:44 gdracdb1 network: 设置网络参数: succeeded
May 18 00:18:44 gdracdb1 kernel: ip_tables: (C) 2000-2002 Netfilter core team
May 18 00:18:43 gdracdb1 network: 正在关闭接口 bond0: succeeded
May 18 00:18:43 gdracdb1 network: 正在关闭接口 eth0: succeeded
May 18 00:18:43 gdracdb1 network: 正在关闭接口 eth1: succeeded
May 18 00:18:44 gdracdb1 network: 关闭环回接口: succeeded
May 18 00:18:44 gdracdb1 network: 弹出环回接口: succeeded
May 18 00:18:44 gdracdb1 kernel: bonding: bond0: link status definitely down for interface eth0, disabling it
May 18 00:18:44 gdracdb1 kernel: bonding: bond0: link status definitely down for interface eth1, disabling it
May 18 00:18:44 gdracdb1 kernel: bonding: bond0: now running without any active interface !

May 18 00:18:44 gdracdb1 kernel: ip_tables: (C) 2000-2002 Netfilter core team
May 18 00:18:48 gdracdb1 ifup: 将 eth0 归属于 bond0
May 18 00:18:48 gdracdb1 ifup: 将 eth1 归属于 bond0
May 18 00:18:48 gdracdb1 network: 弹出界面 bond0: succeeded

这时,eth0、eth1网卡不会自动激活:
引用
# ethtool eth0|grep Link
        Link detected: no
# ethtool eth1|grep Link
        Link detected: no

必须手动启动:

# ifconfig eth0 up; ifconfig eth1 up

日志显示:
引用
May 18 00:19:26 gdracdb1 kernel: bnx2: eth0: using MSI
May 18 00:19:26 gdracdb1 kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
May 18 00:19:28 gdracdb1 kernel: bnx2: eth0 NIC Copper Link is Up, 1000 Mbps full duplex
May 18 00:19:28 gdracdb1 kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
May 18 00:19:28 gdracdb1 kernel: bonding: bond0: link status definitely up for interface eth0.
May 18 00:19:28 gdracdb1 kernel: bonding: bond0: making interface eth0 the new active one.
May 18 00:19:28 gdracdb1 kernel: bonding: bond0: first active interface up!

May 18 00:19:28 gdracdb1 kernel: bnx2: eth1: using MSI
May 18 00:19:28 gdracdb1 kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready
May 18 00:19:31 gdracdb1 kernel: bnx2: eth1 NIC Copper Link is Up, 1000 Mbps full duplex
May 18 00:19:31 gdracdb1 kernel: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
May 18 00:19:31 gdracdb1 kernel: bonding: bond0: link status definitely up for interface eth1.

网卡状态:
引用
# ethtool eth0|grep Link
        Link detected: yes
# ethtool eth1|grep Link
        Link detected: yes

该问题,暂时没有找到彻底的解决办法,只能手动激活网卡。
Tags: ,
博爱老头 Homepage
2010/05/22 20:34
哈哈。。。又见红旗!
分页: 1/1 第一页 1 最后页
发表评论
表情
emotemotemotemotemot
emotemotemotemotemot
emotemotemotemotemot
emotemotemotemotemot
emotemotemotemotemot
打开HTML
打开UBB
打开表情
隐藏
记住我
昵称   密码   游客无需密码
网址   电邮   [注册]