上篇文章講到了Ceph在災備方面有三大神兵利器：故障域、RBD異地災備、RGW異地災備。那麼本文講述下剩下的兩大利器RBD異地災備和RGW異地災備
Ceph RBD異地災備術語叫做Ceph RBD Mirroring，在Ceph Jewel版本中宣布可用。在此之前Ceph塊存儲解決方案（俗稱RBD）還不能很好的跨地域複制（災備）。這裡需要提醒一下，由于Ceph是強一緻性，是以隻有在所有副本都寫完的時候才認為一個寫操作完成。這就是為什麼建立一個跨很長距離地域的叢集通常都不是一個好主意，因為這種情況延時一般都很高。叢集必須等到所有的寫操作都完成，是以用戶端可能需要大量的時間來進行确認。
是以，我們需要一種機制來允許我們在不同地域的叢集之間複制塊裝置。這種方法将幫助我們實作下面兩個不同的目的:
災難恢複
全局塊裝置分布
一個新的守護程序：<code>rbd-mirror</code>将負責把一個叢集的鏡像同步到另一個叢集。在這兩叢集中都需要配置守護程序，它會同時連接配接本地和遠端叢集。在目前Jewel版本中，主要是實作兩個守護程序之間一對一的關系，而在未來将會擴充到1對N。這樣，在Jewel以後的版本中，你将能夠配置一個叢集備份到多個目标備份叢集中。
RBD Mirror的實作依賴于RBD image的兩個新特性:
日志特性: 為作用在image上的每一個事務啟用日志
Mirror特性: 通過這個明确的告訴<code>rbd-mirror</code>程序複制這個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複制。
具體的操作步驟可用檢視：
<a href="http://ceph.org.cn/2016/05/08/ceph-jewel-%E5%8A%9F%E8%83%BD%E9%A2%84%E8%A7%88-ceph-rbd-mirroring/" target="_blank">http://ceph.org.cn/2016/05/08/ceph-jewel-%E5%8A%9F%E8%83%BD%E9%A2%84%E8%A7%88-ceph-rbd-mirroring/</a>
<a href="http://www.sebastien-han.fr/blog/2016/03/28/ceph-jewel-preview-ceph-rbd-mirroring/" target="_blank">http://www.sebastien-han.fr/blog/2016/03/28/ceph-jewel-preview-ceph-rbd-mirroring/</a>
通過在單個Ceph叢集之上搭建RGW服務，可用很輕松的實作一套基于HTTP标準的對象存儲解決方案，但是對象存儲服務一般都是面向網際網路一類的應用，網際網路應用一方面要求較高的可靠性，另一方面還需要最大可能的跨越地域限制去提供高速穩定的接入服務。
而RGW異地同步方案，剛好就是為了解決網際網路服務的上述需求，一方面在多個地理位置存放資料實作服務的高可靠和高可用，另一方面借助DNS負載均衡、CDN等成熟技術手段，提供近端通路進而實作用戶端的高速接入。
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服務，按照一定邏輯組成Region和Zone，進而打破實體地域的限制，在邏輯上形成統一的命名空間。之後啟動同步代理agent，通過輪詢方式比較多個RGW服務執行個體之間的同步日志，最終按照Region和Zone的邏輯關系，将同步日志中的差異部分的資料和中繼資料按照一定規則進行同步。
标注：RGW部分講述的是H版
新版 multisite 沿用記日志再同步的架構，代碼基本重寫，引入了 boost 的協程架構，配置更清晰。同一個域下多 zone之間的資料為多主模式，可以同時寫；中繼資料為主從模式，由主zone寫入并同步到從zone，保證中繼資料一緻性。并且即将支援桶級同步。最近主線合并了同步模型的插件架構，使用者可以自定義插件來對接 elasticsearch 實作中繼資料索引，或者自定義的向雲端備份等操作。
通過簡短的兩篇文章簡單介紹了Ceph在災備方面的三大神兵利器以及實作原了解析。文章涉及的比較基礎，加上作者水準有限，希望本關卡能夠給予Ceph新手參考。轉眼間第七篇文章也結束了，剩下最後的運維關卡了，預知後事如何，請期待最後的《 運維&演練》。
本文轉自Devin 51CTO部落格，原文連結:http://blog.51cto.com/devingeng/1884397