金融行業現場故障處理實錄

金融行業現場故障處理實錄

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 遠端登入。

處理結果及建議

交付給使用者，然後建議重灌系統。但使用者自己認為沒啥問題，以後再說。