【51CTO.com快譯】眾所周知，了解容量的天然特性是我們采納云服務(wù)方案的前提條件，因為并非每種系統(tǒng)的虛擬機管理程序所使用的虛擬計算機制都具備同樣的運作模式。而這一切都將給運行在云環(huán)境之上的應(yīng)用程序帶來重要影響。

[[151284]]

大家可能還記得，AWS提供至少兩種控制指標：ECU(即EC2計算單元)與vCPU(意為虛擬中央處理單元)。而在為本篇文章收集素材 時，我在AWS的官方頁面當中找到一些資料，其指出vCPU概念已經(jīng)取代了ECU。我個人對此并不理解，因為二者都有著明確且有力的存在理由。經(jīng)過檢查， 我發(fā)現(xiàn)AWS也確實對這種結(jié)論做出過反駁，即認為兩項指標都應(yīng)當?shù)玫街匾暋Ｊ聦嵣?，大家可能在實際使用中發(fā)現(xiàn)自己確實需要ECU或者其它一些以容量為基礎(chǔ) 之指標來在“處理器”數(shù)量之外對系統(tǒng)進行進一步控制。具體來講，ECU控制著——或者是在用戶的管理下控制著——計算容量的使用情況。

為了進一步討論CPU虛擬化在云環(huán)境下的實際影響，我們將立足于一套給定的完整SMP系統(tǒng)，且其中包含了系統(tǒng)所能承載的***限度容量。對于某些特定 工作負載而言，大家可以盡可能從SMP的處理器當中壓榨計算資源，從而獲取最為可觀的吞吐能力。如果大家在同一SMP當中安裝多個操作系統(tǒng)實例，而后在其 上運行同樣的工作負載，則會發(fā)現(xiàn)其整體吞吐量幾乎不可能超過此前達到過的上限。而這正是AWS所提出的多工作負載混合概念，或者稱其為ECU;當然，其它 云服務(wù)廠商也采取了類似的概念。無論我們采用何種SMP系統(tǒng)進行云環(huán)境構(gòu)建，該系統(tǒng)都會存在著***容量上限。

因此，大家從云中租用多少容量并添加到一個操作系統(tǒng)實例當中——舉例為說，以AWS ECU的形式——其永遠不能超過這一***上限。盡管我們并不清楚AWS設(shè)定的***容量上限是什么，但在PowerVM當中用戶確實無法讓所有活動操作負載 總和超出這一上限。大家需要根據(jù)要求/需要為每套操作系統(tǒng)分配一定資源配額，而PowerVM則負責滿足/確保達成預期效果。在某種程度上 講，PowerVM了解其能夠為每個操作系統(tǒng)實例分配多少資源，因為我們的操作系統(tǒng)容量需求屬于已知量;各部分容量的總和只會等于或者小于整體容量。

云服務(wù)供應(yīng)商的任務(wù)在于獲取客戶提供的參數(shù)，并找出——至少會在一段時間之后找到——這些資源的可用位置。當然，僅達到這一目標還遠遠不夠。在分配完成后，是否有某些因素阻止某個操作系統(tǒng)實例獲取全部SMP容量?為了避免這種情況的出現(xiàn)，或者說確保每個實例都能得到自己必需的容量配額，我們可能需要 硬性要求vCPU進行短暫的運行中止。這種狀況在其它場景下亦會出現(xiàn)，如果其它實例已經(jīng)達到了自身容量消耗配額上限，則各操作系統(tǒng)實例會暫時中止以進行配 額調(diào)整。這樣處理的目的在于確保所有vCPU都能夠公平地分配到可用硬件容量。

在這方面，PowerVM采取了一種有趣的衍生處理方式，即封頂與不封頂容量分配，我猜測其它云服務(wù)供應(yīng)商也選擇了類似的手段。封頂容量限定操作系 統(tǒng)實例的容量消耗水平不可高于用戶所租用容量之上限。舉例來說，假設(shè)大家使用兩個VP并總計為其分配了1.25個計算核心的容量限額。如此一來，我們的應(yīng) 用程序就只能同時將自身線程分配給這兩個VP。然而假如在某些特定時間段內(nèi)，二者的容量使用量總和超過了這1.25個核心，那么虛擬機管理程序會中止它們 的運行。舉例來說，如果其中一個VP始終保持運行，而另一個VP則只有四分之一時間運行，那么我們此前設(shè)定的容量上限將永遠不會被突破，而應(yīng)用程序則能夠 始終保持正常執(zhí)行?？傮w來講，在這種封頂模式當中，大家可以充分發(fā)揮限額之內(nèi)的容量，直到下一個時間片段開始。

而對于不封頂容量模式，計算消耗量仍然會被正確計量，但會在實例達到容量上限時提出新的問題：是否還有其它操作系統(tǒng)VP需要這部分額外可用容量?如 果沒有，即沒有其它操作系統(tǒng)VP處于資源等待狀態(tài)，那么我們的VP將在超出限額后繼續(xù)運行。但如果存在等待VP或者有需要使用容量的新VP出現(xiàn)，那么新的 VP會接管對應(yīng)的容量，而原先的VP則需要停止執(zhí)行。在這種情況下，當?shù)却齎P快速完成了自己的執(zhí)行任務(wù)，那么正處于等待/可調(diào)度狀態(tài)的VP則能夠繼續(xù)此 前尚未完成的執(zhí)行工作，并仍以超出容量上限的方式保持運行。

聽起來不錯，對吧?在我們列舉的例子當中，這可能意味著大家應(yīng)當優(yōu)先選擇不封頂模式，即2個VP與1.25核心容量的PowerVM操作系統(tǒng)實例能 夠在占用2個核心的情況下繼續(xù)保持運行。在這種情況下，其實際吞吐量為2個完整計算核心，而非預設(shè)的1.25個。不錯，效果很好——但前提是我們的SMP 系統(tǒng)在資源使用量方面始終較低，只有這樣各vCPU才能保持順暢執(zhí)行。在這種情況下，大家會習慣了利用2個完整的計算核心——而非1.25個——執(zhí)行既定 任務(wù)。但隨著時間推移，某些對資源索求無度的操作系統(tǒng)可能進入我們的同一套SMP系統(tǒng)，并始終處于忙碌狀態(tài)。這意味著系統(tǒng)當中不再存在可用的閑置容量;容 量重新被限定回了1.25核心，而吞吐量的實際速度表現(xiàn)甚至會比我們的預期水平更低。需要注意的是，這并不屬于真正的性能問題，而僅僅屬于不當預期管理引 發(fā)的沖突。另外，這種方式也不至于損害性能，其它操作系統(tǒng)實例仍然能夠如預期般正常運作。

緩存的存在令我們難以準確衡量容量上限

到這里，我們已經(jīng)了解到了任意單獨SMP中都存在著***可用容量上限。大家也許會爭辯稱，自己擁有多種方式來衡量這一容量上限——但是實際情況是， 大部分衡量手段會將駐留在處理器緩存中接受訪問的大部分數(shù)據(jù)算入容量水平。由于緩存訪問在速度上要遠高于DRAM，因此緩存的介入有可能讓我們的***容量 上限評估結(jié)果與實際情況相去甚遠。如果不考慮緩存機制，那么***容量上限可能要低得多。另外，如果緩存內(nèi)的數(shù)據(jù)與實際訪問對象的交集較為有限，那么***容 量也會受到嚴重影響。而正是由于這種狀況的存在，我們才需要在后文中詳加敘述。

大家肯定還記得，我們的操作系統(tǒng)需要與其它一些同類實例共享SMP系統(tǒng)的容量，而且我們所能使用的容量只是SMP系統(tǒng)容量總和的一部分。之所以要使 用處理器虛擬化機制，就是要確保不同實例得以對SMP系統(tǒng)的整體容量加以共享。而只要這種共享效果“還不錯”，那么操作系統(tǒng)及其它實例的執(zhí)行性能就會令人 滿意;它們共享的正是測量所得出的容量上限。因此，讓我們換個思路，從最糟糕的角度審視這個問題。

在進行討論之前，讓我們首先明確一個相關(guān)概念。我們假設(shè)能夠分配給每個操作系統(tǒng)實例的容量之總和低于SMP系統(tǒng)當中所存在的全部可用容量。我們還需 要強調(diào)一點，每個操作系統(tǒng)實例都能夠使用一定數(shù)量的VP。雖然整體容量已經(jīng)限定，但并不代表著各活動操作系統(tǒng)中的VP容量總量需要與物理處理器計算核心數(shù) 量(或者SMT線程數(shù)量)相對等。這意味著VP數(shù)量可以進行超額分配，亦有可能超過處理器的實際數(shù)量。事實上，有時候我們會傾向于選擇這種方式;在中低水 平CPU利用率條件下，更多VP能夠保證我們的操作系統(tǒng)擁有更理想的響應(yīng)時間表現(xiàn);而并行執(zhí)行——而非單一VP中的隊列執(zhí)行——機制也能夠更快地完成某些 特定任務(wù)。

不過這同時也意味著較高的容量使用率，其中活動VP數(shù)量要遠高于能夠分配給它們的物理處理器數(shù)量。更直白地解釋，為了確保容量能夠得到恰當使用，虛 擬機管理程序需要劃分出時間片段，從而確保物理處理器能夠為更多VP實際使用。舉例來說，我們假定系統(tǒng)中存在32個物理處理器以及256個活動VP。這種 設(shè)計方式其實非常合理，一套系統(tǒng)資源由數(shù)百個操作系統(tǒng)實例共享的機制可謂隨處可見。為確保容量的公平分配，虛擬機管理程序必須在32個處理器上為256個 VP設(shè)定角色，同時盡可能快地完成這一任務(wù)以保證用戶在直觀感受上認為這些VP是在同時執(zhí)行。

現(xiàn)在我們再說回緩存。當某個任務(wù)開始在某個計算核心上執(zhí)行，該任務(wù)的數(shù)據(jù)狀態(tài)并不會駐留在緩存當中。系統(tǒng)需要經(jīng)過一段時間的運行才會確認這一狀況， 并將其從DRAM或者其它緩存中提取到主緩存內(nèi)。雖然一般來講緩存中的駐留數(shù)據(jù)會在相關(guān)任務(wù)完成的一段時間之后被釋放，但對于某些始終在計算核心上執(zhí)行的 任務(wù)，其狀態(tài)數(shù)據(jù)傾向于長期駐留在緩存內(nèi)以接受重復使用。運氣好的話，這項任務(wù)會長久占用計算核心，而性能也將在緩存駐留數(shù)據(jù)(及指令)狀態(tài)的幫助下顯著 提高;畢竟緩存的存在意義就是為了實現(xiàn)常用數(shù)據(jù)的快速訪問。

甚至在虛擬環(huán)境當中，一項任務(wù)仍然能夠長時間駐留在處理器緩存之內(nèi)，從而保證其執(zhí)行狀態(tài)始終受到緩存機制的加持。在保持緩存狀態(tài)的同時，其最終吞吐 量也會因此顯著提高。這一點在低利用率及不封頂運行模式當中猶為明顯。如果對處理器及其緩存資源的競爭并不激烈，那么該任務(wù)的緩存狀態(tài)將長久保持在穩(wěn)定水 平。

不過現(xiàn)在讓我們添加額外工作負載(以及更多VP)，從而提高虛擬化SMP的資源利用率。在這種情況下，我們可能會發(fā)現(xiàn)活動VP數(shù)量所帶來的超額容量 需求不斷增長，而任務(wù)狀態(tài)——也就是在VP被分配給指定處理器時，狀態(tài)數(shù)據(jù)進入緩存所需的時間——亦會在虛擬機管理程序在處理器上進行VP切換時被刷新， 這意味著其它VP數(shù)據(jù)會取而代之。當我們的任務(wù)VP不斷在處理器之間進行切換時，其運行所處的處理器必然同時發(fā)生改變。如此一來，要想讓VP恢復執(zhí)行，那 么狀態(tài)數(shù)據(jù)進入緩存的時間將因此而大幅延長。

想象一下，這種狀況在每一次VP交換時都會發(fā)生。這意味著前面提到過的緩存準確率開始下降，能夠完成的任務(wù)不斷減少，進而導致吞吐總量嚴重縮水。任 務(wù)的完成流程需要消耗更多時間，且長時間駐留在自己的VP當中而非被完成并釋放，而在此期間我們也將無法獲得能夠接受的合理響應(yīng)時間。

云服務(wù)供應(yīng)商很清楚這些問題

大家需要了解這些會對處理器虛擬機機制產(chǎn)生影響的因素。不過我們幾乎可以肯定，云服務(wù)供應(yīng)商們比我們自己更了解這些問題——或者說應(yīng)該是更了解這些問題。對他們來講，對自家系統(tǒng)進行妥善管理顯然非常重要，而且之前提到的還僅僅其中的一部分相關(guān)因素而已。

我們也幾乎可以肯定，云服務(wù)供應(yīng)商能夠在其整體環(huán)境當中部署更多容量以滿足客戶對性能的實際需求——甚至有能力在全部操作系統(tǒng)實例皆處于忙碌狀態(tài)時 仍然實現(xiàn)這一目標。他們自己的系統(tǒng)會在容量需求量增長或者出現(xiàn)不可避免的故障時進行主動待機。其中一部分系統(tǒng)甚至會自動關(guān)機，以確保在非必要的情況下盡可 能節(jié)約能源消耗。

云服務(wù)供應(yīng)商還具備將各類操作系統(tǒng)實例在不同SMP系統(tǒng)之間進行遷移的能力。當某套系統(tǒng)的資源利用率提升到高危層級時，他們可能會決定將用戶的操作 系統(tǒng)實例轉(zhuǎn)移到其它負載較低的系統(tǒng)當中。反之亦然;如果存在大量被分布在多套低資源利用率系統(tǒng)當中，那么他們會傾向于將這些操作系統(tǒng)加以收集以減少系統(tǒng)占 用數(shù)量——這至少能夠有效降低系統(tǒng)運行所帶來的整體能耗水平。而這種對操作系統(tǒng)實例的遷移能力以及了解該在何時進行系統(tǒng)關(guān)閉與合并，則代表著云服務(wù)供應(yīng)商 一直在對自身環(huán)境進行密切監(jiān)控。正如我們之前所提到，這些供應(yīng)商會將負載均衡工作當成科學事務(wù)來看待，而這種嚴謹?shù)膽B(tài)度也能夠為其帶來切實可見的經(jīng)濟回 報。

不過正如大部分企業(yè)一樣，提高客戶與潛在新客戶滿意度水平也能夠帶來良好的經(jīng)濟回報。換言之，對容量波動水平進行嚴格監(jiān)控以提供穩(wěn)定且合理的性能水 平不僅有益于客戶，同時也有益于云服務(wù)供應(yīng)商自身。因此，雖然從某種角度講云服務(wù)供應(yīng)商能夠通過將盡可能多的操作系統(tǒng)實例塞進少數(shù)活動SMP系統(tǒng)來獲得***程度的經(jīng)濟回報，但他們很清楚這種殺雞取卵的作法會通過低下的性能水平導致客戶滿意度下降，并最終導致其自食惡果。具體來講，過度使用系統(tǒng)資源并不是種 明智的決定。

然而，即使是單一操作系統(tǒng)也可能出現(xiàn)性能波動——但這種偶然性事件就與資源利用規(guī)劃沒什么關(guān)系了。

原文標題：CPU Virtualization In The Cloud: Getting Your Slice, And More

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】