在昨天寫了《IDF15：Xeon D被閹割?SSD性能的“色子效應”》一文之后，有位業內專家提出了批評，我先虛心接受。

“那是2012年3500剛出來的東西，現在的SSD，特別是3D的出現，已經把并發度的問題直接ko了。”

“現在SSD的應用，特別是用在云計算和RDS，隊列深度肯定不止64了。有一家的RDS直接是64個實例。”

和專業人士比起來，我確實有些班門弄斧。不過，寫東西出來也只是希望幫大家開闊一下思路，今天我再寫點偏軟件的，不算自己太擅長的領域吧：)

三種數據副本一致性模型

首先我們看下Ceph的讀/寫流程。以3副本為例，寫入操作會先到主副本所在的服務器，然后復制到另外2個副本的服務器并全部返回ok，才向客戶端確認。這屬于主從副本強一致性的模型。而讀取操作只針對主副本，在訪問并發度足夠的情況下，讀請求會被打散到足夠多的驅動器以消除熱點。

上圖來自我的朋友@劉愛貴 的演講資料，他是國內知名分布式文件系統專家，特別擅長Gluster，目前在Server SAN領域創業。

我們看到除了Ceph的Master-slave replication之外，還有另外兩種強一致性模型——Chain replication(鏈式復制)和Direct replication(直接復制)，Gluster采用的應該是直接復制。

Gluster這種方式的好處，就是存儲節點之間沒有數據流量，但客戶端寫入時直接就要3份(以3副本為例)，那么網卡的帶寬利用率只有1/3;Ceph的網絡開銷則增加在OSD存儲節點之間的互連上面，1個萬兆客戶端接口要對應2個OSD集群連接才能充分發揮帶寬，當然如果利用上全雙工，3副本至少要用2個網口才算優化吧?

#p#

Ceph塊存儲性能預估與測試

Intel資料里的測試環境，3臺客戶機配置不同，每臺上面跑40個運行fio負載的虛擬機。4個存儲節點配置相同，每臺10塊7200轉硬盤，2個400GB DC S3700 SSD放的是Journal日志。

測量原始性能——也就是單個HDD的性能，單盤的4KB隨機寫比讀還快是緩存的因素。這里在OSD上用隨機512KB替代客戶端64KB順序負載的原因應該是：后者的連續存儲目標會被Hash(CRUSH)算法打散在集群中的不同位置。我記得UnitedStack曾經在一個活動上用隨機讀來展示Ceph的性能(接近萬兆網卡瓶頸)，當時有人說是針對Ceph特點來設計的，我關鍵還在于提高并發度吧?

預計集群性能——這里是按照2副本來配置，所以理想狀態下可以達到40塊硬盤的讀取性能，和20塊硬盤的寫入性能。

實測結果如上表，我就不過多解釋了。

#p#

Ceph對象性能測試、瓶頸分析

Ceph的對象存儲需要增加Rados網關，這方面顯然沒有Swift這樣原生來的理想，價值在哪里呢?下面我給出UnitedStack 朱榮澤 兄弟的2頁ppt來解釋一下，有些朋友應該看到過了：)

這里的測試方法與前面針對Ceph塊設備的就不同了。首先128KB讀取的“平均閑置時間”(翻譯成平均訪問時間應該更準確)可能是被緩存命中了?讀IOPS和帶寬基本上達到了寫的3倍(因為是3副本)，而10MB的讀/寫的平均訪問時間基本上也是3倍的關系。不知道Gluster文件系統用類似的方法測試結果會如何?

最右邊一列出的“瓶頸”分析也挺有價值的。其中10MB讀/寫帶寬分別達到了RGW和OSD網卡的瓶頸，這里可以看出3副本的OSD節點用一個網口不夠了吧?

#p#

SSD Cache分層和糾刪碼優化

之前我們知道像UnitedStack托管云這樣的配置了全SSD Ceph集群。對于冷數據比例較大的應用，可能對容量有更多需求，這時混合存儲可能是個更好的方式，而Ceph對Cache分層的支持也在不斷成熟。

如上圖，SSD Cache層用副本保護模式，HDD支持層用糾刪碼進一步降低成本。這讓我想起以前聽過淘寶的TFS也有3副本和糾刪碼兩個分層，不過都是在硬盤之間按數據冷熱度遷移。

采用“代理讀寫”的方式優化，針對Cache層的IO路徑變得更加直接。我聯想到Dell Compellent陣列的自動分層存儲也是數據先進到高速SSD層再“下沉”，不過這類技術的數據塊定位有元數據來跟蹤，而不是讀/寫都永遠經過“代理”。

關于糾刪碼(擦除編碼)和多副本的對比，我在去年的《IDF14：軟硬兼施冷存儲 Atom C2000打倒ARM?》一文中提到過。據了解Swift對象存儲對它的支持還不成熟，不知道主要針對塊存儲(高性能)應用的Ceph進展如何?

一看到糾刪碼性能的優化，Intel又高興了——這里再次出現ISA-L的身影。干用計算來換時間的事情，CPU強大的能力就不用擔心被浪費，跑ZFS文件系統等也是如此。

最后列出Ceph的最佳部署實踐，僅供參考。

博文出處：http://blog.sina.com.cn/s/blog_69406f8d0102vhdo.html