眾所周知，了解容量的天然特性是我們采納云服務(wù)方案的前提條件，因?yàn)椴⒎敲糠N系統(tǒng)的虛擬機(jī)管理程序所使用的虛擬計(jì)算機(jī)制都具備同樣的運(yùn)作模式。而這一切都將給運(yùn)行在云環(huán)境之上的應(yīng)用程序帶來重要影響。
大家可能還記得，AWS提供至少兩種控制指標(biāo)：ECU(即EC2計(jì)算單元)與vCPU(意為虛擬中央處理單元)。而在為本篇文章收集素材 時(shí)，我在AWS的官方頁面當(dāng)中找到一些資料，其指出vCPU概念已經(jīng)取代了ECU。我個(gè)人對(duì)此并不理解，因?yàn)槎叨加兄鞔_且有力的存在理由。經(jīng)過檢查， 我發(fā)現(xiàn)AWS也確實(shí)對(duì)這種結(jié)論做出過反駁，即認(rèn)為兩項(xiàng)指標(biāo)都應(yīng)當(dāng)?shù)玫街匾暋Ｊ聦?shí)上，大家可能在實(shí)際使用中發(fā)現(xiàn)自己確實(shí)需要ECU或者其它一些以容量為基礎(chǔ) 之指標(biāo)來在“處理器”數(shù)量之外對(duì)系統(tǒng)進(jìn)行進(jìn)一步控制。具體來講，ECU控制著——或者是在用戶的管理下控制著——計(jì)算容量的使用情況。
為了進(jìn)一步討論CPU虛擬化在云環(huán)境下的實(shí)際影響，我們將立足于一套給定的完整SMP系統(tǒng)，且其中包含了系統(tǒng)所能承載的最大限度容量。對(duì)于某些特定 工作負(fù)載而言，大家可以盡可能從SMP的處理器當(dāng)中壓榨計(jì)算資源，從而獲取最為可觀的吞吐能力。如果大家在同一SMP當(dāng)中安裝多個(gè)操作系統(tǒng)實(shí)例，而后在其 上運(yùn)行同樣的工作負(fù)載，則會(huì)發(fā)現(xiàn)其整體吞吐量幾乎不可能超過此前達(dá)到過的上限。而這正是AWS所提出的多工作負(fù)載混合概念，或者稱其為ECU;當(dāng)然，其它 云服務(wù)廠商也采取了類似的概念。無論我們采用何種SMP系統(tǒng)進(jìn)行云環(huán)境構(gòu)建，該系統(tǒng)都會(huì)存在著最大容量上限。
因此，大家從云中租用多少容量并添加到一個(gè)操作系統(tǒng)實(shí)例當(dāng)中——舉例為說，以AWS ECU的形式——其永遠(yuǎn)不能超過這一最大上限。盡管我們并不清楚AWS設(shè)定的最大容量上限是什么，但在PowerVM當(dāng)中用戶確實(shí)無法讓所有活動(dòng)操作負(fù)載 總和超出這一上限。大家需要根據(jù)要求/需要為每套操作系統(tǒng)分配一定資源配額，而PowerVM則負(fù)責(zé)滿足/確保達(dá)成預(yù)期效果。在某種程度上 講，PowerVM了解其能夠?yàn)槊總€(gè)操作系統(tǒng)實(shí)例分配多少資源，因?yàn)槲覀兊牟僮飨到y(tǒng)容量需求屬于已知量;各部分容量的總和只會(huì)等于或者小于整體容量。
云服務(wù)供應(yīng)商的任務(wù)在于獲取客戶提供的參數(shù)，并找出——至少會(huì)在一段時(shí)間之后找到——這些資源的可用位置。當(dāng)然，僅達(dá)到這一目標(biāo)還遠(yuǎn)遠(yuǎn)不夠。在分配 完成后，是否有某些因素阻止某個(gè)操作系統(tǒng)實(shí)例獲取全部SMP容量?為了避免這種情況的出現(xiàn)，或者說確保每個(gè)實(shí)例都能得到自己必需的容量配額，我們可能需要 硬性要求vCPU進(jìn)行短暫的運(yùn)行中止。這種狀況在其它場(chǎng)景下亦會(huì)出現(xiàn)，如果其它實(shí)例已經(jīng)達(dá)到了自身容量消耗配額上限，則各操作系統(tǒng)實(shí)例會(huì)暫時(shí)中止以進(jìn)行配 額調(diào)整。這樣處理的目的在于確保所有vCPU都能夠公平地分配到可用硬件容量。
在這方面，PowerVM采取了一種有趣的衍生處理方式，即封頂與不封頂容量分配，我猜測(cè)其它云服務(wù)供應(yīng)商也選擇了類似的手段。封頂容量限定操作系 統(tǒng)實(shí)例的容量消耗水平不可高于用戶所租用容量之上限。舉例來說，假設(shè)大家使用兩個(gè)VP并總計(jì)為其分配了1.25個(gè)計(jì)算核心的容量限額。如此一來，我們的應(yīng) 用程序就只能同時(shí)將自身線程分配給這兩個(gè)VP。然而假如在某些特定時(shí)間段內(nèi)，二者的容量使用量總和超過了這1.25個(gè)核心，那么虛擬機(jī)管理程序會(huì)中止它們 的運(yùn)行。舉例來說，如果其中一個(gè)VP始終保持運(yùn)行，而另一個(gè)VP則只有四分之一時(shí)間運(yùn)行，那么我們此前設(shè)定的容量上限將永遠(yuǎn)不會(huì)被突破，而應(yīng)用程序則能夠 始終保持正常執(zhí)行。總體來講，在這種封頂模式當(dāng)中，大家可以充分發(fā)揮限額之內(nèi)的容量，直到下一個(gè)時(shí)間片段開始。
而對(duì)于不封頂容量模式，計(jì)算消耗量仍然會(huì)被正確計(jì)量，但會(huì)在實(shí)例達(dá)到容量上限時(shí)提出新的問題：是否還有其它操作系統(tǒng)VP需要這部分額外可用容量?如 果沒有，即沒有其它操作系統(tǒng)VP處于資源等待狀態(tài)，那么我們的VP將在超出限額后繼續(xù)運(yùn)行。但如果存在等待VP或者有需要使用容量的新VP出現(xiàn)，那么新的 VP會(huì)接管對(duì)應(yīng)的容量，而原先的VP則需要停止執(zhí)行。在這種情況下，當(dāng)?shù)却齎P快速完成了自己的執(zhí)行任務(wù)，那么正處于等待/可調(diào)度狀態(tài)的VP則能夠繼續(xù)此 前尚未完成的執(zhí)行工作，并仍以超出容量上限的方式保持運(yùn)行。
聽起來不錯(cuò)，對(duì)吧?在我們列舉的例子當(dāng)中，這可能意味著大家應(yīng)當(dāng)優(yōu)先選擇不封頂模式，即2個(gè)VP與1.25核心容量的PowerVM操作系統(tǒng)實(shí)例能 夠在占用2個(gè)核心的情況下繼續(xù)保持運(yùn)行。在這種情況下，其實(shí)際吞吐量為2個(gè)完整計(jì)算核心，而非預(yù)設(shè)的1.25個(gè)。不錯(cuò)，效果很好——但前提是我們的SMP 系統(tǒng)在資源使用量方面始終較低，只有這樣各vCPU才能保持順暢執(zhí)行。在這種情況下，大家會(huì)習(xí)慣了利用2個(gè)完整的計(jì)算核心——而非1.25個(gè)——執(zhí)行既定 任務(wù)。但隨著時(shí)間推移，某些對(duì)資源索求無度的操作系統(tǒng)可能進(jìn)入我們的同一套SMP系統(tǒng)，并始終處于忙碌狀態(tài)。這意味著系統(tǒng)當(dāng)中不再存在可用的閑置容量;容 量重新被限定回了1.25核心，而吞吐量的實(shí)際速度表現(xiàn)甚至?xí)任覀兊念A(yù)期水平更低。需要注意的是，這并不屬于真正的性能問題，而僅僅屬于不當(dāng)預(yù)期管理引 發(fā)的沖突。另外，這種方式也不至于損害性能，其它操作系統(tǒng)實(shí)例仍然能夠如預(yù)期般正常運(yùn)作。
緩存的存在令我們難以準(zhǔn)確衡量容量上限
到這里，我們已經(jīng)了解到了任意單獨(dú)SMP中都存在著最大可用容量上限。大家也許會(huì)爭(zhēng)辯稱，自己擁有多種方式來衡量這一容量上限——但是實(shí)際情況是， 大部分衡量手段會(huì)將駐留在處理器緩存中接受訪問的大部分?jǐn)?shù)據(jù)算入容量水平。由于緩存訪問在速度上要遠(yuǎn)高于DRAM，因此緩存的介入有可能讓我們的最大容量 上限評(píng)估結(jié)果與實(shí)際情況相去甚遠(yuǎn)。如果不考慮緩存機(jī)制，那么最大容量上限可能要低得多。另外，如果緩存內(nèi)的數(shù)據(jù)與實(shí)際訪問對(duì)象的交集較為有限，那么最大容 量也會(huì)受到嚴(yán)重影響。而正是由于這種狀況的存在，我們才需要在后文中詳加敘述。
大家肯定還記得，我們的操作系統(tǒng)需要與其它一些同類實(shí)例共享SMP系統(tǒng)的容量，而且我們所能使用的容量只是SMP系統(tǒng)容量總和的一部分。之所以要使 用處理器虛擬化機(jī)制，就是要確保不同實(shí)例得以對(duì)SMP系統(tǒng)的整體容量加以共享。而只要這種共享效果“還不錯(cuò)”，那么操作系統(tǒng)及其它實(shí)例的執(zhí)行性能就會(huì)令人 滿意;它們共享的正是測(cè)量所得出的容量上限。因此，讓我們換個(gè)思路，從最糟糕的角度審視這個(gè)問題。
在進(jìn)行討論之前，讓我們首先明確一個(gè)相關(guān)概念。我們假設(shè)能夠分配給每個(gè)操作系統(tǒng)實(shí)例的容量之總和低于SMP系統(tǒng)當(dāng)中所存在的全部可用容量。我們還需 要強(qiáng)調(diào)一點(diǎn)，每個(gè)操作系統(tǒng)實(shí)例都能夠使用一定數(shù)量的VP。雖然整體容量已經(jīng)限定，但并不代表著各活動(dòng)操作系統(tǒng)中的VP容量總量需要與物理處理器計(jì)算核心數(shù) 量(或者SMT線程數(shù)量)相對(duì)等。這意味著VP數(shù)量可以進(jìn)行超額分配，亦有可能超過處理器的實(shí)際數(shù)量。事實(shí)上，有時(shí)候我們會(huì)傾向于選擇這種方式;在中低水 平CPU利用率條件下，更多VP能夠保證我們的操作系統(tǒng)擁有更理想的響應(yīng)時(shí)間表現(xiàn);而并行執(zhí)行——而非單一VP中的隊(duì)列執(zhí)行——機(jī)制也能夠更快地完成某些 特定任務(wù)。
不過這同時(shí)也意味著較高的容量使用率，其中活動(dòng)VP數(shù)量要遠(yuǎn)高于能夠分配給它們的物理處理器數(shù)量。更直白地解釋，為了確保容量能夠得到恰當(dāng)使用，虛 擬機(jī)管理程序需要?jiǎng)澐殖鰰r(shí)間片段，從而確保物理處理器能夠?yàn)楦郪P實(shí)際使用。舉例來說，我們假定系統(tǒng)中存在32個(gè)物理處理器以及256個(gè)活動(dòng)VP。這種 設(shè)計(jì)方式其實(shí)非常合理，一套系統(tǒng)資源由數(shù)百個(gè)操作系統(tǒng)實(shí)例共享的機(jī)制可謂隨處可見。為確保容量的公平分配，虛擬機(jī)管理程序必須在32個(gè)處理器上為256個(gè) VP設(shè)定角色，同時(shí)盡可能快地完成這一任務(wù)以保證用戶在直觀感受上認(rèn)為這些VP是在同時(shí)執(zhí)行。
現(xiàn)在我們?cè)僬f回緩存。當(dāng)某個(gè)任務(wù)開始在某個(gè)計(jì)算核心上執(zhí)行，該任務(wù)的數(shù)據(jù)狀態(tài)并不會(huì)駐留在緩存當(dāng)中。系統(tǒng)需要經(jīng)過一段時(shí)間的運(yùn)行才會(huì)確認(rèn)這一狀況， 并將其從DRAM或者其它緩存中提取到主緩存內(nèi)。雖然一般來講緩存中的駐留數(shù)據(jù)會(huì)在相關(guān)任務(wù)完成的一段時(shí)間之后被釋放，但對(duì)于某些始終在計(jì)算核心上執(zhí)行的 任務(wù)，其狀態(tài)數(shù)據(jù)傾向于長(zhǎng)期駐留在緩存內(nèi)以接受重復(fù)使用。運(yùn)氣好的話，這項(xiàng)任務(wù)會(huì)長(zhǎng)久占用計(jì)算核心，而性能也將在緩存駐留數(shù)據(jù)(及指令)狀態(tài)的幫助下顯著 提高;畢竟緩存的存在意義就是為了實(shí)現(xiàn)常用數(shù)據(jù)的快速訪問。
甚至在虛擬環(huán)境當(dāng)中，一項(xiàng)任務(wù)仍然能夠長(zhǎng)時(shí)間駐留在處理器緩存之內(nèi)，從而保證其執(zhí)行狀態(tài)始終受到緩存機(jī)制的加持。在保持緩存狀態(tài)的同時(shí)，其最終吞吐 量也會(huì)因此顯著提高。這一點(diǎn)在低利用率及不封頂運(yùn)行模式當(dāng)中猶為明顯。如果對(duì)處理器及其緩存資源的競(jìng)爭(zhēng)并不激烈，那么該任務(wù)的緩存狀態(tài)將長(zhǎng)久保持在穩(wěn)定水 平。
不過現(xiàn)在讓我們添加額外工作負(fù)載(以及更多VP)，從而提高虛擬化SMP的資源利用率。在這種情況下，我們可能會(huì)發(fā)現(xiàn)活動(dòng)VP數(shù)量所帶來的超額容量 需求不斷增長(zhǎng)，而任務(wù)狀態(tài)——也就是在VP被分配給指定處理器時(shí)，狀態(tài)數(shù)據(jù)進(jìn)入緩存所需的時(shí)間——亦會(huì)在虛擬機(jī)管理程序在處理器上進(jìn)行VP切換時(shí)被刷新， 這意味著其它VP數(shù)據(jù)會(huì)取而代之。當(dāng)我們的任務(wù)VP不斷在處理器之間進(jìn)行切換時(shí)，其運(yùn)行所處的處理器必然同時(shí)發(fā)生改變。如此一來，要想讓VP恢復(fù)執(zhí)行，那 么狀態(tài)數(shù)據(jù)進(jìn)入緩存的時(shí)間將因此而大幅延長(zhǎng)。
想象一下，這種狀況在每一次VP交換時(shí)都會(huì)發(fā)生。這意味著前面提到過的緩存準(zhǔn)確率開始下降，能夠完成的任務(wù)不斷減少，進(jìn)而導(dǎo)致吞吐總量嚴(yán)重縮水。任 務(wù)的完成流程需要消耗更多時(shí)間，且長(zhǎng)時(shí)間駐留在自己的VP當(dāng)中而非被完成并釋放，而在此期間我們也將無法獲得能夠接受的合理響應(yīng)時(shí)間。
云服務(wù)供應(yīng)商很清楚這些問題
大家需要了解這些會(huì)對(duì)處理器虛擬機(jī)機(jī)制產(chǎn)生影響的因素。不過我們幾乎可以肯定，云服務(wù)供應(yīng)商們比我們自己更了解這些問題——或者說應(yīng)該是更了解這些問題。對(duì)他們來講，對(duì)自家系統(tǒng)進(jìn)行妥善管理顯然非常重要，而且之前提到的還僅僅其中的一部分相關(guān)因素而已。
我們也幾乎可以肯定，云服務(wù)供應(yīng)商能夠在其整體環(huán)境當(dāng)中部署更多容量以滿足客戶對(duì)性能的實(shí)際需求——甚至有能力在全部操作系統(tǒng)實(shí)例皆處于忙碌狀態(tài)時(shí) 仍然實(shí)現(xiàn)這一目標(biāo)。他們自己的系統(tǒng)會(huì)在容量需求量增長(zhǎng)或者出現(xiàn)不可避免的故障時(shí)進(jìn)行主動(dòng)待機(jī)。其中一部分系統(tǒng)甚至?xí)詣?dòng)關(guān)機(jī)，以確保在非必要的情況下盡可 能節(jié)約能源消耗。
云服務(wù)供應(yīng)商還具備將各類操作系統(tǒng)實(shí)例在不同SMP系統(tǒng)之間進(jìn)行遷移的能力。當(dāng)某套系統(tǒng)的資源利用率提升到高危層級(jí)時(shí)，他們可能會(huì)決定將用戶的操作 系統(tǒng)實(shí)例轉(zhuǎn)移到其它負(fù)載較低的系統(tǒng)當(dāng)中。反之亦然;如果存在大量被分布在多套低資源利用率系統(tǒng)當(dāng)中，那么他們會(huì)傾向于將這些操作系統(tǒng)加以收集以減少系統(tǒng)占 用數(shù)量——這至少能夠有效降低系統(tǒng)運(yùn)行所帶來的整體能耗水平。而這種對(duì)操作系統(tǒng)實(shí)例的遷移能力以及了解該在何時(shí)進(jìn)行系統(tǒng)關(guān)閉與合并，則代表著云服務(wù)供應(yīng)商 一直在對(duì)自身環(huán)境進(jìn)行密切監(jiān)控。正如我們之前所提到，這些供應(yīng)商會(huì)將負(fù)載均衡工作當(dāng)成科學(xué)事務(wù)來看待，而這種嚴(yán)謹(jǐn)?shù)膽B(tài)度也能夠?yàn)槠鋷砬袑?shí)可見的經(jīng)濟(jì)回 報(bào)。
不過正如大部分企業(yè)一樣，提高客戶與潛在新客戶滿意度水平也能夠帶來良好的經(jīng)濟(jì)回報(bào)。換言之，對(duì)容量波動(dòng)水平進(jìn)行嚴(yán)格監(jiān)控以提供穩(wěn)定且合理的性能水 平不僅有益于客戶，同時(shí)也有益于云服務(wù)供應(yīng)商自身。因此，雖然從某種角度講云服務(wù)供應(yīng)商能夠通過將盡可能多的操作系統(tǒng)實(shí)例塞進(jìn)少數(shù)活動(dòng)SMP系統(tǒng)來獲得最 大程度的經(jīng)濟(jì)回報(bào)，但他們很清楚這種殺雞取卵的作法會(huì)通過低下的性能水平導(dǎo)致客戶滿意度下降，并最終導(dǎo)致其自食惡果。具體來講，過度使用系統(tǒng)資源并不是種 明智的決定。
然而，即使是單一操作系統(tǒng)也可能出現(xiàn)性能波動(dòng)——但這種偶然性事件就與資源利用規(guī)劃沒什么關(guān)系了。
京公網(wǎng)安備 11010502049343號(hào)