利用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网络，一切正常。