文档章节

Exadata上个性需求的反面案例

Oracle一体机用户组
 Oracle一体机用户组
发布于 2017/06/21 17:39
字数 2954
阅读 21
收藏 0

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

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

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

案例1

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

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

 

Fri Sep 11 17:46:30 2015

.....(略......)

Fri Sep 11 17:46:32 2015

[RS] Stopped Service RS_MAIN

Errors in file /opt/oracle/cell/log/diag/asm/cell/dm01celadm01/trace/rstrc_2429_smt.trc (incident=9):

RS-7445 [Serv RS_MAIN hang detected] [It will be restarted] [] [] [] [] [] [] [] [] [] []

Incident details in: /opt/oracle/cell/log/diag/asm/cell/dm01celadm01/incident/incdir_9/rstrc_2429_smt_i9.trc

Fri Sep 11 17:46:34 2015

Sweep [inc][9]: completed

[RS] Detected service hang. Increasing heartbeat timeout to 8 seconds.

Fri Sep 11 17:46:34 2015

[RS] Previously detected 1 hang(s). Using heartbeat timeout of 8 seconds.

.....(略......)

Fri Sep 11 17:51:33 2015

RemoteSendPort has been closed due to inactivity, host dm01celadm01[pid:2426]

Mon Sep 14 01:14:06 2015

.....(略......)

[RS] Stopped Service RS_MAIN

Errors in file /opt/oracle/cell/log/diag/asm/cell/dm01celadm01/trace/rstrc_2429_smt.trc (incident=10):

RS-7445 [Serv RS_MAIN hang detected] [It will be restarted] [] [] [] [] [] [] [] [] [] []

Incident details in: /opt/oracle/cell/log/diag/asm/cell/dm01celadm01/incident/incdir_10/rstrc_2429_smt_i10.trc

Sweep [inc][10]: completed

[RS] Detected service hang. Increasing heartbeat timeout to 10 seconds.

Mon Sep 14 01:14:08 2015

[RS] Previously detected 2 hang(s). Using heartbeat timeout of 10 seconds.

[RS] Started monitoring process /opt/oracle/cell/cellsrv/bin/cellrssmt with pid 19857

Mon Sep 14 01:14:08 2015

RS version=12.1.2.1.2,label=OSS_12.1.2.1.2_LINUX.X64_150617.1,Wed_Jun_17_18:20:48_PDT_2015

[RS] Previously detected 2 hang(s). Using heartbeat timeout of 10 seconds.

[RS] Started Service RS_MAIN with pid 19858

[RS] Kill previous monitoring processes for RS_BACKUP, MS and CELLSRV

Mon Sep 14 01:14:08 2015

[RS] Previously detected 2 hang(s). Using heartbeat timeout of 10 seconds.

Mon Sep 14 01:14:08 2015

[RS] Previously detected 2 hang(s). Using heartbeat timeout of 10 seconds.

.....(略......)

Mon Sep 14 01:19:07 2015

RemoteSendPort has been closed due to inactivity, host dm01celadm01.800best.com[pid:14800]

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

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

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

09/14/15 01:15:34

avg-cpu: %user %nice %system %iowait %steal %idle

2.03 0.01 1.34 9.79 0.00 86.83

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util

nvme0n1 0.00 0.00 32.00 1129.40 531.20 75526.40 65.49 0.02 0.02 0.02 2.12

nvme1n1 0.00 0.00 29.60 1201.40 476.80 80657.60 65.91 0.03 0.02 0.02 2.66

nvme2n1 0.00 0.00 37.40 1188.60 604.80 80123.20 65.85 0.03 0.02 0.02 2.76

nvme3n1 0.00 0.00 32.60 1118.20 534.40 75284.80 65.88 0.03 0.02 0.02 2.52

sdb 0.00 9.00 41.80 378.60 9460.80 20724.80 71.80 0.99 1.77 1.22 51.46

sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

sdb2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

sdb3 0.00 0.00 41.00 373.60 9324.80 20585.60 72.14 0.72 1.67 1.17 48.66

sdb4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

sdb5 0.00 3.60 0.00 2.00 0.00 72.00 36.00 0.00 0.00 0.00 0.00

sdb6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

sdb7 0.00 1.60 0.80 0.80 136.00 19.20 97.00 0.05 32.00 32.00 5.12

sdb8 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

sdb9 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

sdb10 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

sdb11 0.00 3.80 0.00 2.20 0.00 48.00 21.82 0.22 0.36 100.18 22.04

sdl 0.00 0.00 41.40 503.20 9420.80 28784.00 70.15 1.02 1.88 0.36 19.76

sdd 0.00 0.00 61.20 466.40 13926.40 27948.80 79.37 1.13 2.14 0.49 25.64

sdi 0.00 0.00 67.20 541.00 15276.80 32244.40 78.13 2.25 3.69 0.99 60.44

sdh 0.00 0.00 56.40 415.00 12841.60 24387.20 78.97 2.63 5.54 1.29 60.60

sdj 0.00 0.00 74.00 448.60 16819.20 26172.80 82.27 2.06 3.93 0.76 39.82

sdc 0.00 0.00 49.40 355.60 10317.60 19368.40 73.30 0.60 1.52 0.64 26.04

sda 0.00 9.00 37.00 324.80 8339.20 16625.60 69.00 0.72 1.87 1.10 39.68

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

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

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

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

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

1

-A INPUT -p tcp -m tcp --dport 1521 -j DROP

而sysctl-a的输出显示为:

 

 

net.ipv4.ip_local_port_range = 1024    65000

net.ipv4.ip_local_reserved_ports = 5042-5043,8888,9902-9903,23791,23943

从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。

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

 

[root@ht01 ~]# chkconfig --list |grep -i network

NetworkManager 0:off 1:off 2:on 3:on 4:on 5:on 6:off

network 0:off 1:off 2:on 3:on 4:on 5:on 6:off

[root@ht01 ~]# service NetworkManager status

NetworkManager (pid 2227) is running...

[root@ht01 ~]#

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

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

(1).网口配置信息:

 

[root@ht01 network-scripts]# more ifcfg-bondeth0

DEVICE=bondeth0

USERCTL=no

BOOTPROTO=none

ONBOOT=yes

IPADDR=xxx.xxx.0.100

NETMASK=255.255.255.0

NETWORK=xxx.xxx.0.0

BROADCAST=xxx.xxx.0.255

BONDING_OPTS="mode=active-backup miimon=100 downdelay=5000 updelay=5000 num_grat_arp=100"

IPV6INIT=no

[root@ht01 network-scripts]# more ifcfg-eth1

DEVICE=eth1

USERCTL=no

ONBOOT=yes

MASTER=bondeth0

SLAVE=yes

BOOTPROTO=none

HOTPLUG=no

IPV6INIT=no

[root@ht01 network-scripts]# more ifcfg-eth2

DEVICE=eth2

USERCTL=no

ONBOOT=yes

MASTER=bondeth0

SLAVE=yes

BOOTPROTO=none

HOTPLUG=no

IPV6INIT=no

[root@ht01 network-scripts]#

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

(2).ifconfig信息:

 

[root@ht01 network-scripts]# ifconfig -a

bondeth0 Link encap:Ethernet HWaddr 08:00:27:6B:18:39

inet addr:xxx.xxx.0.100 Bcast:xxx.xxx.0.255 Mask:255.255.255.0

inet6 addr: fe80::a00:27ff:fe6b:1839/64 Scope:Link

UP BROADCAST MASTER MULTICAST MTU:1500 Metric:1

RX packets:733 errors:0 dropped:155 overruns:0 frame:0

TX packets:718 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:67036 (65.4 KiB) TX bytes:65382 (63.8 KiB)

eth1 Link encap:Ethernet HWaddr 08:00:27:6B:18:39

BROADCAST SLAVE MULTICAST MTU:1500 Metric:1

RX packets:578 errors:0 dropped:0 overruns:0 frame:0

TX packets:718 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:55656 (54.3 KiB) TX bytes:65382 (63.8 KiB)

eth2 Link encap:Ethernet HWaddr 08:00:27:05:14:BB

BROADCAST SLAVE MULTICAST MTU:1500 Metric:1

RX packets:155 errors:0 dropped:155 overruns:0 frame:0

TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:11380 (11.1 KiB) TX bytes:0 (0.0 b)

[root@ht01 network-scripts]#

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

(3).服务状态:

 

[root@ht01 network-scripts]# chkconfig --list |grep -i network

NetworkManager 0:off 1:off 2:off 3:off 4:off 5:off 6:off

network 0:off 1:off 2:on 3:on 4:on 5:on 6:off

[root@htb01 network-scripts]# service NetworkManager status

NetworkManager is stopped

[root@ht01 network-scripts]#

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

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

 

[root@ht01 network-scripts]# chkconfig NetworkManager on

[root@ht01 network-scripts]#

[root@ht01 network-scripts]# service NetworkManager restart

Stopping NetworkManager daemon: [FAILED]

Setting network parameters... [ OK ]

Starting NetworkManager daemon: [ OK ]

[root@ht01 network-scripts]#

[root@ht01 network-scripts]# service network restart

Shutting down interface bondeth0: Device state: 3 (disconnected)

Device state: 3 (disconnected)

[ OK ]

Shutting down interface eth0: Device state: 3 (disconnected)

[ OK ]

Shutting down interface eth1: [ OK ]

Shutting down interface eth2: [ OK ]

Shutting down loopback interface: [ OK ]

Bringing up loopback interface: [ OK ]

Bringing up interface bondeth0: Active connection state: activated

Active connection path: /org/freedesktop/NetworkManager/ActiveConnection/3

[ OK ]

Bringing up interface eth0: Active connection state: activated

Active connection path: /org/freedesktop/NetworkManager/ActiveConnection/4

[ OK ]

[root@ht01 network-scripts]#

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

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

 

 

[root@ht01 network-scripts]# ifconfig -a

bondeth0 Link encap:Ethernet HWaddr 08:00:27:6B:18:39

BROADCAST MASTER MULTICAST MTU:1500 Metric:1

RX packets:820 errors:0 dropped:242 overruns:0 frame:0

TX packets:892 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:72256 (70.5 KiB) TX bytes:78084 (76.2 KiB)

eth1 Link encap:Ethernet HWaddr 08:00:27:6B:18:39

UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1

RX packets:578 errors:0 dropped:0 overruns:0 frame:0

TX packets:892 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:55656 (54.3 KiB) TX bytes:78084 (76.2 KiB)

eth2 Link encap:Ethernet HWaddr 08:00:27:05:14:BB

UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1

RX packets:242 errors:0 dropped:242 overruns:0 frame:0

TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:16600 (16.2 KiB) TX bytes:0 (0.0 b)

[root@ht01 network-scripts]#

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

原创文章,版权归本文作者所有,如需转载请注明出处

喜欢本文请长按下方的二维码订阅Oracle一体机用户组

本文转载自:http://www.cnxdug.org/?p=1774

Oracle一体机用户组
粉丝 0
博文 5
码字总数 0
作品 0
私信 提问
ERP已死,云计算上位

最近甲骨文和SAP公司频频收购SaaS云计算创业公司,如RightNow、SuccessFactors以及Taleo。但更引人注目的是甲骨文和SAP的竞争对手Saleforce和Workday的几次收购。这些公司的连续收购表明,云...

虫虫
2012/02/20
3.3K
28
性能神化,聊聊Exadata一体机的“七宗罪”

  【IT168 评论】本文是一位战斗在一线,并经常接触到Exadata的DBA个人观点总结,您是否认同?对Exadata,您又怎么看?   什么是Exadata?它跟国内的一些oracle数据库一体机品牌一样,是一套...

it168网站
2018/05/02
0
0
沃趣发布QData T5 性能价格均碾压Exadata

  导语:随着互联网业务的发展,IOE架构暴露出的问题也越来越多,自从阿里巴巴打响了去IOE的第一枪后,去IOE之势就已不可阻挡,而用数据库一体机这种新架构取代IOE架构(实际上是去IE)的方式...

it168网站
2018/04/28
0
0
国内常见大型网站的“账号安全”情况一览

今天,你的密码泄露了吗? 去年年底轰轰烈烈的密码泄露惨案似乎没有能引起国内网站的重视,绝大部分的网站仍然没有采取正确的措施来保护用户的账号。我在此不想考究各大网站的技术实力,只想...

鉴客
2012/03/22
3.4K
54
浅谈用户体验的“反面模式”

英文原文:The World of UX Anti-Patterns 来源:微博UDC 作为网站的一个用户,你也许时常会发现,使用网站时,有些东西很令人厌烦。例如一个登录的表单,或是导航,或者是整个网页应用,都有...

oschina
2013/05/19
2.1K
6

没有更多内容

加载失败,请刷新页面

加载更多

64.监控平台介绍 安装zabbix 忘记admin密码

19.1 Linux监控平台介绍 19.2 zabbix监控介绍 19.3/19.4/19.6 安装zabbix 19.5 忘记Admin密码如何做 19.1 Linux监控平台介绍: 常见开源监控软件 ~1.cacti、nagios、zabbix、smokeping、ope...

oschina130111
今天
10
0
当餐饮遇上大数据,嗯真香!

之前去开了一场会,主题是「餐饮领袖新零售峰会」。认真听完了餐饮前辈和新秀们的分享,觉得获益匪浅,把脑子里的核心纪要整理了一下,今天和大家做一个简单的分享,欢迎感兴趣的小伙伴一起交...

数澜科技
今天
7
0
DNS-over-HTTPS 的下一代是 DNS ON BLOCKCHAIN

本文作者:PETER LAI ,是 Diode 的区块链工程师。在进入软件开发领域之前,他主要是在做工商管理相关工作。Peter Lai 也是一位活跃的开源贡献者。目前,他正在与 Diode 团队一起开发基于区块...

红薯
今天
6
0
CC攻击带来的危害我们该如何防御?

随着网络的发展带给我们很多的便利,但是同时也带给我们一些网站安全问题,网络攻击就是常见的网站安全问题。其中作为站长最常见的就是CC攻击,CC攻击是网络攻击方式的一种,是一种比较常见的...

云漫网络Ruan
今天
11
0
实验分析性专业硕士提纲撰写要点

为什么您需要研究论文的提纲? 首先当您进行研究时,您需要聚集许多信息和想法,研究论文提纲可以较好地组织你的想法, 了解您研究资料的流畅度和程度。确保你写作时不会错过任何重要资料以此...

论文辅导员
今天
8
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部