存儲跨中心雙活方案設計

1、 PAGE 31存儲跨中心雙活方案設計十大難點解析No.1【腦裂風險】存儲跨中心雙活方案設計階段該如何盡量避免腦裂？如何避免腦裂是每個雙機系統(tǒng)都要重視的問題，存儲雙活系統(tǒng)尤其如此，腦裂會帶來長時間的存儲讀寫 IO HANG 住，輕則導致業(yè)務性能下降，重則因磁盤 IO 超時，導致數(shù)據(jù)庫掛起甚至宕機，對生產業(yè)務系統(tǒng)造成重大影響。所以在存儲跨中心雙活架構設計時，究竟應該如何盡量避免腦裂？數(shù)據(jù)中心腦裂簡單說就是兩個數(shù)據(jù)中心間的網(wǎng)絡和存儲鏈路同時發(fā)生中斷，導致兩個數(shù)據(jù)中心內的應用、數(shù)據(jù)庫或者操作系統(tǒng)同時搶占和利用共享的資源，造成資源的數(shù)據(jù)不一致，產生重大影響。這個問題是存儲跨中心雙活方案設計、實施階段不

2、可避免要遇到的問題。各個存儲廠商、存儲虛擬化產品廠商都有自己的避免腦裂的方式：（ 1 ） IBM SVC ESC/HYPERSWAP 或 者 IBM V9000/V7000/V5000 HYPERSWAP對于上述存儲雙活方案架構來說，呈現(xiàn)的是一種對稱式的整體架構，為了防范腦裂，仲裁站點是必需的。在仲裁站點中，基于 IP 的 quorum 節(jié)點和物理 quorum 磁盤都可以提供腦裂的仲裁服務，存儲雙活集群最多能夠擁有 3 個物理 quorum 磁盤，也可以選擇最多 5 個基于 IP 的 quorum 節(jié)點，這個基于 IP 的 quorum 節(jié)點可以是任何站點的任何服務器，或者公有云的一個虛擬機

3、，在這個服務器內運行一個簡單的仲裁 JAVA 程序即可。所以可以看到，基于 IP 的仲裁服務其實大大提高了仲裁站點的選擇空間，節(jié)省了企業(yè)雙活建設成本，只要求 IP 可達， 延時在 80MS 內即可。但是，只有物理 quorum 磁盤的仲裁方式才能夠被用來做 T3 Recovery，所有的 SVC 節(jié)點都會將節(jié)點的相關信息同步至該物理 quorum 磁盤，當節(jié)點或者集群出現(xiàn)故障時，可以通過該物理 quorum 磁盤進行 T3 Recovery在 SVC 集群中有一個概念 configuration node配置節(jié)點，是配置 SVC 集群后，系統(tǒng)自動產生的保存著所有系統(tǒng)配置行為的節(jié)點，不能人工更改

4、配置節(jié)點， 當配置節(jié)點失效后，系統(tǒng)會自動選擇新的配置節(jié)點，配置節(jié)點十分重要，它對 SVC 節(jié)點仲裁勝利起著決定性作用，仲裁勝利的排序規(guī)則通常如下：1.配置節(jié)點（配置節(jié)點獲得仲裁勝利的概率最高）2.距離仲裁站點近的節(jié)點（探測延時較低的 SVC 節(jié)點獲得仲裁勝利的概率次之）3.距離仲裁站點遠的節(jié)點（探測延時較低的 SVC 節(jié)點獲得仲裁勝利的概率最低） 舉例：當兩站點間光纖鏈路中斷，第三站點仲裁節(jié)點活動時，腦裂發(fā)生，將通過投票仲裁選舉獲勝的站點，按照上述的仲裁勝利規(guī)則，configuration node 位于節(jié)點2，選舉站點 2 優(yōu)先贏得仲裁，通過站點 2 恢復業(yè)務的正常存儲訪問。當?shù)谌军c仲裁節(jié)

5、點不活動時，不影響主機的正常存儲訪問，但是此時，兩站點間光纖鏈路也中斷了，發(fā)生腦裂，這時因為節(jié)點 2 為 configuration node，它所擁有候選的 Quorum 將變?yōu)?active Quorum，該 Quorum 選舉站點 2 為仲裁勝利站點，通過站點 2 恢復業(yè)務的正常存儲訪問。EMC VPLEX MetroVPLEX 有著自己專屬的防腦裂規(guī)則：1.分離規(guī)則分離規(guī)則是在與遠程群集的連接中斷（例如，網(wǎng)絡分區(qū)或遠程群集故障）時，確定一致性組 I/O 處理語義的預定義規(guī)則。在這些情況下，在恢復通信之前，大多數(shù)工作負載需要特定虛擬卷集，才能在一個群集上繼續(xù) I/O 并在另一個群集上暫停

6、 I/O。在 VPLEX Metro 配置中，分離規(guī)則可以描述靜態(tài)首選群集，方法是設置：winner:cluster-1、winner:cluster-2 或 No Automatic Winner（無自動優(yōu)勝者）（其中，最后一項指定無首選群集）。如果部署的系統(tǒng)沒有 VPLEX Witness，一致性組設備 I/O 將在首選群集中繼續(xù)，并在非首選群集中暫停。2.VPLEX WitnessVPLEX Witness 通過管理 IP 網(wǎng)絡連接至兩個 VPLEX Metro 群集。VPLEXWitness 通過將其自身的觀察與群集定期報告的信息進行協(xié)調，讓群集可區(qū)分群集內網(wǎng)絡分區(qū)故障和群集故障，并在

7、這些情況下自動繼續(xù)相應站點上的 I/O。VPLEX Witness 僅影響屬于 VPLEX Metro 配置中同步一致性組成員的虛擬卷，并且僅當分離規(guī)則指明群集 1 或群集 2 是一致性組首選群集時才會影響（也就是說，“無自動優(yōu)勝者”規(guī)則未生效時，VPLEX Witness 不影響一致性組）。沒有 VPLEX Witness 時，如果兩個 VPLEX 群集失去聯(lián)系，生效中的一致性組分離規(guī)則將定義哪個群集繼續(xù)操作以及哪個暫停 I/O，如上所述。僅使用分離規(guī)則來控制哪個站點是優(yōu)勝者時，可能會在出現(xiàn)站點故障時增加不必要的復雜性， 因為可能需要手動干預才能恢復仍正常運行的站點 I/O。VPLEX Wi

8、tness 會動態(tài)地自動處理此類事件，這也是它成為擴展 Oracle RAC 部署絕對必要項的原因。它提供了以下幾項內容：a.在數(shù)據(jù)中心之間自動實現(xiàn)負載平衡b.主動/主動使用兩個數(shù)據(jù)中心c.存儲層的完全自動故障處理為了讓 VPLEX Witness 能夠正確區(qū)分各種故障情況，必須使用互不相同的網(wǎng)絡接口在獨立于任意群集的故障域中安裝它。這將消除單個故障同時影響群集和VPLEX Witness 的可能性。例如，如果將 VPLEX Metro 配置的兩個群集部署在同一數(shù)據(jù)中心的兩個不同樓層，請在不同樓層部署 VPLEX Witness。另一方面，如果將 VPLEX Metro 配置的兩個群集部署在兩

9、個不同的數(shù)據(jù)中心，請在第三個數(shù)據(jù)中心部署 VPLEX Witness。HDS HAM/GADHDS 的 HAM/GAD 存儲雙活方案是建立在 VSP TrueCopy 同步復制技術之上的，整個架構也需要仲裁機制防止腦裂，能保證心跳故障后，整個集群系統(tǒng)能對外提供數(shù)據(jù)一致性存儲服務。目前，HAM/GAD 仲裁的實現(xiàn)方式有下面幾種：1、優(yōu)先級站點方式。這種方式最簡單，在沒有第三方站點的情況下使用，從兩個站點中選一個優(yōu)先站點，發(fā)生腦裂后優(yōu)先站點仲裁成功。但如集群果發(fā)生腦裂后，優(yōu)先站點也發(fā)生故障，就是導致業(yè)務中斷，因此這種方案并非推薦的方案。2、軟件仲裁方式。這種方式應用比較普遍，采用專門的仲裁軟件來實

10、現(xiàn)，仲裁軟件放在第三站點，可以跑在物理服務器或 VM 上，甚至可以部署到公有云上，PureStorage 的 ActiveCluster 就把仲裁軟件以 OVF 文件部署在公有云上。3、陣列仲裁盤方式。這種方式是在第三站點采用另外一臺陣列創(chuàng)建仲裁盤。這種方式穩(wěn)定性，可靠性比較高。GAD 的仲裁機制原理是采用仲裁盤的方式實現(xiàn)。NETAPP Clustered Metro Cluster（MCC）MCC 的MetroCluster 的仲裁軟件 TieBreak 支持裝在第三站點的 linux 的主機上，通過檢查對節(jié)點 Ssh 的 session 對 HA pair 和集群進行狀態(tài)監(jiān)控。TieBre

11、ak 軟件能夠在 3 到 5 秒內檢查到 ssh session 的故障，重試的時間間隔為 3 秒。所以這種方式也很靈活，第三站點可以選擇兩個數(shù)據(jù)中心中的一個，也可以選擇公有云中的一個虛擬機，保證 SSH 網(wǎng)絡可達，還可以選擇其他建筑內的任意一臺 Linux 虛擬機。IBM DS8800 系列 HYPERSWAPDS8800 HYPERSWAP 架構下的存儲為 ACTIVE-STANDBY 模式，整體是對稱式的架構，但是卻沒有第三仲裁站點，在雙數(shù)據(jù)中心間鏈路全部中斷時，要恢復業(yè)務需要人為關閉非存活站點的集群服務，并且修復鏈路，如下紅皮書原文： Unplanned HyperSwap: Site

12、 partitionIn the scenario of Site parttion, the workload continues to run on Site_A.Because both sites are partitioned, each site thinks it is the only surviving site, as such, the nodes in each site try to start the workload on each site.Running the workload at the same time on both nodes results i

13、n data corruption. To maintain data integrity, PowerHA SystemMirror supports recovery mode for HyperSwap through manual workload activation. This option indicates that when the link between the sites is down (both sites are down), user intervention for manual recovery is needed, therefore maintainin

14、g data integrity.When the site is down, because Auto Recovery Action is not supported, the resource groups(RGs) will remain in the ERROR state. User intervention is needed to correct the problem.The user has to shut down the cluster services on Site_B and fix theconnectivity issues. When done, the u

15、ser can start the cluster services on Site_B.No.2【性能影響】存儲跨中心雙活方案設計階段如何盡量降低對整體性能的影響？性能影響問題：因為雙活系統(tǒng)在寫入數(shù)據(jù)時，會寫兩次數(shù)據(jù)，尤其是通過復制功能寫到遠端存儲的過程，傳輸鏈路的性能也會影響整體性能。在選型設計階段該如何解決該難點？盡量降低對整體性能的影響？這個問題實際上存儲雙活不可避免要遇到的問題，相比單存儲直接提供讀寫來說， 存儲雙活一定會增加讀寫響應時間，更別說存儲還是跨兩個不同數(shù)據(jù)中心的，隨 著距離的增加，理論上每增加 100KM，會增加 1ms 的 RTT（往返延遲時間）, 通常單個 IO 總耗

16、時在 1-3ms 左右，就會認為單個存儲 I/O 處理處于比較高性能的模式，如果加上其他因素，如“數(shù)據(jù)頭處理”和“并發(fā)”，1ms 的“理論” 延時增加的影響會成倍增加，將原本處于高性能模式的 IO 響應時間拉高，對應用或者數(shù)據(jù)庫來說，“變慢”了。所以存儲雙活的初衷是只是為了高可用性和提 高總體并發(fā)、吞吐量，并不是為了降低讀寫響應時間。那么我們在設計、選型存 儲雙活方案時，就需要考慮如何盡量降低雙活的存儲所帶來的性能降低影響。我們先來看看一些存儲雙活方案的讀寫流程：IBM SVC Enhanced Stretch Cluster(ESC)和 HDS GAD 等IBM SVC ESC 和 HDS

17、GAD 的讀寫方式都很類似，這里就放在一起來看。SVC ESC：HDS GAD：讀：ESC 和 GAD 在兩個存儲拉開到兩個數(shù)據(jù)中心，形成 AA 模式的架構，對于讀來說，是兩個數(shù)據(jù)中心分別對各自中心的存儲本地讀，這樣讀來說不存在跨站點的 RTT，讀性能跟單存儲是一樣的。寫：某數(shù)據(jù)中心的寫操作會先寫到本地控制節(jié)點緩存，然后再跨站點同步至另一控制節(jié)點緩存中，并原路返回，告訴主機寫操作完成，等到緩存達到一定的水位時，再刷入各自底層存儲當中，這時的寫操作存在 1 倍的跨站點 RTT。當兩個數(shù)據(jù)中心都要對某一數(shù)據(jù)塊寫操作時，會先在緩存表對應的數(shù)據(jù)塊中加鎖，并同步鎖信息至對端緩存表，實現(xiàn)雙活存儲的寫并發(fā)。

18、所以寫也是本地寫的方式，性能跟單存儲比是降低的。SVC HyperSwapSVC HyperSwap 的 HyperSwap 卷有 master 和 aux 之分，讀寫復雜度也高很多，master 卷所在站點的主機讀寫是本地讀本地寫，而 aux 卷所在站點的主機讀寫方式是轉發(fā)模式。假設初始化后，Site1 的卷為 Master 卷，Site2 的卷為 Aux 卷讀：Site1 讀 I/O1.主機向 SVC I/O Group1 的任意一個節(jié)點發(fā)送讀請求2.SVC I/O Group1 將該請求傳至 Storage Pool13.Storage Pool1 響應請求，并將數(shù)據(jù)傳至 SVC I/O

19、 Group1 4.SVC I/O Group1 將數(shù)據(jù)結果傳至主機Site2 讀 I/O1.主機向 SVC I/O Group2 的任意一個節(jié)點發(fā)送讀請求2.SVC I/O Group2 將該請求轉發(fā)至 SVC I/O Group1 3.SVC I/O Group1 將請求傳至 Storage Pool1Storage Pool1 響應請求，并將數(shù)據(jù)傳至 SVC I/O Group1SVC I/O Group1 將數(shù)據(jù)回傳給 SVC I/O Group2SVC I/O Group2 將數(shù)據(jù)結果傳至主機所以可以看到AUX 卷所在站點的主機需要跨站點讀對端存儲，存在1 倍的RTT， 而 MAST

20、ER 卷所在的主機讀 IO 和單存儲性能相差無幾。寫：Site1 寫 I/O1.主機向 Site1 的其中一個 SVC 節(jié)點 2 發(fā)送寫 I/O 請求2.該 SVC 節(jié)點 2 將寫 I/O 寫入緩存3.該 SVC 節(jié)點 2 將寫 I/O 同步至節(jié)點 1 緩存，并同時通過 MM 發(fā)送寫 I/O 至站點 2 的節(jié)點 3 和節(jié)點 4SVC 節(jié)點 1、3、4 陸續(xù)回復節(jié)點 2 的寫響應SVC 節(jié)點 2 回復主機寫響應6.兩個站點的 SVC 節(jié)點分別將緩存寫入各自站點的存儲當中Site2 寫 I/O1.主機向 Site2 的其中一個 SVC 節(jié)點 3 發(fā)送寫 I/O 請求2.該 SVC 節(jié)點 3 將寫

21、I/O 轉發(fā)至 Site1 的任意 SVC 節(jié)點 23.SVC 節(jié)點 2 將寫 I/O 寫入緩存4.該 SVC 節(jié)點 2 將寫 I/O 同步至節(jié)點 1 緩存，并同時通過 MM 發(fā)送寫 I/O 至站點 2 的節(jié)點 3 和節(jié)點 4SVC 節(jié)點 1、3、4 陸續(xù)回復節(jié)點 2 的寫響應SVC 節(jié)點 2 回復 SVC 節(jié)點 3 的轉發(fā)響應SVC 節(jié)點 3 回復主機的寫響應8.兩個站點的 SVC 節(jié)點分別將緩存寫入各自站點的存儲當中同理，AUX 卷所在站點的主機需要跨站點寫對端存儲，并且回寫 AUX 卷底層存儲，總共存在 2 倍的 RTT，而 MASTER 卷所在的主機寫 IO 和單存儲性能相差無幾。所以

22、很明顯，SVC HYPERSWAP 的SVC 節(jié)點是跨站點雙活，而存儲則為ACTIVE-STANDBY。NetApp MCCMCC 的雙活方式實際上是兩個數(shù)據(jù)中心的存儲互為鏡像，各自提供不同的存儲服務。對于 AGGX 來說，為站點 A 的主機提供本地讀和本地寫，并通過集群節(jié)點的NVRAM 寫日志同步至站點 B，維持數(shù)據(jù)一致性，也是等到日志達到水位線，刷入底層存儲當中。對于 AGGY 來說，也是類似，為站點 B 的主機提供本地讀和本地寫，并同步NVRAM 的寫日志至站點A。MCC 通過這種方式實現(xiàn)兩個站點存儲的雙活，MCC集群節(jié)點也是雙活，但對于某一應用主機來說，實則只在一個站點活動。性能方面，

23、MCC 的讀性能和單存儲類似，寫性能存在 1 倍的 RTT。SVC Vplex MetroVplex Metro 和其他三種方式都不一樣，是一種分布式的存儲雙活/多活架構。Vplex 沒有寫緩存，有了分布式緩存，標榜為 access anywhere沒有寫緩存就意味了，主機對 VPLEX 的寫是透寫模式，主機的寫 IO 只是經(jīng)過VPLEX 的虛擬化直接落入到底層存儲，并在分布式緩存目錄表中記錄這個寫 IO 是通過哪個 VPLEX 引擎寫入的。當需要對該數(shù)據(jù)塊進行讀操作時，先是在分布式緩存目錄中查找數(shù)據(jù)塊是通過哪個 VPLEX 引擎寫入的，然后再通過本地的VPLEX 引擎轉發(fā)該讀請求至上一次寫入

24、該數(shù)據(jù)塊的 VPLEX 引擎，通過它來讀取它后端的存儲，最終原路返回。另外，對于寫入的 IO，透穿過 VPLEX 寫底層存儲時，還將同步一份 IO 副本至另一 VPLEX 引擎的底層存儲。所以可以看到，對于某數(shù)據(jù)中心 VPLEX 的讀操作來說，如果剛好上次該數(shù)據(jù)塊的寫操作時也是發(fā)在該 VPLEX 中，那么讀是本地讀，親和性好。如果剛好上次該數(shù)據(jù)塊的的寫操作不是在該 VPLEX，那么就需要跨站點進行讀操作，親和性弱，存在 1 倍的跨站點 RTT；對于寫，都是本地寫，只不過需要將該寫 IO 同步至另一站點的底層存儲，也存在 1 倍的跨站點 RTT。好了，寫了這么多，將幾種主流的存儲雙活架構的讀寫操

25、作流程寫清楚了。簡單對比如下：歸根到底，我們最想要的存儲跨中心雙活，就是為了讓兩個數(shù)據(jù)中心的主機對存儲的讀寫，盡量本地讀和本地寫，或者本地讀，減少跨中心寫。這是“盡量降低對整體性能的影響”的最直接的方法！首先是讀寫比例問題，不能將讀寫比例過小的應用放到雙活存儲系統(tǒng)中。 再是距離對讀寫 RTT 的放大問題，讀寫響應時間越敏感，距離越不能過遠。最后是想盡辦法，減少跨中心寫，這里有很多辦法，比如通過數(shù)據(jù)庫的分庫分表， 將應用分割至兩個站點，熱點數(shù)據(jù)分離；增大緩沖池，盡量減少直接的寫存儲操作等。No.3【數(shù)據(jù)一致性風險】跨中心的雙活存儲數(shù)據(jù)一致性如何保障？一方面，當寫入數(shù)據(jù)時，在復制過程中，數(shù)據(jù)傳遞是

26、在緩存中進行的，這樣做的好處是提升了性能，問題是當出現(xiàn)控制器節(jié)點異常宕機事件時，就會導致緩存內的數(shù)據(jù)不能寫入存儲中，從而造成數(shù)據(jù)的不一致，這時有沒有保障單個存儲數(shù)據(jù)一致性的措施？另外一方面，兩個站點的存儲之間的數(shù)據(jù)一致性，從緩存層、底層數(shù)據(jù)層又是如何保障的？第一個問題：前端節(jié)點寫緩存與后端存儲間的數(shù)據(jù)一致性如何保障？存儲跨中心雙活中的單個存儲架構分為三種：1.物理存儲的內部雙控制器比如 V5000/V7000/V9000 HYPERSWAP，寫存儲的操作也就是寫緩存的過程， 寫了一個控制器，控制器也會將緩存數(shù)據(jù)同步至另一控制器的緩存，只有當真正同步完，這次的寫操作才算完成，當寫緩存達到水位線后

27、，會將寫緩存刷入到磁盤組中，當一個控制器異常宕機時，IO HANG 住一小段時間，另一控制器將接管，緩存數(shù)據(jù)也不會因此丟失，一致性得到保障；單控制器時，寫緩存被禁止， 之前的緩存被刷入后端存儲，即使這時這個控制器也異常宕機，后端磁盤的數(shù)據(jù)完整性和一致性也得到了保障；如果不幸兩個控制器的電源同時斷電了，這時寫緩存數(shù)據(jù)還未及時刷入磁盤組，不用怕，幾乎所有存儲都會考慮到這一點，都有專門的電池模塊維持供電幾分鐘，保證緩存數(shù)據(jù)能夠順利落到磁盤組當中。 2.物理存儲+存儲虛擬化網(wǎng)關（有寫緩存）比如 SVC ESC/HYPERSWAP，NETAPP MCC（叫寫日志），這種架構也就是相當于在物理存儲前端又加

28、了一道控制器，也存在寫緩存，相當于擴大了后端物理存儲的緩存容量，寫操作要先寫入 SVC 節(jié)點，再同步至另一 SVC 節(jié)點，只有完全同步成功，才算做是一個完整的寫周期，后面的操作也是等待寫緩存達到水位線刷后端存儲。佑了這種機制的保障，存儲虛擬化網(wǎng)關的緩存與后端物理存儲的數(shù)據(jù)完整性和一致性得到保障，無論是單 SVC 節(jié)點故障，另一節(jié)點緩存數(shù)據(jù)冗余，寫緩存被禁止，所有緩存刷入后端存儲，還是 SVC 的電源斷電，SVC 有專門的 UPS 供電模塊保障寫緩存及時刷入后端存儲，都能完整的保障數(shù)據(jù)的完整性和一致性。這里不再贅述。3.物理存儲+存儲虛擬化網(wǎng)關（無寫緩存）比如 EMC VPLEX METRO，它

29、只有讀緩存，寫緩存還是由后端的物理存儲提供，所以該問題還是和前面說的類似的保障機制。第二個問題：兩個站點的雙活存儲間的數(shù)據(jù)一致性如何保障？這里分兩種方式來闡述這個問題： 1.一種是兩個站點的主機識別的是相同的 VOLUME比如：SVC ESC、EMC VPLEX、HDS GAD 等，兩個站點的主機對這一個 VOLUME寫操作時，數(shù)據(jù)被刷入兩個鏡像的后端存儲，這有兩個存儲都寫完成返回，才算一個完整的緩存刷后端存儲的寫周期，這時兩個存儲從數(shù)據(jù)塊角度來說，是一致的，一個站點或者存儲故障，另一個站點的存儲是可以接管，而不會造成數(shù)據(jù)丟失。2.另一種是兩個站點的主機識別的是不同的 VOLUME比如：SVC

30、 V7000/V5000 HYPERSWAP、NET APP MCC 等，由于兩個站點的主機識別的不是同一個 VOLUME ，必然存在存儲或者存儲虛擬化網(wǎng)關的VOLUME 與 VOLUME 的同步復制技術，HYPERSWAP 有 METRO MIRROR，MCC 有 Syncmirror，它們的技術共同點是復制技術的一致性校驗機制，更高級的有以多個卷為單位的卷組一致性校驗機制，來保障跨站點的兩個卷/卷組的一致性，在某站點所有控制器或者站點完全故障時，另一站點有完整的、一致的存儲可以接管。No.4【數(shù)據(jù)同步邏輯錯誤】存儲跨中心雙活是塊存儲的同步，無法避免邏輯錯誤被同步，出現(xiàn)該問題又該如何防范？數(shù)

31、據(jù)同步邏輯錯誤問題：存儲層面的復制技術基本以存儲塊為單位進行的數(shù)據(jù)復制，假設數(shù)據(jù)塊發(fā)生了邏輯錯誤，那么存儲是無法檢測到的，它會繼續(xù)將壞的數(shù)據(jù)塊兒同步到災備端，如果因此數(shù)據(jù)庫發(fā)生宕機，那么災備端的數(shù)據(jù)庫也同樣無法正常啟動。這是一個很典型的問題，塊存儲如何防范邏輯錯誤。做了存儲的跨中心的雙活或者做了存儲的鏡像，同步復制，很容易就會覺得數(shù)據(jù)有兩份甚至多份一致性的副本，就會覺得萬事大吉，甚至覺得不需要備份系統(tǒng)了。數(shù)據(jù)備份系統(tǒng)是企業(yè)數(shù)據(jù)安全的最后一道防線，無論做了什么同步、異步、雙活還是連續(xù)性數(shù)據(jù)保護，數(shù)據(jù)備份系統(tǒng)都應該作為一個最穩(wěn)固可靠的基礎的存在， 地位無法替代?；氐絾栴}來，基于存儲的復制技術，無論

32、復制方式是同步、異步、雙活還是連續(xù)性數(shù)據(jù)保護，都是基于存儲數(shù)據(jù)塊級別的復制技術，復制源端在可讀時，會將塊中的數(shù)據(jù)原樣的拷貝一份至目標端，當源端數(shù)據(jù)出現(xiàn)誤刪、誤改、磁區(qū)退化數(shù)據(jù)異變、數(shù)據(jù)庫事物層邏輯錯誤等數(shù)據(jù)邏輯性錯誤時，復制目標端無法檢測到這些錯誤，依舊復制“錯誤”的數(shù)據(jù)，導致兩份副本都無法正常使用的災難。所以我們要有多層次的防范機制，來保障數(shù)據(jù)的可靠性和安全性，存儲雙活技術只是其中的一個層次，要輔以備份技術、數(shù)據(jù)庫復制技術，連續(xù)性數(shù)據(jù)保護，建立了完善的數(shù)據(jù)保障體系。（1）備份系統(tǒng)按照一定的時間頻率對數(shù)據(jù)庫做全量和增量備份，在遇到數(shù)據(jù)邏輯錯誤時，通過恢復將數(shù)據(jù)回退到最后一個備份版本。如 TSM

33、 、NBU、COMMVAULT。（2）數(shù)據(jù)庫復制技術有實時同步、準同步、異步等方式，保障主數(shù)據(jù)庫邏輯錯誤無法正常運行時，切至備數(shù)據(jù)庫，回退到備庫前一個日志COMMIT 后的版本。如 DB2 HADR、ORACLE ADG、MYSQL 主從復制等。（3）連續(xù)性數(shù)據(jù)保護技術也是準/實時對存儲數(shù)據(jù)塊做快照，源端數(shù)據(jù)無法繼續(xù)使用時，通過快照回退至前一個數(shù)據(jù)可用版本。如 CDP。通常為了考慮不影響源端數(shù)據(jù)的訪問性能或者單個系統(tǒng)無法滿足需求時，可以考慮多種方式結合，比如備份系統(tǒng)在備份超大數(shù)據(jù)庫時，沒有充足的帶寬或者備份時間窗口，可以用數(shù)據(jù)庫的異步復制方式來做為備份方式的補充；連續(xù)性數(shù)據(jù)保護技術需要通過 L

34、VM 鏡像源端數(shù)據(jù)，增加了寫延遲，可以通過數(shù)據(jù)庫準實時同步或者異步的方式復制數(shù)據(jù)到備庫節(jié)點，備庫節(jié)點的后端存儲為連續(xù)性數(shù)據(jù)保護的存儲節(jié)點，如 DB2 HADR+CDP 的組合。所以總結來看，存儲跨中心雙活并不是萬能的，依舊需要傳統(tǒng)的數(shù)據(jù)保障技術輔助，建立常態(tài)高效的數(shù)據(jù)保障體系，才能應對萬難。No.5【雙中心間通訊不可控】存儲跨中心雙活最關鍵、最難點就是鏈路質量，如何把控該風險？雙中心間通訊不可控問題：一是鏈路穩(wěn)定狀況不可控；二是 IO 延時指標不可控。這些不可控因素非常容易造成災難性影響，輕則導致數(shù)據(jù)庫讀寫性能災難，重則導致數(shù)據(jù)庫節(jié)點直接處于僵死狀態(tài)。另外，鏈路的不穩(wěn)定會導致存儲鏈路頻繁切換，

35、甚至會導致集群仲裁頻繁發(fā)生，這對于業(yè)務連續(xù)性更是一個災難。無論什么雙活，只要上升到了跨中心的層面，就必然需要跨中心的鏈路作為雙活的通訊介質。這個通訊不但要求高可用性和冗余度，而且又對通訊質量要求又很高。并且鏈路所帶來的風險隱患又是巨大的，中斷或者響應時間高都將可能導致雙活集群發(fā)生腦裂仲裁，出于保護的目的，將 IO HANG 住一段時間，將所有沒有落入磁盤的數(shù)據(jù)全部刷盤，才繼續(xù)在某個存活的站點繼續(xù)恢復讀寫訪問。所以阻礙存儲跨中心雙活技術發(fā)展的最直接的因素就是雙中心間鏈路不可控。尤其對風險、穩(wěn)定性要求苛刻的金融機構來說，更加不敢輕易做跨中心的雙活。所以鏈路成為了存儲雙活的最難點，如何既提高鏈路穩(wěn)定

36、性，又保證鏈路的性能，還又有合理的故障保障機制，是每一個存儲廠商和企業(yè)用戶都要深思的關鍵點。在這里我也不刻意去解決該難題，而是提出些許我的想法。1.鏈路冗余度通常我們企業(yè)做雙活，都是自己購買波分設備，然后租用運營商的裸光纖，作為通訊的鏈路。所以波分設備需要冗余，裸光纖也要冗余，波分設備好辦，購買即可。裸光纖通常租用兩家或兩家以上的運營商線路，比如電信和聯(lián)通，電信的裸光纖也需要冗余，聯(lián)通的裸光纖也需要冗余，防止單根裸光纖意外割斷或者損壞。然而單家運營商的裸纖都通常在一個弱點井中，一起意外割斷的事情常有，所以需要兩家運營商互相冗余。這兩家運營商裸纖的路線還不能一致，弱電井需要在不同的街道，并且分別

37、走不同的路線到達目的地。所以可以看到，由于我們是租用，根本不可能要求運營商完全達到你的要求，最好的方式只能自建，成本太高， 好像根本不現(xiàn)實。示意圖：2.鏈路質量鏈路質量包括光衰、抖動和帶寬等。一方面，光衰和抖動無法控制，只能靠波分設備去探測，發(fā)現(xiàn)光衰和抖動，立即中斷該鏈路，切向備鏈路，這對后端的 SAN 網(wǎng)絡無感知，但對波分設備的要求很高，需要購買和建設時注意。至于帶寬，可以監(jiān)測，達到帶寬預警閾值后，可向運營商申請?zhí)嵘龓?。另一方面，對于鏈路質量的監(jiān)測機制一定要在建設存儲雙活或者其他雙活之前建立，由于是運營商的鏈路，鏈路經(jīng)過了多少中繼、多少設備我們是不得知的，我們只能在波分端建立有效的監(jiān)測機制

38、，有些波分設備也有專門的監(jiān)控軟件支持。而且也要要求和運營商建立監(jiān)測聯(lián)動機制，運營商監(jiān)測到鏈路質量（是質量而不是中斷）有問題，也需要第一時間告知，做出合理的決策。3.存儲雙活控制器的機制由于跨中心的雙活控制器間的通訊是實時的，完整寫周期必須兩個站點的控制器都完成寫操作。他們間的通訊又是靠鏈路完成的，鏈路質量和鏈路中斷都將導致性能波動甚至超時，對于中斷，控制器的處理機制都還不錯，對于質量，控制器的處理機制往往不夠，需要長時間的嘗試，才會做出合理的決策，甚至沒有決策， 導致上層數(shù)據(jù)庫或者應用磁盤 IO 超時，而異常掛起甚至宕機。所以這個機制是決定好的雙活體系的重要因素，有時候寧可立即放棄一邊，也要保

39、住 RTO，但目前為止我還未發(fā)現(xiàn)雙活存儲控制器有好的鏈路質量處理機制。知道的也請分享。4.雙活存儲上端的 OS、應用和數(shù)據(jù)庫合理的超時參數(shù)OS 識別磁盤、應用訪問文件系統(tǒng)、數(shù)據(jù)庫訪問裸設備或者文件系統(tǒng)，存儲 IOHANG 住，將導致層層超時，尤其是數(shù)據(jù)庫，超時將徹底中斷宕機，甚至出現(xiàn)邏輯損壞等莫名奇妙的問題。有時候超時響應慢是可以等，而不是中止，所以需要OS、數(shù)據(jù)庫層進行合理的超時聯(lián)動設置。5.盡量避免跨站點讀，減少跨站點寫頻率沒有跨站點讀，就意味著本地可讀，對鏈路質量沒有要求；減少跨站點寫頻率， 就意味著，性能影響弱化，被控制器、數(shù)據(jù)庫、操作系統(tǒng)等層層緩存暫存的寫數(shù)據(jù)，會減少跨站點寫的次數(shù)，

40、進一步弱化鏈路質量所會帶來的影響。No.6【存儲網(wǎng)絡故障泛濫】存儲跨中心雙活帶來的雙中心 SAN 網(wǎng)絡級聯(lián)打通， 是否會因局部 SAN 節(jié)點故障而影響整條路徑？存儲網(wǎng)絡故障泛濫問題：兩個數(shù)據(jù)中心的 SAN 網(wǎng)絡打通，整合為一張大的 SAN 網(wǎng)絡，可能會因為局部的存儲網(wǎng)絡故障而波及到整個存儲網(wǎng)絡，造成重大影響。如果是 IBM SVC 或者是 NETAPP MCC，必然要求存儲虛擬化設備要和另外一個數(shù)據(jù)中心的物理存儲想通?？缰行牡拇?ZONE 也就是必須的了。這種情況下， 我們只能橫向將 ZONE 劃分到更細的粒度。如果是 VPLEX，那么它不需要虛擬化網(wǎng)關和另外一個數(shù)據(jù)中心的存儲想通，而是靠兩中

41、心的 VPLEX 機頭之間的內部連接實現(xiàn)交互。這種場合下雙中心的 SAN網(wǎng)絡相對獨立?？偨Y起來就是1.大的 SAN 網(wǎng)絡用細粒度的 zone 隔離2.存儲雙活的控制節(jié)點的通訊 SAN 網(wǎng)絡和其他 SAN 網(wǎng)絡隔離，建立 PUBLICSAN 和 PRIVATE SAN 兩種網(wǎng)絡3.核心 SAN 網(wǎng)絡采用“環(huán)形”拓撲取代星形拓撲或者線型拓撲如圖：核心 SAN 網(wǎng)絡中的每個 SAN 節(jié)點都和其他 SAN 節(jié)點打通，任何一個 SAN 節(jié)點故障，不會影響其他核心 SAN 節(jié)點的通訊。外圍 SAN 網(wǎng)絡聯(lián)通核心 SAN 網(wǎng)絡中的一個節(jié)點，其故障也不會影響核心 SAN 節(jié)點的通訊。No.7【存儲多路徑控制策

42、略】主機對跨中心的雙活存儲多路徑訪問與控制策略是怎樣的？存儲多路徑控制的策略問題：倘若采用存儲廠商自己的多路徑，可能存在兼容性問題。同時多路徑策略中，對路徑的選擇策略是否正確是存儲雙活的關鍵點；發(fā)生存儲故障切換時，主機又如何快速切換到其他存儲路徑。主機對存儲的控制訪問策略一般就幾種策略，建議還是采用存儲廠商的多路徑軟件，再主機訪問存儲上設置一下，一般是主備方式，這種方式是兩個 hba 卡，類似兩條路徑方式，只有這個 hba 卡出現(xiàn)問題，切換到另外一個 hba 卡上;另外一種就是負載均衡模擬，兩條路徑同時工作，一條出現(xiàn)問題后另外一條正常工程， 現(xiàn)在多半采用這種模式。目前而言最佳的多路徑選擇還是存

43、儲廠商自帶的多路徑軟件，尤其是在存儲雙活領域，每個存儲廠商的雙活技術不一，廠商自帶的多路徑軟件具備更好的、更兼容的針對其下兩個跨中心的雙活存儲控制器的訪問控制和策略切換的能力，通常所有主機都建議具有訪問兩個數(shù)據(jù)中心兩個存儲的路徑，這樣當其中一個存儲故障時，多路徑軟件能夠迅速識別本站點存儲狀態(tài)，將路徑切換至另一個存儲，對上層主機無感應。由于主機具備所有存儲路徑，但是主機只允許訪問那個可以提供 ACCESS 的存儲控制器，只有當切換時，原先不能提供 ACCESS 的存儲控制器，具備了提供給這臺主機 ACCESS 能力時，IO 才能被轉移過來。當然每家存儲廠商的實現(xiàn)技術不一樣，技術細節(jié)也不一樣。也有

44、的存儲廠商能夠提供針對同一主機的雙活控制器，另一控制器將多路徑過來的 IO 轉發(fā)給主控制器等等。No.8【集群仲裁一致性】存儲跨中心雙活集群的仲裁如何和上層數(shù)據(jù)庫集群的仲裁結果保持一致？集群仲裁一致性問題：所謂的仲裁一致性問題，是指雙中心之間的雙活存儲集群和數(shù)據(jù)庫集群的仲裁結果是否能保證一致性。當不一致時，對業(yè)務系統(tǒng)將造成災難性影響?？缰行牡募褐俨靡簿褪钱攦蓚€數(shù)據(jù)中心間的所有鏈路都中斷時，雙活集群的仲裁機制，這里的雙活集群可能不只是存儲雙活集群，也有可能包含了數(shù)據(jù)庫的雙活集群、并行文件系統(tǒng)的雙活集群，甚至一些特殊應用的雙活集群等。這多類雙活集群在鏈路發(fā)生中斷時，都將按照各自的集群的仲裁算法，

45、投票選舉出存活節(jié)點，倘若這多個集群的仲裁結果不是一致的，將可能會給業(yè)務系統(tǒng)帶來災難性的影響。這里拿存儲和數(shù)據(jù)庫雙活舉例：存儲雙活集群的仲裁通常規(guī)則有兩種：1.偏好模式偏好模式的意思就是說，按照系統(tǒng)或者用戶的偏好，特定選擇一個優(yōu)先存活的站點，在發(fā)生鏈路中斷（腦裂）時，這個站點繼續(xù)存活，并擁有接管 IO 讀寫的優(yōu)先權。比如說 SVC 的配置節(jié)點、VPLEX 的分離規(guī)則或者 SRDF/METRO 的ACTIVE BIAS 配 置 選 項 等 。 2.第三仲裁站點仲裁模式第三仲裁站點，顧名思義，也就是在除了兩個雙活的數(shù)據(jù)中心之外的另一個站點， 來對這兩個數(shù)據(jù)中心進行仲裁和選舉，防范腦裂。詳細可見：腦裂

46、風險防范這兩種模式通常都是配合起作用的，優(yōu)先第二種模式。數(shù)據(jù)庫雙活集群的仲裁規(guī)則有：1.磁盤仲裁，擁有磁盤心跳的節(jié)點存活2.節(jié)點數(shù)仲裁，站點節(jié)點數(shù)多的存活3.磁盤和節(jié)點的共同仲裁，獲得磁盤心跳，并且存活站點節(jié)點數(shù)+磁盤心跳數(shù)大于非存活站點節(jié)點數(shù)4.IP 地址最大或者最小者存活5.實例號最小或者最大者存活因數(shù)據(jù)庫的不同，仲裁規(guī)則的算法也不同，但是大多數(shù)都會選擇磁盤和節(jié)點的共同仲裁的方式作為優(yōu)先的方式。那么數(shù)據(jù)庫雙活和存儲雙活集群的仲裁一致性是如何做到的呢？這里以 EXTEND ORACLE RAC 數(shù)據(jù)庫跨中心雙活集群和 VPLEX METRO 存儲跨中心雙活集群舉例說明：EXTEND Orac

47、le RAC 的部署重點介紹OracleClusterware 仲裁文件和Witness 第三個站點。也就是說，在采用 VPLEX Metro 的遠距離群集中，Oracle RAC 仍需使用 Oracle Clusterware 仲裁磁盤。但是，群集仲裁磁盤本身駐留在 VPLEX 虛擬卷上。這可以保證 Oracle 仲裁磁盤訪問 Oracle RAC 的行為和 VPLEXMetro 故障切換行為一致。借助 VPLEX，僅 VPLEX Witness 部署在第三個站點1.如果只有 Oracle 互連鏈路中斷（不是真正的站點故障，且不影響 VPLEX 互連），則 Oracle Clusterwar

48、e 將根據(jù)多數(shù)節(jié)點及仲裁磁盤訪問進行重新配置。2.如果是 VPLEX 互連鏈路中斷（或真正的站點故障），VPLEX 將根據(jù)站點分離規(guī)則的首選項和 Cluster Witness 指導，立即允許 IO 在一個群集恢復。因此，僅當 VPLEX 恢復仲裁磁盤上的 I/O 時，這些 Oracle 群集節(jié)點才有權訪問這些仲裁磁盤；而且 Oracle Clusterware 將相應地重新配置群集。盡管仍需要仲裁磁盤，但無需部署在獨立的第 3 個站點中，因為 VPLEX Witness 可提供 Split-Brain 保護并保證Metro 和Oracle Clusterware 的行為一致。此外，由于VPL

49、EXWitness 控制仲裁文件的訪問，因此可跨獨立 Oracle RAC 部署和相關上游用戶應用程序保證一致的確定性行為。No.9【存儲雙活集群保護】存儲雙活通常是作為一個集群的存儲，如何對這個雙活集群進一步保護？存儲雙活后的集群保護問題：通常存儲雙活的所有存儲節(jié)點都在一個雙活集群當中，倘若這個集群軟件出現(xiàn)重大故障或者 BUG，兩個站點的存儲都將無法訪問， 所以這個雙活集群的保護也是個難點，如何結合其他災備技術實現(xiàn)雙活集群的災備保護，實現(xiàn)兩地三中心甚至多地多中心的災備架構。有些存儲跨中心雙活方案是通過鏡像復制技術（VDM、MetroSync、SyncMirror、TrueCopy 等）將底層

50、兩個存儲虛擬成一個虛擬卷，再掛載給上層的主機，由于這個卷是虛擬的卷，底層存儲有可能無法脫離這個虛擬化（集群）而單獨掛載給主機使用，所以這個虛擬化（集群）軟件的可靠性和穩(wěn)定性就變得非常重要了， 如果出現(xiàn)重大軟件 BUG 或者這個集群的所有節(jié)點先后故障，就將造成數(shù)據(jù)丟失的重大風險。當然這種問題出現(xiàn)十分罕見，但對于數(shù)據(jù)的安全性，是企業(yè)最為重要的資產，是企業(yè)的生命，所以我們也不能大意，依舊需要一套完善的集群保障體系和數(shù)據(jù)保障體系。通常可以把這種雙活集群的保護分為三種：一種是虛擬化網(wǎng)關+底層存儲的復制技術通過虛擬化網(wǎng)關實現(xiàn)的存儲雙活，虛擬化網(wǎng)關的集群保護就需要靠虛擬化網(wǎng)關自身自帶的數(shù)據(jù)保護體系，或者底層

51、存儲的數(shù)據(jù)保護體系，比如說 SVC ESC 是基于 VDM 的復制技術實現(xiàn)的雙活，再配備 SVC METRO MIRRO 或者 GLOBALMIRROR 實現(xiàn)兩地三種的數(shù)據(jù)級容災，當 SVC ESC 的雙活集群完全不可用時， 可以將 SVC 切至容災端就行數(shù)據(jù)的恢復，保障數(shù)據(jù)的安全。又如 VPLEX METRO 或者 VPLEX GEO 雙活，由于這套架構本身就是兩套集群，兩套集群同時故障的可能性更小，幾乎不需要再對 VPLEX METRO 再做集群的保護，如果要做異地的話，可以通過 VPLEX 底層的存儲，比如 EMC VMAX 的 SRDF 再做一份數(shù)據(jù)至同城或者異地容災端，或者 DS80

52、00 系列的 MM 或者 GM 再做一份數(shù)據(jù)至同城或者異地。前面 SVC ESC 的容災保護體系適合所有的高中低端存儲，直接通過 SVC 的容災技術就實現(xiàn)了兩地三中心+存儲同城雙活，而后面的 VPLEX 要實現(xiàn)集群的進一步保護，需要底層高端存儲的同步復制技術的支持。第二種是底層存儲復制技術直接通過底層存儲控制器實現(xiàn)的雙活，是需要專有存儲或者高端存儲的支持，再進一步實現(xiàn)兩地三中心整體架構，也是需要在原有雙活復制技術之上，將數(shù)據(jù)異步擴展至異地，或者支持多份數(shù)據(jù)同步技術。第三種是上層應用/數(shù)據(jù)庫的復制技術對于這種方式的保護也是非常多案例的，既起到從數(shù)據(jù)庫事物層方式起到數(shù)據(jù)邏輯性保護的目的，又達到了對雙活集群的容災目的，像 DB2 HADR 和 ORACLEADG 超異步，ORACLE 的 far sync 復制已經(jīng)支持跨超遠距離的異步復制了。No.10【私有云存儲解決方案相結合】存儲跨中心雙活方案如何和私有云的存儲方案相結合？私有云存儲解決方案相結合的問題:存儲雙活方案如何有效和私有云存儲解決方案相互結合,也是個需要考量的問題。當今是云時代，各種私有、公有和混合云