Exadata上个性需求的反面案例

很多技术控非常喜欢对自己运维的系统进行一些个性定制设计,但对Exadata而言,如果你对它不是特别的理解,一些个性化设置,往往很可能会带来一些不可预知的后果。所以ORACLE一再地强调:”Exadata上的存储节点,不允许进行任何的修改工作”。

不允许对存储节点进行任何的修改工作,这其实是夸张了点,一些简单的修改还是可以的,但ORACLE不确定客户会在存储节点上做些什么修改操作,而存储节点又是Exadata上至关重要的一个组成部分,一旦修改不慎,则可能会导致无法挽回的地步,所以ORACLE就干脆一棒子打死,明确不允许对存储节点进行任何的修改。

下面,我们通过两个案例,来加深理解Exadata上的个性需求有可能会带来的负面影响。

案例1

我们的一个客户,在QQ里给我发了条消息:”**,我们有一个存储节点报了个RS-7445的错,快帮我们看看吧。”跟客户寒暄了几句后,开始了对这个问题的分析。

首先,检查该存储节点存储管理软件的alert日志,发现如下错误:

从存储管理软件的alert日志可以看出,RS_MAIN服务hang住。RS_MAIN服务会派生出来多个监控子进程,它主要负责监控MS或者cellsrv等其他一些进程,所以RS_MAIN需要定期地与MS进程进行通信。

从以上日志可以看出,该存储节点的RS_MAIN服务一共出现过两次hang的情况,并且这两次故障相隔了好几天时间,且这个故障不是连续发生。

首先,我怀疑是否当时存储节点的某项资源耗尽,导致进程间短时间内无法通信?

于是,检查了故障发生时刻的系统资源使用情况,如下是系统CPU和IO资源的使用情况,可以看出,在出现故障时,系统的CPU和IO都相对非常空闲的。

除此之外,我还检查了系统内存的使用情况,未发现有内存资源紧张和cellsrv进程的内存泄露出现。

经过这次检查,基本可以排除是操作系统资源耗尽导致进程间无法通信。

搜索MOS,未找到有价值的信息,没办法,我再次联系客户的技术人员,询问他们最近有没有对存储节点做什么操作?想尽可能地了解多些信息。客户立刻反馈:他们在存储节点上配置了iptables(防火墙),禁用了一些端口。此时,我非常怀疑就是配置的防火墙导致的这个故障,毕竟这套系统从来没出现过这个故障,他们配置完防火墙,没几天就出现了这个故障。

建议客户尽快回退了防火墙配置工作,并进一步跟客户强调:存储节点不允许做任何个性化定制修改操作。经过一周多的观察,该故障再未出现过,说明就是防火墙导致了存储节点的进程间无法通信。

虽然我判断就是防火墙导致了存储节点的进程间无法通信,但是我还是不清楚中间的细节,抱着对技术的渴望,我开了个SR,想从原厂那里了解更多的信息,最终这个SR辗转到了Exadata开发小组,开发人员从我提供的sundiag日志中发现了iptables.out文件的异常,里面多了一条规则:

而sysctl-a的输出显示为:

从sysctl –a的输出可以看出:1521端口可以被系统选择为一个短暂的通信端口,而如果1521端口被选择作为存储软件进程间的通信端口时,而防火墙禁用了这个端口,就会导致进程间的通信超时。开发人员给的workaround就是要么去掉这条防火墙规则,要么将1521端口加入到ipv4.ip_local_reserved_ports中。

至此,我心里只有感叹,开发人员还是牛掰。原理了解得越透彻,解决问题的思路就越多。

案例2

有一天,某个Exadata客户,反映他们计算节点上,eth1和eth2网口bond成的bondeth0没有IP信息了,导致业务中断。我的第一反应就是问客户,第该计算节点做了什么改动?因为正常情况下,是不可能出现这种情况的。客户反馈的信息是刚刚在上面配置了yum源,并且安装xwindow,之后就出现这个问题了。

非常巧合的是,这几天我在虚拟机OEL6.6环境下配置bond时,死活不成功。现象是:bond生成的网卡没有最终的IP信息,但两个子网卡都是UP状态。这让我非常费解,以前在OEL5环境下可重没遇到这个事。后来google了一番,因为是NetworkManager服务在作祟,将该服务disable掉,并关闭该服务,问题解决。

向客户了解得知,他们当前的存储软件版本为:12.1.2.1.1,这也就说明了他们操作系统的版本为OEL6。

于是,我再让客户收集如下信息:

看到这个信息,我已经非常肯定问题出至哪里。由于客户用yum安装了xwindow,间接地安装了NetworkManager服务,并将NetworkManager服务激活,从而导致了bond配置无法生效。

下面,我还是用我的虚拟机模拟这一故障吧:

(1).网口配置信息:

以上是bond的配置信息,eth1和eth2做成bondeth0,主备模式,最终的IP为:10.0.0.100

(2).ifconfig信息:

从ifconfig命令的输出可以看出,当前的bond是生效的。

(3).服务状态:

当前的NetworkManager服务已经关闭了随操作系统自启动,同时该服务是关闭状态。

(4).修改服务状态,模拟故障:

将NetworkManager服务修改为随操作系统自启动,同时启动该服务,并重启网络服务。

(5).检查当前bond状态:

重启完网络服务后,通过ifconfig命令可以看出,bond配置未生效,成功地再现了故障。


未经允许不得转载:Oracle一体机用户组 » Exadata上个性需求的反面案例

相关推荐