[zt]10G RAC中的CSS DISKTIMEOUT, MISSCOUNT, VOTINGDISK

轉載自   

這篇文章是偶用半生不熟的E文翻譯過來的，所以很多可能看著很彆扭，E文好的建議直接看原文，在METALINK中的294430.1，284752.1和309542.1三篇文章中。

CSS的MISSCOUNT引數定義了叢集重新配置並驅逐一個節點前，這個節點的心跳可以缺失的時間，單位是秒。其中各個平臺的預設的MISSCOUNT如下：
Linux下60秒，Unix、VMS和Windows下都是30秒，對於其他非ORACLE提供的CLUSTER來說，預設的MISSCOUNT是600秒，這是為了給其他的叢集提供商提供足夠的時間來解決任何場景下的腦裂。

CSS心跳的機制和他們之間的相互關係:

 

ORACLE CLUSTERWARE的同步服務元件維護兩種心跳機制。
1、對於投票裝置的磁碟心跳
2、透過內網互連的網路心跳來驗證叢集中的成員的有效性。
這兩種心跳機制有一個聯合的超時時間，磁碟心跳有一個內在的以秒為單位的超時間隔（簡稱：IOT），這個時間內對投票盤的I/O必須完成。MISSCOUNT引數是網路心跳可以丟失的次數，以秒計。磁碟心跳的I/O超時間隔直接和MISSCOUNT引數（簡稱：MC）的設定相關。這些咚咚的關聯關係如下：
1、9的版本中MISCOUNT不是上面描述的那些含義
2、10.1.0.2的版本中沒有這些設定
3、10.1.0.3版本中的IOT=MC-15 seconds
4、10.1.0.4版本中，IOT = MC - 15 seconds
5、10.1.0.4打上3306964BUG的補丁後，IOT = MC - 3 seconds
6、10.1.0.4打上CRS II Merge patch後，IOT=預設的200秒的DISKTIMEOUT設定，或者在CLUSTER的初始配置或者重新配置的時候的MISSCOUNT的設定。（下面的原文不知道怎麼翻譯何時，所以原文抄在這裡吧。）
IOT=Disktimeout (Defaults to 200 seconds) Normally OR Misscount seconds only during initial Cluster formation or Slightly before reconfiguration
7、10.1.0.5版本上的IOT = MC - 3S
8、10.2.0.1打上4896338 BUG補丁後，IOT=預設的200秒的DISKTIMEOUT設定，或者在CLUSTER的初始配置或者重新配置的時候的MISSCOUNT的設定。
9、10.2.0.2的版本，IOT=預設的200秒的DISKTIMEOUT設定，或者在CLUSTER的初始配置或者重新配置的時候的MISSCOUNT的設定。

對於投票磁碟的過長的反應時間:
如果對投票磁碟的I/O的反應時間大於IOT的時間，則CLUSTER將會對CSS的節點進行驅逐。這個第一取決於CRS的版本，第二取決於是否應用了merge的補丁，第三是CLUSTER的狀態。

產生這樣的問題有很多的原因，下面總結了大部分的情況：
QLOGIC HBA卡的連線宕掉的時間大於了MC
SAN或者儲存的線纜損壞導致I/O超時
SAN交換機的FAILOVER的響應時間大於MC設定
EMC Clariion Array的trespassing SP到備份SP的時候的時間超過了MC設定
EMC PowerPath的路徑錯誤並且I/O重新投遞並重定向的時間大於MC設定
NETAPP叢集的FAILOVER的響應時間大於MC
持續的高CPU負載影響的CSSD的程式進行對磁碟的ping操作
差的SAN網路配置使得I/O路徑上的響應實現超過MC
大多數情況和多路徑的軟體相關，而且是因為IO路徑的FAILOVER後的重配置時間過長

MISSCOUNT在上面提到的情況中是不應該被修改的。

應用了Bug 4896338的補丁後的10.2.0.1版本的行為
10.2.0.1打上4896338的補丁後，當對投票磁碟的I/O超過MC的設定時，CSS不會把節點驅逐出CLUSTER，除非這個發生在CLUSTER初始化或者重配置的時候。所以，如果我們有N個成員的CLUSTER節點中，如果一個節點因為訪問投票磁碟而發生超時的時候，只要在DISKTIMEOU時間內能完成這次磁碟訪問，這個節點不會被驅逐。所以，應用了這個PATCH後，就不需要增加MISSCOUNT的設定了。這個patch引入的DISKTIMEOUT引數，這個是能夠容忍的最大的對投票磁碟訪問的預設時間

下面描述了驅逐行為發生的條件：
1、都不超時，不會驅逐
2、網路PING在MC時間內完成，磁碟ping超過了MC，但是在DISKTIMEOUT內完成，也不會驅逐
3、網路ping在MC時間內完成，磁碟ping超過了DISKTIMEOUT，則節點被驅逐
4、網路ping超過MC設定，磁碟ping在MC內完成，節點也會被驅逐
預設情況下，MC是小於DISKTIMEOUT設定的

MISSCOUNT驅動著CLUSTER中的成員的重新配置並且直接影響對CLUSTER的訪問。大多數情況下，預設的MC設定可以被接受，改變預設的MISSCOUNT不僅僅影響投票磁碟的I/O訪問的超時時間，同時也會影響內網互連的網路心跳的超時時間。當修改預設的MISSCOUNT值的時候應該考慮的問題：
增加MISSCOUNT的設定來解決I/O響應時間會直接導致網路失敗時的重配置時間。網路心跳是cluster中的節點間連通性的主導，MISSCOUNT是觸發cluster發生重配置前能夠容忍發生多少的“check ins”，增加MISSCOUNT設定會延長對網路失敗的診斷的時間，這將直接影響cluster的可訪問性。

如果是因為底層磁碟的響應時間問題而修改了MISSCOUNT的值，那麼底層地盤的問題解決後，要立刻修改MISSCOUNT回到預設值。
如果是在第三方提供的CLUSTERWARE上實現的叢集，則不要修改MISSCOUNT的預設值，在這樣的環境中修改預設的MISSCOUNT將會導致更多的消耗和潛在的危險。
下面情況下不應該修改MISSCOUNT：
1、修改MISSCOUNT的值來避免因為底層的配置或者硬體的問題導致的超時
2、CLUSTER和資料庫的可訪問性直接受很高的MISSCOUNT設定的影響。

在Oracle RAC 10g Release 2 版本中允許設定多個的投票磁碟，從而不必依靠儲存提供商的多路徑的方式來解決磁碟訪問的問題，你可以設定最多32個投票磁碟。

可以透過如下的方式來修改MISSCOUNT的設定：
1、首先停止CRS：
可以使用指令碼來停止：
不同平臺的指令碼存放的地方如下：
* For Solaris, the scripts are in /etc/init.d/
* For HP, the scripts are in /sbin/init.d
* For AIX, the scripts are in /etc
* For Linux, the scripts are in /etc/init.d
在上面的路徑上執行init.crs stop指令碼來停止，執行init.crs start來啟動。
在10G RELEASE2版本中可以使用crsctl stop crs停止並使用crsctl start crs來啟動。

2、設定MISSCOUNT為N
1) 除了一個節點外，關閉其他所有節點的CRS
2) 執行$ORA_CRS_HOME/bin/crsctl set css misscount
其中n為投票盤的響應時間＋1
3) 重啟動修改了MISSCOUNT引數的節點（這個需要測試是否是必須）
4) 啟動所有其他的節點的CRS

打了4896338補丁後的10.2.0.1版本有兩個附加的引數可以調整，這個改變直接包含在了10.2.0.2和10.1.0.6版本中
1) reboottime (預設是3秒) -它定義了節點被CSS驅逐後到開始重啟的時間間隔，也就是當你重啟機器的時候機器完全關閉需要的時間。（這個間隔難道是為了正常關閉其他服務？）
2) disktimeout (預設200秒) -對投票盤的I/O完成所允許的最大時間，如果達到了這個時間，則投票盤會被標識為OFFLINE。
Note that this is also the amount of time that will be required for initial cluster formation, i.e. when no nodes have previously been up and in a cluster.

$CRS_HOME/bin/crsctl set css reboottime [-force] ( is seconds)
$CRS_HOME/bin/crsctl set css disktimeout [-force] ( is seco

可以透過ocrdump命令來檢視MISSCOUNT的設定，OCR備份的時間、路徑、OCR的磁碟等資訊。