CXL（Compute Express Link）將成為一種變革性技術(shù)，將重新定義數(shù)據(jù)中心的架構(gòu)和構(gòu)建方式。這是因為 CXL 為跨芯片的緩存一致性、內(nèi)存擴展和內(nèi)存池提供了標(biāo)準(zhǔn)化協(xié)議。在本文中，我們將重點介紹微軟正在做的事情，以幫助大家了解CXL對數(shù)據(jù)中心的意義。

數(shù)據(jù)中心是一件非常昂貴的事情。微軟表示，他們高達(dá)50% 的服務(wù)器成本僅來自 DRAM。所需的資本支出是巨大的，但您構(gòu)建的服務(wù)器并不是同質(zhì)的。工作負(fù)載不是靜態(tài)的。它們在不斷地成長和進(jìn)化。計算資源、DRAM、NAND 和網(wǎng)絡(luò)類型的組合將根據(jù)工作負(fù)載而變化。

一刀切的模式是行不通的，這就是為什么您會看到云提供商擁有數(shù)十種甚至數(shù)百種不同的實例類型。這些正在嘗試針對不同的工作負(fù)載優(yōu)化硬件產(chǎn)品。即便如此，許多用戶最終還是為他們真正不需要的東西付費。

實例選擇并不完美，這些實例與硬件的匹配也不完美。隨之而來的是平臺級內(nèi)存擱淺問題。服務(wù)器配置為不合適的實例類型場景。

這個問題的解決方案是內(nèi)存池。多個服務(wù)器可以共享一部分內(nèi)存，并且可以動態(tài)地將其分配給不同的服務(wù)器。與其過度地配置服務(wù)器，不如將它們配置為更接近平均 DRAM 與內(nèi)核的比率，并且可以通過內(nèi)存池來解決客戶的過多 DRAM 需求。此內(nèi)存池將通過 CXL 協(xié)議進(jìn)行通信。未來，隨著對 CXL 協(xié)議的修訂，服務(wù)器甚至可以共享相同的內(nèi)存來處理相同的工作負(fù)載，這將進(jìn)一步減少 DRAM 需求。

擁有大規(guī)模應(yīng)用程序的復(fù)雜運營商可以通過向其開發(fā)人員提供具有不同帶寬和延遲的多層內(nèi)存來解決這個問題。這對于亞馬遜、谷歌、微軟和其他公司運營的公共云環(huán)境來說是站不住腳的。

Microsoft 概述了與公共云環(huán)境中的內(nèi)存池有關(guān)的 3 個主要功能挑戰(zhàn)。無法修改客戶工作負(fù)載，包括guest操作系統(tǒng)。內(nèi)存池系統(tǒng)還必須與虛擬化加速技術(shù)兼容，例如直接將 I/O 設(shè)備分配給 VM 和 SR-IOV。池化還必須可用于商用硬件。

在過去他們也試過內(nèi)存池，但它需要自定義硬件設(shè)計、更改 VM guest并依賴頁面錯誤。這種組合使其無法部署在云中。這就是 CXL 的用武之地。英特爾、AMD 和多個 Arm 合作伙伴已經(jīng)加入了該標(biāo)準(zhǔn)。帶有 CXL 的 CPU 將于今年晚些時候開始問世。此外，三星、美光和 SKHynix 三大 DRAM 制造商也都承諾支持該標(biāo)準(zhǔn)。

即使有硬件供應(yīng)商的廣泛支持，仍有很多問題需要回答。在硬件方面：應(yīng)該如何構(gòu)建內(nèi)存池以及如何平衡池大小與較大池的較高延遲？在軟件方面：如何管理這些池并將池暴露給guest操作系統(tǒng)，云工作負(fù)載可以容忍多少額外的內(nèi)存延遲？

在分布層：提供者應(yīng)如何在具有 CXL 內(nèi)存的機器上調(diào)度 VM，內(nèi)存中的哪些項目應(yīng)存儲在池中與直接連接的內(nèi)存中，它們能否預(yù)測內(nèi)存行為和延遲敏感性有助于產(chǎn)生更好的性能，如果是，準(zhǔn)確度如何這些是預(yù)測嗎？

微軟提出了這些問題，并試圖回答這些問題。我們將在這里概述他們的發(fā)現(xiàn)。他們的第一代的解決方案架構(gòu)取得了令人印象深刻的成果。

隨著未來 CXL 版本的推出和延遲降低，這些收益可能會進(jìn)一步擴大。

首先是硬件層。Microsoft 使用直接連接到 8 到 32 個插槽 CPU 的多端口外部存儲器對此進(jìn)行了測試。內(nèi)存擴展是通過連接 CXL 的外部內(nèi)存控制器 (EMC) 完成的，該控制器具有四個 80 位 ECC DDR5 池 DRAM 通道和多個 CXL 鏈路，以允許多個 CPU 插槽訪問內(nèi)存。此 EMC 管理請求并跟蹤分配給各個主機的各個內(nèi)存區(qū)域的所有權(quán)。

CXL x8 通道的帶寬約為 DDR5 內(nèi)存通道的帶寬。每個 CPU 都有自己更快的本地內(nèi)存，但它也可以訪問具有更高延遲的 CXL 池化內(nèi)存，相當(dāng)于單個 NUMA 躍點?？?CXL 控制器和 PHY、可選重定時器、傳播延遲和外部存儲器控制器的延遲增加了 67ns 到 87ns。

下圖顯示了當(dāng)前本地 DRAM 的固定百分比（10%、30% 和 50%）切換到池化資源。池化內(nèi)存與本地內(nèi)存的百分比越大，節(jié)省的 DRAM 就越多。就 DRAM 節(jié)省而言，增加Socket數(shù)量會很快消失。

雖然更大的池大小和更多的socket看起來是最好的選擇，但這里有更多的性能和延遲影響。如果池大小降為 4 到 8 個 CPU 插槽，則不需要重定時器。這將延遲從 87ns 降低到 67ns。此外，在這些較小的插槽數(shù)中，EMC 可以直接連接到所有 CPU 插槽。

更大的 32 個插槽池將 EMC 連接到不同的 CPU 子集。這將允許在更多數(shù)量的 CPU 插槽之間共享，同時保持 CPU 端口的 EMC 設(shè)備數(shù)量固定。這里需要重定時器，這導(dǎo)致每個方向的延遲為 10ns。

在軟件方面，解決方案相當(dāng)巧妙。

Microsoft 經(jīng)常部署多插槽系統(tǒng)。在大多數(shù)情況下，VM 足夠小，它們完全適合單個 NUMA 節(jié)點、內(nèi)核和內(nèi)存。Azure 的管理程序嘗試將所有核心和內(nèi)存放在單個 NUMA 節(jié)點上，但在極少數(shù)情況下（2% 的時間），VM 有一部分資源跨越socket。這不會暴露給用戶。

內(nèi)存池在功能上的工作方式相同。內(nèi)存設(shè)備將作為零核虛擬 zNUMA 節(jié)點公開，沒有內(nèi)核，只有內(nèi)存。內(nèi)存偏離這個 zNUMA 內(nèi)存節(jié)點，但允許溢出。粒度（granularity）是每片內(nèi)存 1GB 。

分布式系統(tǒng)軟件層依賴于對 VM 的內(nèi)存延遲敏感度的預(yù)測。未觸及的存儲被稱為“frigid memory”。Azure 估計第 50 個百分位的 VM 具有 50% 的冷（frigid）內(nèi)存。這個數(shù)字似乎很圓。預(yù)計對內(nèi)存延遲不敏感的 VM 完全支持池 DRAM。為內(nèi)存敏感的 VM 配置了一個 zNUMA 節(jié)點，僅用于它們的冷內(nèi)存。預(yù)測是在虛擬機部署時完成的，但它是異步管理的，并在檢測到預(yù)測不正確時更改虛擬機放置。

這些算法的準(zhǔn)確性對于節(jié)省基礎(chǔ)設(shè)施成本至關(guān)重要。如果操作不當(dāng)，性能影響可能會很大。

考慮到潛在的性能影響可能是巨大的，將云居民（cloud resident）的內(nèi)存移動到 67ns 到 87ns 的池中是非常糟糕的。

因此，Microsoft 在兩種情況下對 158 個工作負(fù)載進(jìn)行了基準(zhǔn)測試。一種是只有本地 DRAM 的控制。另一個是模擬 CXL 內(nèi)存。應(yīng)該強調(diào)的是，盡管英特爾早前聲稱其支持 Sapphire Rapids CXL 的平臺將于 2021 年底推出?；蛘呗暦Q Sapphire Rapids 將于 2022 年初推出。因此，微軟必須模擬延遲影響。Microsoft 使用了 2 路 24C Skylake SP 系統(tǒng)。

當(dāng)帶寬超過 80GB/s 時，內(nèi)存訪問延遲為 78ns。當(dāng)一個 CPU 跨 NUMA 邊界訪問另一個 CPU 的內(nèi)存時，會導(dǎo)致額外的 64ns 內(nèi)存延遲。這非常接近外部存儲設(shè)備 (EMC) 在低插槽數(shù)系統(tǒng)中的 67ns 額外延遲。

20% 的工作負(fù)載沒有性能影響。另有 23% 的工作負(fù)載出現(xiàn)了不到 5% 的減速。25% 的工作負(fù)載嚴(yán)重減速，性能下降超過 20%，其中 12% 的工作負(fù)載甚至出現(xiàn)超過 30% 的性能下降。根據(jù)工作負(fù)載的本地與池內(nèi)存量，該數(shù)字會發(fā)生相當(dāng)大的變化。

這進(jìn)一步強調(diào)了預(yù)測模型的重要性。Microsoft 的基于隨機森林（random forest） ML 的預(yù)測模型更準(zhǔn)確，并且產(chǎn)生的誤報減速更少。隨著更多的內(nèi)存被池化，越多變得越重要。

隨著 CXL 規(guī)范的改進(jìn)、延遲的降低和預(yù)測模型的改進(jìn)，內(nèi)存池節(jié)省的可能性可能會增長到云服務(wù)器成本的兩位數(shù)百分比

審核編輯 ：李倩