Exadata 的核心程式

Michael_DD發表於2015-01-20
Exadata 的核心程式


Exadata儲存伺服器執行在Oracle Linux x86_64平臺之上,所有的共享儲存都放置在儲存伺服器上,
除了作業系統以外,儲存伺服器上還使用了Exadata專有的儲存管理軟體。
儲存軟體包括三大核心程式cellsrv, MS和RS。

這三組程式的職責各有不同,各自都發揮著十分重要的作用。以下將逐一對這些程式進行介紹。

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Cellsrv 程式
Cellsrv是Exadata儲存伺服器上最核心的一個程式,它是資料庫伺服器和儲存伺服器伺服器之間的一座橋樑,
用來處理所有的資料庫伺服器和儲存伺服器的之間的通訊。
Cellsrv通常包含以下功能:
? 為簡單的塊請求提供服務。如果一個請求為單塊讀,則cellsrv將其轉化為一個傳統的快取記憶體讀取;
? 為智慧掃描(smart scan)提供服務,如果一個全表/全索引掃描的資料庫請求中包含了direct path read,那麼cellsrv則會執行與之相對應的smart scan。
? 如果使用了IORM, cellsrv對資料庫伺服器和儲存伺服器之間I/O頻寬進行控制;
? Cellsrv同時還會統計和收集各種與其操作相關的統計資訊。

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Restart server 程式
Restart server (RS)是CELLCLI命令列透過執行alter cell startup services rs 建立出來的子程式。
正如其名所暗示的,它主要負責監控MS或者cellsrv等其它一些程式,它還能在其它程式崩潰或者存在記憶體洩漏的情況下自動完成這些程式的重啟,
並且不會對這些程式提供的服務可用性造成影響。在Exadata儲存伺服器上並不存在一個名為RS的程式,實際上RS的工作是由好幾個程式共同來完成的。
Exadata RM
如上圖所示,虛線方框內的程式都是RS的組成部分,他們都以cellrs開頭,如果是監控程式則會包含mt字尾。
其中
? cellrssrm為核心的RS程式
? cellrsbkm為備用的RS程式。
監控程式包括:
? cellrssmt——核心主服務cellrssrm的監控程式
? cellrsbmt——備份服務cellrsbkm的監控程式
? cellrsomt——為cellsrv的監控程式,它會定時發起一種ioctl心跳訊息以確認cellsrv是否存活,如果這個心跳丟失,則會建立一個adrci的時間保留現場以後,將其重啟。cellsrv的狀態資訊存放在$OSSCONF/cellrsos.state檔案內。
? cellrsmmt——為MS的監控程式。主要監控MS的http埠是否正常工作,另外監控MS的記憶體使用情況,確保其在正常範圍以內。MS的狀態資訊存放在$OSSCONF/cellrsms.state檔案中。

MS的告警日誌資訊與cellsrv的告警日誌是都是存放在 $ADR_BASE/diag/asm/cell//trace/alert*.log裡面。同時在這個trace目錄下還能找到監控程式的trace檔案,通常這類檔案以名字中包含rstrc以標識為RS的trace檔案。

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Management server 程式
管理伺服器 (MS) 主要提供 Exadata儲存伺服器配置的功能。很多人會以為CellCLI是Exadata儲存伺服器的配置工具,
但是實際上CellCLI只是Exadata配置管理的一個客戶端工具(grid control外掛也是其中的一個客戶端工具),真正的管理工作是由MS來完成的。
MS的管理範圍僅限於當前的儲存伺服器,如果需要管理多個儲存伺服器,則需要透過dcli工具對遠端的儲存伺服器進行管理。
除了CELLSRV收集的統計資訊以外, MS也會收集其它的一些統計資訊並且同時負責傳送告警資訊。
此外MS程式負責儲存伺服器上的日誌的刪除(deletion)和輪換(rotation),刪除和輪換的詳細策略比較複雜,這裡不一一列出,
請參考Oracle Exadata Storage Server User’s Guide的Understanding Automated Cell Maintenance一節。

MS是一個OC4J的應用程式,它使用Oracle Diagnostic Logging(ODL),其配置檔案一般位於/opt/oracle/cell/oc4j/ms/j2ee/home/config/j2ee-logging.xml。
MS程式標準輸出裝置stdout位於$LOG_HOME/ms.lst 標準的錯誤輸出(stderr )位於$LOG_HOME/ms.err,但是這兩者對於診斷問題通常沒有太大的幫助。
MS的log檔案位於位於 $ADR_BASE/diag/asm/cell//trace/ms-odl.log,其trace檔案位於: $ADR_BASE/diag/asm/cell//trace/ms-odl.trc,
其中其單個檔案最大大小限制為5MB,當檔案大小達到5MB以上,會將自動為其加上.0, .1之類的字尾,
並且會建立一個新的日誌檔案,當然檔案上限數為10個,總大小為50MB。

MS輸出的日誌取決於其日誌所在的tracelevel, 以下都是有效的MS日誌的tracelevel:
? Java logging level , 包括SEVERE, WARNING, INFO, CONFIG, FINE, FINER,FINEST,logging的級別依此遞增。
? Oracle Diagnostic Logging (ODL) logging level
包括INCIDENT_ERROR:1, ERROR:1, WARNING:1, NOTIFICATION:1,
NOTIFICATION:16, TRACE:1, TRACE:16, TRACE:32, logging級別也是一次遞增

當前其預設的logging level為INFO。我們可以透過以下命令來修改ms的tracelevel:
“cellcli -e alter cell tracelevel=finer”

修改完成以後cellinit.ora檔案裡面對應的條目會更新,但是需要重啟MS服務新的tracelevel才能生效。
可以透過命令list cell attributes all來檢視當前的tracelevel。

另外值得一提的重要配置檔案就是cell_disk_config.xml檔案,此檔案位於$OSSCONF目錄,由MS程式進行管理,
裡面幾乎包含了除告警和策略以外所有物件的配置。如果有對一個或者多個物件進行修改時,這個檔案的內容就會被更新。
同樣cellsrv在啟動和在某些情況下需要讀取這個檔案的內容。鑑於這個檔案的重要性,在同一目錄下還存在名稱為cell_disk_config_xml_的檔案,
這些檔案是cell_disk_config.xml的自動備份檔案。這個配置檔案有系統進行自動管理,請不要對其進行手工更新。


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
DSKM 程式
Diskmon是Exadata上的非常重要的一個基礎程式,雖然從名字上來看,diskmon可能是負責對儲存的磁碟進行監控,但是實際上其主要職責是負責監控Exadata儲存伺服器程式和儲存網路,確儲存儲節點能夠正常訪問,如果儲存伺服器無法正常訪問,CRS會向diskmon發出一個I/O fencing的請求,diskmon接收以後將其投遞到儲存伺服器一端。Diskmon程式另外一個功能是將IORM plan推送到儲存伺服器一端。
diskmon個程式位於資料庫伺服器一端,屬於Oracle CRS的一部分,在非Exadata的Oracle叢集環境下,這個程式並沒有使用到。例如在11.2.0.3以前,這個程式是啟動的,但是沒有完成任何實質性工作,在11.2.0.3以後,這個資源預設就是是offline的。在Exadata上,每臺資料庫伺服器上都存在1個主(master)diskmon程式(名稱為diskmon.bin),而每個資料庫例項都存在1個從(slave) diskmon程式(名稱為ora_diskm_sid),主程式監視並將狀態資訊推送給從屬程式。從程式使用 SGA 與 RDBMS或者ASM 程式進行通訊。
Diskmon程式的日誌位於$CRS_HOME/log/hostname/diskmon目錄。但是diskmon的日誌檔案通常對於診斷問題幫助不大,只有在極為特殊的情況下,Oracle的support才會要求提供diskmon的資訊。

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

相關文章