從ORACLE RAC角度看跨數據中心的存儲雙活配置注意事項

ORACLE RAC在設計的時候是沒有考慮跨數據中心雙活的，它的設計目的是爲一個數據中心內有着共享存儲的多個主機實現負載均衡和高可用性。可是因爲它的架構確實有着跨數據中心實現負載均衡和高可用性的潛力，因此有幾家存儲設備供應商對它的使用環境作了擴展，提出了跨數據中心的解決方案。ORACLE對此採起了默認的態度，可是建議全部的解決方案在投入客戶生產以前進行仔細的測試。

 

對於RAC而言，跨數據中心解決方案的最大瓶頸是節點之間的interconnect，由於它對時延和帶寬的要求都很是高。通常而言，本地interconnect傳輸時延在1~2ms之間，本地IO的延時則在8~15ms之間。這兩個時延對性能的影響至關大，若是使用雙數據中心方案，隨着機房距離的增加，它們都會嚴重影響性能。並且因爲interconnect的時延基數低（1~2ms），致使機房距離產生的時延對整個interconnect影響的佔比更大：想一想若是由於距離延長致使2ms的傳輸延遲，對於interconnect就是100%~200%的延遲增加，對於IO則只有15%~25%的增加。固然，隨着SSD在存儲中的大量使用，距離對IO的影響也在加大。

 

爲了直觀展現傳輸距離對IO和interconnect延時的影響，圖一和圖二顯示了HP的測試結果做爲參考：

圖一

圖一顯示的是IO時延受距離影響的結果，這個測試結果是在Buffer-to-Buffer Credits(BBC)功能打開狀況下取得的。BBC功能可讓大量的未應答的數據包保存在緩存的同時繼續發送數據包。在數據流量很大的狀況下，距離越遠，BBC的做用越大。

若是在距離100km的狀況下，打開BBC，IO延遲與本地相比大約爲增長43%；若是不打開BBC，IO延遲大約增加120~140%。另外一個廠家的測試代表，在20km的距離下，不打開BBC將會致使流量降低20~24%。

 

圖二則是分別使用高負荷和低負荷對配置一條或者兩條interconnect的RAC進行測試，考察了距離對interconnect的影響。

圖二

圖二這個測試有兩個發現：

1.        兩條鏈路與一條鏈路相比，在高負荷狀況下能夠大約下降50%時延

2.        100km能夠帶來大約1ms的時延增長。

 

圖一和圖二顯示的是距離對鏈路的影響，下面的圖三和圖四則展現距離對RAC總體性能的影響。

因爲在遠距離傳輸過程當中，Buffer-to-Buffer Credits(BBC)功能對傳輸性能影響很大，因此須要強調圖三展現了兩個廠家在打開BBC功能狀況下取得的測試結果。同時做爲對比，圖四展現的是沒有打開BBC功能的測試結果。

從圖三和圖四中能夠看到，打開BBC的狀況下，兩個測試廠商在的方案性能都至關不錯。可是若是不打開BBC，隨着距離延長，性能會有劇烈下滑。考慮到同機房配置比較好的雙節點RAC性能大約比單節點高30~60%，若是由於遠程機房RAC集羣出現大於20%的性能降低，就要慎重考慮是否使用RAC方案了。

 

還有兩點須要注意的是：

1.        各廠家給出的測試結果每每是在極致優化的狀況下測得的最佳數據，實際客戶現場的優化程度每每大幅低於廠家測試環境

2.        廠家每每只會給出對本身最優的測試結果。好比圖三中兩個廠家給出的測試距離範圍是不同的，緣由多是超出該範圍，性能會有較大的下滑。

 

基於上述測試，ORACLE建議基於鏈接機房的線纜的距離考慮是否採用RAC雙活方案：

1.        距離小於50km的機房，能夠考慮使用雙活RAC。

2.        距離大於50km，小於100km的機房，慎重考慮使用雙活RAC。如要使用，須要進行很是慎重的測試。

3.        距離大於100km，不建議使用雙活RAC，能夠考慮RAC one node作高可靠集羣①。

 

① RAC one node是RAC的一個變種，效果有點相似傳統的HP MC/SG + oracle方案，因爲同時只會有一個節點在運行，不會有大量數據跑在interconnect上。

 

若是決定使用跨數據中心的RAC，以下配置建議須要慎重考慮：

1.        interconnect和IO鏈路使用非共享的，端到端線纜直連，英語稱之爲」Dark Fibre」。

2.        強烈建議在傳輸通路上打開BBC功能。

3.        在ORACLE clustware裏配置3個voting disk或者voting file。兩個數據中心各配一個voting disk，另外在第三機房配置一個基於NFS或者ISCSI的voting file以提升RAC系統可靠性。

 

經過以前的測試結果，前兩點建議比較容易理解，下面咱們對對第三點建議作一個詳細闡述：

若是不配置基於第三機房的voting file，當兩個數據機房的連接斷開以後，兩邊的主機都只能訪問本地存儲，而不知道對方狀態。此時由於沒有第三方仲裁，兩邊的RAC主機都會退出集羣，從而致使業務中斷。由於若是不這樣，將會致使數據紊亂，後果更加嚴重。

 

遠程voting file的配置考量：

通常而言， Oracle clustware每秒經過讀寫少於1千字節的數據方式訪問Voting file一次。每一個寫請求IO的應答應該在200秒內（缺省，long disk timeout）或者27秒內（可配置，short disk timeout）返回。爲此，oracle建議voting fiel的寫IO應該在14（27/2）秒內的時間內返回，傳輸帶寬至少128k bps。

 

存儲雙活與RAC集羣的仲裁競爭問題

l  對於HP XP7而言，由於使用了虛擬磁盤陣列技術，只須要把voting disk/file配置到虛擬磁盤陣列上，就能夠避免出現競爭。由於訪問不了虛擬磁盤陣列上的voting disk的RAC節點是不可能被RAC clusterware仲裁爲活着的。這種狀況下不須要RAC配置遠程voting file。

l  對於HP 3par這種使用ALUA協議的準存儲雙活方案，由於RAC節點只同時使用一個物理陣列，結果與XP7相似，只要把voting disk都配置爲peer persistence卷，就能夠避免仲裁衝突。這種狀況下不須要RAC配置遠程voting file。

l  對於其它沒有使用虛擬磁盤陣列技術的存儲雙活方案提供商，特別是作了本地讀寫優化的提供商，這是一個須要很是慎重考慮的問題。由於大部分這種存儲雙活方案提供商的仲裁是使用第三地點的虛擬機實現的，我的建議將這個虛擬機與RAC的第三個Voting file儘量物理接近，減小物理因素差別形成仲裁結果衝突的可能性。

l  有的存儲供應商提供經過手工調整仲裁算法的方式保證存儲仲裁結果與RAC相同。對此由於沒有詳細資料，因此不便評論，可是oracle官方對此持反對態度。

 

參考書目：

《Oracle RAC and Oracle RAC One Node on Extended Distance (Stretched)Clusters》

《Using standard NFS to support a third voting  file for extended cluster configurations - OracleClusterware 11g Release 2》

《Oracle Clusterware Administration and Deployment Guide》

《HP 3Par Remote Copy Software User's guide》