千家信息网

这么用X86,小心ORACLE+RAC中招--技术人生系列第四十一期-我和数据中心的故事

发表于:2024-11-29 作者:千家信息网编辑
千家信息网最后更新 2024年11月29日,最近有朋友和小 y 反馈:他们的一台 IBM 的 X86 服务器(现在属于联想)出现硬件损坏,维护人员通过管理口收集诊断日志给厂商时,服务器上运行的好好的一套 ORACLE 11.2 的 RAC 数据
千家信息网最后更新 2024年11月29日这么用X86,小心ORACLE+RAC中招--技术人生系列第四十一期-我和数据中心的故事

最近有朋友和小 y 反馈:

他们的一台 IBM X86 服务器(现在属于联想)出现硬件损坏,维护人员通过管理口收集诊断日志给厂商时,服务器上运行的好好的一套 ORACLE 11.2 RAC 数据库,

突然有一个节点重启了 .. 这是是什么情况 ?


听到这里,小 y 基本上猜到了原因,类似的问题,以前分析和处理过几次,分析过程也不复杂, 但是没想到,类似的故障现在居然还在发生 .


因此有必要把这个 风险提示出来 !

这里,小 y 为大家分享一个过去处理的案例 , 文章最后会给出 X86 服务器与 RAC 结合的具体的风险提示,希望大家早了解,早预防,避免踩坑,伤人伤己。


问题来了!!

周五,晚上十一点,电话响了,是一位服务商的电话,看来出大事了,一下来了精神;

"小y,一套linux上的11.2.0.3 2节点的RAC,

节点2数据库今天下午自己重启了一次,后来自己起来了。

几个小时前,又挂了,到现在还没起来!

两个节点私网IP互相ping了一下,可以ping通!

你赶紧远程连上来处理下吧"

BTW:

是的,大家没看错,是服务商而不是最终客户的电话。

小y所在的公司不仅直接面向客户提供数据库专家服务,也为其他服务商、软件开发商提供三线支持,不过小y最近业绩压力大的晚上睡不着觉,还请各位兄弟多多帮忙推荐和介绍啊。


分析与恢复故障


验证节点2无法启动

时间紧急,远程连入后,发现节点 2 确实挂掉了,那就直接 startup 启动数据库看看



照理来说,startup命令下去后,这里很快就可以看到SGA分配并启动到mount的信息,

但命令下去已经一分钟了,还没任何输出,确实不妙。

最终,startup命令在敲入后长时间依然无响应,大概10分钟后后报ORA-03113错误后退出。


如下图所示:



看来,数据库启动过程中遇到了异常,需要继续分析alert日志。


检查节点2数据库的alert日志

截取altert日志关键信息,如下图所示:



可以看到:

由于节点 2 Lmon 进程通过 ipc 与节点 1 LMON 进程通讯超时,简单来说,两个节点的 RAC 无法通讯,因此无法加入集群。因此需要进一步检查两个节点的私网通讯是否正常。


获取两个节点私网通讯的IP地址

之前他们提到两个节点的私网 IP 是可以 ping 通的,我估计他们是 ping IP 了。

因为,从 11.2.0.2 (含)开始, ORACLE 私网通讯不再直接采用"我们在私网网卡上所配置的地址(例如 192.168 这样的地址)",而是采用 GRID 启动后, ORACLE 在私网网卡上绑定的 169.254 这个网段的地址。确认了一下,他们果然 ping 的是 192.168 这个 IP ,这个 IP PING 通是不够的


发出下列命令获得,两个节点私网通讯采用的 IP 地址如下所示:



也就是说, RAC 两个节点用于私网通讯的真实地址是:

节点 1 采用的私网通讯地址是 169.254.220.75 ,而不是 192.168.x.x

节点 2 采用的私网通讯地址是 169.254.106.133 ,而不是 192.168.x.x


也就是说, GRID 启动前后的 IP ,如下所示:


Node1

Node2

备注

Bond0

192.168.1.1

192.168.1.2

GRID 启动前、启动后都存在的 IP

Bond0:1

169.254.220.75

169.254.106.133

GRID 启动后才存在的 IP

RAC ASM 通讯使用


检查两个节点私网通讯是否正常




从上图可以看到:

两个节点之间互相 ping 不通 169.254 这个实际的私网通讯地址!这就是为什么节点 2 的数据库实例加不到集群的原因!


思考时间

到这里,我们不妨用一张表表格小结一下:

其中 bond0 是私网网卡, 192.168 是手工配置的, 169.254 这个 IP GRID 起来后绑上去的:



Node1

Node2


Bond0

192.168.1.1

192.168.1.2

可以互相 ping

Bond0:1

169.254.220.75

169.254.106.133

互相 ping 不通


这是什么情况呢?

其实很简单,别着急,问题原因就在后面,什么时候往下翻,由你决定…

……

……

……

……

……

……

……

……

……

……

……

……

……

……

……

……


那是什么原因导致两个地址不通呢?

我们进一步检查两个节点的路由情况,发现了异常。如下所示

检查,发现节点 1 上的私网路由丢失,导致两个节点之间的私网无法正常通讯,继而无法正常加入集群。

而节点 2 上是存在 169.254 这个路由的!


暂时解决问题

在节点 1

#route add -net 169.254.0.0 netmask 255.255.0.0 dev bond1

在节点 1 上实施该解决方案后,节点 2 数据库实例启动正常,问题得到解决。

到这里,有同学说, 可以不可以把两个节点的 GRID 全部停掉,全部重启来恢复呢 ?

答案是 yes !

因为重启 GRID ,会重新在 bond0 169.254 这个 IP ,同时添加 169.254.0.0 这个路由

2016-06-02 23:05:47.457:

[crsd(10403)]CRS-2772:Server 'node2' has been assigned to pool 'ora.RACDB'.

2016-06-03 19:36:48.517:

[/oracle/app/11.2.0.3/grid/bin/orarootagent.bin(8641)]CRS-5018:(:CLSN00037:)

1) 19:36:25, 节点 1 USB0 网卡被分配 169.254.95.120 这个 IP

2) 19:36:48, 节点 1 orarootagent 进程发现 USB0 上分配的 169.254 IP RAC 集群通讯的 IP 冲突后删除 169.254 的路由 ,导致两个节点 RAC 无法通讯

3) 19:41:24, 节点 2 IPC 通讯超时,被驱逐出集群

4) 由于节点 1 169.254 的路由丢失,导致节点 2 无法与节点 1 通讯,一直无法加入集群

5) 手工对节点 1 增加 169.254 的路由后,问题解决


不难看出来,这个行为是正常的行为!

我们以" Removed unused HAIProute: 169.254.95.0 "作为搜索关键字,在 METALINK 上查找, MOS 上的下面文章也介绍了这个行为,推测得到验证。

Oracle RAC H/A Failure Causes Oracle Linux Node Eviction On Server With IBM Integrated Management Module (IMM) (文档 ID 1629814.1)



风险提示

风险提示

在部署了 ORACLE11.2.0.2 或以上的版本中

由于集群的 ASM DB 使用 169.254.x.x 作为集群私网通讯的 IP

GRID 启动后在私网网卡绑定 169.254.x.x 这个 IP 并添加 169.254.0.0 的路由】

目前已知的情况中, IBM X86 服务器装完操作系统后,存在 USB0 这样一块网卡,这个网卡是用来和 IMM 通讯的, IMM 是服务器的管理口,通过 USB 网络的 LAN 进行硬件管理。

USB0 网卡被激活时,将分配 169.265.95.120 118 )这个 IP ,将导致 RAC 集群路由被破坏,继而导致 DB/ASM 无法通讯而重启 / 节点驱逐的故障 ,

#cat /var/log/messages*|grep dhclient |grep "bound to 169.254"

如有,则进入预防环节

2 发出下列命令,检查系统是否当前存在非 RAC 私有网卡被分配 169.254 这个网段的 IP

# ifconfig -a

..

usb0 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX

# vi

# /sbin/ifdown usb0

# /sbin/ifup usb0

# /sbin/ifconfig usb0

本文转载于中亦安图

0