介紹

當前，使用全 NVMe 存儲的需求，徹底改變了 Ceph 的存儲能力及其競爭領域。多年來，Ceph 憑借能夠使用普通的常規硬盤（HDD） 以高性價比的特性被大量使用。這使其成為滿足海量對象存儲需求的首選。但是，機械磁盤的物理速度總是限制其性能，當涉及到需要極高性能，極高響應速度的應用場景時，總是不如一些專用的商業存儲。

NVMe （Non-Volatile Memory Express） 給了 Ceph 一個比較好的選擇，讓 Ceph 能夠打破性能瓶頸。

當將 Ceph 的智能分布式軟件與每秒可以處理數百萬次作且延遲接近零的 NVMe 存儲相結合時，我們將得到一個可以與高端專用的商業存儲正面交鋒的解決方案。這也為 Ceph 在私有云和混合云中運行要求苛刻的應用（如大規模數據庫、AI/ML 訓練和高性能計算） 提供了比較好的解決方案。

但要獲得這種性能，并非簡單地將原來 HDD 舊硬盤換成新 NVMe 驅動器那么簡單。硬件的原始速度非常快，但是，依然會在系統的其他地方存在一些新的性能瓶頸。如果沒有適當的調優，最終可能只獲得新驅動器的十分之一性能。運行一個高性能的全 NVMe Ceph 集群實際上是一項挑戰：必須在 CPU、網絡和軟件設置中找出并消除瓶頸，以充分發揮閃存存儲的全部性能。

性能潛力

當進行過正確的架構和調優時，全 NVMe Ceph 集群的性能確實令人驚嘆。最近 Ceph 版本的基準測試報告顯示，其性能已穩居高性能存儲之列。

例如，在一個包含 10 個節點、60個 NVMe 驅動器 并運行 Ceph Reef 的集群上進行的詳細測試，產生了一些驚人的結果。該集群實現了約 440 萬的隨機讀取 IOPS（每秒輸入/輸出操作）和 71 GB/s的大文件持續讀取速度。在數據寫入方面，它處理了約 80 萬的隨機寫入 IOPS。由于 Ceph 默認會為使用三個副本來確保安全，這實際上意味著整個集群的驅動器上發生了 240 萬次寫入操作。而對于需要即時響應的應用（如數據庫），該集群的平均寫入延遲保持在 0.5 毫秒以下。

需要注意的是，這些并非默認初始設置就可以達到的性能。它們來自一個特定的、均衡的硬件配置——在本例中是配備 AMD EPYC CPU 和三星 NVMe 驅動器的戴爾服務器——以及大量稍后將詳細介紹的精心調優。這些基準測試表明，當有明確計劃地構建集群時，可以實現什么。

來源：

Ceph Reef RBD 性能基準: https://ceph.io/en/news/blog/2023/reef-freeze-rbd-performance/

讀取和寫入性能之間的最大差異歸結為 Ceph 的工作原理。讀取很簡單：Ceph 只需從一個主存儲守護程序 （OSD） 中獲取數據。寫入則更復雜。使用 3 倍復制時，Ceph 必須將數據發送到主 OSD，然后主 OSD 將其復制到其他兩個 OSD。在將寫入標記為完成之前，它必須得到所有 OSD 的確認。這一點，再加上 Ceph 的 BlueStore 后端為管理元數據所做的工作，使得寫入數據自然比讀取數據慢。 基準測試清楚地顯示了這一點 ，隨機操作的讀取速度是寫入的五倍以上，大文件的讀取速度也快了近三倍。

通過這些，我們可以知道該集群適合那些場景。全 NVMe Ceph 非常適合數據分析、內容交付網絡 （CDN） 和 AI 推理等讀取密集型工作。對于數據庫或日志記錄等寫入密集型任務，它仍然非常快，但需要確保性能是否是該應用期望的寫入性能值，以盡可能提高寫入效率。我們的目標不僅僅是購買更高性能的硬件，而是從一開始就構建一個完整的高性能存儲系統。

基礎：實現最佳性能的硬件和架構

在傳統的的 Ceph 集群中，瓶頸幾乎總是驅動器本身。而在全 NVMe 集群中，情況正好相反。NVMe 驅動器速度非常快，以至于影響性能壓力往往是服務器的其他方面：CPU、內存和網絡。這意味著我們必須采用相對均衡的方法來設計集群，選擇每個組件以支持 NVMe 驅動器可以實現的大量 I/O。

CPU: 存儲的新引擎

使用 NVMe，CPU 不再僅僅是運行操作系統，它也在主動驅動存儲。每一次 I/O 操作都需要 CPU。Ceph 的算法需要計算數據存放位置，糾刪碼需要數學計算來創建校驗位，校驗和的計算是為了保證數據安全，而 BlueStore 后端使用的名為 RocksDB 的數據庫也需要 CPU 算力來處理元數據。

測試表明，速度與為每個 NVMe 驅動器分配的 CPU 線程數成正比。在 Ceph Reef 版本中，單個 OSD 在大約 14-16 個 CPU 線程后性能提升就不再明顯（https://docs.clyso.com/blog/reef-osds-per-nvme/）。這意味著需要具有大量核心的 CPU 來處理一臺服務器上的多個 OSD。由 Clyso 構建的破紀錄的 1 TiB/s 集群（https://www.clyso.com/us/a-journey-to-1-tib-s-a-milestone-in-performance/），在其 68 個節點中的每一個都使用了強大的 48 核 AMD EPYC 9454P CPU，以獲得同時運行數百個 NVMe OSD 所需的并行處理能力（稍后會詳細介紹）。在全 NVMe 構建中試圖節省 CPU 開銷，是導致集群緩慢、瓶頸的必然因素。

存儲驅動器：企業級是硬性要求

構建全 NVMe Ceph 集群時，最大且代價最高的錯誤之一是使用消費級 NVMe 驅動器。它們前期看起來可能更便宜，但它們缺少企業存儲絕對必需的兩樣東西：寫入耐久性和掉電保護（PLP）。

企業應用，尤其是在像 Ceph 這樣總是在后臺工作的系統上，可能是寫入密集型的。企業級 SSD 為此而生，企業級 SSD 有一個“每日驅動器寫入次數”（DWPD）的評級，這個會表明在其 5 年保修期內，每天可以向整個驅動器寫入多少次。以讀取為主的的企業級驅動器通常 DWPD 低于 1，混合用途驅動器評級為 1 到 3，而以寫入為主的可以超過 3。

更重要的是掉電保護。企業級驅動器板載電容器，在斷電時，能提供足夠的電力將驅動器臨時緩存中的數據保存到永久閃存中。沒有這個功能，可能會丟失正在寫入過程中的數據，導致靜默數據損壞。這對于依賴其日志和元數據完整性的 Ceph BlueStore 來說是致命的。正如一位在 Reddit 上嘗試使用消費級驅動器的用戶發現的那樣，結果是“平庸”的速度和在任何實際寫入負載下都“飆升”的延遲(https://www.reddit.com/r/ceph/comments/mp121c/ceph_nvme/)。

網絡：集群的核心

網絡是 Ceph 集群的神經系統。它處理從客戶端流量和數據復制到重新平衡，以及最重要的——故障后恢復的所有事情。10GbE/10Gbps 網絡可能是生產環境的最低要求，但對于全 NVMe 集群來說遠遠不夠。基準測試表明，單個客戶端讀取大文件就可以完全占滿一個 10GbE 鏈接。

對于嚴格的全 NVMe Ceph 集群的配置，都需要 25GbE、40GbE 甚至 100GbE 的網絡。達到 1 TiB/s 的集群在每個節點中都使用了兩張 100GbE 網卡，這表示在極高性能場景下需要什么樣的帶寬。網絡速度不高快在恢復期間會成為最大的問題。當一個驅動器或服務器發生故障時，Ceph 開始將其數據復制到集群中的其他地方以恢復完全冗余。這會跑滿網絡。較慢的網絡會使這個恢復窗口變得更長，使集群處于危險的降級狀態，并增加再次故障導致數據丟失的風險。

合理的硬件

選擇一個適合的硬件環境是非常重要的，也是實現超高性能存儲的必備條件，這也是本文的目的。本文也將提供已經經過驗證并準備好應對嚴苛的 OpenStack 和 Ceph 工作負載的硬件配置。像“Large”和“XL”這樣的服務器選項提供了一個堅實的基礎，配備了高核心數 CPU（16-32 核）、充足的 RAM（1TB）以及對每個服務器多個 NVMe 驅動器的支持。對于存儲密集型需求，像 Large v3 這樣的服務器混合了高容量 HDD 和 NVMe 閃存選項以加快速度。具體配置如下：

Large V2/V3/V4

• 16 核，32 線程
• 512GB 內存
• 2 個 6.4 TB NVMe SSD（每臺服務器最多 6 個）
• 20Gbps 上行鏈路

XL V2/V3/V4

• 32 核，64 線程
• 1TB 內存
•  4 個 6.4 TB NVMe SSD（每臺服務器最多 10 個）
• 20Gbps 上行鏈路

通過上述提供的這些預先驗證的配置，免去了硬件選擇的復雜性。下面就可以在一個準備好用于高性能私有云的平臺上進行部署，從而避免一些可能導致系統緩慢和不穩定的常見錯誤。

硬件選擇決定了集群的性能上限。再多的軟件調優也無法彌補 CPU 性能不足、網絡緩慢或驅動器不可靠的問題。頂級基準測試始終使用高核心數 CPU 和 100GbE 網絡說明了一個明確的情況：頂級性能需要頂級硬件。這也需要成為預算規劃的一部分。試圖在 CPU 或網絡上省錢來購買更多 NVMe 容量，只會留下一個不平衡的系統，無法滿足對性能的期望。

關于集群的物理設計，還有一個重要的選擇要做。現代服務器可以容納十個或更多的 NVMe 驅動器，這帶來了一個需要思考的新問題：服務器故障的“影響范圍”。存儲密集的節點更便宜，但如果其中一臺服務器發生故障，會引發大規模的數據恢復事件。據估計，從一臺丟失的 60 驅動器服務器中恢復可能需要長達兩個月的時間，在此期間，集群一直處于高風險狀態。這迫使我們必須在更少、更密集的節點（前期成本更低，但風險更高）和更多、密度更低的節點（成本更高，但風險更低、恢復更快）之間做出選擇。這個決定不僅僅是涉及性能的考量，也是一個成本與風險的綜合考量。

性能調優：系統和 Ceph 級別調優

第一步是從最基礎的企業級硬件開始。但是，要讓系統以及應用程序獲取硬件的實際性能，需要進行一些針對性的調優。這些調優（范圍從服務器的 BIOS 到 Ceph 的配置文件）區分普通集群和高性能集群的關鍵。通常，最大的好處是來自 Ceph 本身之外進行的更改。

系統級調優

在啟動 Ceph 進程之前，通過最基礎的兩個優化，可以獲取明顯的性能提升。這兩個最有效的更改是：關閉旨在節省電源和管理設備的功能，因為它們會增加延遲，這對高性能存儲系統不利。

禁用 CPU 節能 （C-states）

現代 CPU 使用 C-states 的節能模式，在空閑時消耗更少的資源。當 CPU 核心無事可做時，操作系統可以將其置于“睡眠”狀態（C1、C2 等），關閉其時鐘和緩存等部分以節省電力。這對于臺式機來說哼不錯，但對于需要始終保持快速的存儲系統來說，卻是性能殺手。

CPU 從深度 C-state “喚醒”的過程不是瞬時的；它會增加一個微小但關鍵的延遲。對于像 Ceph 這樣需要在微秒內響應請求的存儲系統，這種喚醒延遲會使性能不一致。我們可以發現，僅僅在服務器 BIOS 中關閉 C-states，就立即為他們帶來了 10-20% 的性能提升。對于任何全 NVMe Ceph 配置，將 CPU 設置為“性能”模式并禁用 C-states 是必須做的第一步。

禁用 IOMMU （VT-d/AMD-Vi）

輸入/輸出內存管理單元（IOMMU）是一種硬件功能，它為設備創建一個虛擬內存層。它允許將設備直接傳遞給虛擬機，并保護系統內存免受故障設備的影響。

但這種保護是有代價的。IOMMU 必須為每一次 I/O 操作轉換內存地址，這會給每個請求增加一點開銷和延遲。在一個受信任的、專用的存儲環境中，這個轉換層是一個不必要的性能損失。Clyso 團隊發現大量 CPU 時間被浪費在與 IOMMU 相關的操作上。在內核級別關閉 IOMMU，通過消除這種開銷，為他們帶來了“實質性的性能提升”。雖然這不適用于所有環境，但對于裸機、以性能為中心的 Ceph 集群來說，這是一個關鍵的優化。

一個 NVMe，到底該配幾個 OSD？

對 Ceph 而言，做出的最大調優決策之一是在每個 NVMe 驅動器上運行多少個 OSD 守護進程。過去，由于閃存速度較慢，因此每個驅動器運行多個 OSD 是提高其性能的好方法。對于當今的超高速 NVMe 驅動器和現代 Ceph，選擇變得更加復雜。這是原始速度和一致延遲之間的直接權衡 。

使用 Ceph Reef 的測試顯示了兩種主要策略：

• 每個 NVMe 一個 OSD：這是最簡單的設置。它通常提供寫入大型順序文件的最佳速度，并且在 CPU 上更容易。如果集群沒有大量額外的 CPU 能力，或者主要作業是流式傳輸大文件，例如用于視頻存儲或備份，則建議使用此默認值。
• 每個 NVMe 兩個 OSD：此設置需要更多的 CPU 和內存，但對于對延遲敏感的應用程序來說，它有很大的優勢。測試表明，每個驅動器運行兩個 OSD 可以將第 99 個百分位的尾部延遲減少一半。它還可以在 CPU 密集型環境中獲得更多 IOPS（例如，如果每個 NVMe 驅動器有 16 個或更多 CPU 線程）。這使其成為虛擬桌面 （VDI） 或數據庫等的更好選擇，在這些應用中，可預測的快速響應時間比獲得絕對的最大吞吐量更重要。

這里沒有正確或錯誤的答案。這是關于將集群的設置與主要應用程序的需求相匹配。我們必須了解，優化平均延遲與優化尾部延遲不同，后者是用戶的實際感受。

必要的 ceph.conf和 BlueStore 設置

除了 OSD 布局之外，其他一些 Ceph 設置也是性能的關鍵：

• 內存分配： BlueStore 后端使用大量內存來緩存元數據。ceph.conf 文件中的 osd_memory_target 設置應為每個 OSD 至少 8GB，以確保它有足夠的內存來工作，而不必不斷從速度較慢的驅動器中讀取數據。如果有足夠的 RAM，則分配更多的內存可以進一步提高性能。
• RocksDB 編譯：在高性能測試期間發現的一個棘手問題是，某些 Linux 發行版的標準 Ceph 軟件包沒有使用 RocksDB 的最佳設置進行編譯。這會導致數據庫作變慢和寫入性能受限。為了獲得頂級性能，必須確保 Ceph 是使用優化的 RocksDB 構建的。
• 網絡配置：在集群的內部網絡上， 通過將 MTU（最大傳輸單位）設置為 9000 來啟用巨型幀是一種標準的最佳實踐。這樣，可以在每個網絡數據包中發送更多數據，從而減少需要處理的數據包數量并降低 CPU 使用率。

以下是這些基本調優設置的快速清單，可幫助用戶充分調優全 NVMe Ceph 集群。

實際結果：簡解 1 TiB/s Ceph 集群

基準測試和優化指南是一個不錯的開始，但真正的考驗是了解這些在真實的環境中是如何工作的。2024 年初，Ceph 咨詢公司 Clyso 的一個團隊承擔了一個項目，該項目突破了人們認為 Ceph 可能的極限。他們構建并優化了一個全 NVMe 集群，打破了 1 TB/秒 （TiB/s） 的速度限制 (https://www.clyso.com/us/a-journey-to-1-tib-s-a-milestone-in-performance/)，為我們提供了高性能存儲方面的強大案例研究。

挑戰和硬件

目標很宏大：將現有的基于 HDD 的集群遷移到新的 10 PB 全 NVMe 設置，而無需任何停機時間。他們使用的硬件令人印象深刻。最終設置有 68 臺 Dell PowerEdge R6615 服務器。每臺服務器都是一個性能野獸，配備一個 48 核 AMD EPYC 9454P CPU、192GiB DDR5 RAM、兩個 100GbE Mellanox 網卡和十個 15.36TB 戴爾企業級 NVMe 驅動器。該硬件因其高內存帶寬、大量 CPU 內核和極快的網絡速度而被特別選擇，從而構建了一個可以跟上快速驅動器的超高性能集群。

從失望到突破

即使擁有所有這些強大的硬件， 第一次測試也令人大失所望 。性能遠低于他們的預期，更糟糕的是，它不一致。它會隨著時間的推移而變慢，只有在完全重啟后才會變得更好。這導致了一項深入調查，發現了幾個棘手的系統級瓶頸。他們找到的修復程序證明，我們討論的優化策略確實有效：

• 問題：延遲尖峰。第一個問題是不一致的延遲，這扼殺了性能。
• 解決方案：禁用 C-States。 團隊正確地猜測到 CPU 節能狀態導致了喚醒延遲。在 BIOS 中關閉 C-states，通過確保 CPU 始終處于活動和就緒狀態，立即為他們帶來了 10-20% 的性能提升。
• 問題：內核級瓶頸。 即使關閉了 C-states，性能仍然沒有達到應有的水平。使用內核級工具進行更深入的觀察顯示，大量時間被浪費在內核操作上。
• 解決方案：禁用 IOMMU。 團隊將此問題追溯到 IOMMU。通過使用內核啟動設置將其關閉，他們消除了每次 I/O 操作的地址轉換開銷，這帶來了另一次“實質性的性能提升”，尤其是在他們添加更多 NVMe 驅動器時。
• 問題：寫入性能差。 最后一個主要問題是出奇地慢的 4K 隨機寫入性能。
• 解決方案：修復 RocksDB 編譯。 調查發現，他們使用的標準 Ceph 軟件包沒有使用 RocksDB（驅動 BlueStore 的數據庫）的最佳設置進行編譯。通過使用正確的設置重新編譯 Ceph，RocksDB 的內部清理時間下降了，4K 隨機寫入性能基本上翻了一番。

這段歷程揭示了一個關鍵點：獲得頂級性能不是一個簡單的“安裝即用”的工作。它需要數據驅動的問題解決、深入的系統知識，以及愿意超越 Ceph 自身的設置，去審視底層的操作系統和硬件。

結果：將Ceph 推向極限

隨著這些修復措施的到位，集群的真正潛力終于被釋放出來。結果為 Ceph 的性能創下了新的公開記錄：

• 3 倍復制性能： 在其使用 3 倍復制的最快配置中，這個 63 節點、630 OSD 的集群實現了令人難以置信的 1025 GiB/s（略高于 1 TiB/s）的大文件讀取速度。對于小文件隨機讀取，它達到了 2550 萬 4K IOPS。這些數字表明，一個經過良好調優的大規模 Ceph 集群，其性能可以與最先進的專有存儲系統相媲美。
• 糾刪碼性能： 團隊隨后重新配置了集群，以使用 6+2 糾刪碼（EC）配置文件，這是客戶計劃用來獲得最大存儲效率的設置。即使有 EC 的額外工作，集群仍然提供了驚人的性能：讀取超過 500 GiB/s，寫入近 400 GiB/s。

這個案例研究為我們提供了一個寶貴的真實場景，讓我們了解了在全 NVMe 平臺上復制和糾刪碼之間的性能權衡。雖然 3 倍復制提供了絕對最佳的讀取性能，但糾刪碼以仍然巨大的速度（尤其是對于寫入）提供了巨大的存儲效率。

NVMe 上的 EC 性能與它在 HDD 上的表現完全不同。在機械磁盤上，EC 帶來的隨機 I/O 沖擊通常難以承受。但在 NVMe 上，驅動器速度非常快，以至于計算校驗和的 CPU 成本以及與多個節點通信的網絡成本成為新的瓶頸。

Clyso 的基準測試發現了一些可能看起來與我們默認理解相反的事情：在這個規模集群上，EC 寫入比復制寫入快得多。這是因為 EC 寫入同時分布在許多節點（K+M 個節點）上，而復制寫入則受限于逐個寫入三個節點的過程。另一方面，EC 讀取比復制讀取慢（500 GiB/s vs. 1 TiB/s）。EC 讀取必須從多個（K 個）OSD 獲取數據，并由客戶端的 CPU 將原始對象重新組合起來，這比從復制池中的單個 OSD 進行簡單讀取產生了更多的網絡流量和工作。對于任何構建高性能、全 NVMe Ceph 集群并使用糾刪碼的人來說，這是一個關鍵的設計選擇。

速度的經濟性：TCO 和成本效益

采用全 NVMe 存儲的最大障礙一直是成本。如果只看前期價格，以每 GB 美元 （$/GB） 為單位，與傳統的 HDD 系統相比，全閃存解決方案似乎太昂貴了。但這并不代表所有。完整的總擁有成本 （TCO） 分析，應該還包括電力、冷卻、機架空間和管理時間等運營成本。對于性能要求高的工作負載，全 NVMe Ceph 可能是一個不錯的選擇。

糾刪碼提高可用容量

使全 NVMe Ceph 集群變得經濟實惠的最重要方式是使用糾刪碼（EC）。在標準設置中，Ceph 使用 3 倍復制，這意味著它存儲每個數據片段的三個副本。這意味著有 200% 的額外存儲開銷；要存儲 1PB 的數據，則需要 3PB 的原始磁盤空間。

糾刪碼以少得多的開銷提供相同甚至更好的數據保護級別。例如，一個常見的 k = 4, m = 2（或 4+2）EC 配置文件，將數據分成四個“數據塊”并創建兩個“校驗塊”。此設置可以承受任何兩個 OSD 的故障，就像 3 倍復制一樣，但它只需要 1.5PB 的原始存儲空間就能提供 1PB 的可用空間——這是 50% 的額外開銷，而不是 200%。這基本上將原始存儲硬件成本減半。

在 HDD 集群上，糾刪碼的隨機 I/O 模式對性能的影響通常意味著它僅用于冷存檔。但在全 NVMe 集群上，基準性能非常高，以至于 EC 成為更廣泛的工作負載（包括暖數據甚至熱數據 ） 的絕佳且經濟高效的選擇 。

耗電、散熱和空間占用

全 NVMe 的 TCO 優勢遠不止存儲驅動器。閃存存儲在電力、散熱和空間方面效率要高得多。

• 功耗： 一個正常使用中的 3.5 英寸企業級 HDD 消耗 6 到 10 瓦，而一個正常使用中的企業級 NVMe SSD 通常消耗 3 到 8 瓦。當它們空閑時，差異更大，HDD 可以消耗 4-8W，而 NVMe 驅動器可以降至 0.5-2W。美光公司一項比較全 NVMe Ceph 集群與混合 HDD+NVMe 集群的研究發現，全 NVMe 配置效率要高得多，每 GBps 寫入速度的功耗低 46 倍，每 GBps 讀取速度的功耗低 16 倍。（https://www.micron.com/about/blog/storage/innovations/drop-hdd-from-your-object-storage-ceph-micron-6500-ion）
• 密度和占用空間： 因為它們在小空間內集成了非常高的性能，因此，只需要很少的全 NVMe 節點就可以獲得與基于 HDD 的集群相同的性能。同一項美光研究發現，需要 161 個基于 HDD 的節點才能匹配僅僅 6 個全 NVMe 節點的寫入性能。

耐力問題：管理長期成本

對于所有的閃存系統，需要考慮的一個有效長期成本是驅動器的寫入耐久性有限。如果計劃好，這是一個可控的問題。企業級 NVMe 驅動器提供一定寫入量的保修，以典型五年期間的每日驅動器寫入次數 （DWPD） 衡量。

管理此成本的關鍵是將驅動器的耐用性評級與工作負載的寫入量相匹配。一個普遍的誤解是，所有企業應用程序都需要昂貴的高耐用性驅動器。實際上，我們可以根據工作負載選擇驅動器 ：

• 讀取密集型工作負載 （如分析或存檔）可以使用 DWPD 為 1 或更低的更便宜、高容量的“讀取密集型”驅動器。
• 混合用途工作負載 （如通用虛擬機存儲或 Web 應用程序）與 DWPD 在 1 到 3 之間的主流“混合用途”驅動器一起使用。
• 寫入密集型工作負載 （如數據庫日志或高頻數據收集）是唯一通常需要 DWPD 大于 3 的高級“寫入密集型”驅動器的工作負載。

通過查看應用程序的 I/O 模式并選擇合適的企業級 NVMe 驅動器，可以避免在不需要的耐用性上超支，從而優化初始成本和長期更換成本。

下表提供了假設的 1PB 可用存儲集群的高級 TCO 比較，顯示了如何通過大幅的運營成本節省來平衡 NVMe 硬件較高的初始成本。

表格

注：值僅用于說明，取決于特定的硬件和電源成本。來源：

美光(https://www.micron.com/about/blog/storage/innovations/drop-hdd-from-your-object-storage-ceph-micron-6500-ion)

最終，全 NVMe Ceph 的主要經濟優勢不是更低的每 GB 成本，而是更低的每 IOPS 成本和每瓦特成本。當開始基于性能和運營效率而不是僅僅是容量來衡量時，全閃存的成本案例就變得非常有力。它還使數據中心更加簡單。混合陣列依賴復雜的緩存和分層在快速閃存和慢速 HDD 之間移動數據，這增加了管理工作并可能導致不可預測的性能。全閃存配置消除了這種復雜性，創建了一個單一的、高性能的層，更易于管理并提供更可預測的應用程序響應時間。

未來：Ceph Crimson 和 NVMe 存儲的未來

雖然，目前構建在穩定的 BlueStore 后端上的全 NVMe Ceph 集群提供了出色的性能，但 Ceph 社區一直知道，該平臺的原始設計并不是為現代存儲的微秒級延遲場景而設計的。為了真正釋放下一代硬件的全部潛力，社區正在進行重大重新設計。這個名為 Crimson 的項目是 Ceph 的未來，它表明了社區致力于保持存儲技術前沿的承諾。

問題：為什么傳統 Ceph 無法滿足需求

Ceph 是在物理磁盤（可以處理幾百 IOPS）是最常見場景的時代創建的。在這些場景中，CPU 有足夠的時間來管理每個 I/O 操作。隨著存儲變得越來越快，該時間已經急劇縮短。一個現代 NVMe 驅動器可以達到超過一百萬的 IOPS，這使得 CPU 只有幾千個周期來處理每個請求。

以往的 Ceph OSD 具有多線程設計，并不是為此場景設計的。其內部架構可能導致性能下降的上下文切換、線程爭奪鎖以及其他開銷，從而消耗寶貴的 CPU 周期并增加延遲。這是原始硬件可以執行的作與 Ceph 開箱即用提供的功能之間存在性能差距的主要原因。

解決方案：Crimson 和 SeaStore

Crimson 項目(https://ceph.io/en/news/crimson/) 是 Ceph 社區的說法，即要突破此限制，需要一種新的架構。這是對 Ceph OSD 的完全重寫，而不僅僅是一次更新。Crimson 基于 Seastar（一種用于高性能應用程序的高級 C++ 框架）構建，采用一組不同的規則進行設計。

它的主要目標是通過使用每核線程、無共享設計來減少 CPU 開銷和延遲。在此模型中，任務在 CPU 內核之間進行拆分，以避免線程必須相互通信和鎖定，從而允許在單個內核上盡可能不間斷地處理單個 I/O 。

除了這個新的 OSD 之外，還推出了 SeaStore，這是一個新的存儲后端，專為 NVMe 等快速、隨機訪問媒體而設計。SeaStore 最終將取代 BlueStore 成為 Crimson 的默認后端，提供更簡化、更高效的數據路徑，而不會受到支持 HDD 的遺留問題所拖累。

現狀和實現期望

開發新的存儲引擎是一項艱巨的工作。從長遠來看，BlueStore 本身花了兩年多 的時間才從一個想法到可用于生產。Crimson 和 SeaStore 是一個復雜程度相似的項目。

目前，Crimson 在最近的 Ceph 版本（如 Squid）和商業版本中作為技術預覽提供。這意味著它的功能尚未完成，例如，對糾刪碼的全面支持仍在開發中，不建議用于生產用途。將新的 Crimson OSD 與穩定的 BlueStore 后端配對的早期性能測試表明，其性能已經與傳統 OSD 一樣好或略好 。但是，當原生 SeaStore 后端完全成熟時，預計會出現真正的、顛覆性的性能改進。

在未來的一段時間內，高性能 Ceph 的生產部署仍然將繼續基于經過驗證、穩定且非常快速的經典 OSD 和 BlueStore。這種架構為當今最快的集群提供支持，包括比如上述提到的 1 TiB/s 系統。企業可以放心使用這些解決方案。因為這是當前部署的最成熟的技術，另外，也持續跟進 Crimson ，因為，這有希望在未來幾年獲取更多性能。總結就是：“現在穩定而強大，未來更快。

總結和關鍵要點

將全 NVMe 存儲與 Ceph 配對是開源存儲平臺向前邁出的一大步，將其從一個橫向擴展的集群轉變為一個可以與專業專有系統競爭的高性能機器。潛力是巨大的，基準測試顯示數百萬的 IOPS 和超過 1 TiB/s 的速度。然而，正如本文所示，那種性能并非開箱即用，它是有合理規劃且精心調優的結果。

以下是一些值得考慮的要點：

• 最佳性能是有條件的： 從全 NVMe Ceph 獲得最佳性能取決于合理的架構和具體的調優。NVMe 驅動器的原始速度將瓶頸轉移到系統的其他部分，這使得高內核數 CPU 和高帶寬 （25/100Gbps） 網絡成為成功的關鍵。
• 系統級調優是關鍵： 一些明顯的性能優勢來自 Ceph 自己的設置之外。關閉 CPU 節能功能 （C-states） 以及在受信任的設置中關閉 IOMMU 是減少延遲和釋放硬件真正潛力的關鍵步驟。
• 經濟性被效率所改變： 雖然 NVMe 的前期硬件成本高于 HDD，但 TCO 分析卻講述了不同的情況。在 NVMe 上使用糾刪碼使其具有成本競爭力，而性能密度的巨大提高可大幅節省電力、散熱和機架空間，通常可以降低性能密集型工作負載的總體擁有成本。
• 架構必須適合工作負載： 沒有單一的“最佳”設置。但是，我們必須權衡所有，例如在每個驅動器選擇一個 OSD 以提高速度，或者選擇兩個 OSD 以獲得更好的尾部延遲，并在 3 倍復制之間進行選擇以獲得最佳讀取性能，或在擦除碼之間進行選擇以實現存儲效率和寫入速度。
• 未來的存儲架構： 當今基于 BlueStore 的生產就緒型集群成熟、穩定，可以處理最棘手的企業工作負載。下一代 Crimson OSD 和 SeaStore 后端的持續開發確保 Ceph 有一個明確的路線圖，可以更好地利用未來的存儲技術。

部署一個高性能的全 NVMe Ceph 集群是一項復雜的工作，需要存儲、網絡和系統管理的深入知識。像使用消費級硬件、網絡配置不足或跳過系統級調優等常見錯誤，很容易會導致存儲系統無法發揮出應有的性能。

對于那些希望利用全 NVMe Ceph 的強大功能而又不想經歷陡峭學習曲線和風險的組織來說，本文可以提供一個比較好的參考案例。

常見問題（FAQ）

全 NVMe Ceph 集群與基于 HDD 的傳統集群相比如何？

全 NVMe Ceph 集群與基于 HDD 的 Ceph 集群完全不同。差異不小，而是數量級。經過良好調優的全 NVMe 集群可以提供數百萬 IOPS 和每秒數十 GB 的速度，而 HDD 集群的測試速度為數千 IOPS 和每秒數百兆字節。延遲從 HDD 上的毫秒下降到 NVMe 上的微秒。

在成本方面，NVMe 硬件的每 GB 前期價格高于 HDD。但是，對于性能至關重要的應用場景來說，全 NVMe 集群的總擁有成本 （TCO） 通常要低得多。這是因為在電源、冷卻和機架空間方面取得了巨大的效率提升。例如，一項研究發現，僅 6 個全 NVMe 節點的寫入性能就需要 100 多個基于 HDD 的節點才能匹配 (https://www.micron.com/about/blog/storage/innovations/drop-hdd-from-your-object-storage-ceph-micron-6500-ion)，這可以節省大量運營成本，彌補較高的初始硬件成本。

全 NVMe 集群最關鍵的優化步驟是什么？

雖然有很多配置可以調整，但三個調優步驟對于實現全 NVMe Ceph 集群的超高性能最為重要：

1. 禁用 CPU C-States：這是 BIOS/UEFI 設置。關閉省電的 C 狀態會阻止 CPU 進入睡眠模式，從而消除損害低延遲存儲的“喚醒”延遲。這一項更改可以帶來 10-20% 的性能提升 。
2. 禁用 IOMMU： 在受信任的裸機設置中，IOMMU （VT-d/AMD-Vi） 會向每個 I/O 添加不必要的地址轉換步驟。使用內核引導設置將其關閉可以通過 減少 CPU 工作來顯著提高性能 。
3. 優化每個驅動器的 OSD 策略： 決定每個 NVMe 驅動器運行一個或兩個 OSD 是一個關鍵的選項。 每個驅動器使用一個 OSD 以獲得最佳的大寫入速度和 CPU 效率。每個驅動器使用兩個 OSD 可大幅減少 99% 的尾部延遲，這對于需要一致、可預測的響應時間的應用程序至關重要。

網絡設置如何影響全 NVMe Ceph 集群的性能和恢復速度？

網絡是 Ceph 集群的命脈，它在全 NVMe 設置中的重要性怎么強調都不為過。快速、低延遲的網絡（最低 25 Gbps，對于較大的集群，建議使用 100 Gbps）是必不可少的，原因有兩個：

1. 峰值性能：現代 NVMe 驅動器的速度很容易壓垮速度較慢的網絡。例如，10Gbps 網絡可以被單個客戶端完全用完 ，無論驅動器有多快，都會對性能造成硬性限制。
2. 恢復速度： 這是最關鍵的部分。當驅動器或服務器發生故障時，Ceph 必須通過網絡復制數 TB 的數據才能恢復完全冗余。此恢復的速度與可用網絡帶寬直接相關。緩慢的網絡會使恢復過程更長，使集群處于降級和易受攻擊的狀態，并增加因再次故障而丟失數據的風險。更快的網絡意味著更具彈性和可靠的集群。

何時應該在全 NVMe 集群上使用糾刪碼而不是 3 副本？

在全 NVMe 集群上選擇糾刪碼 （EC） 和 3 倍復制是一種基于應有和成本目標的戰略性選擇。

將 3x 復制用于：

     最大讀取性能： 如果主要目標是絕對最高的讀取 IOPS 和最低的讀取延遲，那么 3 倍復制是理想的選擇。這使其非常適合延遲敏感型工作負載，例如高事務數據庫的數據塊存儲。使用 3 倍復制可以達到 1 TiB/s性能 。

     簡單性： 復制對 CPU 的工作量比糾刪碼少。

將糾刪碼（例如 4+2、8+3）用于：

     存儲效率和成本節約： EC 可顯著降低存儲開銷 ，這是使大型全 NVMe 集群經濟實惠的關鍵。

     高寫入吞吐量： 它可能看起來有點不太可能，但從實際上講，一定規模的集群，EC 可以提供比復制更高的寫入速度 ， 因為寫入同時分布在多個 OSD 中。

     對象存儲和歸檔：它非常適合大規模對象存儲或文件存儲，其中容量和成本效益是首要考慮因素，讀取延遲略高是可以的。

在全 NVMe 上部署 Ceph 時最常見的錯誤是什么？

最常見和最具嚴重的錯誤是使用 消費級硬件 。此錯誤主要以兩種方式表現出來：

1. 費級 NVMe 驅動器： 使用臺式機或筆記本電腦類型的驅動器是導致問題的根源。這些驅動器缺少基本的企業功能，如掉電保護（有數據損壞的風險），并且寫入耐久性 （DWPD） 非常低，這會導致它們在 Ceph 的持續 I/O 負載下過早磨損和失效。
2. 網絡配置不足：在 1GbE 甚至 10GbE 網絡上部署全 NVMe 集群。這會直接導致明顯的性能瓶頸，使集群無法獲得快速存儲的任何優勢，并嚴重影響數據恢復的速度，使集群面臨風險。

這些硬件選擇往往會產生一些基礎限制和可靠性風險，而且是再多的軟件調優都無法解決的。一個成功的全 NVMe Ceph 部署始于正確的企業級硬件的基礎。