雙活方案對比：ASM vs V-PLEX

作者：王文傑

Oracle公司 Principle system analyst

Oracle高級服務部

Oracle數據庫中心的災備的演變，經歷了多年的演變從最初的冷備份，到熱備份，到存儲復制，到DG，ADG，RAC one node， RAC，最終演變到了目前最炙手可熱的雙活雙中心構架，也就是我們常說的遠程RAC（Extended RAC）。

一般售前工程師口中實現雙活的方案有很多種，但我認為真正RTO，RPO趨近於0，且雙中心可用（讀寫）的方案，才能稱為真正的雙活雙中心。復制軟件不能算雙活，DG/ADG也不是雙活，備庫不可寫，切換時間長。真正比較成熟的雙活案例為Oracle ASM host mirror（卷管理），存儲虛擬化方案VPLEX（Oracle認證）和IBM SVC方案（Oracle認證），另外還有一些其它廠商的解決方案，例如HDS,HP，華為的解決方案。

圖片來源（extended RAC white paper）

本文作者最近3年參加過多次Vplex雙活和ASM雙活的數據庫實施和運維，以實際經驗來聊一聊對目前最主流的兩種雙活方案的看法。

首先談一談Extended RAC和普通RAC的主要區別。主要就是距離，距離是為了防止逐如自然災害，恐怖襲擊等對一個數據中心的損害後，另外一個數據庫中心仍然可以提供服務。但距離會帶來額外的網絡和IO的延時，所以雙活建設中對網絡的建設特別重要。在Oracle的HA Best practice文檔中提到：

■ 距離小於10公裏可以使用普通高質量的網絡。

■ 距離等於或超過10公裏需要密集波分設備

PS: DWDM（即密集波分復用）是當今光纖應用領域的首選技術，但其昂貴的價格令不少手頭不夠寬裕的運營商頗為躊躇。那麽有沒有或能以較低的成本享用波分復用技術呢？面對這一需求，CWDM（稀疏波分復用）便應運而生了。DWDM（即密集波分復用）與CWDM（稀疏波分復用）從字面上我們便可以大概看出兩者的區別在於：密集和稀疏第二、CWDM調制激光采用非冷卻激光，而DWDM采用的是冷卻激光。冷卻激光采用溫度調諧。CWDM避開了溫度調諧實難點因則大幅降低了成本，

CWDM成本只有DWDM1/3，CWDM很受歡迎

■ 距離10到50公裏需要存儲網絡(SAN)緩存來抵消，由於距離對性能的影響。否則,性能退化會很明顯。

■ 對於距離超過50公裏，任何構架都需要經過嚴格的性能測試來證明它的性能是可接受的。實際任何距離的雙活都需要做性能測試和壓力測試。

國內雙活近些年最常見的方案即為EMC的VPLEX的方案，和采用Oracle ASM host Mirror的雙活。

下圖為這兩種方案的對比：

VPLEX

ASM

這兩種方案作者參與最多為EMC的方案，一般從方案審核，installation，testing，go-live support，運維，優化，都有參與，ASM方案則更多是參加整體crosscheck，trouble shooting，優化調整等。下面，具體談一談對這兩種方案的個人感悟。

VPLEX的最大優點在於VPLEX大大簡化DBA的工作，不用配置failure group， path preference，第三方quorum磁盤。DBA可以不用參與管理存儲，VPLEX處理了一切的細節，DBA不用看到磁盤，VPLEX工程師會處理好一切，從而減少了硬件故障導致數據庫crash的風險。數據庫從性能上講，VPLEX所有的讀都是本地讀，不用額外進行設置。讀可以受益於VPLEX的高速緩存。其實更重要的是，所有的IO的分發和復制，都是在VPLEX集群中進行管理，IO工作的workload從計算節點下移了存儲集群層面。緩解了數據庫節點的資源壓力。

至於VPLEX的缺點，有兩點是無須質疑的。第一廠商綁定，實際這個議題已經被弱化了很多，很大程度是CTO的風格有關系，第二價格，這個的確VPLEX一開始的價格是不便宜。很多人都想問，那麽拋開VPLEX我們可不可以做到這一切。答案是可以。前提是你有足夠的好構架師，存儲管理員和DBA，在存儲，網絡，數據庫的配置中，不要犯任何錯誤，做好構架設計，高可用測試，性能測試，壓力測試（穩定性）等工作。簡單來講使用ASM mirroring，會面臨以下的挑戰

1)由於是ASM來管理IO的分發和復制，Host Mirroring會消耗一定的數據庫節點上的資源。

2)存儲管理員和DBA需要仔細的協作，配置好failure groups, path preferences，第三方quorum磁盤，並且需要長期保持警惕。一個錯誤的配置，都可能導致容災失效，或者性能降級。

3) DBA需要介入打通大二層SAN鏈路的配置，進行完善的網絡測試。重點關註遠程網絡帶來的延時，心跳的質量。高可用測試，同樣需要進行復雜的設計，確保涵蓋各種故障場景，復雜度。

4)DBA需要涉及復雜的性能測試，穩定性測試和災難測試，充分測試和理解這種構架下IO的性能情況。比如本地fail group和遠程fail group的單讀測試，雙failgroup同時online的雙活測試，及其對比情況，主要關註物理讀和寫測試（比如順序讀，散列讀，直接路徑讀，直接路徑寫，並行寫，控制文件讀，日誌文件寫等等）。RAC cache fusion測試，最大流量下interconnect的質量，GC掉包率，GC CR/CURRENT塊延時。國內很多客戶選擇ASM的原因，就是因為預算，往往采用老舊的硬件來實施，經常RAC集群中，節點配置不一樣，比如服務器型號不同，CPU核數/頻率存在差異等等，這樣更需要測試來驗證方案的健壯性。

5)上線後維護更復雜，對DBA要求更高。後期如果需要橫向擴展，一樣具有復雜性，需要同樣的人力資源配置。

如果說ASM方案在的天然的優勢，我想是ASM不需要通過SAN網絡來同步數據（第三方存儲集群軟件仍然需要心跳，一般都部署在數據庫節點上，例如veritas CVM），ASM的IO復制是從數據庫節點發起。VPLEX則需要通過SAN心跳網絡同步數據，如果SAN心跳網絡斷開，VPLEX一個site會shutdown，同時數據庫會崩潰，主機會reboot。但如果是純粹的某一邊site的存儲DISK損壞，無論是ASM和VPLEX，均不會影響所有數據庫實例。在磁盤修復以後，會重新同步數據。ASM從11.2開始引入了fast resync option特性，可以快速恢復disk的同步。

我見過一個客戶采用ASM方案，匆忙上線後，由於性能嚴重達不到預期。甚至在上線後，才開始考慮設置ASM_PREFERRED_READ_FAILURE_GROUPS這個最基本雙活參數。最後不得不再次采購硬件，最後甚至整體替換到原有硬件。付出的代價也是驚人的。也有某些客戶采用ASM雙活的系統，負載實際是非常低的，遠程節點常年是關閉的。

關於VPLEX另外的幾個網絡上提及的幾個問題：

第一性能，雙活的性能，主要關註什麽：IO和心跳， 如果IO延時和心跳延時都性能良好，那麽雙活就成功了一大半。 某些廠商稱VPLEX MTERO會額外增加IO延時，不建議采用，而這個測試據說通過dd得來的。我認為這個實在的來得太過草率，數據庫的一個IO在雙活構架的從發起到結束的生命周期遠不是一個dd能夠模擬。ASM層的IO分發也會有額外的開銷,同時這部分開銷是在計算節點,而VPLEX則是off loading到存儲層。

VPLEX METRO的寫操作的流程是，首先，該Director判斷是哪個數據塊需要修改，同時也通知在Metro-Plex中的其他Directors，這樣在 cache中擁有這個塊的local 和remote Director將更新各自的dictionary拷貝以示在其cache中的數據是過期的，然後將數據寫入cache，最後寫入到磁盤中，然後從兩站點返回ACK消息給到發出寫的那個Director，然後ACK被返回給到計算節點。

VPLEX METRO的讀操作的流程是，主機將讀請求發給在Metro-Plex中的Directors，本地Director會首先檢查Local cache是否有該數據，若有即返回數據，若沒有則從後端本地存儲去讀數據塊。

EMC這一特性叫做：EMC VPLEX的分布式緩存一致性

ASM的IO管理則比VPLEX要簡單，因為ASM是只是一個卷管理軟件。ASM早期在沒有參數ASM_PREFERRED_READ_FAILURE_GROUPS能指定優先讀取fail group前，讀性能無疑是較大損耗，在設置了ASM_PREFERRED_READ_FAILURE_GROUPS參數後，ASM讀IO也是走local（前提是要配置得當）。ASM的寫IO則需要本地failgroup和遠程failgroup都同時寫成功，IO才認為完成。如果某一個failgroup的IO寫失敗，Oracle會再次尋找新的extent寫入，如果再次失敗，則會offline磁盤。

下面是一些主要雙活的客戶的性能采樣情況：

某客戶VPLEX雙活，距離25公裏，存儲帶閃盤，最近的IO情況。可以看出數據最主要的等待事件db file sequential read基本穩定維持在1ms左右。db file scatter read在1.2ms左右。log file sync在4.5ms左右。性能優異。該客戶數據庫節點1，日常情況下，平均每秒事務數為1500左右，每秒SQL執行為10000左右，每秒邏輯讀為200萬左右。賬期事務數會提高3倍。Interconnect traffic bytes大約在97MB每秒，GC BLOCK LOST基本接近0，各GC指標均表現良好。這裏的心跳流量其實很大了，我們在一般的RAC中都很少見GC bytes超過50MB，該客戶的GC等待已經占到了db time的40%左右，但業務端仍然可以接受目前的性能情況。另外該客戶上線前在數據庫性能測試和壓力測試都遇到過各種問題，不同多路軟件的性能差異，網絡不穩定導致GC掉包高，經過2個月左右的逐步調整後，到達了較好狀態。

某客戶VPLEX雙活，4套庫16節點，共用2個交換機，8根裸光纖，距離35公裏，存儲無閃盤。可以看出該客戶的IO延時大部分時間處於Oracle推薦的正常延時區間，數據庫最主要等待事件db file sequential read一直維持在5ms左右，該客戶GC流量目前較少。其中有一個區間IO延時比較高是由於備份發起導致。每秒邏輯讀在120萬左右。該客戶的構架，存在光纖共用，幾個庫之間互相可能造成影響，每天CRM備份發起後，4套褲的IO同時降級。在結算期，每秒事務數會到4000筆每秒（這裏指的就是數據庫的user commits），會對redo log造成巨大的壓力，但log file sync的指標依舊維持在<5ms左右的良好水平。上線前，利用數據庫專家測試軟件OTest進行了完整的性能基準測試和最大壓力測試，在測試中發現了數據庫bug導致instance crash問題，網絡不穩定掉包問題，逐一解決後，再上線確保了雙活構架下數據庫的性能和穩定。

該客戶的心跳流量在40M每秒左右，同時有一些GC BLOCK LOST發生

某客戶的VPLEX雙活的，帶閃盤， 4節點RAC，主要業務在1節點， Estd Interconnect traffic大約5M每秒，較小。主要IO等待事件，性能良好。該客戶實際3,4節點處於閑置狀態。硬件冗余程度較高。

Avg

%Time Total Wait wait Waits % DB

Event Waits -outs Time (s) (ms) /txn time

-------------------------- ------------ ----- ---------- ------- -------- ------

log file sync 6,488,667 0 41,258 6 1.0 34.0

db file sequential read 11,293,347 0 15,307 1 1.7 12.6S

direct path read 65,267 0 1,336 20 0.0 1.1

Event Waits -outs Time (s) (ms) /txn time

-------------------------- ------------ ----- ---------- ------- -------- ------

db file sequential read 14,988,301 0 15,358 1 6.1 22.3

log file sync 1,660,630 0 4,488 3 0.7 6.5

db file scattered read 437,281 0 916 2 0.2 1.3

某客戶的ASM的雙活方案的性能情況，數據庫為2節點RAC，兩套存儲在距離10公裏的兩個機房，第一階段實施過程中由於節約成本，采用老的存儲和鏈路，在上線前大量發生DISK超時，遠程site的failgroup的磁盤被offline drop掉了大半，性能測試發現IO延時較高。這個階段的問題，在上線前被逐一解決。上線後，數據庫性能尚可接受，數據庫最主要等待事件db file sequential read一直維持在10ms左右，但一旦遇到結算日，或者客戶活動日，IO性能就降級到不可接受的程度，db file sequential read會降級到80ms左右。隨後客戶進行了大規模的優化，效果並不明顯。最終客戶換裝了全套新存儲（帶閃盤）後，性能問題暫時得以解決。

另外一個早期客戶的10g ASM extended RAC方案，I/O性能一般，為了減少由於cluster interconnect帶來的延遲，遠程節點始終處於關閉狀態。存儲雙活，數據庫cluster實際為單活。

總的來說，鑒於雙活構架的復雜性，無論是VPLEX還是ASM的方案，都曾經遇到過各種問題。

第二集群鬥爭問題。VPLEX cluster和Oracle cluster一樣，在發生cluster interconnect通訊故障後，會發生腦裂的驅逐。這種情況下，如果VPLEX cluster和Oracle cluster的 interconnect同時斷開，則需要同步，才能避免整個集群不可用。Oracle的腦裂驅逐算法，簡單來說為Oracle的腦裂算法簡單來說是，保留擁有節點最多的子集群，如果節點數一樣，則保留擁有instance number較小的子集群。註意：從12.1.0.2開始Oracle cluster引入了集群權重這一概念，進群權重高的子集群會存活。

a. The group with more cluster nodes survive
b. The group with lower node member in case of same number of node(s) available in each group
c. Some improvement has been made to ensure node(s) with lower load survive in case the eviction is caused by high system load.

Vplex cluster的構架其實和RAC類似,也存在心跳網絡和總裁機制，見下圖

Witness就類型RAC的vote disk的功能。在VPLEX集群中，2個cluster中一個是preferred (優先的)另一個是non-preferred，假如集群之間的心跳連接完全中斷了，Witness會通知preferred cluster繼續服務，而non-preferred停止服務直至內聯恢復，這一點，我從EMC工程師口中得到的說法，EMC也是保留節點號小的節點。這和11.2.0.4的Oracle的集群的行為基本一致。目前VPLEX的RAC一般都是2節點，或者4節點的，這樣發生數據庫心跳和存儲心跳同時斷開後，驅逐是一致的。在網絡設計階段，最好是SAN心跳和數據庫心跳各自走不同的交換機和光纖，並有冗余機制。

簡單來說，VPLEX不怕某個site storage system崩潰，數據庫實例繼續訪問本地cache和remote storage system，也不怕某一個個site的崩潰（該site數據庫同步崩潰）,但另外一個site的storage system和數據庫繼續服務。

唯一有一定concern的就是storage和數據庫心跳同時斷開，這種小概率的風險理論上是的確存在的，如果集群節點多，心跳網絡斷開後形成了子集群多的恰好位於VPLEX的踢出site，Oracle版本>=12.1.0.2，配置有專門node weight，那麽的確可能存在腦裂不一致的情況。

所以，第一雙活建設中，對存儲心跳網絡的配置是非常重要的，以高可用性為第一考慮。第二這種驅逐場景，是必須包含在高可用測試中進行反復驗證的，從而進一步減小風險。

第三鎖定問題，這個問題是說VPLEX一個站點存儲損壞後，另外一個站點會有短時間（5秒）的鎖定，導致業務無法被順利接管。這個問題其實很好理解， 任何集群在某一個站點崩潰後，為了維護事務的完整性，數據庫的一致性，都會存在鎖定的情況，包括Oracle集群：IMR instance membership recovery or reconfig ，一樣會發生同樣的鎖定。這是現階段集群構架不可避免出現的情況，但大多數集群在完成reconfig是可以繼續提供服務的。該問題完全可以在測試階段進行模擬，確保硬件資源，中間件，應用都可以承受短時間的鎖定後，再完成接管。

很多人喜歡問Oracle原廠怎麽推薦， 其實這個很難有固定的說法，第一原廠不太可能為你推薦非Oracle產品的細節。第二官方文檔，對這個solution的解釋簡直是少之有少，只有短短的幾頁。早期版本的Oracle HA文檔，推薦的是storage的mirror，在storage mirror不能實現的情況下才考慮ASM mirror， 到了11.2後，Oracle建議采用Host based mirror，采用ASM作為Cluster邏輯卷管理到了12.2，目前還沒有HA Best practice文檔公布。

如果要問我怎麽推薦？VPLEX和ASM都是Oracle認證的解決方案。方案是死的，人才是項目成功關鍵。

一個典型雙活項目的技術流程應該包括：

我推薦由Oracle ACS專家實施團隊根據客戶的實際情況來全程參與實施基於AMS mirror的雙活和基於storage mirror的雙活。這兩種解決方案都需要比一般數據庫中心實施，更規範和完善的數據庫構架設計，安裝，配置，高可用性測試，基準性能測試，極限壓力測試和災難測試，（推薦采用Oracle 測試，優化，實施最佳實踐 ：Otest進行數據庫測試，http://www.dbfine.net/otest）很明顯ASM方案需要更加專業的實施人員。西區原廠團隊，是國內最有經驗的雙活Oracle實施團隊之一。

參考資料：Oracle extended RAC white paper

EMC_VPLEX_Overview_and_General_Best_Practices

資深專家孫久江提供多地的雙活方案參考

Oracle HA best practice文檔

文章來源：http://www.dbfine.net/archives/480

2017-07-06

Oracle數據庫中心雙活之道：ASM vs VPLEX （轉）