業務支撐系統云化平臺資源調度方案

牟宏蕾，楊波，郝亞飛

（中國移動通信集團設計院有限公司黑龍江分公司，黑龍江 哈爾濱150080）

1 引言

4G時代，運營商在從語音經營向流量經營和數字化經營的轉型過程中，原有的客戶、渠道、產品、合作伙伴等商業要素的內涵、外延均已不同。新的商業模式和信息新技術的發展，均推動著業務支撐系統的云化演進，如圖1所示。

而云平臺中普遍存在著資源浪費和閑置的情況。以黑龍江O域為例，為保證系統的穩定性，云平臺根據忙時業務需求進行虛擬機的配置部署。各應用獨立占用預分配的計算、存儲和網絡資源，從而在業務非忙時產生大量資源浪費現象。另外，應用的上線、更新、擴容等資源調整依賴人為操作，浪費了大量的人力。

為了提高資源利用率，提升云資源的運維效率，本文針對業務支撐系統不同場景的需求對云資源的動態調度進行了探索。

2 資源動態調度方案

2.1 基于負載性能的調度方案

2.1.1 適用場景

網絡支撐客服系統（以下簡稱客服系統）Web應用有著顯著的負載變化特點，在客服業務流程中，隨著客戶的投訴量等變化，系統的負載變化明顯。在平時，客服量基本保持在一定水平；在忙時或者重大事件發生時，客服系統負荷顯著上升；在閑時（如晚間話務量減少時），會出現負載的大范圍下降。

圖1 業務支撐系統演進

根據此類業務的負載變化特點，有針對性地動態調節資源供給量，以達到資源隨著業務量變化聯動的效果，保持資源使用率維持在較高水準，提高資源平均利用率。

2.1.2 調度方案

通過引入業務服務等級管理的概念，進行資源的動態調整。通過虛擬機服務等級的定義和各種選項的組合，影響虛擬機在創建和運行時的狀態，從而區別對待不同的虛擬機。在業務申請時，可以根據自身業務的需求而選擇不同的服務等級。

虛擬機在創建時如果指定了服務等級，則在資源調度系統中調度時，會將服務等級定義參數作為調度的參考因素之一。基礎服務等級定義有如下種類。

·計算類資源：包括資源池、集群、資源標簽及內存預留。

·網絡類資源：包括設置網絡、網絡限速。

·存儲類資源：設置存儲標簽，對底層的存儲設施進行標簽化。在創建虛擬機時，通過不同存儲標簽的選擇，影響虛擬機所使用的存儲設施。根據存儲設施的配置，可以設置如SSD存儲、SCSI存儲、本地（local）存儲等。

·高可用性：虛擬機HA。在創建VM時，可以選擇啟動HA功能。從而運行的VM在出現故障時，可以自動被云平臺重建并遷移到其他hypervisor上面運行，避免關鍵性業務中斷。

調度系統在調度虛擬機資源時，將根據服務等級的定義自動選擇合適的hypervisor主機、網絡以及存儲類型。在分配hypervisor主機資源時，根據SLA的定義，預留主機CPU和內存資源，確保虛擬機運行性能。

在虛擬機運行過程中，引入了動態的資源分配預測和動態調整兩種技術。云平臺通過申請資源與實際使用率，獲取實際的資源占用情況；再通過比較hypervisor主機當前的資源占用情況和上一個周期的資源占用情況，經過多點計算，獲取hypervisor資源的使用趨勢，實時評估hypervisor承載的虛擬機業務在未來幾個周期內對資源的需求趨勢。通過預留參數控制預留資源，確保hypervisor本身的性能穩定可靠。在動態資源分配預測中，如果hypervisor資源占用趨勢趨于向上 （即業務占用資源加大），則預留參數值較大，實時預留資源同時加大，保證業務新資源的申請可以即刻獲得；如果資源占用趨勢趨于向下（即業務釋放資源），則預留參數值較小，實時預留資源減少。

2.1.3 調度流程

步驟1業務申請虛擬機：應用業務動態申請資源，實現業務直接與平臺的對接，簡化資源申請流程。

步驟2云管理平臺根據預測算法計算分配量：通過應用在平臺上設置的參數（業務等級、負載性能設定指標等），實現每個應用的資源個性化管理分配。

步驟3云管理平臺選擇適當的hypervisor運行業務虛擬機：根據應用設定的資源等級信息，對應開通相應的資源，確保重點應用優質資源保障。

步驟4云管理平臺在運行期監測業務虛擬機資源需求：平臺根據應用的發展與負載性能的變化及時調整資源分配策略。

步驟5云管理平臺動態調整虛擬機資源：平臺根據調度策略及時更新應用的資源供給。

圖2 應用架構

2.2 基于規劃擴容調度方案

2.2.1 適用場景

客服系統WAP話單處理模塊使用的是Hadoop架構，有著大數據應用的顯著特點，即數據量不斷擴大，需要資源的橫向擴展能力很強，并且可以達到無限擴展能力。此類大數據類型應用需要資源的特點是資源在擴展后隨時可加入，資源的使用情況是可預計的。基于這類應用的特點，給出基于規劃擴容的動態調度機制。

2.2.2 調度方案

引入自動伸縮組的概念，將一組相關業務的虛擬機作為整體來看待。同時，通過監控和分析它們的性能指標以及各業務自動伸縮組配置的各種策略，實時調整伸縮組內的資源數量，如圖2所示。

在使用橫向擴展方式對應用性能進行管理時，應用在運行過程中主要有兩種策略：擴容 （scale-out）和收縮（scale-in）。

在配置擴容策略時，用戶可以指定擴容的條件（規則引擎），配置擴容時進行VM創建或者進行物理機部署。同時，如果伸縮組配置了負載均衡器，還需要指定負載均衡器和配置負載均衡器的方式。

在配置收縮策略時，用戶需要指定收縮時選取被回收的節點的算法，如最新優先算法、最老優先算法或者隨機算法。在回收了節點后，如果伸縮組配置了負載均衡器，也需要指定更新負載均衡的方式。

針對不同的業務類型，Web類或者Hadoop分布式類需要在配置時選擇不同的策略和后續處理方式。伸縮策略是一種插件機制，在有新類型的業務需要添加時，可以進行擴充。

2.2.3 調度流程

步驟1納管Hadoop集群：通過應用監控采集Hadoop的運行數據。

步驟2以組為單位對Hadoop集群的整體運行情況進行分析和評估：如果Hadoop需要進行擴容，則利用物理機自動部署功能，從物理機資源池中分配合適的物理機資源，同時自動完成操作系統安裝和網絡配置等工作，并自動在新的物理機上完成Hadoop的各種業務服務的部署安裝，使得Hadoop集群的資源實現自動擴展的功能。

2.3 基于業務申請調度方案

2.3.1 適用場景

有些業務系統具有周期性的特點，而且隨著業務的增長，會不定時地增加資源需求。這種業務不適用于負載性能調度和規劃擴容調度方案，可通過API的調用和相應信息反饋的判定來解決這種業務系統的資源需求。

2.3.2 調度方案

業務系統根據自身相關任務的特點建立任務模型和長期有效的學習機制，通過對自身業務的不斷學習，收集每個任務資源消耗，從而不斷地更新任務模型，使得每個任務模型能持續優化，為每個任務建立一個比較準確的資源消耗值。

通過對自身任務策略的分析和每個任務的資源消耗，對未來一段時間內的資源消耗進行預估，將預估值與系統的當前資源量進行對比，當預估值大于系統當前資源量時，將差值換算成虛擬機的數量，調用云平臺的資源申請API，實現資源的自動申請。如果預估值小于系統當前資源量時，將差值換算成虛擬機的數量，調用云平臺的資源釋放API，實現資源的自動釋放。系統架構如圖3所示。

各模塊功能如下。

任務管理：主要包括任務策略管理、任務生成、任務分發等功能。該模塊根據任務策略生成相應的處理任務，并按照動態負載均衡策略把任務分發到虛擬機的任務執行（業務主機）節點；同時，對處理任務的執行狀態進行監控。

模型管理：將各類處理任務抽象出任務特征值，對其進行建模，將任務學習管理模塊監測、學習到的整個任務運行周期內資源消耗信息更新到任務模型管理的數據庫中，實現對任務模型的管理，并支持向外擴展。

任務學習：根據任務調度管理模塊中的任務策略以及任務基本信息，生成學習任務，下發至學習機，學習機針對學習任務定期上報采樣數據，采樣數據提供給任務模型管理模塊進行任務模型的更新修正。

資源監控：主要實現虛擬機資源負載的實時監控功能、任務實時采樣數據的收集。

資源決策：計算當前各虛擬機的運行負載、當前運行任務、剩余任務、預執行任務、任務模型等信息，通過綜合評估判決是否進行VM資源的申請或釋放。在實時監測各任務執行節點的基礎上，預測未來一段時間（時間可進行配置）的系統運行狀況，實現虛擬機提前申請以及延后釋放的功能。

圖3 系統架構

資源調度：根據資源決策模塊的分析結果，調用云平臺提供的API，實現虛擬機的申請和銷毀，同時，將虛擬機的信息發送給任務調度管理模塊，實現處理任務的動態調度，保證在申請和銷毀虛擬機上的任務動態調整。

2.3.3 調度流程

步驟1任務生成：任務調度管理模塊根據任務策略定時啟動處理任務，并按照動態負載均衡策略把任務分發到云平臺虛擬機的任務執行節點；對任務的執行狀態進行監控，并通知任務學習模塊進行任務的資源消耗監測。

步驟2任務建模：任務模型管理模塊在每個應用任務第一次運行時，根據任務的特征建立任務模型，包括：任務標識、任務屬性、采集時間點、資源CPU消耗、內存消耗、硬盤消耗等，并將相關信息通過數據表的形式保存到任務模型數據庫中。首次執行的任務建立的新模型只有任務的相關信息，無資源消耗信息，資源消耗信息在任務學習模塊中逐步采集更新。

步驟3任務學習：任務學習管理模塊收到任務調度管理模塊發送的任務啟動消息后，根據任務標識，對在任務執行節點上的任務每5 s（可配置調整）進行一次資源消耗監測，并記錄監測到的數據，直至任務完成。

步驟4任務模型修正：任務學習管理模塊記錄每次監測到的資源消耗數據，計算出每次任務執行的時長、平均及最大CPU消耗、平均及最大內存消耗、硬盤消耗。通過任務模型修正的算法，通過計算可得到一個相對平穩正常的資源消耗預測數據，用于該任務的資源消耗估計，如果波動超過10%（門限可配置調整），則作為學習異常的錯誤拋出，進行人工干預。

步驟5資源分析決策：資源決策模塊在任務到來時，決策模塊根據任務模型管理模塊中的任務資源二維表，按照任務資源消耗算法，得到任務資源消耗，將該任務資源消耗的數據預測和現存的資源進行對比，得到是否需要申請或釋放的結果。資源占用指標暫定為CPU使用率、內存使用率、磁盤占用率，可后續進行擴展。

虛擬機資源申請：未來每5 min的資源占用（連續N個5 min周期）均大于系統總資源（監控模塊獲取當前系統占用資源和空閑資源）時，則需要進行虛擬機的申請，超過當前系統資源的部分最終換算成需要申請的虛擬機臺數。

虛擬機資源釋放：將1個大周期內（1 h）未來每5 min的峰值資源占用和系統總資源進行對比，如峰值資源按照任務資源消耗算法換算的虛擬機數量大于現有的虛擬機臺數，則釋放虛擬機。為了規避虛擬機釋放過多導致的應用問題，系統設置一個虛擬機釋放的門限N，設定1 h內最多減少N臺虛擬機（N可根據應用特點來動態設定）。

步驟6資源動態調度：根據資源決策模塊判斷的申請/釋放結果調用云平臺的API，實現虛擬機的申請和釋放，同時，調用任務調度管理模塊的消息，實現對申請/釋放虛擬機的應用任務的動態分發調度，各應用服務的啟動事先部署在云平臺模板中，在申請虛擬機時，將任務需要的虛擬機模板發送到云平臺上，這樣，在云平臺接收到虛擬機申請后，會根據模板部署虛擬機，虛擬機使用模板附帶的自動腳本來啟動應用服務。

2.4 基于任務時間的調度方案

2.4.1 適用場景

有些業務有顯著的時間特點，在不同的時間段有不同的資源需求，如網管網絡支撐客服Web業務和桌面云業務，均在工作時間高發使用，而在晚上使用量會驟然下降。這類業務應用基于時間特點呈現的波峰波谷資源使用特點，需要使用時分復用的算法，將不同時間段內空閑出來的資源復用起來。

2.4.2 調度方案

通過彈性伸縮組定義時間策略的方式進行時間維度的調度。在不同的時間段內，可以定義啟動、停止、創建、刪除虛擬機的策略，使得不同應用在不同時段使用相同的資源，達到資源高效利用的目的，如圖4所示。

自動伸縮組是將邏輯上對等的一組機器資源組織成一個邏輯上的“大機器”。通過對資源、伸縮策略、負載評估算法、負載均衡等的配置和管理，提供橫向的擴展或者收縮能力。

·當業務配置的時間點到達時，則由時間策略管理模塊發出策略觸發事件。

·伸縮組根據配置的方案，進行擴容。

·伸縮組同時根據相關業務的時間重疊性，回收重疊業務已經分配的資源（如果業務的資源分配在擴容時間段內）。

·當業務配置的回收策略時間點到達時，時間策略管理模塊發出策略觸發事件。

·伸縮組根據配置的方案，進行資源回收。

圖4 基于任務時間的資源調度

·伸縮組同時根據業務的時間重疊性，擴容重疊業務的資源分配（如果業務在擴容時間段內）。

2.4.3 調度流程

步驟1自動伸縮組配置時間策略。

步驟2應用A的時間策略觸發：應用A根據業務需求，擴張資源，占據資源，提供服務。

步驟3應用A結束時間策略觸發：應用A根據業務需求，減少資源占用。

步驟4應用B的時間策略觸發：計算應用A資源池資源空閑量，創建應用B業務VM，應用B占據資源運行。

步驟5應用B結束時間策略觸發：應用B結束業務占用的VM，釋放占用的資源。

3 建設效果

3.1 基于負載性能的調度方案——網絡支撐客服Web集群

實施基于負載性能調度后，Web集群由從物理機遷移至虛擬機環境。Web集群使用了基于負載性能調度對Web集群服器CPU、內存、每秒服務請求數量進行監控，當這些指標達到閾值上、下限時，自動調整Web集群節點數量。表1為實施前、實施后計算資源對比情況。

表1 方案實施前后對比

基于負載性能的彈性調度，只需要在被管理集群上部署監控模塊，定時向云平臺上報性能數據，由云平臺根據彈性調度策略分析引擎進行評估，并進一步決定開通或回收虛擬機，完成彈性調度。應用系統只需要提供性能采集接口，無須增加應用系統額外的開發工作，適合在私有云大部分應用系統上進行推廣。

3.2 基于規劃擴容調度方案——統一采集集群

統一采集是網管系統的核心業務，因此，每個虛擬機CPU、內存分配方式為100%預留，以保證有足夠的計算資源，承載突發業務流量。

實施基于業務申請調度時，創建了一組基于彈性調度的虛擬機，與原有統一采集集群并行運行。其資源動態調配比較復雜，需考慮到采集任務的隊列長度、傳輸時延等業務運行指標。表2為實施前、實施后計算資源對比情況。

表2 方案實施前后對比

當應用系統計算資源調配不僅依賴于系統性能指標，而且依賴于業務運行指標，彈性調度算法相對復雜時，更適合使用基于業務申請的彈性調度。如果應用系統的業務運行指標可以方便地進行量化，可以將應用系統的業務運行KPI擴展至私有云平臺，由私有云平臺實現基于負載性能的彈性調度，以減少應用系統的開發、部署工作量。

3.3 基于業務申請調度方案——網絡支撐客服Hadoop集群

在一般情況下，Hadoop集群在運行一段時間之后，有資源擴充的需求，沒有資源回收的需求。但在擴充Hadoop集群時，需要準備IP網絡、存儲網絡環境，手工安裝Hadoop節點，再將計算節點擴充至Hadoop集群，工作量大，操作復雜。

基于規劃擴容的資源調度解決了這個問題，在Hadoop集群運行過程中，通過采集Hadoop運行性能信息，定期制作Hadoop集群節點需求趨勢評估報告，由基礎架構管理員根據評估報告制定擴容規劃，擴充物理機計算節點至Hadoop集群，節省了大量的手工操作。

3.4 基于任務時間調度方案——桌面云調度與資源聯動

在調度方案實施之前，桌面云系統使用詳情見表3。

表3 方案實施前運行情況

采用網管應用、桌面云聯動方式：在桌面云系統業務閑時，運行網管MR補采、報表匯總等功能實時性要求不是非常高的應用。為保證二者之間的物理隔離，在同一個hypervisor上，網管業務、桌面云業務使用不同的物理網卡、FC卡連接各自的IP網絡、存儲網絡，并在夜間采取如下措施盤活計算資源：將空閑桌面休眠或關閉，釋放CPU、內存計算資源；集中遷移非空閑桌面應用至指定hypervisor，釋放其他hypervisor CPU、內存計算資源；在業務人員上班前，恢復已休眠桌面或啟動空閑桌面。表4為桌面云系統實施定時資源釋放與回收之后的資源使用率性能。

表4 方案實施后運行情況

除桌面云系統外，基于任務時間調度可進一步推廣至具有明顯時間特性的資源池/應用系統，如業務支撐系統的CRM、BOSS等應用系統，主要集中在白天使用計算資源，而經營分析系統集中在夜間使用資源。這一類資源池/應用系統都適合采用基于任務時間的彈性調度，完成在時間上互補的應用系統相互填峰削谷，使計算資源錯峰使用。

4 結束語

如何實現云資源使用的按需分配和動態管理是業務支撐系統云化中面臨的重要問題，本文基于負載性能、規劃擴容、業務申請及任務時間4個場景對資源動態調度方案進行了探索與實踐，為今后業務支撐系統云化的資源調度提供了可借鑒的經驗和思路。

[1]宋維佳,馬皓,肖臻,等.虛擬化數據中心資源調度研究[J].廣西大學學報,2011(S1):329-333.SONG W J,MA H,XIAO Z,et al.A survey of resource scheduling for virtualized data center[J].Journal of Guangxi University,2011(S1):329-333.

[2]陳睦,黃黎明,李先鋒.云計算中虛擬機磁盤遷移時機優化策略[J].計算機工程與設計,2014(2):525-530.CHEN M,HUANG L M,LI X F.Disk migration timing optimization mechanism in cloud computing[J].Computer Engineering and Design,2014(2):525-530.

[3]郭濤,劉菲軍,杜垚,等.云計算環境下虛擬機部署策略的優化[J].計算機應用研究,2012(9):3425-3431.GUO T,LIU F J,DU Y,et al.Virtual machine deployment optimization in cloud[J].Application Research of Computers,2012(9):3425-3431.