66
《vSphere性能設計：性能密集場景下CPU、內存、存儲及網絡的最佳設計實踐》一1.2.1 CPU基礎設施基準
本節書摘來異步社區《vSphere性能設計：性能密集場景下CPU、內存、存儲及網絡的最佳設計實踐》一書中的第1章 ，第1.2.1節，[美] 克裏斯托弗·庫塞克（Christopher Kusek） 著 呂南德特·施皮斯（Rynardt Spies）姚海鵬 劉韻潔 譯, 更多章節內容可以訪問雲棲社區“異步社區”公眾號查看。
1.2.1 CPU基礎設施基準
從基礎架構的角度來看，通常會根據服務器能夠支持的內核和CPU的數量，以及能夠處理的內存插槽數量來選擇服務器。根據這些就能決定VMware vSphere集群可以支持vCPU的最大數量，以及能夠提供給虛擬機的最大內存。從而能夠確定虛擬機能夠支持的最高配置。
例如，如果你要將一個舊設備再利用，它每台服務器最大可用四核，並且RAM最大為16 GB。可以確定，它將無法提供一個具有32 vCPU、64 GB RAM的單一虛擬機。所以，可見你的虛擬配置達不到最大vSphere主機的可用資源—記住，vSphere以及它為虛擬機保留的開銷也需要可用的資源。
一旦確定能夠支持的最高配置，你很快就會認識到可接受的最低配置通常會低於先前認為的界限。在建立應用程序基準的過程中，你還會發現，“製造商建議的最佳實踐”的最好情況是保守的，而最壞情況則是完全欺騙！
又如，多少次你聽到過一個應用程序因為太忙而需要一定量的資源，隻為了讓你發現那些資源沒有得到充分利用？
那麼，這是否意味著當我們為應用程序分配vCPU時一定存在一個最好的配置？讓我們研究vCPU的參數究竟意味著什麼特征。從圖1-1可以看到，CPU的主要相關參數是CPU的數量、CPU處理能力、CPU共享、CPU限製、CPU保留。不考慮設備，基礎架構可以給主機分配CPU數量以及指定分享和限製。在大多數情況下，這些你完全可以通過關注分配給主機的CPU的數量和工作量而獲得。
分析CPU使用、爭用和工作負載有助於建立應用程序基準。需要指出的重要一點是，實際上，一個被監控的CPU可能會出現尖峰，所以最好使用監測工具（如esxtop、vCenter Operations Manager或內置在vCenter中的性能工具）來不斷收集數據。我們已經看到許多用戶報告說，他們的應用是低於分配標準的，因為他們在Windows任務管理器中看到了CPU的尖峰。其實，CPU尖峰預計是肯定會發生的。
現在，監控CPU的使用，最重要的就是不做任何操作，不要調整、修改分配好的共享或者內核的數量。就像我們點了一份菜單然後等待，耐心很重要，這樣才能確定應用程序的使用基準。
作者Christopher Kusek分享了一個小故事，關於他如何測試每一步來建立一個應用的基準。正如在我們的設想中認為的，一個工程師或者架構師是極度保守的，出於同樣的原因，我們也希望隻使用所需要的資源。他有一個非常密集型的應用，有一個監控工具從他的100多個vCenter服務器中收集數據，還有上千個ESXi主機操作這些數據中心。因為非常龐大，他認為原始分配的兩個vCPU和8GB的內存無法良好運行，所以隻要有一個IT工具能夠承擔他認為合適的中斷，他馬上就將vCPU的數量增加至8個，內存增加至16GB。
這樣就可以看到經過一段時間（建立基準）的運行，在不影響應用程序性能下，係統能達到的峰值。他選擇利用曆史數據的收集和報告，通過vCenter操作管理和vCenter的性能標簽來收集數據。VMware vSphere特別好的一點是可以持續計算出它所需要的資源。經過一小段時間後，可以確定這個係統最多使用5個vCPU和12GB內存便可以高效運行。
這時Christopher將係統下調至這個需求，並且基於他的基準，他不僅知道了運行的工作量，同時知道了預期峰值。這樣，他就知道了運行這個特定的應用程序所需的資源，不會因為配置不達標而影響性能，也不會因為超標而浪費資源。
你會發現，對你的虛擬環境來說，vCPU的分配是最重要的方麵之一，尤其是當考慮到第4章中的CPU調度程序時。其中在聚集頻率方麵不能節省，同時在分配邏輯vCPU數量方麵不能浪費（同時調度複雜度>1或2 vCPU=+++%RDY%），因為CPU確實是一個有限的資產，如果沒有性能指示則不能“被共享”。
最後更新：2017-06-22 10:01:58