塊儲存系統

分散式儲存有出色的效能，可以扛很多故障，能夠輕鬆擴充套件，所以我們使用Ceph構建了高效能、高可靠的塊儲存系統，並使用它支撐公有云和託管雲的雲主機、雲硬碟服務。

由於使用分散式塊儲存系統，避免了複製映象的過程，所以雲主機的建立時間可以縮短到10秒以內，而且雲主機還能快速熱遷移，方便了運維人員對物理伺服器上硬體和軟體的維護。

使用者對於塊儲存系統最直觀的感受來源於雲硬碟服務，現在我們的雲硬碟的特點是：

• 每個雲硬碟最大支援 6000 IOPS和170 MB/s的吞吐率，95%的4K隨機寫操作的延遲小於2ms 。
• 所有資料都是三副本，強一致性，永續性高達10個9。
• 建立、刪除、掛載、解除安裝都是秒級操作。
• 實時快照。
• 提供兩種雲硬碟型別，效能型和容量型。

軟硬體配置

經過多輪的選型和測試，並踩過無數的坑之後，我們選擇了合適我們的軟體和硬體。

軟體

硬體

• 從SATA磁碟到SSD，為了提高IOPS和降低Latency。
• 從消費級SSD到企業級SSD，為了提高可靠性。
• 從RAID卡到HBA卡，為了提高IOPS和降低Latency。

最小部署架構

隨著軟硬體的升級，需求的調整， 我們的部署架構也不斷在演進，力求在成本、效能、可靠性上達到最佳平衡點。

最小規模部署中有12個節點，每個節點上有3塊SSD。節點上有2個萬兆口和1個千兆口，虛擬機器網路和儲存網路使用萬兆口，管理網路使用千兆口。每個叢集中都有3個Ceph Monitor節點。

輕鬆擴充套件

雲端計算的好處是極強的擴充套件性，作為雲端計算的底層架構，也需要有快速的Scale-out能力。在塊儲存系統的部署架構中，可以以12臺節點為單位進行擴充套件。

改造OpenStack

原生的OpenStack並不支援統一儲存，雲主機服務Nova、映象服務Glance、雲硬碟服務Cinder的後端儲存各不相同，造成了嚴重的內耗。我們把這三大服務的後端統一起來，進行高效管理，解決了虛擬機器建立時間長和映象風暴等問題，還能讓虛擬機器隨便漂移。

原生的OpenStack

改造後的OpenStack

使用原生的OpenStack建立虛擬機器需要1~3分鐘，而使用改造後的OpenStack僅需要不到10秒鐘時間。這是因為nova-compute不再需要通過HTTP下載整個映象，虛擬機器可以通過直接讀取Ceph中的映象資料進行啟動。

我們還增加兩個OpenStack沒有的功能: QoS 和 共享雲硬碟。雲端計算的另外一個好處是租戶資源隔離，所以必備QoS。共享雲硬碟可以掛載給多臺雲主機，適用於資料處理的場景。

我們還使用了OpenStack的multi-backend功能，支援多種雲硬碟型別，現在我們的雲硬碟型別有效能型、容量型，可以滿足資料庫和大檔案應用。

高效能

儲存系統主要的效能指標是IOPS和Latency。我們對於IOPS的優化已經達到了硬體的瓶頸，除非更換更快的固態硬碟或者快閃記憶體卡，或者是改變整個架構。我們對於Latency的優化也快接近完成，可以達到企業級儲存的水平。

複雜的I/O棧

整個塊儲存系統有著長長的I/O棧，每個I/O請求要穿過很多執行緒和佇列。

優化作業系統

優化作業系統的引數可以充分利用硬體的效能。

• CPU
  • 關閉CPU節能模式
  • 使用Cgroup繫結Ceph OSD程序到固定的CPU Cores上
• Memory
  • 關閉NUMA
  • 設定vm.swappiness=0
• Block
  • 設定SSD的排程演算法為deadline
• FileSystem
  • 設定掛載引數”noatime nobarrier”

優化Qemu

Qemu作為塊儲存系統的直接消費者，也有很多值得優化的地方。

• Throttle: 平滑的I/O QoS演算法
• RBD: 支援discard和flush
• Burst: 支援突發請求
• Virt-scsi: 支援多佇列

優化Ceph

我們對於Ceph的優化是重頭戲，有很多問題也是時間長、規模上去之後才暴露出來的。

高可靠性

儲存需要高可靠性，保證資料可用並且資料不丟失。因為我們的架構中沒有使用UPS和NVRAM，所以寫請求的資料都是落到三塊硬碟之後才返回，這樣最大限度地保證了使用者的資料安全。

如何計算永續性

永續性是資料丟失的概率，可以用於度量一個儲存系統的可靠性，俗稱 “多少個9”。資料的放置(DataPlacement)決定了資料永續性，而Ceph的CRUSH MAP又決定了資料的放置，因此CRUSH MAP的設定決定了資料永續性。但是，即時我們知道需要修改CRUSH MAP的設定，但是我們應該怎麼修改CRUSH MAP的設定呢，我們該如何計算資料永續性呢？

我們需要一個計算模型和計算公式，通過以下資料，我們可以構建一個計算模型和計算公式。

最終的計算公式是：P = func(N, R, S, AFR)

• P: 丟失所有副本的概率
• N: 整個Ceph Pool中OSD的數量
• R: 副本數
• S: 在一個Bucket中OSD的個數
• AFR: 磁碟的年平均故障率

這個計算模型是怎麼樣得到計算公式的呢？下面是4個步驟。

1. 先計算硬碟發生故障的概率。
2. 定義哪種情況下丟失資料不能恢復。
3. 計算任意R個OSD發生故障的概率。
4. 計算Ceph丟失PG的概率。

硬碟發生故障的概率是符合泊松分佈的：

• fit = failures in time = 1/MTTF ~= 1/MTBF = AFR/(24*365)
• 事件概率 Pn(λ,t) = (λt)n e-λt / n!

Ceph的每個PG是有R份副本的，存放在R個OSD上，當存有這個PG的R個OSD都發生故障時，資料是不可訪問的，當這R個OSD都損壞時，資料是不可恢復的。

計算一年內任意R個OSD發生相關故障概率的方法是：

1. 計算一年內有OSD發生故障的概率。
2. 在Recovery時間內，(R-1)個OSD發生故障的概率。
3. 以上概率相乘，就是一年內任意R個OSD發生相關故障概率，假設是 Pr。
4. N個OSD中，任意R個OSD的組合數是C(R, N)。

因為這任意R個OSD不一定存有同一個PG的副本，所以這任意R個OSD發生故障並不會導致資料不可恢復，也就是不一定會導致資料丟失。

假設每個PG對應一組OSD(有R個OSD， 稱之為Copy Set)，有可能多個PG對應同一組OSD。假設有M個不同的Copy Set， M是一個非常重要的數字。

我們再來對Copy Set進行精確的定義：Copy Set上至少有一個PG的所有副本，當這個Copy Set損壞時，這個PG的所有副本也會丟失，這個PG上的所有資料就不可恢復。所以Ceph丟失資料的事件就是Ceph丟失PG， Ceph丟失PG就是有一個Copy Set發生損壞，一個Copy Set丟失的概率就是 P = Pr * M / C(R, N) 。

永續性公式就是個量化工具，它可以指明努力的方向。我們先小試牛刀，算一下預設情況下的永續性是多少？

假設我們有3個機架，每個機架上有8臺節點，每個幾點上有3塊硬碟，每個硬碟做一個OSD，則一共有72個OSD。

預設的crush map設定如下所示

通過永續性公式，我們得到下面的資料。

預設情況下，永續性有8個9，已經比一般的RAID5、RAID10要高，和RAID6差不多，但是還不能滿足公有云的要求，因為公有云的規模很大，故障事件的數學期望也會很大，這就逼著我們儘量提高永續性。

提高永續性的方法有很多，比如增加副本數，使用Erase Code等。不過這些方法都有弊端，增加副本數勢必會擴大成本；使用Erase Code會導致Latency提高，不適合於塊儲存服務。在成本和Latency的制約下，還有什麼辦法可以提高永續性呢？

前面我們已經得到一個量化公式 P = Pr * M / C(R, N)， 我們從量化公式入手，去提高永續性(也就是降低P)。要想降低P， 就得降低Pr、M，或者是提高C(R, N)。因為C(R, N)已經確定，我們只能降低Pr和M。

降低恢復時間

從Pr的定義可以知道Pr與恢復時間有關，恢復時間越短，Pr的值越低。那麼恢復時間跟什麼有關係呢？

我們需要增加更多的OSD用於資料恢復，以便減少恢復時間。目前host bucket不能增加更多的OSD，這是因為主機的網路頻寬限制和硬碟插槽限制。解決辦法是從CRUSH MAP入手，增加一種虛擬的Bucket: osd-domain， 不再使用host bucket。

通過使用osd-domain bucket，我們把永續性提高了10倍，現在永續性有9個9。

減少Coepy Set個數

如何減少Copy Set的個數呢？Copy Sets是和PG的對映有關的，我們從CRUSH MAP的規則和條件入手，減少Copy Set的個數。解決辦法增加虛擬的Bucket: replica-domain， 不再使用rack bucket。每個PG必須在一個replica-domain上，PG不能跨replica-domain，這樣可以顯著減少Copy Set的個數。

通過使用replica-domain，現在的永續性有10個9，永續性比預設的crush map設定提高了100倍。

自動化運維

Ceph的運維比較費心，稍有差池，整個雲平臺都會受到影響，因此我們覺得運維的目標是可用性：

減少不必要的資料遷移，進而減少slow requests，保證SLA。

部署

我們整個雲平臺都是使用Puppet部署的，因此我們使用了Puppet去部署Ceph。一般Ceph的安裝是分階段的：

1. 安裝好Ceph Monitor叢集。
2. 格式化Disk，使用檔案系統的UUID去註冊OSD， 得到OSD ID。
3. 根據OSD ID去建立資料目錄，掛載Disk到資料目錄上。
4. 初始化CRUSH MAP。

Puppet只需要完成前三步，第四步一般根據具體情況用指令碼去執行。因為OSD ID是在執行過程中得到的，而Puppet是編譯後執行，這是一個悲傷的故事，所以puppet-ceph模組必須設計成retry的。

相比eNovance和Stackforge的puppet-ceph模組，我們的puppet-ceph模組的優點是：

• 更短的部署時間
• 支援Ceph所有的引數
• 支援多種硬碟型別
• 使用WWN-ID替代碟符。

維護

升級Ceph的過程很簡單，三條命令就可以搞定：

1. ceph osd set noout #避免在異常情況下不可控
2. ceph osd down x #提前mark down， 減少slow request
3. service ceph restart osd.x

更換硬體或者升級核心時需要對機器進行重啟，步驟也很簡單:

1. 把這臺機器上的虛擬機器遷移到其他機器上
2. ceph osd set noout
3. ceph osd down x #把這個機器上的OSD都設定為down狀態
4. service ceph stop osd.x
5. 重啟機器

擴充套件叢集的時候需要非常小心，因為它會觸發資料遷移：

1. 設定crush map
2. 設定recovery options
3. 在凌晨12點觸發資料遷移
4. 觀察資料遷移的速度，觀察每個機器上網口的頻寬，避免跑滿
5. 觀察slow requests的數量

你總會碰到硬碟損壞的時候，替換硬碟時需要非常小心，你要小心的設定crush map，你要保證要替換硬碟過程中replica-domain的weight的值是不變的，這樣才能保證不必須要的資料遷移。

監控

Ceph自家的Calamari長得不錯，但是不夠實用，而且它的部署、打包還不完善，在CentOS上還有一些BUG，我們只能繼續使用原有的工具。

• 收集：使用diamond，增加新的colloctor，用於收集更詳細的資料。
• 儲存：使用graphite，設定好採集精度和儲存精度。
• 展示：使用grafana，挑了十幾個工具，發現還是grafana好看好用。
• 報警：zabbix agent && ceph health

我們根據Ceph軟體架構對每個OSD分成了很多個throttle層，下面是throttle模型：

有了throttle model，我們可以對每個throttle進行監控，我們在diamond上增加了新的collector用於對這些throttle進行監控，並重新定義了metric name。

最後，我們可以得到每個OSD每層throttle的監控資料。但平時只會關注IOPS、吞吐率、OSD Journal延遲、讀請求延遲、容量使用率等。

事故

在雲平臺上線已經快一年了，我們遇到的大小事故有：

• SSD GC問題，會導致讀寫請求的Latency非常大，飆到幾百毫秒。
• 網路故障，會導致Monitor把OSD設定為down狀態。
• Ceph Bug， 會導致OSD程序直接崩掉。
• XFS Bug， 會導致叢集所有OSD程序直接崩掉。
• SSD 損壞。
• Ceph PG inconsistent。
• Ceph資料恢復時把網路頻寬跑滿。

總體來說，Ceph是非常穩定和可靠的。

未來

我們未來的工作會集中於

• 塊儲存系統Latency的優化
• 塊儲存系統管理平臺的改進，使得更多運維操作自動化，監控資訊視覺化
• 塊儲存系統提供更多的介面，對接更多的應用
• 塊儲存系統無痛擴容，減少擴容對上層應用的影響
• 提供關係型資料庫服務
• 提供NoSQL服務
• ……