Ceph RBD mirror資料非同步備份的具體實踐

分類＼科技
時間＼2017-04-11

備份是災備的基礎。在當今的災備體系中，為了保證備份資料的可靠性以及可用性，備份資料往往都是獨立於生產資料而存在，這也就使得的備份方式更多是通過在生產系統上部署用戶端或Agent來完成資料的複製以及向備端的傳輸，

然後通過備端完成資料的存儲及歸檔等。

而軟體定義存儲則採用的是分散式架構，資料是以多副本的形式分散在幾十成百甚至上千節點的集群進行存儲的，憑藉多副本機制以及後臺校驗等機制，軟體定義存儲可以提升集群資料的可靠性保護，在單個硬體發生故障時，節點可以做到動態的負載均衡，並且可以憑藉分佈在不同的機器上的副本及演算法完成資料的恢復，

實現高可用性。

但這種分散式存儲機制，也導致了一個問題，就是很難用傳統的基於存儲複製或CDP等技術來完成對整個集群資料的異地複製以及傳輸。

本文就從此出發，以杉岩資料基於Ceph的RBD mirror上的具體實踐為例，來談談軟體定義存儲的資料備份問題：

因為Ceph採用的是強一致性同步模型，即必須所有副本都完成寫操作才算一次寫入成功。

而如果副本在異地的話，由於網路延遲的存在，那麼整個集群的寫性能就會比較差，也就無法有效支撐異地複製，較早的ZoneGroup和聯合集群概念也並沒有很好的解決這個問題。

於是從2015年開始啟動的新功能——RBD Mirror進了大家的視線，用以解決兩個集群間非同步備份的問題。

RBD Mirror原理其實和MySQL的主從同步原理非常類似，簡單地說就是利用日誌進行重播(replay)：通過在存儲系統中增加Mirror元件，

採用非同步複製的方式，實現異地備份。

在說Mirror之前，我們需要首先瞭解一下Ceph的journal機制。這裡說明一下，此處的journal是指Ceph RBD的journal，而不是OSD的journal。

當RBD Journal功能打開後，所有的資料更新請求會先寫入RBD Journal，然後後臺執行緒再把資料從Journal區域刷新到對應的image區域。RBD journal提供了比較完整的日誌記錄、讀取、變更通知以及日誌回收和空間釋放等功能，可以認為是一個分散式的日誌系統。

具步驟如下：

1.I/O會寫入主集群的Image Journal

2. Journal寫入成功後，RBD再把資料寫入主集群回復回應

3.備份組群的mirror進程發現主集群的Journal有更新後，從主集群的Journal讀取資料，寫入備份組群。

4.備份組群寫入成功後，會更新主集群Journal中的中繼資料，表示該I/O的Journal已經同步完成

5.主集群會定期檢查，刪除已經寫入備份組群的Journal資料。

這種方式的優點包括：

1、當副本在異地的情況下，減少了單個集群不同節點間的資料寫入延時；

2、減少本地集群或異地集群由於意外斷電導致的資料丟失。

目前社區的RBD mirror正在不斷完善中，相信未來隨著Ceph的不斷發展，mirror在技術上也將為更為成熟，同時，由於Ceph可以作為OpenStack後端存儲，因此mirror的逐步成熟，也將使得OpenStack在塊設備的異地容災方面有所提升。

其他方式：

軟體定義存儲實現了軟硬體的分離，在硬體存儲上獨立出一個軟體的管理層，而資料複製的這一動作就可以在這裡完成，這就回避了前面所提到的由於存儲節點分散而難以複製的問題。例如，利用SDS平臺的Storage Management API允許備份系統生成一份對生產資料的靜態拷貝，比如對生產資料做快照（snapshot），或者提供對多副本歷史資料訪問功能實現災備，但這相當於在SDS中增加了CDP功能，對SDS的性能會有不小的影響，因此，目前並未看到有具體的實踐產品。

另一種和SDS類似的方式則是通過在軟體定義存儲上一層搭建的分散式資料庫進行資料的複製。所謂的分散式資料庫，就是指分散式存儲系統中各節點上資料庫的邏輯集合，具體的複製機制類似SDS，這裡就不再贅述。

從目前實際情況來看，不管是較為熱門的雲災備理念還是兩地三中心理念，網路的限制對異地災備系統的限制依然較為明顯，這個問題的解決任重而道遠。世上沒有100%的安全，也沒有100%的災備，黑天鵝事件總會發生，相比於“預防”，想想如何從黑天鵝事件中提升自己的反脆弱性而不僅僅是堅韌性同樣重要。