互備算不算雙活？

雙活為什么比同步復制更怕“光纖抖動”

數據庫復制與雙活

1000公里多活是如何實現的？

多企業經濟適用的雙活

 

年紀大了記性容易不好列出這些供大家參考的同時，也是為了避免自己再寫重復的東西。那么這次我有哪些新話題跟大家分享呢？

 

 

幾乎每次和同行朋友們討論雙活時，都會有人提出應用層實現更好。從某種角度上講這沒有錯，但理想很豐滿現實卻骨感，一說到要重新開發/調整應用許多用戶就開始搖頭了。更多的人還是愿意動數據庫、存儲層，這樣簡單、牽涉的方面較少，而且在數據層面拆成2份也比較好理解。

 

不排除有一部分用戶是為了“雙活”而雙活的，而同城乃至本地雙存儲（雙柜）也有其存在的價值。傳統中高端企業級陣列普遍能達到99.999%的可用性，但也有人“抽中過彩票”——遇到背板故障之類的小概率問題。盡管這些情況數據恢復的概率比較大（加上有還有備份什么的），但停機時間長了損失受不了。

 

 

對于數據庫保護和業務連續性，現在不少DBA推崇基于日志的復制（比如的Oracle ADG），而存儲復制和雙活的適用范圍可以更寬。在《Salesforce曝數據丟失原因：存儲陣列固件bug？》一文中，我們也能看出DataGuard不是萬能的——在容災規劃考慮不夠充分的情況下，存儲壓力過大導致I/O超時可能造成數據庫文件損壞；另外，在沒有打開Flashback時主庫壞塊被復制到從庫也是無法回滾的。

 

 

 

上圖同樣來自李德鵬老師的分享資料，里面提到了DataGuard擅長應對的故障，ADG加入了準實時備庫只讀查詢功能，但它還不是真正的雙活。因此我們看到越來越多的人推薦同時部署DataGuard和Oracle Extended RAC，雖然后者也不是沒有技術上的前提和限制，比如底層存儲雙活的需求，但RPO=0和最小化RTO的吸引力還是蠻大的。

 

在Salesforce的例子中我們還看出不同品牌存儲的差別，如果有高效的Near-CDP、數據庫一致性快照技術，此類故障RPO應該有很大機會縮短至4小時以內。

 

 

隨著SDS（軟件定義存儲）的流行，借助多副本和糾刪碼技術的分布式集群可以支持節點級的容錯。存儲服務器節點斷網、斷電已經成為常規的POC測試項目。對于傳統雙控存儲陣列而言，只能拔一側的控制器或者電源，當然這并不代表Server SAN的可靠性和可用性就會更高。

 

 

隨著VMware VSAN延伸集群的推出， Server SAN也開始支持真正的雙活。從技術角度來看，多副本的機制對于將集群擴展到同城數據中心有些先天便利。盡管只能應用在虛擬化環境，VSAN此舉還是顯著拉低了存儲雙活的門檻，使該特性不再一味“高大上”。

 

沒有雙活都不好意思出去講，這大概也是存儲雙活市場不斷擴大的原因吧。

 

 

 

不可否認，EMC憑借VPLEX在存儲廠商中率先提出雙活數據中心的概念，并且讓更多人認識到Oracle Extended RAC這種方案。正如上面的結構圖，VPLEX將RAC表決磁盤放到虛擬卷上，簡化了數據庫體系結構。

 

使用ASM鏡像的存儲方案，也就是ASM的Normal和High冗余方式。“ASM Mirror的一個問題是：怎樣保證RAC集群的仲裁盤滿足投票規則？…即使非超融合的雙機雙柜也要考慮這個問題。對此有一種解決辦法是把仲裁盤放在外部NFS上。”

 

 

 

這份資料描述的就是依賴ASM來搭建遠程RAC數據庫。A、B、C三個站點各有一套戴爾SC（Compellent Storage Center）陣列，沒有使用存儲自身的雙活。中間的站點C存儲上只放OCR和仲裁盤，以滿足Oracle RAC防止腦裂的最小需求。

 

如果使用VPLEX或者存儲自身的雙活，則無需第三套陣列，對仲裁站點的要求大為降低，而兩對VPLEX Metro網關的價格不菲，并且使存儲網絡變得復雜。如今流行的趨勢是陣列自帶雙活功能，比如VMAX3上基于同步復制發展而來的SRDF/Metro，還有性價比較高的戴爾SC系列Live Volume雙活等，都可以配合實現Oracle Extended RAC。

 

 

 

上圖引用自VMwrae網站KB文章《Implementing vSphere Metro Storage Cluster（簡稱vMSC） using Dell Storage Live Volume (2144158)》。在vSphere延伸集群環境中，Dell SC存儲雙活有兩種主機連接方式，這里列出的是Uniform方式，如果去掉紅圈部分的兩條交叉鏈路就變為Non-Uniform方式。

 

在Non-Uniform雙活連接方式下，VMware主機可以通過本地Dell SC陣列的控制器來訪問另一站點SC陣列Onwer的Live Volume活動卷。這就是存儲雙活所特有，也是傳統同步復制所不具備的技術。

 

 

Hyper-V虛擬化在追趕VMware大家都是知道的，我們也看到VMware支持的一些存儲、高可用特性會不斷被微軟采納。戴爾在SCOS 7.1 新版存儲軟件中，增加了Live Volume雙活對Windows、Hyper-V和集群環境的支持。

 

上圖引用自戴爾技術白皮書《Dell SC Series Storage: Synchronous Replication and Live Volume》。配置Live Volume之后的LUN，經過兩套存儲（Compellent A、B）同時映射到主機后，可以由MPIO多路徑軟件整合。實際運行中的連接狀態，應該可以Active/Standby或者Active/Active的方式。

 

 

這兩張圖截自Dell TechCenter網站上的視頻，我們不難看出用于第三站點仲裁的主機（或虛擬機）上安裝有Dell Storage Manager管理軟件。上面還有LV-AFO支持微軟環境的最低網絡要求：

 

▌大于等于1Gb/s連接

 

▌小于等于5-10ms延時

 

▌作為仲裁的第三站點到每套Dell SC陣列的往返延時小于200ms

 

雖然這里的Windows/Hyper-V雙活是依賴Dell存儲實現，而鏈路條件與VMware VSAN延伸集群的差別并不大，可見相關技術已經比較成熟。

 

 

 

 

如上圖，Hyper-V集群中的Cluster Disk數據盤和Quorum Disk仲裁盤，都是放在CSV集群共享卷上的VHDX文件，集群共享卷底下就是Live Volume。與VMware環境相似的是，此時Hyper-V虛擬機也可以輕松地在不同站點之間的Windows主機間進行遷移等操作。

 

 

 

同城雙活，Oracle Extended RAC目前普遍推薦的站點間距離（光纖長度）是不超過40公里；VMware和Hyper-V最遠可達100-300公里。網絡延時不可避免，規律還是距離越遠性能越差。

 

在兩地三中心容災方案中，除了同城之外一般還需要1000公里以外的災備站點。這時就需要遠程復制或者備份，由于延時和昂貴的帶寬基本上只能做到異步。以上圖中的Dell SC存儲為例，除了黃色區域的兩套陣列采用同步復制/雙活之外，還可以選擇在不同位置添加異步復制。一種是“級聯式復制”，從明尼阿波利斯的同城容災中心復制到圣保羅（這里是用近距離來舉例）；另一種則是“一對多復制（含雙活）”，直接從明尼阿波利斯主站點復制到東海岸的新澤西。

 

當然，除了數據保護特性之外，用戶一定也不希望雙活與存儲的其它高級功能互斥，比如快照、自動分層優化等等。