虛擬化Pod性能比裸機還要好,原因竟然是這樣!
- 2019 年 12 月 16 日
- 筆記
之前的文章介紹過 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