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

sery發表於2024-02-18

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

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

處理結果及建議

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


來自 “ ITPUB部落格 ” ,連結:https://blog.itpub.net/632405/viewspace-3006684/,如需轉載,請註明出處,否則將追究法律責任。

相關文章