RAC 概念和原理知識

一 叢集環境下的一些特殊問題

 

1.1 併發控制

在叢集環境中， 關鍵資料通常是共享存放的，比如放在共享磁碟上。 而各個節點的對資料有相同的訪問許可權， 這時就必須有某種機制能夠控制節點對資料的訪問。 Oracle RAC 是利用DLM(Distribute Lock Management) 機制來進行多個例項間的併發控制。

 

1.2 健忘症(Amnesia)

叢集環境配置檔案不是集中存放的，而是每個節點都有一個本地副本，在叢集正常執行時，使用者可以在任何節點更改叢集的配置，並且這種更改會自動同步到其他節點。

有一種特殊情況： 節點A 正常關閉， 在節點B上修改配置， 關閉結點A，啟動結點B。 這種情況下，修改的配置檔案是丟失的， 就是所謂的健忘症。

 

1.3 腦裂(Split Brain)

在叢集中，節點間透過某種機制(心跳)瞭解彼此的健康狀態，以確保各節點協調工作。 假設只有"心跳"出現問題， 各個節點還在正常執行， 這時，每個節點都認為其他的節點當機了， 自己是整個叢集環境中的"唯一建在者"，自己應該獲得整個叢集的"控制權"。 在叢集環境中，儲存裝置都是共享的， 這就意味著資料災難， 這種情況就是"腦裂"

解決這個問題的通常辦法是使用投票演算法(Quorum Algorithm). 它的演算法機理如下：

叢集中各個節點需要心跳機制來通報彼此的"健康狀態"，假設每收到一個節點的"通報"代表一票。對於三個節點的叢集，正常執行時，每個節點都會有3票。 當結點A心跳出現故障但節點A還在執行，這時整個叢集就會分裂成2個小的partition。 節點A是一個，剩下的2個是一個。 這是必須剔除一個partition才能保障叢集的健康執行。 

對於有3個節點的叢集， A 心跳出現問題後， B 和 C 是一個partion，有2票， A只有1票。 按照投票演算法， B 和C 組成的叢集獲得控制權， A 被剔除。 

如果只有2個節點，投票演算法就失效了。 因為每個節點上都只有1票。 這時就需要引入第三個裝置：Quorum Device. Quorum Device 通常採用餓是共享磁碟，這個磁碟也叫作Quorum disk。 這個Quorum Disk 也代表一票。 當2個結點的心跳出現問題時， 2個節點同時去爭取Quorum Disk 這一票， 最早到達的請求被最先滿足。 故最先獲得Quorum Disk的節點就獲得2票。另一個節點就會被剔除。

 

1.4 IO 隔離(Fencing)

當叢集系統出現"腦裂"問題的時候，我們可以透過"投票演算法"來解決誰獲得叢集控制權的問題。 但是這樣是不夠的，我們還必須保證被趕出去的結點不能操作共享資料。  這就是IO Fencing 要解決的問題。

IO Fencing實現有硬體和軟體2種方式：

軟體方式：對於支援SCSI Reserve/Release 命令的儲存裝置， 可以用SG命令來實現。 正常的節點使用SCSI Reserve命令"鎖住"儲存裝置， 故障節點發現儲存裝置被鎖住後，就知道自己被趕出了叢集，也就是說自己出現了異常情況， 就要自己進行重啟，以恢復到正常狀態。 這個機制也叫作 Sicide(自殺). Sun 和Veritas 使用的就是這種機制。

硬體方式：STONITH(Shoot The Other Node in the Head)， 這種方式直接操作電源開關，當一個節點發生故障時，另一個節點如果能偵測到，就會透過串列埠發出命令，控制故障節點的電源開關，透過暫時斷電，而又上電的方式使故障節點被重啟動， 這種方式需要硬體支援。

 

二 RAC 叢集

 

2.1 Clusterware

在單機環境下，Oracle是執行在OS Kernel 之上的。 OS Kernel負責管理硬體裝置，並提供硬體訪問介面。 Oracle 不會直接操作硬體，而是有OS Kernel代替它來完成對硬體的呼叫請求。

在叢集環境下， 儲存裝置是共享的。OS Kernel 的設計都是針對單機的，只能控制單機上多個程式間的訪問。 如果還依賴OS Kernel的服務，就無法保證多個主機間的協調工作。 這時就需要引入額外的控制機制，在RAC中，這個機制就是位於Oracle 和 OS Kernel 之間的Clusterware，它會在OS Kernel之前截獲請求，然後和其他結點上的Clusterware協商，最終完成上層的請求。

在Oracle 10G之前，RAC 所需要的叢集件依賴與硬體廠商，比如SUN,HP,Veritas. 從Oracle 10.1版本中，Oracle 推出了自己的叢集產品. Cluster Ready Service(CRS),從此RAC 不在依賴與任何廠商的叢集軟體。 在Oracle 10.2版本中，這個產品改名為：Oracle Clusterware。 

所以我們可以看出， 在整個RAC 叢集中，實際上有2個叢集環境的存在，一個是由Clusterware 軟體組成的叢集，另一個是由Database 組成的叢集。

 

2.2 Clusterware 組成

Oracle Cluster 是一個單獨的安裝包，安裝後，在每個結點上的Oracle Clusterware 會自動啟動。 Oracle Clusterware的執行環境由2個磁碟檔案(OCR,Voting Disk)，若干程式和網路元素組成。 

 

2.2.1 磁碟檔案:

Clusterware 在執行期間需要兩個檔案：OCR和Voting Disk. 這2個檔案必須存放在共享儲存上。 OCR 用於解決健忘問題，Voting Disk 用於解決健忘問題。 Oracle 建議使用裸裝置來存放這2個檔案，每個檔案建立一個裸裝置，每個裸裝置分配100M左右的空間就夠了。

2.2.1.1 OCR

健忘問題是由於每個節點都有配置資訊的複製，修改節點的配置資訊不同步引起的。 Oracle 採用的解決方法就是把這個配置檔案放在共享的儲存上， 這個檔案就是OCR Disk。

OCR 中儲存整個叢集的配置資訊，配置資訊以"Key-Value" 的形式儲存其中。 在Oracle 10g以前， 這個檔案叫作Server Manageability Repository(SRVM). 在Oracle 10g， 這部分內容被重新設計，並重名為OCR.在Oracle Clusterware 安裝的過程中， 安裝程式會提示使用者指定OCR位置。並且使用者指定的這個位置會被記錄在/etc/oracle/ocr.Loc(Linux System) 或者/var/opt/oracle/ocr.Loc(Solaris System)檔案中。 而在Oracle 9i RAC中，對等的是srvConfig.Loc檔案。 Oracle Clusterware在啟動時會根據這裡面的內容從指定位置讀入OCR 內容。

1). OCR key

整個OCR 的資訊是樹形結構，有3個大分支。分別是SYSTEM,DATABASE 和CRS。每個分支下面又有許多小分支。這些記錄的資訊只能由root使用者修改。

 

2) OCR process

Oracle Clusterware 在OCR中存放叢集配置資訊，故OCR 的內容非常的重要，所有對OCR的操作必須確保OCR 內容完整性，所以在ORACLE Clusterware執行過程中，並不是所有結點都能操作OCR Disk. 

在每個節點的記憶體中都有一份OCR內容的複製，這份複製叫作OCR Cache。 每個結點都有一個OCR Process 來讀寫OCR Cache，但只有一個節點的OCR process能讀寫OCR Disk中的內容，這個節點叫作OCR Master結點。 這個節點的OCR process 負責更新本地和其他結點的OCR Cache內容。

所有需要OCR 內容的其他程式，比如OCSSD,EVM等都叫作Client Process， 這些程式不會直接訪問OCR Cache，而是像OCR Process傳送請求，藉助OCR Process獲得內容，如果想要修改OCR 內容，也要由該節點的OCR Process像Master node 的OCR process 提交申請，由Master OCR Process完成物理讀寫，並同步所有節點OCR Cache中的內容。

 

   2.2.1.2  Voting Disk

Voting Disk 這個檔案主要用於記錄節點成員狀態，在出現腦裂時，決定那個Partion獲得控制權，其他的Partion必須從叢集中剔除。在安裝Clusterware時也會提示指定這個位置。 安裝完成後可以透過如下命令來檢視Voting Disk位置。

$Crsctl query css votedisk

 

2.2.2 Clusterware 後臺程式

Clusterware 由若干程式組成，其中最重要的3個是：CRSD,CSSD,EVMD. 在安裝clusterware的最後階段，會要求在每個節點執行root.sh 指令碼， 這個指令碼會在/etc/inittab 檔案的最後把這3個程式加入啟動項，這樣以後每次系統啟動時，Clusterware 也會自動啟動，其中EVMD和CRSD 兩個程式如果出現異常，則系統會自動重啟這兩個程式，如果是CSSD 程式異常，系統會立即重啟。

   1). OCSSD

      OCSSD 這個程式是Clusterware最關鍵的程式，如果這個程式出現異常，會導致系統重啟，這個程式提供CSS(Cluster Synchronization Service)服務。 CSS 服務透過多種心跳機制實時監控叢集狀態，提供腦裂保護等基礎叢集服務功能。

CSS 服務有2種心跳機制： 一種是透過私有網路的Network Heartbeat，另一種是透過Voting Disk的Disk Heartbeat.

這2種心跳都有最大延時，對於Disk Heartbeat， 這個延時叫作IOT (I/O Timeout);對於Network Heartbeat, 這個延時叫MC(Misscount)。 這2個引數都以秒為單位，預設時IOT大於MC，在預設情況下，這2個引數是Oracle 自動判定的，並且不建議調整。可以透過如下命令來檢視引數值：

$crsctl get css disktimeout

$crsctl get css misscount

   注：除了Clusterware 需要這個程式，在單節點環境中如果使用了ASM，也需要這個程式；這個程式用於支援ASM Instance 和RDBMS Instance之間的通訊。 如果在使用了ASM的節點上安裝RAC，會遇到一個問題：RAC節點要求只有一個OCSSD程式，並且應該是執行$CRS_HOME目錄下的，這時就需要先停止ASM，並透過$ORACLE_HOME/bin/localcfig.Sh delete 刪除之前的inittab 條目。 之前安裝ASM時，也使用這個指令碼來啟動OCSSD： $ORACLE_HOME/bin/localconfig.Sh add. 

 

2). CRSD

  CRSD是實現"高可用性(HA)"的主要程式，它提供的服務叫作CRS(Cluster Ready Service) 服務。

Oracle Clusterware是位於叢集層的元件，它要為應用層資源(CRS Resource) 提供"高可用**"，所以， Oracle Clusterware 必須監控這些資源，並在這些資源執行異常時進行干預，包括關閉，重啟程式或者轉移服務。CRSD程式提供的就是這些服務。

所有需要 高可用性 的元件，都會在安裝配置的時候，以CRS Resource的形式登記到OCR中，而CRSD 程式就是根據OCR中的內容，決定監控哪些程式，如何監控，出現問題時又如何解決。也就是說，CRSD 程式負責監控CRS Resource 的執行狀態，並要啟動，停止，監控，Failover這些資源。 預設情況下，CRS 會自動嘗試重啟資源5次，如果還是失敗，則放棄嘗試。

CRS Resource 包括GSD(Global Serveice Daemon),ONS(Oracle Notification Service),VIP, Database, Instance 和 Service. 這些資源被分成2類：

GSD，ONS,VIP 和 Listener 屬於Noteapps類

Database，Instance 和Service 屬於 Database-Related Resource 類。

 

我們可以這樣理解： Nodeapps 就是說每個節點只需要一個就夠了，比如每個節點只有一個Listener，而Database-Related Resource 就是說這些資源和資料庫有關，不受節點的限制，比如一個節點可以有多個例項，每個例項可以有多個Service。

GSD，ONS,VIP 這3個服務是在安裝Clusterware的最後，執行VIPCA 時建立並登記到OCR中的。 而Database， Listener， Instance 和Service 是在各自的配置過程中自動或者手動登記到OCR中的。

 

  3). EVMD

     EVMD 這個程式負責釋出CRS 產生的各種事件(Event). 這些Event可以透過2種方式釋出給客戶：ONS 和 Callout Script. 使用者可以自定義回撥指令碼，放在特定的目錄下，這樣當有某些事件發生時，EVMD會自動掃描該目錄，並呼叫使用者的指令碼，這種呼叫是透過racgevt程式來完成的。

EVMD 程式除了複雜釋出事件之外，它還是CRSD 和CSSD 兩個程式之間的橋樑。 CRS 和CSS 兩個服務之前的通訊就是透過EVMD 程式完成的。

 

  4). RACGIMON

     RACGIMON 這個程式負責檢查資料庫健康狀態，負責Service的啟動，停止，故障轉移(Failover)。 這個程式會建立到資料庫的持久連線，定期檢查SGA中的特定資訊，該資訊由PMON 程式定時更新。

 

   5). OPROCD

OPROCD 這個程式也叫作 Process Monitor Daemon. 如果在非Linux 平臺上，並且沒有使用第三方的叢集軟體時，就會看到這個程式。 這個程式用來檢查節點的Processor Hang(CPU 掛起), 如果排程時間超過1.5秒， 就會認為CPU 工作異常，會重啟節點。 也就是說這個程式提供 "IO 隔離" 的功能。 從其在Windows 平臺上的服務名： OraFnceService 也可以看出它的功能。 而在Linux 平臺上， 是利用Hangcheck-timer 模組來實現"IO 隔離"的。

 

 

2.3 VIP 原理和特點

Oracle 的TAF 就是建立在VIP 技術之上的。 IP 和VIP 區別在與： IP 是利用TCP層超時， VIP 利用的是應用層的立即響應。VIP 它是浮動的IP. 當一個節點出現問題時會自動的轉到另一個節點上。

假設有一個2個節點的RAC，正常執行時每個節點上都有一個VIP。 VIP1 和VIP2. 當節點2發生故障，比如異常關係。 RAC 會做如下操作：

1). CRS 在檢測到rac2節點異常後，會觸發Clusterware 重構，最後把rac2節點剔除叢集，由節點1組成新的叢集。

2). RAC的Failover 機制會把節點2的VIP轉移到節點1上，這時節點1的PUBLIC 網路卡上就有3個IP 地址： VIP1,VIP2, PUBLIC IP1.

3). 使用者對VIP2的連線請求會被IP層路由轉到節點1

4). 因為在節點1上有VIP2的地址，所有資料包會順利透過路由層，網路層，傳輸層。

5). 但是，節點1上只監聽VIP1和public IP1的兩個IP地址。並沒有監聽VIP2，故應用層沒有對應的程式接收這個資料包，這個錯誤立即被捕獲。

6). 客戶段能夠立即接收到這個錯誤，然後客戶段會重新發起向VIP1的連線請求。

 

   VIP 特點：

     1). VIP 是透過VIPCA指令碼建立的

     2). VIP 作為Nodeapps型別的CRS Resource 註冊到OCR中，並由CRS 維護狀態。

     3). VIP 會繫結到節點的public 網路卡上，故public 網路卡有2個地址。

     4). 當某個節點發生故障時，CRS 會把故障節點的VIP 轉移到其他節點上。

5). 每個節點的Listener 會同時監聽public 網路卡上的 public ip 和VIP

6). 客戶端的tnsnames.Ora 一般會配置指向節點的VIP.

 

 

2.4 Clusterware 的日誌體系

Oracle Clusterware的輔助診斷，只能從log 和trace 進行。 而且它的日誌體系比較複雜。 

 

alert.log:

 $ORA_CRS_HOME/log/hostname/alert.Log, 這是首選的檢視檔案。

 

Clusterware後臺程式日誌：

crsd.Log: $ORA_CRS_HOME/log/hostname/crsd/crsd.Log

ocssd.Log: $ORA_CRS_HOME/log/hostname/cssd/ocsd.Log

evmd.Log: $ORA_CRS_HOME/log/hostname/evmd/evmd.Log

 

Nodeapp日誌位置：

$ORA_CRS_HOME/log/hostname/racg/

 這裡面放的是nodeapp的日誌，包括ONS和VIP，比如：ora.Rac1.ons.Log

 

工具執行日誌：

$ORA_CRS_HOME/log/hostname/client/

Clusterware 提供了許多命令列工具： 

比如ocrcheck, ocrconfig,ocrdump,oifcfg和clscfg, 這些工具產生的日誌就放在這個目錄下

 

還有$ORACLE_HOME/log/hostname/client/ 和

$ORACLE_HOME/log/hostname/racg 也有相關的日誌。