1.前言

本文是關于 Ceph 對象網關性能深入探討：構建安全且可擴展的對象存儲 系列的第二篇。若尚未閱讀第一與第二部分，建議從第一篇入手。前文詳細介紹了測試環境，包括硬件軟件配置、網絡架構及基準測試方法論以及通過測試 Ceph RGW 在 4 節點、8 節點及 12 節點集群的擴展表現，我們揭示了 PUT 與 GET 操作吞吐量隨節點增加呈現近似線性提升的規律。研究同時驗證了橫向擴展可提升資源使用效率——即使是資源密集型的糾刪碼工作負載，其單節點資源消耗也隨集群擴大而顯著降低。

2.TLS 終端性能：S3 端點傳輸加密評估

為評估 TLS 對 Ceph 對象網關（RGW）S3 端點性能的影響，我們對比了三種常見部署策略：端到端加密（RGW 層 SSL）、cephadm 部署的 Ingress 服務（HAProxy）SSL 終端卸載，以及未加密基準方案。HAProxy 服務與 Ceph 對象網關（RGW）服務采用共用節點部署模式，每節點配置虛擬 IP 地址（VIP），基準測試客戶端在所有 VIP 間實現請求負載均衡。本次測試在十二節點集群上采用 EC 8+3 配置，分別針對中/大對象（4 MiB）與小對象（64 KiB）工作負載進行。

中/大型對象工作負載 （4 MiB）

本節重點介紹 4 MiB 對象大小結果，作為中大型對象大小的代表性案例。對于更大的對象，由于傳輸效率更高，每字節開銷更低，本文觀察到的趨勢通常保持不變或進一步優化。

RGW 層 SSL 加密方案的吞吐量與無 SSL 配置幾乎持平：GET 請求僅低 0.4%，PUT 吞吐量下降幅度稍大為 4.2%。這種微小差異符合預期，因為集群處于網絡瓶頸狀態。盡管測試期間 RGW 平均 CPU 使用率 GET 增加 40%、PUT 增加 71%，但單主機最高 CPU 利用率僅達約 83%，額外負載未對性能產生實質影響。這表明 RGW 層 SSL 加密作為默認安全選項，對大對象工作負載的性能影響可忽略不計。

圖片

圖片

相比之下，在 Ingress 服務層（HAProxy）終止 SSL 的方案表現出更明顯的性能影響：GET 吞吐量下降約 27%，PUT 吞吐量降低 19%，延遲相應增加。這種下降并非源于 SSL 本身開銷，而是由于加密工作負載轉移至 HAProxy 層所致。在重負載下，隨著對象大小從 64 KiB 增至 1 GiB，單個 HAProxy 守護進程平均消耗 3 至 6 個 vCPU。Ceph 主機峰值 CPU 使用率最高達 90%，這表明需要針對 HAProxy 進行適當調優與擴展，以避免 CPU 成為性能瓶頸。

圖片

小對象工作負載 （64 KiB）

在處理小對象時，吞吐量瓶頸自然從網絡轉移至 CPU，使得加密開銷更為顯著。盡管如此，在 Ceph 對象網關（RGW）啟用 SSL 的影響仍處于可控范圍：相較于無 SSL 基準，GET IOPS 下降 5.2%，PUT IOPS 降低 10.7%。RGW 的 CPU 使用率 GET 增加 4.2%，PUT 增加 11.3%，這表明加密工作在集群中分布良好。雖然小對象工作負載對 CPU 使用率更為敏感，但端到端 SSL 方案仍具實用性——在多數場景下性能損耗被控制在個位數百分比范圍內。

圖片

Ingress 層 SSL 終端方案再次呈現更顯著的性能差距：相較于無 SSL 配置，GET IOPS 下降約 18%，PUT IOPS 降低 8%，同時伴隨 Ingress 服務 CPU 使用率上升與請求延遲微增。盡管數據顯示性能差異較大，該方案仍適用于生產環境——當安全策略要求 TLS 卸載時，只需確保 Ingress 服務的擴展能力與并發量及吞吐量目標匹配即可實現有效部署。

結論 - SSL/TLS S3 端點安全性

總而言之，在 Ceph 對象網關（RGW）層配置 SSL/TLS 可在安全性與性能間實現出色平衡：該方案為大對象工作負載提供接近基準的吞吐量，對小對象僅造成輕微性能衰減，同時保持端到端加密優勢。

3.集群服務傳輸加密：大規模內部流量保護

隨著安全標準的不斷發展，保護 Ceph 守護進程之間的內部通信正在成為生產部署的最佳實踐，尤其是在受監管的環境中。在 Ceph 中，此內部加密是通過 Messenger v2 安全模式啟用的，也稱為集群網絡加密或傳輸中的內部加密。與保護外部客戶端和 S3 Ceph 對象網關 （RGW） 端點之間的流量的 TLS 不同，Messenger v2 確保所有守護進程間流量（包括 RGW 到 OSD、OSD 到 Monitor 和 Manager 通信）都經過加密和身份驗證。

本節介紹在啟用 Ceph 對象網關 （RGW） SSL 的基準之上啟用 Messenger v2 安全模式對性能的影響。兩種配置（帶安全模式和不帶安全模式）都在 RGW 上使用 SSL 進行面向客戶端的加密。測試是在 12 節點集群上進行的，使用 8+3 糾刪碼，中/大型對象大小（1 MiB 至 256 MiB）。

核心結論：強安全性的最小性能開銷

我們評估了啟用和未啟用 Messenger v2 安全性的配置中 GET 和 PUT 作的吞吐量和延遲。如下圖和表格所示，讀取和寫入作的性能增量可以忽略不計，這表明傳輸中的內部加密與高吞吐量對象存儲用例兼容。

圖片

接下來是一個表格，該表提供了使用我們的參考 4 MiB 對象大小測量的配置之間百分比變化的完整比較。

圖片

分析

• 吞吐量影響：在所有測試對象大小（1 MiB 至 256 MiB）中，啟用 Messenger v2 安全模式后 GET 吞吐量基本保持不變。PUT 吞吐量出現適度下降，其中 1 MiB 對象下降最明顯（-3.1%），隨對象大小增大影響趨近于零（如 64 MiB 和 256 MiB 僅-0.4%）。該趨勢符合預期：小對象會放大加密開銷，而大對象更受吞吐量限制且能攤薄額外成本。
• 延遲影響：GET 與 PUT 延遲在所有場景下均保持穩定。觀測到的波動極小（通常為 ±1 毫秒），這證實即使在高并發和不同對象大小下，啟用 Messenger v2 安全模式也不會引入顯著排隊或處理延遲。
• 資源利用率：RGW 層 CPU 使用率在 PUT 操作中略有上升（約 2-6%，具體取決于對象大小），GET 操作 CPU 使用率基本持平。內存消耗同樣呈現微小變化（約 5-7%范圍內），未出現資源耗盡或飽和跡象。

結論 – Messenger v2 內部加密方案 

啟用 Messenger v2 安全模式可為內部 Ceph 守護進程通信添加加密保護，對性能的影響可以忽略不計。我們的測試顯示，所有對象大小的吞吐量和延遲都很穩定，RGW 內存和 CPU 使用率僅略有增加，主要是用于 PUT 操作。Messenger v2 的設計以最小的代價確保了強大的安全保障，使其與高吞吐量、企業級對象存儲部署高度兼容。

4.最終建議——安全架構：TLS + Messenger v2

對于需要同時保障客戶端傳輸安全與集群內部服務通信安全的環境，采用 S3 端點 TLS 加密與 Messenger v2 內部加密的組合方案，可在實現強安全性的同時將性能影響降至最低。

無論是保護 AI 訓練、分析平臺還是多租戶對象存儲服務，Ceph RGW 證明了全棧加密方案可放心部署——在吞吐量、延遲與擴展性方面均不會受到明顯影響。

5.靜態加密（SSE-S3）：應用場景與 4 MiB 測試結果

為何選擇 SSE-S3？

靜態加密確保對象數據在持久化存儲前完成加密，僅在訪問時解密。Ceph RGW 中的 SSE-S3 采用信封加密機制：每個對象使用獨立數據密鑰加密載荷，該數據密鑰本身由 KMS（本基準測試中采用 Vault Transit 并通過 Vault Agent 實現令牌管理與認證卸載）進行存儲和保護。該設計提供強安全保證與集中式密鑰管控。

性能權衡符合預期：每個對象的 PUT/GET 操作均增加加密工作及（KMS 保護密鑰的）解包步驟。對象越小，固定每對象成本占比越高。小對象測試中我們觀察到預期規律：對象大小越小，每對象密鑰操作與加密的相對開銷越大

測試數據（12 節點，EC 8+3，512 客戶端線程，4 MiB 對象）

測試方案：

• 基準方案 ：RGW + TLS + msgr_v2（未啟用 SSE）
• SSE@RGW 方案 ：基準方案 + SSE-S3（TLS 在 RGW 層終止）
• SSE@Ingress 方案 ：SSE-S3 + TLS 在 HAProxy 層卸載（msgr_v2 啟用）

SSE 與基線性能的吞吐量和延遲比較：

說明

• 對于 4 MiB 對象，SSE@RGW 方案可保持約 90%的 PUT 吞吐量，僅伴隨適度延遲增長——這對大對象寫入密集型而言屬積極結果。
• GET 路徑表現出更高敏感性，因為每次讀取均需解包對象數據密鑰（涉及 KMS 往返+解密操作），該過程在高并發下成為限速因素。將 TLS 卸載至 Ingress 層可釋放 RGW 的 CPU 資源并部分彌補 GET 性能差距，但 KMS 密鑰解包成本仍是主要開銷。

結論 – 靜態加密 （SSE-S3）

SSE-S3 以可預測的性能開銷提供強靜態加密保護：對于大對象可保持高效處理（PUT 操作接近基準性能），但對于頻繁存取的小對象工作負載則受 KMS 性能影響。通過對象大小優化、KMS 擴展部署以及 RGW/Ingress 容量規劃，可有效緩解此類權衡。

6.下一步我們未來的目標

• 探索快速 EC 改進 （Ceph 9.x） 以實現小對象 EC 性能。
• 使用 200/400 GbE 重新運行大型對象測試，以突破當前的網卡上限。
• 研究 SSL 終端卸載場景下 Ingress 服務更優的默認調優參數

7.結論

在整個三部分系列中，我們驗證了啟用安全功能后的可預測擴展能力：

• 12 節點集群實現約 111 GiB/s GET 與 66 GiB/s PUT 吞吐量，4→8→12 節點擴展呈現近線性增益且延遲保持穩定或降低，64 KB 對象場景下達成約 39.1 萬/8.6 萬 IOPS。
• RGW 層 TLS 加密性能接近基準，Messenger v2 帶來的開銷可忽略不計，SSE-S3 則呈現可基于對象尺寸調節的加密成本。  

上述結果充分證明 Ceph 對象存儲是大規模高吞吐、低延遲工作負載場景下的不錯選擇。