一種資源管理方法及裝置的制造方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及通信技術(shù)領(lǐng)域，具體涉及一種資源管理方法及裝置。
【背景技術(shù)】
[0002]隨著大數(shù)據(jù)和云計算時代的來臨，數(shù)據(jù)中心等概念越來越被人所熟知。目前，最大的數(shù)據(jù)中心由超過十萬臺的物理節(jié)點組成，功耗超過20兆瓦已經(jīng)非常普遍，預(yù)期不久的將來會達到200兆瓦，正在逼近數(shù)據(jù)中心供電的極限。然而，當(dāng)前數(shù)據(jù)中心也同時面臨著資源使用率不高的問題。例如，許多大的云計算基礎(chǔ)設(shè)施提供商，其數(shù)據(jù)中心中CPU和內(nèi)存資源使用率都低于40%，就單個節(jié)點(物理機)來說，大部分的物理機資源使用率都低于50%。因此，在硬件成本不斷提高的背景下，如何有效的將數(shù)據(jù)中心中的應(yīng)用進行整合，提高資源使用率，具有重要的現(xiàn)實意義。
[0003]在主流云計算提供商如亞馬遜、Google的大力推動下，越來越多的應(yīng)用提供商將他們的應(yīng)用遷徙到數(shù)據(jù)中心云平臺上，利用數(shù)據(jù)中心的規(guī)模效應(yīng)降低應(yīng)用部署成本。一般來說，數(shù)據(jù)中心應(yīng)用可以分為兩種類型:
[0004]服務(wù)類應(yīng)用:此類應(yīng)用如搜索引擎(Search Engine)、社交網(wǎng)絡(luò)(Social Network)和電子商務(wù)(E-commerce)等往往提供在線服務(wù),用戶對請求延遲十分敏感,請求的執(zhí)行時間稍有延遲就會造成大量的用戶流失和經(jīng)濟損失。
[0005]分析類應(yīng)用:此類應(yīng)用如Hadoop上排序、kneans等對任務(wù)處理時間不敏感,其性能往往用吞吐量(單位時間處理的任務(wù)數(shù))來衡量。
[0006]在當(dāng)前的數(shù)據(jù)中心中，往往基于虛擬化技術(shù)將多個應(yīng)用整合在同一個節(jié)點上。如圖1所示，數(shù)據(jù)中心包含η個節(jié)點，每個節(jié)點上均運行有服務(wù)類應(yīng)用和分析類應(yīng)用，這種數(shù)據(jù)中心運行的服務(wù)類應(yīng)用通常有如下特征:
[0007](1)大規(guī)模、高并發(fā):現(xiàn)代數(shù)據(jù)中心中的每個服務(wù)類應(yīng)用，往往部署在多個服務(wù)器上，而一個請求，也會被切分為多個子任務(wù)在這些服務(wù)器上并發(fā)執(zhí)行。因此，請求的響應(yīng)時間，取決于反應(yīng)最慢的服務(wù)器，稱為瓶頸服務(wù)器。
[0008](2)客戶端用戶請求變化:客戶端用戶請求量會周期性變化，例如搜索引擎，白天訪問量大而晚上訪問量小，工作日訪問量大而周末訪問量?。涣硗?，客戶端用戶請求量也會因為一些事件而變化，例如電子商務(wù)，訪問量會因為促銷活動而在一段時間內(nèi)突然變大，從而導(dǎo)致對節(jié)點資源的使用情況發(fā)生變化。
[0009](3)服務(wù)器端資源使用狀況變化:服務(wù)器端會周期性的有一些更新和維護的活動，從而影響其資源使用狀況。例如，搜索引擎會定期更新服務(wù)器端的索引文件，在更新的過程中需要占用較多的CPU資源。
[0010]另外，在這種數(shù)據(jù)中心運行的分析類應(yīng)用通常有如下特征:
[0011](1)資源需求的多樣性:例如Hadoop上的分析類應(yīng)用，有高CPU計算資源需求的分析類應(yīng)用如K-means，也有高1/0資源需求的分析類應(yīng)用如排序算法。
[0012](2)資源間的共享、競爭、干擾:當(dāng)將這些應(yīng)用混合部署在同一個節(jié)點上時，不同的應(yīng)用間會共享、競爭資源，導(dǎo)致應(yīng)用性能下降。雖然當(dāng)前的虛擬機技術(shù)如Xen、Rainforest可以通過不同的操作系統(tǒng)實例，將CPU和內(nèi)存資源進行隔離，但是對于微體系結(jié)構(gòu)層的資源例如Cache、TLB、網(wǎng)絡(luò)帶寬、磁盤帶寬，應(yīng)用仍然會競爭資源。進一步，根據(jù)應(yīng)用特性的不同，會競爭不同的微體系結(jié)構(gòu)層的資源。例如,CPU密集型的k-means應(yīng)用主要競爭CPU相關(guān)微體系結(jié)構(gòu)資源如Cache和TLB ；I/O密集型的排序應(yīng)用主要競爭I/O相關(guān)微體系結(jié)構(gòu)資源如網(wǎng)絡(luò)和磁盤帶寬。因此k-means和排序應(yīng)用等分析類應(yīng)用會對在同一個節(jié)點上并行運行的服務(wù)類應(yīng)用造成不同的干擾。
[0013]綜上所述，如何考慮不同應(yīng)用的特征，以及它們在微體系結(jié)構(gòu)層對不同資源的競爭，是進行合理的資源調(diào)度和管理的關(guān)鍵問題。
[0014]現(xiàn)有的基于干擾意識的資源管理，是在應(yīng)用運行前，分析共存于同一個節(jié)點上的服務(wù)類應(yīng)用和分析類應(yīng)用之間的相互干擾，從而避免將干擾大的分析類應(yīng)用與服務(wù)類應(yīng)用放在同一個節(jié)點上。
[0015]例如文章“Bubble-Up:1ncreasing Utilizat1n in Modern Warehouse ScaleComputers via Sensible Co-locat1ns”,提出了一種性能干擾預(yù)測方法，具體如下:
[0016]首先，針對一個延遲敏感的服務(wù)類應(yīng)用，從LLC和內(nèi)存帶寬的角度，來度量在不同的負載壓力下應(yīng)用的性能；然后，選取一個分析類應(yīng)用，解析它在運行時對資源的競爭和干擾；通過前兩步的分析，預(yù)測該分析類應(yīng)用，對并行的服務(wù)類應(yīng)用性能的影響。最后將對服務(wù)類應(yīng)用性能干擾影響較小的分析類應(yīng)用與服務(wù)類應(yīng)用整合到同一個節(jié)點。
[0017]這種方法僅僅在應(yīng)用運行前，通過靜態(tài)資源管理的方式來避免對服務(wù)類應(yīng)用造成嚴重的干擾，沒有考慮服務(wù)類應(yīng)用負載的動態(tài)性，無法保證運行過程中服務(wù)類應(yīng)用的QoS，往往導(dǎo)致資源利用率低，用戶體驗差。因此，有必要提供一種新的資源管理方法解決上述問題。

【發(fā)明內(nèi)容】

[0018]有鑒于此，本發(fā)明提供了一種資源管理方法及裝置，能夠保證服務(wù)類應(yīng)用的QoS，提高資源的利用率。
[0019]第一方面，本發(fā)明實施例提供的資源管理方法應(yīng)用于資源管理系統(tǒng)，所述資源管理系統(tǒng)中分布有至少兩個物理節(jié)點，每個物理節(jié)點上運行有服務(wù)類應(yīng)用及分析類應(yīng)用，所述方法包括:
[0020]檢測所述服務(wù)類應(yīng)用的服務(wù)質(zhì)量QoS是否滿足QoS閾值；
[0021]若不滿足，則在所述資源管理系統(tǒng)中檢測所述服務(wù)類應(yīng)用的瓶頸節(jié)點，所述瓶頸節(jié)點指的是針對請求響應(yīng)時間最長的服務(wù)類應(yīng)用所在的物理節(jié)點；
[0022]確定所述服務(wù)類應(yīng)用的待補充資源；
[0023]在所述瓶頸節(jié)點中查找對所述服務(wù)類應(yīng)用在所述待補充資源上干擾度最大的分析類應(yīng)用，將查找到的對所述服務(wù)類應(yīng)用在所述待補充資源上干擾度最大的分析類應(yīng)用占用的所述待補充資源分配給所述服務(wù)類應(yīng)用，以使得所述服務(wù)類應(yīng)用的QoS滿足所述QoS閾值。
[0024]結(jié)合第一方面，在第一方面的第一種實施方式中，所述方法還包括:
[0025]檢測運行在各個物理節(jié)點上的所述服務(wù)類應(yīng)用是否有空閑資源；
[0026]若任意一個物理節(jié)點上運行的所述服務(wù)類應(yīng)用有空閑資源，則在所述物理節(jié)點上查找對所述服務(wù)類應(yīng)用在所述空閑資源上干擾度最小的分析類應(yīng)用，在保證所述服務(wù)類應(yīng)用的QoS滿足所述QoS閾值的前提下，將所述空閑資源分配給對所述服務(wù)類應(yīng)用在所述空閑資源上干擾度最小的分析類應(yīng)用。
[0027]結(jié)合第一方面的第一種實施方式，在第一方面的第二種實施方式中，在檢測所述服務(wù)類應(yīng)用的服務(wù)質(zhì)量QoS是否滿足QoS閾值之前，所述方法還包括:
[0028]檢測每個物理節(jié)點上的每個分析類應(yīng)用對所述服務(wù)類應(yīng)用在每類資源上的干擾度，每個分析類應(yīng)用對所述服務(wù)類應(yīng)用在每類資源上的干擾度指的是:調(diào)整每個分析類應(yīng)用單位數(shù)量的每類資源所造成的所述服務(wù)類應(yīng)用的響應(yīng)時間變化值。
[0029]結(jié)合第一方面的第二種實施方式，在第一方面的第三種實施方式中，所述每類資源包括中央處理器CPU資源和輸入/輸出I/O資源；
[0030]所述確定所述服務(wù)類應(yīng)用的待補充資源具體為:
[0031]檢測所述服務(wù)類應(yīng)用的CPU資源和I/O資源的利用率是否大于預(yù)設(shè)閾值，若所述服務(wù)類應(yīng)用的CPU資源和/或I/O資源的利用率大于所述預(yù)設(shè)閾值，則確定所述CPU資源和/或I/o資源為所述待補充資源。
[0032]結(jié)合第一方面的第二種實施方式，在第一方面的第四種實施方式中，所述每類資源包括中央處理器CPU資源和輸入/輸出I/O資源；
[0033]所述檢測運行在各個物理節(jié)點上的所述服務(wù)類應(yīng)用是否有空閑資源具體為:
[0034]檢測各個物理節(jié)點上的所述服務(wù)類應(yīng)用的CPU資源和I/O資源的利用率是否小于或等于所述預(yù)設(shè)閾值，若所述服務(wù)類應(yīng)用的CPU資源和/或I/O資源的利用率小于或等于所述預(yù)設(shè)閾值，則確定所述CPU資源和/或I/O資源為所述空閑資源。
[0035]第二方面，本發(fā)明實施例提供了一種源管理裝置，所述資源管理裝置應(yīng)用于資源管理系統(tǒng)，所述資源管理系統(tǒng)中分布有至少兩個物理節(jié)點，每個物理節(jié)點上運行有服務(wù)類應(yīng)用及分析類應(yīng)用，所述裝置包括:
[0036]第一檢測單元，用于檢測所述服務(wù)類應(yīng)用的服務(wù)質(zhì)量QoS是否滿足QoS閾值；
[0037]第二檢測單元，用于在所述服務(wù)類應(yīng)用的QoS不滿足所述QoS閾值時，在所述資源管理系統(tǒng)中檢測所述服務(wù)類應(yīng)用的瓶頸節(jié)點，所述瓶頸節(jié)點指的是針對請求響應(yīng)時間最長的服務(wù)類應(yīng)用所在的物理節(jié)點；
[0038]確定單元，用于確定所述服務(wù)類應(yīng)用的待補充資源；
[0039]第一調(diào)整單元，用于在所述瓶頸節(jié)點中查找對所述服務(wù)類應(yīng)用在所述待補充資源上干擾度最大的分析類應(yīng)用，將查找到的對所述服務(wù)類應(yīng)用在所述待補充資源上干擾度最大的分析類應(yīng)用占用的所述待補充資源分配給所述服務(wù)類應(yīng)用，以使得所述服務(wù)類應(yīng)用的QoS滿足所述QoS閾值。
[0040]結(jié)合第二方面，在第二方面的第一種實施方式中，所述裝置還包括:
[0041]第三檢測單元，用于檢測運行在各個物理節(jié)點上的所述服務(wù)類應(yīng)用是否有空閑資源；
[0042]第二調(diào)整單元，用于在任意一個物理節(jié)點上運行的所述服務(wù)類應(yīng)用有空閑資源時，在所述物理節(jié)點上查找對所述服務(wù)類應(yīng)用在所述空閑資源上干擾度最小的分析類應(yīng)用，在保證所述服務(wù)類應(yīng)用的QoS滿足所述QoS閾值的前提下，將所述空閑資源分配給對所述服務(wù)類應(yīng)用在所述空閑資源上干擾度最小的分析類應(yīng)用。
[0043]結(jié)合第二方面的第一種實施方式，在第二方面的第二種實施方式中，所述裝置還包括:
[0044]第四檢測單元，用于在所述第一檢測單元檢測所述服務(wù)類應(yīng)用的QoS是否滿足QoS閾值之前，檢測每個物理節(jié)點上的每個分析類應(yīng)用