云計算

虛擬化Pod性能比裸機還要好,原因竟然是這樣!

   題圖攝于頤和園:雪后初晴佛香閣

之前的文章介紹過 VMware 在 VMworld 上宣布的太平洋項目 (Project Pacific) ,這是 vSphere 向 Kubernetes 原生平臺的演進。太平洋項目引入了 vSphere 主管集群( Supervisor Cluster )的概念,該集群能夠在 ESXi 上原生地運行 Kubernetes Pod(稱為 Native Pod )。

根據  VMware 官博上發布的信息,太平洋項目中通過虛擬化實現的 Native Pods,竟然比物理機(裸機)上 Kubernetes 的 pod 有8%的性能提升!

是的,你的確沒有看錯,虛擬化 Pod 的性能要比裸機 Pod 要好,這似乎有悖常理,眾所周知,虛擬化是有性能損失的,怎能優于裸機呢?且聽筆者慢慢道來。

為什么太平洋項目的 Native Pods 更快?

現代的服務器一般有多個處理器(CPU),采用的是 NUMA(非統一內存訪問)的內存訪問方式。在 NUMA 體系架構中,每個 CPU 負責管理一塊內存,稱為本地(local)內存。

當 CPU 訪問自己管理的內存時,因為是就近訪問,速度比較快;但如果需要訪問其它 CPU 名下的內存時(稱為遠程訪問),往往需要經過若干個電路開關,通常會慢一些。

ESXi 在調度 Pod 的時候,考慮到了 Pod 使用內存的本地性(locality),會確保其盡量訪問本地內存,這樣 Pod 運行性能比較好,并提高總體 CPU 效率。另一方面,裸機 Linux 中的進程調度程序可能無法在 NUMA 域之間提供類似的功能,因此性能有一定的損失。

ESXi CPU 調度程序知道 Pod 是獨立的運行實體,因此會盡量確保其內存訪問位于本地 NUMA 域內,大大減少了遠程內存訪問的次數,從而為 Pod 中的工作負載提供更好的性能,并提高 CPU 總體效率。另一方面,Linux 中的進程調度程序無法較好地識別 NUMA 域之間差異,所以不能提供類似的調度能力。

太平洋項目 Native Pods 的性能評估實驗

為了比較性能,VMware 的工程師在相同的硬件上配置了圖1所示的測試平臺,每臺服務器硬件是 2.2 GHz 的內核 44 個以及 512 GB 內存:
   a) 兩個太平洋項目的ESXi節點和其上的主管集群
   b) 兩個缺省配置的某主流企業級 Linux 裸機集群節點


圖1:測試平臺配置

通常,超線程處理器內核具有多個邏輯內核(超線程),它們之間共享硬件資源。為了減少對測試影響的因素,在兩個測試平臺中都禁用了超線程。在每個集群中,使用其中一個節點作為被測系統(Worker Node),而在另一個節點上運行 Kubernetes Master 。

圖2:Pod配置

在 Worker 節點中部署了10個 Kubernetes Pod,每個 Pod 的資源限制為 8個CPU,42 GB 內存,并在每個容器中運行一個標準 Java 事務基準測試,如圖2所示。

考慮到用于我們的工作負載的復雜性和性質,在實驗中使用了較大的 Pod ,以便管理測試樣例運行和 Pod 的評分匯總。使用 Pod 定義將 Pod 固定(affinitized)到每個測試平臺中的 Worker節點。使用所有10個 Pod 的匯總分數(最大吞吐量)來評估被測系統的性能。測試中基本沒有設計I / O或網絡傳輸,并且所有實驗都限于單個 Kubernetes節點。因此,I / O或網絡性能方面的影響不在本文中討論。

測試結果

圖3顯示了某主流企業級 Linux 裸機節點的性能和太平洋主管群集的性能(綠色條)對比,裸機 Linux 的性能作為基準1.0。
與裸機企業級 Linux 相比,太平洋主管群集的性能提高了8%。

圖3:太平洋主管集群與裸機企業級Linux節點相對性能

測試重復了多次并用平均數減少了實驗的誤差。與裸機情況相比,太平洋主管群集可實現約8%的總體性能提升。

分析和優化

查看系統統計信息,與 vSphere 主管集群相比,裸機上運行的工作負載被許多遠程 NUMA 內存訪問拖累了性能。vSphere 主管群集的性能優勢主要來自更優的CPU調度方法,同時還抵扣掉因虛擬化帶來的性能額外開銷。

進一步分析發現,在裸機 Linux 中,只有約43.5%的非命中L3高速緩存的數據可從本地 DRAM 中獲取,其余的則需要由遠程內存提供。相比之下,vSphere 主管群集得益于ESXi中出色的 CPU 調度功能,有 99.2%的未命中 L3 數據可在本地 DRAM中獲得,從而避免了遠程內存訪問,提高了vSphere主管群集的性能。(如圖4所示)

圖4:vSphere 主管群集與裸機 Linux上的 DRAM 命中率對比(數值越大越好) 

為了減少裸機 Linux上非本地 NUMA 訪問對性能的影響,工程師們嘗試了一些基本的優化,例如切換 NUMA 平衡開關和使用基于任務集的Pod固定到 CPU,但是這些都沒有實質性地提高性能。目前 Kubernetes 沒有對 NUMA 架構的 CPU 使用納入 Pod 規范,因此暫時沒有教好的方法解決這個問題。

在本實驗的結論取決于Pod訪問內存的密集度情況,如果工作負載具有不同的內存需求,則 NUMA 本地性對其性能的影響可能會有所不同。簡而言之,對內存訪問頻率高的 Pod 應用,跑在 vSphere 主管群集上可能比裸機上性能更好。
更多信息,參見:

https://blogs.vmware.com/performance/2019/10/how-does-project-pacific-deliver-8-better-performance-than-bare-metal.html

我還沒有學會寫個人說明!

這個教人寫出爛代碼的項目在 GitHub 上火了...

上一篇

為什么要在離線A/B測試中使用貝葉斯方法?

下一篇

你也可能喜歡

虛擬化Pod性能比裸機還要好,原因竟然是這樣!

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
双色球常规走势图 七乐彩 财富之轮 湖北麻将规则 男篮世界杯比赛比分 蓝球nba比分网 捷报比分app没声音 辽宁11选5 河源百搭麻将安卓 福建11选5 江苏七位数开奖号码 足球彩票比分直播500投注 安徽安徽十一选五走