多么痛的领悟：十三起惨痛宕机案例

社区有很多兄弟分享惨痛宕机案例，提醒大家需警惕，以下介绍几起，满满都是血的教训……

（以下案例来自社区多位会员分享，主要由社区专家孙伟光、崔增顺编辑整理）

01

AIX 下 NTP 设置不当导致的多个集群宕机

事情发生在一段时间之前，接到朋友电话，用户有三套 oracle rac 集群运行在 aix 小机上，本地两套，同城机房两套，做完设备搬迁后的一天晚上，其中本地和同城的两套 rac 突然就整个重启了，而且发生在同一时间点。

网络、小机、存储、数据库分属不同的维保厂商，这就开始了扯皮。各家就开始从自己的方向自证无过错。我去之前内心也比较倾向于 oracle 的网络心跳出了问题，crs 抢 vote disk 的时候触发了重启。但由于是小机方的代表，仅从 aix 层面做了排查，未发现明显原因。对各主机宕机的时间做了一个梳理，去和 oracle 的事件日志去比对。暂时没查到什么东西。

宕机产生的 dump 发到了 IBM 原厂，IBM 后来出了个报告，根据 dump 内容定位触发宕机的进程为 cssd。oracle dba 重点看了那个进程的日志，发现宕机时间前后，时间突然变更，提前了40多秒。dba 确认，时间变更过多，cssd 进程会导致系统重启，怀疑和时间同步有关。

经检查，3套 aix 的 rac 集群使用了同一个 ntp server，但有一套没发生问题。对比检查差异，发现没问题的那套主机集群使用 xntpd 方式配置了时间同步。出问题的主机则直接使用了 ntpdate 命令做时间更新，并写入了 crontab 定期执行。检查 /var/adm/cron/log 日志，发现定时任务的执行时间和 cssd 故障时间一致。检查时间服务器，发现搬迁后，时间服务器的时间产生了较大偏差，xntpd 方式的时间同步在时间偏差大时不会去强制同步，ntpdate 命令的方式没有这个限制，会直接进行同步。最终导致了 cssd 进程检测到过大时间偏差后触发了宕机。

经验分享：配置时间同步时，建议使用 xntpd 服务的方式，不用直接在定时任务里写 ntpdate，因为 ntpdate 比较粗暴，发生故障时较大的时间偏差会导致应用出现问题，触发无法预知的后果。

由社区会员王巧雷分享

02

采用爱数备份一体机导致宕机

去年我们刚刚入手了一台爱数备份一体机，在测试阶段遇到了一个小例子和大家分享一下：

当时测试各种数据的备份和功能，就在一台系统上安装了爱数备份的代理客户端，客户端安装选项中有一项安装 CDP 驱动。 当时并没有留意，后来升级客户端版本，另外做了一些其他测试，就把代理客户端卸载了，但是并没有先去卸载 CDP 驱动，重启后系统就直接起不来了，和爱数的技术支持沟通后了解，需要先卸载CDP驱动，再卸载客户端，否则 CDP 驱动存在的时候，就会导致系统启动失败。

由社区会员“pysx0503”分享

03

经典双机双存储，某晚主存储异常故障，业务立刻中断

用户经典的双机双存储高可用应用方案。IBM 2*P570 PowerHA6.1 两台中端存储通过 lvm mirror 实现的数据镜像，上面跑着用户信贷系统，报表系统，存储压力较为繁忙。用户每年都会完成一次 HA 切换演练保证业务高可用。某晚一次存储电源故障，电源还没来得急更换，另外一个电源也坏了。这样主存储宕机了。恰巧这个时候业务也立刻停止了，用户电话里说刚做完的 Powerha 的演练，很顺利。可今天发生的这事却百思不得其解。

后来经过大量的日志和与用户交流得知，用户之前的一个操作给这次的业务中断埋下了一个大大的”地雷”。

究竟用户自己做的什么操作导致的此次事件呢？

用户业务系统有一个文件系统存储空间不够了，需要扩容，但是目前共享 vg 里的空间无法满了，需要重新加新的磁盘到 vg 里，存储管理员分配新的磁盘给两台主机，然后用户通过 Powerha cspoc 去加盘，扩容 FS。就是这么一个操作导致的问题发生。

经验分享：lvm mirror 双存储的情况下，我们扩 fs 需要注意先扩 LV，再扩 fs，这样能保证数据正确分布在2个存储上，如果在用户这种场景新加磁盘后直接扩fs，那就会造成数据拷贝是2份，但是不能准确地保证分布在两个存储上，有可能存储A分布90% 存储B分布110%。这样一台存储故障，就会直接导致数据的不完整。

由社区会员孙伟光分享

04

HACMP NODE ID 一致导致故障宕机

故障描述：

前些天在论坛闲逛，发现一兄弟的帖子“Power HA 其中一台异常宕机”（发布者：yangming27），点进去一看，发现故障描述和报错信息和我之前遇到的完全一样，基于提醒和血的教训，特将该问题编写成案例，希望大家引以为戒！

我们生产环境有 PowerVM 虚拟化后的 AIX 虚拟机2台，灾备环境有 PowerVM 虚拟化后 AIX 虚拟机1台，三台虚拟机通过 PowerHA XD(基于 SVC PPRC 远程复制)搭建了跨中心高可用环境，操作系统版本为7.1.2.3，HA 版本为7.1.2.6，搭建该环境之前，生产环境的两台 AIX 是通过 HAMCP 搭建了本地的高可用环境，为了灾备建设需求，将本地的1台主机通过 alt_disk_copy 的方式复制了一份 rootvg 至外置存储，并将该外置存储通过 SVC PPRC 复制至灾备存储卷当中，灾备的虚拟机再挂载该卷，并通过该卷启动操作系统。这样三台 AIX 虚拟机再重新搭建了PowerHA XD，实现跨中心 HA 热备。

通过这种方式，我们搭建了三套系统，均通过了 HA 切换测试，但是运行了一段时间后，其中一套系统的主机故障宕机（关机），资源组切向了备机，发现问题后，第一时间查看 errpt 日志，如下（这里借用 yangming27帖子中的日志截图）

故障分析：

由于操作系统没有开 always allow dump，所以并没有产生 dump 文件，当时分析了很久日志，很是疑惑不解，最终只能提交给 IBM 后台进行分析，后台也是许多天都没有答复。过了一个星期后，第二套系统也出现了一样的现象，一样的故障，造成主备 HA 切换，我开始怀疑是 HACMP XD 实施问题，立马翻阅了一下实施文档，发现在做 alt_disk_copy 时只用了 alt_disk_copy -d hdiskx,后面并没有用-O -B -C参数，这些参数主要是用来复制rootvg时，删除原操作系统的配置信息和 ODM 库的一些信息，这样一来可能就会造成生产主机和灾备备机的操作系统某些信息一致。基于这种怀疑，我复看了 errpt 报错记录，宕机的主要原因应该是以下几个点：

IBM.StorageRM daemon has been stopped

Group Services daemon stopped

Group Services detected a failure

QUORUM LOST,VOLUME GROUP GROUP CLOSING

猜想是否是 QUORUM 中保留的两个主备节点信息一致，导致 QUORUM 关闭。

接着在生产主机运行命令

odmget -q "attribute='node_uuid'" CuAt

输出：CuAt: name = "cluster0" attribute = "node_uuid" value = "673018b0-7a70-11e5-91fa-f9fe9b9bc3c6" type = "R" generic = "DU" rep = "s" nls_index = 3

在灾备主机运行命令 odmget -q "attribute='node_uuid'" CuAt

输出：CuAt: name = "cluster0" attribute = "node_uuid" value = "67301842-7a70-11e5-91fa-f9fe9b9bc3c6" type = "R" generic = "DU" rep = "s" nls_index = 3

生产主机运行命令

/usr/sbin/rsct/bin/lsnodeid

灾备主机运行命令

/usr/sbin/rsct/bin/lsnodeid

以上发现两个节点的 RSCT NODE ID 完全一致

这就是造成信息冲突的点，造成了主服务停止和 QUORUM 仲裁关闭的元凶。

故障解决：

1.将 PowerHA XD 的 HA 服务全部关闭，禁止 HA 组服务的保护，并运行命令

/usr/sbin/rsct/bin/hags_stopdms -s cthags

/usr/sbin/rsct/bin/hags_disable_client_kill -s cthags

2.停止 HA 的 ConfigRM 服务和 cthags 服务

stopsrc -s IBM.ConfigRM stopsrc -s cthags

3.重新配置 RSCT 节点

/usr/sbin/rsct/install/bin/recfgct

4.重启所有3台操作系统

shutdown -Fr

5.启动 HACMP 服务和资源组，并检查 RSCT NODE ID

经验分享：通过以上方法，彻底解决了三套系统的 HACMP 主机宕机问题，建议以后做类似 alt_disk_copy 时，一定要带上-B -C -O参数，保持新操作系统的洁净，以防碰到类似的莫名其妙的问题。

由社区会员“jxnxsdengyu”分享

05

Power 570/595 宕机

事情起因：

由于机器宕机是在周六，是客户的核心应用，但周六客户没有人上班，当周一上班的时候发现所有的办公，邮件系统等一半的核心应用不能访问，经过现场机房管理人员的临时排查，发现小机 Power595 后面所有的 I/O 柜掉电，Power570 黄灯亮起，绿灯慢闪。

工程师到达现场，按照与客户沟通好结果，我们开始干活，大概折腾了6个小时，Power595 还是没有启动起来，但 power570 可以正常访问了。为了赶紧让客户生产数据，我们临时决定，用 power570 临时做个 lpar 让存储链接过来，先拉起应用，再又折腾了3个多小时之后，所有应用都可以正常访问。我们继续排查Power595，我们更换了 CEC DCA 内存板，CPU 都没有解决问题，最后更换了 pubook 问题解决了，花费时间3天。

问题原因：

电工改造线路，造成了机房断电，UPS 临时接管，由于电池放了太久，机器功率太大，造成低电压运行，造成设备不能正常工作，更为关键的是电工出现问题之后没有及时检查电路，根据师傅的陈述大概过了1分钟又把交流电送出去，这个电压冲击是很厉害的，经排查此电工无证施工，客户已经提起诉讼。

由社区会员“shizhe1030”分享

06

ERP 备份导致的一起宕机案例

现象回顾：

某日凌晨，其中一台 ERP 数据库主机宕机。AIX.5.3 HACMP RAC 数据库环境。

故障分析：

宕机时间点是在备份期间。通过分析数据库日志、系统日志、发现导致数据库停库的主要原因是由于 HACMP 的一个守护进程 haemd 发生自动重启，由于 oracle 数据库和 haemd 进程之间有关联，因此数据库在发现 haemd 重新启动后也自动停止。

经 IBM 工程师及实验室分析，Haemd 自动重新启动的原因是由于在一定期间内（参数为2分钟）没有给 HACMP 系统响应，其原因之一是由于系统过于繁忙，没有响应 Haemd。

随后分析结果发现在备份期间，从存储看系统不是很繁忙；但 ERP 数据库服务器主机性能异常：有时会出现阶段性的不响应现象，同时系统 I/O 高。停止备份后，这种现象消失。

经 IBM 实验室协助，初步经过分析：

1)AIX 系统内存分为计算类和非计算类内存。非计算类内存主要用于文件操作CACHE，以便提高文件再次读写的性能。目前 ERP 生产数据库占用了近20G内存作为文件系统 CACHE。

2)当文件系统 CACHE 有空间时，写文件操作将不会产生阻塞，当文件系统 CACHE 无空间时，系统将会根据内部策略，挤出部分 CACHE。当无法找到空闲的 CACHE 时，会等待系统调整出空闲的 CACHE。当出现大量等待时，系统可能出现无响应的状态。

解决方案：

考虑到将来数据量的增加，如果无法解决较大 I/O 对系统的影响过大的问题，这个隐患将一直存在。

调整该备份文件系统的属性，在该文件系统的 I/O 请求到达一定值的情况下，阻塞对该文件系统的读写 I/O，从而保证预留足够的资源给系统。具体参数为 Maxpout、Minpout。

经验分享：Maxpout、Minpout 参数的选择，是和具体环境相关的，没有一个统一的建议值。若该参数设置不合理，可能会影响到文件系统的读写操作。而合适的参数需要经过设置、观察来确定。

由社区会员孙伟光分享

07

weblogic 宕机问题排查

问题现象：

系统持续运行2-3天，中间件出现宕机

系统运行期间只要访问 weblogic 控制台，操作几次后中间件宕机

报错日志：

分析：

通过报错日志分析，为内存溢出，且为非堆内存溢出，这种情况一般需要调整：PermSize 的大小。

解决过程：

调整 weblogic 配置参数：setDomainEnv.sh 设置 setDomainEnv.sh 为512。

调整后重启系统，发现问题依旧，并没有解决宕机问题。

确认修改参数是否生效：生成 javacore 来分析（kill -3 进程ID）截图如下：

我们发现参数并没有生效。继续分析参数为什么没有生效。

Weblogic 中的 commEnv.sh ,发现 JAVA_VENDOR 为 N/A

而 setDomainEnv.sh 中 PermSize 的设置为：

此处的参数并没有 设置我们需要的 Open JDK的 JAVA_VENDOR 的 N/A 的赋值，所以非堆内存的设置并未生效。

注意：正常 open jdk 的 JAVA_VENDOR 为 Oracle 的，但是配置文件却为：N/A,可能是 weblogic 的兼容性问题，或者人为改动导致，找到原因了，这个问题就没有细究。

解决方案：

修改 commEnv.sh , JAVA_VENDOR 为 Oracle、HP、IBM、Apple 中的任何一个

在 startWeblogic 中，单独定义：MEM_ARGS="-Xms2048m -Xmx2048m -XX:PermSize=1024m"

验证方案：

采取第二种方案：

1）在原始默认环境，进行12个小时的循环操作，并持续访问 weblogic 控制台。

2）在修改后的环境，持续访问 weblogic 控制台，生成 javacore 文件看参数是否生效。并进行50人高强度的并发测试20个小时，看是否会重现宕机问题。

在方案的第一步，系统运行2小时，访问控制台，中间件宕机，系统无法访问。

在方案的第二步，系统在50人高强度的并发测试20小时的情况下，响应正常。频繁访问控制台并未发现任何异常。通过生成 javacore 发现非堆内存正常生效。

由社区会员“gu y 011”分享

08

P550/P570 宕机案例

某周末，客户致电，说核心业务无法访问。工程师到达现场，发现客户环境（P550/P570--HACMP）P550 两台小机均关机。发现客户现场有部分服务器也已处于关机掉电状态。此时客户才发现，市电周五晚上断电过，但是客户机房配备有2台 UPS，机房设备一半一半分别接到2台 UPS上。排查发现其中一台 ＵＰＳ无法供电。而两台小机均有一路电源接到该 UPS，导致市电断电后，直接宕机。

后将小机通电开机，发现P550无法开机，CPU VRM 稳压模块报错，由于客户业务较为重要，将 P570 已经拉起来，准备将 HA 集群在 IBM P570 单节点运行。却发现 HA 无法将 Oracle 数据库拉起。由于时间紧迫，手动在 P570 网卡上添加 IP 别名后，手动挂载 VG，恢复业务。

后续，将 P550 稳压模块进行更换后，发现仍然无法开机，又出现新的报错：11002630，再次更换 CPU 板后，P550 小机正常开机。安排停机窗口进行排查恢复。在处理过程中，集群出现意外，在 HA 拉起来后，经业务测试，发现/orafile丢失一部分数据，此时备份数据最新的为前一天晚上23点，单天的数据未做备份，只能采取数据恢复，最后成功将数据恢复回来。重新配置 ＨＡ，模拟故障切换，测试业务，验证数据完整性，业务恢复正常！

由社区会员“ACDante”分享

09

AIX6100-06-06系统 bug 引起 down 机

某机器操作系统版本6100-06-06，系统 down 机，生成 dump 文件。

Problem：

System crash with following stack

CRASH INFORMATION:

CPU 3 CSA F00000002FF47600 at time of crash, error code

for

LEDs: 30000000

pvthread+02BD00 STACK:

[00009500].simple_lock+000000 ()

[00450E24]netinfo_unixdomnlist+000824 (??, ??, ??, ??,

??, ??)

[0451214C]netinfo+00006C (??, ??, ??, ??, ??, ??)

[004504DC]netinfo+0000FC (??, ??, ??, ??)

[00003850]ovlya_addr_sc_flih_main+000130 ()

[kdb_get_virtual_memory] no real storage @

FFFFFFFFFFFEF20

[100002640]0000000100002640 ()

[kdb_read_mem] no real storage @ FFFFFFFFFFF5E30

bug原因：

File lock is taken before checking whether the file type is socket.

该故障因 netstat -f unix 命令引起系统 crash, 是 IBM bug 引起

建议单独提升 bos.mp64包补丁包或者整体升级到6100-06-12-1339(SP12)

官网解释：

IV09793: SYSTEM CRASH IN NETINFO_UNIXDOMNLIST APPLIES TO AIX 6100-06

http://www-01.ibm.com/support/docview.wss?uid=isg1IV09793

File lock is taken before checking whether the file type is socket.

由社区会员“qb306”分享

10

P570 宕机案例

IBM 570 意外宕机，处理过程如下：

1、首先查看 asmi 日志，电源和风扇故障，更换了2个电源和1个风扇后，可以启动到 standby 模式。但是非常多的 firmware 报错。

2、升级微码到 sf240-417后，微码报错消失。

3、激活分区失败，hmc 终端会出现几秒的”ide inited failed“提示，然后消失。接着卡死，报找不到硬盘。

4、观察外观，发现后端的光纤卡灯特别弱，有时会不亮。

5、查了下570的红皮书结构图，发现 ide controller(红线圈住部分)同时处理 pci 设备和硬盘背板设备过来的 io，根据现有故障现象，判定 ide controller 有故障。

6、通过 ibm system information center，定位到 ide controller 的 location code 为p1-15，不是一个可替换的 FRU，必须随同 IO backbone（就是主板）一起更换。

7、更换 io backbone 后，系统正常启动，进入系统微调后，一切正常。

由社区会员王巧雷分享

11

某企业 HACMP 软件，在网络交换机变更时引起 down 机

某企业 HA cluster log, IP switch down 时引起双节点 halt,系统版本7100-03-03，HA 版本6.1sp13

Error description

In HACMP 6 with rsct.core.utils 3.1.4.9 or higher, if all

IP networks are lost and at least one non-IP network is

functioning, the Group Services subsystem will core dump when

trying to send packets to be routed through Topology Services

(across the non-IP connection). This will cause a node halt.

Customers with PowerHA 7, or HACMP 6 customers with no non-IP

networks (such as rs232 or disk) are not in danger. Also this

will not happen if only one node is still running, since there

will be no other cluster members to send messages to.

日志如下：

原因是补丁 IV55293: HAGSD CORE DUMP WHEN IP NETWORKS LOST， 需要升级 rsct 文件集。

官网解释：

http://www-01.ibm.com/support/docview.wss?uid=isg1IV55293

由社区会员“qb306”分享

12

巡检不仔细 Power595 宕机

事件起因，本来巡检已经发现其中的一个 I/O 柜电源故障，在线更换走脚步的时候，脚步执行到一半引起该 I/O 柜突然掉电，重启了该 I/O 柜。

原因：一线工程师巡检时候不够仔细，因为该同一个 I/O 其实坏了2个电源，只不过另外一个没有报出来具体的位置，但已经报出来该 I/O 的部件号，但也说明了 IBM 小机没有完全报错具体槽位，只报错了大概的位置。

解决方法：设备下电，更换两个 I/O DCA，然后设备开机，问题解决。

由社区会员“shizhe1030”分享

13

X86 史上最离谱的宕机事件

硬件： IBM的X3650 操作系统： suse 9

linux 系统无法远程登陆，用 KVM 登录上去看发现定在操作系统页面不能动。

重启操作系统后，在操作系统 message 日志里面查看到如下错误：

经过咨询 novell 和 IBM 工程师，结论是 IBM 这类服务器在装 linux 系统的时候，如果光驱有问题确实是会导致宕机。

经硬件工程师检查，是光驱坏了……坏了……

编者按：宕机原因千万种，这个宕机有点冤

由社区会员“hp_hp”分享

本文转载自公众号： talkwithtrend

更多相关文章阅读

一个运维如何从底层走上人生巅峰

运行无间：阿里巴巴运维保障体系的一种最佳实践

芳华永在！一个老运维的20年奋斗史

饿了么异地双活数据库实战

Python 编程中常用的12种基础知识总结

青铜到王者，快速提升你 MySQL 数据库的段位！

有赞数据库自动化运维实践之路

运维版《成都》，听哭了多少人...

同样会 Python，他的工资比你高一倍

阿里万亿交易量级下的秒级监控

IT 运维的救赎——顺丰运维的理想践行

学好 Python、拿高薪、竟是如此简单

快加入高维学院直通车成为认证运维开发工程师

只需要5天！

在5天内集中向你传授面向 DevOps 的运维开发工程师所需要掌握的所有精华。

更有含金量的是，学习结束你还将拥有一张【运维开发工程师认证证书】

这份含金量超高的证书：

如能被推荐进入上述大厂，您的培训费将被退回一半！！

更多企业直通车，正在路上。

也欢迎企业和我们联系：

刘琳，微信/电话：13910952502

参与认证运维开发工程师课程报名、详情请点击阅读原文链接