介紹

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

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

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

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

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

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

自 2017 年以來，CERN 在生產(chǎn)中運行了多個 CephFS 集群，截至 2021 年，我們在三種環(huán)境中使用 CephFS：

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

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

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

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

盡管有這些優(yōu)勢，CephFS 目前在 CERN 僅限于之前列出的用例，因為缺少一些對高能物理社區(qū)至關(guān)重要的功能：

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

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

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

EOS簡介

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

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

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

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

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

Ceph 后端存儲

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

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

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

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

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

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

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

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

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

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

此外，我們還使用 CephFS 的文件布局擴展屬性評估了對象大小對性能的影響。RADOS 放置組被平衡到每個 OSD 的最大偏差。

編輯搜圖

圖一

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

EOS 前端服務(wù)器

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

圖二

八個 CephFS 掛載提供的 ceph 空間的配置：

圖三

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

測試和結(jié)果

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

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

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

基準設(shè)置

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

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

編輯搜圖

圖四

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

編輯搜圖

圖五

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

結(jié)果

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

編輯搜圖

圖六

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

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

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

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

編輯搜圖

編輯搜圖

圖七

寫入性能尾部：紅線顯示平均上傳時間，方框限制顯示 99 個百分位數(shù)，錯誤限制顯示給定糾刪碼布局觀察到的最大上傳時間。基于表1中的數(shù)據(jù)：

編輯搜圖

圖八

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

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

編輯搜圖

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

編輯搜圖

圖九

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

編輯搜圖

圖十

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

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

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

編輯搜圖

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

編輯搜圖

圖十一

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

調(diào)整 Ceph

在我們的性能評估過程中，我們遇到了幾個問題，默認 Ceph 配置和警告并不理想：

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

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

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

結(jié)論與討論

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

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

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

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

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

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

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

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

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

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

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

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

作者：祝祥

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