Ceph:針對云工作負載性能測試及優(yōu)化淺析

作者：唐僧_huangliang 2015-07-28 14:18:21

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

成都創(chuàng)新互聯(lián)專注于武宣企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè)公司,購物商城網(wǎng)站建設(shè)。武宣網(wǎng)站建設(shè)公司,為武宣等地區(qū)提供建站服務(wù)。全流程按需策劃，專業(yè)設(shè)計，全程項目跟蹤，成都創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

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

“那是2012年3500剛出來的東西，現(xiàn)在的SSD，特別是3D的出現(xiàn)，已經(jīng)把并發(fā)度的問題直接ko了?！?/p>

“現(xiàn)在SSD的應(yīng)用，特別是用在云計算和RDS，隊列深度肯定不止64了。有一家的RDS直接是64個實例?！?/p>

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

三種數(shù)據(jù)副本一致性模型

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

上圖來自我的朋友@劉愛貴 的演講資料，他是國內(nèi)知名分布式文件系統(tǒng)專家，特別擅長Gluster，目前在Server SAN領(lǐng)域創(chuàng)業(yè)。

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

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

#p#

Ceph塊存儲性能預(yù)估與測試

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

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

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

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

#p#

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

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

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

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

#p#

SSD Cache分層和糾刪碼優(yōu)化

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

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

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

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

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

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

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

當前題目：Ceph:針對云工作負載性能測試及優(yōu)化淺析
文章源于：http://m.fisionsoft.com.cn/article/dpiseee.html