企業(yè)容災(zāi)規(guī)劃建設(shè)三大階段關(guān)鍵問題總結(jié)及最佳實踐

企業(yè)容災(zāi)規(guī)劃建設(shè)三大階段關(guān)鍵問題總結(jié)及最佳實踐

近些年興起的雙活災(zāi)備解決方案逐漸成為探討業(yè)務(wù)連續(xù)性的主旋律。但是面對技術(shù)的日新月異和信息技術(shù)的多元化發(fā)展，如何提高企業(yè)整體容災(zāi)體系標準，建立一套適合自己的容災(zāi)體系架構(gòu)，一直是企業(yè)面臨的重大挑戰(zhàn)。甚至有些企業(yè)花費大量時間調(diào)研學習之后還是無從下手。歸根結(jié)底是一些關(guān)鍵問題困擾著。本文根據(jù)近期社區(qū)圍繞企業(yè)容災(zāi)規(guī)劃建設(shè)的全過程進行的討論議題梳理而成。包括：容災(zāi)規(guī)劃建設(shè)之初需要考慮的問題、容災(zāi)架構(gòu)規(guī)劃階段需要定性的問題、容災(zāi)建設(shè)過程當中必須要考慮的一些關(guān)鍵技術(shù)問題。一、關(guān)于容災(zāi)規(guī)劃建設(shè)之初需要考慮的問題【關(guān)鍵問題】金融企業(yè)搞容災(zāi)建設(shè)應(yīng)該從什么地方著手？第一步需要做什么事情？容災(zāi)建設(shè)的合規(guī)性要求有哪些？如何進行容災(zāi)建設(shè)規(guī)劃？容災(zāi)的RTO和RPO需要如何來制定？數(shù)據(jù)同步技術(shù)到底有沒有實際作用？【關(guān)鍵總結(jié)】1、何理解備份、高可用、容災(zāi)、容錯等常用概念？從作用范疇上來講，備份恢復(fù)、高可用架構(gòu)設(shè)計、容錯設(shè)計、容災(zāi)都是為了保障業(yè)務(wù)連續(xù)性的一種手段、技術(shù)和工具。在廣義的容災(zāi)設(shè)計當中必然也會包括基礎(chǔ)架構(gòu)的高可用設(shè)計、設(shè)備軟件的容錯設(shè)計以及必要的備份恢復(fù)。但是備份恢復(fù)、高可用和容錯是可以獨立存在的，不依賴容災(zāi)架構(gòu)。從設(shè)計功能上來講，備份恢復(fù)不僅僅可以解決由物理故障引起的數(shù)據(jù)損壞和丟失，而且更重要的是它可以解決由人為的邏輯錯誤導致的數(shù)據(jù)損壞和丟失，比如誤刪數(shù)據(jù)。備份恢復(fù)是一種事后的補救措施，也就是說它只能發(fā)生在問題發(fā)生之后。容錯、高可用、容災(zāi)中核心的架構(gòu)設(shè)計是為了解決實時問題，是一種事中解決問題的思路，但是這兩者都無法解決人為導致的邏輯錯誤故障導致的業(yè)務(wù)中斷，只能解決物理故障導致的業(yè)務(wù)中斷問題。從所屬性質(zhì)來講，業(yè)務(wù)連續(xù)性是著眼業(yè)務(wù)層面的一套解決思路或者方法論指導下的制度、流程、方案、技術(shù)、工具、資源等一系列元素組成的。而容災(zāi)、高可用、備份恢復(fù)、容錯僅僅是為了保障業(yè)務(wù)連續(xù)而對基礎(chǔ)架構(gòu)進行設(shè)計實現(xiàn)的技術(shù)工具或者手段。2、企業(yè)容災(zāi)架構(gòu)的核心目標是什么？也就是說我們?yōu)槭裁匆ㄟ@么大力氣去搞容災(zāi)建設(shè)？就一句話，RTO&RPO是搞容災(zāi)建設(shè)的最核心目標，一切容災(zāi)建設(shè)目的都需要回到RTO和RPO的評估上來。RTO：企業(yè)可容許服務(wù)中斷的時間長度，簡言之業(yè)務(wù)可以恢復(fù)的最快時間。RPO：企業(yè)可容許數(shù)據(jù)丟失的數(shù)量級，簡言之數(shù)據(jù)可以恢復(fù)到最新的時刻點。RTO關(guān)注的是數(shù)據(jù)丟失的多少，而對什么時候恢復(fù)業(yè)務(wù)中斷沒有要求；RPO關(guān)注的是什么時候恢復(fù)業(yè)務(wù)，但是歷史數(shù)據(jù)丟失多少并沒有要求。只有這兩個結(jié)合起來才是對現(xiàn)實生活當中的業(yè)務(wù)連續(xù)性的約束。要實現(xiàn)什么樣的RTO&RPO目標，一定會有相應(yīng)的方案來支撐，也必然有對此方案需要付出的IT成本投入。我們評估容災(zāi)的目標要求，一定是從RTO&RPO的選定范圍出發(fā)，然后權(quán)衡企業(yè)可以付諸的投入，最終確定合理的容災(zāi)建設(shè)方案。3、數(shù)據(jù)復(fù)制技術(shù)在容災(zāi)當中的意義？如果上升到商業(yè)業(yè)務(wù)的高度，那么一切容災(zāi)技術(shù)都是為了業(yè)務(wù)的連續(xù)性服務(wù)的。具體來說，數(shù)據(jù)復(fù)制技術(shù)即完成數(shù)據(jù)從一個數(shù)據(jù)中心到另外的數(shù)據(jù)中心的冗余性保護。一旦發(fā)生災(zāi)難導致一個數(shù)據(jù)中心的數(shù)據(jù)丟失或者損壞，可以通過另外一個數(shù)據(jù)中心的數(shù)據(jù)來支撐應(yīng)用系統(tǒng)運行。沒有應(yīng)用系統(tǒng)的不中斷運行就沒有業(yè)務(wù)的連續(xù)性可言，沒有數(shù)據(jù)的存在就沒有應(yīng)用系統(tǒng)的不中斷運行可言，沒有數(shù)據(jù)復(fù)制技術(shù)的支撐就沒有容災(zāi)的必要性可言。數(shù)據(jù)在應(yīng)用系統(tǒng)當中的地位直接決定了數(shù)據(jù)復(fù)制技術(shù)在容災(zāi)框架當中的絕對必要性地位。①RPO：簡言之，RPO就是衡量災(zāi)難時刻依靠容災(zāi)手段可以丟失的最少數(shù)據(jù)。數(shù)據(jù)復(fù)制的及時性直接決定RPO的量級標準，如果數(shù)據(jù)復(fù)制是同步模式，那么RPO必然是零。如果數(shù)據(jù)是異步模式，那么RPO就直接與數(shù)據(jù)復(fù)制的異步效率指標息息相關(guān)。②RTO：簡言之，RTO就是衡量災(zāi)難時刻依靠容災(zāi)手段可以恢復(fù)業(yè)務(wù)的最短時間。這個不僅僅取決于數(shù)據(jù)復(fù)制技術(shù)，還要依賴于縱向的網(wǎng)絡(luò)、負載分發(fā)、服務(wù)器、應(yīng)用、數(shù)據(jù)庫、存儲等各個層面的恢復(fù)技術(shù)。但是，數(shù)據(jù)復(fù)制技術(shù)一定是所有恢復(fù)技術(shù)的基石，沒有這個基石，及時所有層面都恢復(fù)了，沒有數(shù)據(jù)的業(yè)務(wù)訪問也依然無效。因此，數(shù)據(jù)復(fù)制技術(shù)是容災(zāi)體系架構(gòu)當中最關(guān)鍵的技術(shù)元素。數(shù)據(jù)同步技術(shù)是容災(zāi)備份技術(shù)，參考的必要的條件。數(shù)據(jù)庫同步技術(shù)是應(yīng)用系統(tǒng)處理核心，不但應(yīng)用系統(tǒng)需要向數(shù)據(jù)庫進行增/刪改/查操作，同樣數(shù)據(jù)倉庫也需要從眾多的數(shù)據(jù)庫中獲取不同交易數(shù)據(jù)來完善自身的數(shù)據(jù)集。技術(shù)需求

：越來越多實時數(shù)據(jù)查詢應(yīng)用使得數(shù)據(jù)庫不能直接為客戶帶來直接查詢結(jié)果，因為數(shù)據(jù)庫負荷越來越重，更多的系統(tǒng)無法享受直接查詢的結(jié)果，這樣數(shù)據(jù)庫同步技術(shù)就應(yīng)運而生。技術(shù)指標

：1--重要數(shù)據(jù)必須可以實時查詢，至少到秒級別2--必須能夠限制查詢?nèi)藛T的條件3--查詢系統(tǒng)主機和業(yè)務(wù)系統(tǒng)主機必須處于內(nèi)外網(wǎng)，保證系統(tǒng)安全4--必須能夠?qū)π枰降腛WNER、TABLE、FIELDS進行配置和過濾，保證查詢數(shù)據(jù)的安全。二、關(guān)于容災(zāi)架構(gòu)規(guī)劃階段需要定性的問題【關(guān)鍵問題】容災(zāi)方案中的異常處理方面的設(shè)計？災(zāi)備與雙活如何選擇？企業(yè)容災(zāi)的規(guī)劃者如何找到適合自己的規(guī)劃？異地容災(zāi)規(guī)劃的時候，在業(yè)務(wù)分級上有什么注意的地方？【關(guān)鍵總結(jié)】1、為什么要搞容災(zāi)建設(shè)？這個問題非常重要，因為企業(yè)搞容災(zāi)建設(shè)的背景可能會因為行業(yè)背景、監(jiān)管標準、業(yè)務(wù)特點等情況不同而完全不一樣。例如多數(shù)金融行業(yè)搞容災(zāi)建設(shè)是因為監(jiān)管的行業(yè)要求，有的企業(yè)則是因為曾經(jīng)面臨過數(shù)據(jù)中心災(zāi)難教訓或者看到別人的教訓而主動搞容災(zāi)建設(shè)。不同的建設(shè)目的會導致追求的目標不盡相同。2、建設(shè)成什么樣的容災(zāi)架構(gòu)體系，用什么樣的標準去衡量？企業(yè)因搞容災(zāi)的初衷不同，那么對RTO和RPO的目標也會有嚴格和寬松之分，所謂嚴格的RTO&RPO指標就是政府或行業(yè)監(jiān)管的最低標準，不同規(guī)模性質(zhì)的企業(yè)有不同的最低標準要求。所謂寬松就是企業(yè)為了平衡投入成本和容災(zāi)架構(gòu)帶來的收益，可以將RTO&RPO鎖定在一定范圍內(nèi)。3、建設(shè)的容災(zāi)架構(gòu)應(yīng)該是什么級別（國家標準&國際標準）？銀監(jiān)局和中國人民銀行對商業(yè)銀行業(yè)最嚴格的要求標準是5級容災(zāi)標準，RPO<=15分鐘，RTO<=30分鐘。而根據(jù)國際標準share78，六級容災(zāi)標準是RPO=0，RTO=分鐘級；七級容災(zāi)標準是RPO=0，RTO近似為0。企業(yè)可以根據(jù)這些標準界定自己應(yīng)該實現(xiàn)的最低標準，比如說5級或者6級標準。4、選擇什么樣的容災(zāi)架構(gòu)技術(shù)體系，如何評估各種容災(zāi)中技術(shù)方案？以同城雙中心容災(zāi)為例，企業(yè)需要評估網(wǎng)絡(luò)層、應(yīng)用層、數(shù)據(jù)庫層、存儲層等縱向各個功能層的具體技術(shù)方案，同時需要考慮到縱向和橫向的融合和擴展。評估的時候，我們需要選擇好評估的維度以及關(guān)鍵風險的把控，后續(xù)章節(jié)我們會詳細介紹評估這些關(guān)鍵技術(shù)方案的方法和思路。每一種容災(zāi)技術(shù)方案，從實現(xiàn)的技術(shù)復(fù)雜度、需要投入的成本、需要承擔的風險、技術(shù)的先進性、技術(shù)的成熟度等幾個方面來綜合評估，尋求適合企業(yè)的最佳技術(shù)組合方案。①技術(shù)復(fù)雜度：對于容災(zāi)技術(shù)方案的技術(shù)復(fù)雜度，總的原則是同目標可達的情況下，架構(gòu)越簡單越好。大的方面分析來看，不僅僅需要考慮建設(shè)的復(fù)雜度還需要考慮運維的復(fù)雜度；不僅僅要考慮方案本身的復(fù)雜度還需要考慮方案需要依賴的環(huán)境的復(fù)雜度；不僅僅需要考慮橫向復(fù)雜度還要考慮縱向的復(fù)雜度。②投入成本：對于企業(yè)來講，投入成本是非?？傄囊豁椧蛩亍？偟脑瓌t是同目標可達的情況下，成本越少越好。大的方面分析來看，投入成本不僅包括容災(zāi)方案本身的設(shè)備成本還需要考慮軟件成本；不僅需要考慮建設(shè)成本還需要考慮運維成本；不僅需要考慮資源成本還需要考慮人力成本；不僅需要考慮一次性成本還需要考慮持續(xù)投入成本。③承擔風險：所謂風險，最主要的就是極端情況下的RTO和RPO風險?？偟脑瓌t是可以在寬松目標范圍內(nèi)適度降低，但是不能因此而承擔災(zāi)難性的風險概率。大的方面分析來看，承擔風險主要包括極端情況下的數(shù)據(jù)丟失風險、區(qū)域性業(yè)務(wù)中斷擴展的風險。④技術(shù)先進性：所謂技術(shù)先行性，一方面要看技術(shù)本身與主流發(fā)展的方向是否匹配，另外一方面要看技術(shù)本身在性能、高可用、擴展性、兼容性等方面的能力?？偟脑瓌t是在目標可達的情況下，選用先進的技術(shù)體系。⑤技術(shù)成熟性：所謂技術(shù)成熟性，不僅需要從技術(shù)體系本身的發(fā)展歷史來看它的健壯性和穩(wěn)定性，還需要從技術(shù)方案應(yīng)用的案例情況以及市場的反饋情況來看技術(shù)的成熟性。三、關(guān)于容災(zāi)建設(shè)過程當中必須要考慮的一些關(guān)鍵技術(shù)問題【關(guān)鍵問題】雙活架構(gòu)中是否設(shè)定仲裁優(yōu)先級，合理規(guī)避“腦裂”風險？是否更應(yīng)該考慮多種容災(zāi)方案的疊加？企業(yè)如果想建設(shè)三個數(shù)據(jù)中心，都跑應(yīng)用業(yè)務(wù)，互備模式如何實現(xiàn)？同城雙活方案中關(guān)聯(lián)業(yè)務(wù)的保障與支撐主要依靠什么來實現(xiàn)？雙活數(shù)據(jù)中心如何保證數(shù)據(jù)同步實時與一致性？如何解決錯誤傳遞問題？【關(guān)鍵總結(jié)】1、如何選擇數(shù)據(jù)復(fù)制技術(shù)路線？數(shù)據(jù)復(fù)制最終完成的結(jié)果是在兩個磁盤介質(zhì)上完成同一個IO數(shù)據(jù)，但是將來自客戶端的單個IO請求鏡像為兩個IO的源頭可以有三種不同的選擇：操作系統(tǒng)層面、數(shù)據(jù)庫層面以及存儲層面。1).操作系統(tǒng)層面的復(fù)制技術(shù)：以LVM、VXVM等邏輯卷鏡像為基礎(chǔ)，IO寫入的時候可以在組成同一個邏輯卷的物理鏡像上同時寫入數(shù)據(jù)，底層數(shù)據(jù)寫入是需要通過SAN協(xié)議完成的。2).數(shù)據(jù)庫層面的復(fù)制技術(shù)：一種是類似操作系統(tǒng)邏輯卷的模式，比如ORACLE的ASM，它也是一種邏輯卷管理模式，同樣也可以通過多個物理鏡像來組成一個邏輯卷，從而通過鏡像復(fù)制的方式完成數(shù)據(jù)副本的同時寫入。本質(zhì)上它與操作系統(tǒng)層面的邏輯卷鏡像技術(shù)沒有區(qū)別，只是它離數(shù)據(jù)庫更近，數(shù)據(jù)庫更懂它。另外一種是通過數(shù)據(jù)庫事務(wù)日志復(fù)制的方式將數(shù)據(jù)修改行為在另外一個備庫上重新演繹一遍，最終可以達到使數(shù)據(jù)結(jié)果一致的目的。3).存儲層面的復(fù)制技術(shù)：一種是通過存儲網(wǎng)關(guān)將兩個物理存儲卷組成一個邏輯存儲卷，通過鏡像復(fù)制的方式完成數(shù)據(jù)在存儲落盤時的雙寫。本質(zhì)上它與操作系統(tǒng)層面的邏輯卷鏡像技術(shù)也沒有區(qū)別，只是它選擇在存儲層面實現(xiàn)。另外一種是通過存儲介質(zhì)之間以塊拷貝的方式來實現(xiàn)數(shù)據(jù)副本的冗余。究其原理，其實無論從哪個層面來實現(xiàn)，這些技術(shù)從原理上可以劃分為三種類型：1.

IO雙寫（操作系統(tǒng)邏輯卷鏡像、ASM、存儲網(wǎng)關(guān)鏡像.etc）2.事務(wù)回放（以O(shè)racleADG為代表.etc）3.數(shù)據(jù)單元拷貝（以存儲CA、DP技術(shù)為代表的存儲復(fù)制技術(shù)）基于鏡像技術(shù)實現(xiàn)的數(shù)據(jù)復(fù)制技術(shù)（無論是基于系統(tǒng)層還是存儲層）以及基于存儲本身BlockCopy的技術(shù)實現(xiàn)的數(shù)據(jù)復(fù)制技術(shù)，都存在邏輯Block錯誤傳導的問題。也就是說一旦發(fā)生存儲Block錯誤，那么它一定會傳導到備數(shù)據(jù)中心。本質(zhì)上是因為這種傳輸機制跟IO應(yīng)用沒關(guān)系，識別不到IO應(yīng)用層的數(shù)據(jù)，所以有些數(shù)據(jù)雖然在應(yīng)用層看已經(jīng)是壞掉的數(shù)據(jù)了，但是存儲層完全識別不到，所以正常復(fù)制。但是，這種問題在整個數(shù)據(jù)中心容災(zāi)可防范的災(zāi)難列表里面占據(jù)的比例非常小?；跀?shù)據(jù)庫重做日志實現(xiàn)的數(shù)據(jù)復(fù)制技術(shù)，不存在這種問題。因為它是應(yīng)用層的復(fù)制，它復(fù)制的是數(shù)據(jù)庫層做過的事務(wù)，是過程復(fù)制，不是結(jié)果復(fù)制。只要過程沒錯，那么結(jié)果就不會有問題。即使主中心的存儲Block發(fā)生了錯誤，但是在災(zāi)備中心經(jīng)過日志回放實現(xiàn)的數(shù)據(jù)結(jié)果不會受到任何影響。所以從這一點上，這種技術(shù)相對安全。如果是人為失誤造成的數(shù)據(jù)損壞，那就是備份技術(shù)解決的問題了，不是容災(zāi)方案能解決的了（比如DBA的誤操作刪除了一些數(shù)據(jù)，無論哪種數(shù)據(jù)復(fù)制技術(shù)都會傳導到災(zāi)備中心，容災(zāi)方案沒有義務(wù)也沒有能力來區(qū)分DBA的操作到底是不是失誤）。2、為什么會集群可能產(chǎn)生腦裂？集群如果發(fā)生了腦裂問題，那么會造成什么樣的結(jié)果？這個問題需要回到集群的仲裁機制上來，一般來講集群的仲裁算法是以每一個節(jié)點可以獲得仲裁資源的多少來判斷誰是集群的主導。集群的仲裁資源無非是來自網(wǎng)絡(luò)層面的心跳信息和共享存儲的磁盤心跳資源，在普通的節(jié)點層故障場合下，發(fā)生故障的節(jié)點可以獲得的仲裁資源就會少于其他節(jié)點，那么就不會發(fā)生腦裂問題。但是在一種特殊的場合（雙數(shù)據(jù)中心之間的網(wǎng)絡(luò)發(fā)生了故障），兩個節(jié)點可以獲得的仲裁資源是一樣的，網(wǎng)絡(luò)彼此不能互通，存儲彼此不能看到對方，這樣的的場景下仲裁就會失效，腦裂發(fā)生。

那么為什么說對于容災(zāi)架構(gòu)來講，腦裂是災(zāi)難性的事件呢？如果從一個統(tǒng)一集群的調(diào)度變成兩個相互獨立的集群調(diào)度，意味著雙方的寫操作相互也是獨立的，但是他們的存儲空間是共享的，AA模式下通過鎖機制控制并發(fā)，HA模式下通過存儲卷的Owner控制寫的權(quán)限。但是獨立之后意味著兩個集群可以隨時寫入同樣的存儲地址，必然會造成臟寫臟讀等一系列數(shù)據(jù)不一致事件。這對業(yè)務(wù)來講是災(zāi)難性的。3、如何解決腦裂問題？1.

優(yōu)先級解決方案OracleRAC優(yōu)先級解決方案以兩個節(jié)點的OracleRAC為例來講，當私網(wǎng)發(fā)生故障而從網(wǎng)絡(luò)上導致集群分割為幾個孤島子集的時候，網(wǎng)絡(luò)心跳同票數(shù)情況下，仲裁算法有兩個非常重要的規(guī)則：①保障隔離后的集群子集中節(jié)點數(shù)目最多的子集存活。②當隔離后的集群子集獲得的仲裁票數(shù)相等時，保障實例號小者存活。從規(guī)則內(nèi)容上可以看出，第一條規(guī)則基本沒有什么意義，雙方的資源是對等的；但是第二條規(guī)則直接決定了集群的最終狀態(tài)，那就是實例號小的節(jié)點成為新的集群，這就避免了腦裂的存在。資源失衡配置解決方案所謂資源失衡配置解決方案，就是要在容災(zāi)設(shè)計之初就保障主數(shù)據(jù)中心的資源配置要多于災(zāi)備中心，使得兩個數(shù)據(jù)中心節(jié)點可以獲取到的仲裁資源處于不平衡狀態(tài)。容災(zāi)設(shè)計的時候可以將主備數(shù)據(jù)中心的節(jié)點分布數(shù)量或者仲裁文件分布數(shù)量按照2:1的非平衡策略設(shè)置。那么按照集群仲裁的一般規(guī)則：發(fā)生集群分裂故障的時候，可以獲得更多仲裁資源的子集將成為新的集群。當發(fā)生數(shù)據(jù)中心之間的網(wǎng)絡(luò)故障的時候：第一種架構(gòu)，主數(shù)據(jù)中心內(nèi)部兩個節(jié)點可以獲取到更多的網(wǎng)絡(luò)心跳，自然會接管集群。第二種架構(gòu)，主數(shù)據(jù)中心的節(jié)點可以獲取到更多的磁盤心跳，同樣會接管集群。這也符合我們設(shè)計之初衷。但是，這種方法只適合于AA模式的多節(jié)點集群，不適合HA模式的架構(gòu)。自定義優(yōu)先級解決方案自定義優(yōu)先級的解決方案，其實本質(zhì)上與OracleRAC的仲裁算法第二條“當隔離后的集群子集獲得的仲裁票數(shù)相等時，保障實例號小者存活。”是一樣的。只不過對于OracleRAC，當通過第一條規(guī)則無法判斷的時候（節(jié)點獲取的仲裁資源矩陣是平衡的），它默認采用了實例號定義其優(yōu)先級。而其他的一些容災(zāi)方案，這個優(yōu)先級定義的靈活性留給了客戶。例如VPLEX產(chǎn)品，尤其是在雙活架構(gòu)的設(shè)計當中，有可能因為地域、設(shè)備新舊、運營管理等方面的差異，往往災(zāi)備中心的運行能力會稍差，那么發(fā)生數(shù)據(jù)中心之間隔離的這種故障時，大家往往希望保留主數(shù)據(jù)中心的運行。那么這個時候客戶就可以根據(jù)主數(shù)據(jù)中心的節(jié)點標識來固定其仲裁優(yōu)先級。2.

仲裁解決方案網(wǎng)絡(luò)仲裁網(wǎng)絡(luò)資源是集群仲裁當中非常重要的一種心跳資源，因此通過第三方網(wǎng)絡(luò)資源的可達性心跳信息來判斷對稱集群分裂后的新秩序也是一種非常有效的方法。一般在以存儲網(wǎng)關(guān)實現(xiàn)數(shù)據(jù)雙寫的容災(zāi)架構(gòu)當中比較常見，比如VPLEX、SVC、MCC等。第三方仲裁點需要滿足的條件：①與主備兩個數(shù)據(jù)中心L3可達，并且網(wǎng)絡(luò)質(zhì)量穩(wěn)定。②仲裁點需要安裝具備網(wǎng)絡(luò)探測功能的虛擬服務(wù)器或物理服務(wù)器，具備運行條件。仲裁點服務(wù)器上的軟件會與組成集群的存儲器網(wǎng)關(guān)兩個節(jié)點分別發(fā)送PING/ACK來確認雙方的健康情況，集群會把兩個節(jié)點與第三方仲裁點的網(wǎng)絡(luò)仲裁心跳看做是最終的裁判。VplexWitness通過管理IP網(wǎng)絡(luò)連接至兩個集群節(jié)點，通過將其自身的觀察與集群定期報告的信息進行協(xié)調(diào)，讓集群可區(qū)分是集群內(nèi)故障還是集群間鏈路故障，并在這些情況下自動繼續(xù)相應(yīng)站點上的I/O服務(wù)。VplexWitness僅當分離規(guī)則沒有定義時才會生效。當然細心的讀者可能產(chǎn)生了一個新的問題：如果數(shù)據(jù)中心與第三仲裁站點的網(wǎng)絡(luò)發(fā)生故障，那會不會影響集群本身的運行？什么是仲裁？仲裁是只有發(fā)生集群隔離故障的時候才會起作用，如果沒有發(fā)生數(shù)據(jù)中心之間的隔離故障的時候，即使他們的一方或者雙方于第三方仲裁站點發(fā)生網(wǎng)絡(luò)暫時中斷的事件，也不會對既有集群造成任何健康影響。我們需要做的是保障第三方仲裁資源在發(fā)生故障的時候有效就可以了（監(jiān)控&及時修復(fù)）。存儲仲裁存儲一般是數(shù)據(jù)庫集群當中非常關(guān)鍵的仲裁資源，數(shù)據(jù)庫集群的節(jié)點負載比較重，不像存儲網(wǎng)關(guān)模式的集群，可以再設(shè)計與WitnessNode的通訊接口。所以在這類技術(shù)方案的容災(zāi)設(shè)計當中，通常會用第三方存儲陣列來作為集群的第三方仲裁點。例如OracleExtendedRAC、HA&Oracle、HA&DB2等。a.第三方站點放置一個存儲陣列、并且與兩個數(shù)據(jù)中心網(wǎng)絡(luò)穩(wěn)定可達。b.存儲陣列以NFS或者ISCSI方式提供共享存儲卷或文件服務(wù)給兩個中心的集群節(jié)點。c.集群配置的時候，將這個共享存儲卷或者文件作為集群的磁盤仲裁之一。當雙中心的集群發(fā)生隔離故障的時候，集群通過第三方的仲裁磁盤或者文件來判斷集群的新秩序。對稱隔離場景集群發(fā)生的故障場景有很多，有可能是網(wǎng)卡故障導致節(jié)點隔離，也有可能是鏈路問題導致節(jié)點隔離。鏈路問題本身又分很多種，有一種場景即使存在第三仲裁的場景下，依然有可能是對稱平衡的狀態(tài)。當兩個中心之間的鏈路中斷，但是其他各條線路都完好無損的情況下，及時存在第三方仲裁，那么集群分裂后的仲裁資源分布依然是平衡對稱的，這又該如何解決呢？我們認為有兩種解決方式：1.優(yōu)先級定義解決方案，也