介紹

圖片

Ceph 是一個(gè)開源的分布式存儲系統(tǒng)，設(shè)計(jì)初衷是提供較好的性能、可靠性和可擴(kuò)展性。 Ceph 獨(dú)一無二地在一個(gè)統(tǒng)一的系統(tǒng)中同時(shí)提供了對象、塊、和文件存儲功能。 Ceph 消除了對系統(tǒng)單一中心節(jié)點(diǎn)的依賴，實(shí)現(xiàn)了無中心結(jié)構(gòu)的設(shè)計(jì)思想。

我們知道Ceph為了保障數(shù)據(jù)的可靠性，存放數(shù)據(jù)通常是三副本策略（另有EC策略）。那么無論是data，metadata，journal都是三份。因此在應(yīng)用端寫入一個(gè)IO，在ceph內(nèi)部實(shí)際上會額外產(chǎn)生許多內(nèi)部IO，不同的存儲后端差異很大。 Ceph提供了FileStore、KStore和BlueStore三種存儲后端以供選擇，那么以FileStore為例，來看看13X的寫放大的來由。FileStore中ceph的數(shù)據(jù)被存放在XFS或者ZFS等本地文件系統(tǒng)中。這些文件系統(tǒng)本身又會記錄日志（FS journal），以及還有它自己的元數(shù)據(jù)（FS metadata）。

在設(shè)計(jì)存儲基礎(chǔ)結(jié)構(gòu)時(shí)，為了防止故障，保證一定的冗余度是非常有必要的。但是，冗余伴隨著存儲效率的降低，這也會增加您的成本。對于大型基礎(chǔ)設(shè)施，每 TB 成本的差異可能會導(dǎo)致總存儲成本顯著提高。因此，Ceph 中的糾刪碼非常有吸引力。 糾刪碼類似于基于奇偶校驗(yàn)的 RAID 陣列。為每個(gè)對象創(chuàng)建許多數(shù)據(jù)塊 （K） 和奇偶校驗(yàn)塊 （M）。另一方面，副本只是創(chuàng)建給定對象的其他副本，類似于鏡像 RAID 陣列。這通常意味著糾刪碼比副本具有更高的存儲效率，計(jì)算公式為 k/（k+m）。 例如，以 6+2 為例，您將獲得 75% 的存儲效率——在記錄的總 8 個(gè)區(qū)塊中，有 6 個(gè)數(shù)據(jù)塊。與三個(gè)副本相比，您將有 33% 的效率，總共 3 個(gè)記錄的塊中有 1 個(gè)數(shù)據(jù)塊。

寫入放大

正常來說，Ceph 都沒啥問題，除了一個(gè)經(jīng)常被忽視的問題：寫入放大。 數(shù)據(jù)存儲中的最小分配大小本質(zhì)上是一段數(shù)據(jù)可以寫入的最小單位。在 Pacific Ceph 之前，此值默認(rèn)為 64kb。此最小分配單元會給某些工作負(fù)載帶來問題，尤其是那些對小文件進(jìn)行操作的工作負(fù)載。

案例

4% 存儲效率示例如下圖：

圖片

為了更直觀一點(diǎn)，讓我們考慮一個(gè)傳入寫入為 16kb 的 4+2 糾刪碼池。 在上面的示例中，單個(gè) 16K 寫入最終會放大 24 倍的大小，因?yàn)槊總€(gè)塊至少需要以 64K 的速度寫入磁盤。這導(dǎo)致此特定對象的總存儲效率為 ~4%。如果您的工作負(fù)載主要由 16K 對象組成，那么這可能會很快抵消您的 EC 配置文件提供的任何優(yōu)勢。下面是使用相同文件大小的 3 副本示例。

圖片

如上圖所示，在此特定工作負(fù)載中，3 Replica 實(shí)際上比 4+2 糾刪碼池的存儲效率更高。這表明規(guī)則總是有例外。從理論上講，當(dāng)存儲效率是最高優(yōu)先級時(shí)，應(yīng)使用糾刪碼，但根據(jù)您的數(shù)據(jù)集，這可能會發(fā)生巨大變化。

寫入放大重要的用例

當(dāng)然，即使按照小文件工作負(fù)載標(biāo)準(zhǔn)，16K 文件也很小，單單一篇文章的大小就 100K 左右。另外，一些可能存在寫入放大問題的場景是：

• AI training 人工智能訓(xùn)練
• audio editing 音頻編輯
• log storing/aggregation 日志存儲/聚合
• scientific computing 科學(xué)計(jì)算

結(jié)論

了解數(shù)據(jù)和工作負(fù)載是確定 Ceph 集群構(gòu)建的關(guān)鍵部分。了解整個(gè)數(shù)據(jù)的平均文件大小將使您能夠避免這種極高的寫入放大。 當(dāng)然，這并不總是這樣的。通常，在單個(gè)集群中往往會存在各種大小的文件。在這種情況下，只需確定數(shù)據(jù)的位置即可。例如，如果單個(gè)目錄樹擁有大部分小文件，則可以將副本池固定到該特定樹，而具有較大文件大小的其余數(shù)據(jù)仍保留在糾刪碼上。 如前所述，當(dāng)您的最小分配大小太大時(shí)，寫入放大會更加普遍，這就是為什么較新版本的 Ceph（如 Pacific 和 Quincy）默認(rèn)為 4K 而不是 64K 的原因。在較新的集群或最小分配大小修改的 Octopus 集群中，寫入放大的問題要小得多，因此，我們在后續(xù)的集群部署前，需要認(rèn)真考慮一下。