吳 波 李 鵬

（401120 重慶機(jī)場(chǎng)信息通信網(wǎng)絡(luò)有限公司 重慶）

0 引言

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

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

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

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

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

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

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

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

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

類似情況不僅是國內(nèi)產(chǎn)品，國際大品牌同樣時(shí)有發(fā)生：

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

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

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

2017年 6月28日, 蘋果iCloud：蘋果iCloud Backup服務(wù)停止服務(wù)至少36個(gè)小時(shí)。

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

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

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

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

2 異地容災(zāi)真實(shí)案例

前文的宕機(jī)實(shí)例中有兩次都是阿里云，但卻從未對(duì)阿里自身的業(yè)務(wù)造成任何影響，正是因?yàn)榘⒗餂]有把雞蛋放在同一個(gè)籃子里：

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

此次事件雖然時(shí)間稍微長(zhǎng)了一點(diǎn)，但技術(shù)是不斷進(jìn)步的。

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

3 異地雙活容災(zāi)技術(shù)

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

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

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

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

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

3.2 理想的異地雙活容災(zāi)方案

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

3.2.1網(wǎng)絡(luò)和存儲(chǔ)層面

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

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

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

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

①寫請(qǐng)求到鏡像卷；

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

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

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

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

①讀請(qǐng)求到鏡像卷；

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

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

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

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

3.2.3應(yīng)用層面

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

3.2.4 第三方仲裁

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

3.3 異地雙活的基本要求

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

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

4 雙活容災(zāi)解決方案的不足

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

4.1 腦裂現(xiàn)象

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

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

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

4.3 運(yùn)營(yíng)維護(hù)并不簡(jiǎn)單

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

5 結(jié)束語

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

6 縮寫詞

縮略語 英文解釋 中文解釋IIS Information integration System 信息集成化系統(tǒng)RPO Recovery Point Objective 數(shù)據(jù)恢復(fù)點(diǎn)目標(biāo)，主要指的是業(yè)務(wù)系統(tǒng)所能容忍的數(shù)據(jù)丟失量RTO Recovery Time Objective恢復(fù)時(shí)間目標(biāo)，主要指的是所能容忍的業(yè)務(wù)停止服務(wù)的最長(zhǎng)時(shí)間，也就是從災(zāi)難發(fā)生到業(yè)務(wù)系統(tǒng)恢復(fù)服務(wù)功能所需要的最短時(shí)間周期VIS Virtual Intelligent Storage 虛擬化智能存儲(chǔ)SAN Storage Area Network 存儲(chǔ)區(qū)域網(wǎng)絡(luò)FC Fibre Channel 光纖通道GSLB Global Server Load Balance 全局負(fù)載均衡SLB Server Load Balance 服務(wù)器負(fù)載均衡HA High availability 高可用性