包云崗

(中國科學院計算技術(shù)研究所 北京 100190)

1 引 言

1.1 數(shù)據(jù)中心成為基礎(chǔ)設(shè)施

互聯(lián)網(wǎng)應(yīng)用如電子郵件、搜索、網(wǎng)絡(luò)購物、社交網(wǎng)絡(luò)、在線視頻、網(wǎng)絡(luò)地圖等已經(jīng)成為人們生活的一部分。這些應(yīng)用往往要為上億用戶服務(wù)，意味著互聯(lián)網(wǎng)應(yīng)用已變成如電力一樣的社會公共服務(wù)，而支撐擁有海量用戶互聯(lián)網(wǎng)應(yīng)用的數(shù)據(jù)中心也成為如同發(fā)電廠一樣的社會核心基礎(chǔ)設(shè)施。

典型的數(shù)據(jù)中心一般由 5 萬～10 萬臺中低端服務(wù)器組成，這些服務(wù)器通過內(nèi)部網(wǎng)絡(luò)互連，一起協(xié)同運行，為海量用戶服務(wù)。因為這類數(shù)據(jù)中心規(guī)模很大，往往部署在大型倉庫級別的機房，從應(yīng)用角度來看就如同一臺計算機，因此也被稱為“倉庫級計算機(Warehouse-scale Computer)”[1]。國內(nèi)外著名的互聯(lián)網(wǎng)公司往往擁有多個數(shù)據(jù)中心，服務(wù)器數(shù)量達到數(shù)十萬甚至上百萬臺。例如，谷歌(Google)公司的數(shù)據(jù)中心服務(wù)器數(shù)量已經(jīng)超過百萬臺，為全球用戶提供搜索、郵件、地圖等服務(wù)[2]；亞馬遜(Amazon)公司僅EC2 就部署了約 50 萬臺服務(wù)器，用以提供云計算服務(wù)[3]；據(jù)可靠消息，國內(nèi)騰訊公司也擁有約 30 萬臺服務(wù)器，為用戶提供各種互聯(lián)網(wǎng)服務(wù)。

盡管目前互聯(lián)網(wǎng)企業(yè)的數(shù)據(jù)中心已經(jīng)頗具規(guī)模，但一個趨勢是未來數(shù)據(jù)中心還將持續(xù)發(fā)展。一方面，互聯(lián)網(wǎng)用戶數(shù)量仍在不斷增長，目前全球已有 24 億網(wǎng)絡(luò)用戶，很多機構(gòu)預(yù)測未來全球還將新增 30 億網(wǎng)民融入互聯(lián)網(wǎng)[4]，這對數(shù)據(jù)中心的數(shù)量和規(guī)模的需求都將加大。另一方面，快速發(fā)展的移動終端已超越個人計算機(PC)成為終端計算設(shè)備的主流。由于移動設(shè)備性能相對較低、存儲容量較小，將計算與存儲轉(zhuǎn)移到數(shù)據(jù)中心的需求也變得越來越強烈。在這些需求的推動下，不僅企業(yè)不斷擴大其數(shù)據(jù)中心規(guī)模，各地政府也開始建立各自的云計算中心(如山東云計算中心)，將一些政務(wù)、稅收等數(shù)據(jù)逐步遷移到數(shù)據(jù)中心。因此數(shù)據(jù)中心作為基礎(chǔ)設(shè)施的重要性也會日益凸顯，其地位甚至可能上升到國家戰(zhàn)略層面。

1.2 數(shù)據(jù)中心設(shè)計與運營維護的核心理念

低成本是數(shù)據(jù)中心設(shè)計的最核心理念，這是由互聯(lián)網(wǎng)時代的商業(yè)模式所決定的——很多互聯(lián)網(wǎng)公司的服務(wù)是免費的，通過免費服務(wù)吸引用戶以獲取廣告收入。雖然設(shè)計原則是低成本，但因為數(shù)據(jù)中心規(guī)模巨大，典型的 5 萬～10 萬臺服務(wù)器的數(shù)據(jù)中心成本高達到 10 億人民幣(1.5 億美元)[5]。對于擁有數(shù)十萬臺服務(wù)器的互聯(lián)網(wǎng)公司，其數(shù)據(jù)中心成本會達成幾十億甚至上百億人民幣。比如京東最近宣布在內(nèi)蒙古自治區(qū)巴彥淖爾市和江蘇省宿遷市建立云計算中心，每個中心容納 10 萬～15 萬臺服務(wù)器，投資總額高達 40 億元。

因而，如何降低成本、提高資源利用率是數(shù)據(jù)中心的設(shè)計、運行與維護(運維)的核心目標。一般而言，主要有兩種技術(shù)路線來降低成本：

(1)綜合考慮性能、功耗與成本，選擇性價比最高的服務(wù)器。

以運行數(shù)據(jù)庫基準測試集 TPC-C 為例，為了提供更大容量的內(nèi)存、可靠性等，高端服務(wù)器處理事務(wù)的單價是低端服務(wù)器的 20 倍[1]。Google 等互聯(lián)網(wǎng)公司都是采購低端服務(wù)器。為了進一步節(jié)省軟件成本，企業(yè)甚至會定制或開發(fā)自己的系統(tǒng)軟件棧，包括操作系統(tǒng)、存儲系統(tǒng)、數(shù)據(jù)庫等。如，Google 公司的BigTable、MapReduce，國內(nèi)淘寶公司的 TFS 文件系統(tǒng)，騰訊公司的存儲系統(tǒng)等。

(2)采用資源共享的方式提高數(shù)據(jù)中心資源利用率。對于價值幾十上百億規(guī)模的數(shù)據(jù)中心，即使提高1% 的資源利用率也能帶來非?？捎^的效益[6]。資源共享是提高利用率最有效的方式。以 Google 公司的數(shù)據(jù)中心為例，其中同時運行了各種應(yīng)用，如 Gmail郵件服務(wù)、街景地圖(Street View)、科學計算等。最近哥倫比亞大學的研究人員對 Google 公司的數(shù)據(jù)中心進行分析后，發(fā)現(xiàn)有超過 1100 個應(yīng)用同時在一個數(shù)據(jù)中心內(nèi)部運行[6]。除了企業(yè)內(nèi)部應(yīng)用共享數(shù)據(jù)中心，將資源以某種形式出租給用戶也是一種共享模式，即云計算模式。這種云計算模式不僅能節(jié)省成本，還開辟了新的商業(yè)模式，能為企業(yè)帶來巨大的收益。如 Amazon EC2 數(shù)據(jù)中心約有 50 萬臺服務(wù)器，2013 年度預(yù)計營業(yè)額已達到 38 億美元[7]，遠高于 50臺服務(wù)器的成本。

表1 服務(wù)響應(yīng)時間對用戶行為、企業(yè)收入的影響[8]

總結(jié)而言，為了追求低成本目標，數(shù)據(jù)中心在設(shè)計階段采用性價比高的硬件設(shè)備來降低采購成本與管理成本，在運營與維護時則采用資源共享方式提高資源利用率。

1.3 應(yīng)用服務(wù)質(zhì)量(QoS)成為制約數(shù)據(jù)中心資源利用率的關(guān)鍵因素

盡管通過資源共享方式能顯著提高數(shù)據(jù)中心利用率，但共享同時也會帶來應(yīng)用之間相互干擾問題，這種干擾會嚴重影響許多延遲敏感型應(yīng)用的服務(wù)質(zhì)量(Quality of Service，QoS)，如搜索、在線購物等。

1.3.1 服務(wù)質(zhì)量是互聯(lián)網(wǎng)應(yīng)用的關(guān)鍵指標

活躍用戶數(shù)與用戶訪問量是影響互聯(lián)網(wǎng)公司營收的主要因素?；ヂ?lián)網(wǎng)公司一般都采用免費服務(wù)吸引用戶，快速的服務(wù)響應(yīng)時間是讓用戶滿意、留住用戶的關(guān)鍵，也是衡量服務(wù)質(zhì)量的關(guān)鍵。有研究表明，如果服務(wù)響應(yīng)時間增加，公司收入就會減少。2009 年微軟在 Bing 搜索引擎上開展測試服務(wù)響應(yīng)時間對收入影響的實驗[8]。如表 1 所示，當服務(wù)響應(yīng)時間為 200 ms時，用戶點擊下一個鏈接的時間也變長，用戶的點擊數(shù)與滿意度都在下降。當服務(wù)響應(yīng)時間增加到 2000 ms時，用戶滿意度下降了 3.8%，而每個用戶帶給企業(yè)的收益下降了 4.3%。由于這個實驗結(jié)果對公司產(chǎn)生了負面影響，最終不得不永久終止實驗[8]。

由此可見，應(yīng)用服務(wù)質(zhì)量對互聯(lián)網(wǎng)企業(yè)以及云計算中心都至關(guān)重要。事實上，應(yīng)用服務(wù)質(zhì)量也正是很多互聯(lián)網(wǎng)企業(yè)對數(shù)據(jù)中心運維工程師業(yè)績考核的核心指標之一。為了讓用戶有更好的體驗，許多公司采用各種技術(shù)減少服務(wù)響應(yīng)時間，提高服務(wù)質(zhì)量，例如Google 公司甚至提出千兆網(wǎng)入戶方案。

1.3.2 應(yīng)用服務(wù)質(zhì)量與資源利用率之間的矛盾

如前所述，資源共享方式能提高數(shù)據(jù)中心利用率，但我們的一些實驗數(shù)據(jù)初步揭示了“資源共享會影響應(yīng)用服務(wù)質(zhì)量”的現(xiàn)象。如圖 1 所示，在一臺部署了 Web 服務(wù)的機器上，當同時訪問 events.php 網(wǎng)頁的用戶數(shù)從 600 增加到 1200 時，CPU 利用率從 10%增加到 20%。對比相應(yīng)的請求響應(yīng)時間分布曲線(紅色與綠色)，雖然請求的平均響應(yīng)時間并沒有明顯增加，但在 1200 個用戶時出現(xiàn)了明顯的長尾延遲現(xiàn)象(Long Tail Latency)，即曲線右側(cè)比重增加。

在數(shù)據(jù)中心中，各種不同類型的應(yīng)用會混合部署在一起。為了模擬數(shù)據(jù)中心環(huán)境，我們在 1200 個用戶的基礎(chǔ)上又運行一個 MapReduce 數(shù)據(jù)分析應(yīng)用。此時 CPU 利用率提高到 100%，但是 web 服務(wù)的請求響應(yīng)時間的長尾延遲更加顯著(藍色曲線)。圖 1 右邊顯示了對 addEventResult.php 網(wǎng)頁的訪問的實驗數(shù)據(jù)，因為涉及數(shù)據(jù)庫與磁盤 I/O 操作，干擾也變得更加嚴重。從上述實驗可見：資源利用率與應(yīng)用服務(wù)質(zhì)量之間存在矛盾——資源利用率提高卻導(dǎo)致應(yīng)用服務(wù)質(zhì)量下降，響應(yīng)時間出現(xiàn)長尾延遲現(xiàn)象。另一個角度而言，為了保障服務(wù)質(zhì)量，不得不限制資源利用率過高，亦即“應(yīng)用服務(wù)質(zhì)量會制約資源利用率的提高”。

1.3.3 數(shù)據(jù)中心會放大長尾延遲現(xiàn)象、降低服務(wù)質(zhì)量

更嚴重的是，上述長尾延遲現(xiàn)象在數(shù)據(jù)中心環(huán)境下會被進一步放大。這是因為互聯(lián)網(wǎng)應(yīng)用已經(jīng)被分解為許多服務(wù)，這些服務(wù)部署到數(shù)據(jù)中心的大規(guī)模服務(wù)器上。一般而言，服務(wù)之間的耦合方式有兩種[9]，但兩種模式都會放大長尾延遲現(xiàn)象：

圖1 Web Server 請求響應(yīng)時間在共享環(huán)境下的變化

(1)劃分/聚合模式(Partition/Aggregate)。有些互聯(lián)網(wǎng)應(yīng)用如 Google、百度搜索，每個用戶請求涉及TB 級別甚至更大規(guī)模的數(shù)據(jù)訪問，這些數(shù)據(jù)分布存儲在成千上萬臺服務(wù)器。因此完成一個請求需要訪問上千臺機器，具有很大的扇出(fan-out)。這種場景下，請求的響應(yīng)時間取決于最慢的那臺服務(wù)器。Google 公司的 Jeff Dean 在 2012 年 Berkeley 的報告[10]中就指出了長尾現(xiàn)象的嚴重性。假設(shè)一臺機器處理請求的平均響應(yīng)時間為 1 ms，有 1% 的請求處理時間會大于 1 s(99th-Percentile)。如果一個請求需要由 100個這樣的節(jié)點一起處理，那么就會出現(xiàn) 63% 的請求響應(yīng)時間大于 1 s。

(2)依賴/串行模式(Dependent/Sequential)。這些互聯(lián)網(wǎng)應(yīng)用代表是 Facebook 社交網(wǎng)絡(luò)，Amazon 和淘寶的在線購物等，這些應(yīng)用處理用戶請求需要依次訪問一系列有依賴的服務(wù)，才能最終得到結(jié)果返回給用戶。比如，淘寶的在線購物應(yīng)用接收到一個用戶請求，會先獲取用戶的個人信息，然后得到購物歷史記錄，再根據(jù)歷史記錄調(diào)用推薦系統(tǒng)等。在這種模式下，服務(wù)都在關(guān)鍵路徑上，因此每個服務(wù)的處理延遲會累加。正是由于這種累加效應(yīng)，F(xiàn)acebook 限制每個網(wǎng)頁的處理不能訪問超過 150 個服務(wù)[9]。

這兩種模式都會導(dǎo)致處理一個請求需要訪問多臺服務(wù)器，因而只要有一臺服務(wù)器的處理速度受到干擾，就會導(dǎo)致整個請求的處理時間增加。由于一個請求處理的全生命周期里會涉及成百上千臺服務(wù)器，因此如何保障請求全生命周期的服務(wù)質(zhì)量成為數(shù)據(jù)中心環(huán)境下的新挑戰(zhàn)。

1.4 實例分析：Google 數(shù)據(jù)中心以及其他互聯(lián)網(wǎng)企業(yè)的現(xiàn)狀

Google 公司的數(shù)據(jù)中心技術(shù)一直處于領(lǐng)先地位，我們以 Google 為例分析其數(shù)據(jù)中心資源利用率與應(yīng)用服務(wù)質(zhì)量的現(xiàn)狀。圖 2 顯示了 2006 年 Google 數(shù)據(jù)中心 5000 臺服務(wù)器 6 個月的 CPU 利用率統(tǒng)計[1]，其資源利用率并不高，整個數(shù)據(jù)中心的平均 CPU 利用率僅為 30% 左右。此時較低的資源利用率主要由于單個服務(wù)器資源有限，單個應(yīng)用就會占有大部分資源，導(dǎo)致無法滿足其他應(yīng)用需求，即所謂的“裝包問題(Bin-Packing)”[1]：因為包太小而只能裝一樣物品。在這種場景下，實際上每臺服務(wù)器處于獨占狀態(tài)，鮮有應(yīng)用間干擾現(xiàn)象。

隨著處理器芯片內(nèi)的核數(shù)目不斷增加，單服務(wù)器節(jié)點內(nèi)的核數(shù)目也在增加。如，2012 年 Google 的單服務(wù)器節(jié)點已有 12 個核、24 線程(啟用 Intel 超線程技術(shù))[6]。單節(jié)點已有足夠資源，可有效地緩解資源分配時遇到的裝包問題，在不考慮服務(wù)質(zhì)量的情況下，可以將多個應(yīng)用部署到同一個節(jié)點以提高資源利用率。如圖 3 所示，2012 年 Google 的 1000 臺服務(wù)器平均已能達到 50% 以上的 CPU 利用率，比 2006 年有顯著提高，但卻帶來了嚴峻的應(yīng)用服務(wù)質(zhì)量問題。而圖 4(b)顯示，2013 年 1～3 月 Google 數(shù)據(jù)中心 2 萬臺離線作業(yè)服務(wù)器的 CPU 利用率高達 75%。

圖2 2006 年 Google 數(shù)據(jù)中心 5000 臺服務(wù)器 6 個月的 CPU 利用率分布[1]

圖3 2012 年 Google 數(shù)據(jù)中心 1000 臺 24 線程服務(wù)器的 CPU 利用率 [6]

但是，長尾延遲導(dǎo)致的服務(wù)質(zhì)量問題依然沒有解決。Google 的 Jeff Dean 與 Luiz Barroso 在 2013 年2 月的《Communication of the ACM》上就專門撰文“The Tail at Scale”[11]，闡述了在數(shù)據(jù)中心的長尾延遲問題。他們分析了導(dǎo)致長尾延遲的首要原因是資源共享，包括體系結(jié)構(gòu)層次的 CPU 核、Cache、訪存帶寬、網(wǎng)絡(luò)帶寬等，而干擾不僅來自應(yīng)用，還來自系統(tǒng)軟件層次的后臺守護作業(yè)、監(jiān)控作業(yè)、共享文件系統(tǒng)等。

Dean 與 Barroso 在參考文獻[11]中介紹了 Google采用的緩解長尾延遲的技術(shù)，包括操作系統(tǒng)容器隔離技術(shù)[12]、應(yīng)用優(yōu)先級管理[13]、備份請求[10]、同步后臺管理進程[10]等，取得了一定的效果，但仍無法避免資源共享對應(yīng)用服務(wù)質(zhì)量的負面影響。如圖 5 所示，一些延遲敏感型應(yīng)用(如街景地圖 Streetview)的性能仍有較大幅度的波動[6]。因此，在實際部署中，對于那些關(guān)鍵的在線應(yīng)用，CPU 利用率仍然只有 30% 左右(見圖 4(a))。

對于其他互聯(lián)網(wǎng)企業(yè)，在資源利用率與服務(wù)質(zhì)量之間不得不二選一。為了保障應(yīng)用服務(wù)質(zhì)量，很多企業(yè)放棄將多個應(yīng)用混合部署的方案。據(jù)調(diào)研，國內(nèi)主流互聯(lián)網(wǎng)企業(yè)的在線應(yīng)用都采用獨占數(shù)據(jù)中心的方式，其數(shù)據(jù)中心資源利用率一般在 10%～30%，與Google 的 50%～60% 利用率相比仍有不少的差距。相反，Amazon EC2 為了提高數(shù)據(jù)中心資源利用率，在其條款上直接聲明不向用戶承諾服務(wù)質(zhì)量。因此有研究發(fā)現(xiàn)相同的程序在 Amazon EC2 上運行多次，性能波動幅度會比本地機群高一個數(shù)量級[15]，性能不可預(yù)測。

技術(shù)發(fā)展的趨勢是處理器內(nèi)部的核數(shù)目仍會不斷增加，一些研究人員甚至已經(jīng)開始關(guān)注片上數(shù)據(jù)中心(On-Chip Datacenters)[16]。因此單節(jié)點內(nèi)資源將越來越多，意味著必然會有更多應(yīng)用同時在一個節(jié)點內(nèi)運行，干擾會越來越嚴重，應(yīng)用性能波動幅度也會隨之不斷擴大，嚴重影響應(yīng)用服務(wù)質(zhì)量。而資源利用率與服務(wù)質(zhì)量關(guān)系密切，以單機為例，虛擬化技術(shù)能有效地解決應(yīng)用之間的資源隔離(但仍未解決性能隔離問題)，使多個虛擬機能部署到一臺機器，實現(xiàn)物理資源共享，提高利用率。因此，如果數(shù)據(jù)中心環(huán)境下無法做到性能隔離以保障服務(wù)質(zhì)量，最終很可能不得不采用限制數(shù)據(jù)中心資源利用率以避免服務(wù)質(zhì)量的不可控。我們預(yù)計：保障應(yīng)用服務(wù)質(zhì)量將成為數(shù)據(jù)中心核心技術(shù)之一。而軟件定義網(wǎng)絡(luò)(Software Defined Networking)興起正印證這個趨勢。

2 國內(nèi)外相關(guān)工作

圖4 Google 數(shù)據(jù)中心2013 年 1 至 3 月運行在線應(yīng)用的 CPU 利用率平均為 30%(a)，離線作業(yè)數(shù)據(jù)中心的 CPU利用率為 75%(b)[14]

圖5 2012 年 Google 數(shù)據(jù)中心應(yīng)用性能存在波動性[6]

為了保障數(shù)據(jù)中心全生命周期服務(wù)質(zhì)量，需要從服務(wù)器節(jié)點內(nèi)部、服務(wù)器之間通信以及分布式架構(gòu)多個層次協(xié)同工作。近年來，學術(shù)界、工業(yè)界在這三個層次都不斷努力。如近年流行的 Software Defined Networking(SDN)技術(shù)[17]，其目標就是為了解決數(shù)據(jù)中心網(wǎng)絡(luò)通信的管理、共享與性能隔離問題。Google在分布式架構(gòu)上采用了超時發(fā)送備份請求同步后臺管理進程等技術(shù)[18]對改善“劃分/聚合”模式應(yīng)用的長尾延遲有幫助，但并不能顯著改善“依賴/串行”模式應(yīng)用的響應(yīng)時間。此外，單節(jié)點內(nèi)服務(wù)質(zhì)量保障技術(shù)已成為短板。現(xiàn)在主流的軟件隔離技術(shù)能對資源容量隔離起到較好的效果，但無法保障性能隔離，無法保障服務(wù)質(zhì)量。

總的來說，國內(nèi)外在保障應(yīng)用服務(wù)質(zhì)量方面的研究包括單節(jié)點與分布式環(huán)境兩個方面。以下分別介紹這兩個方面的相關(guān)工作。

2.1 單機保障服務(wù)質(zhì)量研究

單機保障服務(wù)質(zhì)量研究的相關(guān)技術(shù)包括軟件資源隔離技術(shù)、軟硬件調(diào)度技術(shù)、硬件支持等。

軟件資源隔離技術(shù)：針對數(shù)據(jù)中心里多個應(yīng)用相互干擾的問題，一般采取虛擬化手段在資源共享的條件下保障資源隔離，如虛擬機技術(shù) Xen[19]或 Linux Container[20]。

傳統(tǒng)虛擬機技術(shù)通過將多臺虛擬機 VM 部署到物理機上，每臺虛擬機運行一個應(yīng)用或應(yīng)用的一個組件，每個應(yīng)用在自己的操作系統(tǒng)環(huán)境中獨立運行，減少相互干擾。但這些隔離主要是資源的隔離，而無法實現(xiàn)性能隔離，如，為不同應(yīng)用分配不同的訪存帶寬。并且，使用虛擬機也會帶來一定的性能損失[21]，增加延遲，帶來性能波動。

Linux Container[20]是一種輕量級虛擬化，通過在操作系統(tǒng)層面增添虛擬服務(wù)器功能，操作系統(tǒng)內(nèi)核能夠提供多個互相獨立的用戶態(tài)實例。每個用戶態(tài)實例對于它自己的用戶來說都像是一臺獨立的計算機，有自己獨立的網(wǎng)絡(luò)、文件系統(tǒng)、庫函數(shù)和系統(tǒng)設(shè)置等。操作系統(tǒng)級虛擬化技術(shù)的優(yōu)點是性能開銷較小，不需要硬件的特別支持，而且能為用戶態(tài)實例之間提供一定的隔離性，所以被廣泛地應(yīng)用在虛擬主機服務(wù)器環(huán)境中。然而，容器虛擬化技術(shù)的虛擬對象不是實際的物理資源(處理器、內(nèi)存和外設(shè))，而是從用戶角度出發(fā)的抽象操作系統(tǒng)內(nèi)部資源，如 CPU 時間、內(nèi)存、I/O 帶寬等。在性能隔離方面也有相關(guān)研究，Rice 大學的 Druschel 等人[22]設(shè)計了 Resource Container 系統(tǒng)，實現(xiàn)了單臺物理機上多個應(yīng)用間的性能隔離和 CPU細粒度資源分配機制支持。然而局部隔離并不能保證全局隔離，Druschel 等人又設(shè)計了 Cluster Container系統(tǒng)[23]，以解決應(yīng)用在集群范圍內(nèi)的隔離問題。但十幾年前單機核數(shù)目非常小，如今單節(jié)點已經(jīng)有幾十個核，同時運行的應(yīng)用也增加了一個數(shù)量級。

頁著色(Page Coloring)[24]是一種以軟件方式控制內(nèi)存物理頁映射到處理器緩存上的技術(shù)，映射到同一緩存塊中的物理頁對應(yīng)同一顏色?；陧撝夹g(shù)可以實現(xiàn)對共享二級緩存的劃分(Partition)[25]，能緩解應(yīng)用在共享二級緩存上的干擾。Cho 等人[26]使用 Page Coloring 技術(shù)來管理共享緩存，Tam 等人[27]在 Linux內(nèi)核上實現(xiàn)了基于頁面著色的緩存劃分策略。而對于DRAM 系統(tǒng)，也可以使用頁著色技術(shù)對共享 DRAM顆粒進行劃分[28-30]，Liu 等人[31]在 Linux 內(nèi)核上實現(xiàn)了基于頁著色的 DRAM 顆粒劃分。北京大學李曉明教授團隊也在這方面做了很多工作[32-34]，研究利用頁著色技術(shù)在虛擬環(huán)境下對共享 Cache 進行了劃分。頁著色技術(shù)能緩解一些粗粒度共享資源層次的干擾，但無法解決微體系結(jié)構(gòu)的干擾，比如共享隊列等，并且使用不靈活。總結(jié)而言，軟件隔離技術(shù)能對資源容量隔離起到較好的效果，但無法保障性能隔離，無法保障服務(wù)質(zhì)量。

軟硬件調(diào)度技術(shù)：在多核微體系結(jié)構(gòu)上，由于共享片上和片外資源的競爭會引起跨核應(yīng)用之間的干擾。Mars 和 Vachharajani 等人提出了競爭感知的輕量級運行時環(huán)境 CAER[35]，能在提高利用率的同時減少由競爭引起的跨核干擾問題。他還和 Tang 等人在參考文獻[36]中介紹了 CiPE 框架，可以直接用于測量和量化多核結(jié)構(gòu)下應(yīng)用的跨核干擾敏感度。Mars 等人還設(shè)計了 Bubble-Up[37]機制，通過使用氣泡(Bubble)來代表內(nèi)存子系統(tǒng)的可變壓力情況，能準確預(yù)測在內(nèi)存子系統(tǒng)中競爭共享資源而導(dǎo)致的性能下降。Tang 等人在參考文獻[38]中提出了一種動靜結(jié)合的編譯方法 ReQos，在確保高優(yōu)先級應(yīng)用的服務(wù)質(zhì)量的同時讓低優(yōu)先級應(yīng)用也可以自適應(yīng)地執(zhí)行。ReQoS包含一種由配置文件引導(dǎo)的編譯技術(shù)，來識別低優(yōu)先級應(yīng)用中有爭議的代碼段。這些調(diào)度相關(guān)的工作在具有大規(guī)模真實應(yīng)用的 Google“混布”數(shù)據(jù)中心里，使用該機制能在保證延遲敏感性應(yīng)用的服務(wù)質(zhì)量的同時，能顯著提高 50%～90% 的資源利用率。但這些工作屬于 Ad-hoc 類型，針對特定場景有效，并沒有從根本上解決問題。

以 CMU 的 Onur Mutlu 為代表的一些學術(shù)界專家提出了一系列調(diào)度算法[39-41]以緩解內(nèi)存控制器的不公平問題，從而提高系統(tǒng)吞吐量以及服務(wù)質(zhì)量。但這些算法是固化的，并不能針對某個應(yīng)用進行調(diào)節(jié)，不具有靈活性。

體系結(jié)構(gòu)支持：Iyer 在參考文獻[42]中提出了一種保障 CMP 體系結(jié)構(gòu)上緩存 Qos 的管理框架，設(shè)計了 CQos 優(yōu)先級分類、優(yōu)先級分配和優(yōu)先級執(zhí)行。CQos 優(yōu)先級分類和優(yōu)先級分配采用的是從用戶到開發(fā)人員驅(qū)動的編譯檢測和基于流的方法。CQos 優(yōu)先級執(zhí)行則包括(1)選擇高速緩存分配；(2)動靜態(tài)結(jié)合設(shè)置分區(qū)；(3)異構(gòu)緩存區(qū)域。實驗結(jié)果表明，CQoS在多線程或多核平臺上能提高共享緩存的效率和系統(tǒng)性能。然而，Iyer 并沒有詳細描述保障 CMP 體系結(jié)構(gòu)上緩存 Qos 的具體策略和軟硬件支持。在參考文獻[43]中，Iyer 等人又再實現(xiàn)了一種在 CMP 平臺上保障 Qos 的內(nèi)存體系結(jié)構(gòu)，允運行時的動態(tài)資源再分配，能在減少低優(yōu)先級應(yīng)用性能下降的同時優(yōu)化高優(yōu)先級應(yīng)用的性能。Herdrich 等人[44]證明了用于功耗管理的基于速率(rate-based)技術(shù)能適應(yīng)于 CMP 結(jié)構(gòu)上緩存/內(nèi)存的 Qos 管理，其基本方法是當正在運行的低優(yōu)先級任務(wù)由于資源爭用而干擾了高優(yōu)先級任務(wù)的性能時，就減緩核心的處理速率。通過評估時鐘調(diào)制和頻率縮放這兩個速率限制機制，發(fā)現(xiàn)時鐘調(diào)制更適用于緩存/內(nèi)存 Qos 管理。

Iyer 在體系結(jié)構(gòu)支持服務(wù)質(zhì)量方面做了一些有價值的工作，但主要集中在內(nèi)存方面，并沒有從整個系統(tǒng)角度去考慮。我們認為這個方向在未來會越來越重要，值得深入研究。

2.2 分布式環(huán)境保障服務(wù)質(zhì)量

在分布式環(huán)境下，影響應(yīng)用服務(wù)質(zhì)量的因素主要是節(jié)點故障與干擾引起的長尾延遲，下面將從這兩個方面介紹相關(guān)優(yōu)化技術(shù)。

軟硬件故障：Dean 等人設(shè)計 MapReduce[45]的初衷是使用由成百上千機器組成的集群來處理超大規(guī)模數(shù)據(jù)，所以，要求 MapReduce 必須能很好地處理機器故障。MapReduce 采用了任務(wù)重新調(diào)度或重新執(zhí)行任務(wù)(backup task)的方法來解決節(jié)點故障或短暫忙碌。如果一個機器的硬盤出了問題，讀取數(shù)據(jù)的速度從 30 M/s 降低到 1 M/s，MapReduce 框架中將發(fā)送backup task 機制來減少這一類長尾延遲。Backup task機制通常只會占用比正常操作多幾個百分點的計算資源，但能顯著改善因為故障出現(xiàn)的長尾延遲。類似于TCP 重傳機制，backup task 的有效性會隨著負載的提高而削弱。

競爭共享資源引起的干擾：為了緩解干擾引起的長尾延遲現(xiàn)象，Dean 等人[11]介紹了 Google 采用的緩解長尾延遲的技術(shù)，包括操作系統(tǒng)容器隔離技術(shù)[12]、應(yīng)用優(yōu)先級管理[13]、備份請求[10]、同步后臺管理進程[10]等。Kapoor 等人在參考文獻[46]中提出了 Chronos 架構(gòu)，以降低數(shù)據(jù)中心應(yīng)用的長尾延遲。Chronos 基于 NIC 上應(yīng)用層數(shù)據(jù)包頭字段的請求劃分、應(yīng)用實例負載均衡和 NIC 負載均衡模塊的加載來消除關(guān)鍵通信路徑上的共享資源，如內(nèi)核和網(wǎng)絡(luò)協(xié)議棧，以減少應(yīng)用延遲以及相關(guān)干擾。

這些研究工作從分布式架構(gòu)上一定程度上緩解了“劃分/聚合”模式應(yīng)用的長尾延遲，但對“依賴/串行”模式應(yīng)用并不顯著。另一方面，隨著單個服務(wù)器節(jié)點的核數(shù)目不斷增加，甚至未來“片上數(shù)據(jù)中心”[16]出現(xiàn)，單節(jié)點內(nèi)同時運行的應(yīng)用也會增加，那么干擾將會越來越嚴重，僅僅依賴分布式架構(gòu)以及軟件方法將無法保障性能隔離。如何從硬件上支持服務(wù)質(zhì)量保障技術(shù)將是一個值得關(guān)注與研究的方向。

2.3 小 結(jié)

從現(xiàn)有技術(shù)來看，單節(jié)點內(nèi)服務(wù)質(zhì)量保障技術(shù)的不足，導(dǎo)致節(jié)點內(nèi)應(yīng)用相互干擾嚴重，這某種程度上已成為目前數(shù)據(jù)中心整體服務(wù)質(zhì)量保障的短板，是成為長尾延遲現(xiàn)象的主要因素之一。同時這也是一個非常具有挑戰(zhàn)的問題，需要跨層次協(xié)同設(shè)計。美國計算共同委員會(Computing Community Consortium)于 2012 年 5 月發(fā)布的計算機體系結(jié)構(gòu)共同體白皮書《21 世紀計算機體系結(jié)構(gòu)》中也將單節(jié)點內(nèi)保障服務(wù)質(zhì)量作為未來研究方向之一，其中認為[19]：“管理應(yīng)用之間的相互作用也帶來了挑戰(zhàn)。例如，這些應(yīng)用如何表達服務(wù)質(zhì)量(QoS)目標并且讓底層的硬件、操作系統(tǒng)以及虛擬層共同工作來保障它們?！?/p>

另一方面，數(shù)據(jù)中心應(yīng)用涉及成百上千個節(jié)點，保障節(jié)點內(nèi)應(yīng)用服務(wù)質(zhì)量僅僅是基礎(chǔ)，而如何在數(shù)據(jù)中心環(huán)境下保障應(yīng)用全局服務(wù)質(zhì)量也非常具有挑戰(zhàn)，需要在數(shù)據(jù)中心分布式環(huán)境下大規(guī)模節(jié)點協(xié)同保障才能實現(xiàn)，從分布式理論到系統(tǒng)設(shè)計多個層次均需考慮。

3 PARD：資源可編程體系結(jié)構(gòu)

針對上述數(shù)據(jù)中心面臨的挑戰(zhàn)，中國科學院計算技術(shù)研究所(中科院計算所)計算機體系結(jié)構(gòu)國家重點實驗室已經(jīng)開展了如何在數(shù)據(jù)中心環(huán)境下保障應(yīng)用服務(wù)質(zhì)量的相關(guān)研究。

首先，我們認同計算機體系結(jié)構(gòu)共同體白皮書《21 世紀計算機體系結(jié)構(gòu)》中的觀點——要實現(xiàn)性能隔離以保障應(yīng)用服務(wù)質(zhì)量，需要軟硬件協(xié)同工作。數(shù)據(jù)中心互連網(wǎng)絡(luò)技術(shù)已經(jīng)在資源管理、性能隔離、服務(wù)質(zhì)量等方面開展了一系列研究，軟件定義網(wǎng)絡(luò)SDN(Software Def i ned Networking)。能有效地解決不同網(wǎng)絡(luò)流之間的性能隔離，保障網(wǎng)絡(luò)服務(wù)質(zhì)量。SDN的主要思想是：(1)網(wǎng)絡(luò)數(shù)據(jù)包附上流標識(f l owid)；(2)將網(wǎng)絡(luò)路由器的數(shù)據(jù)面(Data Plane)與控制面(Control Plane)分離；(3)數(shù)據(jù)面只負責轉(zhuǎn)發(fā)請求，控制面可由軟件編程，這樣實現(xiàn)靈活高效地網(wǎng)絡(luò)管理。

受 SDN 的啟發(fā)，如圖 6 所示，我們可以將單節(jié)點看作是一個小網(wǎng)絡(luò)，內(nèi)存控制器、I/O 控制器等看作是網(wǎng)絡(luò)交換機，負責轉(zhuǎn)發(fā)處理器核、內(nèi)存和 I/O 設(shè)備之間的請求與數(shù)據(jù)包；運行在單節(jié)點上的多應(yīng)用同時產(chǎn)生的請求，可視為不同的網(wǎng)絡(luò)流。然而，在計算機節(jié)點內(nèi)部，許多資源仍然處于沒有管理的共享狀態(tài)，比如片內(nèi)共享緩存、共享內(nèi)存控制器、共享訪存帶寬等。

我們借鑒 SDN，提出了資源可編程體系結(jié)構(gòu)——PARD(Programmable Architecture of Resourcing on-Demand)。從某種角度來看，PARD 結(jié)構(gòu)屬于一種軟件定義體系結(jié)構(gòu) SDA(Software Def i ned Architecture)的范疇，是 SDA 的一個具體實現(xiàn)方案，其核心思想是：

(1)計算機內(nèi)的請求包與數(shù)據(jù)包附上標簽；

(2)將主要控制器(如內(nèi)存控制器)的數(shù)據(jù)面與控制面分離；

(3)數(shù)據(jù)面負責轉(zhuǎn)發(fā)請求與數(shù)據(jù)，控制面可由軟件編程，根據(jù)標簽實現(xiàn)資源分配、性能隔離。

PARD 技術(shù)希望通過硬件支持資源管理與軟件可編程相結(jié)合的方式，實現(xiàn)更高效靈活的資源共享與性能隔離。如果將計算機內(nèi)部的資源類比于城市交通系統(tǒng)。無 PARD 技術(shù)支持的計算機系統(tǒng)就如城市交通不設(shè)多個車道、不設(shè)紅路燈、不設(shè)交通規(guī)則，這會造成大量的沖突和混亂，也會導(dǎo)致關(guān)鍵車輛(如救護車、消防車等)通行無法得到保障。而 PARD 技術(shù)的目標，正如交通管理系統(tǒng)能在保障救護車等關(guān)鍵車輛順利通過的前提下提高道路利用率，針對多種應(yīng)用混合的數(shù)據(jù)中心，能在保障關(guān)鍵應(yīng)用的服務(wù)質(zhì)量前提下提高資源利用率。

圖6 從網(wǎng)絡(luò)互連角度看計算機結(jié)構(gòu)

圖7 內(nèi)存控制器圖

如圖 7 所示，以內(nèi)存控制器為例，我們將內(nèi)存控制器分為控制面與數(shù)據(jù)面。其中數(shù)據(jù)面負責傳統(tǒng)的包轉(zhuǎn)發(fā)，和內(nèi)存芯片交互；控制面則負責資源管理與控制，包括 QoS 優(yōu)先級、內(nèi)存容量、帶寬限制等。這些資源的管理與控制可由控制面的編程接口來訪問。所有訪存請求將賦予對象標簽 oid(Object id)，控制面中有一張控制表(Control Table)存儲基于 oid 索引的控制信息。因此，針對每一個訪存請求，控制面中邏輯可以根據(jù)該請求的 oid 獲取對應(yīng)的控制信息，進而做權(quán)限審查、帶寬控制等。軟件方面，控制面提供編程接口給軟件，操作系統(tǒng)可以通過編程接口對控制表進行修改。

目前本課題組已經(jīng)初步完成了 Cache 控制器、內(nèi)存控制器的設(shè)計與實現(xiàn)，并在模擬器平臺成功加載操作系統(tǒng)、啟動應(yīng)用程序，使操作系統(tǒng)能根據(jù)應(yīng)用需求來控制執(zhí)行優(yōu)先級以獲取相應(yīng)的資源。同時課題組也在基于 OpenSPARC 的 FPGA 仿真平臺上進一步驗證PARD 技術(shù)。

4 總 結(jié)

數(shù)據(jù)中心相關(guān)產(chǎn)業(yè)在全球已經(jīng)達到 1500 多億美元，并且在未來依然有很大的增長空間。Google 公司代表了世界領(lǐng)先的數(shù)據(jù)中心技術(shù)水平，但是依然面臨著資源利用率與應(yīng)用服務(wù)質(zhì)量之間的矛盾。數(shù)據(jù)顯示，2006 年在線應(yīng)用數(shù)據(jù)中心 CPU 利用率僅為30%，但到 2013 年依然沒有大的提高。對于動輒價值上十億美元的數(shù)據(jù)中心，即使提供 1% 的效率也有很客觀的收益。要解決資源利用率與應(yīng)用服務(wù)質(zhì)量之間的矛盾，需要計算機軟硬件協(xié)同設(shè)計，這也是計算機系統(tǒng)結(jié)構(gòu)研究的新機遇。

本課題組針對數(shù)據(jù)中心面臨的上述關(guān)鍵挑戰(zhàn)，提出的資源可編程體系結(jié)構(gòu) PARD 技術(shù)。PARD 技術(shù)提供一種新的體系結(jié)構(gòu)平臺。傳統(tǒng)計算機軟件與硬件交互的界面是指令集，一方面軟件基于指令集對低層結(jié)構(gòu)進行控制，另一方面指令集為軟件開發(fā)人員屏蔽了低層結(jié)構(gòu)細節(jié)。但隨著底層結(jié)構(gòu)越來越復(fù)雜，僅僅通過指令集已無法充分發(fā)揮低層結(jié)構(gòu)的效率，亟需一種新的軟硬件交互模式。而 PARD 提供了一個新的交互界面，當然，這其中帶來了很多新的問題，如交互效率、安全問題、分布式環(huán)境下擴展性等。目前本課題組正對基于模擬器與 FPGA 仿真平臺開展概念驗證工作，已取得初步進展，希望能與國內(nèi)工業(yè)界、學術(shù)界的同行們進行更多的交流合作。

[1]Hoelzle U, Barroso LA. The Datacenter as a Computer: an Introduction to the Design of Warehouse-scale Machines [M].Morgan and Claypool Publishers, 2009.

[2]Google throws open doors to its top-secret data center [EB/OL]. http://www.wired.com/wiredenterprise/2012/10/ffinside-google-data-center/all/.

[3]Steven J, Nichols V. Amazon EC2 cloud is made up of almost half-a-million Linux servers [EB/OL]. [2012-03-16]. http://www.zdnet.com/blog/open-source/amazon-ec2-cloud-is-made-up-ofalmost-half-a-million-linux-servers/10620.

[4]Diamandis P, Kotler S. Abundance: The Future is Better Than You Think [M]. Free Press, 2012.

[5]Patterson D, Hennessy J. Computer Architecture: A Quantitative Approach [M]. Morgan Kaufmann, 2011.

[6]Kambadur M, Moseley T, Hank T, et al. Measuring interference between live datacenter applications [C]// Proceedings of the International Conference on High Performance Computing,Networking, Storage and Analysis, 2011.

[7]Dignan L. Amazon’s AWS: $3.8 billion revenue in 2013 [EB/OL]. [2013-01-07]. http://www.zdnet.com/amazons-aws-3-8-billion-revenue-in-2013-says-analyst-7000009461/

[8]Schurman E, Brutlag J. The user and business impact of server delays [C]// Proceedings of Velocity: Web Performance and Operations Conference, 2009.

[9]Kapoor R, Porter G, Tewari M, et al. Chronos: predictable low latency for data centerapplications [C]// Proceedings of the 3rd ACM Symposium on Cloud Computing, 2012.

[10]Dean J. Achieving Rapid Response Times in Large Online Services [Z]. Berkeley, 2012.

[11]Dean J, Barroso L. The tail at scale [J]. Communication of the ACM, 2013, 56(2): 74-80.

[12]Cgroups [EB/OL]. http://en.wikipedia.org/wiki/Cgroups.

[13]Google cluster workload traces [EB/OL]. http://code.google.com/p/googleclusterdata/.

[14]Barrosa L, Clidaras J, Holzle U. The Datacenter as a Computer:An Introduction to the Design of Warehouse-Scale Machines [M].Morgan and Claypool Publishers, 2013.

[15]Schad J, Dittrich J, Quiané-Ruiz JA. Runtime measurements in the cloud: observing, analyzing, and reducing variance [J].Proceedings of the VLDB Endowment, 2010, 3(1-2): 460-471.

[16]Kas M. Towards on-chip datacenters: a perspective on general trends and on-chip particulars [J]. The Journal of Supercomputing, 2011, 62(1): 214-226.

[17]ONF. Software-Def i ned Networking: the New Norm for Networks[Z]. In Open Networking Foundation White Paper. 2012.

[18]Deshane T, Dimatos D, Hamilton G, et al. Performance Isolation of a Misbehaving Virtual Machine with Xen, VMware and Solaris Containers [Z]. Technical Report, 2007.

[19]Barham P, Dragovic B, Fraser K, et al. Xen and the art of virtualization [C]// Proceedings of the 19th ACM Symposium on Operating Systems Principles, 2003: 164-177.

[20]Linux Container(LXC)[EB/OL]. http://lxc.sourceforge.net/.

[21]Menon A, Santos JR, Turner Y, et al. Diagnosing performance overheads in the Xen virtual machine environment [C]//Proceedings of the 1st ACM/USENIX International Conference on Virtual Execution Environments, 2005: 13-23.

[22]Banga G, Druschel P, Mogul JC. Resource containers: a new facility for resource management in server systems [C]// Proceedings of the 3rd Symposium on Operating Systems Design and Implementation, 1999: 45-58.

[23]Aron M, Druschel P, Zwaenepoel W. Cluster reserves: a mechanism for resource management in cluster-based network servers [C]// Proceedings of the Conference on Measurement and Modeling of Computer Systems, 2000: 90-101.

[24]Lyneh W, Bray B, Flynn M. The effect of page allocation on caches [C]// Proceedings of the 25th Annual International Symposium, 1992: 222-225.

[25]Lin J, Lu Q, Ding X, et al. Gaining insights into multicore cache partitioning: bridging the gap between simulation and real systems [C]// IEEE 14th International Symposium on High Performance Computer Architecture, 2008: 16-20.

[26]Cho S, Jin L. Managing distributed, shared L2 caches through OS-level page allocation [C]// Proceedings of the IEEE/ACM International Symposium on Microarchitecture, 2006: 455-465.

[27]Tam D, Azimi R, Soares L, et al. Managing shared L2 caches on multicore systems in software [C]// Proceedings in Workshop on the Interaction between Operating Systems and Computer, 2007.

[28]Jeong MK, Yoon DH, Sunwoo D, et al. Balancing DRAM locality and parallelism in shared memory CMP systems [C]// IEEE 14th International Symposium on High Performance Computer Architecture, 2012.

[29]Muralidhara SP, Subramanian L, Mutlu OM, et al. Reducing memory interference in multicore systems via applicationaware memory channel partitioning [C]// Proceedings of the 44th Annual IEEE/ACM International Symposium on Microarchitecture, 2011: 374-385.

[30]Mi W, Feng X, Xue J, et al. Software-hardware cooperative DRAM bank partitioning for chip multiprocessors [J]. Network and Parallel Computing, 2010, 6289: 329-343.

[31]Liu L, Cui Z, Xing M, et al. A software memory partition approach for eliminating bank-level interference in multicore systems [C]// Proceedings of the 21st International Conference on Parallel Architectures and Compilation Techniques, 2012:367-376.

[32]Wang XL, Wen X, Li YC, et al. Dynamic cache partitioning based on hot page migration [J]. Frontiers of Computer Science,2012, 6(4): 363-372.

[33]Chen H, Wang X, Wang Z, et al. DMM: a dynamic memory mapping model for virtual machines [J]. Science China Information Sciences, 2010, 53(5): 1097-1108.

[34]Jin X, Chen H, Wang X, et al. A simple cache partitioning approach in a virtualized environment [C]// Proceedings of the 2009 IEEE International Symposium on Parallel and Distributed Processing with Applications, 2009.

[35]Mars J, Vachharajani N, Hundt R, et al. Contention aware execution: online contention detection and response [C]//Proceedings of the 8th Annual IEEE/ACM International Symposium on Code Generation and Optimization, 2010: 257-265.

[36]Mars J, Tang LJ, Soffa ML. Directly characterizing cross core interference through contention synthesis [C]// Proceedings of the 6th International Conference on High Performance and Embedded Architectures and Compilers, 2011: 167-176.

[37]Mars J, Tang LJ, Hundt R, et al. Bubble-up: increasing utilization in modern warehouse scale computers via sensible co-locations [C]// Proceedings of the 44th Annual IEEE/ACM International Symposium on Microarchitecture, 2011: 248-259.

[38]Tang LJ, Mars J. ReQoS: Reactive static/dynamic compilation for QoS in warehouse scale computers [C]// Proceedings of the 18th International Conference on Architectural Support for Programming Languages and Operating Systems, 2013.

[39]Mutlu O, Moscibroda T. Parallelism-aware batch scheduling:Enhancing both performance and fairness of shared DRAM systems [C]// Proceedings of 35th International Symposium on Computer Architecture, 2008.

[40]Kim Y, Han D, Mutlu O, et al. ATLAS: A scalable and highperformance scheduling algorithm for multiple memory controllers [C]// Proceedings of 16th IEEE International Symposium on High-Performance Computer Architecture, 2010: 1-12.

[41]Kim Y, Papamichael M, Mutlu O, et al. Thread cluster memory scheduling: Exploiting differences in memory access behavior [C]// Proceedings of the 2010 43rd Annual IEEE/ACM International Symposium on Microarchitecture, 2010:65-76.

[42]Iyer R. CQoS: a framework for enabling qos in shared caches of cmp platforms [C]// Proceedings of 18th Annual International Conference on Supercomputing, 2004.

[43]Iyer R, Zhao L, Guo F, et al. Reinhardt: QoS policies and architecture for cache/memory in CMP platforms [C]//Proceedings of the 2007 ACM International Conference on Measurement and Modeling of Computer Systems, 2007: 25-36.

[44]Herdrich A, Illikkal R, Iyer RR, et al. Rate-based QoS techniques for cache/memory in CMP platforms [C]// Proceedings of the 23rd International Conference on Supercomputing, 2009: 479-488.

[45]Dean J, Ghemawat S. MapReduce: simplified data processing on large clusters [J]. Communications of the ACM, 2008, 51(1):107-113.

[46]Kapoor R, Porter G, Tewari M, et al. Chronos: predictable low latency for data centerapplications [C]// Proceedings of the Third ACM Symposium on Cloud Computing, 2012.

[47]Computing Community Consortium. 21st Century Computer Architecture [Z]. White Paper, 2012.