利用Exadata的Infiniband网络进行数据备份之前,务必先检查当前Exadata环境中Infiniband交换机是什么版本,在比较老的版本中,Infiniband交换机的固件版本存在软件缺陷,有可能会导致整个Infiniband网络全部瘫痪。

如果Infiniband交换机的固件版本比较老,则建议先升级Exadata环境中的Infiniband交换机,然后再来搭建Infiniband备份网络。

下面,分享一个因为搭建Infiniband备份网络导致整个Exadata数据库服务中断的案例。

案例概要:

12月29号上午9点半左右,某Exadata客户的现场工程师实施Exadata数据库备份工作,将介质服务器通过IB网络连接至Exadata内部的IB交换机时,突然,整个数据库集群出现异常,计算节点的主机自动重启。

故障紧急恢复

为了紧急恢复业务,需要尽快修复故障,保障数据库集群能够正常启动。

1、手动启动CRS集群。

手动关闭并重启CRS集群,但集群仍然无法启动,CSS进程无法启动。这种情况通常是由于IB网络心跳或磁盘心跳出现问题。需要进一步检查网络和存储状态。

2、检查计算节点和存储节点的IB网络状态。

关闭所有CRS集群进程,开始检查IB心跳网络,通过ifconfig -a命令检查计算节点的网络情况时发现异常,计算节点的ib0和ib1这两个IB网口没有IP地址信息,而正常情况下,ib0和ib1这两个网口是集群的内联心跳网络,使用内置的IB交换机进行互联。

进一步检查该计算节点/etc/sysconfig/network-scripts目录下,ib0和ib1的网络配置信息,发现这两个网口的配置文件一切正常。

这种情况只能说明IB网络出现异常,为了恢复业务,需要先解决IB网络ib0和ib1这两个网口IP地址的故障。

3、重启计算节点network服务。

使用service network restart命令重启该计算节点的网络服务,网络服务重启完成后,ib0和ib1这两个网口IP地址已经恢复正常。

4、检查IB网络。

在计算节点db01上运行ping命令检查与其他计算节点和存储节点的连通性,发现db01计算节点虽然自身的IB网络已经恢复,但仍然无法ping通其他节点的IB网络地址。这说明整个IB网络仍然存在问题,而整个IB网络仅仅经过了两台IB交换机,节点间的IB网络不通,基本上可以断定就是IB交换机故障,已经无法提供IB网络服务。

5、重启所有节点。

首先,需要重启两台IB交换机,它是该故障的关键,重启完IB交换机后,继续重启存储节点,最后重启计算节点,此时,故障恢复完成。

故障分析:

通过故障紧急恢复的步骤可以看出,重启主机的原因是由于CRS集群间的IB心跳网络出现异常,CRS集群为了保证集群数据的完整性和唯一性,必须将故障节点驱逐出集群,也即自动将主机重启。

整个故障的原因已经非常明显,那就是为什么IB网络会突然无法正常工作,而IB网络的关键点是两台IB交换机,这需要分析IB交换机的相关日志。

1、分析IB交换机的opensm.log日志。

Dec 29 09:34:23 768545 [B76D4B90] 0x01 -> trap_rcv_process_request: Received Generic Notice type:1 num:128 (Link state change) Producer:2 (Switch) from LID:1 (SUN DCS 36P QDR gatsw-ibb01 10.196.10.13) TID:0x000000000000000c Dec 29 09:34:23 768545 [B76D4B90] 0x02 -> osm_report_notice: Reporting Urgent Notice “Link state change” from switch LID 1, GUID 0x0010e06515f1a0a0 Dec 29 09:34:23 797537 [B66D2B90] 0x02 -> __osm_ftree_fabric_dump_general_info: General fabric topology info Dec 29 09:34:23 797537 [B66D2B90] 0x02 -> __osm_ftree_fabric_dump_general_info: ============================ Dec 29 09:34:23 797537 [B66D2B90] 0x02 -> __osm_ftree_fabric_dump_general_info:   – FatTree rank (roots to leaf switches): 1 Dec 29 09:34:23 797537 [B66D2B90] 0x02 -> __osm_ftree_fabric_dump_general_info:   – FatTree max switch rank: 0 Dec 29 09:34:23 797537 [B66D2B90] 0x02 -> __osm_ftree_fabric_dump_general_info:   – Fabric has 6 CAs, 11 CA ports (11 of them CNs), 2 switches Dec 29 09:34:23 797537 [B66D2B90] 0x02 -> __osm_ftree_fabric_dump_general_info:   – Fabric has 2 switches at rank 0 (roots) Dec 29 09:34:23 798536 [B66D2B90] 0x02 -> osm_ucast_mgr_process: ftree tables configured on all switches Dec 29 09:34:23 805534 [B66D2B90] 0x02 -> osm_report_notice: Reporting Informational Notice “GID in service”, GID:fe80::e41d:2d03:e0:1181 Dec 29 09:34:23 805534 [B66D2B90] 0x02 -> state_mgr_report_new_ports: Discovered new port with GUID:0xe41d2d0300e01181 LID range [13,13] of node: Datanode1 mlx4_0 Dec 29 09:34:23 807534 [B66D2B90] 0x02 -> SUBNET UP Dec 29 09:34:23 833526 [B66D2B90] 0x02 -> __osm_ftree_fabric_dump_general_info: General fabric topology info Dec 29 09:34:23 833526 [B66D2B90] 0x02 -> __osm_ftree_fabric_dump_general_info: ============================ Dec 29 09:34:23 833526 [B66D2B90] 0x02 -> __osm_ftree_fabric_dump_general_info:   – FatTree rank (roots to leaf switches): 1 Dec 29 09:34:23 833526 [B66D2B90] 0x02 -> __osm_ftree_fabric_dump_general_info:   – FatTree max switch rank: 0 Dec 29 09:34:23 833526 [B66D2B90] 0x02 -> __osm_ftree_fabric_dump_general_info:   – Fabric has 6 CAs, 11 CA ports (11 of them CNs), 2 switches Dec 29 09:34:23 833526 [B66D2B90] 0x02 -> __osm_ftree_fabric_dump_general_info:   – Fabric has 2 switches at rank 0 (roots) Dec 29 09:34:23 833526 [B66D2B90] 0x02 -> osm_ucast_mgr_process: ftree tables configured on all switches Dec 29 09:34:23 838525 [B66D2B90] 0x02 -> SUBNET UP Dec 29 09:34:23 838525 [B76D4B90] 0x01 -> trap_rcv_process_request: Received Generic Notice type:4 num:144 (CapabilityMask, NodeDescription, Link [Width|Speed] Enabled changed) Producer:1 (Channel Adapter) from LID:13 (Datanode1 mlx4_0) TID:0x0000000000000004 Dec 29 09:34:23 838525 [B76D4B90] 0x02 -> trap_rcv_process_request: Trap 144 Node description update Dec 29 09:34:23 838525 [B76D4B90] 0x02 -> osm_report_notice: Reporting Informational Notice “CapabilityMask, NodeDescription, Link [Width|Speed] Enabled changed” from LID 13, GUID 0xe41d2d0300e01181, ChangeFlags 0x0001 Dec 29 09:34:23 906505 [B66D2B90] 0x02 -> __osm_ftree_fabric_dump_general_info: General fabric topology info Dec 29 09:34:23 906505 [B66D2B90] 0x02 -> __osm_ftree_fabric_dump_general_info: ============================ Dec 29 09:34:23 906505 [B66D2B90] 0x02 -> __osm_ftree_fabric_dump_general_info:   – FatTree rank (roots to leaf switches): 1 Dec 29 09:34:23 906505 [B66D2B90] 0x02 -> __osm_ftree_fabric_dump_general_info:   – FatTree max switch rank: 0 Dec 29 09:34:23 906505 [B66D2B90] 0x02 -> __osm_ftree_fabric_dump_general_info:   – Fabric has 6 CAs, 11 CA ports (11 of them CNs), 2 switches Dec 29 09:34:23 906505 [B66D2B90] 0x02 -> __osm_ftree_fabric_dump_general_info:   – Fabric has 2 switches at rank 0 (roots) Dec 29 09:34:23 906505 [B66D2B90] 0x02 -> osm_ucast_mgr_process: ftree tables configured on all switches Dec 29 09:34:23 911503 [B66D2B90] 0x02 -> SUBNET UP

以上为iba01交换机日志,从以上日志可以看出,备份介质服务器是在9点30分左右接入IB网络,iba01已经识别出整个IB网络。

2、分析IB交换机的操作系统日志。

Iba01操作系统日志:

Dec 29 10:29:46 gatsw-iba01 whereismaster[1806]: Master SubnetManager on sm lid 13 sm guid 0xe41d2d0300e01181 : Datanode1 mlx4_0 Dec 29 10:38:00 gatsw-iba01 whereismaster[1806]: No Master SubnetManager seen in the system Dec 29 10:38:08 gatsw-iba01 whereismaster[1806]: Master SubnetManager on sm lid 2 sm guid 0x10e06515e3a0a0 : SUN DCS 36P QDR gatsw-iba01 10.196.10.12 Dec 29 10:43:32 gatsw-iba01 whereismaster[1806]: Master SubnetManager on sm lid 13 sm guid 0xe41d2d0300e01181 : Datanode1 HCA-1 Dec 29 10:51:47 gatsw-iba01 whereismaster[1806]: No Master SubnetManager seen in the system

Ibb01操作系统日志:

Dec 29 09:33:56 gatsw-ibb01 envd[1653]: Connector  7A present Dec 29 10:29:37 gatsw-ibb01 whereismaster[1799]: Master SubnetManager on sm lid 13 sm guid 0xe41d2d0300e01181 : Datanode1 mlx4_0 Dec 29 10:37:53 gatsw-ibb01 whereismaster[1799]: Master SubnetManager on sm lid 2 sm guid 0x10e06515e3a0a0 : SUN DCS 36P QDR gatsw-iba01 10.196.10.12 Dec 29 10:43:27 gatsw-ibb01 whereismaster[1799]: Master SubnetManager on sm lid 13 sm guid 0xe41d2d0300e01181 : Datanode1 HCA-1 Dec 29 10:51:34 gatsw-ibb01 envd[1653]: Connector  7A not present Dec 29 10:51:43 gatsw-ibb01 whereismaster[1799]: No Master SubnetManager seen in the system

从操作系统日志可以看出,在9点33分,介质服务器接入ibb01这台IB交换机的7a接口,在10点29分,现场同事安装介质服务器的IB卡驱动时,IB网络的master子网管理器自动切换到了新接入的备份介质服务器,然而,继续搜索IB交换机的opensm日志可知,当新接入的备份介质服务器成为master子网管理器时,以前的master子网管理器(iba01)此时并没有进入STANDBY状态,也即此时,整个IB网络存在两个master子网管理器。在10点38分,IB网络的master子网管理器又重新自动切换到了iba01这台IB交换机上,然后在10点43分,再次发现IB网络的master子网管理器又重新自动切换到了新接入的备份介质服务器。

3、继续分析IB交换机的opensm.log日志。

Dec 29 10:33:57 754029 [B5ED1B90] 0x01 -> umad_receiver: ERR 5411: DR SMP Send completed with error — dropping             Method 0x1, Attr 0x15, TID 0xc0198cadf, Hop Ptr: 0x0 Dec 29 10:33:57 754029 [B5ED1B90] 0x01 -> __osm_sm_mad_ctrl_send_err_cb: ERR 3113: SubnGet(PortInfo) completed in error (IB_TIMEOUT): attr_mod 0x0, TID 0x198cadf Dec 29 10:33:57 755029 [B5ED1B90] 0x01 -> umad_receiver: ERR 5411: DR SMP Send completed with error — dropping             Method 0x1, Attr 0x15, TID 0xc0198cae0, Hop Ptr: 0x0 Dec 29 10:33:57 755029 [B5ED1B90] 0x01 -> __osm_sm_mad_ctrl_send_err_cb: ERR 3113: SubnGet(PortInfo) completed in error (IB_TIMEOUT): attr_mod 0x0, TID 0x198cae0 Dec 29 10:33:57 755029 [B5ED1B90] 0x01 -> umad_receiver: ERR 5411: DR SMP Send completed with error — dropping             Method 0x1, Attr 0x15, TID 0xc0198cae4, Hop Ptr: 0x0 Dec 29 10:33:57 755029 [B5ED1B90] 0x01 -> __osm_sm_mad_ctrl_send_err_cb: ERR 3113: SubnGet(PortInfo) completed in error (IB_TIMEOUT): attr_mod 0x0, TID 0x198cae4 Dec 29 10:33:57 755029 [B5ED1B90] 0x01 -> umad_receiver: ERR 5411: DR SMP Send completed with error — dropping             Method 0x1, Attr 0x15, TID 0xc0198cae5, Hop Ptr: 0x0 Dec 29 10:33:57 755029 [B5ED1B90] 0x01 -> __osm_sm_mad_ctrl_send_err_cb: ERR 3113: SubnGet(PortInfo) completed in error (IB_TIMEOUT): attr_mod 0x0, TID 0x198cae5 Dec 29 10:34:06 956337 [B66D2B90] 0x01 -> state_mgr_light_sweep_start: ERR 3315: Unknown remote side for node 0x0010e00001753140 (gatadm02 S 192.168.10.3,192.168.10.4 HCA-1) port 2. Adding to light sweep sampling list Dec 29 10:34:06 956337 [B66D2B90] 0x01 -> state_mgr_light_sweep_start: ERR 3315: Unknown remote side for node 0x0010e000017463b0 (gatadm01 S 192.168.10.1,192.168.10.2 HCA-1) port 2. Adding to light sweep sampling list

从10点33分开始,整个IB网络出现异常,IB交换机的opensm日志已经出现大量IB_TIMEOUT信息。通过以上报错信息,我们可以在ORACLE的文档库中搜索到类似案例。具体见:(IB7) An overloaded subnet manager (SM) master can lead to having multiple SM masters in the network and servers being unable to communicate on the InfiniBand network (Doc ID 2400204.1),在该案例中,临时恢复故障的办法是:先手动重启master IB交换机,然后重启所有IB网络无法通信的主机,最终的解决办法是:升级IB交换机的固件版本。故障原因是:Bug 17482244。

我们在恢复该故障的过程中,同样也是重新启动了所有IB交换机,然后重启所有的存储节点和计算节点,并且断开新接入的备份介质服务器,才成功恢复业务,该措施与上述案例中的临时故障恢复办法基本相同。

下面,我们对整个故障过程进行还原:

1、9点33分,备份介质服务器插入ibb01这台IB交换机,此时的备份介质服务器仅仅在IB卡上配置了网络IP信息,但还未安装IB驱动。

2、10点29分,备份介质服务器IB驱动安装完成,该服务器与整个IB网络正式完成物理的IB连接,同时master子网管理器在新接入的备份介质服务器上运行。但同时,以前的master子网管理器仍然在iba01这台IB交换机上继续运行(因为该IB交换机的opensm日志未显示该IB交换机的opensm服务进入STANDBY状态),此时,整个IB网络中存在两个master子网管理器。

3、紧接着,故障产生,业务人员反馈计算节点没有响应,检查发现,计算节点自动重启(因为CRS集群的IB心跳网络出现故障,CRS集群为了保证集群的完整性和一致性,必须主动地重启操作系统)。

建议:

该IB交换机的固件BUG在2.2.2及以上的版本中进行了修复,建议将IB交换机升级至较新且比较稳定的版本。

深入进行思考,该故障的原因是由于整个Infiniband网络中突然出现了两个master子网管理器,从而导致整个Infiniband网络出现了管理混乱,第1个master子网管理器在iba01这台Infiniband交换机上,而第2个master子网管理器出现在刚刚安装的介质服务器上。

设想一下,如果介质服务器上没有master子网管理器,也许不会触发这个软件缺陷出现,而介质服务器上的master子网管理器是由opensmd服务控制的,由于现场的工程师在安装Infiniband网卡驱动时,启动了opensmd服务,而这个opensmd服务并不是Infiniband网卡驱动必须的服务,所以完全没有必须开启。

最终,我们对客户的Exadata版本进行了升级工作,同时关闭了备份介质服务器上的opensmd服务,再次将备份介质服务器接入Exadata的Infiniband网络,一切正常。

作者 管理员