運營商容災備份研究及其關鍵技術應用

□ 文 孫淳曄 梁 楊

運營商業務支撐系統主要面向客戶服務和業務管理，隨著近年來的不斷建設、發展、完善，已從企業內部IT系統轉型為開放的移動互聯網節點，成為客戶運營的核心和連接數字化服務的紐帶，新形勢下的競爭環境、業務、客戶、產品和網絡的變化都對現有的系統架構帶來巨大挑戰，實現系統架構的穩定可靠性，保證業務連續性，以便更好地支撐市場拓展及客戶服務的發揮顯得極為必要。

為實現業務的連續性保障，制度上應建立風險防控手段、應急管理辦法措施進行規避，技術上通過建立容災、備份等應急保障實現。本文通過調研部分省份的容災技術選擇，詳細分析了技術原理及特點，針對某省公司現網單中心的現狀提出了雙中心建設方案。

應急保障措施按照由低到高程度主要分為雙機、集群、備份、應急、容災幾個層次。

1、建設目的

運營商進行容災備份建設主要出于以下目的：

系統安全運行需求

單生產環境做到的應急保障程度有限，一旦發生自然災害，大面積且長時間停電等不可抗拒因素會造成系統癱瘓，影響公司整體收入，造成嚴重社會影響。

運營、運維連續性需求

單生產環境進行業務升級時為避免可能造成的日常營業影響，通常會采用較短的上線窗口，造成上線范圍有限，此外部分升級還需中斷業務，影響業務連續性。對于系統的升級無法快速響應，難以滿足市場快速支撐響應。

此模式下的升級多采用夜間上線升級，以人工操作為主，效率不高且易出錯，不具備可視化運維能力，對支撐人員造成嚴重壓力。

系統架構演進需求

云化時代，工程投資精細化，投入產出數字化，保持系統的穩定、安全、可擴展性顯得至關重要，容災建設模式架構合理，符合演進趨勢，正常狀態負荷分擔，資源復用，降低系統壓力，提高設備利用率；發生系統重大故障或災難時實現應用接管，起到容災作用。

2、應急保障分類

應急保障措施按照由低到高程度主要分為雙機、集群、備份、應急、容災幾個層次。雙機、集群涉及范圍最小，主要為單個業務或應用模塊的保障，其中雙機又分為雙機HA，負載均衡模式，集群主要指集群主機共同完成某項任務并能自動化實現宕機的業務接管。

備份保障直接面向基礎數據，主要是在單個數據中心內實現關鍵數據的備份，承載介質多為帶庫，虛擬帶庫以及各類分布式存儲等，備份為粒度最小的應急保障，也是最易實現、投資最少的方式，常用的備份工具有Networker、NBU等商業備份軟件等。

應急面向對象為系統級或平臺級，目的在于故障發生時通過主備系統快速切換，實現業務的連續性保障、達到客戶無感知的目的，應急的范圍一般局限于單個數據中心內的核心系統，覆蓋底層數據庫至應用層，需單獨的設備物理隔離部署，應充分考慮與生產設備在機房、供電等配套資源的區分，以實現保障程度的最大化。

容災為最高級的應急保障機制，也是投資最高的建設模式。容災建設在物理格局上可分為多地多中心模式、同城多中心模式，運營模式上有冷備、熱備、雙活、多活等方式，功能架構上劃分全量和降級容災模式建設，進行容災建設最為關鍵的是解決了風、火、雷、電等自然災害帶來的風險，在災難發生時實現業務的快速切換，并盡量縮短RPO和RTO，以保證業務連續性、減少經濟損失、保障客戶利益為最終目的。本文僅就保障級別最高的容災技術進行研究分析，并以雙中心雙活模式進行說明。

3、建設模式

進行雙中心容災建設首先考慮第二中心的配套問題，具備數據中心機房的各類資源保障條件，具備良好的擴展性，連續的空調制冷環境，獨立冗余的電力保障以及中心間可靠的傳輸條件等。除物理配套因素外，系統的技術選型、業務邏輯也至關重要，目前雙中心建設功能上存在兩種分類：

垂直劃分

垂直劃分是以業務功能為單位進行劃分，根據業務功能的特性，按業務耦合程度在生產中心和容災中心分別運行不同的應用，同時向另一中心同步數據，如圖1、圖2所示。

在實現數據級容災的基礎上，任一中心出現災難時，另一個中心接管全部業務，相應的雙中心數據復制以應用維度進行復制。

水平劃分

水平劃分是以地域為單位進行劃分，根據用戶歸屬，分別在生產中心和容災中心運行完整的系統，正常情況下某一中心只負責處理歸屬用戶的業務（跨地區業務除外），同時向另一中心同步數據，如圖3、圖4所示。

當任一中心出現災難時，另一個中心接管全部業務，相應的雙中心數據復制以地市維度進行復制。

4、關鍵技術研究

應急保障是一個系統工程，需要雙中心接入層、應用層、數據層、存儲層分別設置訪問策略及切換機制，同時保證數據的安全備份機制。

接入層、應用層主要依賴IP地址、DNS域名等配置解決，而涉及應用層以下則需要專門的同步復制工具，目前主流方向有三種：基于存儲復制、基于數據庫日志復制、基于數據庫的復制，如圖5所示。

圖1 垂直劃分模式

圖3 水平劃分模式

圖2 垂直劃分同步

圖4 水平劃分同步

圖5 雙中心總體架構

存儲復制：通過存儲控制或者虛擬卷控制實現數據在存儲設備之間的復制；所有的數據變化在兩個站點進行鏡像。

數據庫日志復制：由數據庫系統的輔助程序或第三方工具，逆向解析數據庫交易日志并施行于遠端數據庫完成數據復制。

應急保障是一個系統工程，需要雙中心接入層、應用層、數據層、存儲層分別設置訪問策略及切換機制，同時保證數據的安全備份機制。

數據庫復制：由數據庫系統軟件完成數據復制，復制的粒度是數據庫內數據操縱動作，復制涉及的范圍為單個數據庫。

“’互動性’存在于口語交際的各個環節和話語理解的各個層面”，是指參與語言交流的雙方在口語交際中形成聽和說的交互作用。

為實現某省公司的容災建設，充分考慮了兄弟省份的建設經驗，調研了部分省份的在用技術，結果如表1所示：

針對上述省份的技術選型，對三類流派技術從以下維度進行了分析，如表2所示：

各類同步復制產品特點差距較大，對現網環境依賴性也不同，而大多數省份已考慮了應急保障的建設，但近年來新的數據中心啟用則需要各個省公司情根據現網實際情況及業務讀寫要求選擇適合的同步產品，以下針對各產品的進行了總結建議，如表3所示。

表1 部分省份同步復制技術選擇

表2 同步復制技術對比

表3 技術使用場景分析

圖6 整體架構圖

5、兩地雙中心建設方案

針對某運營商目前單數據中心的實際情況以及迫切建設第二中心的需求，結合在網在用數據庫產品及存儲產品，采用基于數據庫的同步復制技術進行雙中心雙活容災建設，對各層的配置分析如下，如圖6所示。

自頂而下劃分渠道層、接入層、應用中心層及數據層，分別設置不同的接入方式和切換機制，雙中心間提供網絡層、存儲網絡層的雙鏈路、高帶寬保障。

主機按等量部署在雙中心，單中心內根據不同外部訪問入口劃分多個集群，在WEB層設置DNS，根據請求源地址與兩個中心IP的對應關系，將不同地市的訪問請求轉發到不同的中心進而訪問對應中心的WEB集群。

當WEB集群組1內的一臺主機發生故障時，由集群機制保障WEB集群組1內的其他主機承擔其負載的訪問請求；當WEB集群組1內的主機大面積發生故障時，通過策略調整DNS解析配置，使所有請求切換到第二中心內，確保業務不間斷。

應用層

物理上兩個機房分別部署主機，應用邏輯上跨機房集群部署形成統一的應用支撐中心。

WEB層通過解析用戶屬性與歸屬地市映射關系，歸屬路由請求通過客戶端訪問控制機制，執行客戶分組的訪問策略，將WEB請求指向對應應用中心集群。

原則上客戶端訪問應用中心集群組采取就近策略訪問本局應用中心，當應用集群組內的服務器發生故障時，由集群機制保障應用集群組內的其他服務器能夠承擔其負載的請求量，當本中心獲取不到較近的應用服務器地址，自動將請求指向對端應用中心集群組，確保業務連續性。

數據層

現網一中心某核心系統采用的是Oracle數據庫，由于第二中心所購設備按照第一中心同構等量考慮，按照全量1:1考慮全量災備建設，優先考慮數據庫性能影響及數據壞塊的處理機制，選用Oracle ADG技術進行雙中心同步技術，雙中心數據庫主備庫跨機房交叉部署，一中心部署A主庫、B備庫，二中心部署A備庫、B主庫。

每個業務應用存在兩個或多個數據庫連接。根據訪問主備庫要求，設定數據庫DNS可解析的IP地址；用于優先訪問備庫的連接將備庫IP地址設為首選，用于優先訪問主庫的連接將主庫IP地址設為首選。注冊服務與主備優先連接設定關聯關系，按照對應策略從對應的連接池中獲取數據庫連接。數據主庫出現故障，可通過人工干預或根據策略進行自動切換。

單中心數據庫通過RAC實現高可用，雙中心通過第三方數據同步軟件保障主庫與備庫的數據一致性。雙中心的數據同時可讀寫，數據相互備份，并且在其中一個中心出現異常的時候，對端中心可以馬上接管。

雙活模式下的應用升級：基于分布式中心架構，只要不涉及數據庫變更，應用變更或升級可以通過在線方式升級，保證業務不中斷。利用雙中心的在線切換機制，即便涉及數據庫變更的升級，也可以做到在線升級，保障業務不中斷。

6、結束語

本文針對業界主流的容災建設模式做出來詳細分析，歸納總結了技術對比分析，并針對某公司提出了兩地雙中心的具體實現方案。當今時代運營商既面臨機遇，又面臨挑戰，只要把握自身優勢地位，充分保障系統穩定，保持架構先進，不斷優化業務能力、提高客戶感知，才能在互聯網的前進大潮中立于不敗之地?！?/p>