關鍵詞：城市照明，云計算，資源調(diào)度

  1、引言

城市照明在過去的20多年經(jīng)歷了大幅度發(fā)展，針對監(jiān)控設施運行情況的遠程監(jiān)測和集中控制技術已趨于成熟，90%的省會城市，60%的地級市已經(jīng)完成路燈遠程監(jiān)控系統(tǒng)的建設。但是仍有相當一部分地級市、縣級市甚至鄉(xiāng)鎮(zhèn)對照明監(jiān)控有著迫切的需求，而受限于一次性投入的成本較高，享受不到先進技術對管理能力的提升。此外，隨著云計算的發(fā)展，尤其是2012年我國興起的以物聯(lián)網(wǎng)云計算應用為核心業(yè)務的信息技術浪潮，將成為引領未來信息產(chǎn)業(yè)創(chuàng)新的關鍵戰(zhàn)略性技術和手段。

2、相關技術

2.1 云計算

云計算是一種新計算模式，是分布式計算、并行計算和網(wǎng)格計算的融合產(chǎn)物。但是其定義各有不同，并無一個確定的標準。云計算系統(tǒng)一般有以下特點：

1） 規(guī)模龐大?！霸啤蹦芙o予用戶高效的計算能力，其具有相當可觀的資源和設備。

2）虛擬化。云計算支持用戶使用各種終端在云系統(tǒng)的任意位置獲取服務。用戶不必了解應用具體在云中的運行位置，只需知道應用是在“云”中某處運行即可。

3）高可靠性?！霸啤辈捎昧藬?shù)據(jù)多副本、計算節(jié)點同構(gòu)可互換等多種措施來保障服務的高可靠性，使得云技術比本地計算機的安全性更高。

4） 通用性。在“云”的支撐下，云計算不針對指定的應用，能夠支撐應用的千變?nèi)f化。

5）按需服務。作為一個資源池，“云”根據(jù)客戶需求給客戶提供服務。

云計算體系中的硬件和軟件被抽象整合為資源，并以服務的形式向用戶提供，用戶則主要以互聯(lián)網(wǎng)為接入點，獲取云中的服務。

2.2 平臺虛擬化技術

隨著研發(fā)的虛擬化軟件連同IT硬件的改進和多樣化，虛擬化的應用領域也得到的大幅度擴展，同時對基于多個方面解決各種系統(tǒng)性能問題提出了大量不同類型的虛擬化解決方案。通常我們說的虛擬化技術主要是操作系統(tǒng)等級的虛擬化，操作系統(tǒng)虛擬化的體系結(jié)構(gòu)如圖1所示。

圖1 操作系統(tǒng)虛擬化的體系結(jié)構(gòu)

城市照明公共服務云平臺將基礎設施和照明公共服務應用相隔離，通過存儲虛擬化、計算虛擬化、網(wǎng)絡虛擬化等為用戶提供透明的基礎設施資源及照明公共服務虛擬化應用，讓用戶只關心自己的需求是否得到滿足，無需了解平臺內(nèi)部結(jié)構(gòu)。

城市照明云服務和城市管理用戶是一對多的客戶關系，用戶以租賃的方式獲取服務，功能實例是在用戶租賃的虛擬系統(tǒng)上運行的。平臺作為一個共享基礎架構(gòu)能有效屏蔽底層資源的異構(gòu)性，將各種通信、計算及存儲資源充分整合入資源池，進行統(tǒng)一管理和調(diào)度，為用戶創(chuàng)造服務器、存儲、應用、桌面虛擬服務。對用戶而言，這些資源是透明的，他們無須了解內(nèi)部結(jié)構(gòu)，只關心自己的需求是否得到滿足即可。

2.3 虛擬機遷移技術

在云平臺中，虛擬機的建立和銷毀是動態(tài)的，云服務器中，隨時都可能存在新虛擬機的創(chuàng)建和任務運行完成的虛擬機的銷毀。因此，單個復雜化的云服務器的資源分配問題是由其中虛擬機參數(shù)及個數(shù)的動態(tài)性決定的。若僅僅是虛擬機的初始部署，則當虛擬機的總體個數(shù)呈下降趨勢或達到一個基本的平衡趨勢時，就可能出現(xiàn)部分物里服務器的資源利用率已經(jīng)過高導致資源緊缺和部分物理服務器的資源利用率卻很低導致資源空閑這兩種情況，這時，就需要重新部署部分虛擬機，盡可能以最少的物理服務器運行應用任務。除此之外，在任務量頗大的情況下，還可能造成資源的浪費，因為在任務量的高峰時間完結(jié)之后，一些服務器上資源使用率已超過了閾值，而又些服務器資源卻依舊空閑。這時，就需要出發(fā)并實施虛擬機遷移，重新分配主機資源。

2.4 虛擬機靜態(tài)遷移技術

虛擬機靜態(tài)遷移方式是基于“stop-and-copy”模式來進行的，其原理是：首先，由VMM發(fā)出掛起指令給被選定待遷移的目標虛擬機，遷移的目標虛擬機收到掛起指令后暫停虛擬機中運行的所有應用程序，然后將被遷移虛擬機的內(nèi)存拷貝到遷移實施的目標主機上，數(shù)據(jù)傳輸結(jié)束以后，啟動目標主機上的虛擬機并繼續(xù)向用戶提供該服務。

從“stop-and-copy”遷移模式的邏輯可以看出，該模式明顯的不足就在于遷移指令的執(zhí)行開始，應用服務就要暫停其對外的服務能力，從而導致服務的暫停時間過長，應用服務在整個遷移過程中處于不可訪問的狀態(tài)較久，以至于對虛擬機應用提供服務的質(zhì)量及用戶需求造成了嚴重的影響。

2.5虛擬機動態(tài)遷移技術

虛擬機動態(tài)遷移方式是虛擬機遷移技術的重要部分，它能夠在不關閉虛擬機的情況下，將處于運行狀態(tài)的虛擬機從一個物理節(jié)點遷移到另一個物理節(jié)點上，從而實現(xiàn)數(shù)據(jù)中心節(jié)能、服務器的維護和更新等。虛擬機動態(tài)遷移，又稱為實時遷移或在線遷移，旨在保證正常提供虛擬機上執(zhí)行服務的情況下，實施虛擬機遷移操作。通常虛擬機的遷移過程是首先暫停虛擬機，虛擬機在服務器之間共享存儲系統(tǒng)的只需將系統(tǒng)狀態(tài)拷貝到目標服務器上，接著重建虛擬機實例狀態(tài)，恢復虛擬機實例服務，而使用本地存儲模式的還需要在暫停虛擬機的過程中復制虛擬機實例鏡像到目標服務器。在實時遷移過程中虛擬機的宕機時間將相當短暫，用戶幾乎感覺不到服務的中斷，不會影響服務質(zhì)量。虛擬機動態(tài)遷移操作主要策略有：

1）   遷移觸發(fā)策略：判斷觸發(fā)遷移的時機，決定什么時候觸發(fā)遷移操作。目前諸多虛擬機遷移機制都是依據(jù)特定值來決定的，即當虛擬機的某個資源使用率高于既定閾值時，立刻觸發(fā)宿主機實施遷移。

2）   目標虛擬機選擇策略：即在超負荷運行的宿主機上選取合適的目標虛擬機實施遷移操作，包括遷移時CPU狀態(tài)、IO、內(nèi)存鏡像和硬盤數(shù)據(jù)等。因此在實施遷移操作之前，必須選擇好的遷移的目標虛擬機，以便最大程度降低服務器因負載過高而增加的能耗。

3）   目標主機定位策略：給遷移指定的虛擬機選擇最佳的目標主機，目標主機的選擇可用不同的策略來實現(xiàn)，如隨機加權選擇策略、最快反應速度策略、首次適應或最佳適應策略等。

3、基于實時反饋的負載均衡資源調(diào)度策略

在云平臺中VM的動態(tài)遷移是非常重要的，而根據(jù)什么策略來實施動態(tài)遷移就成為了一個非常熱門的研究點。本平臺則采用了一種基于實時反饋的綜合負載均衡資源優(yōu)化策略。該策略根據(jù)云平臺中各個宿主機的CPU和內(nèi)存的實時負載信息，通過把VM從一臺重負載的宿主機上動態(tài)遷移到一臺輕負載的宿主機上的方式實現(xiàn)云平臺資源的均衡和高效利用。該策略的關鍵在于計算制定出VM遷移計劃，包括一個或多個遷移操作。每一個遷移操作由一個源宿主機、一個VM和一個目標宿主機組成。如果宿主機中由VM構(gòu)成的那部分資源利用率是固定并且已知的，那么制定一個VM遷移計劃實際上就是一個經(jīng)典的裝箱問題。在這種情況下，一個理想的解決方案是：計算出宿主機的平均負載，計算并找出負載方差最小的一個VM布局，然后將其與云平臺現(xiàn)有的虛擬布局進行比較制定出VM遷移計劃。但是VM的負載是可變和難以進行測定的，并且VM遷移操作也有資源的耗費，因此遷移結(jié)果是很難預測的。

為了使VM的遷移結(jié)果可控，本策略使用貪心算法，一次只處理一個宿主機上的VM遷移操作，并且每個宿主機只進行一個VM遷移操作。當宿主機的負載在連續(xù)幾個取樣間隔中的值T_n都超過預定義的閾值時，該宿主機將被作為候選的源宿主機。之后從該宿主機上選取一個合適的VM作為候選VM。為了盡量減少遷移操作，優(yōu)先選取占用資源最多的那個VM。因為遷移本身是需要消耗資源的，所以本策略需要同時評估VM遷移的價值和資源消耗。

由于VM構(gòu)成的那部分資源利用率是可變的，難以量化的，進而導致的遷移結(jié)果也難以預測。因此本文以下列相關指標和部分假設來量化VM的負載和宿主機的性能：

1） 宿主機的性能由它的配置規(guī)格來計算。其中，內(nèi)存容量取決于宿主機的內(nèi)存配置；CPU性能取決于宿主機的vCPU個數(shù)。

2） 宿主機中VM構(gòu)成的那部分CPU負載取決于VM中vCPU個數(shù)，每個vCPU占滿一個物理內(nèi)核。

3） 宿主機中由VM構(gòu)成的那部分內(nèi)存負載取決于VM的內(nèi)存配置，VM中的每個內(nèi)存單元占用宿主機中相應物理內(nèi)存的100%。

因此，目標宿主機在VM遷入之后的負載用以下公式計算：

基于實時反饋的綜合負載均衡資源優(yōu)化策略算法偽代碼如下：

 public void LoadBalance()

  {

     if(resource_load_type is not cpu or men) return; //policy is disabled

        if(resource_load_type is cpu) {

          foreach (var host in allhosts) {

                    if(host.hasmigrationvm==true)continue;

                    if(host.CPUut>Ta) { host.Tva++; }else{host.Tva = 0; }

                    if(host.Tva>Tva) { HostListAboveTa.add(host); }

                    if(host.CPUut

                    if(host.Tvb>Tvb) {HostListbelowTb.add(host); }

                }

          foreach (var hostx in HostListAboveTa) {

            var bestTargetHost = null;

            VM list Sorted by cost and value of migration = vms;

             foreach(vm in vms on hostx) {

                   hostlist = get_possible_host_list(vm);

                   foreach(host in hostlist) {

                    if(!HostListbelowTb.contains(host)) continue;

                     host.CPUnewut = host.CPUut + VMncpu/Hostnscore;

                    if(host.CPUnewut>Tb)continue; if(bestTargetHost==null||(bestTargetHost.CPUnewut>host.CPUut.newut))                    bestTargetHost = host;

} }

             if(bestTargetHost!=null) {

                        migrate vm to bestTargetHost;

                        HostListbelowTb.remove(bestTargetHost);

                    } } }

 if(resource_load_type is men)

            {//和CPU的算法描述類似

               }

 }

4、策略方案的應用

基于物聯(lián)網(wǎng)的城市照明公共服務云平臺采用三臺機器compute2、compute3、compute4作為計算節(jié)點、compute1作為控制節(jié)點。將compute2、compute3、compute4組成一個資源池。平臺使用KVM虛擬方案，采用m1.tiny、m1.small、m1.medium、m1.large、m1.xlarge五種虛擬機創(chuàng)建模板。平臺可以根據(jù)用戶定制的服務使用不同的虛擬機創(chuàng)建模板。在搭建完框架后，需要對部分的指標進行取樣和配置。關鍵指標的選取和配置如下：

1）取樣指標的穩(wěn)定性。本文提出的策略中，CPU和內(nèi)存的負載指標將被用來觸發(fā)VM的遷移操作。特定的取樣采集是有偶然性的，所有平臺采用了只有當這些負載指標在幾次連續(xù)的取樣中都滿足條件時才觸發(fā)VM的遷移操作，這就需要穩(wěn)定化設置。

2)資源優(yōu)化策略的運行頻率。平臺的采樣頻次設置為3，采樣時間間隔設置為5分鐘。因此VM遷移操作在啟用該穩(wěn)定化值后將在15分鐘后觸發(fā)。

3）配置遷移級別。平臺可在“high”、“middle”、“l(fā)ow”三個層次上運行，這三個層級配置的閾值為：high: Ta為70%，Tb為40%；middle: Ta為75%，Tb為35%；low: Ta為85%，Tb為30%。平臺采用high級別的閾值。

平臺采用初始放置在compute2上，使用m1.large模板快速創(chuàng)建4個虛擬機，每個大約占用25%的CPU。經(jīng)過一段時間后，結(jié)果如下表所示：

 結(jié)果表明，當CPU超過70%時觸發(fā)遷移操作，將其中的兩個VM勢力分別遷移到compute3和compute4上。這樣compute2上的負載降低至50%，低于閾值70%，所以將不在進行VM遷移操作。這樣該策略可以很好的平衡平臺中的資源負載。

5、總結(jié)

本文提出了一個基于實時反饋的資源負載均衡策略，并在城市照明公共服務云平臺上進行了實驗。使得平臺上的虛擬機有了均衡的調(diào)度，各個虛擬機運行穩(wěn)定?，F(xiàn)在平臺上啟用了4臺虛擬機，其中三個用于公司內(nèi)部測試，一個搭載著照明監(jiān)控服務。系統(tǒng)運行至今一直非常穩(wěn)定，讓用戶單位享受到“云+端”服務。

參考文獻

[1]OpenStack Object Storage Developer Guid. http://docs./.

[2]蔚歡樂. 基于OpenStack的資源動態(tài)分配框架的設計與實現(xiàn)

[3]樊勇兵,丁圣勇,陳天,汪來福. 解惑云計算. 人民郵電出版社

[4]鄭國《國內(nèi)外數(shù)字化城市管理案例》;中國人民大學出版社,2009-12-01

[5] 錢樂秋《軟件工程》第2版;北京清華大學出版社，2013-08-01