基于云計算的異地雙活容災技術在民航生產保障中的應用

吳波 李鵬

摘 要：隨著科技發展和技術的進步，信息化建設成為民航機場現代化建設持續發展的必然趨勢，而確保信息系統穩定可靠的運行和數據安全則成為民航機場信息化建設的重中之重。當前各大民航機場普遍通過建設災備中心來保證關鍵應用的業務連續性。這種災備部署方式災備中心平時處在不工作狀態，只有當災難發生時，生產數據中心癱瘓，災備中心才啟動。切換時間長、突發事件中存在必然的數據損失、缺少演練等等實際情況普遍存在。

關鍵詞：業務連續性;數據中心;容災;異地雙活;ACTIVE-ACTIVE

0引言

習近平總書記在網絡安全和信息化工作座談會上的講話中提到：“網絡安全和信息化是相輔相成的。安全是發展的前提，發展是安全的保障，安全和發展要同步推進?！盵1]新時代中國特色社會主義建設對民航工作提出了更高的要求，習總書記在十九大中更是提出了“安全隱患零容忍” 的重要精神指示。

隨著民航業的發展，民航現代化程度越來越高、生產規模越來越大、分工越來越細、生產協作越來越廣泛。民航空安全生產已涉及航空公司、空管、機場、油料等眾多互相協作的系統， 巳遍布全國各地，甚至世界上不同國家和地區。而民航機場作為這樣復雜生產組合下的重要交通樞紐，其指揮和保障工作涉及飛機、車輛、人員和特種設備等多個方面。為了使機場各崗位能夠有條不紊地開展工作，各機場都建立了一套適合自身情況的IIS，并與企業戰略緊密整合在一起。高度集成的智能化信息系統的確為生產保障提升了效率，但也不可避免的帶來了高風險的安全隱患。突發事件造成的非計劃宕機的事件不可避免，一旦出現這種情況，輕則影響航班保障流程，重則造成航班信息丟失其損失無法估量。如何容災已成為各大機場不可回避的嚴峻問題。

1行業現狀

中國民航信息化建設起步較晚，各大民航機場普遍采用傳統的災備方案來保證關鍵應用的業務連續性。這種災備部署方式為一個生產中心、一個災備中心，災備中心平時處在不工作狀態，只有當災難發生時，生產數據中心癱瘓，災備中心才啟動。這種傳統模式通常是采用存儲數據級復制，或是采用數據庫Golden Gate或Data Gurd特性復制，但是數據庫本身License比較昂貴，且無法自動化主備切換，更不能滿足業務對連續性RPO=0、RTO≈0要求，即使采用存儲復制技術也很難解決RTO≈0的要求;從運維角度來說，切換時間長、突發事件中存在必然的數據損失、災備中心健康狀態不可見、缺少演練等等實際情況普遍存在。

所以也有部分走在信息化建設前沿的機場，已經看到傳統災備方案確實不能滿足現有安全生產的需求，由此提出并落地實施了基于云計算的信息化系統建設。

云計算在海外經過多年的發展，其虛擬化、分布式計算、分布式存儲、編程模型、云平臺等核心技術已日臻成熟。相對于傳統部署模式而言，其靈活配置、資源利用率高和節省成本的優勢將愈發顯著，也確實極大程度降低了突發事件造成的非計劃宕機事件RPO、RTO。

但是，任何一件事物都有利弊之分，云計算也不例外。盡管眾云計算廠商把云計算炒得大紅大紫，每個廠商推出的公有云、私有云、混合云、云套件也是層出不窮，在介紹產品時更是提出99.99%的可靠性、高可用性、安全性，故障率可控在0.01%以下等。不可否認，云計算很好，但還有很長的路要走，很多地方都得完善和優化：

2018年6月27日，阿里云因上線一項更新操作，導致提供的云計算服務除部分管控功能外，MQ、NAS、OSS等產品的部分功能出現訪問異常。此次事故從16點21分至17點30分，時長約一小時，被譽為中國互聯網半壁江山，驚魂整整一小時！

2019年3月3日，阿里云再次發生類似故障，導致華北2地域可用區ECS服務器（云服務器）等實例出現IO HANG，所有依托在上面的信息服務停止響應。

類似情況不僅是國內產品，國際大品牌同樣時有發生：

2017年 1月26日，IBM：客戶用于訪問其Bluemix云基礎架構的一個管理網站服務中斷了數小時，用戶無法管理自身的應用程序，添加或刪除支持工作負載的云資源。

2017年 1月31日，GitLab：GibLab.com遭遇了18小時的服務中斷，最終無法完全修復。一些客戶的生產數據最終丟失，影響范圍約5000個項目。

2017年 2月28日， 亞馬遜：亞馬遜坐擁約三分之一的全球云市場，此次事件造成諸如Slack，Quora和Trello等眾多全球性企業服務平臺宕機4個小時，根據外媒估算，此次宕機造成了最高數千萬美元的損失。

2017年 6月28日， 蘋果iCloud：蘋果iCloud Backup服務停止服務至少36個小時。

2018年 7月17日，谷歌：谷歌云的宕機，持續近1小時。

2018年 7月16日，亞馬遜：當天是第四屆亞馬遜會員日，當日的開幕儀式后幾分鐘，大規模的故障使得當日的銷售陷入了癱瘓。而亞馬遜的云平臺確實世界上最領先，用戶數量最多的平臺。

由此可見，云雖好，但“雞蛋不能放在一個籃子里”，哪怕是0.01%的故障幾率，造成的結果可能也是無法承受之重。

因此，當一個數據中心發生故障時，另外一個數據中心可實時接管所有業務的雙活容災解決方案成為當前討論和建設的熱門技術方案。雙活容災解決方案能夠盤活現有IT資源，充分發揮資源利用優勢，實現應用級雙活無感知切換，達到業務服務的7x24小時服務質量保證，降低災難性事件發生后業務宕機的風險。

2異地容災真實案例

前文的宕機實例中有兩次都是阿里云，但卻從未對阿里自身的業務造成任何影響，正是因為阿里沒有把雞蛋放在同一個籃子里：

2015年5月28日下午17時許，支付寶被反映故障;18時許，支付寶通過官方微博給出回應，解釋是因為電信運營商光纖被挖斷，導致小規模用戶登錄異常。19時許，支付寶服務恢復正常;次日凌晨，電信運營商恢復光線鏈路。此次事件中，絕大部分用戶實現了無感知切換。而“小部分”不能無感知切換的用戶，是應為在事故發生的瞬間正在產生交易記錄，支付寶處于金融安全的考慮，進行了完整的數據校驗，保證所有客戶的客戶信息、賬戶信息、資金信息、交易信息都是正確的，一切確認完成后，才重新“開門迎客”。這個過程耗時了一個多小時，不過相比較支付寶數億客戶所對應的校對數據量，這個時間完全是可以接受的。此次事件是中國金融史上第一次在完全突發情形下，成功完成快速切換的真實案例，整個切換過程中，沒有一條客戶數據丟失，充分體現了金融級的數據高可用要求。

此次事件雖然時間稍微長了一點，但技術是不斷進步的。

2017年杭州云棲大會ATEC主論壇現場上，支付寶工程師針對此次的事件進行了一次特別技術演練：他們基于支付寶的真實機房，現場模擬挖斷支付寶近一半服務器的光纜。斷網后的約20秒內，賬戶頁面顯示系統異常，26秒后，觀眾全部都能順利轉賬。

3異地雙活容災技術

支付寶的案例，是一次異地多活的“三地五中心”金融級別的典型案例，就民航機場而言，我們大可不必大張旗鼓，異地多活過于奢侈，我們只需要做到“同場不同樓的異地雙活”即可。

3.1業界主流雙活技術

目前的業界主要針對存儲，為解決數據庫"高可用性"（High availability， HA）問題而衍生出兩種主流技術：active-active（真雙活）和active-passive（偽雙活）。

active-active：用兩個完全一樣的server，然后用一個load balancer（負載均衡）進行請求的調度。load balancer的算法可以很高深也可以很簡單。簡單的例如"round-robin"， 就是輪換. 第一個請求發給服務器1， 第二個發給服務器2， 第三個發給服務器1， 以此類推。重要的是這兩個服務器應該是完全一致的， 這樣才能確保用戶端，仿佛一直在訪問同一個服務器。Huawei HyperMetro，HDS GAD，EMC VMAX SRDF/Metro Active-Active 均采用這種技術，雙活的兩個副本可同時被主機并發讀寫訪問，負載均衡，有完備仲裁機制。

active-passive：active-passive也是兩個服務器節點， 但是絕大多數時間是active的那個（或者說primary）進行服務， 當primary服務器出問題， 就使用另一個passive服務器作為備用。跟active-active一樣， active-passive也應該確保兩個服務器完全一致。NetApp，HP PeerPersistence，FUJITSU Storage Cluster，DELL LiveVolume，IBM HyperSwap 等廠商采用這種技術，Server間有各自不同的仲裁機制。

3.2理想的異地雙活容災方案

一套理想的異地雙活容災方案，不應當僅僅局限在存儲層面的雙活。在保障民航生產系統7X24小時不間斷安全穩定這個前提下，我們所提出的雙活，應該是更加廣義的，涵蓋應用、網絡、存儲和數據的端到端的數據中心雙活。即應用、網絡、存儲、數據都應該是雙活狀態。如下圖三是一個理想中的廣義數據中心雙活方案：

3.2.1網絡和存儲層面

方案中數據中心A和數據中心B之間采用網絡互聯，數據中心內采用傳統兩層或三層組網方式互聯;接入層鏈接業務服務器、核心/匯聚層通過大二層互通技術鏈接到對端數據中心;存儲、交換機和服務器通過專門的SAN網絡互聯;通過冗余組網的方式，用FC協議實現兩個數據中心的交換機互聯，各節點間互為備份，均衡負載，任何節點故障后，其承接的業務自動切換到正常節點，保證系統的可靠性、業務的連續性。在數據雙活的情況下，實現數據零丟失，業務零中斷。[2]

3.2.2. 數據層面

方案中以大二層網絡為基礎，通過VMware、Hyper-V、Oracle RAC、SQL MSCS/MSFC、IBM PureScale、華為VIS等業界主流技術，均可以實現數據中心的數據同步，其中Oracle RAC、PureScale和華為VIS均可實現active-active，既可以單獨使用，也可以混合搭配以實現更為完備的功能，可根據各機場實際情況采用不同的技術架構。圖四以華為VIS技術為例，介紹數據層同步的基本原理：

VIS鏡像的寫I/O流程如下：

①寫請求到鏡像卷;

②鏡像卷將請求復制為兩份下發到兩中心的鏡像數據盤;

③鏡像數據盤返回寫操作完成;

④鏡像卷返回寫I/O操作完成。

VIS鏡像的讀I/O流程如下：

①讀請求到鏡像卷;

②鏡像卷根據讀策略下發請求到其中一個中心的鏡像數據盤;

③鏡像數據盤返回讀數據;

④鏡像卷返回讀數據。

該方案利用VIS鏡像卷技術，保證兩個數據中心存儲陣列之間數據的實時同步。由于VIS鏡像卷技術對主機層透明，當任一存儲陣列故障時，鏡像陣列無縫接管業務，數據零丟失，業務零中斷。當單陣列或單數據中心故障時，鏡像卷選取正常數據中心的陣列響應主機I/O，并采用差異位圖盤記錄故障期間數據的變化情況，待故障修復后進行增量同步，從而減少數據同步量，縮短數據同步時間，降低數據同步對帶寬的需求。[3]

3.2.3應用層面

方案中在兩個數據中心均部署了相同的應用服務器，用戶對雙活數據中心資源訪問的訪問，通過LAN經過服務器本地緩存、第三方仲裁（Thrid-place quorum site）定位到資源。為了保證負載均衡，數據中心會部署GSLB和SLB來保證每次訪問都能負載均衡到相應的數據中心、相應的服務器上。GSLB和SLB之間實時同步兩個數據中心IP資源情況，通過HA或本地優先方案的策略實現資源訪問IP分配。在具體實現上，目前成熟技術有OracleRAC、IBMGPFS、Symantec VCS、PowerHA HyperSwap和華為VIS等。由于技術并不復雜，有實力的機場也可以自己開發適合自己的技術方案。

3.2.4 第三方仲裁

方案中使用到了第三方仲裁，該仲裁其實是對存儲集群和服務器應用集群之間的仲裁。因為成本低、技術簡單，目前支持仲裁服務器的廠商比較多。但該設備也不是必須，很多廠商也提供優先存活站點策略來實現業務訪問，不過如果運氣不好，優先存活站點發生故障，后果很嚴重。所以在預算許可的情況下，采用第三方站點仲裁更保險。

3.3 異地雙活的基本要求

雙活方案對網絡健康情況有較高的要求。網絡時延、帶寬、誤碼率都會影響雙活方案。由于兩個數據中心數據實時復制，所以鏈路網絡帶寬必須高于高峰IO訪問時的帶寬;網絡時延會影響整個應用系統業務響應;誤碼率會影響網絡的利用率，誤碼率越高就意味著數據需要被重傳，從而形象整個網絡。

同時，雙活方案對硬件也有一定要求。因為兩個數據中心在級別上是對等的，所以兩個數據中心的存儲、服務器等系統都應該是對等的，否則任何一方如果成為性能瓶頸都將影響另外數據中心。

4雙活容災解決方案的不足

世上沒有完美無缺的技術。雖然雙活容災解決方案優點很明顯，對于集中式管理的數據中心更大限度的保證了業務生產的在線性及有效的防御了災難性事件恢復業務生產的能力。但是雙活數據中心的容災方案還是存在一定的不足之處，理想與現實總存在一定的距離：

4.1腦裂現象

雙活數據中心方案實現了站點級的冗余的容災解決方案，但是受限于當前的技術等因素，在建設過程中解決了企業當前面臨的業務連續性問題，同時也產生了新的問題，就是雙活解決方案普遍存在的腦裂現象，在意外事件發生時，若監測技術不到位、系統平臺不健康、兩數據中網絡波動性中斷等因素的發生，使得兩個數據中心一體化的業務系統會分裂成兩個獨立的數據中心。使用戶很難取舍那一個是唯一的生產數據，那一個是將要廢掉的非生產數據。

4.2非“零丟失”，不具備軟錯誤的保障

雙活容災解決方案的優勢強調在健康的運行平臺下，大型災難事件發生是的“零”數據丟失，但是若雙活平臺本身不健康或者遭遇邏輯故障時，并不能保障數據零丟失。這種故障發生在漸變式災難發生的情況下，比如業務系統升級過程中導致系統錯誤，這種時候還需借助備份系統的數據恢復手段或方法。因此，雙活容災方案大多數情況下不具備解決軟錯誤的保障，而恰恰這種事件發生的概率遠遠超過站點級的災難及硬件故障事件。

4.3 運營維護并不簡單

雙活容災解決方案災難切換方面變的較為簡單，但在實際的維護方面并不簡單，企業自身人員的維護能力必須加強，才具備能力維護跨站點的雙活系統。也就是需企業用戶自身人維護人員必須從維護設備的能力轉變為具備維護雙活系統架構的能力，才能維穩系統的正常運行，讓雙活系統實現該有的效果。[4]

5結束語

隨著科技發展和技術的進步，信息化建設成為民航機場現代化建設持續發展的必然趨勢，而確保信息系統穩定可靠的運行和數據安全則成為民航機場信息化建設的重中之重。雙活容災技術有其不足之處，但隨著技術的發展、管理的提高、運維人員能力的增強，其現有的不足之處必將被無限的縮小，在民航系統現代化建設中展現出重要的作用。

6 縮寫詞

參考文獻：

[1]習近平. 在網絡安全和信息化工作座談會上的講話[J].中國應急管理， 2016（4）：12-16.

[2]Hardy. 云數據中心：雙活為業務連續性保駕護航. [EB/OL].http：//hx.zol.com.cn/591/5910524.html，2016-06-29/2018-12-16

[3] 華為，華為存儲雙活解決方案技術白皮書V3.1

[4]中國存儲網. 雙活容災系統建設 有利有弊客觀看[EB/OL].http：//www.chinastor.com/a/rongzai/0312232442016.html，2016-03-12/2018-12-16