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

[[151284]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

云服務供應商很清楚這些問題

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

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

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

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

然而，即使是單一操作系統也可能出現性能波動——但這種偶然性事件就與資源利用規劃沒什么關系了。

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

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