企業容災規劃建設三大階段關鍵問題總結及最佳實踐

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

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

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

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

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

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

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