作者:刘建军 Exadata 是目前运行Oracle 数据库最好的平台,而Infiniband 网络则是其中最重要的一个部分。Infiniband 是Oracle RAC 数据库节点间的通讯网络,为RAC的cache fusion 及信息传输提供了一个低延时、高带宽的网络;同时也是数据库节点和存储之间的高速IO 通路。Infiniband 网络的性能和可靠性,直接影响了Exadata上运行的数据库的性能和功能。 Infiniband network 构成及其架构Exadata X-2类型的数据库机器,Infiniband网络主要包括Infiniband交换机和服务器上的Infiniband 网卡。每个服务器节点(包括计算节点,存储节点) 配置一块双口(4X QDR 40Gb/s PCIe 3.0) Infiniband 网卡;每个机柜两台Infiniband 交换机(Sun Datacenter 36-port Managed QDR)、每个节点的2个端口(active-active bonding),通过Infiniband 网线,分别和两台叶子交换机相连。交换机运行subnet manager , 并自动检测网络的topology,在整个连接入的Infiniband网络中,只有一个active的subnet manager。 交换机之间有7条直连线,实现交换机之间的数据通讯。以X-2满配为例,连接方式如下:
微信图片_20170406113340.jpg 当多个机柜相连时,通常每个机柜增加第三个Infiniband 交换机(spine switch),采用“Fat Tree” Topology实现机柜互联。根据机柜的个数,从叶子交换机的互联线中,移出一定数量的Infiniband 线,连接到spine 交换机。以两机柜互联为例(1/4配两机柜互联方式为特例,无需第三台交换机),连接方式如下:
微信图片_20170406113433.bmp Infiniband 是通过光来传输数据的,因此对各个部件的连接,网线的走线,有比较严格的要求,弯曲度过大,transceiver安装不好,都有可能导致传输错误或导致性能下降,甚至导致RAC节点或存储节点不工作。Exadata上常见Infiniband 网络诊断工具及其作用Exadata 中有很多用于检查和诊断Infiniband 网络的性能和功能的工具,常见如下: 1.网络拓扑检查verify-topology - 检查Infiniband 网络的topology, 并能返回各项连接是否成功 ibnetdiscover - 返回每个交换机各个端口连接节点 ibswitches - 返回整个网络中的交换机信息 ibhosts – 返回整个光纤网络中的服务器卡、端口、IP、主机名信息 iblinkinfo - report link info for all links in the fabric,返回整个网络中每个节点的每个端口连接的交换机,连接的状态及波特率信息 2.IB网卡、端口检查lspci |grep -i Infiniband - 返回Infiniband 网卡厂商,型号 ibv_devices - 列出系统中有RDMA能力的设备,在exadata 中为infinbiband 网卡,包含设备名称及GUID ibv_devinfo -返回系统中RDMA 能力设备的详细信息,在exadata中为Infiniband 卡、端口的信息及其状态。 mstflint -d mlx4_0 q - 返回Infiniband 网卡的firmware的版本 ibstat -列出Infiniband 网卡端口及其状态等基本信息 ibstatus 主要返回Infiniband 两个端口的状态,连接状态及运行速率 3.ib交换机检查Version – 返回交换机firmware 版本、序列号 env_test – Oracle Infiniband 交换机环境自诊断 Listlinkup –列出交换机上每个端口及其连接状态 setsmpriority list – 显示SM 优先级、handover 状态、subnet prefix and M_Key等信息 Getmaster – 新式subnet manager master 角色信息 4.综合检查工具perfquery - 查询端口的传输计数,包括一些传输的数据、包的计数和传输错误的计数次数 ibcheckerrors - 检查所有端口的报错情况 ibqueryerrors - 缺省报告报错计数超过阀值的端口及其连接情况 ibdiagnet - 扫描整个Infiniband 网络,提取所有连接、设备的信息。 ibdiagpath - 跟踪节点端口间端到端往返访问路径 ibdump - 类似于tcpdump 工具,捕获Infiniband 上传输的package,该工具需要从Mellanox 公司网站下载 Exadata 上Infiniband 故障案例分析案例分析数据来源于实际环境,但分析过程做了较大简化,主要提供分析示例和思路。 故障现象一台新部署的exadata,在通过rman 恢复的方式迁移数据的过程中,其中一个数据库节点重启,导致数据恢复中断。 系统环境:该系统为多个Exadata机柜互联。数据库版本RAC11.2.0.4,存储软件的image 版本为12.1.2.3.2。 故障分析分析主要分两大块: 数据库层面分析,确定故障可能由Infiniband 网络引起,然后针对Infiniband 网络进行检查、分析。分析步骤如下: A. 首先按常规RAC数据库重启问题检查检查OS messages、ExaWatcher 监控数据、cluster alert log、cssd log、diskmon log,分析节点重启的发起者 - 检查重起节点OS message,日志中重启前时间段没有报错,也没有重启发起程序信息
- 重启节点的GI alert.log,看到该节点diskmon 失败
- 查看GI cssd 日志,可以看到cssd 终止,且vote disk offline
- 从另一个节点的alert 日志中,可以看到和节点1的通讯失败,超过misscount之后,建议重启节点1
...... [cssd(81387)]CRS-1610:Network communication with node xxxxdb01 (1) missing for 90% of timeout interval. Removal of this node from cluster in 5.690 seconds 2016-10-04 05:38:56.434: [ohasd(56258)]CRS-8011:reboot advisory message from host: xxxxdb01, component: cssagent, with time stamp: L-2016-10-04-05:38:56.434 [ohasd(56258)]CRS-8013:reboot advisory message text: Rebooting after limit 57960 exceeded; disk timeout 57960, network timeout 57510, last heartbeat from CSSD at epoch seconds 1475530678.425, 58000 milliseconds ago based on invariant clock value of 131639354 2016-10-04 05:38:58.878: [cssd(81387)]CRS-1601:CSSD Reconfiguration complete. Active nodes are xxxxdb02 xxxxdb03 xxxxdb04 xxxxdb05 xxxxdb06 . - 从ExaWatcher 的输出看,当时的数据库负载并不高,资源充足。
从以上的分析看,节点1和其它节点的私网(Infiniband) 网络通讯存在问题,且(通过Infiniband)访问存储也存在问题,导致votedisk offline。由于负载较低,可以排除由于资源问题引起的节点间通讯问题。因此重点分析Infiniband 网络。
B. 分析IB 网络是否存在故障- 运行exachk, 综合检查exadata 是否存在硬件、配置故障,Exachk 报告中Infiniband 部分,检测出交换机(GUID 0x10e0b44ed8a0a0)SymbolErrorCounter 计数值很高。
GUID 0x10e0b44ed8a0a0 port ALL: [SymbolErrorCounter ==26] [PortRcvErrors == 25] [PortRcvRemotePhysicalErrors ==19] [PortRcvSwitchRelayErrors == 573] VL15Dropped == 2 GUID 0x10e0b44ed8a0a0 port 13: SymbolErrorCounter == 3 [VL15Dropped == 2] [PortXmitWait ==29795265] GUID 0x10e0b44ed8a0a0 port 18: SymbolErrorCounter == 23 [PortXmitWait == 29957014] GUID 0x10e0b44ecaa0a0 port ALL: PortRcvErrors == 5[PortRcvSwitchRelayErrors == 2823] [PortXmitWait ==85092986] GUID 0x10e0b44ecaa0a0 port 9: PortRcvErrors == 1 [PortXmitWait == 7814010] ...... 确定对应的交换机 # ibswitches |grep '10e0b44ed8a0a0' Switch : 0x0010e0b44ed8a0a0 ports 36 "SUN DCS 36P QDR xxxxsw-ib3 xx.xx.xx.xxx" enhanced port 0 lid 171 lmc 0
对应交换机为switch "xxxxsw-ib3 xx.xx.xx.xxx",其端口13, 18 报SymbolErrorCounter较多。
为确认问题,进一步详细检查Infiniband 网络各个部件,重点检查xxxxsw-ib3交换机 (1) 检查是否有端口被disable # listlinkup Connector 0A Not present Connector 1A Not present Connector 2A Not present Connector 3A Present <-> Switch Port 26 is up (Enabled) Connector 4A Present <-> Switch Port 28 is up (Enabled) Connector 5A Present <-> Switch Port 30 is up (Enabled) Connector 6A Present <-> Switch Port 35 is up (Enabled) Connector 7A Present <-> Switch Port 33 is up (Enabled) ...... Connector 6B Present <-> Switch Port 36 is down (AutomaticHighErrorRate) <<<<< Connector 7B Present <-> Switch Port 34 is up (Enabled) Connector 8B Present <-> Switch Port 32 is up (Enabled) ......
(2)关闭自动disable, 且enable disabled 的端口port 6B #autodisable none #enableswitchport 6B
(3)连接到所有的Infiniband switch, 确认所有的infiband switches接入网线的端口都是up #listlinkup
(4)清除错误及计数 # ibclearerrors # ibclearcounters
(5)确认错误已全部清零,主要是SymbolErrorCounter # ibcheckerrors
(6)运行ibdiagnet, 给 Infiniband 网络加一定压力 # ibdiagnet -c 500 -pm
(7)再次检查报错情况 # ibqueryerrors -rR -s PortRcvSwitchRelayErrors, PortXmitDiscards, PortXmitWait, Rcv SwRelayErrors,XmtDiscards,XmtWait,VL15Dropped
C 问题解决再次查发现,多个switch上的多个端口存在SymbolErrorCounter增长,至此基本确认为硬件问题。首先怀疑是安装连接的不好,将报错的port对应的transceiver重新接好,重复上面的检查过程,发现大部分端口不再报错,有少数端口仍旧报错,后来通过替换transceiver、替换cable,最终所有的端口都不再报错,再次启动恢复过程,数据库运行稳定,恢复过程成功完成。 总结Infiniband 网络是Exadata的重要部件,其故障可能引起系统性能下降甚至不工作。做Infiniband 网络故障的诊断之前,需要通过Exawatcher 等工具,排除OS层面的资源缺乏导致的通讯故障。然后通过Exadata(OS) 提供的工具确认各个部件的状态,清除当前的报错,再监控网络报错定位故障网卡,交换机,网线等。
|