第一章 技術人生系列 · 我和資料中心的故事（第二期）——風險提醒之Oracle RAC高可用失效

中亦安圖 | 2016-01-15 21:36

前言

不知不覺，技術人生·我和資料中心的故事來到了第二期，有朋友開始關心小y是誰，這不重要，我們更關心的是技術層面的分享以及給客戶帶來的實際的風險提示。後續我們還會繼續分享中包括作業系統的小亦，中介軟體的小W的故事....小y這個名字，其實沒有什麼特殊的含義，就暫且用他來代表我們這些為資料中心奉獻自己無悔青春的運維人吧！

本期分享主題

小y今天要和大家分享的是下面這麼一個嚴肅的話題：

你的Oracle RAC是真的高可用麼？還是偽高可用呢？

換句話說:

當Oracle RAC叢集中的一個節點所在的分割槽/伺服器宕掉的時候，

你是否可以和領導拍著胸脯說，

“沒事，這是ORACLE RAC，還有一個節點呢！只要該節點可以抗住負載，完全可以正常對外提供服務！”

如果你再把上面那段話讀一遍，是否有開始猶豫的感覺了呢？

小y再換個方法來問一下這個話題：

雖然系統上線前做過RAC高可用測試，但是當叢集中的一個節點長時間執行，包括CPU、記憶體、程式數在內的負載在不斷變化，並且又經歷了一些列變更後，期間又沒有再做過高可用測試，這樣的情況下，如果RAC一個節點所在的分割槽/伺服器宕掉的時候，你是否依然可以拍著胸脯堅定的說，“我的Oracle RAC其他的節點一定可以正常對外提供服務！”?

同樣的問題，當多了一些話語的鋪墊後，再次聽到這個問題的你，答案是否又更加猶豫了呢？

小y今天就為大家奉獻一個“RAC高可用丟失”的真實案例及其完整、真實的分析過程。

你可以從案例中獲得什麼瞭解到導致Oracle RAC高可用失效的一些具體因素。

小y估計不少朋友的系統中依然還存在類似的問題，

建議參考本案例進行細緻檢查,排除隱患。

。

案例精彩看點預告

這個案例會有不小的難度，客戶為了分析該問題發生的根因，投入了大量的人力和時間，一度沒有結果。小y接手該case後，在缺少資訊的情況下，問題的分析也一度陷入僵局。不過小y最終還是通過反覆梳理所有線索，從一個和資料庫毫不相關的小細節中找到了突破口，成功定位到了問題原因。大家可以借鑑一下這樣的方法。

Part 1

故障描述

現象：Oracle RAC高可用丟失。表現如下

1）下午16點1分左右，XX系統資料庫RAC叢集節點2所在的P595 發生硬體故障，導致節點2 資料庫所在的分割槽不可用。

2）但從16點1分開始，應用程式無法連線到資料庫RAC叢集中存活的節點1。

ORACLE資料庫RAC叢集未能發揮高可用架構的作用！

客戶指示，務必找到問題根因，以便對系統高可用架構提出改進意見。

小y很理解，出了這樣的大事，對於一個執行著幾百套RAC的資料中心而言，是一個巨大的風險，其他系統是否也還存在這樣的問題？什麼時候會再發生？如果不找到問題根因，又如何做到由點帶面全面全面梳理、檢查和預防呢？

環境描述:

AIX 5.3

Oracle 10.2 2節點 RAC

HACMP+裸裝置

所以，小y接到該case時，還是有很大壓力的。在開始分析前，小y得到了以下資訊：

1）故障時運維DBA在RAC存活節點1通過sqlplus “/as sysdba”連線到資料庫掛起

2）故障時運維DBA在RAC存活節點1通過sqlplus -prelim “/as sysdba”連線到資料庫掛起,加了-prelim引數連線到資料庫也hang,這是很罕見的情況

3）在存活的節點1上通過 crsctl stop crs -f停止crs無法停止,命令掛起無法結束

4）在存活的節點1上通過shutdown –Fr重啟作業系統，命令掛起無法結束，最終通過hmc重啟分割槽，業務恢復正常

Part 2

分析過程

2.1故障分析思路

叢集中一個節點宕掉，其他節點無法對外提供服務。

通常情況下，是因為當中的叢集軟體沒有完成對整個叢集狀態、資料的重組，

因此資料未達到一致，所以叢集其他節點無法對外提供服務。

這個環境中部署在IBM小機上，其中用到的叢集軟體有：

ORACLE RAC/ORACLE CRS/IBM HACMP

因此，需要分別檢視這三個叢集是否完成了重組、重新配置

2.2 確認ORACLE RAC是否完成重組

檢視一節點資料庫alert日誌,可以看到，RAC叢集在16點1分32秒就完成了重組。

可排除該問題。

2.3 確認ORACLE CRS是否完成重組

可以看到，從16:01開始網路心跳超時，開始對節點2進行剔除的動作，最終在16:01:27節點2離開叢集。可排除該問題。

2.4 確認IBM hacmp是否完成重組

經AIX專家分析，未發現HACMP中出現異常

整個檢查下來，沒有發現異常。

既然節點2資料庫所在的Lpar宕了，那麼節點2的vip應該會漂移到節點1上，接下來通過netstat –in命令檢查，發現節點1上居然沒有節點2飄過來的VIP ！

接管VIP的動作最終將由CRSD程式來完成，因此檢查CRSD.log,以便檢視是否在接管過程中發生了什麼異常。

2.5 檢查1節點crs日誌確認節點2 vip的接管情況

2.6 節點1 crs日誌總結

可以看到：

1）節點2當掉後，節點1的CRS要把節點2的vip、db等資源接管過來，在節點1啟動，但是呼叫指令碼racgwarp來做check/start/stop時均出現了超時timeout,從而把子程式終止了。

2）並且節點1 本身自己的 vip檢測中也出現了超時，如下所示

/oracle/app/oracle/product/10.2.0/crs/bin/racgwrap(check) timed out for ora.node1.vip! (timeout=60)

3） 因此，CRS在資源管理上也出現了一定的異常，主要是呼叫指令碼racgwrap時出現了超時異常。

Racgwrap指令碼出現timeout,通常是因為：

? 作業系統效能緩慢，如記憶體大量換頁

? 指令碼執行過程出現命令掛起的情況

2.7 檢查nmon資料以獲得作業系統效能

可以看到,5月20日的nmon居然停止在了故障時間點16點1分，這說明NMON執行到某個命令可能出現了掛起等異常

另外，從監控軟體來看，作業系統未出現記憶體、CPU的告警。

2.8 確定分析方向

那麼，接下來，我們的分析重點到底是放在資料庫還是作業系統層面呢？

通過上面的線索梳理，我們有理由相信：

作業系統在當時出現了某些異常!因此後續把分析的重點方向放在作業系統層面！

2.9 彙總並梳理所有線索

1）存活節點Sqlplus –prelim無法attach到共享記憶體

2）Kill -9 無法殺掉部分程式

程式處於一個原子級的呼叫，例如一個IO，必須在兩個呼叫之間才可以接受程式終止的訊號，說明某個原子呼叫無法結束導致無法被kill -9終止

3）CRS通過指令碼無法接管故障節點vip,出現超時

4）CRS通過指令碼無法檢測存活節點本身的vip/監聽等資源，均出現超時

5）存活節點Nmon故障點後無輸出

2.10 問題分析一度陷入僵局

雖然把方向放在作業系統上，但AIX專家未檢查到異常。

AIX專家的結論是作業系統當時是沒有異常的！

因為他們檢查了一些crontab的指令碼，是有輸出的，說明OS還在工作。

如下圖所示

2.11 如何找到突破口

小y把方向定到了作業系統，但是作業系統專家檢查並否認作業系統有異常。

對於存活節點nmon為什麼停止寫入的問題，雙方持不同意見。

至此，問題分析陷入僵局，小y開始思考，該如何繼續往下分析呢？怎麼能證明作業系統的異常呢？

1)如果沒有給到作業系統一個明確的點，那麼作業系統是很難查到到底有哪些異常的問題

2)問題分析陷入僵局，該如何找到突破口成為關鍵

3)堅信作業系統異常這個方向是正確的

回到原點，重新梳理和驗證每個線索，會不會漏掉了什麼重要線索

重現檢查之前的線索，有重大發現！

可以看到：

從16點02分以及後續的的取樣可以看到，到了” The file system result is as follows”的檢測就停止了，沒有寫SYSTEM.SH_RUN_COMPLETE關鍵字來表示指令碼執行完成.這說明作業系統在執行非資料庫命令時也遇到了異常！

2.12 確認shell指令碼出現異常時呼叫的具體命令

檢查shell指令碼,發現指令碼掛在” The file system result is as follows:”的地方，事實上是呼叫了df命令來檢視檔案系統。

那麼這個操作在什麼情況會出現HANG的情況呢。

答案是使用nfs檔案系統的時候。

XX系統資料庫叢集中使用了NFS檔案系統，將節點2的/arch2檔案系統通過NFS掛載到了節點1的/arch2檔案系統上。當節點2出現硬體故障後，導致節點1無法與節點2的nfs server通訊，繼而導致節點1上，df命令檢視檔案系統時掛起。

由此來看，節點1 nmon資料停止的原因是df命令hang住了

但是這和節點1無法連線資料庫又有什麼關係呢？

當小y看到df命令時，淚奔了！

所有現象都可以得到解釋了！當所有現象都得到解釋的時候，心裡就踏實了！這意味著你找到了問題的根因，那麼預防措施就萬無一失了！

2.13 Nfs mount點丟失和無法連線資料庫的關係

執行連線資料庫操作時，需要獲取當前工作目錄(pwd)

但是由於AIX某些版本作業系統內部實現pwd過程的缺陷,導致必須遞迴到根目錄/下檢查目錄或檔案的許可權、型別.

當檢查到nfs時，由於nfs 以hard/background方式掛載，當nfs server不可用時，必然導致檢查nfs目錄時出現掛起，繼而導致了無法獲得pwd的輸出結果，繼而導致無法連線資料庫!

2.14 解開所有謎團

1） 存活節點Sqlplus –prelim無法attach到共享記憶體

獲取當前工作目錄時，由於nfs mount點丟失，get_cwd(pwd)掛起

2） Kill -9 無法殺掉部分程式

程式對nfs mount點進行IO操作，掛起，因此沒有機會收到程式終止訊號

3） CRS通過指令碼無法接管故障節點vip,出現超時

Racgwrap指令碼中呼叫了pwd命令

4） CRS通過指令碼無法檢測存活節點本身的vip/監聽等資源，均出現超時

Racgwrap指令碼中呼叫了pwd命令

5） 存活節點Nmon故障點後無輸出

Nfs mount點丟失導致nmon呼叫df命令時掛起

2.15 再往前一步的分析

1.該機制下，如果根目錄/小檔案或目錄很多，則pwd(get_cwd)的效能會很差

2.測試環境重現過程

節點2 mount /testfs到節點1的/testfs,停止節點2 nfs服務，未能重現。原因在於pwd的輸出為/oracle, 首字母o比t要小，因此未檢測到/testfs就獲得pwd結果而退出了

節點2 mount /aa到節點1的/aa,停止節點2 nfs服務，未能重現。原因是通過truss命令對比，發現生產和測試環境檢索/根目錄下的行為不一致，繼而檢查OS版本，發現測試環境OS版本較高

3.高版本的OS無法重現，低版本的作業系統可以重現，說明作業系統做了修正和增強，在ibm.com上已nfs hang搜尋，可以發現IBM釋出了APAR來修復該問題。

Part 3

原因總結和建議

3.1 原因總結

1、RAC叢集節點2所在的P595 發生硬體故障，導致節點2 LPAR不可用。

繼而導致Nfs mount點丟失。

2、登陸資料庫時，需要獲取當前工作目錄(pwd)

3、但是由於AIX某些版本作業系統內部實現pwd過程的缺陷,導致必須遞 歸到根目錄/下檢查目錄或檔案的許可權、型別.

4、當檢查到nfs掛載點目錄/arch2時，由於nfs 以hard/background方式 掛載，當nfs server不可用時，必然導致檢查nfs目錄時出現掛起，繼 而導致了無法獲得pwd的輸出結果，繼而導致無法連線資料庫!

以hard/background掛載的NFS server丟失是導致RAC成為偽叢集的根本原因！

所有故障現象都可以得到解釋，如下：

1、存活節點Sqlplus –prelim無法attach到共享記憶體

獲取當前工作目錄時，由於nfs mount點丟失，get_cwd(pwd)掛起

2、Kill -9 無法殺掉部分程式

程式對nfs mount點進行IO操作，掛起，因此沒有機會收到程式終止訊號

3、CRS通過指令碼無法接管故障節點vip,出現超時

Racgwrap指令碼中呼叫了pwd命令

4、CRS通過指令碼無法檢測存活節點本身的vip/監聽等資源，均出現超時

Racgwrap指令碼中呼叫了pwd命令

5、存活節點Nmon故障點後無輸出

Nfs mount點丟失導致nmon呼叫df命令時掛起

3.2 問題解決方案和建議

1） 如果需要實用nfs,則mount到二級目錄，比如mount到/home /arch 2而不是/arch2

2） 使用gpfs代替nfs

3） 提供故障線索時，請勿根據個人經驗過濾掉認為不重要的資訊

4） 安裝AIX APAR，改變作業系統get_cwd(pwd)呼叫的內部實現方式

5） 處理故障時Df命令hang的情況如果一開始就反饋給小y，那麼這個case直接就解開了，就不需要查了！

6） 只在上線前做高可用測試是不夠的，因為上線後系統會經歷一系列的 變更，可能某些因素會報紙RAC冗餘性丟失，建議定期做高可用測 試，可以選擇在變更視窗選擇逐個重啟例項、伺服器的方式來進行驗證。

 

 

About Me

....................................................................................................................................................

本文來自於微信公眾號轉載文章，若有侵權，請聯絡小麥苗及時刪除

ITPUB BLOG：http://blog.itpub.net/26736162

QQ：642808185 若加QQ請註明您所正在讀的文章標題

【版權所有，文章允許轉載，但須以連結方式註明源地址，否則追究法律責任】

....................................................................................................................................................

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