存儲(chǔ)雙活架構(gòu)設(shè)計(jì)規(guī)范

存儲(chǔ)雙活架構(gòu)設(shè)計(jì)規(guī)范

我們知道，對于容災(zāi)架構(gòu)來講，腦裂是災(zāi)難性的事件。如果從一個(gè)統(tǒng)一集群的

調(diào)度變成兩個(gè)相互獨(dú)立的集群調(diào)度，意味著雙方的寫操作相互也是獨(dú)立的，但

是他們的存儲(chǔ)空間是共享的，AA模式下通過鎖機(jī)制控制并發(fā)，HA模式下通過存

儲(chǔ)卷的Owner控制寫的權(quán)限。但是獨(dú)立之后意味著兩個(gè)集群可以隨時(shí)寫入同樣

的存儲(chǔ)地址，必然會(huì)造成臟寫臟讀等一系列數(shù)據(jù)不一致事件，這對業(yè)務(wù)來講是

災(zāi)難性的。那么存儲(chǔ)雙活架構(gòu)的設(shè)計(jì)當(dāng)中，應(yīng)該采用什么樣的設(shè)計(jì)思路或者是

方法才能避免這種情況的發(fā)生？

四：

為避免腦裂，存儲(chǔ)雙活架構(gòu)設(shè)計(jì)應(yīng)遵循哪些思想和方法？

本次議題將由本人以及江西農(nóng)信運(yùn)維技術(shù)經(jīng)理鄧毓、哈爾濱銀行系統(tǒng)專家團(tuán)隊(duì)

存儲(chǔ)管理員張鵬分別主張議題下的相關(guān)關(guān)鍵點(diǎn)，幾位專家的主張?jiān)谀侈r(nóng)信資深

技術(shù)經(jīng)理雷智、寧夏銀行技術(shù)經(jīng)理陳明福的復(fù)議后，最終形成一定的共識(shí)供同

行參考。

?社區(qū)專家主張,

趙海某金融系統(tǒng)高級主管：

每一種集群都會(huì)有相應(yīng)的解房方法，通?？梢酝ㄟ^節(jié)點(diǎn)優(yōu)先級及仲裁的方式來

解決，但是我們在利用這些策略進(jìn)行架構(gòu)設(shè)計(jì)的時(shí)候必須知道其原理以及最佳

實(shí)踐的方法。

容災(zāi)設(shè)計(jì)過程中避免腦裂問題的思路

-默認(rèn)優(yōu)先級解決方案

以兩個(gè)節(jié)點(diǎn)的OracleRAC為例來講，OracleRACASM管理模式下，磁盤組通常

有三個(gè)(+DATA,+FRA,+OCR),在OCR磁盤組.當(dāng)中所有的磁盤中存儲(chǔ)的數(shù)據(jù)包

括兩部分，一部分是VoteFile,另外一部分就是OCR(Oracle

ClusterRegistry)oVoteFile是用來記錄集群節(jié)點(diǎn)的磁盤心跳信息，而OCR

是保存集群配置信息的數(shù)據(jù)。VoteFile,以整個(gè)文件的方式存儲(chǔ)在OCR磁盤

上，不做任何條帶。表1是其信息記錄的一個(gè)說明。

表1Oracle仲裁邏輯信息

表1是一個(gè)三節(jié)點(diǎn)的OracleRAC集群的VoteFile的一個(gè)示意矩陣，每一行是

一個(gè)節(jié)點(diǎn)的寫入的信息，例如第一行，Instance1分別把其對集群中的三個(gè)成

員（1、2、3）進(jìn)行私網(wǎng)檢測的結(jié)果寫入到仲裁文件當(dāng)中，Instance2、

Instances同樣把其檢測結(jié)果寫入仲裁文件，最終組成了三個(gè)節(jié)點(diǎn)的仲裁矩

陣。當(dāng)私網(wǎng)發(fā)生故障導(dǎo)致網(wǎng)絡(luò)上導(dǎo)致集群分割為幾個(gè)孤島子集的時(shí)候，在網(wǎng)絡(luò)

心跳同票數(shù)情況下，仲裁算法有兩個(gè)非常重要的規(guī)則：

一、保障隔離后的集群子集中節(jié)點(diǎn)數(shù)目最多的子集存活。

二、當(dāng)隔離后的集群子集獲得的仲裁票數(shù)相等時(shí)，保障實(shí)例號小者存活。

當(dāng)兩個(gè)節(jié)點(diǎn)的OracleRAC集群面臨私網(wǎng)故障的時(shí)候，必然會(huì)遵循以上規(guī)則，從

規(guī)則內(nèi)容上可以看出，第一條規(guī)則基本沒有什么意義，雙方的資源是對等的；

但是第二條規(guī)則直接決定了集群的最終狀態(tài)，那就是實(shí)例號小的節(jié)點(diǎn)成為新的

集群，這就避免了腦裂的存在。

-資源失衡配置解決方案

所謂資源失衡配置解決方案，就是要在容災(zāi)設(shè)計(jì)之初就保障主數(shù)據(jù)中心的資源

配置要多于災(zāi)備中心，從而使得兩個(gè)數(shù)據(jù)中心節(jié)點(diǎn)可以獲取到的仲裁資源處于

不平衡狀態(tài)。

圖1資源失衡架構(gòu)

如圖1所示，容災(zāi)設(shè)計(jì)的時(shí)候可以將主備數(shù)據(jù)中心的節(jié)點(diǎn)分布數(shù)量或者仲裁文

件分布數(shù)量按照2」的非平衡策略設(shè)置。那么按照集群仲裁的一般規(guī)則：發(fā)生

集群分裂故障的時(shí)候，可以獲得更多仲裁資源的子集將成為新的集群。當(dāng)發(fā)生

數(shù)據(jù)中心之間的網(wǎng)絡(luò)故障的時(shí)候：

1）主數(shù)據(jù)中心內(nèi)部兩個(gè)節(jié)點(diǎn)可以獲取到更多的網(wǎng)絡(luò)心跳，自然會(huì)接管集群。

2）主數(shù)據(jù)中心的節(jié)點(diǎn)可以獲取到更多的磁盤心跳，同樣會(huì)接管集群。

這也符合我們設(shè)計(jì)之初衷。但是，這種方法只適合于AA模式的多節(jié)點(diǎn)集群，不

適合HA模式的架構(gòu)。

自定義優(yōu)先級解決方案

自定義優(yōu)先級的解決方案，其實(shí)本質(zhì)上與OracleRAC的仲裁算法第二條“當(dāng)隔

離后的集群子集獲得的仲裁票數(shù)相等時(shí)，保障實(shí)例號小者存活。”是一樣的。

只不過對于OracleRAC,當(dāng)通過第一條規(guī)則無法判斷的時(shí)候（節(jié)點(diǎn)獲取的仲裁

資源矩陣是平衡的），它默認(rèn)采用了實(shí)例號定義其優(yōu)先級。

圖2自定義優(yōu)先級架構(gòu)

而其他的一些容災(zāi)方案，這個(gè)優(yōu)先級定義的靈活性留給了客戶。例如圖2當(dāng)中

的VPLEX產(chǎn)品，尤其是在雙活架構(gòu)的設(shè)計(jì)當(dāng)中，有可能因?yàn)榈赜颉⒃O(shè)備新舊、

運(yùn)營管理等方面的差異，導(dǎo)致災(zāi)備中心的運(yùn)行能力會(huì)稍差，那么發(fā)生數(shù)據(jù)中心

之間隔離的這種故障時(shí)，大家往往希望保留主數(shù)據(jù)中心的運(yùn)行。這個(gè)時(shí)候客戶

就可以根據(jù)主數(shù)據(jù)中心的節(jié)點(diǎn)標(biāo)識(shí)來固定其仲裁優(yōu)先級。

■仲裁解決方案

o網(wǎng)絡(luò)仲裁

網(wǎng)絡(luò)資源是集群仲裁當(dāng)中非常重要的一種心跳資源，因此通過第三方網(wǎng)絡(luò)資源

的可達(dá)性心跳信息來判斷對稱集群分裂后的新秩序也是一種非常有效的方法。

一般在以存儲(chǔ)網(wǎng)關(guān)實(shí)現(xiàn)數(shù)據(jù)雙寫的容災(zāi)架構(gòu)當(dāng)中比較常見，比如VPLEX、SVC、

MCC等。具體原理如圖3所示：

圖3三方網(wǎng)絡(luò)仲裁架構(gòu)

第三方仲裁點(diǎn)需要滿足的條件：與主備兩個(gè)數(shù)據(jù)中心L3可達(dá)，并且網(wǎng)絡(luò)質(zhì)量穩(wěn)

定。

仲裁點(diǎn)一般需要安裝具備網(wǎng)絡(luò)探測功能的虛擬服務(wù)器或者物理服務(wù)器，具備運(yùn)

行條件。

如圖3所示，仲裁點(diǎn)服務(wù)器上的軟件會(huì)與組成集群的存儲(chǔ)器網(wǎng)關(guān)兩個(gè)節(jié)點(diǎn)分別

發(fā)送PING/ACK來確認(rèn)雙方的健康情況，集群會(huì)把兩個(gè)節(jié)點(diǎn)與笫三方仲裁點(diǎn)的網(wǎng)

絡(luò)仲裁心跳看做是最終的裁判。VplexWitness通過管理IP網(wǎng)絡(luò)連接至兩個(gè)

集群節(jié)點(diǎn)，通過將其自身的觀察與集群定期報(bào)告的信息進(jìn)行協(xié)調(diào)，讓集群可區(qū)

分是集群內(nèi)故障還是集群間鏈路故障，并在這些情況下自動(dòng)繼續(xù)相應(yīng)站點(diǎn)上的

I/O服務(wù)。VplexWitness僅當(dāng)分離規(guī)則沒有定義時(shí)才會(huì)生效。當(dāng)然細(xì)心的讀

者可能產(chǎn)生了一個(gè)新的問題：

如果數(shù)據(jù)中心與第三仲裁站點(diǎn)的網(wǎng)絡(luò)發(fā)生故障，那會(huì)不會(huì)影響集群本身的運(yùn)

行？

什么是仲裁？仲裁是只有發(fā)生集群隔離故障的時(shí)候才會(huì)起作用，如果沒有發(fā)生

數(shù)據(jù)中心之間的隔離故障的時(shí)候，即使他們的一方或者雙方于第三方仲裁站點(diǎn)

發(fā)生網(wǎng)絡(luò)暫時(shí)中斷的事件，也不會(huì)對既有集群造成任何健康影響。我們需要做

的是保障第三方仲裁資源在發(fā)生故障的時(shí)候有效就可以了（監(jiān)控&及時(shí)修復(fù)）。

O存儲(chǔ)仲裁

存儲(chǔ)一般是數(shù)據(jù)庫集群當(dāng)中非常關(guān)鍵的仲裁資源，數(shù)據(jù)庫集群的節(jié)點(diǎn)負(fù)載比較

重，不像存儲(chǔ)網(wǎng)關(guān)模式的集群，可以再設(shè)計(jì)與WitnessNode的通訊接口。所以

在這類技術(shù)方窠的容災(zāi)設(shè)計(jì)當(dāng)中，通常會(huì)用第三方存儲(chǔ)陣列來作為集群的第三

方仲裁點(diǎn)。例如OracleExtendedRAC、HA&Oracle.HA&DB2等。具體原理如圖

4所示：

圖4三方存儲(chǔ)仲裁架構(gòu)

1）笫三方站點(diǎn)放置一個(gè)存儲(chǔ)陣列、并且與兩個(gè)數(shù)據(jù)中心網(wǎng)絡(luò)穩(wěn)定可達(dá)。

2）存儲(chǔ)陣列以NFS或者ISCSI方式提供共享存儲(chǔ)卷或文件服務(wù)給兩個(gè)中心的集

群節(jié)點(diǎn)。

3）集群配置的時(shí)候，將這個(gè)共享存儲(chǔ)卷或者文件作為集群的磁盤仲裁之一。

當(dāng)雙中心的集群發(fā)生隔離故障的時(shí)候，集群通過第三方的仲裁磁盤或者文件來

判斷集群的新秩序。

O對稱隔離場景

集群發(fā)生的故障場景有很多，有可能是網(wǎng)卡故障導(dǎo)致節(jié)點(diǎn)隔離，也有可能是鏈

路問題導(dǎo)致節(jié)點(diǎn)隔離。鏈路問題本身又分很多種，有一種場景即使存在第三仲

裁的場景下，依然有可能是對稱平衡的狀態(tài)。如圖5所示：

圖5對稱隔離架構(gòu)

如圖5所示，當(dāng)兩個(gè)中心之間的鏈路中斷，但是其他各條線路都完好無損的情

況下，及時(shí)存在第三方仲裁，那么集群分裂后的仲裁資源分布依然是平衡對稱

的，這又該如何解決呢？

一般認(rèn)為有兩種解決方式:

1）優(yōu)先級定義解決方案，也就是說我們在第二節(jié)提到的解決方案必須成為容災(zāi)

設(shè)封的必選項(xiàng)。

2）仲裁爭奪方案，無論是三方的網(wǎng)絡(luò)仲裁還是存儲(chǔ)仲裁，假設(shè)出現(xiàn)集群隔離故

障后各個(gè)節(jié)點(diǎn)開始爭奪這個(gè)資源，那么必然有先后順序之分，以先到先得的規(guī)

則來重新定義集群新秩序。這種方案尤其適用于以HA模式的容災(zāi)架構(gòu)。當(dāng)然具

體如何爭奪，如何確認(rèn)爭奪維度及結(jié)果就需要根據(jù)不同產(chǎn)品架構(gòu)來探討了。

■仲裁沖突解決方案

O什么是仲裁沖突？

我們知道在容災(zāi)整體設(shè)計(jì)當(dāng)中，需要有網(wǎng)絡(luò)層、計(jì)算層、數(shù)據(jù)庫服務(wù)層、存儲(chǔ)

服務(wù)層等各方面的設(shè)計(jì)。

他們在縱向上是疊加的形態(tài)，如圖6所示。

圖6仲裁沖突示意圖

圖6是我們將容災(zāi)設(shè)計(jì)當(dāng)中縱向抽象出來的幾個(gè)功能層，其中數(shù)據(jù)跨中心復(fù)制

是實(shí)現(xiàn)雙活容災(zāi)的前提條件，它是支撐網(wǎng)絡(luò)及計(jì)算層具備容災(zāi)意義的基礎(chǔ)，那

么如何實(shí)現(xiàn)數(shù)據(jù)復(fù)制，我們在《企業(yè)容災(zāi)選型指南-2：數(shù)據(jù)復(fù)制技術(shù)》當(dāng)中

介紹了很多方法，基本上集中在數(shù)據(jù)庫層和存儲(chǔ)層去實(shí)現(xiàn)。假設(shè)我們采用了存

儲(chǔ)層的數(shù)據(jù)復(fù)制技術(shù)，存儲(chǔ)層提供的虛擬分布式卷對于數(shù)據(jù)庫集群來講是透明

的。

當(dāng)數(shù)據(jù)中心之間發(fā)生線路故障的時(shí)候，數(shù)據(jù)庫集群和存儲(chǔ)網(wǎng)關(guān)組成的集群是兩

個(gè)不同的集群，他們的仲裁結(jié)果會(huì)不會(huì)不一致?

集群的仲裁是瞬間完成的，其觸發(fā)條件有可能有片刻的先后順序之差。數(shù)據(jù)庫

層的仲裁先于存儲(chǔ)層的仲裁，那么雖然概率小，但是這個(gè)沖突是完全有可能

的。但是如果存儲(chǔ)的仲裁發(fā)生在數(shù)據(jù)庫之前，理論上這個(gè)沖突是可以避免的，

因?yàn)榇鎯?chǔ)卷是數(shù)據(jù)庫集群健康運(yùn)行的前提。

如何解決仲裁沖突問題？

以O(shè)racleRAC和VPLEX結(jié)合的架構(gòu)為例，我們探討它的解決方法。

風(fēng)險(xiǎn)發(fā)生的引發(fā)點(diǎn)有兩個(gè)：

1）集群的仲裁觸發(fā)條件導(dǎo)致的仲裁順序發(fā)生紊亂；

2）對稱平衡狀態(tài)下的仲裁規(guī)則沖突。

資源被1:1割裂之后的默認(rèn)仲裁策略不一致。也就是說，只要控制這兩個(gè)引發(fā)

點(diǎn)，這個(gè)問題從理論上也就避免了。對于第一個(gè)引發(fā)點(diǎn)來講，實(shí)際上存儲(chǔ)集群

的默認(rèn)仲裁觸發(fā)時(shí)間會(huì)是15秒左右，而數(shù)據(jù)庫仲裁觸發(fā)的控制參數(shù)由

misscount這個(gè)參數(shù)來決定，所以我們只要將misscount這個(gè)參數(shù)調(diào)整到15秒

之后，也就是說理論上絕對保障存儲(chǔ)集群仲裁在前，數(shù)據(jù)庫仲裁在后，那么第

1個(gè)引發(fā)點(diǎn)就沒有了。對于第二個(gè)引發(fā)點(diǎn)來講，假設(shè)兩站點(diǎn)節(jié)點(diǎn)資源對等，仲

裁選票同樣對等的情況下，存儲(chǔ)集群會(huì)有一個(gè)默認(rèn)的Winner策略，同樣在這種

情況下數(shù)據(jù)庫集群也有一個(gè)默認(rèn)仲裁策略：選擇實(shí)例號小的集群存活。只要我

們保證這兩個(gè)策略結(jié)果的一致性，那么笫2個(gè)引發(fā)點(diǎn)也就不存在了。

鄧毓江西農(nóng)信運(yùn)維技術(shù)經(jīng)理：

為防止腦裂發(fā)生給企業(yè)生產(chǎn)業(yè)務(wù)帶來重大影響，存儲(chǔ)跨中心雙活方案設(shè)計(jì)的架

構(gòu)設(shè)計(jì)和解決思路必須兩面抓，一面是“防”，一面是“解”。

存儲(chǔ)雙活模式下，腦裂問題簡單說就是兩個(gè)數(shù)據(jù)中心間的網(wǎng)絡(luò)和存儲(chǔ)鏈路同時(shí)

發(fā)生中斷，導(dǎo)致兩個(gè)數(shù)據(jù)中心內(nèi)的應(yīng)用、數(shù)據(jù)庫或者操作系統(tǒng)同時(shí)搶占和利用

共享的資源，造成資源的數(shù)據(jù)不一致，產(chǎn)生重大影響。這個(gè)問題是在存儲(chǔ)跨中

心雙活方案設(shè)計(jì)、實(shí)施階段不可避免要遇到的。遇到該類問題時(shí)，通常的架構(gòu)

設(shè)計(jì)和解決思路有兩個(gè)方面，一方面是“防”，另一方面是“解”?！胺馈敝?/p>

要是防止腦裂問題的發(fā)生，防止兩個(gè)數(shù)據(jù)中心間鏈路全部中新，將產(chǎn)生腦裂問

題的根源掐斷。在故障場景下，只要兩個(gè)數(shù)據(jù)中心間能夠存在鏈路通訊，就不

會(huì)有進(jìn)一步的腦裂問題產(chǎn)生?！敖狻敝饕墙鉀Q腦裂問題的發(fā)生，利用合理、

充分的仲裁機(jī)制，以極短的故障恢復(fù)時(shí)間和幾乎為零的故障恢復(fù)目標(biāo)，解決腦

裂故障災(zāi)難。

“防”方面：

1）增加鏈路冗余度：存儲(chǔ)雙活模式通常是企業(yè)自己購買波分設(shè)備，然后租用運(yùn)

營商的裸光纖作為通訊的鏈路。所以波分設(shè)備需要冗余，裸光纖也要冗余。對

于波分設(shè)備購買即可。裸光纖通常租用兩家或兩家以上的運(yùn)營商線路，比如電

信和聯(lián)通。電信的裸光纖也需要冗余，聯(lián)通的裸光纖也需要冗余，防止單根裸

光纖意外割斷或者損壞。然而單家運(yùn)營商的裸纖都通常在一個(gè)弱點(diǎn)井中，一起

意外割斷的事情常有，所以需要兩家運(yùn)營商互相冗余。這兩家運(yùn)營商裸纖的路

線還不能一致，弱電井需要在不同的街道，并且分別走不同的路線到達(dá)目的

地。

2）增強(qiáng)鏈路監(jiān)測：對于鏈路的監(jiān)測機(jī)制一定要在建設(shè)存儲(chǔ)雙活之前建立。由于

通常是租用運(yùn)營商的鏈路，鏈路經(jīng)過了多少中繼、多少設(shè)備企業(yè)是不得知的，

企業(yè)只能在波分端建立有效的監(jiān)測機(jī)制，有些波分設(shè)備也有專門的監(jiān)控軟件支

持。而且也要求和運(yùn)營商建立監(jiān)測聯(lián)動(dòng)機(jī)制，運(yùn)營商監(jiān)測到鏈路質(zhì)量有問題，

需要第一時(shí)間告知企業(yè)，再做出合理的決策。

“解”方面：

在存儲(chǔ)雙活方案中，防范腦裂通用的做法就是使用仲裁機(jī)制，在第三站點(diǎn)放置

仲裁服務(wù)器或者仲裁存儲(chǔ)陣列。通常有以下四種方式：

1）優(yōu)先級站點(diǎn)方式。這種方式最簡單，在沒有第三方站點(diǎn)的情況下使用，在發(fā)

生鏈路中斷腦裂現(xiàn)象時(shí)，從兩個(gè)站點(diǎn)中選一個(gè)優(yōu)先站點(diǎn)，發(fā)生腦裂后優(yōu)先站點(diǎn)

仲裁成功，既強(qiáng)制使優(yōu)先的存儲(chǔ)節(jié)點(diǎn)繼續(xù)提供服務(wù)。但如集群發(fā)生腦裂后，優(yōu)

先站點(diǎn)也發(fā)生故障，則會(huì)導(dǎo)致業(yè)務(wù)全部中斷，因此這種方案并非推薦的方案。

2）軟件仲裁方式。這種方式應(yīng)用比較普遍，在有第三方站點(diǎn)的情況下使用，采

用專門的仲裁軟件來實(shí)現(xiàn)，仲裁軟件放在第三站點(diǎn)，可以跑在物理服務(wù)器或虛

擬機(jī)上，甚至可以部署到公有云上，在發(fā)生鏈路中斷腦裂現(xiàn)象時(shí)，仲裁軟件節(jié)

點(diǎn)和雙活的存儲(chǔ)節(jié)點(diǎn)一道選舉出存活的存儲(chǔ)節(jié)點(diǎn)繼續(xù)提供服務(wù)。

3）陣列仲裁盤方式。這種方式應(yīng)用于部分存儲(chǔ)雙活方案，該方式是在第三站點(diǎn)

采用另外一臺(tái)陣列創(chuàng)建仲裁盤，在發(fā)生鏈路中斷腦裂現(xiàn)象時(shí)，仲裁磁盤和雙活

的存儲(chǔ)節(jié)點(diǎn)一道選舉出存活的存儲(chǔ)節(jié)點(diǎn)繼續(xù)提供服務(wù)。這種方式穩(wěn)定性、可靠

性比較高。

4）雙仲裁方式。少部分存儲(chǔ)雙活方案支持，該方式可同時(shí)設(shè)置優(yōu)先級站點(diǎn)和軟

件仲裁/陣列仲裁盤方式，實(shí)現(xiàn)雙仲裁保護(hù)能力，最大限度保障存儲(chǔ)雙活方案的

高可用。部分方案還支持按雙活Pair或雙活一致性組（多對雙活Pair）為單

位進(jìn)行仲裁，仲裁精細(xì)度高，通?？膳渲靡詷I(yè)務(wù)為粒度進(jìn)行仲裁（雙活一致性

組）。仲裁之后，業(yè)務(wù)均衡分布訪問兩個(gè)存儲(chǔ)，實(shí)現(xiàn)站點(diǎn)間鏈路故障時(shí)，主機(jī)

就近訪問。

張鵬哈爾濱銀行系統(tǒng)專家團(tuán)隊(duì)存儲(chǔ)管理員：

在存儲(chǔ)雙活容災(zāi)系統(tǒng)中，發(fā)生腦裂的根本原因是雙系統(tǒng)之間心跳中斷，導(dǎo)致資

源搶占影響數(shù)據(jù)一致性。為防止腦裂的產(chǎn)生，通常需要在容災(zāi)系統(tǒng)中增加仲裁

軟件對兩端陣列系統(tǒng)進(jìn)行仲裁，一旦出現(xiàn)任一數(shù)據(jù)中心整體故障或陣列間鏈路

故障時(shí)，陣列向仲裁服務(wù)器發(fā)起仲裁請求，由仲裁服務(wù)器綜合判斷哪端獲勝。

仲裁獲勝的一方繼續(xù)提供服務(wù)，另一方停止服務(wù)，由此防止了腦裂現(xiàn)象的產(chǎn)生。

雙活系統(tǒng)的仲裁方案主要分如下三種場景模式。

靜態(tài)優(yōu)先級模式場景:

用戶在未配置仲裁服務(wù)器或仲裁服務(wù)器無法訪問時(shí)，雙活仲裁模式為靜態(tài)優(yōu)先

級模式，雙活Pair發(fā)生仲裁時(shí)優(yōu)先站點(diǎn)端獲得仲裁并提供業(yè)務(wù)。

1）當(dāng)存儲(chǔ)系統(tǒng)間鏈路故障（如圖7）

雙活Pair為待同步狀態(tài)，經(jīng)過仲裁，設(shè)置的優(yōu)先站點(diǎn)數(shù)據(jù)中心A的LUN繼續(xù)運(yùn)

行業(yè)務(wù)，非優(yōu)先站點(diǎn)數(shù)據(jù)中心B的LUN停止運(yùn)行業(yè)務(wù)。

圖7存儲(chǔ)間鏈路故障

2）當(dāng)非優(yōu)先站點(diǎn)數(shù)據(jù)中心B故障（如圖8）

雙活Pair為待同步狀態(tài)，經(jīng)過仲裁，設(shè)置的優(yōu)先站點(diǎn)數(shù)據(jù)中心A的LUN繼續(xù)運(yùn)

行業(yè)務(wù)，非優(yōu)先站點(diǎn)數(shù)據(jù)中心B的LUN停止運(yùn)行業(yè)務(wù)。

圖8非優(yōu)先站點(diǎn)數(shù)據(jù)中心B故障

3）當(dāng)優(yōu)先站點(diǎn)數(shù)據(jù)中心A故障（如圖9）

雙活Pair為待同步狀態(tài)，數(shù)據(jù)中心A的LUN無法訪問、數(shù)據(jù)中心B的LUN停止

運(yùn)行業(yè)務(wù)。此時(shí)，非優(yōu)先站點(diǎn)不能自動(dòng)接管雙活業(yè)務(wù)，雙活業(yè)務(wù)停止，需要人

工強(qiáng)制啟動(dòng)非優(yōu)先站點(diǎn)雙活業(yè)務(wù)。

圖9優(yōu)先站點(diǎn)數(shù)據(jù)中心A故障

單仲裁服務(wù)器場景：

仲裁服務(wù)器模式下，一旦出現(xiàn)任一數(shù)據(jù)中心整體故障或陣列間鏈路故障時(shí)，陣

列向仲裁服務(wù)器發(fā)起仲裁請求，由仲裁服務(wù)器綜合判斷哪端獲勝，仲裁獲勝的

一方繼續(xù)提供服務(wù)，另一方停止服務(wù)，仲裁服務(wù)器模式下優(yōu)先站點(diǎn)會(huì)優(yōu)先獲得

仲裁勝利。

1）當(dāng)存儲(chǔ)系統(tǒng)間鏈路故障（如圖10）

雙活Pair為待同步狀態(tài)，優(yōu)先站點(diǎn)數(shù)據(jù)中心A的LUN繼續(xù)運(yùn)行業(yè)務(wù)，非優(yōu)先站

點(diǎn)數(shù)據(jù)中心B的LUN停止業(yè)務(wù)。

4

/

*

/

圖10單仲裁存儲(chǔ)間鏈路故障

2）當(dāng)優(yōu)先站點(diǎn)數(shù)據(jù)中心A的存儲(chǔ)系統(tǒng)故障（如圖11）

雙活Pair為待同步狀態(tài)，優(yōu)先站點(diǎn)數(shù)據(jù)中心A的LUN失效、數(shù)據(jù)中心B的LUN

繼續(xù)運(yùn)行業(yè)務(wù)。

圖11單仲裁優(yōu)先站點(diǎn)數(shù)據(jù)中心A故障

3）當(dāng)仲裁服務(wù)器故障時(shí),存儲(chǔ)系統(tǒng)間復(fù)制鏈路同時(shí)故障（如圖12）

雙活Pair為待同步狀態(tài),此時(shí)仲裁服務(wù)器無法執(zhí)行仲裁判斷，無法決策優(yōu)先站

點(diǎn)，數(shù)據(jù)中心A的LUN與數(shù)據(jù)中心B的LUN均停止業(yè)務(wù)。

圖12單仲裁故障+存儲(chǔ)間鏈路故障

仲裁站點(diǎn)配置兩臺(tái)仲裁服務(wù)器時(shí)，如果主仲裁服務(wù)器到兩端陣列之間所有鏈路

斷開，且備仲裁服務(wù)器與兩端陣列連接正常、雙活站點(diǎn)間鏈路也正常時(shí)，系統(tǒng)

在主仲裁故障后1分鐘內(nèi)自動(dòng)切換到備仲裁服務(wù)器，由備仲裁服務(wù)器來執(zhí)行仲

裁功能。

1）一臺(tái)存儲(chǔ)系統(tǒng)與對端存儲(chǔ)系統(tǒng)、仲裁服務(wù)器之間的鏈路同時(shí)故障（如圖

13）

雙活Pair為待同步狀態(tài)，主沖裁服務(wù)器繼續(xù)工作，數(shù)據(jù)中心A的LUN停止業(yè)

務(wù)、數(shù)據(jù)中心B的LUN繼續(xù)運(yùn)行業(yè)務(wù)。

圖13雙仲裁主仲裁A中心鏈路故障+存儲(chǔ)間鏈路故障

2）一臺(tái)存儲(chǔ)系統(tǒng)故障，且對端存儲(chǔ)系統(tǒng)與主仲裁服務(wù)器鏈路故障（如圖14）

當(dāng)存儲(chǔ)系統(tǒng)先故障，仲裁鏈路后故障：

?當(dāng)故障間隔時(shí)間60秒以內(nèi)（包括60秒），主仲裁服務(wù)器繼續(xù)工作，數(shù)據(jù)中

心A的LUN無法訪問、數(shù)據(jù)中心B的LUN可能停止運(yùn)行業(yè)務(wù)。

?當(dāng)故障間隔時(shí)間60秒以上,主仲裁服務(wù)器繼續(xù)工作，數(shù)據(jù)中心A的LUN無

法訪問、數(shù)據(jù)中心B的LUN繼續(xù)運(yùn)行業(yè)務(wù)。

當(dāng)仲裁鏈路先故障，存儲(chǔ)系統(tǒng)后故障：

?主仲裁服務(wù)器繼續(xù)工作，數(shù)據(jù)中心A的LUN無法訪問、數(shù)據(jù)中心B的LUN停

止運(yùn)行業(yè)務(wù)。

圖14雙仲裁主仲裁B中心鏈路故障+A中心故障

3）當(dāng)主仲裁服務(wù)器與優(yōu)先站點(diǎn)（數(shù)據(jù)中心A）的鏈路故障，備仲裁服務(wù)器到非

優(yōu)先站點(diǎn)（數(shù)據(jù)中心B）的鏈路故障，以及存儲(chǔ)設(shè)備間的鏈路故障同時(shí)發(fā)生

（如圖15）

雙活Pair為待同步狀態(tài)，主仲裁服務(wù)器繼續(xù)工作，數(shù)據(jù)中心A的LUN停止運(yùn)行

業(yè)務(wù)，數(shù)據(jù)中心B的LUN繼續(xù)運(yùn)行業(yè)務(wù)。

圖15雙仲裁主仲裁A中心鏈路故障+備仲裁B中心鏈路故障+存儲(chǔ)間鏈路故障

4）當(dāng)主仲裁服務(wù)器與非優(yōu)先站點(diǎn)（數(shù)據(jù)中心B）的鏈路故障，備仲裁服務(wù)器到

優(yōu)先站點(diǎn)（數(shù)據(jù)中心A）的鏈路故障，及存儲(chǔ)設(shè)備間的鏈路故障同時(shí)故障（如

圖16）

雙活Pair為待同步狀態(tài)，主沖裁服務(wù)器繼續(xù)工作，數(shù)據(jù)中心A的LUN繼續(xù)運(yùn)行

業(yè)務(wù)，數(shù)據(jù)中心B的LUN停止運(yùn)行業(yè)務(wù)。

圖16雙仲裁主仲裁B中心鏈路故障十備仲裁A中心鏈路故障+存儲(chǔ)間鏈路故障

5）當(dāng)主仲裁服務(wù)器故障后，存儲(chǔ)系統(tǒng)間鏈路也發(fā)生故障（如圖17）

雙活Pair為待同步狀態(tài)，仲裁服務(wù)器根據(jù)兩故障間隔時(shí)間，有兩種結(jié)果。

仲裁結(jié)果1:當(dāng)發(fā)生主仲裁服務(wù)器故障和存儲(chǔ)系統(tǒng)間鏈路故障，且兩個(gè)故障之

間的時(shí)間間隔60秒以上時(shí)，備仲裁服務(wù)器接替主仲裁服務(wù)器繼續(xù)工作。數(shù)據(jù)中

心A通過備仲裁服務(wù)器仲裁獲勝，數(shù)據(jù)中心A的LUN繼續(xù)運(yùn)行業(yè)務(wù)，數(shù)據(jù)中心

B的LUN停止業(yè)務(wù)。

仲裁結(jié)果2：當(dāng)發(fā)生主仲裁服務(wù)器故障和存儲(chǔ)系統(tǒng)間鏈路故障，且兩個(gè)故障之

間的時(shí)間間隔