上篇文章講到了Ceph在災備方面有三大神兵利器：故障域、RBD異地災備、RGW異地災備。那么本文講述下剩下的兩大利器RBD異地災備和RGW異地災備

關卡五：Ceph災備神兵利器-RBD Mirroring & RGW異地災備

重要度：五顆星

Ceph災備神兵利器-RBD Mirroring

Ceph RBD異地災備術語叫做Ceph RBD Mirroring，在Ceph?Jewel版本中宣布可用。在此之前Ceph塊存儲解決方案（俗稱RBD）還不能很好的跨地域復制（災備）。這里需要提醒一下，由于Ceph是強一致性，所以只有在所有副本都寫完的時候才認為一個寫操作完成。這就是為什么建立一個跨很長距離地域的集群通常都不是一個好主意，因為這種情況延時一般都很高。集群必須等到所有的寫操作都完成，所以客戶端可能需要大量的時間來進行確認。

因此，我們需要一種機制來允許我們在不同地域的集群之間復制塊設備。這種方法將幫助我們實現下面兩個不同的目的:

• 災難恢復

• 全局塊設備分布

?

具體實現

一個新的守護進程：rbd-mirror將負責把一個集群的鏡像同步到另一個集群。在這兩集群中都需要配置守護進程，它會同時連接本地和遠程集群。在當前Jewel版本中，主要是實現兩個守護進程之間一對一的關系，而在未來將會擴展到1對N。這樣，在Jewel以后的版本中，你將能夠配置一個集群備份到多個目標備份集群中。

?

實現原理

RBD Mirror的實現依賴于RBD image的兩個新特性:

• 日志特性: 為作用在image上的每一個事務啟用日志

• Mirror特性: 通過這個明確的告訴rbd-mirror進程復制這個image

后續還會有命令和librbd接口來為一個特定的Mirror啟用/禁用。日志維護著這個image上的所有事務的操作記錄列表。它可以被視為存在于集群中的另一個rbd image(一系列RADOS對象)。一般來說，一個寫操作首先到達日志，再返回到客戶端，然后被寫入底層rbd image中。由于性能的原因，這個日志可以存放在跟執行日志化的image不同的資源池中。目前，每一個rbd image都有一個日志。在為Ceph實現一致性組（consistency group）之前，可能會一直保持這種結構。對于不熟悉這些概念的人而言，可以這樣理解：一致性組是一個實體，它管理著可以被視為是一個的一堆卷(如:rbd image)。這樣，你就可以針對這個組內的所有卷執行一些操作，比如快照。有了一致性組，就可以保證所有卷在同一個一致的狀態上。所以當一致性組在Ceph中實現后，將使用一個日志來記錄所有的rbd image，同時作為這個組的一部分。

RBD Mirror功能的啟用和禁用可以作用在整個Pool或者一個image上。如果在資源池級別啟用了RBD Mirror功能，這樣資源池中的每一個啟用了日志特性的鏡像將會被Mirror agent復制。

具體的操作步驟可用查看：

http://ceph.org.cn/2016/05/08/ceph-jewel-%E5%8A%9F%E8%83%BD%E9%A2%84%E8%A7%88-ceph-rbd-mirroring/

http://www.sebastien-han.fr/blog/2016/03/28/ceph-jewel-preview-ceph-rbd-mirroring/

?

Ceph災備神兵利器-RGW異地災備

通過在單個Ceph集群之上搭建RGW服務，可用很輕松的實現一套基于HTTP標準的對象存儲解決方案，但是對象存儲服務一般都是面向互聯網一類的應用，互聯網應用一方面要求較高的可靠性，另一方面還需要最大可能的跨越地域限制去提供高速穩定的接入服務。

而RGW異地同步方案，剛好就是為了解決互聯網服務的上述需求，一方面在多個地理位置存放數據實現服務的高可靠和高可用，另一方面借助DNS負載均衡、CDN等成熟技術手段，提供近端訪問從而實現客戶端的高速接入。

?

RGW邏輯概念

Region：一般用來代表邏輯上的地理區域（比如省會、國家等較大規模的地理范圍），一個Region可以包含一個或多個Zone。若如果一個Ceph集群隸屬于多個Region，則必須指定其中一個Region為Master Region。

Zone：指一個或多個RGW服務實例的邏輯組合，每個Region需要指定一個Master Zone來負責處理所有來自客戶端的請求。也就是說，寫對象操作只能在Master Zone進行（可讀寫），讀對象操作可以在其他的Zone中進行。（只讀）但是讀者需要注意的是目前RGW并未設置任何策略來阻止除Master Zone以外的Zone進行寫入操作，請務必遵循規范。

數據同步：實現多個Ceph集群之間的對象數據的同步（對象數據可以簡單理解為bucket內存放的object數據）。

元數據同步：實現多個Ceph集群之間的對象元數據信息的同步（元數據信息可以簡單理解為用戶uid、email、access-key、secret-key等一類的元數據信息）。

RGW服務實例：這個概念相對來講比較抽象，可以簡單理解為一個RGW服務實例就對應一個在操作系統上運行的RGW服務。確切來講一個RGW服務實例應該是對應一組Region和Zone配置信息。

同步日志：記錄各個RGW服務實例的數據和元數據的變更情況。

同步代理agent：同步代理agent是一組同步服務，通過輪詢的方式比較多個RGW服務實例之間的同步日志，從而得到需要同步的數據列表，之后根據列表調用RGW服務的相關API來實現數據和元數據的同步。

?

RGW災備原理

要實現RGW異地同步，首先需要將原本孤立零散的RGW服務，按照一定邏輯組成Region和Zone，從而打破物理地域的限制，在邏輯上形成統一的命名空間。之后啟動同步代理agent，通過輪詢方式比較多個RGW服務實例之間的同步日志，最終按照Region和Zone的邏輯關系，將同步日志中的差異部分的數據和元數據按照一定規則進行同步。

標注：RGW部分講述的是H版

RGW 的 H 版多站點同步，由于需要起額外的 python 寫的 agent，配置復雜，鎖失敗等問題被廢棄，如?http://tracker.ceph.com/issues/14081。

新版 multisite 沿用記日志再同步的架構，代碼基本重寫，引入了 boost 的協程框架，配置更清晰。同一個域下多 zone之間的數據為多主模式，可以同時寫；元數據為主從模式，由主zone寫入并同步到從zone，保證元數據一致性。并且即將支持桶級同步。最近主線合并了同步模型的插件框架，用戶可以自定義插件來對接 elasticsearch 實現元數據索引，或者自定義的向云端備份等操作。

通過簡短的兩篇文章簡單介紹了Ceph在災備方面的三大神兵利器以及實現原理解析。文章涉及的比較基礎，加上作者水平有限，希望本關卡能夠給予Ceph新手參考。轉眼間第七篇文章也結束了，剩下最后的運維關卡了，預知后事如何，請期待最后的《?運維&演練》。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的从传统运维到云运维演进历程之软件定义存储（五）下的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。