金融行业现场故障处理实录

系统运维 2024-02-19 向阳逐梦 手机阅读

金融行业现场故障处理实录

 

n   KL 银行现场服务记录 —HA 故障

 

服务时间

2019 年9 月10 日星期二 14 ：40 到2019 年9 月11 日星期三 0 ：30

 

服务内容

ü   排查redhat RHEL 6.4 一个节点cman 启动故障。

（1 ）、查看系统日志；

（2 ）、查看ha 日志，/etc/cluster 下各日志文件；

（3 ）、clustat 查看集群状态，提示cman 未运行；

（4 ）、查看集群配置文件/etc/cluster.conf;

（5 ）、对比另一个正常运行节点的状态及日志输出；

（6 ）、运行指令 strace –f –o /tmp/cman.log /etc/init.d/cman status ，生成跟踪文件；

由于当前不能执行cman 启动操作，故障暂时不能排除。

ü   新的华为服务器，由于使用了UEFI 代替老旧的bios 进行引导管理，客户在安装redhat RHEL6.4 时进行 不下去，顺便协助他正确完成安装。

ü   Ha 挂接的共享盘报“no clean ”, 预判文件系统存在问题，准备服务停止后，卸载挂接，然后修复（fsck ）。

 

n   MS 银行（顺义）现场服务记录 --

 

问题描述

 

某Redhat RHEL 6.X 系统部署应用以后，运行一段时间，可能会出现系统挂起现象，挂起时间不确定。相关人员怀疑是应用所引起的，为了弄清事实真相，需要在系统挂起前导出core 文件。

 

系统已经配置好kdump ，但在启动kdump 服务时，无法成功。因此现场服务的主要任务时排查kdump 启动故障。

 

排查过程

 

ü   检查相关的软件包是否正确安装：rpm-qa|grep kexec-tool ，已经被正确的安装。

ü   检查kdump.conf 配置文件, 为发现异常；

ü   检查系统日志/var/log/messages, 未发现有价值信息；

ü   试着启动服务 service kdump start ，输出提示” 找不到内核文件 kernel-15…” 。初步判断问题出现在这里。这个数字15 是哪里来的呢？

ü   打开文件/etc/sysconfig/kdump ，发现其有效行的第一行有异常

通过对比其他正常系统的配置，其值默认为空，不为“15 ”。在征得同意以后，对其修改，并启动kdump 服务。

 

处理结果

 

故障排除，完成服务。

 

n   TK 保险服务器重启排查记录

 

主要现象

 

近期以来，每隔2 天左右会自动重启，并且重启时间不固定。

主要信息收集

 

ü   硬件信息：4 颗物理cpu ，总核数96 ，总线程数192 ；内存1T; 磁盘多路径连接，划分多个逻辑卷。

ü   操作系统为redhat RHEL 7.4 ，内核版本3.10.0-693. 未进行过版本更新。

ü   应用为db2 数据库。

 

排查过程

 

ü   查看系统日志，dmesg 及打开文件/var/log/messages ，并用关键字error 、fatal 、warning 等进行过滤。

egrep   –i “error|fatal|warning” /var/log/messages

未发现有价值信息。

ü   查看系统用户，存在多个普通用户，并拥有shell （bash ）。

ü   查看用户授权，主要是/etc/suders ，使用的命令 visudo 。虽然授权指令较多，但未发现有reboot 指令的权限授予。

ü   排查用户的计划任务，因为用户较多，使用如下脚本进行查找。

for u in `cat /etc/passwd | cut -d ":" -f1`; do sudo crontab -l -u $u ; done

发现db2 数据库启动账号有个重启脚本，设定的时间是每天早上8 点。搜索此脚本及所在路径，不存在， 建议注释掉此条。

ü   用户反馈，说二线技术支持曾经远程配置了kdump ，模拟系统崩溃能生成vmcore 文件，但昨天早上（6 ：00 多钟）系统崩溃发生重启，却没有生成转储文件。查看文件/etc/default/grub 及/boot/grub2/grub.cfg ，其中 crashkernel=786M@0M 。鉴于此，把crashkernel 的值改成786M ，去掉了后边的偏移量。再修改文件/etc/kdump.conf ，启用压缩功能。

core_collector makedumpfile - c -- message - level 1 - d 31

增加一個选项“-c ”，表示启用压缩。

grub 2-mkconfig -o /boot/grub2/grub .cfg  

重新生成grub 配置，需要重启才能生效。

ü   查看系统参数kernel.sysrq ，其值为16, 手动方式修改文件 /etc/sysctl.conf ，显示指定

Kernel.sysrq=1

修改完执行 sysctl –p 使其生效。

ü   执行下列指令，模拟故障发生。

echo c > /proc/sysrq-trigger

重启完成后，在目录/var/crash 确实生成了大文件，大小为4G 。

 

服务建议

 

等下一次重启，如果生成了vmcore 文件，把此文件传到case 附件里边，有后台技术对其进行分析。

 

n   TK 人寿系统修复操作记录

 

问题及成因

 

一虚拟机系统， 不能正常引导，但还能进入单用户模式。此虚拟机没有对镜像进行备份，因此无法还原。系统中有用户的数据，因此不能通过重新安装系统来进行有效恢复。

 

通过沟通，了解到是用户自己在远程执行一個ssh 脚本，此脚本有一行”chmod –R 777” 的指令，本意是共享一個nfs 服务目录，但因为为对目录是否存在进行判断，因此一执行完脚本，所有的目录文件的权限都变成777 了。

 

处理过程

 

找一台运行正常的，版本一致的系统，对比/etc 目录里各种权限与验证有关的目录和权限，如 passwd 、shadow 、ssh 等。用chmod 指令逐一进行修改，修改一些权限以后，重启系统，直到能正常运行，并且能用ssh 远程登录。

 

 

处理结果及建议

 

交付给用户，然后建议重装系统。但用户自己认为没啥问题，以后再说。