网站建设资讯

NEWS

网站建设资讯

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

最近有朋友和小 y 反馈:

创新互联公司长期为成百上千家客户提供的网站建设服务,团队从业经验10年,关注不同地域、不同群体,并针对不同对象提供差异化的产品和服务;打造开放共赢平台,与合作伙伴共同营造健康的互联网生态环境。为石嘴山企业提供专业的网站建设、网站设计石嘴山网站改版等技术服务。拥有10年丰富建站经验和众多成功案例,为您定制开发。

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

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

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

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

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

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

问题来了!!

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

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

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

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

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

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

 

BTW:

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

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

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

分析与恢复故障

验证节点2无法启动

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


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


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

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

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


如下图所示:


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


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


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

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


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


可以看到:

由于节点 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 地址如下所示:

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

也就是说, 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 通讯使用

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

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

 

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

从上图可以看到:

两个节点之间互相 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 上的私网路由丢失,导致两个节点之间的私网无法正常通讯,继而无法正常加入集群。

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

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

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

暂时解决问题

在节点 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)

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

风险提示

风险提示

在部署了 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

 

本文转载于中亦安图


网页题目:这么用X86,小心ORACLE+RAC中招--技术人生系列第四十一期-我和数据中心的故事
URL标题:http://njwzjz.com/article/gejdii.html