亚洲精品国产第一区第二区,中文字幕一精品亚洲无线一区

【圖1：滿條帶寫】

【圖2：滿條帶讀】

【圖3：非條帶讀】

【圖4：非條帶寫】

【圖5：有硬盤故障時的滿條帶讀】

【圖6：有硬盤故障時的非條帶讀】

EC和三副本的讀寫消耗對比

假設EC 4+2 的分片數據塊大小是32KB，下面是不同數據塊大小的讀寫請求所消耗的IO次數和帶寬，消耗倍數越多，性能越差。

【表1：EC和三副本的讀寫消耗對比】

EC和三副本的性能對比

由此我們可以得出EC和三副本的性能對比，可以看到EC在小塊隨機讀寫的性能比三副本差，但是EC在大塊順序寫的性能比三副本要好很多。

【表2：EC和三副本的性能表現對比】

假設EC 4+2，EC分片數據塊大小是32KB。假設寫入的文件/對象大小都是小于128KB，則存在空間浪費。假如平均文件大小是64KB，則會浪費50%，假如平均文件大小是32KB，則會浪費75%

從上可知EC的三大缺點是：

小塊隨機寫的IO消耗很大，導致在HDD配置下性能很差。

對于小文件場景，空間浪費嚴重。

小塊隨機讀在命中故障盤情況下的IO消耗很大，導致在HDD配置性能很差。

我們已經知道了EC的三大缺點，那么在塊存儲應該如何使用EC呢？

塊存儲該如何使用EC

塊存儲承接的場景很多，包括虛擬化、云平臺、數據庫等。這些場景會產生非常多的小塊隨機讀寫負載（特別是虛擬化平臺，俗稱IO攪拌機），這就要求塊存儲系統(tǒng)需要支持萬級別的小塊隨機讀寫IOPS，并且時延要在5ms級別內，這正好是普通EC的缺點，應該如何解決呢？

目前對于塊存儲使用EC，有三種方案來解決。

第一種，vSAN

vSAN支持EC，但僅支持在全閃配置下使用EC，屬于硬剛EC，也就是要使用硬件SSD的性能去彌補EC的性能缺點。

【表3：vSAN如何解決EC的問題】

第二種，Ceph Cache Tiering

社區(qū)版 Ceph 的 Cache Tiering 的初衷很好，是希望通過增加新的一層的辦法，也就是分層架構(三副本 SSD 存儲池+ EC HDD 存儲池)來規(guī)避EC的缺點，充分利用EC的優(yōu)點。

但社區(qū)版Ceph的 Cache Tiering 架構的設計有很多問題沒有考慮到，導致無法在生產環(huán)境中使用。已經有很多案例證明，社區(qū)版Ceph的 Cache Tiering 在塊存儲生產環(huán)境上出現問題。

目前Ceph社區(qū)不建議在塊存儲上使用 Cache Tiering，因為它有嚴重的性能問題，相關鏈接是 https://docs.ceph.com/en/latest/rados/operations/cache-tiering/#known-bad-workloads 。

RedHat也早就聲明已棄用 Cache Tiering功能，因為該功能不會為大多數 Ceph 工作負載提供任何性能改進，并且在在使用時會給集群帶來穩(wěn)定性問題，相關鏈接是 https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/2.0/html/release_notes/deprecated_functionality 。

下面我們來講講 Ceph 的 Cache Tiering 架構。

【圖7：Ceph Cache Tiering架構】

Cache Tiering有四種模式：

【表4：Ceph Cache Tiering的四種模式】

因為在 Cache Tier 和 Storage Tier 之間的數據遷移的粒度是4MB，當一個對象在做數據遷移時，至少需要等待1~2秒以上。那么依賴于數據遷移的小塊讀寫請求就阻塞1~2秒。

只有當工作負載局部性很高并且是確定性的，這樣大多數請求都只是訪問少量對象時，則 Cache Tiering 才會有效?；蛘呤荂ache Pool足夠大，能夠保證大多數的讀寫請求都能夠命中Cache，才能避免性能抖動。

但這導致 Cache Tiering非常不實用，因為要高度依賴于工作負載模式(有確定性的熱數據集)。但是大部分場景的熱數據集是在不斷變化的，這使得 Cache Tiering 在實際場景中的性能很糟糕，IOPS會急劇跌落，并出現秒級別的時延。

而且 Cache Tiering 的另外一個缺點是配置復雜，學習成本高，用戶需要很好地了解他們的工作負載，并且需要仔細調整緩存分層參數。

社區(qū)Ceph的Cache Tiering失敗的原因包括：

把重心放在Tiering(數據遷移)，數據遷移的粒度是整個對象(4M)，遷移成本非常高。

數據遷移和刷盤的觸發(fā)機制太敏感(太簡單)，導致性能劇烈抖動。

如何在基準測試中快速驗證社區(qū)Ceph的 Cache Tiering 的問題呢？假設Ceph存儲池中，Cache Pool是1TB可用容量，Backend Pool是60TB可用容量。則可以通過以下方式進行快速驗證：

創(chuàng)建8個4TB的卷。往20個卷中填滿數據。保證卷的總大小大于Backend Pool的50%，保證卷的總大小是Cache Pool的10倍以上。

使用fio或vdbench對這8個卷做100%LBA全盤8K隨機讀寫(3:7)，數據量是4T。保證測試的數據集范圍大于大于Backend Pool的50%，保證測試的數據量是Cache Pool的4倍。

因為是在32TB的數據集里面做100%LBA的8KB隨機讀寫，遠遠大于Cache Pool的容量，因此會導致頻繁數據遷移，所以測試結果非常差。

第三種，XSpeed

在表2中，我們看到了三副本和EC的性能對比，想同時擁有三副本和EC的好處，應該怎么辦？怎么才能解決EC小塊隨機寫性能差的問題呢？我們設計和開發(fā)了XSpeed架構，三管齊下：

分層：XSpeed存儲池采用全局分層架構，其中數據層可以使用EC，同時Cache層使用三副本提供高性能的讀寫能力。并且分層后，Cache層的硬盤（主要是SSD）和數據層的硬盤（主要是HDD）沒有綁定關系，換盤更方便。

全局Cache：Cache粒度不是整個對象，而是4~64KB的數據塊，通過智能Cache算法，保證寫Cache刷盤和讀Cache Promote的精細化控制。

LogAppend刷盤技術：LogAppend模塊可以把隨機小塊寫IO聚合成大塊順序寫，然后再回刷到數據層中。數據層的大塊順序寫性能很高，所以可以快速把臟數據回刷到數據層，騰出Cache空間給前端業(yè)務使用。對于EC數據層，聚合成大塊順序條帶寫入，不會有寫放大問題，性能最高。LogAppend模塊不僅聚合隨機小塊，而且還對數據進行壓縮和縮減，為用戶節(jié)省更多空間。Log Append刷盤技術保證大壓力下性能平穩(wěn)。