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

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

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

Ceph底層是用資源池（POOL）來實現數據邏輯隔離，往往我們會出現因容量或性能不足需要對資源池進行擴容的問題，但是在容量擴容過程中，勢必會帶來進行數據重新平衡的要求。Ceph中數據以PG為單位進行組織，因此當數據池中加入新的存儲單元（OSD）時，通過調整OSDMAP會帶來數據重平衡。

正是針對這個問題，元核云分布式存儲產品在運維管理平臺層面進行了優化。擴容發生時，運維人員只需要將待擴容的服務器信息以及策略加入到運維管理平臺中，后面的事情都由運維管理平臺進行自動化處理。簡單來說，運維平臺會根據PG的狀態和待擴容OSD資源，尋求一個最優的擴容方式，即在不影響PG可用性的情況下，循序漸進地進行OSD擴容，直到擴容動作完全完成為止。

文章中提到的第二個問題主要是講在頻繁數據遷移過程中帶來的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可用性問題和IO爭用問題后，關于文章中提到的PG數量調整問題自然也就解決了。數據遷移本身是一個常態化的過程，當控制了數據在遷移過程中的不良影響，同時在OSDMap變化過程中，PG始終能夠保持可用狀態，那么就并不會像那篇文章中所說的那樣，調整PG數量會帶來災難性的后果。況且，PG的調整確實也不是一個經常性的動作。

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

其實要做到保證每塊盤的數據均衡，這是一個比較復雜的過程。因為首先要確保數據分布能夠遵循每個Pool的Rule-Set規則，同時又要保證每個Pool對應的PG較為合理的分布在每個OSD中（因為有些Pool是放元數據的，并不會承載大量的數據），同時還要保證當PG數量發生變化時不會發生災難性的數據遷移（stable_mod）。

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