【技术】多么痛的领悟：6起惨痛宕机案例
发布作者：微思网络 发布时间：2018-01-03 浏览量：0次
社区有很多兄弟分享惨痛宕机案例，提醒大家需警惕，以下介绍几起，满满都是血的教训……
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 比较粗暴，发生故障时较大的时间偏差会导致应用出现问题，触发无法预知的后果。
由社区会员王巧雷分享
采用爱数备份一体机导致宕机
去年我们刚刚入手了一台爱数备份一体机，在测试阶段遇到了一个小例子和大家分享一下：
当时测试各种数据的备份和功能，就在一台系统上安装了爱数备份的代理客户端，客户端安装选项中有一项安装 CDP 驱动。 当时并没有留意，后来升级客户端版本，另外做了一些其他测试，就把代理客户端卸载了，但是并没有先去卸载 CDP 驱动，重启后系统就直接起不来了，和爱数的技术支持沟通后了解，需要先卸载CDP驱动，再卸载客户端，否则 CDP 驱动存在的时候，就会导致系统启动失败。
由社区会员“pysx0503”分享
经典双机双存储，某晚主存储异常故障，业务立刻中断
用户经典的双机双存储高可用应用方案。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%。这样一台存储故障，就会直接导致数据的不完整。
由社区会员孙伟光分享
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”分享
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 参数的选择，是和具体环境相关的，没有一个厦门linux培训多少钱统一的建议值。若该参数设置不合理，可能会影响到文件系统的读写操作。而合适的参数需要经过设置、观察来确定。
由社区会员孙伟光分享
