在寫這一篇之前，我們先回顧一下去年的《存儲極客：大話「雙十一」與經濟適用型雙活》，其中主要討論了以下話題：
互備算不算雙活?雙活為什麼比同步複製更怕「光纖抖動」資料庫複製與雙活1000公裡多活是如何實現的?多企業經濟適用的雙活
年紀大了記性容易不好列出這些供大家參考的同時，也是為了避免自己再寫重複的東西。那麼這次我有哪些新話題跟大家分享呢?
雙活的技術和非技術因素
上圖引用自元鼎時代資深Oracle技術專家李德鵬的分享資料《數據中心雙活的前生今世》
幾乎每次和同行朋友們討論雙活時，都會有人提出應用層實現更好。從某種角度上講這沒有錯，但理想很豐滿現實卻骨感，一說到要重新開發/調整應用許多用戶就開始搖頭了。更多的人還是願意動資料庫、存儲層，這樣簡單、牽涉的方面較少，而且在數據層面拆成2份也比較好理解。 不排除有一部分用戶是為了「雙活」而雙活的，而同城乃至本地雙存儲(雙櫃)也有其存在的價值。傳統中高端企業級陣列普遍能達到99.999%的可用性，但也有人「抽中過彩票」——遇到背板故障之類的小概率問題。儘管這些情況數據恢復的概率比較大(加上有還有備份什麼的)，但停機時間長了損失受不了。
Salesforce故障給我們的啟示對於資料庫保護和業務連續性，現在不少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的可靠性和可用性就會更高。
上圖引用自Veritas資深架構師黃海峰的分享資料《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。
vMSC的Uniform和Non-Uniform連接方式除了Oracle之外，VMware是存儲雙活的另一個主流應用場景。
對於Dell SC而言，防止腦裂、判斷「誰活誰死」的第三站點仲裁無需採用SAN或者NAS，只要一個物理伺服器，或者運行在雲中的虛擬機都可以。
上圖引用自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活動卷。這就是存儲雙活所特有，也是傳統同步複製所不具備的技術。
Windows/Hyper-V雙活存儲自動切換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存儲為例，除了黃色區域的兩套陣列採用同步複製/雙活之外，還可以選擇在不同位置添加異步複製。一種是「級聯式複製」，從明尼阿波利斯的同城容災中心複製到聖保羅(這裡是用近距離來舉例);另一種則是「一對多複製(含雙活)」，直接從明尼阿波利斯主站點複製到東海岸的新澤西。 當然，除了數據保護特性之外，用戶一定也不希望雙活與存儲的其它高級功能互斥，比如快照、自動分層優化等等。