Oracle資料庫中心雙活之道：ASM vs VPLEX

標籤：host   2.0   進一步   目的   when   src   物理   區別   idt   

雙活方案對比：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公裡需要密集波分裝置
和多工(DWDM)的裝置。如果使用了DWDM或CWDM用這些，那應該使用專用交換機直接連接。

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，在儲存，網路，資料庫的配置中，不要犯任何錯誤，做好構架設計，高可用測試，效能測試，壓力測試（穩定性）等工作。簡單來講使用ASMmirroring，會面臨以下的挑戰

1)由於是ASM來管理IO的分發和複製，HostMirroring會消耗一定的資料庫節點上的資源。

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

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

4)DBA需要涉及複雜的效能測試，穩定性測試和災難測試，充分測試和理解這種構架下IO的效能情況。比如本地failgroup和遠程failgroup的單讀測試，雙failgroup同時online的雙活測試，及其對比情況，主要關注物理讀和寫測試（比如順序讀，散列讀，直接路徑讀，直接路徑寫，並行寫，控制檔案讀，記錄檔寫等等）。RACcache fusion測試，最大流量下interconnect的品質，GC掉包率，GCCR/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

                                        %TimeTotal Wait    wait    Waits  % DB

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

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

log filesync                 6,488,667     0    41,258       6      1.0  34.0

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

directpath read                 65,267     0     1,336      20      0.0   1.1

 

 

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

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

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

log filesync                 1,660,630     0     4,488       3      0.7   6.5

db filescattered 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 nodessurvive
b. The group with lower node member in case of same number of node(s) availablein each group
c. Some improvement has been made to ensure node(s) with lower load survive incase the eviction is caused by high system load.

d. For 12c, node(s) with more weight will survive, see Note 1951726.1 12c: Which Node Will Survive when Split Brain Takes Place[This section is not visible to customers.]

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的解釋簡直是少之有少，只有短短的幾頁。早期版本的OracleHA文檔，推薦的是storage的mirror，在storage mirror不能實現的情況下才考慮ASMmirror， 到了11.2後，Oracle建議採用Hostbased mirror，採用ASM作為Cluster邏輯卷管理到了12.2，目前還沒有HA Bestpractice文檔公布。

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

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

 

 

 

 

我推薦由OracleACS專家實施團隊根據客戶的實際情況來全程參與實施基於AMSmirror的雙活和基於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 （轉）