作者為:? SHOUG成員 – ORACLE ACS高級顧問羅敏 Oracle公司自10g版本開始就推出了集群管理軟件CRS,以后又升級改造成Clusterware,到11g版本之后更是大動干戈,內(nèi)部架構(gòu)進(jìn)行了大幅度改造,并與ASM技術(shù)整合在一起,稱之為GI(Grid Infrastructure)。Clusterw
作者為:?
Oracle公司自10g版本開始就推出了集群管理軟件CRS,以后又升級改造成Clusterware,到11g版本之后更是大動干戈,內(nèi)部架構(gòu)進(jìn)行了大幅度改造,并與ASM技術(shù)整合在一起,稱之為GI(Grid Infrastructure)。Clusterware替代了硬件廠商和第三方廠商的集群軟件功能,也使得Oracle RAC與Clusterware集成為一體,在產(chǎn)品的整體性、服務(wù)支持一體化等方面具有顯著優(yōu)勢。
作為新產(chǎn)品、新技術(shù),穩(wěn)定性、成熟性略差,情有可原。但到了11g仍然如此,則讓人難以理解了。
本人最近在Windows 2012平臺實施了2節(jié)點11.2.0.4 RAC,并通過增加節(jié)點方式擴展到了4節(jié)點RAC,在國內(nèi)實屬罕見案例。期間一些波折,表明 Clusterware產(chǎn)品仍然不成熟。
話說那天我在實施節(jié)點擴展操作之前,先花費了半天時間進(jìn)行了新節(jié)點的環(huán)境準(zhǔn)備之后,并通過如下命令進(jìn)行了環(huán)境檢查:
cluvfy stage -pre nodeadd -n hsedb3 –verbose
… …
節(jié)點 “hsedb3″ 上的共享存儲檢查成功
硬件和操作系統(tǒng)設(shè)置 的后期檢查成功。
喲,一切都“成功”,開練了!于是,我按照Oracle文檔標(biāo)準(zhǔn)流程在節(jié)點1開始運行AddNode.bat腳本了,一切“正?!保∥依^續(xù)在節(jié)點3運行了gridconfig.bat等腳本。
待所有腳本順利運行完之后檢查環(huán)境時,卻發(fā)現(xiàn)節(jié)點3根本沒有加入到集群環(huán)境中,節(jié)點3上的Clusterware服務(wù)也根本沒有啟動。—– 這就是產(chǎn)品的嚴(yán)重不成熟,明明出問題了,所有腳本卻不顯示任何一條返回錯誤,顯示一切正常!更可氣的是,AddNode.bat腳本的日志文件(addNodeActions2014-09-07_04-52-22PM.log)也居然顯示一切正常,最后還來一句:
*** 安裝 結(jié)束 頁***
C:\app\11.2.0\grid 的 添加集群節(jié)點 已成功。
我知道Oracle支持在Windows平臺進(jìn)行RAC加節(jié)點操作,但現(xiàn)在沒有成功,一定是我犯什么錯誤了,也肯定知道有什么錯誤信息藏在什么鳥日志文件里了。無奈天色已晚,忙乎一天了,于是先打道回府了。
隔日,待我回到現(xiàn)場仔細(xì)分析各類Clusterware日志文件信息時,首先在alerthsedb3.log文件中大海撈針般地發(fā)現(xiàn)了出錯信息:
[cssd(4484)]CRS-1649:表決文件出現(xiàn) I/O 錯誤: \\.\ORCLDISKORADG0; 詳細(xì)信息見 (:CSSNM00059:) (位于 C:\app\11.2.0\grid\log\hsedb3\cssd\ocssd.log)。
于是,按圖索驥繼續(xù)去查詢ocssd.log文件中的信息。又像偵探一樣,在ocssd.log文件8千多行的日志信息中發(fā)現(xiàn)了如下錯誤信息:
2014-09-07 17:00:06.192: [?? SKGFD][4484]ERROR: -9(Error 27070, OS Error (OSD-04016: 異步 I/O 請求排隊時出錯。
O/S-Error: (OS 19) 介質(zhì)受寫入保護。)
此時,其實本人已經(jīng)覺察出問題了:可能是節(jié)點3對存儲設(shè)備只有讀權(quán)限,連表決盤(Voting Disk)都沒有寫入功能,從而導(dǎo)致失敗了。為保險期間,還是根據(jù)上述出錯信息在Metalink中進(jìn)行了一番搜索,果然如此!《Tablespace (Datafile) Creation On ASM Diskgroup Fails With “[ORA-15081: Failed To Submit An I/O Operation To A Disk] : [ O/S-Error: (OS 19) The media Is Write Protected]” On Windows. ( Doc ID 1551766.1 )》詳細(xì)描述了原委和解決方案。于是,按照該文檔的建議,我將節(jié)點3對所有共享存儲設(shè)備的權(quán)限從只讀狀態(tài)修改為可讀、可寫的聯(lián)機狀態(tài)。也明白一個細(xì)節(jié):新節(jié)點對共享存儲設(shè)備的權(quán)限缺省為只讀狀態(tài)。無論如何,安裝之前沒有仔細(xì)檢查共享存儲設(shè)備的權(quán)限是我犯的一個錯誤。
接下來該是重新進(jìn)行節(jié)點增加操作了。且慢!因為前面已經(jīng)錯誤地進(jìn)行了節(jié)點增加操作,而且居然顯示成功了,那么運行AddNode.bat腳本的節(jié)點1肯定已經(jīng)在OCR、Voting Disk等集群文件中寫入節(jié)點3不正確的信息了。因此,需要先實施從集群中刪除節(jié)點3的操作,但是發(fā)現(xiàn)Oracle標(biāo)準(zhǔn)文檔中的刪除節(jié)點操作的如下第一條命令有錯誤!
C:\>Grid_home\perl\bin\perl -I$Grid_home\perl\lib -I$Grid_home\crs\install
Grid_home\crs\install\rootcrs.pl -deconfig -force
又是一番折騰,將上述命令修改如下:
cd \app\11.2.0\grid
C:\>perl\bin\perl -I perl\lib -I crs\install crs\install\rootcrs.pl -deconfig –force
終于順利刪除了節(jié)點3!
現(xiàn)在可以重新來一遍了。這次一馬平川地成功增加了節(jié)點3的Clusterware以及RAC,還有節(jié)點4的Clusterware和RAC。
感悟之一:明明節(jié)點3對共享存儲只有讀權(quán)限,而cluvfy卻說:節(jié)點 “hsedb3″ 上的共享存儲檢查成功!一定是cluvfy只檢查了讀權(quán)限,而沒有檢查寫權(quán)限。很可能是cluvfy的Bug!
感悟之二:明明增加節(jié)點3的操作失敗了。但不僅AddNode.bat沒有在命令行及時顯示錯誤,而且對應(yīng)的日志文件還顯示“添加集群節(jié)點已成功”。極大地誤導(dǎo)客戶!罪不可?。?/p>
感悟之三:診斷Clusterware問題太難了!Oracle公司沒有告訴客戶Clusterware問題的診斷思路,特別是日志文件太多了,不知道先看哪個日志文件,后看哪個日志文件。此次本人完全是憑經(jīng)驗,先看了alerthsedb3.log文件,才找到問題的蛛絲馬跡,進(jìn)而逐步確認(rèn)問題并加以解決。
… …
總之,Clusterware仍然是一個非常不成熟的產(chǎn)品!
Related posts:
原文地址:Oracle Acs資深顧問羅敏 老羅技術(shù)核心感悟:Clusterware是成熟產(chǎn)品嗎?, 感謝原作者分享。
聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com