将 Ceph 擴充到十億個對象甚至更多

執行摘要

• 讀取：觀察到一緻的聚合吞吐量 (Ops) 和讀取延遲。
• 寫入：觀察到一緻的寫入延遲，直到叢集達到大約。其容量的 90%。
• 在整個測試周期中，我們沒有觀察到 CPU、記憶體、HDD、NVMe、網絡方面的任何瓶頸。我們也沒有觀察到 Ceph 守護程序的任何問題，這些問題表明叢集在處理存儲對象的數量方面存在困難。
• 該測試是在一個相對較小的叢集上進行的。中繼資料溢出到較慢的裝置和叢集容量的大量使用的組合效應影響了整體性能。這可以通過适當調整 Bluestore 中繼資料裝置的大小并在叢集中保持足夠的可用容量來緩解。

業績總結

• 成功攝取超過 10 億（準确地說是 1,014,912,090）個對象，通過 S3 對象接口分布在 10K 個桶中到 Ceph 叢集中，操作或資料一緻性挑戰為零。這證明了 Ceph 叢集的可擴充性和健壯性。
• 當叢集中的對象數量接近 8.5 億時，我們的存儲容量就用完了。當叢集填充率達到約 90% 時，我們需要為更多對象騰出空間，是以我們從之前的測試中删除了較大的對象并激活了平衡器子產品。它們結合起來産生了額外的負載，我們認為這會降低用戶端吞吐量并增加延遲。
• 不利的寫入性能反映了 Bluestore 中繼資料從閃存溢出到慢速媒體。對于涉及存儲數十億個對象的用例，建議為 Bluestore 中繼資料 (block.db) 設定适當大小的 SSD，以避免 RocksDB 級别溢出到較慢的媒體。
• 使用bluestore_min_alloc_size = 64KB 會導緻小型糾删碼對象出現顯着的空間放大。
• 減少bluestore_min_a