牟宏蕾，楊波，郝亞飛

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

1 引言

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

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

為了提高資源利用率，提升云資源的運維效率，本文針對業(yè)務(wù)支撐系統(tǒng)不同場景的需求對云資源的動態(tài)調(diào)度進行了探索。

2 資源動態(tài)調(diào)度方案

2.1 基于負載性能的調(diào)度方案

2.1.1 適用場景

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

圖1 業(yè)務(wù)支撐系統(tǒng)演進

根據(jù)此類業(yè)務(wù)的負載變化特點，有針對性地動態(tài)調(diào)節(jié)資源供給量，以達到資源隨著業(yè)務(wù)量變化聯(lián)動的效果，保持資源使用率維持在較高水準，提高資源平均利用率。

2.1.2 調(diào)度方案

通過引入業(yè)務(wù)服務(wù)等級管理的概念，進行資源的動態(tài)調(diào)整。通過虛擬機服務(wù)等級的定義和各種選項的組合，影響虛擬機在創(chuàng)建和運行時的狀態(tài)，從而區(qū)別對待不同的虛擬機。在業(yè)務(wù)申請時，可以根據(jù)自身業(yè)務(wù)的需求而選擇不同的服務(wù)等級。

虛擬機在創(chuàng)建時如果指定了服務(wù)等級，則在資源調(diào)度系統(tǒng)中調(diào)度時，會將服務(wù)等級定義參數(shù)作為調(diào)度的參考因素之一?；A(chǔ)服務(wù)等級定義有如下種類。

·計算類資源：包括資源池、集群、資源標簽及內(nèi)存預(yù)留。

·網(wǎng)絡(luò)類資源：包括設(shè)置網(wǎng)絡(luò)、網(wǎng)絡(luò)限速。

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

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

調(diào)度系統(tǒng)在調(diào)度虛擬機資源時，將根據(jù)服務(wù)等級的定義自動選擇合適的hypervisor主機、網(wǎng)絡(luò)以及存儲類型。在分配hypervisor主機資源時，根據(jù)SLA的定義，預(yù)留主機CPU和內(nèi)存資源，確保虛擬機運行性能。

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

2.1.3 調(diào)度流程

步驟1業(yè)務(wù)申請?zhí)摂M機：應(yīng)用業(yè)務(wù)動態(tài)申請資源，實現(xiàn)業(yè)務(wù)直接與平臺的對接，簡化資源申請流程。

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

步驟3云管理平臺選擇適當?shù)膆ypervisor運行業(yè)務(wù)虛擬機：根據(jù)應(yīng)用設(shè)定的資源等級信息，對應(yīng)開通相應(yīng)的資源，確保重點應(yīng)用優(yōu)質(zhì)資源保障。

步驟4云管理平臺在運行期監(jiān)測業(yè)務(wù)虛擬機資源需求：平臺根據(jù)應(yīng)用的發(fā)展與負載性能的變化及時調(diào)整資源分配策略。

步驟5云管理平臺動態(tài)調(diào)整虛擬機資源：平臺根據(jù)調(diào)度策略及時更新應(yīng)用的資源供給。

圖2 應(yīng)用架構(gòu)

2.2 基于規(guī)劃擴容調(diào)度方案

2.2.1 適用場景

客服系統(tǒng)WAP話單處理模塊使用的是Hadoop架構(gòu)，有著大數(shù)據(jù)應(yīng)用的顯著特點，即數(shù)據(jù)量不斷擴大，需要資源的橫向擴展能力很強，并且可以達到無限擴展能力。此類大數(shù)據(jù)類型應(yīng)用需要資源的特點是資源在擴展后隨時可加入，資源的使用情況是可預(yù)計的?；谶@類應(yīng)用的特點，給出基于規(guī)劃擴容的動態(tài)調(diào)度機制。

2.2.2 調(diào)度方案

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

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

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

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

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

2.2.3 調(diào)度流程

步驟1納管Hadoop集群：通過應(yīng)用監(jiān)控采集Hadoop的運行數(shù)據(jù)。

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

2.3 基于業(yè)務(wù)申請調(diào)度方案

2.3.1 適用場景

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

2.3.2 調(diào)度方案

業(yè)務(wù)系統(tǒng)根據(jù)自身相關(guān)任務(wù)的特點建立任務(wù)模型和長期有效的學(xué)習(xí)機制，通過對自身業(yè)務(wù)的不斷學(xué)習(xí)，收集每個任務(wù)資源消耗，從而不斷地更新任務(wù)模型，使得每個任務(wù)模型能持續(xù)優(yōu)化，為每個任務(wù)建立一個比較準確的資源消耗值。

通過對自身任務(wù)策略的分析和每個任務(wù)的資源消耗，對未來一段時間內(nèi)的資源消耗進行預(yù)估，將預(yù)估值與系統(tǒng)的當前資源量進行對比，當預(yù)估值大于系統(tǒng)當前資源量時，將差值換算成虛擬機的數(shù)量，調(diào)用云平臺的資源申請API，實現(xiàn)資源的自動申請。如果預(yù)估值小于系統(tǒng)當前資源量時，將差值換算成虛擬機的數(shù)量，調(diào)用云平臺的資源釋放API，實現(xiàn)資源的自動釋放。系統(tǒng)架構(gòu)如圖3所示。

各模塊功能如下。

任務(wù)管理：主要包括任務(wù)策略管理、任務(wù)生成、任務(wù)分發(fā)等功能。該模塊根據(jù)任務(wù)策略生成相應(yīng)的處理任務(wù)，并按照動態(tài)負載均衡策略把任務(wù)分發(fā)到虛擬機的任務(wù)執(zhí)行（業(yè)務(wù)主機）節(jié)點；同時，對處理任務(wù)的執(zhí)行狀態(tài)進行監(jiān)控。

模型管理：將各類處理任務(wù)抽象出任務(wù)特征值，對其進行建模，將任務(wù)學(xué)習(xí)管理模塊監(jiān)測、學(xué)習(xí)到的整個任務(wù)運行周期內(nèi)資源消耗信息更新到任務(wù)模型管理的數(shù)據(jù)庫中，實現(xiàn)對任務(wù)模型的管理，并支持向外擴展。

任務(wù)學(xué)習(xí)：根據(jù)任務(wù)調(diào)度管理模塊中的任務(wù)策略以及任務(wù)基本信息，生成學(xué)習(xí)任務(wù)，下發(fā)至學(xué)習(xí)機，學(xué)習(xí)機針對學(xué)習(xí)任務(wù)定期上報采樣數(shù)據(jù)，采樣數(shù)據(jù)提供給任務(wù)模型管理模塊進行任務(wù)模型的更新修正。

資源監(jiān)控：主要實現(xiàn)虛擬機資源負載的實時監(jiān)控功能、任務(wù)實時采樣數(shù)據(jù)的收集。

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

圖3 系統(tǒng)架構(gòu)

資源調(diào)度：根據(jù)資源決策模塊的分析結(jié)果，調(diào)用云平臺提供的API，實現(xiàn)虛擬機的申請和銷毀，同時，將虛擬機的信息發(fā)送給任務(wù)調(diào)度管理模塊，實現(xiàn)處理任務(wù)的動態(tài)調(diào)度，保證在申請和銷毀虛擬機上的任務(wù)動態(tài)調(diào)整。

2.3.3 調(diào)度流程

步驟1任務(wù)生成：任務(wù)調(diào)度管理模塊根據(jù)任務(wù)策略定時啟動處理任務(wù)，并按照動態(tài)負載均衡策略把任務(wù)分發(fā)到云平臺虛擬機的任務(wù)執(zhí)行節(jié)點；對任務(wù)的執(zhí)行狀態(tài)進行監(jiān)控，并通知任務(wù)學(xué)習(xí)模塊進行任務(wù)的資源消耗監(jiān)測。

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

步驟3任務(wù)學(xué)習(xí)：任務(wù)學(xué)習(xí)管理模塊收到任務(wù)調(diào)度管理模塊發(fā)送的任務(wù)啟動消息后，根據(jù)任務(wù)標識，對在任務(wù)執(zhí)行節(jié)點上的任務(wù)每5 s（可配置調(diào)整）進行一次資源消耗監(jiān)測，并記錄監(jiān)測到的數(shù)據(jù)，直至任務(wù)完成。

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

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

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

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

步驟6資源動態(tài)調(diào)度：根據(jù)資源決策模塊判斷的申請/釋放結(jié)果調(diào)用云平臺的API，實現(xiàn)虛擬機的申請和釋放，同時，調(diào)用任務(wù)調(diào)度管理模塊的消息，實現(xiàn)對申請/釋放虛擬機的應(yīng)用任務(wù)的動態(tài)分發(fā)調(diào)度，各應(yīng)用服務(wù)的啟動事先部署在云平臺模板中，在申請?zhí)摂M機時，將任務(wù)需要的虛擬機模板發(fā)送到云平臺上，這樣，在云平臺接收到虛擬機申請后，會根據(jù)模板部署虛擬機，虛擬機使用模板附帶的自動腳本來啟動應(yīng)用服務(wù)。

2.4 基于任務(wù)時間的調(diào)度方案

2.4.1 適用場景

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

2.4.2 調(diào)度方案

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

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

·當業(yè)務(wù)配置的時間點到達時，則由時間策略管理模塊發(fā)出策略觸發(fā)事件。

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

·伸縮組同時根據(jù)相關(guān)業(yè)務(wù)的時間重疊性，回收重疊業(yè)務(wù)已經(jīng)分配的資源（如果業(yè)務(wù)的資源分配在擴容時間段內(nèi)）。

·當業(yè)務(wù)配置的回收策略時間點到達時，時間策略管理模塊發(fā)出策略觸發(fā)事件。

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

圖4 基于任務(wù)時間的資源調(diào)度

·伸縮組同時根據(jù)業(yè)務(wù)的時間重疊性，擴容重疊業(yè)務(wù)的資源分配（如果業(yè)務(wù)在擴容時間段內(nèi)）。

2.4.3 調(diào)度流程

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

步驟2應(yīng)用A的時間策略觸發(fā)：應(yīng)用A根據(jù)業(yè)務(wù)需求，擴張資源，占據(jù)資源，提供服務(wù)。

步驟3應(yīng)用A結(jié)束時間策略觸發(fā)：應(yīng)用A根據(jù)業(yè)務(wù)需求，減少資源占用。

步驟4應(yīng)用B的時間策略觸發(fā)：計算應(yīng)用A資源池資源空閑量，創(chuàng)建應(yīng)用B業(yè)務(wù)VM，應(yīng)用B占據(jù)資源運行。

步驟5應(yīng)用B結(jié)束時間策略觸發(fā)：應(yīng)用B結(jié)束業(yè)務(wù)占用的VM，釋放占用的資源。

3 建設(shè)效果

3.1 基于負載性能的調(diào)度方案——網(wǎng)絡(luò)支撐客服Web集群

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

表1 方案實施前后對比

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

3.2 基于規(guī)劃擴容調(diào)度方案——統(tǒng)一采集集群

統(tǒng)一采集是網(wǎng)管系統(tǒng)的核心業(yè)務(wù)，因此，每個虛擬機CPU、內(nèi)存分配方式為100%預(yù)留，以保證有足夠的計算資源，承載突發(fā)業(yè)務(wù)流量。

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

表2 方案實施前后對比

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

3.3 基于業(yè)務(wù)申請調(diào)度方案——網(wǎng)絡(luò)支撐客服Hadoop集群

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

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

3.4 基于任務(wù)時間調(diào)度方案——桌面云調(diào)度與資源聯(lián)動

在調(diào)度方案實施之前，桌面云系統(tǒng)使用詳情見表3。

表3 方案實施前運行情況

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

表4 方案實施后運行情況

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

4 結(jié)束語

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

[1]宋維佳,馬皓,肖臻,等.虛擬化數(shù)據(jù)中心資源調(diào)度研究[J].廣西大學(xué)學(xué)報,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]陳睦,黃黎明,李先鋒.云計算中虛擬機磁盤遷移時機優(yōu)化策略[J].計算機工程與設(shè)計,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]郭濤,劉菲軍,杜垚,等.云計算環(huán)境下虛擬機部署策略的優(yōu)化[J].計算機應(yīng)用研究,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.