【圖1：滿條帶寫】
【圖2：滿條帶讀】
【圖3：非條帶讀】
【圖4：非條帶寫】
【圖5：有硬盤故障時(shí)的滿條帶讀】
【圖6：有硬盤故障時(shí)的非條帶讀】
EC和三副本的讀寫消耗對比
假設(shè)EC 4+2 的分片數(shù)據(jù)塊大小是32KB，下面是不同數(shù)據(jù)塊大小的讀寫請求所消耗的IO次數(shù)和帶寬，消耗倍數(shù)越多，性能越差。
【表1：EC和三副本的讀寫消耗對比】
EC和三副本的性能對比
由此我們可以得出EC和三副本的性能對比，可以看到EC在小塊隨機(jī)讀寫的性能比三副本差，但是EC在大塊順序?qū)懙男阅鼙热北疽煤芏唷?/p>
【表2：EC和三副本的性能表現(xiàn)對比】
*
假設(shè)EC 4+2，EC分片數(shù)據(jù)塊大小是32KB。假設(shè)寫入的文件/對象大小都是小于128KB，則存在空間浪費(fèi)。假如平均文件大小是64KB，則會(huì)浪費(fèi)50%，假如平均文件大小是32KB，則會(huì)浪費(fèi)75%
從上可知EC的三大缺點(diǎn)是：
小塊隨機(jī)寫的IO消耗很大，導(dǎo)致在HDD配置下性能很差。
對于小文件場景，空間浪費(fèi)嚴(yán)重。
小塊隨機(jī)讀在命中故障盤情況下的IO消耗很大，導(dǎo)致在HDD配置性能很差。
我們已經(jīng)知道了EC的三大缺點(diǎn)，那么在塊存儲(chǔ)應(yīng)該如何使用EC呢？
塊存儲(chǔ)該如何使用EC
塊存儲(chǔ)承接的場景很多，包括虛擬化、云平臺、數(shù)據(jù)庫等。這些場景會(huì)產(chǎn)生非常多的小塊隨機(jī)讀寫負(fù)載（特別是虛擬化平臺，俗稱IO攪拌機(jī)），這就要求塊存儲(chǔ)系統(tǒng)需要支持萬級別的小塊隨機(jī)讀寫IOPS，并且時(shí)延要在5ms級別內(nèi)，這正好是普通EC的缺點(diǎn)，應(yīng)該如何解決呢？
目前對于塊存儲(chǔ)使用EC，有三種方案來解決。
第一種，vSAN
vSAN支持EC，但僅支持在全閃配置下使用EC，屬于硬剛EC，也就是要使用硬件SSD的性能去彌補(bǔ)EC的性能缺點(diǎn)。
【表3：vSAN如何解決EC的問題】
第二種，Ceph Cache Tiering
社區(qū)版 Ceph 的 Cache Tiering 的初衷很好，是希望通過增加新的一層的辦法，也就是分層架構(gòu)(三副本 SSD 存儲(chǔ)池+ EC HDD 存儲(chǔ)池)來規(guī)避EC的缺點(diǎn)，充分利用EC的優(yōu)點(diǎn)。
但社區(qū)版Ceph的 Cache Tiering 架構(gòu)的設(shè)計(jì)有很多問題沒有考慮到，導(dǎo)致無法在生產(chǎn)環(huán)境中使用。已經(jīng)有很多案例證明，社區(qū)版Ceph的 Cache Tiering 在塊存儲(chǔ)生產(chǎn)環(huán)境上出現(xiàn)問題。
目前Ceph社區(qū)不建議在塊存儲(chǔ)上使用 Cache Tiering，因?yàn)樗袊?yán)重的性能問題，相關(guān)鏈接是 https://docs.ceph.com/en/latest/rados/operations/cache-tiering/#known-bad-workloads 。
RedHat也早就聲明已棄用 Cache Tiering功能，因?yàn)樵摴δ懿粫?huì)為大多數(shù) Ceph 工作負(fù)載提供任何性能改進(jìn)，并且在在使用時(shí)會(huì)給集群帶來穩(wěn)定性問題，相關(guān)鏈接是 https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/2.0/html/release_notes/deprecated_functionality 。
下面我們來講講 Ceph 的 Cache Tiering 架構(gòu)。
【圖7：Ceph Cache Tiering架構(gòu)】
Cache Tiering有四種模式：
【表4：Ceph Cache Tiering的四種模式】
因?yàn)樵?Cache Tier 和 Storage Tier 之間的數(shù)據(jù)遷移的粒度是4MB，當(dāng)一個(gè)對象在做數(shù)據(jù)遷移時(shí)，至少需要等待1~2秒以上。那么依賴于數(shù)據(jù)遷移的小塊讀寫請求就阻塞1~2秒。
只有當(dāng)工作負(fù)載局部性很高并且是確定性的，這樣大多數(shù)請求都只是訪問少量對象時(shí)，則 Cache Tiering 才會(huì)有效。或者是Cache Pool足夠大，能夠保證大多數(shù)的讀寫請求都能夠命中Cache，才能避免性能抖動(dòng)。
但這導(dǎo)致 Cache Tiering非常不實(shí)用，因?yàn)橐叨纫蕾囉诠ぷ髫?fù)載模式(有確定性的熱數(shù)據(jù)集)。但是大部分場景的熱數(shù)據(jù)集是在不斷變化的，這使得 Cache Tiering 在實(shí)際場景中的性能很糟糕，IOPS會(huì)急劇跌落，并出現(xiàn)秒級別的時(shí)延。
而且 Cache Tiering 的另外一個(gè)缺點(diǎn)是配置復(fù)雜，學(xué)習(xí)成本高，用戶需要很好地了解他們的工作負(fù)載，并且需要仔細(xì)調(diào)整緩存分層參數(shù)。
社區(qū)Ceph的Cache Tiering失敗的原因包括：
把重心放在Tiering(數(shù)據(jù)遷移)，數(shù)據(jù)遷移的粒度是整個(gè)對象(4M)，遷移成本非常高。
數(shù)據(jù)遷移和刷盤的觸發(fā)機(jī)制太敏感(太簡單)，導(dǎo)致性能劇烈抖動(dòng)。
如何在基準(zhǔn)測試中快速驗(yàn)證社區(qū)Ceph的 Cache Tiering 的問題呢？假設(shè)Ceph存儲(chǔ)池中，Cache Pool是1TB可用容量，Backend Pool是60TB可用容量。則可以通過以下方式進(jìn)行快速驗(yàn)證：
創(chuàng)建8個(gè)4TB的卷。往20個(gè)卷中填滿數(shù)據(jù)。保證卷的總大小大于Backend Pool的50%，保證卷的總大小是Cache Pool的10倍以上。
使用fio或vdbench對這8個(gè)卷做100%LBA全盤8K隨機(jī)讀寫(3:7)，數(shù)據(jù)量是4T。保證測試的數(shù)據(jù)集范圍大于大于Backend Pool的50%，保證測試的數(shù)據(jù)量是Cache Pool的4倍。
因?yàn)槭窃?2TB的數(shù)據(jù)集里面做100%LBA的8KB隨機(jī)讀寫，遠(yuǎn)遠(yuǎn)大于Cache Pool的容量，因此會(huì)導(dǎo)致頻繁數(shù)據(jù)遷移，所以測試結(jié)果非常差。
第三種，XSpeed
在表2中，我們看到了三副本和EC的性能對比，想同時(shí)擁有三副本和EC的好處，應(yīng)該怎么辦？怎么才能解決EC小塊隨機(jī)寫性能差的問題呢？我們設(shè)計(jì)和開發(fā)了XSpeed架構(gòu)，三管齊下：
分層：XSpeed存儲(chǔ)池采用全局分層架構(gòu)，其中數(shù)據(jù)層可以使用EC，同時(shí)Cache層使用三副本提供高性能的讀寫能力。并且分層后，Cache層的硬盤（主要是SSD）和數(shù)據(jù)層的硬盤（主要是HDD）沒有綁定關(guān)系，換盤更方便。
全局Cache：Cache粒度不是整個(gè)對象，而是4~64KB的數(shù)據(jù)塊，通過智能Cache算法，保證寫Cache刷盤和讀Cache Promote的精細(xì)化控制。
LogAppend刷盤技術(shù)：LogAppend模塊可以把隨機(jī)小塊寫IO聚合成大塊順序?qū)?，然后再回刷到?shù)據(jù)層中。數(shù)據(jù)層的大塊順序?qū)懶阅芎芨撸钥梢钥焖侔雅K數(shù)據(jù)回刷到數(shù)據(jù)層，騰出Cache空間給前端業(yè)務(wù)使用。對于EC數(shù)據(jù)層，聚合成大塊順序條帶寫入，不會(huì)有寫放大問題，性能最高。LogAppend模塊不僅聚合隨機(jī)小塊，而且還對數(shù)據(jù)進(jìn)行壓縮和縮減，為用戶節(jié)省更多空間。Log Append刷盤技術(shù)保證大壓力下性能平穩(wěn)。
【圖8：LogAppend模塊示意圖】
【圖9：“永遠(yuǎn)不會(huì)被擊穿的Cache”——Log Append 刷盤技術(shù)】
XSpeed分層技術(shù)消滅了隨機(jī)小塊寫，兼顧高性能與經(jīng)濟(jì)性：
Cache層承接小IO寫性能以及第一級讀性能
數(shù)據(jù)層承接大IO讀寫性能，以及第二級小IO讀性能，提供持續(xù)高性能服務(wù)
通過LogAppend刷盤寫技術(shù)，保證寫入數(shù)據(jù)層都是大塊順序?qū)慖O，充分發(fā)揮HDD和QLC SSD的順序?qū)懲掏履芰Α?/p>
假如數(shù)據(jù)層采用的是QLC SSD，則大塊順序?qū)慖O保證QLC SSD得性能和壽命。
QLC層提供穩(wěn)定的小塊IO讀性能，解決混合場景Cache讀miss 帶來的性能衰減問題。
緩存層和數(shù)據(jù)層分開，換盤方便，運(yùn)維簡單。
XSpeed在混合存儲(chǔ)中的優(yōu)勢
【表5：XSpeed在混合存儲(chǔ)中的優(yōu)勢】
XSpeed在全閃存儲(chǔ)中的優(yōu)勢
【表6：XSpeed在全閃存儲(chǔ)中的優(yōu)勢】
總結(jié)
我們設(shè)計(jì)和開發(fā)的XSpeed存儲(chǔ)池，搞定了塊存儲(chǔ)EC，并且可以更好支持QLC，包括以后的SMR HDD。XSpeed技術(shù)升級了XSKY SDS V5版本的底座，滿足了全場景EC，實(shí)現(xiàn)了可靠性、性能和經(jīng)濟(jì)性三者兼顧。
本文 作者：IO Ripper
