Cloudflare 為第十代邊緣伺服器選擇 AMD 處理器

每天有超過 11 億個唯一 IP 位址透過 Cloudflare 網路； 它每秒處理超過 100 萬個 HTTP 請求； 她與 95% 的網路人口的差距在 200 毫秒之內。 我們的網路覆蓋 90 多個國家的 XNUMX 個城市，我們的工程師團隊建立了極其快速、可靠的基礎設施。

我們對我們的工作感到非常自豪，並致力於幫助使網路變得更好、更安全。 Cloudflare 的硬體工程師對伺服器及其元件有深入的了解，可以了解並選擇最佳硬體以最大限度地提高其效能。

我們的軟體堆疊可處理高負載運算，並且高度依賴 CPU，這要求我們的工程師在堆疊的每個層級不斷優化 Cloudflare 的效率和可靠性。 在伺服器端，提高處理能力最簡單的方法是添加 CPU 核心。 伺服器可以容納的核心越多，它可以處理的資料就越多。 這對我們來說很重要，因為我們的產品和客戶的種類隨著時間的推移而不斷增加，而請求的成長需要伺服器效能的提升。 為了提高它們的性能，我們需要增加核心的密度 - 這正是我們所實現的。 下面我們提供了自 2015 年以來部署的伺服器處理器的詳細數據，包括核心數：

-
6
7
8
9

入門
2015
2016
2017
2018

中央處理器
英特爾至強E5-2630 v3
英特爾至強E5-2630 v4
Intel Xeon Silver 4116
英特爾至強白金 6162

物理核心
2 8點¯x
2 10點¯x
2 12點¯x
2 24點¯x

TDP
2 X 85W
2 X 85W
2 X 85W
2 X 150W

每個核心的 TDP
10.65W
8.50W
7.08W
6.25W

2018 年，我們透過 Gen 9 在每台伺服器的核心總數上實現了巨大飛躍。 與第 33 代相比，環境影響減少了 8%，使我們有機會增加每個機架的容量和運算能力。 散熱設計要求（熱設計功率、TDP）是為了強調我們的能源效率也隨著時間的推移而提高。 這個指標對我們來說很重要：首先，我們要向大氣中排放較少的碳； 其次，我們希望充分利用資料中心的能源。 但我們知道我們有一些值得努力的事情。

我們的主要定義指標是每瓦特的請求數量。 我們可以透過添加核心來增加每秒的請求數，但我們需要保持在功率預算範圍內。 我們受到資料中心電力基礎設施的限制，它與我們選擇的配電模組一起，為我們每個伺服器機架提供了一定的上限。 將伺服器添加到機架會增加功耗。 如果我們超過每個機架的能源限制並且必須添加新機架，營運成本將顯著增加。 我們需要提高處理能力，同時保持在相同的功耗範圍內，這將增加每瓦請求數，這是我們的關鍵指標。

正如您可能已經猜到的，我們在設計階段就仔細研究了能耗。 上表顯示，如果每個核心的 TDP 高於當前世代，我們不應該浪費時間部署更多耗能的 CPU - 這將對我們的指標（每瓦請求數）產生負面影響。 我們仔細研究了市場上 X 代的現成運作系統並做出了決定。 我們正在從 48 核心 Intel Xeon Platinum 6162 雙插槽設計轉向 48 核心 AMD EPYC 7642 單插槽設計。

-
Intel英特爾
AMD

中央處理器
至強Platinum 6162
EPYC 7642

微架構
《天湖》
“禪宗2”

代碼名稱
“天湖 SP”
“羅馬”

技術流程
14nm
7nm

核心
2 24點¯x
48

頻率
1.9 GHz
2.4 GHz

L3 快取/插槽
24×1.375MiB
16×16MiB

記憶體/插槽
6 通道，最高可達 DDR4-2400
8 通道，最高可達 DDR4-3200

TDP
2 X 150W
225W

PCIe/插槽
48 Lanes
128 Lanes

ISA
x86 64
x86 64

從規格中可以清楚地看出，AMD 的晶片將允許我們在降低 TDP 的同時保持相同數量的核心。 第 9 代的每核心 TDP 為 6,25 W，第 X 代為 4,69 W。 減少 25%。 由於頻率的增加，或許還有一個插槽的更簡單的設計，可以認為AMD晶片在實踐中會表現得更好。 我們目前正在運行各種測試和模擬，看看 AMD 的表現會好多少。

現在，我們要注意的是，TDP 是製造商規格的簡化指標，我們在伺服器設計和 CPU 選擇的早期階段使用了該指標。 谷歌快速搜尋顯示，AMD 和英特爾定義 TDP 的方法不同，導致該規範不可靠。 真實的CPU功耗，更重要的是伺服器功耗，才是我們在做出最終決定時真正使用的。

生態系準備狀況

為了開始選擇下一代處理器，我們研究了來自不同製造商的各種 CPU，這些 CPU 非常適合我們的軟體堆疊和服務（以 C、LuaJIT 和 Go 編寫）。 我們已經詳細描述了一套測量速度的工具 在我們的一篇部落格文章中。 在這個例子中，我們使用了相同的設定 - 它使我們能夠在合理的時間內評估 CPU 的效率，之後我們的工程師可以開始使我們的程式適應特定的處理器。

我們測試了具有不同核心數量、插槽數量和頻率的各種處理器。 由於本文是關於我們選擇 AMD EPYC 7642 的原因，因此本部落格中的所有圖表都專注於 AMD 處理器與 Intel Xeon Platinum 6162 相比的效能 我們的第九代.

結果對應於具有每種處理器變體的單一伺服器的測量結果- 即具有兩個來自Intel 的24 核處理器，或具有一個來自AMD 的48 核處理器（Intel 伺服器具有兩個插槽，AMD EPYC伺服器具有一個插槽） 。 在BIOS中我們設定與正在運行的伺服器相對應的參數。 AMD 為 3,03 GHz，Intel 為 2,5 GHz。 大大簡化後，我們預計在相同數量的核心下，AMD 的效能將比 Intel 好 21%。

密碼學

AMD 看起來很有希望。 它在公鑰加密方面的效能提高了 18%。 使用對稱金鑰時，它會失去 AES-128-GCM 加密選項，但整體效能相當。

壓縮

在邊緣伺服器上，我們壓縮大量資料以節省頻寬並提高內容交付速度。 我們透過 C 庫 zlib 和 brotli 傳遞資料。 所有測試均在記憶體中的 blog.cloudflare.com HTML 檔案上運行。

使用 gzip 時 AMD 平均獲勝 29%。 就 brotli 而言，在我們用於動態壓縮的品質為 7 的測試中，結果甚至更好。 在 brotli-9 測試中，出現了急劇下降 - 我們透過 Brotli 消耗大量記憶體並溢出快取這一事實來解釋這一點。 然而，AMD以較大優勢獲勝。

我們的許多服務都是用 Go 寫的。 在下圖中，我們使用字串庫在 32 KB 行上透過 RegExp 仔細檢查了 Go 中的加密和壓縮速度。

去密碼學

去壓縮

去正規表達式

圍棋弦樂

AMD 在 Go 的所有測試中都表現得更好，除了 ECDSA P256 Sign，它落後了 38%——這很奇怪，因為它在 C 中的表現要好 24%。 值得弄清楚那裡發生了什麼事。 總體而言，AMD 獲勝不多，但仍顯示出最好的成績。

LuaJIT

我們經常在堆疊上使用LuaJIT。 這是將 Cloudflare 所有部分黏合在一起的黏合劑。 我們很高興 AMD 也在這裡獲勝。

總體而言，測試表明EPYC 7642 的性能優於兩個Xeon Platinum 6162。AMD 在多項測試中失敗- 例如AES-128-GCM 和Go OpenSSL ECDSA-P256 Sign - 但平均而言，在所有其他測試中獲勝25% 。

工作負載模擬

經過快速測試後，我們透過另一組模擬運行伺服器，其中將合成負載應用於軟體邊緣堆疊。 這裡我們模擬一個場景工作負載，其中包含實際工作中可能遇到的不同類型的請求。 請求因資料量、HTTP 或 HTTPS 協定、WAF 來源、Workers 和其他許多變數而異。 下面是兩個 CPU 對於我們最常遇到的請求類型的吞吐量的比較。

圖表中的結果是根據第 9 代基於 Intel 的機器的基線進行測量的，x 軸上的值標準化為 1,0。 例如，透過 HTTPS 取得簡單的 10 KiB 請求，我們可以看到 AMD 在每秒請求數方面比 Intel 好 1,5 倍。 平均而言，AMD 在這些測試中的表現比英特爾高出 34%。 考慮到單一 AMD EPYC 7642 的 TDP 為 225 W，兩個 Intel 處理器的 TDP 為 300 W，事實證明，就「每瓦請求數」而言，AMD 的結果是 Intel 的 2 倍！

此時，我們已經明顯傾向於 AMD EPYC 7642 作為我們未來的 X 代 CPU 的單插槽選項。我們非常有興趣了解 AMD EPYC 伺服器在實際工作中的表現，我們立即發送了幾個伺服器到一些資料中心。

實際工作

當然，第一步是讓伺服器做好實際工作的準備。 我們機隊中的所有機器都使用相同的流程和服務，這為正確比較性能提供了絕佳的機會。 與大多數資料中心一樣，我們部署了幾代伺服器，並將伺服器收集到叢集中，以便每個類別都包含大致相同世代的伺服器。 在某些情況下，這可能會導致群集之間的回收曲線不同。 但不是我們。 我們的工程師對各代的CPU利用率進行了最佳化，因此無論特定機器的CPU是8核心還是24核，CPU利用率通常與其他機器相同。

該圖說明了我們對利用率相似性的評論 - X 代伺服器中使用 AMD CPU 和第 9 代伺服器中使用 Intel 處理器之間沒有顯著差異。這意味著測試伺服器和基準伺服器的負載相同。 偉大的。 這正是我們在伺服器中努力追求的目標，我們需要這個來進行公平的比較。 下面兩張圖顯示了伺服器層級一個 CPU 核心和所有核心處理的請求數。

每個核心的請求數

向伺服器發出請求

可以看出，AMD 平均多處理 23% 的請求。 一點也不差！ 我們經常在部落格上撰寫有關提高第 9 代效能的方法。現在我們擁有相同數量的核心，但 AMD 以更少的功耗完成更多的工作。 從核心數量和 TDP 的規格中可以清楚地看出，AMD 提供了更高的速度和更高的能源效率。

但正如我們已經提到的，TDP並不是一個標準規格，對於所有製造商來說也不是一樣的，所以讓我們看看實際的能源使用情況。 透過並行測量伺服器的能耗與每秒請求數，我們得到了下圖：

根據每瓦每秒請求數計算，運行在 AMD 處理器上的 X 代伺服器的效率提高了 28%。 鑑於 AMD 的 TDP 降低了 25%，人們可以期待更多，但應該記住，TDP 是一個模糊的特性。 我們發現，在遠高於基準頻率的情況下，AMD 的實際功耗與標稱的 TDP 幾乎相同； 英特爾沒有這個。 這是 TDP 不是可靠的能源消耗估算的另一個原因。 我們的第 9 代伺服器中的 Intel CPU 整合到多節點系統中，而 AMD 的 CPU 在標準 1U 外形伺服器中運作。 這對 AMD 不利，因為多節點伺服器應該提供更高的密度，同時每個節點的功耗更低，但 AMD 在每個節點的功耗方面仍然超過了英特爾。

在大多數規格、測試模擬和實際性能的比較中，1P AMD EPYC 7642 配置的性能明顯優於 2P Intel Xeon 6162。在某些情況下，AMD 的性能可以提高高達 36%，我們相信透過優化硬體和軟體，我們可以持續實現這項改進。

結果AMD贏了。

其他圖表顯示 99 小時內運行 NGINX 的平均延遲和 p24 延遲。 平均而言，AMD 上的進程運行速度快了 25%。 在 p99 上，它的運行速度會快 20-50%，具體取決於一天中的時間。

結論

Cloudflare 的硬體和效能工程師進行了大量的測試和研究，以確定適合我們客戶的最佳伺服器配置。 我們喜歡在這裡工作，因為我們可以解決此類大問題，我們可以透過無伺服器邊緣運算等服務以及 Magic Transit、Argo Tunnel 和 DDoS 保護等一系列安全解決方案來幫助您解決問題。 Cloudflare 網路中的所有伺服器均配置為可靠運行，我們始終努力使每一代伺服器都比前一代伺服器更好。 我們相信 AMD EPYC 7642 是 X 代處理器的答案。

使用 Cloudflare Workers，開發人員可以將他們的應用程式部署在我們遍布全球的不斷擴展的網路上。 我們很自豪能夠讓我們的客戶專注於編寫程式碼，而我們專注於雲端中的安全性和可靠性。 今天，我們更高興地宣布，他們的工作將部署在運行第二代 AMD EPYC 處理器的 X 代伺服器上。

EPYC 7642 處理器，代號「Rome」[羅馬]

透過使用 AMD EPYC 7642，我們能夠提高效能並更輕鬆地將網路擴展到新城市。 羅馬不是一天造成的，但它很快就會離你們許多人更近。

在過去幾年中，我們一直在嘗試使用 Intel 和 AMD 的許多 x86 晶片以及 ARM 的處理器。 我們期待這些CPU廠商未來能繼續與我們合作，共同建置更美好的網路。

來源： www.habr.com