瞭解Oracle RAC Brain Split Resolution叢集腦裂協議

CSS工作原理

在理解腦裂(Brain Split)處理過程前，有必要介紹一下Oracle RAC Css(Cluster Synchronization Services)的工作架構:

Oracle RAC CSS提供2種後台服務包括群組管理(Group Managment簡稱GM)和節點監控(Node Monitor簡稱NM)，其中GM管理組(group)和鎖(lock)服務。在叢集中任意時刻總有一個節點會充當GM主控節點(master node)。叢集中的其他節點串列地將GM請求發送到主控節點(master node)，而master node將叢集成員變更資訊廣播給叢集中的其他節點。群組成員關係(group membership)在每次發生叢集重設(cluster reconfiguration)時發生同步。每一個節點獨立地詮釋叢集成員變化資訊。

而節點監控NM服務則負責通過skgxn(skgxn-libskgxn.a，提供節點監控的庫)與其他廠商的叢集軟體保持節點資訊的一致性。此外NM還提供對我們熟知的網路心跳(Network heartbeat)和磁碟心跳(Disk heartbeat)的維護以保證節點始終存活著。當叢集成員沒有正常Network heartbeat或Disk heartbeat時NM負責將成員踢出叢集，被踢出叢集的節點將發生節點重啟(reboot)。

NM服務通過OCR中的記錄(OCR中記錄了Interconnect的資訊)來瞭解其所需要監聽和互動的端點，將心跳資訊通過網路發送到其他叢集成員。同時它也監控來自所有其他叢集成員的網路心跳Network heartbeat，每一秒鐘都會發生這樣的網路心跳，若某個節點的網路心跳在misscount(by the way:10.2.0.1中Linux上預設misscount為60s，其他平台為30s，若使用了第三方vendor clusterware則為600s，但10.2.0.1中未引入disktimeout；10.2.0.4以後misscount為60s,disktimeout為200s；11.2以後misscount為30s:CRS-4678: Successful get misscount 30 for Cluster Synchronization Services,CRS-4678: Successful get disktimeout 200 for Cluster Synchronization Services)指定的秒數中都沒有被收到的話，該節點被認為已經”死亡”了。NM還負責當其他節點加入或離開叢集時初始化叢集的重設(Initiates cluster reconfiguration)。

在解決腦裂的情境中，NM還會監控voting disk以瞭解其他的競爭子叢集(subclusters)。關於子叢集我們有必要介紹一下，試想我們的環境中存在大量的節點，以Oracle官方構建過的128個節點的環境為我們的想象空間，當網路故障發生時存在多種的可能性，一種可能性是全域的網路失敗，即128個節點中每個節點都不能互相發生網路心跳，此時會產生多達128個的資訊”孤島”子叢集。另一種可能性是局部的網路失敗，128個節點中被分成多個部分，每個部分中包含多於一個的節點，這些部分就可以被稱作子叢集(subclusters)。當出現網路故障時子叢集內部的多個節點仍能互相通訊傳輸投票資訊(vote mesg),但子叢集或者孤島節點之間已經無法通過常規的Interconnect網路交流了，這個時候NM Reconfiguration就需要用到voting disk投票磁碟。

Voting Disk

因為NM要使用voting disk來解決因為網路故障造成的通訊障礙，所以需要保證voting disk在任意時刻都可以被正常訪問。在正常狀態下，每個節點都會進行磁碟心跳活動，具體來說就是會到投票磁碟的某個塊上寫入disk心跳資訊，這種活動每一秒鐘都會發生，同時CSS還會每秒讀取一種稱作”kill block”的”賜死塊”，當”kill block”的內容表示本節點被驅逐出叢集時，CSS會主動重啟節點。

為了保證以上的磁碟心跳和讀取”kill block”的活動始終正常運作CSS要求保證至少(N/2+1)個投票磁碟要被節點正常訪問，這樣就保證了每2個節點間總是至少有一個投票磁碟是它們都可以正常訪問的，在正常情況下(注意是風平浪靜的正常情況)只要節點所能訪問的線上voting disk多於無法訪問的voting disk，該節點都能幸福地活下去，當無法訪問的voting disk多於正常的voting disk時，Cluster Communication Service進程將失敗並引起節點重啟。所以有一種說法認為voting disk只要有2個足以保證冗餘度就可以了，沒有必要有3個或以上voting disk，這種說法是錯誤的。Oracle推薦叢集中至少要有3個voting disks。

Question:

有同學問那麼voting disk  必須是奇數個呢？

Answer:

實際上我們僅僅是推薦使用奇數個vote disk ，而非必須是奇數個。10gR2中vote disk的數目上限是32個。

Question

我們可以使用2或4個vote disk嗎？

Answer:

可以的。 但是2、4這樣的數目在“至少(N/2+1)個投票磁碟要被節點正常訪問”這一disk heartbeat的硬性演算法下是不利的：

當我們使用2個vote disk 時，不能發生任意個vote disk的心跳失敗

當我們使用3個vote disk 時，不能發生大於1個的vote disk心跳失敗

當我們使用4個vote disk 時，不能發生大於1個的vote disk心跳失敗 ，這和3個時的容錯率是一樣，但是因為我們有更多的vote disk，這會導致管理成本和引入的風險增長

當我們使用5個vote disk 時，不能發生大於2個的vote disk心跳失敗

當我們使用6個vote disk 時，仍然不能發生大於2個的vote disk心跳失敗， 同樣的因為比5時多出一個 ，也會引入不合理的管理成本和風險

Question:

若節點間的網路心跳正常，且節點所能正常心跳的vote disk 大於不能正常訪問的 ，如3個votedisk 時恰巧有1個vote disk 的disk heartbeat 逾時，此時Brain split 會發生嗎？

Answer:

這種情況即不會觸發Brain Split，也不會引發節點驅逐協議(eviction protocol)。 當單個或小於(N/2+1)個的voting disk心跳失敗(disk heartbeat failure)時，這種心跳失敗可能是由於短期內節點訪問voting disk發生I/O error錯誤而引起的，此時css會立刻將這些失敗的voting disk標記為OFFLINE。雖然有一定數量的voting disk OFFLINE了，但是我們仍有至少(N/2+1)個投票磁碟可用，這保證了eviction protocol不會被調用，所以沒有節點會被reboot重啟。緊接著node monitor模組的Disk ping Monitor Thread(DPMT-clssnmDiskPMT)會重複嘗試訪問這些失敗的OFFLINE voting disk，若這些投票磁碟變得再次可I/O訪問且經過驗證其上的資料也沒有訛誤，那麼css會再次將此voting disk標記為ONLINE；但是如果在45s( 這裡的45s是基於misscount和 內部演算法獲得的) 內仍不能正常訪問相關的voting disk，那麼DMPT將在cssd.log中產生警告資訊，如：

CSSD]2011-11-11 20:11:20.668 >

WARNING: clssnmDiskPMT: long disk latency >(45940 ms) to voting disk (0//dev/asm-votedisk1)

假設以上發生clssnmDiskPMT警告的RAC情境共有3個voting disk，現已有一個asm-votedisk1因為I/O error或其他原因而被標記為OFFLINE，若此時再有一個votedisk也出現了問題並disk heartbeat 失敗，那麼節點會因為少於規定數目(2)的votedisk而引發eviction protocol，進而重啟reboot。

單個或小於(N/2+1)個的voting disk心跳失敗都僅僅產生警告(Warning)，而非致命的錯誤。因為仍有絕大數量的vote disk可被訪問，因此產生的警告都是非致命的，eviction protocol將不會被觸發。

1 2 3 4 5 下一頁