黃遵祥，朱磊基，熊勇

(中國科學(xué)院上海微系統(tǒng)與信息技術(shù)研究所 中國科學(xué)院無線傳感網(wǎng)與通信重點實驗室， 上海 201800； 中國科學(xué)院大學(xué)， 北京 100049)

如今，越來越多的商業(yè)公司使用分布式存儲系統(tǒng)解決PB級數(shù)據(jù)存儲問題[1]。而分布式存儲系統(tǒng)Ceph作為軟件定義存儲的代表，被設(shè)計為可在眾多主流商用硬件上運行，因此具有部署成本低、擴展性高等優(yōu)點[2-3]，從而得到廣泛應(yīng)用。

與目前其他一些熱門的分布式存儲系統(tǒng)相比，當(dāng)需要對小文件進行頻繁修改時，Ceph比Hadoop表現(xiàn)更為出色[4]；相比較GlusterFS(gluster file system)，Ceph在系統(tǒng)擴容、縮容時對整個集群的數(shù)據(jù)服務(wù)影響更小[5]；與Sheepdog支持單一的存儲接口相比，Ceph同時提供主流的3種存儲接口等[6-7]。雖然與其他熱門的分布式存儲系統(tǒng)相比Ceph具有上述的很多優(yōu)勢，但其本身依然存在不足，以Intel為代表的商用硬件供應(yīng)商對Ceph讀寫性能的測試結(jié)果表明[8]：單線程下Ceph寫入速度只有原生磁盤的3.6%，在多線程條件下也只能達到原生磁盤的10%。究其寫性能不理想的主要原因是Ceph的多副本強一致性寫入機制[3]，即主副本要在本地寫入完成后，還要等待其余從副本寫入完成，當(dāng)所有副本都寫入完成，才會向客戶端返回最終的寫入完成。這種多副本強一致性寫入機制雖然保證了數(shù)據(jù)的安全性和可靠性，但也嚴(yán)重影響了集群的寫性能，同時由于各副本寫入速度的不盡相同，并且如遇到如網(wǎng)絡(luò)擁塞、從副本所在的OSD出現(xiàn)故障等問題，會導(dǎo)致整個集群的寫延遲出現(xiàn)劇烈波動，從而影響集群的穩(wěn)定性和魯棒性。

針對Ceph寫性能不理想的問題，文獻[8]優(yōu)化了Ceph后端存儲引擎FileStore，實現(xiàn)的nojournal-block模型用于提高系統(tǒng)的IO性能。從Jewel版本開始，Ceph引入BlueStore取代傳統(tǒng)存儲引擎FileStore，用于緩解寫放大問題，并針對SSD進行優(yōu)化，目前社區(qū)已經(jīng)推薦在生產(chǎn)環(huán)境中使用BlueStore。

文獻[9]提出一種根據(jù)不同的讀寫操作比例，決定最終副本同步與異步更新比例的方法。首先統(tǒng)計在一定時間內(nèi)讀寫操作的數(shù)量，通過不同數(shù)量的對比，決定當(dāng)前同步執(zhí)行寫操作的副本數(shù)量，從而實現(xiàn)寫操作占IO操作數(shù)比例越多，寫延遲越小的特性。

文獻[10]提出當(dāng)主副本OSD完成數(shù)據(jù)的日志盤和數(shù)據(jù)盤寫入后，向客戶端返回寫完成的改進方法，即主副本在完成本地事務(wù)的寫入數(shù)據(jù)盤操作后，才向客戶端返回寫完成。在該方法中如遇到數(shù)據(jù)盤寫入失敗也可以從日志盤進行恢復(fù)并重新寫入，所以日志盤成功寫入即可保證數(shù)據(jù)最終一定會寫入數(shù)據(jù)盤。

文獻[11]提出一種基于分布式哈希環(huán)的多副本弱一致性模型。該方法在一定程度上降低了寫延遲，但在復(fù)雜的應(yīng)用場景下該方法提高Ceph寫入速度的效果并不明顯，同時Ceph以對存儲數(shù)據(jù)的高可用著稱，但該多副本弱一致性模型可能會影響數(shù)據(jù)安全性和高可靠性。

文獻[12]研究了網(wǎng)絡(luò)配置對Ceph讀寫性能的影響，底層使用SSD的存儲集群則推薦使用至少能提供10Gbps的網(wǎng)絡(luò)配置，才能發(fā)揮最佳系統(tǒng)性能；文獻[13]分析了Ceph的CRUSH(controlled replication under scalable hashing)算法中各項參數(shù)對集群讀寫性能的影響；文獻[14]通過引入多流水線算法，每條流水線中包含一個生產(chǎn)者進程和一個消費者進程，利用多核CPU實現(xiàn)大文件IO性能的提升；文獻[15]通過設(shè)計SFPS (small file process system)框架，包括消除重復(fù)數(shù)據(jù)中的副本、合并相似小文件和引入數(shù)據(jù)緩存，提高CephFS的IO性能。

上述研究雖然在一定程度上提高了Ceph集群的寫性能，但同時也引入了很多新的問題，比如讀寫機制還有優(yōu)化空間、寫機制改進后破壞了Ceph對數(shù)據(jù)安全性和高可靠性保證、在實際部署中優(yōu)化效果不明顯等問題。因此本文對基于雙控節(jié)點的Ceph進行研究，通過改進多副本強一致性寫入機制，提高集群寫入性能。同時為保證數(shù)據(jù)依然具有安全性和高可靠性，集群使用雙控制器雙存儲陣列節(jié)點，確保集群內(nèi)部不需要通過數(shù)據(jù)遷移來實現(xiàn)多副本的存儲需求，降低節(jié)點間數(shù)據(jù)傳輸流量和副本磁盤讀寫流量，實現(xiàn)數(shù)據(jù)服務(wù)的不間斷和集群狀態(tài)的快速恢復(fù)。

1 Ceph基本架構(gòu)

本文在Ceph基本架構(gòu)基礎(chǔ)上提出改進算法，可將Ceph中的節(jié)點按照不同功能分成3類：

1)Monitor節(jié)點(MON)，負責(zé)收集、整理和分發(fā)集群的各類映射表。從Luminous版本開始，Ceph增加了全新的Manager節(jié)點(MGR)，負責(zé)實時追蹤集群狀態(tài)和集群各類參數(shù)的統(tǒng)計[1]。

2)Object Storage Device節(jié)點(OSD)，負責(zé)數(shù)據(jù)的最終存儲，同時還提供數(shù)據(jù)復(fù)制、恢復(fù)和再平衡等功能[16]。

3)MetaData Sever節(jié)點(MDS)，主要用于在CephFS(Ceph file storage)中對元數(shù)據(jù)進行管理[3]。

以上只是從功能角度對節(jié)點進行分類，可在同一臺物理服務(wù)器上運行多個服務(wù)進程實現(xiàn)上述的多種功能，從而對外提供不同的服務(wù)。

同時Ceph通過引入池(Pool)的概念，Pool中存放若干歸置組(placement group，PG)。Ceph通過執(zhí)行2次映射實現(xiàn)數(shù)據(jù)尋址：第1次靜態(tài)映射，輸入是任意類型的數(shù)據(jù)，按照默認4 M大小進行切割、編號，通過偽隨機哈希函數(shù)生成對應(yīng)的PGID[2]；第2次實現(xiàn)PG與OSD的相互映射，除了PGID，輸入還需要集群拓撲和相應(yīng)的CRUSH規(guī)則作為哈希函數(shù)的輸入[4]，最終得到一組OSD列表，即該數(shù)據(jù)對象的所有副本存儲位置。

Ceph可采用多副本或糾刪碼方式維護數(shù)據(jù)的安全性[17]，本文以多副本存儲方式為例，當(dāng)客戶端發(fā)起一個寫請求時，Ceph的數(shù)據(jù)寫入流程如圖1所示。由于采用的是多副本強一致性寫入機制[3]，客戶端首先通過上述數(shù)據(jù)尋址過程，得到該數(shù)據(jù)對象最終存儲的OSD列表，然后與列表中第一個OSD，即主副本OSD，發(fā)起寫請求；主副本OSD收到后分別向其余從副本OSD發(fā)起相應(yīng)事務(wù)，并開始本地寫，當(dāng)主副本OSD收到其余從副本OSD的寫入日志盤完成，并且本地也完成后，向客戶端返回寫入日志盤完成；當(dāng)主副本OSD收到其余從副本OSD的寫入數(shù)據(jù)盤完成應(yīng)答，并且本地也完成后，最終向客戶端返回寫入數(shù)據(jù)盤完成應(yīng)答。

圖1 Ceph數(shù)據(jù)寫入流程

(1)

各副本寫延遲如公式1所示，式中：TOSD1、TOSD2和TOSD3分別代表主副本OSD1、從副本OSD2和從副本OSD3的寫延遲，三者在時間軸上是并列關(guān)系；trp代表Request preprocessing，請求預(yù)處理階段；ttd代表Transaction dispatch，各從副本事務(wù)分發(fā)階段；twj代表Write journal，寫入日志盤階段；twd代表Write disk，寫入數(shù)據(jù)盤階段；tcs代表Completion status collection，各副本事務(wù)完成情況收集及各類回調(diào)操作階段。

因此可以發(fā)現(xiàn)，只有當(dāng)所有副本都寫入完成才向客戶端返回，同時由于各副本寫入速度的不盡相同，并且如遇到網(wǎng)絡(luò)擁塞、從副本所在的OSD出現(xiàn)故障等問題，無法確保從副本OSD及時完成相應(yīng)事務(wù)。因此，本文主要研究在保證數(shù)據(jù)安全性和高可靠性的基礎(chǔ)上，對上述的Ceph數(shù)據(jù)寫入機制進行優(yōu)化。

2 基于雙控節(jié)點的Ceph寫性能優(yōu)化

為保證寫入機制優(yōu)化后，Ceph數(shù)據(jù)存儲依然具有安全性和高可靠性，同時為避免存儲節(jié)點控制器出現(xiàn)故障時，集群需要通過數(shù)據(jù)遷移實現(xiàn)多副本存儲需求，集群使用雙控制器雙存儲陣列節(jié)點，雙控作為2個不同的OSD為集群提供數(shù)據(jù)存儲服務(wù)。采用雙控節(jié)點的分布式集群架構(gòu)如圖2所示。

圖2 雙控節(jié)點分布式集群架構(gòu)

2.1 雙控存儲節(jié)點的實現(xiàn)

節(jié)點正常工作時，雙控分別控制著各自的存儲陣列，并作為2個不同的OSD為集群提供數(shù)據(jù)存儲服務(wù)，當(dāng)雙控中一個控制器出現(xiàn)故障時，該節(jié)點另一個伙伴控制器創(chuàng)建新的OSD進程并快速接管故障控制器的存儲陣列，此時2個OSD進程運行在同一控制器上。為實現(xiàn)上述操作，首先需要區(qū)分出現(xiàn)的故障類型，節(jié)點故障分為臨時性故障和永久性故障[12]：前者包括主機重啟等，后者包括控制器損壞、磁盤損壞等。由于OSD之間通過周期性的心跳檢測，監(jiān)控彼此的狀態(tài)，當(dāng)超過一定時間閾值沒有收到雙控中另一個伙伴OSD的心跳消息，則向Monitor上報該OSD的失聯(lián)信息，同時，該控制器開始嘗試接管故障控制器的存儲陣列。在集群配置時，需要設(shè)置mon_osd_down_out_ subtree_limit配置項，用來限制當(dāng)集群在出現(xiàn)故障時，集群進行自動數(shù)據(jù)遷移的粒度。因為如果發(fā)生的是永久性故障中的控制器故障，底層磁盤上的數(shù)據(jù)都是完好的，可以通過雙控中另一個伙伴控制器啟動新的OSD進程，接管故障控制器的存儲陣列實現(xiàn)集群數(shù)據(jù)的快速恢復(fù)，從而避免通過數(shù)據(jù)遷移實現(xiàn)多副本存儲。

因此雙控節(jié)點接管故障控制器存儲陣列的操作主要步驟如下：

步驟1：確定同節(jié)點另一個控制器故障，通過OSD間周期性的心跳檢測，監(jiān)控彼此的狀態(tài)，當(dāng)超過一定時間閾值沒有收到雙控中另一個伙伴OSD的心跳消息就執(zhí)行步驟2；

步驟2：開始嘗試接管故障控制器的存儲陣列，首先讀取存儲陣列中的引導(dǎo)數(shù)據(jù)(bootstrap)用于身份驗證，具體引導(dǎo)數(shù)據(jù)如表1所示。接著創(chuàng)建tmpfs文件系統(tǒng)，并掛載到當(dāng)前控制器OS中的OSD directory中，通過使用ceph_bluestore_ tool獲取啟動故障OSD需要的元數(shù)據(jù)信息(這些元數(shù)據(jù)存儲在label中)，并寫入工作目錄中，接下來創(chuàng)建設(shè)備文件軟鏈接并變更設(shè)備的所有者和所有組，最后通過systemctl注冊系統(tǒng)服務(wù)，故障控制器存儲陣列對應(yīng)的OSD進程即可創(chuàng)建成功，并在同節(jié)點的伙伴控制器上開始執(zhí)行；

表1 通過讀取的OSD引導(dǎo)數(shù)據(jù)

步驟3：對重新啟動的OSD上存儲的所有PG進行數(shù)據(jù)一致性檢查，從而確保各副本數(shù)據(jù)的完全相同。

2.2 Ceph的寫性能優(yōu)化

在雙控節(jié)點存儲架構(gòu)基礎(chǔ)上，將Ceph寫入機制優(yōu)化為主副本OSD在本地寫入日志盤后，就向客戶端返回寫完成。之后主副本OSD本地寫入數(shù)據(jù)盤的完成情況、其余從副本OSD寫入日志盤完成應(yīng)答(applied)和從副本OSD寫入數(shù)據(jù)盤完成應(yīng)答(committed)則由主副本OSD在后臺繼續(xù)收集并完成后續(xù)各類回調(diào)操作。優(yōu)化后的寫入機制如圖3所示。

圖3 優(yōu)化后的寫入機制

T=trp+ttd+twj.

(2)

優(yōu)化后寫延遲如公式2所示，式中：T代表從主副本OSD收到客戶端發(fā)送的寫請求到向客戶端返回最終寫完成的時延；其余符號含義如公式1所示。

優(yōu)化后寫入機制具體步驟如下：

步驟1：客戶端首先對需要操作的數(shù)據(jù)計算出32位哈希值作為對象標(biāo)識，并作為輸入通過ceph_stable_mod計算出Pool中承載該對象的PG，然后通過CRUSH算法，得到該操作對象存放的主副本OSD，最終通過send_message向該OSD發(fā)送寫請求；

步驟2：主副本OSD收到客戶端發(fā)送的寫請求后，首先將message封裝成一個op，根據(jù)其中的PGID信息插入到對應(yīng)的op_shardedwq隊列，最終由osd_op_tp線程池中的線程開始步驟3的處理；

步驟3：該op首先通過do_request和do_op完成一系列檢查，前者完成PG層的檢查，后者完成包括初始化其中各種標(biāo)志位、op合法性校驗和最重要的獲取操作對象上下文(ObjectContext)，并創(chuàng)建OpContext用于承接客戶端對op的所有操作，并對該op后續(xù)執(zhí)行情況進行追蹤；

步驟4：通過execute_ctx執(zhí)行步驟3中生成的OpContext。步驟4～步驟6都是在execute_ctx中執(zhí)行，首先需要進行PG Transaction準(zhǔn)備，PG Transaction中封裝了一系列對原始對象的處理步驟，并和日志共同保證數(shù)據(jù)存儲的一致性。PG Transaction準(zhǔn)備階段包括：將op中的每個處理步驟轉(zhuǎn)化為PG Transaction中的操作，接著判斷是否需要對原始對象進行快照，最后生成日志并更新操作對象的OI(Object Info)和SS(Snap Set)屬性；

步驟5：接著將PG Transaction轉(zhuǎn)化為各個副本的本地事務(wù)(ObjectStore Transaction)，從而保證各副本的本地一致性，接著由issue_repop執(zhí)行副本間Transaction分發(fā)，同時將其加入waiting_for_applied和waiting_for_commit兩個隊列中；

步驟6：當(dāng)主副本OSD調(diào)用本地存儲引擎后端寫入日志盤后，主副本OSD回調(diào)執(zhí)行先前在OpContext中注冊的on_applied和on_committed回調(diào)函數(shù)，即向客戶端返回寫完成；

步驟7：各從副本OSD收到主副本OSD發(fā)送的寫請求對應(yīng)的本地事務(wù)(ObjectStore transaction)后，調(diào)用本地存儲引擎后端分別執(zhí)行寫入日志盤和數(shù)據(jù)盤，對應(yīng)操作完成后向主副本OSD返回相應(yīng)完成應(yīng)答；

步驟8：主副本OSD收到從副本OSD返回的寫入日志盤完成應(yīng)答(applied)或?qū)懭霐?shù)據(jù)盤完成應(yīng)答(committed)后，通過eval_repop，在waiting_for_applied或waiting_for_commit隊列上刪除對應(yīng)事務(wù)，并不斷檢查waiting_for_applied和waiting_for_commit是否為空，重點檢查waiting_for_commit隊列，如果發(fā)生waiting_for_ commit為空，而waiting_for_applied不為空的情況，那么就直接清空waiting_for_applied中未完成的OSD，并執(zhí)行其余回調(diào)函數(shù)，最終清理和釋放OpContext。

通過上述優(yōu)化后的寫入機制，數(shù)據(jù)成功寫入主副本OSD的日志盤(journal)后，就向客戶端返回寫完成，消除了公式1中TOSD1的twd+tcs、TOSD2和TOSD3的寫入延遲，從而降低非必要寫操作對集群寫性能的影響。

2.3 優(yōu)化后數(shù)據(jù)可用性分析

優(yōu)化后的Ceph數(shù)據(jù)可用性主要體現(xiàn)在以下3個方面：節(jié)點控制器故障時數(shù)據(jù)可用性保證、存儲陣列或磁盤故障時數(shù)據(jù)可用性保證、節(jié)點電源或網(wǎng)卡故障時數(shù)據(jù)可用性保證。下面分別進行闡述：

1)節(jié)點控制器故障時數(shù)據(jù)可用性保證：對于OSD在執(zhí)行數(shù)據(jù)寫入過程中，若控制器發(fā)生故障，可通過節(jié)點雙控雙存儲陣列模式，有效確保數(shù)據(jù)的安全性和高可靠性。具體情況分析及相應(yīng)處理機制如下：

①如果當(dāng)主副本OSD寫入日志盤前，發(fā)生主副本OSD控制器故障，則會由同節(jié)點雙控中另一個伙伴控制器重新拉起該OSD進程，并接管故障控制器存儲陣列后通知Monitor，客戶端通過Monitor獲取最新的OSDMap后，會重新發(fā)起本次寫請求，并重復(fù)上述優(yōu)化后寫入機制的所有步驟。

②如果當(dāng)從副本OSD寫入日志盤前，發(fā)生從副本OSD控制器故障，則會由同節(jié)點雙控中另一個伙伴控制器重新拉起該OSD進程，并接管故障控制器存儲陣列后通知Monitor，主副本OSD通過Monitor獲取最新的OSDMap后，重新發(fā)送對應(yīng)副本的本地事務(wù)(ObjectStore Transaction)，從副本OSD收到后，重新調(diào)用后端存儲引擎執(zhí)行寫入操作。

③如果當(dāng)主副本OSD寫入日志盤后，并且在寫入數(shù)據(jù)盤完成前，主副本OSD控制器發(fā)生故障，則會由同節(jié)點雙控中另一個伙伴控制器重新拉起該OSD進程，并接管故障控制器存儲陣列后，將日志盤中數(shù)據(jù)重新寫入數(shù)據(jù)盤，由于重新接管后造成其余從副本OSD上寫操作完成狀態(tài)丟失，因此還需要對操作對象進行一致性檢查。當(dāng)發(fā)現(xiàn)從副本OSD中相應(yīng)數(shù)據(jù)與主副本OSD不一致時，則將主副本OSD中的數(shù)據(jù)作為權(quán)威副本，恢復(fù)從副本OSD中未成功寫入的數(shù)據(jù)，從而保證各副本數(shù)據(jù)最終一致性。

④如果當(dāng)從副本OSD寫入日志盤后，并且在寫入數(shù)據(jù)盤完成前，從副本OSD控制器發(fā)生故障，則會由同節(jié)點雙控中另一個伙伴控制器重新拉起該OSD進程，并接管故障控制器存儲陣列后，將其日志盤中數(shù)據(jù)重新寫入數(shù)據(jù)盤，最后還需要向主副本OSD發(fā)送該事務(wù)的寫入數(shù)據(jù)盤完成應(yīng)答(committed)。

通過上述4種情景分析，雙控節(jié)點在其中一個控制器故障的情況下，進行控制器切換確保了集群內(nèi)部不需要通過數(shù)據(jù)遷移實現(xiàn)多副本的存儲需求，降低了節(jié)點間數(shù)據(jù)傳輸流量和副本磁盤讀寫流量，從而確保數(shù)據(jù)服務(wù)的不間斷和集群狀態(tài)的快速恢復(fù)。

2)存儲陣列或磁盤故障時數(shù)據(jù)可用性保證：對存儲陣列故障進行分類，具體情景分析及相應(yīng)處理機制如下：

①如果只是存儲陣列或磁盤由于某種原因?qū)е碌谋敬螌懭胧?，存儲陣列或磁盤本身并未損壞的情況下，如果是數(shù)據(jù)盤寫入失敗，則由日志盤(journal)中的對應(yīng)數(shù)據(jù)進行恢復(fù)；如果是日志盤寫入失敗，則由日志log恢復(fù)針對該數(shù)據(jù)對象的操作步驟，從而實現(xiàn)對日志盤的重新寫入。

②如果是由于存儲陣列或磁盤損壞，導(dǎo)致的數(shù)據(jù)寫入失敗，那么此時該節(jié)點將通過心跳信號通知Monitor節(jié)點對應(yīng)存儲陣列或磁盤失聯(lián)，Monitor節(jié)點間將通過Paxos算法實現(xiàn)對該OSD節(jié)點狀態(tài)一致性確認。若最終判定該OSD節(jié)點失聯(lián)時，Monitor會重新選擇OSD用于放置故障存儲陣列或磁盤數(shù)據(jù)，數(shù)據(jù)恢復(fù)過程如下：若主副本OSD的數(shù)據(jù)盤損壞，則從日志盤進行數(shù)據(jù)恢復(fù)；若主副本OSD的日志盤損壞，則先檢測數(shù)據(jù)盤有沒有寫入成功，若數(shù)據(jù)盤沒有寫入成功，則先從日志log恢復(fù)針對該數(shù)據(jù)對象的操作步驟，從而實現(xiàn)對數(shù)據(jù)盤的重新寫入；若從副本OSD上的存儲陣列或磁盤出現(xiàn)損壞，則處理為：當(dāng)Monitor重新分配了新的OSD用于恢復(fù)故障存儲陣列或磁盤數(shù)據(jù)后，首先更新集群Map，當(dāng)主副本OSD收到最新的集群Map后，將重新發(fā)起未完成的從副本寫入操作，直到新的從副本OSD返回寫入完成應(yīng)答。

3)節(jié)點電源或網(wǎng)卡故障時數(shù)據(jù)可用性保證：該故障在實際項目部署中一方面對服務(wù)器雙電源連接不同容災(zāi)域的供電端口，和對服務(wù)器雙網(wǎng)卡連接不同網(wǎng)絡(luò)進行規(guī)避；另一方面當(dāng)某一節(jié)點出現(xiàn)電源或網(wǎng)卡故障時，即該節(jié)點與外界失聯(lián)，與故障節(jié)點建立了心跳連接的節(jié)點會通過未周期性收到心跳包而最先感知，之后該節(jié)點會將失聯(lián)節(jié)點通知Monitor。若最終Monitor判定該節(jié)點失聯(lián)則會將其下線，之后重新分配新的OSD，并更新集群map，在執(zhí)行數(shù)據(jù)恢復(fù)過程中會出現(xiàn)以下兩種情況：

①若正在執(zhí)行寫入操作數(shù)據(jù)對象的從副本OSD出現(xiàn)節(jié)點電源或網(wǎng)卡故障：當(dāng)主副本OSD收到更新后的集群map后，將會由主副本OSD發(fā)起針對新的從副本OSD數(shù)據(jù)Backfill機制，直到從副本OSD上數(shù)據(jù)符合系統(tǒng)要求的副本數(shù)；

②若正在執(zhí)行寫入操作數(shù)據(jù)對象的主副本OSD出現(xiàn)節(jié)點電源或網(wǎng)卡故障：當(dāng)從副本OSD收到更新后的集群map后，由于從副本OSD無法確定出現(xiàn)故障的主副本OSD上是否有未完成的三副本數(shù)據(jù)對象的寫操作，因此從副本OSD首先與另一個從副本OSD就該PG上的數(shù)據(jù)達成一致，即確定該PG上數(shù)據(jù)對象的權(quán)威副本，然后根據(jù)權(quán)威副本恢復(fù)新的主副本OSD上的數(shù)據(jù)，直到主副本OSD上的數(shù)據(jù)符合系統(tǒng)要求的副本數(shù)。

3 實驗結(jié)果與分析

該部分通過VMware創(chuàng)建虛擬機，搭建Ceph集群的方式，對基于雙控節(jié)點的Ceph寫性能優(yōu)化方法進行實驗，測試分為驗證優(yōu)化后方法的數(shù)據(jù)高可用和評估優(yōu)化后方法的寫性能提升效果。

3.1 實驗環(huán)境

實驗使用8臺虛擬機(node0～node7)搭建Ceph分布式存儲集群，每臺虛擬機都運行OSD進程作為OSD節(jié)點使用，同時前3臺虛擬機還分別運行Monitor和Manager進程，作為MON節(jié)點和MGR節(jié)點使用[18]，還需任選一臺虛擬機作為客戶端節(jié)點。將集群數(shù)據(jù)副本數(shù)設(shè)定為3，所有虛擬機的系統(tǒng)環(huán)境均為CentOS-7系統(tǒng)。測試環(huán)境的集群拓撲如圖4所示，測試軟件為Fio，其中IO引擎為libaio。

圖4 實驗集群拓撲圖

3.2 數(shù)據(jù)可用性測試

在虛擬機搭建的Ceph集群中，通過修改CEUSH map的方式(包括修改Cluster map和Placement rule)，將node0與node1、node2與node3、node4與node5、node6與node7分別綁定為伙伴控制器，從而模擬實際中的雙控制器雙存儲陣列節(jié)點。數(shù)據(jù)可用性測試主要驗證控制器、硬盤、電源和網(wǎng)卡出現(xiàn)故障時，整個集群的數(shù)據(jù)讀寫是否正常，即客戶端此時進行任何數(shù)據(jù)讀寫是否不受故障影響，測試結(jié)果如表2所示。

表2 數(shù)據(jù)可用性測試

3.3 寫性能測試

優(yōu)化后方法的寫性能測試主要從寫延遲、吞吐量和IOPS等3個方面，對本文提出的基于雙控節(jié)點的Ceph寫性能優(yōu)化方法和Ceph原生多副本強一致性寫入機制進行測試比較，并在數(shù)據(jù)大小分別為4 K、8 K、16 K、64 K、128 K、1 M、2 M和4 M情況下對測試結(jié)果進行統(tǒng)計和分析。

如圖5(a)、5(b)所示的是寫延遲測試結(jié)果圖，本組Fio測試的direct參數(shù)設(shè)置為1，iodepth參數(shù)設(shè)置為1?？梢钥闯觯ㄟ^本文提出的基于雙控節(jié)點的Ceph寫性能優(yōu)化方法，在不同數(shù)據(jù)大小的情況下，無論順序?qū)戇€是隨機寫，寫延遲與Ceph原生機制相比普遍降低了一半左右，并且隨著寫入數(shù)據(jù)塊的增大，對1 M以上大數(shù)據(jù)塊寫延遲降低越明顯，因為在Ceph原生的多副本強一致性寫入機制中，主副本OSD需要通過網(wǎng)絡(luò)為每個從副本傳輸事務(wù)，當(dāng)操作對象越大時，網(wǎng)絡(luò)傳輸造成的延遲也越大，因此本文提出優(yōu)化方法運行在經(jīng)常進行大文件讀寫的存儲系統(tǒng)中，集群的寫延遲表現(xiàn)會更加出色。

圖5 不同數(shù)據(jù)大小情況下寫延遲的比較

如圖6(a)、6(b)所示的是吞吐量測試結(jié)果圖，本組Fio測試的direct參數(shù)設(shè)置為1，iodepth參數(shù)設(shè)置為64?？梢钥闯觯ㄟ^本文提出的基于雙控節(jié)點的Ceph寫性能優(yōu)化方法，在操作16 K以下的小數(shù)據(jù)塊時，順序?qū)懞碗S機寫都有1.5倍性能提升，在數(shù)據(jù)塊大小為64 K和128 K時，隨機寫的吞吐量性能提升了2倍以上，但在順序?qū)憰r，對1 M以上的大數(shù)據(jù)塊操作效果沒有小數(shù)據(jù)塊明顯，主要因為無論是本文提出的優(yōu)化方案還是Ceph原生寫入機制，最終結(jié)果各副本數(shù)據(jù)都需要寫入數(shù)據(jù)盤中，在本文提出的優(yōu)化方案中，如果某一副本本次寫操作還未最終寫入數(shù)據(jù)盤，下一個針對同一對象的寫請求就已經(jīng)到達，那么此時只有將最新的寫請求插入等待隊列中，等待上一次針對同一對象的寫請求最終寫入數(shù)據(jù)盤后，才能從隊列中取出繼續(xù)執(zhí)行，而這種情況的發(fā)生概率在頻繁順序?qū)懭胼^大數(shù)據(jù)塊時會增大，因此本文優(yōu)化方案吞吐量的表現(xiàn)與系統(tǒng)對數(shù)據(jù)的操作特性有較大關(guān)系，如果系統(tǒng)需要頻繁順序操作大數(shù)據(jù)塊，使用本文提出的優(yōu)化方法，在吞吐量上的提升沒有頻繁操作小數(shù)據(jù)塊效果明顯。

圖6 不同數(shù)據(jù)大小情況下吞吐量的比較

如圖7(a)、7(b)所示的是IOPS測試結(jié)果圖，本組Fio測試的direct參數(shù)設(shè)置為1，iodepth參數(shù)設(shè)置為128?？梢钥闯?，通過本文提出的基于雙控節(jié)點的Ceph寫性能優(yōu)化方法，在操作16 K以下小數(shù)據(jù)塊時，順序?qū)懶阅芴嵘?.5倍左右，操作128 K以上的大數(shù)據(jù)塊性能提升2倍左右。在隨機寫中IOPS性能提升效果更加明顯，其中操作64 K以上的大數(shù)據(jù)塊性能提升3倍左右，因為在本文提出的優(yōu)化方案中，對于IO操作的完成不需要等待所有副本都完成才向客戶端返回，當(dāng)主副本OSD寫入本地日志盤后，即可向客戶端返回寫完成，之后主副本OSD本地寫入數(shù)據(jù)盤完成情況、其余從副本OSD寫入日志盤完成應(yīng)答(applied)和從副本OSD寫入數(shù)據(jù)盤完成應(yīng)答(committed)則由主副本OSD在后臺繼續(xù)收集并完成后續(xù)各類回調(diào)操作，從而消除了公式(1)中TOSD1的twd+tcs、TOSD2和TOSD3寫入延遲，避免非必要寫對集群IOPS的影響，從而提高單位時間內(nèi)寫操作的完成次數(shù)。

圖7 不同數(shù)據(jù)大小情況下IOPS的比較

4 結(jié)語

本文針對分布式系統(tǒng)Ceph的多副本強一致性寫入機制造成的寫性能不理想問題，提出一種基于雙控節(jié)點的Ceph寫性能優(yōu)化方法，提高寫性能的同時，保證數(shù)據(jù)的安全性和高可靠性。通過對實驗測試結(jié)果的進一步分析，保證了數(shù)據(jù)的高可用，并驗證本文提出的優(yōu)化方法對寫性能提升的效果。雖然該優(yōu)化方法對集群中的節(jié)點提出了一定的要求，要求具備雙控雙存儲陣列能力，但卻帶來了對數(shù)據(jù)安全性和高可靠性的嚴(yán)格保證，對Ceph的商業(yè)化應(yīng)用，特別是在國產(chǎn)平臺上搭建Ceph具有一定的參考意義。