基于OpenStack的高可用城軌云平臺:設計、實現與可用性分析

朱 力，李子恒，唐 濤，王 悉

(北京交通大學 軌道交通信號控制與安全國家重點實驗室，北京 100044)

在我國城市軌道交通迅猛發展的態勢下,城市軌道交通的運營及設備管理已成為行業部門關注的重點。傳統城市軌道交通系統架構存在IT資源浪費、設備負載率高、不同系統數據共享困難等問題。如何在城軌規模擴大的同時,對城軌運營和應用設備進行統一管理維護,提高各系統的資源利用率及系統間數據交互的便捷性,并在保證系統設備可靠性的前提下,提高城軌交通的運輸效率,是亟待解決的問題。

近年來,云計算技術,即一種IT基礎設施的交付和使用模式,因其可以按照用戶需求提供相應的基礎設施資源,同時用戶可“按需付費”使用對應資源而廣泛地在各行各業得以應用。然而,由于城軌系統對于可靠性的要求較高[1],在城軌云計算產業建設過程中,云計算平臺具有規模較大、結構復雜,云環境呈現高度動態的特點,單個節點的失效成為常態。應用云計算時,在云虛擬機環境中構建高可靠的應用服務同樣是一個具有挑戰性的關鍵研究問題。本文首先通過使用IaaS層面云平臺技術——OpenStack構建高可靠城市軌道私有云平臺。在此基礎上利用故障樹分析(fault tree analysis, FTA)工具及馬爾科夫過程(Markov process)建模方法對承載軌道交通云應用的虛擬機進行可靠性分析及高可用研究,實現了單個虛擬機故障或節點故障時,云應用仍能對外提供服務的目標。最后,將城軌CBTC系統應用運行在高可用虛擬機上,并對虛擬機的可用性進行測試與評價,通過測試結果分析衡量虛擬機應用的可用性與可靠性。為軌道交通行業解綁傳統架構軟硬件束縛提供了技術與理論支撐[2]。

1 城軌云計算應用背景

當前我國大部分城市的城軌系統設備均采用“煙囪式”傳統垂直架構體系,見圖1。在這種架構下,不同系統具有各自獨立的存儲設備、管理工具及數據庫,不同系統間無法共享資源,無法交互與訪問,存在數據共享壁壘,容易造成信息孤島與資源孤島。

圖1 傳統軌道交通系統垂直架構體系

具體來說,傳統架構現存問題可以總結為以下三點:

1)一條線路上車站級服務器占到服務器總數的90%以上,但大多數服務器CPU利用率低至5%,并且由于容錯需求,服務器關鍵設備需要使用冗余備份的方式運行應用程序,這就造成了更多IT資源的浪費。

2)個別設備存在負載率較高的問題,均值超過70%,設備長期工作于高負載工況下,使用壽命大幅降低。

3)傳統基于硬件架構的城軌系統不具備動態調整能力,隨著線路規模不斷擴大以及客流量的快速增長,使得城軌核心業務(列控系統、CCTV系統等)呈現爆發式增長,只能通過增加服務器數量來滿足線路需求,大幅增加了企業開銷。

傳統城軌系統架構無法滿足未來智慧城軌的發展目標,而云計算技術最顯著的優勢是部署靈活,規模易于擴展,資源池化并按需分配。利用云計算的優勢,可實現城市軌道交通物理硬件資源的最大化利用,避免出現某些設備資源過度占用,其他設備資源余量較多的情況,大幅減少了生產環境中的開支。此外,云計算還幫助城軌交通系統實現集中部署、集中監控、集中運維的需求,降低系統設備的運營維護成本。

就軌道交通行業云計算的應用研究來說,2012年,廣州地鐵開始搭建私有云的環境,是行業內首個上線投產云計算數據中心的城軌企業,首次利用基礎架構和云強大運算能力打造彈性軟件應用,為行業如何引入云計算建設和應用方面提供了有意義的嘗試。2018年,武漢和呼和浩特被協會批準成為云計算的重點試點城市,南京、重慶、無錫、溫州等一批城市也積極推進云平臺建設和云上應用深化。

從2019年開始,云計算在實際城軌線路中的建設發展如雨后春筍一般不斷呈現。目前,已有北京、上海、廣州、深圳、武漢等這樣運營線網規模較龐大的城市在部署和推動城軌云的建設,也有呼和浩特、太原等新興地鐵建設城市著手城軌云的建設。2019年9月,呼和浩特搭建了全球首個多線多業務系統的城軌云項目,從頂層設計入手,構建生產中心云平臺、災備中心云平臺、站段云平臺,為多系統提供IaaS服務,滿足呼和浩特軌道交通1、2號線的建設要求。

城軌系統應用云計算,從傳統架構轉向云環境的過程中,需要考慮眾多因素,如云計算提供資源的形式、云計算的交付模式、云環境的可靠性、云應用的可用性等。軌道交通行業的云業務主要面向企業內部,因此私有云是城軌企業主要的云平臺建設模式。同時城軌行業正處于云服務建設的起步階段,IaaS層交付基礎設施和自動化運維能力是企業目前的剛需。

另一方面,依據《城市軌道交通云計算應用指南》的建議,城軌私有云平臺應由中心云、站段云節點構成,計算資源池應配置為高可用(high availability, HA)形式以承載線網生產業務運行。實現高可用配置需從兩個方面著手,即云節點高可用、云上虛擬機高可用。云計算服務器出現宕機時,應觸發集群節點的切換,主機上的服務自動進行故障切換。當某個計算節點中的虛擬機運行狀態異常也應觸發虛擬機高可用切換,在其他正常運行的業務節點上快速恢復業務,從而保證城軌業務平穩運行。

因此,對于部署運行在IaaS層的城軌應用業務,實現云節點集群的高可用及業務所在虛擬機的高可用是保證故障后城軌業務不中斷的必要條件,同時實現虛擬機高可用,在任何可能導致虛擬機異常崩潰的情況下,保證虛擬機承載的城軌應用負載具有能夠被繼續訪問的能力是城軌業務可靠上云的重要保證。

2 主流云平臺技術及云容錯方法

云計算管理平臺為構建云的基礎架構服務,能讓用戶更好地管理云計算資源。一個功能完整、性能較優的云管平臺應該具有以下特征:平臺動態可擴展、資源按需分配、組件高可用、服務高性能、負載均衡等。

2.1 主流云平臺技術

云計算這一概念在20世紀70年代已有了雛形,隨后計算機技術的迅猛發展以及互聯網行業的興起,都在向這個概念不斷靠攏,從而推動了云計算基礎設施的發展。直到2006年3月亞馬遜公司推出彈性計算云服務EC2,按用戶使用的資源量進行收費,這一里程碑式的服務開啟了云計算商業化的元年。同樣,云計算在國內也掀起風波,2009年1月,阿里建立首個電商云計算中心。2011年阿里云官網上線,并發布阿里云的第一個ECS云服務器。直到今天,國內已涌現出諸如華為云、Z-Stack等眾多優秀云計算廠商。

除了商用云平臺,諸如CloudStack[3]、OpenStack、Kubernetes等開源的云計算平臺管理項目也不斷發展并成熟,使云平臺的管理更加方便快捷。城軌系統應用開源云技術,能夠讓企業具有平臺二次開發能力,并能夠解綁商用云計算廠家,具有較大優勢。以下將介紹兩種常用的開源云平臺管理技術。

2.1.1 Kubernetes

Kubernetes(K8s)是Google開發的一個容器編排引擎,是PaaS云平臺代表,它在Docker的基礎上,為容器化應用提供部署運行、資源調度、服務發現等一系列功能,提高了容器集群管理的便捷性。

K8s是一個完備的分布式系統支撐平臺,具有完備的集群管理能力。開發人員可以在物理機或者虛擬機的K8s集群上運行容器化應用,滿足容器化應用的環境依賴和運維需求,例如多個容器子進程并行協同工作、健康檢查應用運行狀態、應用實例的擴容縮容、共享存儲卷、負載均衡、K8s版本滾動更新、日志查詢、認證授權等功能[4]。同時K8s提供完善的管理工具,涵蓋了包括開發、部署測試、運維監控在內的各個環節。這些都是K8s強大的優勢所在。

2.1.2 OpenStack

OpenStack項目最早由NASA、Rackspace等在2010年合作推出,其宗旨在于幫助組織或者個人運行一個虛擬化計算或存儲服務的云,為用戶提供可擴展的、靈活的云計算服務。OpenStack云計算技術支持部署IaaS層的私有云平臺,并具有開源的特點,企業或個人可以按照自身需求搭建功能豐富的云計算平臺[5]。OpenStack的特點是模塊功能由一系列組件通過松耦合集成,可以根據自身需求自行拓展相應功能的組件,有較大的彈性空間,并且OpenStack組件基于Rest-full API實現,易于二次開發。同時OpenStack也支持高可用形式部署,滿足企業需求。目前,OpenStack已在全球IaaS領域占據主導地位。

OpenStack整體邏輯架構見圖2,其中不同組件負責向集群和用戶提供對應的功能。圖中七個組件是OpenStack的核心組件,分別提供計算、對象存儲、塊存儲、認證、網絡、鏡像存儲和用戶界面功能。除此之外,OpenStack還提供諸如監控、計費等功能[6]。每個組件本質上都是多個服務的集合,用戶可以按照自身需求與資源總量將上述服務選擇部署在一臺主機或多臺主機上,靈活擴展集群規模。

圖2 OpenStack邏輯架構

2.2 云容錯方法

容錯是指在某個系統中出現錯誤或失效的情況下,能夠繼續提供服務的能力,是高可用技術的核心。為應對云平臺潛在的失效風險,目前主要有兩種標準的容錯策略可用,分別是主動容錯策略和被動容錯策略。主動容錯策略通過監控、風險感知等主動預防措施來避免失效,使用主動容錯機制可以保證在應用服務失效前就識別到潛在風險。被動容錯策略基于處理措施,即通過故障恢復手段,盡可能減少云系統中已經發生的失效所造成的嚴重后果。

2.2.1 主動容錯策略

主動容錯策略會根據系統的狀態,判斷當前可能會發生的失效情況,從而采取適當的手段預防失效的發生。主動容錯技術包括預先遷移技術和軟件恢復技術。預先遷移技術遷移需要持續監控云平臺及虛擬機運行的狀態,并不斷分析虛擬機運行狀態是否異常,在出現運行狀態異常,但還未發生失效的情況下,集群將暫停虛擬機進程,記錄其狀態,將其從當前所在的物理節點轉移到另一個節點并在該節點中恢復進程的操作,這其中包含一個檢測與反饋的過程。

對于軟件恢復技術,集群中虛擬機及與虛擬機運行相關的軟件老化不可避免地會導致系統軟件故障,因此可以主動應用軟件再生技術避免潛在失效風險[7]。實際上,它是一種為系統安排定期重啟的技術。每次重新啟動后,系統將以干凈可靠的狀態運行。

2.2.2 被動容錯策略

被動容錯也叫作反應式容錯,是指當系統故障形成錯誤后,采用合適的策略防止系統失效的發生。常用的被動容錯技術包括檢查點/重啟機制和冗余機制。檢查點技術允許云平臺定期保存整個集群的運行狀態為一個檢查點,當集群中故障發生后,將最近的檢查點恢復到整個集群中以實現容錯。發生故障后,虛擬機將從檢查點重新啟動,而不是重建整個虛機。它是一種高效的容錯技術,適用于托管在云中的高計算密集型虛擬機應用程序。

冗余機制是最流行的容錯技術之一,可以根據當前場景的需求使用,將特定的服務或組件進行冗余配置。冗余技術一般分為主備模式以及主從模式。在主備模式下,正常情況下所有實例都在運行,由主機提供服務,數據同步至所有備機。當主機宕機后,備機啟用,成為主機并接管服務。主從模式下同一時刻下多個實例提供服務,主從之間進行數據同步,保證主從之間信息一致,具備相同的系統狀態。在虛機容錯技術中,復制可以通過保持數據和服務的多個副本來實現。由于云環境中部署的應用服務通常包含大量組件,并且云中虛擬資源的獲取較為容易,冗余機制通常是最多用來構建云節點及虛擬機的高可用策略。

3 高可用城軌私有云平臺設計與實現

高可用城軌私有云分為兩個部分:云平臺高可用和虛擬機高可用。云平臺高可用即保證為平臺提供云服務的OpenStack組件具有高可用性,通常將集群組件運行在多個節點上,當某個節點的特定組件發生故障時,其他節點的該組件能夠接替其繼續工作,對外提供服務。云中虛擬機可以視為云組件所提供服務的具體實例,因此虛擬機的高可用建立在云平臺高可用的基礎上。同時,對于云上虛擬機來說,虛擬機內部故障和虛擬機所在物理節點的軟硬件故障都有可能導致虛擬機失效,從而導致虛擬機中的應用無法正常工作[8],上述因素也是構建高可用虛擬機過程中需考慮的。本章介紹了實現完整的高可用城軌私有云所需的云平臺和云上虛擬機高可用的整體設計架構及部署過程。

3.1 OpenStack平臺高可用實現

OpenStack平臺中虛擬機的功能由一系列組件提供,為實現IaaS平臺的虛擬機高可用,首先需要實現平臺集群高可用。原生OpenStack云平臺的搭建過程中,整個平臺主要由兩個部分構成:控制節點和計算節點?？刂乒濣c通常被用來管理整個云平臺,是OpenStack的控制中心。原生平臺中一般設有一個控制節點,為保證高可用,則考慮控制節點的冗余,即部署兩個以上的控制節點。計算節點負責為虛擬機提供內存、存儲等資源,是虛擬機整個生命周期管理過程中必不可少的部分。

OpenStack高可用集群的整體框架見圖3。

圖3 高可用私有云平臺架構

在集群中,控制節點隨時監控集群全部資源的運行情況并進行資源啟停、恢復和遷移等操作,因而集群中需要運行一個集群資源管理器,如Pacemaker。同時,高可用集群系統中的服務器通常被分為負載均衡服務器和真實服務器,負載均衡服務器用于分發用戶請求給真實服務器,真實服務器接收到請求后會處理用戶請求。高可用集群中每個服務均運行在多個節點上,以確保某個節點的服務失效時,用戶的請求與命令仍能夠到達某個正常運行的節點上[9]。為解決該問題,使用HAProxy作為高可用負載均衡代理服務器。以下分別對高可用平臺搭建過程中關鍵工具Pacemaker及HAProxy進行介紹。

3.1.1 Pacemaker

傳統的Linux高可用部署和目前OpenStack高可用集群部署中,最成熟的集群資源管理器方案是Pacemaker和Corosync的組合。在集群的高可用搭建中,全部控制節點上運行Pacemaker和Corosync進程,通過設置一個可漂移的虛擬IP(virtual IP, VIP)進行節點心跳通信和資源管理控制。任何運行在控制節點集群中的服務都可以設置為Active/Active模式或Active/Passive模式。

Pacemaker的架構由集群底層基礎模塊、集群無關組件和集群資源管理組件三部分組成。底層的基礎架構模塊向集群提供可靠的消息通信、集群成員關系等功能。集群無關組件主要包括資源本身及啟動、關閉以及監控資源狀態的腳本。集群資源管理組件包括集群資源管理器和資源代理控制系統,同時分布式鎖管理器(distributed lock manager, DLM)利用Corosync所提供的集群消息和集群成員節點處理能力來實現系統集群,并對故障的服務或節點進行隔離操作。Pacemaker整體架構見圖4(a)。

圖4 Pacemaker與HAProxy邏輯架構

3.1.2 HAProxy

HAProxy開源軟件能夠為OpenStack云平臺集群提供高可用與負載均衡支持,在TCP和HTTP的基礎上實現應用代理,工作在七層以上,通過負載均衡算法,HAProxy能夠接受大規模的訪問請求并將其轉發到后端服務器池中進行處理,分析數據包中的應用層協議并按照規則進行負載,對大規模的并發連接具有高可用性。HAProxy負載均衡架構見圖4(b)。

3.2 OpenStack虛擬機高可用實現

OpenStack集群中,計算節點為虛擬機提供資源,對于虛機中的城軌業務來說,不僅需要考慮虛機自身的可靠性,還需考慮計算節點是否可靠。針對IaaS層云計算的高可用,目前的研究主要集中在如何實現控制節點的高可用上,對于計算節點,尤其是虛擬機的高可用研究較少。虛擬機高可用需考慮如何提高虛擬機在其運行過程中可用性。因此,實現虛擬機高可用需要在監控到虛擬機的運行狀態和虛擬機所在主機的運行狀態的前提下,考慮如何在虛擬機或主機故障后遷移并在新節點上恢復故障節點的虛擬機,最后再重新啟動相關服務。本文通過在OpenStack集群的計算節點中將Pacemaker_remote和Masakari結合,構建云平臺中的高可用虛擬機。

3.2.1 Pacemaker_remote

對于不同的OpenStack虛擬機HA方案而言,都離不開三個環節,即監控、隔離和恢復。在虛擬機HA中,監控需要實現兩個任務,即虛擬機所在節點主機的故障監控和觸發對于主機故障監控的相應操作(隔離和恢復等)。云集群中一般使用Pacemaker_remote實現節點監控功能。

Pacemaker_remote允許將計算節點作為控制節點Packmaker集群的一部分,實現節點監控功能,同時使其獨立于控制層面的Corosync集群。計算節點組成的Pacemaker遠程節點負責運行OpenStack計算服務并接受控制層面的調度控制,其上運行的服務資源接受Pacemaker的統一管理和調度。

隔離是服務故障監控后的首要操作,其目的在于將故障節點完全孤立隔開,排除在云平臺集群之外。云集群在其他節點重新啟動虛擬機之前,必須確保故障節點完全失去提供服務的能力,以避免同一個虛擬機在不同計算節點同時運行,產生錯誤。在節點隔離方面,Pacemaker已內置該功能。

一旦集群監控到故障行為并且故障節點已被隔離,下一步措施是觸發虛擬機疏散并在其他計算節點上恢復虛擬機。OpenStack中提供專門API以將虛擬機由故障主機遷移至正常主機。同時為成功完成虛擬機的遷移,虛擬機用戶的系統鏡像必須位于共享存儲中。遷移與疏散操作完成后,虛擬機的系統鏡像和應用程序并沒有改變,僅是在其他節點上由相同的鏡像重新啟動虛擬機,而虛擬機其他全部屬性仍保持不變。

3.2.2 Masakari

由于上述虛擬機監控、隔離和恢復操作需要手動配置與操作,本研究中使用OpenStack中的Maskari虛擬機高可用方案?；贛asakari組件和Pacemaker_remote軟件的整體虛擬機高可用架構見圖5。該組件通過自動恢復失效的虛擬機為OpenStack提供實例高可用性服務?；诠蚕泶鎯ο?Masakari中Masakari-monitors和Pacemaker協同工作,檢測虛擬機或者整個計算節點的故障,并嘗試將其恢復。

圖5 虛擬機高可用架構

目前,Masakari可以從故障事件中恢復基于KVM的虛擬機,例如虛擬機進程關閉、配置進程關閉和Nova-compute服務所在主機故障以及其他一些節點故障情況。Masakari還提供監控服務API來管理和控制自動救援機制。當出現虛擬機自身異?；蛱摂M機進程異常的情況,Masakari將通過虛擬機的API關閉和重新啟動虛擬機。當運行在計算節點上的KVM虛擬化進程異常,Masakari將設置Nova-compute服務為“down”狀態,將節點隔離并啟用虛擬機疏散機制。Masakari進行虛擬機的疏散操作同樣需要共享存儲提供集群間虛擬機鏡像存儲功能,以便完成虛擬機相關文件的復制。

4 云環境中虛擬機可靠性分析

OpenStack私有云平臺中,虛擬機承載著云上城軌業務,業務本身的可用性與可靠性取決于虛擬機是否高可用與高可靠[10]。首先對影響平臺虛擬機可靠性的因素進行分析,將失效因素用故障樹模型描述;在建模得到失效率的基礎上,通過馬爾科夫狀態轉移分析法求得本文實現的高可用私有云平臺的可用率。

4.1 可靠性分析基礎

依據可靠性理論及云計算平臺的特性,云計算的可靠性指標可從平臺的可靠性及云上虛擬機的可靠性兩個角度定義。轉向云環境后,傳統可靠性分析方法同樣適用?？煽啃匝芯恐邢嚓P的技術指標與參數如下:

1)可靠度

可靠度是指系統從開始運行(t=0)到某時刻t這段時間里系統正常運行的概率。假設云系統符合隨機失效過程,則可以用指數分布將其可靠度R(t)描述為

R(t)=P(T>t)=e-λt

(1)

式中:t為規定的時間范圍;T為失效前時間;λ為系統失效率。

2)累積失效率和失效概率密度

累積失效概率是系統在規定條件下和時間t內,喪失規定功能的概率F(t),也稱為不可靠度,通常表示為

F(t)=P(T≤t)=1-e-λt

(2)

失效概率密度是累計失效概率對t的導數,是系統單位時間內失效的概率,記為f(t),通常表示為

(3)

3)失效率

在可靠性分析中,失效率定義為工作到某一時刻t尚未失效的系統或產品[11],在該時刻后,單位時間內發生失效的概率,一般記為λ,它是時間t的函數,通常表示為

(4)

4)MTTF和MTBF

平均失效時間(meantimetofailure,MTTF)tMTTF指系統無故障運行的平均時間,為系統開始正常運行到發生故障之間的平均時間[12]。平均失效間隔時間(meantimebetweenfailure,MTBF)tMTBF是指系統兩次故障發生時間之間的平均時間。平均修復時間(meantimetorepair,MTTR)tMTTR是指系統從發生故障到維修結束之間的平均時間[13]。MTTF與可靠度及失效率之間的關系為

(5)

5)修復率和MTTR

修復率是指修理時間已達t時刻但尚未修復的產品在t時刻后單位時間內完成修復的概率,記為μ(t)。若維修概率服從指數分布,則修復率為常數μ(t)=μ。MTTR與修復率的關系可表示為

(6)

6)可用性(可用率)

可用性Availability是指在一個周期內,系統無故障運行的平均時間,由MTTF、MTBF和MTTR指標表示為

(7)

4.2 虛擬機可靠性分析

4.2.1 故障樹建模分析

云環境中的失效,一般由單點故障導致。單點故障可以解釋為一個系統中一旦失效,就可能引發整個系統產生故障風險的部件。為實現虛擬機的高可靠性,需要分析虛擬機潛在的單點故障。虛擬機的可靠性不同于云節點的可靠性,云節點失效通常由節點軟件或硬件失效所導致。對于虛擬機而言,其硬件系統功能由計算節點所在物理服務器的軟件模擬所得[14]。因此,虛擬機可靠性的分析可以從虛擬機運行時系統內部的故障、虛擬機所在計算節點的軟硬件的故障考慮。同時,OpenStack計算節點所在服務與資源失效同樣會對虛擬機的可靠性造成影響。

綜上,將導致虛擬機失效的因素歸納為:虛擬機系統內部異常導致的故障、計算節點所提供資源不足導致的故障以及計算節點服務器軟硬件失效導致的故障。在此基礎上,通過故障樹分析(faulttreeanalysis,FTA)法分析虛擬機的可靠性[15]。故障樹分析法是一種將系統故障形成原因按樹枝狀逐級細化的圖形演繹方法,主要包括:建立故障樹、故障樹的定性分析和故障樹的定量分析。

定性分析的目的是尋找可能導致故障樹頂事件發生的某個原因或某些原因的組合,以便能夠發現該系統潛在的故障和安全隱患,進而指導人員進行系統維護與改進。故障樹定量分析法的目的主要是通過基本事件故障的概率,計算頂事件發生的概率以及想要獲取的可靠性指標。本文使用的定量分析法分析高可用云系統的可靠性。故障樹分析中為計算頂事件的發生概率定義了割集與最小割集的概念,即故障樹的一些底事件的集合,當這些事件同時發生時,頂事件必然會發生。若這個底事件的集合去掉任何一個底事件就不再成為割集,即為最小割集。每個最小割集是基本事件發生概率的乘積,不同最小割集之間是邏輯或的關系。因此有如下通過最小割集定義的頂事件概率。

設頂事件TOP=C1+C2+C3+…+Cn,C1到Cn為最小割集,則頂事件的發生概率Ptop為

[P(CiCjCk)+…+(-1)P(C1C2…Cn)]

(8)

式中:P(Ci)為每個最小割集發生的概率[16]。

由式(8)可知,當最小割集的數量比較龐大時,頂事件的計算較為復雜,因此近似計算頂事件發生概率為

(9)

本研究建立的虛擬機失效故障樹模型見圖6,三種中間失效因素分別表示為A、B和C。假設云環境中某個特定虛擬機發生這三種失效的概率為λA=λB=λC=λ*,圖中基本事件的發生概率(即失效率)從左至右依次為λ1到λ13,假設每個基本事件相互獨立,每個事件發生的概率相同,即為λ1=λ2=…=λ13=λ。此時中間事件E1、E3和E5的發生概率為E1=E3=E5=1-(1-λ)2,E2、E4和E6的發生概率為E2=E4=E6=λ2。則A、B和C的發生概率為A=B=C=λ3(2-λ)。由于該故障樹最小割集較多,頂事件的概率計算會發生組合爆炸的問題。故在實際計算過程中,采用近似的方式進行計算,虛擬機失效概率PVM的近似計算式為

圖6 高可用OpenStack云平臺虛擬機故障樹模型

式中:n為最小割集數量。

A、B和C中某個事件發生都有概率導致虛擬機失效,三個中間事件因素也會由E1到E6的子中間事件或基本事件發生導致。在找到可能導致虛擬機不可用的潛在失效風險后,需要使用本文介紹的云平臺容錯方法的方法防范這些風險的出現。

4.2.2 馬爾科夫過程建模分析

馬爾科夫過程可以描述為:對于一個系統,其按照一定概率從一個狀態轉移到另一個狀態,該狀態轉移概率依據轉移前的狀態得到,和系統最初態及之前的轉移過程無關。云環境中,高可用云平臺最開始處于完美無故障運行的狀態,隨著時間推移,系統中節點依次故障,可用節點越來越少,直至所有節點故障,最終云平臺失效無法繼續對外提供服務的整個周期符合馬爾科夫過程。

在基于馬爾科夫方法的云可靠性模型中,馬爾科夫方法的自身特性可能會導致系統狀態組合的維數災難,因此該方法適用于低復雜度或狀態數量較少的系統的可靠性分析。在OpenStack云平臺中,系統通常采用三控制節點高可用部署形式,所構建的云平臺節點馬爾科夫可用度模型見圖7,該模型滿足以下條件假設:

1)高可用云計算平臺由三個獨立的控制節點組成,各節點具有相同的失效率λ,以及故障修復率μ。

2)當云集群中某個節點故障時,設置在集群中的心跳腳本無法繼續接收到該節點發送的心跳信息,在進行了節點仲裁后,集群管理器認定該節點失效,將其從集群中隔離,待該故障節點完成修復后,可重新將其加入集群。

3)當且僅當全部節點均失效宕機時,云平臺無法繼續提供包括虛擬機在內的云服務,在三節點云平臺集群中,若至多有兩個節點故障,則云上虛擬機仍然能夠正常運行。

因此,云平臺節點馬爾科夫可用度模型包含四種狀態:

狀態0:所用節點正常運行,系統無故障工作,系統處于該狀態的概率記為S0;狀態1:一個節點故障,其余兩個節點正常運行,系統無故障工作,系統處于該狀態的概率記為S1;狀態2:兩個節點故障,剩余一個節點正常運行,系統無故障工作,系統處于該狀態的概率記為S2;狀態3:所有節點均故障不可用,云服務故障,系統處于該狀態的概率記為S3。根據模型可以得出:系統處于四個狀態的概率之和為1,即S0+S1+S2+S3=1。

根據圖7的轉移概率可以得到狀態轉移矩陣P為

狀態轉移矩陣每一行代表一個狀態,矩陣P表示一段時間內系統由一種狀態轉移到另一狀態的概率,是一步轉移概率,P*P表示兩步轉移概率,當到達極限狀態時Pn+1=Pn,此時狀態空間不再發生改變,即(S0S1S2S3)=(S0S1S2S3)P,由此可得極限狀態轉移方程為

云環境中,系統在0、1和2狀態時虛擬機均是可用的,若已知λ和μ的取值,則可以得到高可用系統的可用率為

Acloud=S0+S1+S2

(13)

5 高可用虛擬機性能測試及可用性分析

根據高可用架構完成集群整體的部署與配置,將CBTC系統運行在高可用虛擬機中,以實現真實完整的高可用軌道交通私有云。在此基礎上進行故障恢復能力測試,并通過虛擬機遷移和疏散過程中的指標與現象計算與評價私有云的可用性。

5.1 高可用虛擬機應用

高可用軌道交通私有云中,虛擬機僅用來完成軌道交通業務而并不對外開放。目前,城市軌道交通CBTC系統,主要由車載設備系統、地面設備系統與數據傳輸系統三部分組成。車載設備主要由列車自動駕駛系統(ATO)、列車自動防護系統(ATP)等組成;地面設備主要由列車自動監控系統(ATS)、計算機聯鎖(CI)、區域控制器(ZC)組成。兩種設備之間的雙向通信通過骨干數據通信系統(DCS)完成,多種系統相互配合使CBTC系統的功能得以發揮。目前多數在建的城軌云平臺中,大多數首先選擇將非安全相關的CBTC子系統(如ATS)移植上云。

5.2 虛擬機故障恢復測試及可用性指標分析

通常虛擬機的高可用性體現在兩個方面:①虛擬機熱遷移過程中,業務不中斷,用戶不會感覺到遷移的進行;②節點故障后虛擬機疏散所用時間較短,疏散工作完成后虛擬機的業務也能快速恢復運行。以下在虛擬機熱遷移和疏散兩個場景進行故障恢復能力測試,以反映其可用性性能指標。

首先根據實際生產環境中常用的虛擬機類型與規格,在測試場景中分別使用安裝了Windows10和Ubuntu18.04操作系統的虛擬機。兩種虛擬機的規格參數如表1所示,測試結果見圖8。

表1 兩種規格虛擬機配置參數

圖8 虛擬機熱遷移及疏散測試結果

測試場景一:高可用組件檢測到虛擬機自身或所在節點存在異常,可能導致失效風險。此時啟動虛擬機熱遷移,將虛擬機遷移到其他計算節點并將其重建。該項測試指標為從虛擬機遷移指令發出,到虛擬機狀態再次變為Active的時間,對規格相同的虛擬機進行50次熱遷移測試,測試結果見圖8(a)、圖8(c)。Windows10規格的虛擬機熱遷移的平均時間為76.44 s,Ubuntu18.04虛擬機熱遷移的平均時間為30.74 s。在遷移過程中虛擬機中的CBTC業務仍然正常運行,未出現宕機情況。

測試場景二:停止計算節點的云服務,模擬計算節點失效宕機。此時Masakari組件察覺到當前節點的失效故障,首先將該節點從集群中隔離出去,再發出虛擬機疏散命令,在其他正常節點重建虛擬機,此時虛擬機服務停止,待虛機重建完成后虛機中的服務再次正常運行。該項測試指標為從節點被隔離,到虛擬機重建后狀態再次變為Active的時間。對同一臺虛擬機進行50次熱遷移測試,結果見圖8(b)、圖8(d),單臺Windows10虛擬機的平均恢復時間為14.8 s,單臺Ubuntu18.04虛擬機的平均恢復時間為7.69 s。

高可用云平臺基于共享存儲實現了虛擬機的熱遷移功能,虛擬機熱遷移過程中,虛機提供的業務不中斷,云上應用仍然處于可用狀態,相較于原生OpenStack平臺中僅有的冷遷移功能(在計算節點之間遷移已關閉或已掛起的虛擬機,云上應用處于不可用狀態),云環境的可用率大幅提高。

通過對Windows10虛擬機故障恢復數據的分析,根據4.2節中可靠性分析結果得到:μ=0.068,同時假設在云計算平臺集群中,共有同一型號的1 000臺服務器,在規定的條件下工作1 000 h,其中有10臺出現故障,根據式(4)可得失效率定義為單位時間內服務器節點故障個數與試驗到t時刻點還能工作的服務器節點數的比值,即λ=1×10-5,因此取λ=1×10-5/h,代入4.2.2節中極限狀態轉移方程,得到:S0=99.996%,S1=4.438×10-4,S2=6.567×10-8,S3=3.240×10-12。最終,云環境的可用率為Acloud=S0+S1+S2=99.999%。

假設云環境出現故障的可能性為1年1次,在宕機時間不超過5min的高可用要求下,該方案使得軌道交通云上應用具有較高可用性。此外,在測試場景中分別對λ和μ取不同的值,驗證兩個指標對于整個云集群環境可靠性與可用性的影響程度。

云系統可靠性的測試結果見圖9(a),測試中云系統符合隨機失效過程,由公式R(t)=P(T>t)=e-λt得到系統的可靠度,并在1 000h的測試過程中發現當λ>1×10-5/h時,隨著時間推移所實現的OpenStack云集群將明顯發生失效。云系統可用性的測試結果見圖9(b),由圖可知,在修復率μ相同的情況下,失效率λ的大小同樣會對系統的可用性造成較大影響。

圖9 集群可靠度與時間及可用性與修復率的關系

6 結論

1)本文將城市軌道交通系統與基于IaaS層面的OpenStack云計算平臺相結合,實現了高可用OpenStack城軌私有云,包括私有云節點的高可用及平臺中虛擬機的高可用。在此基礎上,使用故障樹分析法對云環境中虛擬機的可靠性進行建模分析,使用馬爾科夫狀態轉移過程對云節點的失效轉移情況進行分析,兩種可靠性分析方法相結合,得到準確的可靠性與可用性分析結果。

2)本文提出兩種虛擬機容錯方法,最終在城軌云平臺中實現虛擬機高可用,對虛擬機的可用性進行測試,通過遷移和疏散時長的測試結果得到系統的修復率,進而分析云平臺的可靠性與可用性,說明實現云平臺高可用及虛擬機高可用對應對失效風險的必要性,最終分析得出云環境虛擬機具有較高可用率。

3)本研究能夠有效提升城軌云平臺中虛擬機的可用性,但未對虛機內部運行的應用狀態進行實時監測,未考慮虛擬機遷移對虛擬機中城軌系統應用運行質量的影響。同時,本研究也未使用諸如恢復時間目標(RTO)和恢復點目標(RPO)等高可用指標來衡量整體云環境的可用性的高低,在后續研究中需要完善。