3par peer persistence與XP7雙活在RAC環境下的比較

3par不支持嚴格意義的存儲雙活，可是它的PeerPersistence功能在存儲雙數據中心的配置中，很是有意思。在此咱們以RAC應用爲例對其作一個分析。

先上一張架構圖，看明白這個架構是怎麼回事。

這個架構裏面有兩個模塊：一個是上面的服務器+ORACLE RAC構成的，由RAC向外提供服務，並管理服務器集羣應對可能的物理設備故障，還實現了負載均衡分配；另外一個是由3par存儲和SAN網絡交換機以及運行在虛擬機之上的仲裁服務器構成，存儲空間經過peer persistence展示給服務器和RAC軟件。

若是看過我以前的文章，會有一個感受：它和HP XP7的雙活方案很像耶！XP7的虛擬磁盤陣列是存儲到主機的中間層，3par Peer Persistence也是中間層，並且都有仲裁機制。爲何它不是雙活呢？

這就要談到3par Peer Persistence與HP XP7對主機IO路由的分配了：

l  XP7的虛擬磁盤陣列中的會把接收到的IO根據必定的（好比本地存儲優先）把IO發送到兩個磁盤陣列中去。一個LUN在兩個磁盤陣列的鏡像能夠同時處理主機發來的IO，沒有主從的區別。XP7實際是LUN在兩個陣列上的鏡像均可以處理主機IO，可是它們的WWN是同樣的，那麼主機是如何知道哪一個LUN在本地的呢？

l  3par Peer Persistence設置的LUN存儲有主從區別，主機來的IO都會先到主存儲，再由主存儲同步到從存儲。對於主機，存儲路徑的管理和切換，經過ALUA協議來實現。

下面這張圖顯示了二者在IO路徑上的不一樣，對於3par，兩條×××IO路徑在正常狀態下是非激活狀態的，沒有IO流過；對於XP7則否則，兩條×××路徑處於激活狀態，分擔部分綠色路徑上的IO。

3par的peer persistence沒有了×××路徑，又是如何管理陣列的呢？它經過ALUA （AsymmetricLogical Unit Access異步邏輯單元訪問）協議，把主陣列設置爲主動/優化（active/optimized）狀態，把從陣列設置爲主動/非優化（active/unoptimized）狀態。這樣主機天然把IO都發送到主陣列上去了。當主陣列出現故障時，peerpersistence又會反過來把從陣列設置爲主動/優化（active/optimized）狀態，把主陣列設置爲主動/非優化（active/unoptimized）狀態。圖示以下：

至此，是否能夠說XP7的雙活是否必定優於3par的peer persistence呢？表面上看是的，緣由以下：

1.        因爲兩個陣列同時處於激活狀態，切換會很快，理論上主機和RAC軟件無感知。

2.        在XP7的雙活狀況下，兩個陣列同時處理主機IO，均衡負載。

 

如今，咱們對兩種狀況分別做更深刻的分析：

1.        存儲切換速度問題，須要分兩種狀況討論

l  正常狀況下的手工切換：二者雙活切換速度都很是快，業務應用軟件不會有感知。

l  非正常狀況下的自動切換：咱們在3par拷貝大文件的時候作過暴力測試，在使用了遠端仲裁服務器仲裁的狀況下，拷貝操做暫停了2~5秒的時間，而後繼續進行，操做沒有中斷。這個延時是由仲裁服務器須要對兩個存儲狀態進行斷定必須的代價。全部仲裁服務器爲了防止誤判，都會須要一段時間延時來斷定存儲狀態。XP雙活也不例外。

2.        兩個陣列同時處理主機IO，均衡負載問題：

l  雖然兩個陣列能夠同時處理主機IO，可是爲了保持數據一致，這些IO中的寫操做必須同步到另一個陣列上。也就是說下圖中的第2和第3步驟沒法節省。只有第1和第4步驟節省了傳輸時間。可是，雙活由於複雜的鎖機制帶來了陣列內部軟件處理時延。這個時延是否可以抵消第1和第4步驟的傳輸時間節省，值得商榷。還有一點須要特別注意的是：隨着系統負荷增加，IO流量越大，處理時延越長。

l  通常而言，一個陣列上每每存有多個應用的數據，把這些應用數據分組，分別設置不一樣主存儲能夠達到手工負載均衡的效果。可是要注意：一個應用的數據必須設置到一個組裏面，不能夠經過分組設置不一樣的主存儲。