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

最近有很多朋友拿著一篇關於“ceph運維那些坑”的文章來找我，起初我並沒有在意，畢竟對於一個“新物種”來說，存在質疑是再正常不過的。不過，陸續有更多的合作伙伴甚至圈內同行來問我如何看待這篇文章時，我覺得做為一名Ceph開發和運維的技術者，理應站出來為Ceph說點什麼。

首先，原作者分析Ceph運維中遇到的問題是真實存在的，甚至在實際的運維過程中還出現過其他更復雜的問題。因為最初的Ceph只是社群提供的一套開源版，因而想要實現產品化需要趟過很多次“坑”，就像最早的安卓系統一樣。我想任何產品在一開始都難以做到十全十美，因為技術本身就是在發現問題與解決問題的道路上不斷前進發展的。不過，在這裡我想澄清的事實是：連初涉Ceph的運維人員都能發現的問題，研究Ceph多年的資深技術人員們肯定也早已發現。

接下來我就根據那篇文章中提到的坑，來說一說在實際產品化過程中我們是如何解決它們的。

一、擴容問題

Ceph本身基於Crush演算法，具備了多種資料複製策略，可以選擇在磁碟、主機、機櫃等等位置附著。例如：如果採取3副本的資料保護策略，就可以通過複製策略來決定這3個副本是否同時分佈在不同的磁碟、不同的主機、不同的隔離域、不同的機櫃等位置來保證部分硬體故障後資料安全性和服務執行不中斷。

Ceph底層是用資源池（POOL）來實現資料邏輯隔離，往往我們會出現因容量或效能不足需要對資源池進行擴容的問題，但是在容量擴容過程中，勢必會帶來進行資料重新平衡的要求。Ceph中資料以PG為單位進行組織，因此當資料池中加入新的儲存單元（OSD）時，通過調整OSDMAP會帶來資料重平衡。正如文章所提到的，如果涉及到多個OSD的擴容是可能導致可用PG中OSD小於min_size，從而發生PG不可用、IO阻塞的情況。為了儘量避免這種情況的出現，只能將擴容粒度變小，比如每次只擴容一個OSD或者一個機器、一個機櫃（主要取決於儲存隔離策略），但是這樣註定會帶來極大的運維工作量，甚至連擴容速度可能都趕不上資料增長速度。

正是針對這個問題，元核雲分散式儲存產品在運維管理平臺層面進行了優化。擴容發生時，運維人員只需要將待擴容的伺服器資訊以及策略加入到運維管理平臺中，後面的事情都由運維管理平臺進行自動化處理。簡單來說，運維平臺會根據PG的狀態和待擴容OSD資源，尋求一個最優的擴容方式，即在不影響PG可用性的情況下，循序漸進地進行OSD擴容，直到擴容動作完全完成為止。例如：在三副本的場景下，當某一個PG加入兩個OSD後，運維平臺會通過演算法把擴容分為兩次完成，每次僅擴容一個OSD，這樣就能保證PG的min_size始終大於1。而這整個過程完全由運維平臺自動完成，對運維管理員完全透明。

二、資料遷移過程中的IO爭用問題

文章中提到的第二個問題主要是講在頻繁資料遷移過程中帶來的IO爭用問題。當叢集規模變大後，硬碟損壞、PG數量擴充可能會變得常態化。

以我們的運維經驗來看，客戶大概每年都會有幾次的相關運維操作。在我們運維過的所有叢集中，最大的超過了1000個儲存節點，而在這過程中會遭遇到每個月損壞1-2臺硬碟、3個月左右進行一次集中換盤的情況。這些運維操作都需要通過資料遷移來進行資料恢復，資料恢復過程中會對硬碟的IO進行爭用，如何有效、智慧地控制並恢復IO，並做到使業務IO不受影響，是Ceph運維管理的核心工作。

在元核雲自動化運維管理平臺中，會採用時間策略、流量策略來控制資料恢復的速率。我們會在業務的高峰期，8：00——18：00這一時間段內使用某種流量恢復策略，在業務的低峰期，18：00——第二天8：00這一時間段使用另一種流量恢復策略。在流量恢復策略中，可以基於磁碟的IO利用率情況，來動態調整資料流量恢復速率，比如說設定恢復流量佔用IO利用率閾值不能超過50%，則總會保證不因恢復流量導致IO的利用率超過50%，當業務IO佔比越大，恢復IO佔比就越小，當業務IO利用率超過50%時，則停止恢復IO。此種方式可以靈活有效地利用閒時IO，在不影響業務IO的情況下，快速完成資料遷移恢復。

三、PG數量調整問題

當解決了資料遷移過程中的PG可用性問題和IO爭用問題後，關於文章中提到的PG數量調整問題自然也就解決了。資料遷移本身是一個常態化的過程，當控制了資料在遷移過程中的不良影響，同時在OSDMap變化過程中，PG始終能夠保持可用狀態，那麼就並不會像那篇文章中所說的那樣，調整PG數量會帶來災難性的後果。況且，PG的調整確實也不是一個經常性的動作。

四、叢集利用率問題

文章中提到的儲存成本問題主要是講叢集可用率問題，即Ceph叢集規模增大後，偽隨機演算法導致了儲存資源分佈不均衡，磁碟利用率方差過大的問題。

其實要做到保證每塊盤的資料均衡，這是一個比較複雜的過程。因為首先要確保資料分佈能夠遵循每個Pool的Rule-Set規則，同時又要保證每個Pool對應的PG較為合理的分佈在每個OSD中（因為有些Pool是放元資料的，並不會承載大量的資料），同時還要保證當PG數量發生變化時不會發生災難性的資料遷移（stable_mod）。元核雲在Ceph基礎上開發了智慧資料分佈管理特性，它能通過預先設定好的計算模型，反覆迭代計算，預測出一個最優的資料分佈，在現實運維經驗中，我們可以保證OSD之間的資料容量之差不超過2%，儲存叢集空間可用率達到95%以上。此特性功能會對因叢集初始化、擴容、硬體故障等原因導致的資料遷移後的資料失衡進行管控，實現較優的空間使用率。

五、運維複雜度問題

正如文章所提到的，Ceph本身是一個十分複雜的體系，要做到穩定運維非常看重團隊的實力。元核雲除了對Ceph核心進行了深度優化，還提供了一套支援跨資料中心多Ceph叢集的自動化運維管理平臺，能極大提高運維效率、降低Ceph儲存叢集運維成本。目前我們通過這套運維平臺，做到了五個資料中心上千個節點的儲存叢集，每年僅需一個運維人力的案例。

總而言之，對於那篇文章中提到的“坑”，其實我們早已做好了充分的預防策略。紙上談兵都是容易的，實際操作卻比之複雜千萬倍。怎樣才能跳出人云亦云的圈子，真正認識到事實的本來面目，還是需要有長久的實踐操作經驗才能夠看清楚。元核雲主導負責的某大型金融集團近50PB+的分散式儲存方案，屬於國內金融行業最大的Ceph儲存案例，達到了4年的軟體儲存產品本身零故障記錄，期間也經歷了各種網路異常、伺服器和硬碟故障、伺服器擴容、作業系統打補丁和升級、儲存軟體打補丁和升級等運維問題，仍然完好地維護了儲存資料。軟體定義儲存軟體系統屬於工程型專案，需要大規模的生產實踐經驗和時間積累，遇“坑”填“坑”，才能保證其產品的成熟度。儲存畢竟是底層核心的關鍵技術產品，資料的最後一道防線，如果要正式進行生產應用，還是建議大家使用成熟的商業化Ceph儲存產品。

【本文版權歸儲存線上所有，未經許可不得轉載。文章僅代表作者看法，如有不同觀點，歡迎新增儲存線上微信公眾號（微訊號：doitmedia）進行交流。】