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

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

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

成都創(chuàng)新互聯(lián)專注于武宣企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè)公司,購物商城網(wǎng)站建設(shè)。武宣網(wǎng)站建設(shè)公司,為武宣等地區(qū)提供建站服務(wù)。全流程按需策劃，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，成都創(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)用，特別是用在云計(jì)算和RDS，隊(duì)列深度肯定不止64了。有一家的RDS直接是64個(gè)實(shí)例。”

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

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

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

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

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

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

#p#

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

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

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

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

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

#p#

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

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

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

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

#p#

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

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

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

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

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

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

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

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

分享名稱：Ceph:針對云工作負(fù)載性能測試及優(yōu)化淺析
本文路徑：http://www.dlmjj.cn/article/dpiseee.html