近年來，作為災備方案中高級別的雙活數(shù)據(jù)中心解決方案逐漸成為了應對傳統(tǒng)災備難題的一把利劍，它能夠解決傳統(tǒng)的災備方案中資源利用率低、可用性差、出現(xiàn)故障時停機時間長、數(shù)據(jù)恢復慢、風險高等問題，但同時也帶來了很多難點問題。這其中，存儲跨數(shù)據(jù)中心雙活的方案更是雙活數(shù)據(jù)中心架構(gòu)方案中最重要且最艱難的一項，能否在方案架構(gòu)選型和設計階段，順利地解決和盡量規(guī)避這些存儲雙活的難點問題，對企業(yè)IT架構(gòu)師團隊的能力有著極大的考驗。

[[206656]]

為了幫助企業(yè)IT架構(gòu)師理清和解決存儲跨中心雙活方案架構(gòu)的難點，IT架構(gòu)師和存儲專家整理出一些方案設計中較為典型的難點，并特別組織線上交流，邀請專家逐一對這些難點進行解析和解答。

這些難點將包括：

腦裂風險問題、性能影響問題、數(shù)據(jù)一致性風險問題、雙中心間通訊不可控問題、數(shù)據(jù)同步邏輯錯誤問題、存儲網(wǎng)絡故障泛濫問題、集群仲裁一致性問題、存儲多路徑控制的策略問題、存儲雙活后的集群保護問題、私有云存儲解決方案相結(jié)合的問題等。

突破存儲跨中心雙活方案設計階段難點(一)：腦裂風險

存儲跨中心雙活方案設計階段該如何盡量避免腦裂?

如何避免腦裂是每個雙機系統(tǒng)都要重視的問題，存儲雙活系統(tǒng)尤其如此，腦裂會帶來長時間的存儲讀寫IO HANG住，輕則導致業(yè)務性能下降，重則因磁盤IO超時，導致數(shù)據(jù)庫掛起甚至宕機，對生產(chǎn)業(yè)務系統(tǒng)造成重大影響。所以在存儲跨中心雙活架構(gòu)設計時，究竟應該如何盡量避免腦裂?

解析和解答：

鄧毓 某農(nóng)信社資深骨干工程師

數(shù)據(jù)中心腦裂簡單說就是兩個數(shù)據(jù)中心間的網(wǎng)絡和存儲鏈路同時發(fā)生中斷，導致兩個數(shù)據(jù)中心內(nèi)的應用、數(shù)據(jù)庫或者操作系統(tǒng)同時搶占和利用共享的資源，造成資源的數(shù)據(jù)不一致，產(chǎn)生重大影響。

這個問題是存儲跨中心雙活方案設計、實施階段不可避免要遇到的問題。各個存儲廠商、存儲虛擬化產(chǎn)品廠商都有自己的避免腦裂的方式：

(1)IBM SVC ESC/HYPERSWAP 或者IBM V9000/V7000/V5000 HYPERSWAP

對于上述存儲雙活方案架構(gòu)來說，呈現(xiàn)的是一種對稱式的整體架構(gòu)，為了防范腦裂，仲裁站點是必需的。在仲裁站點中，基于IP的quorum節(jié)點和物理quorum磁盤都可以提供腦裂的仲裁服務，存儲雙活集群最多能夠擁有3個物理quorum磁盤，也可以選擇最多5個基于IP的quorum節(jié)點，這個基于IP的quorum節(jié)點可以是任何站點的任何服務器，或者公有云的一個虛擬機，在這個服務器內(nèi)運行一個簡單的仲裁JAVA程序即可。所以可以看到，基于IP的仲裁服務其實大大提高了仲裁站點的選擇空間，節(jié)省了企業(yè)雙活建設成本，只要求IP可達，延時在80MS內(nèi)即可。

但是，只有物理quorum磁盤的仲裁方式才能夠被用來做T3 Recovery，所有的SVC節(jié)點都會將節(jié)點的相關(guān)信息同步至該物理quorum磁盤，當節(jié)點或者集群出現(xiàn)故障時，可以通過該物理quorum磁盤進行T3 Recovery

在SVC集群中有一個概念configuration node---配置節(jié)點，是配置SVC集群后，系統(tǒng)自動產(chǎn)生的保存著所有系統(tǒng)配置行為的節(jié)點，不能人工更改配置節(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é)點不活動時，不影響主機的正常存儲訪問，但是此時，兩站點間光纖鏈路也中斷了，發(fā)生腦裂，這時因為節(jié)點2為configuration node，它所擁有候選的Quorum將變?yōu)閍ctive Quorum，該Quorum選舉站點2為仲裁勝利站點，通過站點2恢復業(yè)務的正常存儲訪問。

(2)EMC VPLEX Metro

VPLEX有著自己專屬的防腦裂規(guī)則：

1.分離規(guī)則

分離規(guī)則是在與遠程群集的連接中斷(例如，網(wǎng)絡分區(qū)或遠程群集故障)時，確定一致性組 I/O 處理語義的預定義規(guī)則。在這些情況下，在恢復通信之前，大多數(shù)工作負載需要特定虛擬卷集，才能在一個群集上繼續(xù) I/O 并在另一個群集上暫停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 Witness

VPLEX Witness 通過管理 IP 網(wǎng)絡連接至兩個 VPLEX Metro 群集。VPLEX Witness通過將其自身的觀察與群集定期報告的信息進行協(xié)調(diào)，讓群集可區(qū)分群集內(nèi)網(wǎng)絡分區(qū)故障和群集故障，并在這些情況下自動繼續(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 Witness會動態(tài)地自動處理此類事件，這也是它成為擴展 Oracle RAC 部署絕對必要項的原因。它提供了以下幾項內(nèi)容：

a.在數(shù)據(jù)中心之間自動實現(xiàn)負載平衡

b.主動/主動使用兩個數(shù)據(jù)中心

c.存儲層的完全自動故障處理

為了讓 VPLEX Witness 能夠正確區(qū)分各種故障情況，必須使用互不相同的網(wǎng)絡接口在獨立于任意群集的故障域中安裝它。這將消除單個故障同時影響群集和 VPLEX Witness 的可能性。例如，如果將 VPLEX Metro 配置的兩個群集部署在同一數(shù)據(jù)中心的兩個不同樓層，請在不同樓層部署 VPLEX Witness。另一方面，如果將 VPLEX Metro 配置的兩個群集部署在兩個不同的數(shù)據(jù)中心，請在第三個數(shù)據(jù)中心部署VPLEX Witness。

(3)HDS HAM/GAD

HDS的HAM/GAD存儲雙活方案是建立在VSP TrueCopy同步復制技術(shù)之上的，整個架構(gòu)也需要仲裁機制防止腦裂，能保證心跳故障后，整個集群系統(tǒng)能對外提供數(shù)據(jù)一致性存儲服務。目前，HAM/GAD仲裁的實現(xiàn)方式有下面幾種：

1、優(yōu)先級站點方式。這種方式最簡單，在沒有第三方站點的情況下使用，從兩個站點中選一個優(yōu)先站點，發(fā)生腦裂后優(yōu)先站點仲裁成功。但如集群果發(fā)生腦裂后，優(yōu)先站點也發(fā)生故障，就是導致業(yè)務中斷，因此這種方案并非推薦的方案。

2、軟件仲裁方式。這種方式應用比較普遍，采用專門的仲裁軟件來實現(xiàn)，仲裁軟件放在第三站點，可以跑在物理服務器或VM上，甚至可以部署到公有云上，PureStorage的ActiveCluster就把仲裁軟件以OVF文件部署在公有云上。

3、陣列仲裁盤方式。這種方式是在第三站點采用另外一臺陣列創(chuàng)建仲裁盤。這種方式穩(wěn)定性，可靠性比較高。GAD的仲裁機制原理是采用仲裁盤的方式實現(xiàn)。

(4)NETAPP Clustered Metro Cluster(MCC)

MCC的MetroCluster的仲裁軟件TieBreak支持裝在第三站點的linux的主機上，通過檢查對節(jié)點Ssh的session對HA pair和集群進行狀態(tài)監(jiān)控。TieBreak軟件能夠在3到5秒內(nèi)檢查到ssh session的故障，重試的時間間隔為3秒。所以這種方式也很靈活，第三站點可以選擇兩個數(shù)據(jù)中心中的一個，也可以選擇公有云中的一個虛擬機，保證SSH網(wǎng)絡可達，還可以選擇其他建筑內(nèi)的任意一臺Linux虛擬機。

(5)IBM DS8800系列HYPERSWAP

DS8800 HYPERSWAP架構(gòu)下的存儲為ACTIVE-STANDBY模式，整體是對稱式的架構(gòu)，但是卻沒有第三仲裁站點，在雙數(shù)據(jù)中心間鏈路全部中斷時，要恢復業(yè)務需要人為關(guān)閉非存活站點的集群服務，并且修復鏈路，如下紅皮書原文：

Unplanned HyperSwap: Site partition

In 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 in 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

maintaining 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 the connectivity issues. When done, the user can start the cluster services on Site_B.

趙海 大連農(nóng)商銀行 架構(gòu)師

其實這個問題，我覺得還是要看整體的架構(gòu)是什么樣的?

假設定位到存儲雙活，那么是不是就割裂了數(shù)據(jù)庫層的仲裁問題。實際上存儲最終是為上層數(shù)據(jù)庫及應用服務，如果這個夸中心的架構(gòu)涉及到數(shù)據(jù)庫、存儲兩層的組合，比如說存儲雙活之上是oracle rac，那么就比較復雜了。

首先對于存儲本身的仲裁，應該有自己的算法，例如：

1)仲裁中心

2)最壞情況下，默認的算法。

對于夸中心的rac集群，同樣有自己的規(guī)則：

1)仲裁盤

2)通過網(wǎng)絡和磁盤心跳保證獲得票數(shù)最多的子集活著。

3)實例小的節(jié)點存活。

但是當二者結(jié)合的時候，就有更復雜的場景可能會出現(xiàn)，尤其是出現(xiàn)兩層架構(gòu)仲裁的結(jié)果不一致。

為了避免這個結(jié)果出現(xiàn)，那么我們需要攻克以下問題：

1. 如何保障仲裁觸發(fā)的時間序列一致。

2. 極端情況下的仲裁算法一致性。

例如，你可以通過oracle的仲裁參數(shù)misscount結(jié)合vplex的仲裁timeout參數(shù)來保障時間序列的一致性。

例如，你也可以調(diào)整各自默認算法的最終結(jié)果落到一邊。

例如，你也可以通過二次開發(fā)來實現(xiàn)二者的聯(lián)動。

***，所有的前提條件和策略都需要得到模擬實踐的檢驗。