介紹

在未來幾年，大型粒子對(duì)撞機(jī)獲取的大量數(shù)據(jù)將對(duì)CERN的存儲(chǔ)吞吐量、容量和存儲(chǔ)的耐久性提出更高的要求。開源存儲(chǔ)系統(tǒng)的最新狀態(tài)展示了令人信服的功能和成熟度。同時(shí)，我們也關(guān)注這些組件是否以及如何在未來的物理存儲(chǔ)系統(tǒng)中發(fā)揮作用的問題。

現(xiàn)成的軟件缺少重要的高級(jí)功能，而且對(duì)LHC物理項(xiàng)目至關(guān)重要的成本優(yōu)化硬件的效率證據(jù)有限;然而，一個(gè)完整的解決方案可以通過在開源產(chǎn)品的基礎(chǔ)上分層HEP特定的網(wǎng)關(guān)來構(gòu)建。在本文中，我們描述并評(píng)估了一種新的開源集群存儲(chǔ)系統(tǒng)CEPFS與EOS的組合，EOS是CERN為L(zhǎng)HC數(shù)據(jù)采集設(shè)計(jì)的高性能低成本存儲(chǔ)解決方案。

CephFS 及其在 CERN 的應(yīng)用

CephFS 是一個(gè)現(xiàn)代集群文件系統(tǒng)，在單個(gè)數(shù)據(jù)中心的典型計(jì)算場(chǎng)景中充當(dāng) NFS 替代品，包括主目錄、HPC 暫存區(qū)或其他分布式應(yīng)用程序的共享存儲(chǔ)。該軟件為數(shù)據(jù)和元數(shù)據(jù) IOPS 實(shí)現(xiàn)了橫向擴(kuò)展架構(gòu)：數(shù)據(jù)和元數(shù)據(jù)被持久保存在分布式對(duì)象存儲(chǔ) RADOS ，并且元數(shù)據(jù)由少量可替換的 MDS 服務(wù)器進(jìn)行管理。

容量和性能可以在不停機(jī)的情況下動(dòng)態(tài)增加：通過將服務(wù)器添加到 RADOS 后端來擴(kuò)展原始容量和 IOPS，通過將文件系統(tǒng)子樹重新分配給新的 MDS 服務(wù)器來擴(kuò)展元數(shù)據(jù)。RADOS 使用副本(通常是 3 個(gè)副本)或糾錯(cuò)碼提供持久對(duì)象存儲(chǔ)，例如使用四個(gè)數(shù)據(jù)條帶和兩個(gè)奇偶校驗(yàn)條帶 (EC4,2)。RADOS 使用 CRUSH 將對(duì)象放置在故障域中：通過這種方式，系統(tǒng)可以設(shè)計(jì)為基于磁盤、主機(jī)、機(jī)架、電源或交換機(jī)級(jí)別容忍故障。

CephFS 旨在提供與本地文件系統(tǒng)相同的一致性保證。為了實(shí)現(xiàn)這一點(diǎn)，MDS 將一系列 IO 功能委托給客戶端，這些功能根據(jù)對(duì)目錄和文件的并行訪問的實(shí)時(shí)需求，授予同步或異步執(zhí)行不同的 POSIX 操作。例如，由一個(gè)沒有其他客戶端的寫入器打開的文件可以通過客戶端緩沖快速寫入并僅定期持久化，而具有并發(fā)寫入/讀取的文件必須同步持久化，并且不允許客戶端緩存其讀取。

自 2017 年以來，CERN 在生產(chǎn)中運(yùn)行了多個(gè) CephFS 集群，截至 2021 年，我們?cè)谌N環(huán)境中使用 CephFS：

• HPC Scratch使用位于 SLURM 計(jì)算節(jié)點(diǎn)上的 Ceph OSD 構(gòu)建的全閃存集群，使用本地空閑節(jié)點(diǎn)作為 MDS；3 副本，可用容量約為 110 TiB；

• OpenStack Manila 混合 HDD/SSD 集群，為 IT 和科學(xué)應(yīng)用提供通用共享存儲(chǔ)；3 副本，可用容量約為 1 PiB；

• 企業(yè)群件：一個(gè)全閃存集群，位于 OpenStack 管理程序上，專門為 CERN 社區(qū)提供新的集群解決方案；EC2,2 可用容量約為 100 TiB。

在這些環(huán)境中，CephFS已在多年的運(yùn)行中證明了其健壯性和性能。CERN的這些和其他Ceph集群經(jīng)歷了幾次外部中斷，并經(jīng)歷了三個(gè)硬件采購周期：在此期間，我們注意到與數(shù)據(jù)可用性、丟失或損壞相關(guān)的事件很少。

盡管有這些優(yōu)勢(shì)，CephFS 目前在 CERN 僅限于之前列出的用例，因?yàn)槿鄙僖恍?duì)高能物理社區(qū)至關(guān)重要的功能：

• 身份驗(yàn)證機(jī)制和用戶/組管理：SciTokens 、X.509、Kerberos、配額和通過 eGroups 進(jìn)行的訪問控制；

• 存儲(chǔ)協(xié)議和特性：HTTPS、XRootD、第三方拷貝；

此外，CephFS 尚未在 CERN 進(jìn)行廣泛的高吞吐量 LHC 數(shù)據(jù)采集測(cè)試，例如寫入速率超過 20GiB/s。

EOS簡(jiǎn)介

EOS 是 CERN 開發(fā)的一個(gè)大規(guī)模存儲(chǔ)系統(tǒng)，目前為物理實(shí)驗(yàn)和 CERN 基礎(chǔ)設(shè)施的普通用戶提供 350 PB 的容量。自 2010 年首次部署以來，EOS 已經(jīng)發(fā)展并適應(yīng)了不斷增長(zhǎng)的存儲(chǔ)容量要求所帶來的挑戰(zhàn)。

EOS 作為 XRootD 框架的插件實(shí)現(xiàn)。文件使用復(fù)制或糾錯(cuò)碼存儲(chǔ)，并使用 QuarkDB 作為持久性后端。前端 MGM 服務(wù)提供對(duì)命名空間和其他元數(shù)據(jù)的緩存訪問。存儲(chǔ)節(jié)點(diǎn)運(yùn)行一個(gè)或多個(gè) FST 服務(wù)來提供對(duì)存儲(chǔ)在本地安裝的文件系統(tǒng)(FileIO[posix])或遠(yuǎn)程存儲(chǔ)(XrdIo[root protocol]、DavixIo[Webdav/S3])上的數(shù)據(jù)的訪問。對(duì)于 Linux 文件系統(tǒng)，文件都被組織為 inode。

MGM 服務(wù)將邏輯路徑名稱轉(zhuǎn)換為 inode，F(xiàn)ST 服務(wù)器按 inode 名稱存儲(chǔ)所有數(shù)據(jù)。本地或遠(yuǎn)程 FST 文件系統(tǒng)上的命名空間使用簡(jiǎn)單的 inode 哈希前綴目錄和十六進(jìn)制 inode 名稱來組織，以構(gòu)建給定 inode 編號(hào)的物理路徑。FST 本地文件系統(tǒng)唯一需要的特性是基本的 POSIX 語義和擴(kuò)展屬性。

因此，用 CephFS 替換本地 FST 文件系統(tǒng)很簡(jiǎn)單。在這種情況下，通過 FST 訪問的數(shù)據(jù)會(huì)使用遠(yuǎn)程 CephFS 文件系統(tǒng)。在這樣的部署模型中，冗余和數(shù)據(jù)高可用性被委托給 CephFS 層，并且 EOS 被配置為存儲(chǔ)具有單副本布局的文件。

系統(tǒng)架構(gòu)

Ceph 后端存儲(chǔ)

后端由八個(gè)磁盤服務(wù)器構(gòu)成，每個(gè)磁盤服務(wù)器具有以下規(guī)格：

• 雙 Intel Xeon Silver 4216 CPU 和 192 GiB RAM；

• Mellanox ConnectX-5 網(wǎng)絡(luò)接口支持 100Gb/s 以太網(wǎng)；

• 通過單個(gè) SAS3616 主機(jī)總線適配器連接 60 個(gè) 14 TB 企業(yè)級(jí) SATA HDD；

• 1××1 TB 固態(tài)硬盤。

這些高密度磁盤服務(wù)器尚未在 CERN 用于生產(chǎn)。目前，EOS 使用具有四個(gè) 24 磁盤機(jī)箱的服務(wù)器，這些機(jī)箱連接到具有 192 GiB 內(nèi)存的前端。由于每個(gè) Ceph OSD 需要大量?jī)?nèi)存，這些 96 磁盤 EOS 系統(tǒng)需要磁盤集群或額外內(nèi)存。相反，在我們的 PoC 中評(píng)估的高密度服務(wù)器是理想的，因?yàn)樗鼈優(yōu)槊總€(gè) OSD 提供 3 GiB 的內(nèi)存。

在這個(gè)硬件上，我們使用 Octopus 15.2.8 版安裝了 Ceph。每臺(tái)服務(wù)器的磁盤都準(zhǔn)備好運(yùn)行 61 個(gè) Ceph OSD：HDD 和 SSD 分別用于托管 CephFS 數(shù)據(jù)和元數(shù)據(jù)池。單個(gè)非本地磁盤服務(wù)器的虛擬機(jī)充當(dāng)集群的 MON、MGR 和 MDS。CephFS 配置了頂級(jí)目錄，每個(gè)目錄由不同的 RADOS 池支持，擦除編碼和 CRUSH 配置如下：

• /ec42：Reed-Solomon 編碼，k = 4，m = 2;每個(gè)主機(jī)最多有一個(gè)對(duì)象塊；4096 個(gè)歸置組，每個(gè) OSD 51.2 個(gè)；

• /ec82：Reed-Solomon 編碼，k = 8，m = 2;每個(gè)主機(jī)最多有兩個(gè)對(duì)象塊；2048 個(gè)歸置組，每個(gè) OSD 42.6 個(gè)；

• /ec162：Reed-Solomon 編碼，k = 16，m = 2;每個(gè)主機(jī)最多有三個(gè)對(duì)象塊；1024 個(gè)歸置組，每個(gè) OSD 38.4 個(gè)。

此外，我們還使用 CephFS 的文件布局?jǐn)U展屬性評(píng)估了對(duì)象大小對(duì)性能的影響。RADOS 放置組被平衡到每個(gè) OSD 的最大偏差。

編輯搜圖

圖一

使用八個(gè)運(yùn)行 Ceph OSD 的后端磁盤服務(wù)器(塊 1-8)和運(yùn)行 EOS FST 和 CephFS 內(nèi)核掛載的八個(gè)前端(塊 9-16)測(cè)試設(shè)置。MGM 和 MDS 分別處理 EOS 和 CephFS 的元數(shù)據(jù)。CephFS 元數(shù)據(jù)存儲(chǔ)在 SSD 上，而數(shù)據(jù)對(duì)象存儲(chǔ)在 HDD 上。

EOS 前端服務(wù)器

我們使用另外八臺(tái)相同的機(jī)器作為 EOS FST 節(jié)點(diǎn)，使用 CentOS 8.2 附帶的內(nèi)核客戶端安裝 CephFS。對(duì)于每個(gè) FST，我們?cè)?CephFS 掛載目錄中創(chuàng)建了一個(gè)單獨(dú)的數(shù)據(jù)目錄，并將它們配置為八個(gè) EOS 文件系統(tǒng)。設(shè)置如圖1所示，而圖 圖2和圖3顯示了 EOS 空間和文件系統(tǒng)配置。

圖二

八個(gè) CephFS 掛載提供的 ceph 空間的配置：

圖三

EOS ceph 空間內(nèi) 8 個(gè) CephFS 掛載的文件系統(tǒng)配置。

測(cè)試和結(jié)果

我們執(zhí)行了兩組基準(zhǔn)測(cè)試來評(píng)估 CephFS 后端和 EOS 前端服務(wù)的性能：

• 后端直接在客戶端內(nèi)核掛載上使用dd命令，以研究 CephFS 后端的流式傳輸性能；

• 前端通過 EOS FST使用 XRootD 協(xié)議eoscp復(fù)制客戶端，以研究它們對(duì)整體性能的影響。

基準(zhǔn)設(shè)置

每個(gè)基準(zhǔn)測(cè)試使用每個(gè)ceph掛載的 10 個(gè)并行流(總共 80 個(gè))來創(chuàng)建/寫入或讀取每個(gè) 2 GB 大小的文件?；鶞?zhǔn)測(cè)試通常執(zhí)行幾個(gè)小時(shí)以觀察穩(wěn)定的運(yùn)行情況;為了測(cè)試性能下降，我們還測(cè)試了支持 CephFS 何時(shí)填充到 95%。在前端基準(zhǔn)測(cè)試中，并發(fā)流的數(shù)量可能會(huì)因設(shè)計(jì)而波動(dòng)。每個(gè)客戶端掛載的平均流數(shù)再次配置為 10 個(gè)。我們還調(diào)整了 RADOS 對(duì)象大小參數(shù)，以提高每個(gè)糾刪碼布局的寫入性能。

我們對(duì)原始控制器和網(wǎng)絡(luò)速度進(jìn)行了基準(zhǔn)測(cè)試。在最佳負(fù)載條件下，兩條 IO 路徑均達(dá)到設(shè)計(jì)規(guī)范 12 GiB/s。此外，我們測(cè)量了單個(gè) CephFS 內(nèi)核客戶端的限制;讀寫速度最高可達(dá) 6 GiB/s。圖4顯示寫入吞吐量與客戶端數(shù)量呈線性關(guān)系，直到 8 個(gè)客戶端節(jié)點(diǎn)中有 6 個(gè)達(dá)到最大集群寫入性能。圖5同樣顯示，當(dāng)足夠多的并發(fā)工作時(shí)，讀取吞吐量不受客戶端限制：讀取擴(kuò)展以線性方式開始，然后顯示一條阻尼曲線，這很可能是由于盤片尋道時(shí)間隨著并發(fā)流的數(shù)量而增加。

編輯搜圖

圖四

使用 EC16,2;64M 隨客戶端節(jié)點(diǎn)數(shù)量進(jìn)行寫入的性能擴(kuò)展。寫入吞吐量隨客戶端數(shù)量而變化，直到 8 個(gè)客戶端中有 6 個(gè)同時(shí)運(yùn)行：

編輯搜圖

圖五

使用 EC16,2;64M 讀取客戶端節(jié)點(diǎn)數(shù)量的性能擴(kuò)展。讀取性能開始線性擴(kuò)展，但在 3 個(gè)并發(fā)流以上時(shí)衰減。

結(jié)果

圖6顯示了相對(duì)寫入性能對(duì)硬盤卷使用量的依賴性：100% 性能相當(dāng)于 31 GiB/s。降級(jí)與觀察到的 OSD 節(jié)點(diǎn)上的 IO 等待增加一致。

編輯搜圖

圖六

寫入性能與 CephFS 總使用量的相關(guān)性。當(dāng)后端 CephFS 在 0 到 50% 滿時(shí)達(dá)到峰值性能，但超過 75% 的使用率會(huì)降低性能。

表1，如圖 7和8總結(jié)了在空間使用率低于 10% 的情況下測(cè)量的各種糾錯(cuò)碼布局和對(duì)象大小的寫入性能。表2，如圖 9和10總結(jié)了在空間使用率低于 10% 的情況下測(cè)量的各種糾刪碼布局、對(duì)象大小和讀取塊大小的讀取性能。兩個(gè)表都顯示了在 8 個(gè)客戶端節(jié)點(diǎn)上運(yùn)行 80 個(gè)并行 dd 命令上傳或下載 2 GiB 文件的平均時(shí)間。每個(gè)基準(zhǔn)測(cè)試使用 8000 個(gè)文件和 16 TiB 的數(shù)據(jù)量。此外，還顯示了標(biāo)準(zhǔn)偏差、平均流率、第 99 個(gè)百分位數(shù)和 IO 時(shí)間的最大值。

很明顯，高性能流有利于大塊大小。EC16,2 提供最高的寫入吞吐量，因?yàn)榕c EC8,2 或 EC4,2 配置相比，它具有最小的奇偶校驗(yàn)負(fù)載;然而，由于對(duì)象分布的方差增加，這些大塊大小顯示出長(zhǎng)尾。閱讀時(shí)塊大小的影響更加明顯。內(nèi)核掛載的默認(rèn)預(yù)讀設(shè)置為 8 MiB;大于此的塊大小有助于提高讀取吞吐量。對(duì)象大小的影響也會(huì)在讀取時(shí)表現(xiàn)出來，因?yàn)槊刻峁┓?wù)的 GiB 預(yù)計(jì)會(huì)有更多的磁盤尋道。

表 1 各種糾刪碼布局 (ECk,m) 和對(duì)象大小 (; s M) 的寫入性能。IO 時(shí)間和速率顯示為每 2 GiB 文件流和 80 個(gè)并發(fā) IO 流：

編輯搜圖

編輯搜圖

圖七

寫入性能尾部：紅線顯示平均上傳時(shí)間，方框限制顯示 99 個(gè)百分位數(shù)，錯(cuò)誤限制顯示給定糾刪碼布局觀察到的最大上傳時(shí)間?；诒?中的數(shù)據(jù)：

編輯搜圖

圖八

基于表1中的數(shù)據(jù)，各種糾刪碼布局的平均寫入流速度和標(biāo)準(zhǔn)偏差。

表2各種糾刪碼布局 (ECk,m)、對(duì)象大小 (; s M) 和dd blocksize (, b M)的讀取性能測(cè)量：

編輯搜圖

IO時(shí)間和速率顯示為每2 GiB文件流80個(gè)并行流。使用默認(rèn)的內(nèi)核預(yù)讀設(shè)置8 MiB。

編輯搜圖

圖九

讀取性能尾部：紅線顯示平均下載時(shí)間，框限制顯示 99 個(gè)百分位數(shù)，錯(cuò)誤限制為給定糾刪碼布局觀察到的最大下載時(shí)間?；诒?中的數(shù)據(jù)。

編輯搜圖

圖十

基于表2中數(shù)據(jù)的各種糾刪碼布局的平均讀取流速度和標(biāo)準(zhǔn)偏差。

圖11中可視化的表3顯示了通過 EOS 作為前端服務(wù)訪問 CephFS 的影響。整體性能沒有變化，但由于寫入時(shí)流調(diào)度不公平，XRootD 協(xié)議的使用增加了尾部效應(yīng)。這些尾部效應(yīng)可以通過將每個(gè)流限制到標(biāo)稱 325/350 MiB/s 客戶端來消除。讀取性能實(shí)際上受益于前端，因?yàn)?EOS 傳輸中使用的塊大小大于原生 CephFS 后端的基線比較。

表3 原生 CephFS 后端性能和通過 EOS 前端服務(wù)訪問的比較，用于各種糾刪碼布局 (ECk,m)、對(duì)象大小 (; s M) 和 IO 塊大小 (, b M)：

編輯搜圖

使用EOSaa 和 EOSbb，我們分別將客戶端限制為325 MiB/s和350 MiB/s。

編輯搜圖

圖十一

根據(jù)表3中的數(shù)據(jù)可視化將 EOS 前端添加到 CephFS 后端的影響。

調(diào)整 Ceph

在我們的性能評(píng)估過程中，我們遇到了幾個(gè)問題，默認(rèn) Ceph 配置和警告并不理想：

客戶端限制傳輸中的字節(jié)默認(rèn)情況下，librados 客戶端將運(yùn)行中寫入的數(shù)量限制為 100MiB。我們觀察到經(jīng)常會(huì)達(dá)到這個(gè)限制，從而限制了可實(shí)現(xiàn)的寫入性能。將objecter_inflight_op_bytes設(shè)置為10485760000消除了這種人為限制。

MDS caps回調(diào)調(diào)整EOS fsck過程用于檢查EOS命名空間與后端CEPFS存儲(chǔ)的一致性。這一過程對(duì)MDS持續(xù)施加壓力，要求其盡快統(tǒng)計(jì)所有文件，這可能會(huì)導(dǎo)致這樣一種情況，即客戶獲取CAP的速度比MDS要求召回的速度更快，從而導(dǎo)致MDS出現(xiàn)內(nèi)存不足錯(cuò)誤。改進(jìn)了默認(rèn)上限召回設(shè)置，有效地將上限授予/召回率提高了5倍以上，并得到了上游社區(qū)的建議和接受。此外，EOS fsck現(xiàn)在可以被限制，以便在可配置的時(shí)間間隔內(nèi)掃描名稱空間。

單個(gè)高延遲 OSD 造成了嚴(yán)重影響： 在我們的測(cè)試中，集群范圍的寫入性能從標(biāo)稱的 25 GiB/s 下降到 5 GiB/s 以下。故障排除后發(fā)現(xiàn)是單個(gè) HDD 的物理 SATA 連接不佳，最小 IO 請(qǐng)求平均耗時(shí)超過 2 秒 。一旦從集群中移除該磁盤，預(yù)期的性能就會(huì)恢復(fù)。此類問題以前在 CERN 的生產(chǎn)中從未見過。由于 Ceph 目前沒有檢測(cè)到此類問題并發(fā)出警告，因此我們目前正在開發(fā)一個(gè)外部探針，該探針會(huì)在檢測(cè)到異常 OSD 延遲時(shí)發(fā)出警告，如果證明有用，將向上游提供。

結(jié)論與討論

經(jīng)過評(píng)估的基于高密度磁盤服務(wù)器的設(shè)置在各種擦除編碼方案下提供了優(yōu)異的性能，并允許每個(gè)節(jié)點(diǎn)為流式訪問提供高達(dá)4 GiB/s的讀寫數(shù)據(jù)負(fù)載。在規(guī)劃服務(wù)時(shí)，必須考慮到隨著 CephFS 使用量的增加而導(dǎo)致的性能大幅下降，而在硬件故障期間不存在操作風(fēng)險(xiǎn)的安全最大可用空間閾值需要更多的實(shí)際經(jīng)驗(yàn)。我們已經(jīng)測(cè)試了使用upmap數(shù)據(jù)平衡將備份CEPFS填充到高達(dá)95%的空間，以實(shí)現(xiàn)統(tǒng)一的磁盤利用率。

在接近網(wǎng)絡(luò)連接極限時(shí)執(zhí)行的糾錯(cuò)碼寫入性能;CPU 和磁盤在這些峰值吞吐量下均未飽和。讀的瓶頸更明顯;它們很可能由磁盤盤片尋道延遲控制。CephFS 糾錯(cuò)碼IO模型的讀寫通信量大致翻了一番。在使用大數(shù)據(jù)塊進(jìn)行寫測(cè)試時(shí)，單個(gè)節(jié)點(diǎn)上的網(wǎng)絡(luò)輸入達(dá)到令人印象深刻的 9 GiB/s，而傳出流量為5 GiB/s，磁盤輸出為5 GiB/s。

要利用每臺(tái)服務(wù)器的總可用磁盤IO帶寬(10 GiB/s)，必須將網(wǎng)絡(luò)連接增加一倍。此外，除了報(bào)告的結(jié)果，我們還調(diào)查了并發(fā)讀寫用例。CephFS 優(yōu)先考慮寫入的可用帶寬，留給讀剩余的帶寬;writer-preferred IO調(diào)度確實(shí)是大多數(shù)用例的理想行為。

EOS 前端對(duì)整體 IO 性能的影響很小。應(yīng)該針對(duì) XRootD 服務(wù)器內(nèi)部的不平衡流調(diào)度實(shí)現(xiàn)來調(diào)查寫入時(shí)增加的尾部。

從理論上講，可以將 EOS FST 和 Ceph OSD 放在同一臺(tái)服務(wù)器上，但是這需要在 OSD 節(jié)點(diǎn)上安裝 CephFS：如果出現(xiàn)內(nèi)存壓力，這種安裝會(huì)導(dǎo)致內(nèi)核死鎖。超聚合存儲(chǔ)/網(wǎng)關(guān)模型需要在高負(fù)載情況下進(jìn)行一些額外的測(cè)試。

CEPFS+EOS 混合設(shè)置是將 CephFS 的高性能并行 IO 功能與 EOS 提供的高級(jí)功能相結(jié)合的簡(jiǎn)單方法。這包括強(qiáng)大的安全性、使用 XRootD 和 HTTP(S)協(xié)議的高效 WAN 訪問、擴(kuò)展配額和權(quán)限管理、第三方傳輸、令牌授權(quán)、校驗(yàn)和支持、可選磁帶后端等。

在設(shè)計(jì)采用 100Gig-E 技術(shù)的混合服務(wù)時(shí)，必須特別注意后端 OSD 中的網(wǎng)絡(luò)，以及每個(gè)前端節(jié)點(diǎn)的IO限制。我們?cè)O(shè)法用一個(gè)帶有一個(gè)CephFS內(nèi)核掛載的單網(wǎng)關(guān)FST最多寫4.5 GiB/s，讀6 GiB/s。在 CERN 的 LHC 存儲(chǔ)使用中，我們觀察到典型的 10:1 讀取與寫入比率。因此，在 CephFS 可以以開放訪問方式掛載以在客戶端節(jié)點(diǎn)上讀取的情況下，將重定向到本地功能添加到 EOS 可能是一個(gè)有趣的選項(xiàng)。

本地重定向可能取決于每個(gè)目錄的權(quán)限設(shè)置。CephFS 掛載本身也可以在 XRootD 插件內(nèi)根據(jù)包含所需 CephFS 只讀掛載的 cephx 身份驗(yàn)證密鑰的重定向響應(yīng)觸發(fā)。當(dāng)文件訪問稀疏時(shí)，網(wǎng)關(guān) FST 模型提供了一個(gè)額外的緩存層來將客戶端稀疏訪問轉(zhuǎn)換為流式后端流量。這需要適當(dāng)調(diào)整 CephFS 裝載預(yù)讀設(shè)置。

所提出的服務(wù)模型允許在單個(gè)管理域后面將多個(gè)具有獨(dú)立故障域和不同服務(wù)質(zhì)量的獨(dú)立 CephFS 設(shè)置集群化。它使運(yùn)營商能夠使用 EOS 管理工具和第三方傳輸在 CephFS 系統(tǒng)之間從舊后端到新后端進(jìn)行透明的硬件遷移，而不會(huì)中斷生產(chǎn)使用。

我們已經(jīng)為IO流操作驗(yàn)證了此設(shè)置。稀疏物理分析用例的可用性將是驗(yàn)證的下一步。此外，經(jīng)過幾個(gè)填充/刪除周期老化后的預(yù)期碎片懲罰尚未評(píng)估。我們演示了 CephFS 可以用于高吞吐量流式 IO，而無需為 BlueStore 元數(shù)據(jù)block.db指定 SSD。運(yùn)行大容量服務(wù)器的主要要求是每個(gè)OSD(HDD)至少提供3 GiB的內(nèi)存。

總之，CephFS + EOS 是一個(gè)可行的解決方案，它以非常簡(jiǎn)單的方式結(jié)合了 Ceph 的對(duì)象存儲(chǔ)概念和 EOS 的高級(jí)服務(wù)功能。我們需要綜合平衡復(fù)雜性和服務(wù)成本以及帶來的好處。

原文：https://link.springer.com/article/10.1007/s41781-021-00071-1

作者：祝祥

資深云計(jì)算架構(gòu)師，OpenStack官方特邀講師。上萬臺(tái)云主機(jī)和幾十PB分布式存儲(chǔ)的建設(shè)管理經(jīng)驗(yàn)。