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》