元核云如何解決Ceph分布式存儲中碰到的坑

最近有很多朋友拿著一篇關(guān)于“ceph運(yùn)維那些坑”的文章來找我，起初我并沒有在意，畢竟對于一個“新物種”來說，存在質(zhì)疑是再正常不過的。不過，陸續(xù)有更多的合作伙伴甚至圈內(nèi)同行來問我如何看待這篇文章時(shí)，我覺得做為一名Ceph開發(fā)和運(yùn)維的技術(shù)者，理應(yīng)站出來為Ceph說點(diǎn)什么。

首先，原作者分析Ceph運(yùn)維中遇到的問題是真實(shí)存在的，甚至在實(shí)際的運(yùn)維過程中還出現(xiàn)過其他更復(fù)雜的問題。因?yàn)樽畛醯腃eph只是社區(qū)提供的一套開源版，因而想要實(shí)現(xiàn)產(chǎn)品化需要趟過很多次“坑”，就像最早的安卓系統(tǒng)一樣。我想任何產(chǎn)品在一開始都難以做到十全十美，因?yàn)榧夹g(shù)本身就是在發(fā)現(xiàn)問題與解決問題的道路上不斷前進(jìn)發(fā)展的。不過，在這里我想澄清的事實(shí)是：連初涉Ceph的運(yùn)維人員都能發(fā)現(xiàn)的問題，研究Ceph多年的資深技術(shù)人員們肯定也早已發(fā)現(xiàn)。

接下來我就根據(jù)那篇文章中提到的坑，來說一說在實(shí)際產(chǎn)品化過程中我們是如何解決它們的。

一、擴(kuò)容問題

Ceph本身基于Crush算法，具備了多種數(shù)據(jù)復(fù)制策略，可以選擇在磁盤、主機(jī)、機(jī)柜等等位置附著。例如：如果采取3副本的數(shù)據(jù)保護(hù)策略，就可以通過復(fù)制策略來決定這3個副本是否同時(shí)分布在不同的磁盤、不同的主機(jī)、不同的隔離域、不同的機(jī)柜等位置來保證部分硬件故障后數(shù)據(jù)安全性和服務(wù)運(yùn)行不中斷。

Ceph底層是用資源池(POOL)來實(shí)現(xiàn)數(shù)據(jù)邏輯隔離，往往我們會出現(xiàn)因容量或性能不足需要對資源池進(jìn)行擴(kuò)容的問題，但是在容量擴(kuò)容過程中，勢必會帶來進(jìn)行數(shù)據(jù)重新平衡的要求。Ceph中數(shù)據(jù)以PG為單位進(jìn)行組織，因此當(dāng)數(shù)據(jù)池中加入新的存儲單元(OSD)時(shí)，通過調(diào)整OSDMAP會帶來數(shù)據(jù)重平衡。正如文章所提到的，如果涉及到多個OSD的擴(kuò)容是可能導(dǎo)致可用PG中OSD小于min_size，從而發(fā)生PG不可用、IO阻塞的情況。為了盡量避免這種情況的出現(xiàn)，只能將擴(kuò)容粒度變小，比如每次只擴(kuò)容一個OSD或者一個機(jī)器、一個機(jī)柜(主要取決于存儲隔離策略)，但是這樣注定會帶來極大的運(yùn)維工作量，甚至連擴(kuò)容速度可能都趕不上數(shù)據(jù)增長速度。

正是針對這個問題，元核云分布式存儲產(chǎn)品在運(yùn)維管理平臺層面進(jìn)行了優(yōu)化。擴(kuò)容發(fā)生時(shí)，運(yùn)維人員只需要將待擴(kuò)容的服務(wù)器信息以及策略加入到運(yùn)維管理平臺中，后面的事情都由運(yùn)維管理平臺進(jìn)行自動化處理。簡單來說，運(yùn)維平臺會根據(jù)PG的狀態(tài)和待擴(kuò)容OSD資源，尋求一個最優(yōu)的擴(kuò)容方式，即在不影響PG可用性的情況下，循序漸進(jìn)地進(jìn)行OSD擴(kuò)容，直到擴(kuò)容動作完全完成為止。例如：在三副本的場景下，當(dāng)某一個PG加入兩個OSD后，運(yùn)維平臺會通過算法把擴(kuò)容分為兩次完成，每次僅擴(kuò)容一個OSD，這樣就能保證PG的min_size始終大于1。而這整個過程完全由運(yùn)維平臺自動完成，對運(yùn)維管理員完全透明。

二、數(shù)據(jù)遷移過程中的IO爭用問題

文章中提到的第二個問題主要是講在頻繁數(shù)據(jù)遷移過程中帶來的IO爭用問題。當(dāng)集群規(guī)模變大后，硬盤損壞、PG數(shù)量擴(kuò)充可能會變得常態(tài)化。

以我們的運(yùn)維經(jīng)驗(yàn)來看，客戶大概每年都會有幾次的相關(guān)運(yùn)維操作。在我們運(yùn)維過的所有集群中，最大的超過了1000個存儲節(jié)點(diǎn)，而在這過程中會遭遇到每個月?lián)p壞1-2臺硬盤、3個月左右進(jìn)行一次集中換盤的情況。這些運(yùn)維操作都需要通過數(shù)據(jù)遷移來進(jìn)行數(shù)據(jù)恢復(fù)，數(shù)據(jù)恢復(fù)過程中會對硬盤的IO進(jìn)行爭用，如何有效、智能地控制并恢復(fù)IO，并做到使業(yè)務(wù)IO不受影響，是Ceph運(yùn)維管理的核心工作。

在元核云自動化運(yùn)維管理平臺中，會采用時(shí)間策略、流量策略來控制數(shù)據(jù)恢復(fù)的速率。我們會在業(yè)務(wù)的高峰期，8：00——18：00這一時(shí)間段內(nèi)使用某種流量恢復(fù)策略，在業(yè)務(wù)的低峰期，18：00——第二天8：00這一時(shí)間段使用另一種流量恢復(fù)策略。在流量恢復(fù)策略中，可以基于磁盤的IO利用率情況，來動態(tài)調(diào)整數(shù)據(jù)流量恢復(fù)速率，比如說設(shè)置恢復(fù)流量占用IO利用率閾值不能超過50%，則總會保證不因恢復(fù)流量導(dǎo)致IO的利用率超過50%，當(dāng)業(yè)務(wù)IO占比越大，恢復(fù)IO占比就越小，當(dāng)業(yè)務(wù)IO利用率超過50%時(shí)，則停止恢復(fù)IO。此種方式可以靈活有效地利用閑時(shí)IO，在不影響業(yè)務(wù)IO的情況下，快速完成數(shù)據(jù)遷移恢復(fù)。

三、PG數(shù)量調(diào)整問題

當(dāng)解決了數(shù)據(jù)遷移過程中的PG可用性問題和IO爭用問題后，關(guān)于文章中提到的PG數(shù)量調(diào)整問題自然也就解決了。數(shù)據(jù)遷移本身是一個常態(tài)化的過程，當(dāng)控制了數(shù)據(jù)在遷移過程中的不良影響，同時(shí)在OSDMap變化過程中，PG始終能夠保持可用狀態(tài)，那么就并不會像那篇文章中所說的那樣，調(diào)整PG數(shù)量會帶來災(zāi)難性的后果。況且，PG的調(diào)整確實(shí)也不是一個經(jīng)常性的動作。

四、集群利用率問題

文章中提到的存儲成本問題主要是講集群可用率問題，即Ceph集群規(guī)模增大后，偽隨機(jī)算法導(dǎo)致了存儲資源分布不均衡，磁盤利用率方差過大的問題。

其實(shí)要做到保證每塊盤的數(shù)據(jù)均衡，這是一個比較復(fù)雜的過程。因?yàn)槭紫纫_保數(shù)據(jù)分布能夠遵循每個Pool的Rule-Set規(guī)則，同時(shí)又要保證每個Pool對應(yīng)的PG較為合理的分布在每個OSD中(因?yàn)橛行㏄ool是放元數(shù)據(jù)的，并不會承載大量的數(shù)據(jù))，同時(shí)還要保證當(dāng)PG數(shù)量發(fā)生變化時(shí)不會發(fā)生災(zāi)難性的數(shù)據(jù)遷移(stable_mod)。元核云在Ceph基礎(chǔ)上開發(fā)了智能數(shù)據(jù)分布管理特性，它能通過預(yù)先設(shè)定好的計(jì)算模型，反復(fù)迭代計(jì)算，預(yù)測出一個最優(yōu)的數(shù)據(jù)分布，在現(xiàn)實(shí)運(yùn)維經(jīng)驗(yàn)中，我們可以保證OSD之間的數(shù)據(jù)容量之差不超過2%，存儲集群空間可用率達(dá)到95%以上。此特性功能會對因集群初始化、擴(kuò)容、硬件故障等原因?qū)е碌臄?shù)據(jù)遷移后的數(shù)據(jù)失衡進(jìn)行管控，實(shí)現(xiàn)較優(yōu)的空間使用率。

五、運(yùn)維復(fù)雜度問題

正如文章所提到的，Ceph本身是一個十分復(fù)雜的體系，要做到穩(wěn)定運(yùn)維非?？粗貓F(tuán)隊(duì)的實(shí)力。元核云除了對Ceph核心進(jìn)行了深度優(yōu)化，還提供了一套支持跨數(shù)據(jù)中心多Ceph集群的自動化運(yùn)維管理平臺，能極大提高運(yùn)維效率、降低Ceph存儲集群運(yùn)維成本。目前我們通過這套運(yùn)維平臺，做到了五個數(shù)據(jù)中心上千個節(jié)點(diǎn)的存儲集群，每年僅需一個運(yùn)維人力的案例。

總而言之，對于那篇文章中提到的“坑”，其實(shí)我們早已做好了充分的預(yù)防策略。紙上談兵都是容易的，實(shí)際操作卻比之復(fù)雜千萬倍。怎樣才能跳出人云亦云的圈子，真正認(rèn)識到事實(shí)的本來面目，還是需要有長久的實(shí)踐操作經(jīng)驗(yàn)才能夠看清楚。元核云主導(dǎo)負(fù)責(zé)的某大型金融集團(tuán)近50PB+的分布式存儲方案，屬于國內(nèi)金融行業(yè)最大的Ceph存儲案例，達(dá)到了4年的軟件存儲產(chǎn)品本身零故障記錄，期間也經(jīng)歷了各種網(wǎng)絡(luò)異常、服務(wù)器和硬盤故障、服務(wù)器擴(kuò)容、操作系統(tǒng)打補(bǔ)丁和升級、存儲軟件打補(bǔ)丁和升級等運(yùn)維問題，仍然完好地維護(hù)了存儲數(shù)據(jù)。軟件定義存儲軟件系統(tǒng)屬于工程型項(xiàng)目，需要大規(guī)模的生產(chǎn)實(shí)踐經(jīng)驗(yàn)和時(shí)間積累，遇“坑”填“坑”，才能保證其產(chǎn)品的成熟度。存儲畢竟是底層核心的關(guān)鍵技術(shù)產(chǎn)品，數(shù)據(jù)的最后一道防線，如果要正式進(jìn)行生產(chǎn)應(yīng)用，還是建議大家使用成熟的商業(yè)化Ceph存儲產(chǎn)品。

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。