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

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

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

Ceph底層是用資源池（POOL）來(lái)實(shí)現(xiàn)數(shù)據(jù)邏輯隔離，往往我們會(huì)出現(xiàn)因容量或性能不足需要對(duì)資源池進(jìn)行擴(kuò)容的問(wèn)題，但是在容量擴(kuò)容過(guò)程中，勢(shì)必會(huì)帶來(lái)進(jìn)行數(shù)據(jù)重新平衡的要求。Ceph中數(shù)據(jù)以PG為單位進(jìn)行組織，因此當(dāng)數(shù)據(jù)池中加入新的存儲(chǔ)單元（OSD）時(shí)，通過(guò)調(diào)整OSDMAP會(huì)帶來(lái)數(shù)據(jù)重平衡。

正是針對(duì)這個(gè)問(wèn)題，元核云分布式存儲(chǔ)產(chǎn)品在運(yùn)維管理平臺(tái)層面進(jìn)行了優(yōu)化。擴(kuò)容發(fā)生時(shí)，運(yùn)維人員只需要將待擴(kuò)容的服務(wù)器信息以及策略加入到運(yùn)維管理平臺(tái)中，后面的事情都由運(yùn)維管理平臺(tái)進(jìn)行自動(dòng)化處理。簡(jiǎn)單來(lái)說(shuō)，運(yùn)維平臺(tái)會(huì)根據(jù)PG的狀態(tài)和待擴(kuò)容OSD資源，尋求一個(gè)最優(yōu)的擴(kuò)容方式，即在不影響PG可用性的情況下，循序漸進(jìn)地進(jìn)行OSD擴(kuò)容，直到擴(kuò)容動(dòng)作完全完成為止。

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

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

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

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

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

其實(shí)要做到保證每塊盤(pán)的數(shù)據(jù)均衡，這是一個(gè)比較復(fù)雜的過(guò)程。因?yàn)槭紫纫_保數(shù)據(jù)分布能夠遵循每個(gè)Pool的Rule-Set規(guī)則，同時(shí)又要保證每個(gè)Pool對(duì)應(yīng)的PG較為合理的分布在每個(gè)OSD中（因?yàn)橛行㏄ool是放元數(shù)據(jù)的，并不會(huì)承載大量的數(shù)據(jù)），同時(shí)還要保證當(dāng)PG數(shù)量發(fā)生變化時(shí)不會(huì)發(fā)生災(zāi)難性的數(shù)據(jù)遷移（stable_mod）。

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