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

  1、引言

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

2、相關(guān)技術(shù)

2.1 云計(jì)算

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

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

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

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

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

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

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

2.2 平臺(tái)虛擬化技術(shù)

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

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

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

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

2.3 虛擬機(jī)遷移技術(shù)

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

2.4 虛擬機(jī)靜態(tài)遷移技術(shù)

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

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

2.5虛擬機(jī)動(dòng)態(tài)遷移技術(shù)

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

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

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

3）   目標(biāo)主機(jī)定位策略：給遷移指定的虛擬機(jī)選擇最佳的目標(biāo)主機(jī)，目標(biāo)主機(jī)的選擇可用不同的策略來(lái)實(shí)現(xiàn)，如隨機(jī)加權(quán)選擇策略、最快反應(yīng)速度策略、首次適應(yīng)或最佳適應(yīng)策略等。

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

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

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

由于VM構(gòu)成的那部分資源利用率是可變的，難以量化的，進(jìn)而導(dǎo)致的遷移結(jié)果也難以預(yù)測(cè)。因此本文以下列相關(guān)指標(biāo)和部分假設(shè)來(lái)量化VM的負(fù)載和宿主機(jī)的性能：

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

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

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

因此，目標(biāo)宿主機(jī)在VM遷入之后的負(fù)載用以下公式計(jì)算：

基于實(shí)時(shí)反饋的綜合負(fù)載均衡資源優(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、策略方案的應(yīng)用

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

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

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

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

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

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

5、總結(jié)

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

參考文獻(xiàn)

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

[2]蔚歡樂(lè). 基于OpenStack的資源動(dòng)態(tài)分配框架的設(shè)計(jì)與實(shí)現(xiàn)

[3]樊勇兵,丁圣勇,陳天,汪來(lái)福. 解惑云計(jì)算. 人民郵電出版社

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

[5] 錢(qián)樂(lè)秋《軟件工程》第2版;北京清華大學(xué)出版社，2013-08-01