吳波 李鵬

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

關鍵詞：業(yè)務連續(xù)性;數(shù)據(jù)中心;容災;異地雙活;ACTIVE-ACTIVE

0引言

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

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

1行業(yè)現(xiàn)狀

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2異地容災真實案例

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

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

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

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

3異地雙活容災技術

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

3.1業(yè)界主流雙活技術

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

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

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

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

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

3.2.1網(wǎng)絡和存儲層面

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

3.2.2. 數(shù)據(jù)層面

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

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

①寫請求到鏡像卷;

②鏡像卷將請求復制為兩份下發(fā)到兩中心的鏡像數(shù)據(jù)盤;

③鏡像數(shù)據(jù)盤返回寫操作完成;

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

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

①讀請求到鏡像卷;

②鏡像卷根據(jù)讀策略下發(fā)請求到其中一個中心的鏡像數(shù)據(jù)盤;

③鏡像數(shù)據(jù)盤返回讀數(shù)據(jù);

④鏡像卷返回讀數(shù)據(jù)。

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

3.2.3應用層面

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

3.2.4 第三方仲裁

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

3.3 異地雙活的基本要求

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

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

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

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

4.1腦裂現(xiàn)象

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

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

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

4.3 運營維護并不簡單

雙活容災解決方案災難切換方面變的較為簡單，但在實際的維護方面并不簡單，企業(yè)自身人員的維護能力必須加強，才具備能力維護跨站點的雙活系統(tǒng)。也就是需企業(yè)用戶自身人維護人員必須從維護設備的能力轉變?yōu)榫邆渚S護雙活系統(tǒng)架構的能力，才能維穩(wěn)系統(tǒng)的正常運行，讓雙活系統(tǒng)實現(xiàn)該有的效果。[4]

5結束語

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

6 縮寫詞

參考文獻：

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

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

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

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