CAL(Central Application Logging)系統(tǒng)主要負(fù)責(zé)收集和處理 eBay 內(nèi)部各個(gè)應(yīng)用程序池的日志，日處理超過 3PB 的數(shù)據(jù)，供運(yùn)維團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)日常監(jiān)控使用。
CAL 系統(tǒng)通 過 HTTP 接口接受應(yīng)用產(chǎn)生的日志，將日志持久化到經(jīng) NFS 掛載 的網(wǎng)絡(luò)存儲上， 用戶（運(yùn)維團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)）可以通過 CAL 系統(tǒng)方便地 查找、查看日志 。同時(shí)，日志也會(huì)被導(dǎo)入 Hadoop 進(jìn)行進(jìn)一步的分析形成報(bào)告。該系統(tǒng)自 21 世紀(jì)初至今，已經(jīng)有 10 多年 的歷史了。
CAL 從第一天起就運(yùn)行在 Netapp 的商業(yè)存儲 上。隨著業(yè)務(wù)的發(fā)展，業(yè)務(wù)產(chǎn)生的數(shù)據(jù)量急劇增加，單個(gè)存儲集群已經(jīng)無法承載 CAL 的流量和性能需求，存儲團(tuán)隊(duì)和業(yè)務(wù)團(tuán)隊(duì)通過增加集群來解決性能問題。一直到 2018 年 ，CAL 在每個(gè)數(shù)據(jù)中心已經(jīng)需要 25 個(gè) 集群才能支撐起其性能需求。
雖然統(tǒng)計(jì)上，CAL 只使用了 eBay 5% 的 NFS Filer 總?cè)萘浚珜?shí)際上卻消耗了 50% 的總性能。性能和容量的巨大偏離，使得實(shí)際成本已經(jīng)比該存儲方案的 裸 $/GB 成本 高了一個(gè)數(shù)量級。
高成本，疊加上由 eBay 業(yè)務(wù)驅(qū)動(dòng)的每年 30% 自然增長，這套架構(gòu)亟需重構(gòu)優(yōu)化。
2014 年，eBay 存儲團(tuán)隊(duì)開始在公司內(nèi)將 Ceph 應(yīng)用于生產(chǎn)環(huán)境。第一階段主要是 RBD 塊設(shè)備服務(wù)。
2017 年，Jewel 版本發(fā)布后，我們開始嘗試提供 CephFS 分布式文件系統(tǒng)服務(wù)，多個(gè)天使應(yīng)用從商業(yè)存儲遷移到 CephFS 上，從中我們發(fā)現(xiàn)修復(fù)了 MDS 的多個(gè) bug 并貢獻(xiàn)回社區(qū)，也在社區(qū)首次完成了 MDS 的性能分析。
2018 年，隨著 MDS 多活功能的初步成熟，我們也和業(yè)務(wù)團(tuán)隊(duì)一起，開始了把 CAL 遷移到 CephFS 上的征程。
2019 年初上線至今，Ceph 在大流量下穩(wěn)定運(yùn)行。平均讀寫帶寬同時(shí)超過了 3GB/S ，讀寫請求數(shù)合計(jì)超過 100K IOPS（每秒進(jìn)行讀寫操作的次數(shù)）, 文件系統(tǒng)元數(shù)據(jù)操作數(shù)超過 30K OP/S（每秒操作次數(shù)）。
01 總體設(shè)計(jì)
通過對 CAL 現(xiàn)有業(yè)務(wù)邏輯和歷史性能數(shù)據(jù)的分析，我們明確了 設(shè)計(jì)目標(biāo) ：
1）文件系統(tǒng)元數(shù)據(jù)路徑，支持 100K OP/S ，包括：create / getattr / lookup / readdir / unlink 等文件系統(tǒng)操作；并預(yù)留足夠的升級空間滿足業(yè)務(wù)發(fā)展。
2）文件系統(tǒng)的數(shù)據(jù)路徑，支持 150K IOPS（50% 讀，50% 寫），以及至少 6GB/S（50% 讀，50% 寫）的吞吐。
3）單集群容量需求300TB 可用空間，滿足性能需求的前提下盡可能降低存儲成本。
這個(gè)略顯激進(jìn)的設(shè)計(jì)目標(biāo)，其實(shí)在很大程度上已經(jīng)決定了我們的方案。
- 基于我們之前針對 Ceph MDS 的性能研究，單 MDS 只能支持 2K ~ 4K OP/S, 要支持 100K OP/S， MDS 多活負(fù)載均衡集群 是唯一的路徑。至少需要 25 個(gè) MDS Active-Active 組成集群。同時(shí)，業(yè)務(wù)負(fù)載還要能相對均衡地分布到每個(gè) MDS 上。
- 150K IOPS 的讀寫性能， 如果單用機(jī)械硬盤 HDD ，需要至少 1500 塊 盤，可用容量接近 3PB ，又回到了用盡性能而浪費(fèi)容量的老路。 如果全部用 SSD ， 1PB 裸容量的 SSD 雖然能比商業(yè)存儲省錢，但仍是一筆不小的數(shù)字。針對日志數(shù)據(jù)有明顯 冷熱度 的特點(diǎn)， 使用分層存儲，把頻繁訪問的數(shù)據(jù)放在 SSD 上，相對冷的數(shù)據(jù)放在 HDD 上， 才能達(dá)到最佳費(fèi)效比。
02 實(shí)現(xiàn)細(xì)節(jié)
1. MDS 多活負(fù)載均衡集群
要實(shí)現(xiàn)向外擴(kuò)展（scale-out）的架構(gòu)，核心是任務(wù)分配，把負(fù)載相對均等地分配到每個(gè) MDS 上。對于文件系統(tǒng)來說，整個(gè)目錄結(jié)構(gòu)是一棵樹。任務(wù)分配的本質(zhì)，是通過設(shè)計(jì)目錄樹的結(jié)構(gòu)，使得 葉子（文件） 平均地長在這顆樹的每個(gè) 枝干（目錄） 上。同時(shí)，每個(gè)層次的文件 / 文件夾個(gè)數(shù)必須是 可控且相對均衡的 ，這樣才能盡量降低樹的深度，避免對一個(gè)巨大文件夾進(jìn)行 ListDir 操作 帶來的延遲和開銷。
CAL 原先的目錄層次如下圖 1 所示，一共有 15 層，100 多萬 個(gè)文件夾， 幾乎違反了上面討論的所有原則，目錄過深且不均衡 。eBay 每個(gè) pool 承擔(dān)一個(gè)服務(wù)，每個(gè)服務(wù)的流量，服務(wù)器數(shù)量差異顯著。更糟糕的是整個(gè)目錄樹，在每個(gè)小時(shí)開始的時(shí)候，幾乎完全重建（虛線部分），導(dǎo)致每小時(shí)開始時(shí)元數(shù)據(jù)操作風(fēng)暴。
圖 1（點(diǎn)擊可查看大圖）
針對這個(gè)問題，我們和 CAL 團(tuán)隊(duì)合作設(shè)計(jì)并實(shí)現(xiàn)了 一套新的目錄層次 ，如圖 2 所示：
圖 2（點(diǎn)擊可查看大圖）
1）在根目錄下建立 1024 個(gè) Bucket， Client （CAL 的 Client，其實(shí)是業(yè)務(wù) APP 服務(wù)器） 通過哈希映射到其中一個(gè) bucket 下 。由于哈希的（統(tǒng)計(jì)意義）均衡性，每個(gè) Bucket 里的 Client 文件夾數(shù)量是均衡的。而 Client 文件夾的總數(shù)，和業(yè)務(wù) APP 服務(wù)器的總數(shù)對應(yīng)。
雖然虛擬化、容器化使得 Client 越來越小，越來越多，但因?yàn)?Bucket 數(shù)量足夠多， 每個(gè) Bucket 下的文件夾數(shù)依舊是可控的 。而對于每個(gè) Client 文件夾里的文件數(shù)，根據(jù)配置，每小時(shí)產(chǎn)生 5-20 個(gè) 不等的文件，文件總數(shù) = 5～20 /hour * rotation_hours。 可見，其文件數(shù)也是可控的 。
2）Bucket 通過 auth_pin , 綁定到 MDS_rank 上， 簡單來說：
auth_pin = bucket_id % NUM_MDSs
基于之前討論的 Bucket 均衡性，以及所有 Bucket 被均衡地分布到各個(gè) MDS。 可見，MDS 的負(fù)載也是均衡的 。
除此之外，我們也預(yù)留了拓展性。當(dāng)前我們用了 33 個(gè) MDS 做了 AA，其中 32 個(gè) MDS 分別綁定了 32 個(gè) Bucket，rank 為 0 的 MDS 綁定到了根目錄。日后，只需要增加 MDS 的數(shù)量，例如從 33（32+1） 增加到 65（64+1） ，修改 auth_pin 綁定關(guān)系，就能在客戶不感知的情況下實(shí)現(xiàn)無縫擴(kuò)容。
2. Cache Tier
Ceph Cache Tier 是一個(gè)在誕生之初被抱以巨大期望，而在現(xiàn)實(shí)中讓不少部署踩坑的技術(shù)，尤其是在 RBD 和 CephFS 上。在社區(qū)郵件組和 IRC 里最經(jīng)常出現(xiàn)的問題就是應(yīng)用了 Cache Tier，性能反而下降了。
其實(shí)，那些場景多數(shù)是誤讀了 Cache Tier 的應(yīng)用領(lǐng)域。Cache Tier 的管理粒度是 Object（默認(rèn) 4MB) ， 而在 RBD/CephFS 上的用戶 IO 通常明顯 小于 4MB 。當(dāng)用戶訪問未命中，Cache Tier 決定將這個(gè) Object 從 Base Tier 緩存到 Cache Tier 時(shí)， 付出了 OBJ_SIZE 大小的 慢速讀 （Base Tier）加上 OBJ_SIZE 大小的 快速寫 （Cache Tier）。
只有后續(xù)用戶對同一個(gè) Object 的重復(fù)訪問達(dá)到足夠多的次數(shù)，才能體現(xiàn) Cache Tier 的性能和成本優(yōu)勢。例如，業(yè)務(wù)負(fù)載是隨機(jī) IO，平均請求大小 4KB ，則命中率必須達(dá)到 **99.9%** 以上。
現(xiàn)實(shí)是許多業(yè)務(wù)負(fù)載并沒有這樣的特性。
在 CAL 的業(yè)務(wù)模型里，典型的 IO 負(fù)載是應(yīng)用日志每隔一分鐘或者 128KB 觸發(fā)一次寫入。同時(shí)，讀取端不斷地追蹤日志，以同樣的間隔把數(shù)據(jù)讀走。 針對這個(gè)特點(diǎn)，我們決定將 Cache Tier 配置成為一個(gè) Writeback Cache（回寫式緩存）， 這樣就能實(shí)現(xiàn)多個(gè)目的 ：
1）寫入緩沖與合并。Cache Tier 的設(shè)計(jì)容量足夠緩存一小時(shí)的寫入量，不論業(yè)務(wù)的寫入請求大小是多少，都會(huì)被 Cache Tier 吸收，以 OBJ_SIZE（4M）為單位刷回 Base Tier。4M 的大塊寫，是對 HDD 最友好的訪問行為，可以最大化 Base Tier 的吞吐量。
2）讀取緩存。CAL 的讀取行為也大多集中在對最近一個(gè)小時(shí)寫入數(shù)據(jù)的讀取。這部分?jǐn)?shù)據(jù)在 Cache Tier 里，所以讀請求也能基本全部命中 Cache Tier。
3）故障隔離。機(jī)械硬盤的故障率比 SSD 高幾個(gè)數(shù)量級，并且更容易因壞道導(dǎo)致響應(yīng)時(shí)間增長，從而使得 Ceph 集群出現(xiàn) 慢請求（slow request） 。表現(xiàn)在服務(wù)質(zhì)量上，就是延遲相對不穩(wěn)定且 尾延遲（tail latency） 特別長。借助 Cache Tier 的緩沖，業(yè)務(wù)并不會(huì)直接感受到由全機(jī)械硬盤構(gòu)成的 Base Tier 的性能抖動(dòng)，從而達(dá)到更好的性能一致性。
值得一提的一個(gè)優(yōu)化點(diǎn)是：我們通過禁用 Hitset 關(guān)閉了 Proxy Write 這個(gè)功能。Ceph Cache Tier 的默認(rèn)行為是 Proxy Write——即若待寫入數(shù)據(jù)在 Cache Tier 不命中，Cache Tier 會(huì)直接把請求寫入 Base Tier，并在寫入完成后才將結(jié)果返回給應(yīng)用。
這是一個(gè)正確的設(shè)計(jì)，主要是為了避免寫請求不命中時(shí) promote 帶來的額外延遲，并解耦數(shù)據(jù)寫入邏輯和 Cache Promote 邏輯。
但在 eBay 日志的應(yīng)用場景中，因?yàn)閷懭胄袨榈捻樞蛐院腿罩静豢勺兏奶匦裕梢悦鞔_知道 寫入不命中一定是因?yàn)閷懭肓艘粋€(gè)新的 Ceph Object，而非對老 Object 的改寫，因此 proxy write 的邏輯就帶來了額外的開銷 。
例如，對 obj x 的第一次寫入， write（obj_x, 128kb)， 在默認(rèn)的 Proxy Write 行為下 ，這個(gè)寫被 proxy 到了 Base Tier 。寫入成功后，在 Base Tier 留下 128KB 的 object，然后 Cache Tier 再把 obj_x 從 Base_tier promote 上來。
而關(guān)閉 proxy write 后，則先對 obj_x 做一次 promote，在 Cache Tier 中產(chǎn)生一個(gè)空對象，再直接寫入 128KB 數(shù)據(jù)即可。
相比之下，后者節(jié)約了 Base Tier 一次 128KB 寫和一次 128KB 讀，對于由全機(jī)械硬盤構(gòu)成的 Base Tier 來說，這樣的節(jié)約意義重大，并且應(yīng)用的寫入延遲大大降低了。這部分 Ceph 具體代碼，可以閱讀
PrimaryLogPG::maybe_handle_cache_detail 的實(shí)現(xiàn)。
其他的配置優(yōu)化包括設(shè)置 min_flush_age 和 min_evict_age 來保證最近一小時(shí)的數(shù)據(jù)不會(huì)被刷出 Cache，以及對 target_max_byte, target_dirty_ratio, target_dirty_ratio_high 的調(diào)整，在此不一一贅述。
通過上述一系列優(yōu)化， 如圖 3 所示，在寫入側(cè)， Cache Tier 非常好地完成了寫入緩沖與合并，來自應(yīng)用的 25K IOPS 經(jīng)由 Cache Tier 緩沖與合并之后到 Base Tier(fs_data) 寫入請求只有 1.5K IOPS。
換句話說，通過 Cache Tier 我們減少了 94 的寫 IOPS。
圖 3 集群客戶端寫入性能（點(diǎn)擊可查看大圖）
而在讀取側(cè)，如圖 4 所示，幾乎所有的 IO 都在 Cache Tier 上發(fā)生， Base Tier 讀流量近乎為 0 。
圖 4 集群客戶端讀取性能（點(diǎn)擊可查看大圖）
綜合來看， 在 Cache Tier 上的總 IOPS 達(dá)到了 70K ，而 Base Tier 只有 1.5K IOPS。通過深入理解業(yè)務(wù)的 IO 模型，合理配置 Cache Tier，我們實(shí)現(xiàn)了 分層存儲 。
應(yīng)用享受到了全閃存集群的性能，成本上卻接近全機(jī)械盤的價(jià)格，實(shí)現(xiàn)了了性價(jià)比最大化。
03 遇到的問題
下面分享幾個(gè)在實(shí)施日志存儲方案中遇到的 軟硬件問題 ，附上我們的 解決方案 ，以供大家參考。
1. Bluestore Allocator(空間分配器）
在上線過程中，我們很順利地度過了 25%， 50% 的流量。但在 75% 流量時(shí)，遇到了詭異的性能問題。
如下圖 5 所示， Cache Tier 的寫入延遲暴增 ，甚至能達(dá)到分鐘級別，通過 OSD Performance Counter 很快把問題縮小到 Bluestore 內(nèi)部, 結(jié)合日志發(fā)現(xiàn)延遲主由
STATE_KV_COMMITING_LATSTATE_KV_COMMITING_LAT 約等于 commit_lat。
我們第一個(gè)懷疑的對象是 RocksDB 的性能，尤其是 compaction 帶來的影響，并在此做了大量的調(diào)優(yōu)，然而一無所獲。
但我們發(fā)現(xiàn)，在調(diào)優(yōu)的過程中，為了修改參數(shù)重啟 OSD 服務(wù)后，被重啟的 OSD 能保持 20 小時(shí) 良好性能，之后延遲慢慢衰減到重啟以前。 既然重啟 OSD 能暫時(shí)緩解問題，那 RocksDB 就沒有嫌疑了 。
圖 5 Bluestore commit latency 性能監(jiān)控（點(diǎn)擊可查看大圖）
如下圖 6 所示，進(jìn)一步觀察分析 性能計(jì)數(shù)器（performance counter） 的數(shù)據(jù)并結(jié)合代碼，我們注意到： STATE_KV_DONE_LAT 雖然平均值只有 STATE_KV_COMMITING_LAT 的 3% ，但與 STATE_KV_COMMITING_LAT 有明顯的相關(guān)性。
這個(gè)發(fā)現(xiàn)大大縮小了問題的范圍，因?yàn)?STATE_KV_DONE_LAT 所覆蓋的代碼范圍基本只包含 _txc_finish 這一個(gè)函數(shù)。在某些時(shí)候，_txc_finish 釋放空間后，需要等待超過 100 毫秒 才能獲得分配器的鎖。同時(shí)， perf 的結(jié)果也指向了 StupidAllocator 這個(gè)循環(huán) 。
圖 6（點(diǎn)擊可查看大圖）
如下圖 7 所示，進(jìn)一步分析日志，我們發(fā)現(xiàn)在 StupidAllocator 中的空間碎片非常嚴(yán)重 。雖然磁盤利用率不超過 50% ，但分配器里已經(jīng)沒有超過 256K 的 數(shù)據(jù)段（segment） 可供分配。這就解釋了為什么 StupidAllocator 會(huì)在上述的分配空間循環(huán)中耗費(fèi)大量時(shí)間。因?yàn)榉峙鋾r(shí)持有了分配器鎖，所以釋放空間時(shí)需要等待很長時(shí)間來獲得鎖。
圖 7（點(diǎn)擊可查看大圖）
通過分析 Bluestore 的分配表，我們發(fā)現(xiàn)其實(shí)物理空間并沒有碎片化，只是 StupidAllocator 在內(nèi)存中的實(shí)現(xiàn)導(dǎo)致了碎片化。
StupidAllocator 是一個(gè)類似于內(nèi)存管理中 Buddy 分配的一個(gè)實(shí)現(xiàn)。
通過下圖 8 的例子，我們看看碎片是如何產(chǎn)生的：
一個(gè) 20K 的連續(xù)空間，經(jīng)過 5 次 4K 分配，和亂序的 5 次 對應(yīng)的 4K 釋放后，會(huì)變成 8k+4k+8k 三塊空間。
其中 [8K, 12K) 區(qū)域已經(jīng)是個(gè)碎片，但因?yàn)楹椭苓厖^(qū)塊不是同樣大小，落到不同的 bin 中，已經(jīng)很難再被合并了，而類似的操作序列，在 Bluestore 日常面臨的空間分配回收請求中并不鮮見。
OSD 重啟過程中， 分配器的內(nèi)存結(jié)構(gòu)會(huì)根據(jù)磁盤上的位圖重新建立，恰好是一次全局的合并，這也就解釋了為什么重啟服務(wù)能暫時(shí)緩解這個(gè)問題。
圖 8（點(diǎn)擊可查看大圖）
我們首先在社區(qū)發(fā)現(xiàn)定位了這個(gè)問題，并與核心開發(fā)者一起驗(yàn)證了 Naultilus 中的 位圖分配器（Bitmap Allocator） 沒有類似問題，且性能表現(xiàn)更為穩(wěn)定。因此也使得位圖分配器被完整地反向移植到 Luminous 和 Mimic 版本中，并成為默認(rèn)分配器。
2. 應(yīng)對 SSD 穩(wěn)態(tài)性能下降
關(guān)于 SSD 性能有一個(gè)并不冷門的常識——SSD 的穩(wěn)態(tài)性能與標(biāo)稱性能不一定是一致的。對于普通數(shù)據(jù)中心級別的 SSD 來說， 穩(wěn)態(tài)性能 通常比 非穩(wěn)態(tài)性能 低（相應(yīng)的，非穩(wěn)態(tài)可以認(rèn)為 SSD 尚有足夠空間供分配，或者后臺維護(hù)行為對業(yè)務(wù) IO 無干擾），非寫入密集型的型號差距會(huì)尤其明顯。
SSD 進(jìn)入穩(wěn)態(tài)是需要一定寫入量和時(shí)間的，因此在做硬件性能和軟件性能調(diào)優(yōu)時(shí)需要將這個(gè)因素充分考慮進(jìn)去，否則實(shí)際產(chǎn)品運(yùn)行起來以后就會(huì)出現(xiàn)意料不到的問題。
圖 9 是我們實(shí)測某 DWPD 為 0.7 的產(chǎn)品穩(wěn)態(tài)與非穩(wěn)態(tài)性能比較。 藍(lán)色線 是穩(wěn)態(tài)性能， 橘色線 是非穩(wěn)態(tài)性能（對 SSD 做了全盤 TRIM)。
圖 9 SSD 穩(wěn)態(tài)與非穩(wěn)態(tài)性能對比（點(diǎn)擊可查看大圖）
受限于成本以及當(dāng)前可用服務(wù)器選擇，我們所采用的 SSD 即屬于 非寫入密集型 （DWPD 較低），同機(jī)型同容量，來自 3 個(gè) 不同廠商的 SSD 的 DWPD 分布在 0.7～1 之間。而 eBay 日志存儲 Cache Tier 恰好是寫入讀取都很密集的類型。這下，我們似乎面臨了巧婦難為無米之炊的困境。
基于我們對 SSD 實(shí)現(xiàn)原理的理解，非寫入密集型 SSD（DWPD 指標(biāo)低）穩(wěn)態(tài)與非穩(wěn)態(tài)性能差距大的主要原因之一是廠商針對這類 SSD 的產(chǎn)品設(shè)計(jì)上，出廠預(yù)留的 Over Provision 空間 較小。
當(dāng)合理的產(chǎn)品設(shè)計(jì)面臨“不合理”的業(yè)務(wù)需求時(shí)，大寫入壓力持續(xù)一段時(shí)間以后，SSD 固件做 空間整理 和 垃圾回收（GC） 的效率會(huì)變低。應(yīng)用端的表現(xiàn)是在持續(xù)的大負(fù)載寫入下，GC 發(fā)生時(shí)延遲和吞吐都會(huì)受到很大的負(fù)面影響。
分析完這個(gè)可能原因后，在無法變更硬件的前提下，我們的解決辦法是通過主動(dòng)預(yù)留空間，來彌補(bǔ)廠商原有 OP 先天不足的“缺點(diǎn)”：
在 SSD 被加入集群前，我們對全盤 TRIM 之后，分區(qū)時(shí)只使用 80% 的空間；留下 20% 被 TRIM 過的區(qū)域因?yàn)樵诠碳?FTL 中標(biāo)記為空閑，自然會(huì)在 GC 等操作的時(shí)候當(dāng)作緩沖來使用。加上這額外的 20% OP 后，我們 SSD 的寫入延遲和帶寬都能穩(wěn)定在最佳狀態(tài)（圖 9 中 橘色線 的性能）。
這套實(shí)踐應(yīng)用在同機(jī)型、多批次來自 3 個(gè)不同廠商的 SSD 上都獲得同樣好的效果，上線至今并未觀察到衰減。
那么 20% 的空間預(yù)留是目前的經(jīng)驗(yàn)值，當(dāng)應(yīng)用行為有所改變時(shí) SSD 性能再次衰減又該怎么應(yīng)對呢？需要停下服務(wù)重新修改預(yù)留空間大小嗎？
其實(shí)不然， 對于已經(jīng)衰減的 SSD, 只需要 TRIM 20 的區(qū)域提供 OP，再經(jīng)過一個(gè)完整的寫入周期后，性能就可以回升到最佳狀態(tài) 。
圖 10 展示的就是這樣一個(gè)過程，在模擬測試開始約 600 秒 時(shí)，性能開始大幅下降，此時(shí)對預(yù)留的 20% 區(qū)域做 TRIM，經(jīng)過一個(gè)多小時(shí)，性能逐步回升，最終回到峰值并持續(xù)穩(wěn)定下去。
圖 10 對預(yù)留區(qū)域 TRIM 恢復(fù)全盤性能測試（點(diǎn)擊可查看大圖）
在這里需要指出：上述經(jīng)驗(yàn)是我們基于存儲產(chǎn)品的理解和合理猜測基礎(chǔ)上，經(jīng)測試驗(yàn)證通過，并在生產(chǎn)中應(yīng)用的。 限于條件和知識所限，我們無法進(jìn)一步探究 OP 是否是同系列不同定位的 SSD 產(chǎn)品之間的主要差別 。
通過我們所接觸的有限樣本中的數(shù)據(jù)，可得出以下觀點(diǎn)： 讀密集型 SSD 加上大的 OP，能達(dá)到同系列寫入密集型 SSD 同樣的性能和可靠性，但我們并不確定該經(jīng)驗(yàn)是否在更大范圍內(nèi)具有通用性 。這里僅供讀者參考，也歡迎來自各廠商的專家提供更多的分享。
04 總結(jié)
在 eBay 存儲團(tuán)隊(duì)和業(yè)務(wù)團(tuán)隊(duì)的無縫合作下，我們完美地將 eBay 應(yīng)用的日志從商業(yè)存儲遷移到了 CephFS 上，達(dá)到了非常高的性能和費(fèi)效比（遷移給 eBay 帶來的成本下降在單數(shù)據(jù)中心達(dá) 數(shù)百萬美金 ）。整個(gè)方案沒有單點(diǎn)和瓶頸，各個(gè)部分均可以橫向拓展，支撐更高的性能和吞吐。
CephFS由于成熟得相對晚，在國內(nèi)外的大規(guī)模商用案例有限，更多的被作為歸檔和冷存儲使用，較少有大流量的線上業(yè)務(wù)應(yīng)用。盡管我們比較激進(jìn)的使用了 MultiMDS 多活 ， Cache Tier 等當(dāng)前在業(yè)界還較少部署的技術(shù)， 但 CephFS 在大流量的生產(chǎn)環(huán)境中證明了自己的價(jià)值和穩(wěn)定性，為其他 eBay 內(nèi)部應(yīng)用遷移到 CephFS 打下了堅(jiān)實(shí)的基礎(chǔ) 。
