上篇文章講到了ceph在災備方面有三大神兵利器：故障域、rbd異地災備、rgw異地災備。那麼本文講述下剩下的兩大利器rbd異地災備和rgw異地災備
ceph rbd異地災備術語叫做ceph rbd mirroring，在ceph jewel版本中宣布可用。在此之前ceph塊儲存解決方案（俗稱rbd）還不能很好的跨地域複製（災備）。這裡需要提醒一下，由於ceph是強一致性，所以只有在所有副本都寫完的時候才認為乙個寫操作完成。這就是為什麼建立乙個跨很長距離地域的集群通常都不是乙個好主意，因為這種情況延時一般都很高。集群必須等到所有的寫操作都完成，所以客戶端可能需要大量的時間來進行確認。
因此，我們需要一種機制來允許我們在不同地域的集群之間複製塊裝置。這種方法將幫助我們實現下面兩個不同的目的:
具體實現
乙個新的守護程序：rbd-mirror將負責把乙個集群的映象同步到另乙個集群。在這兩集群中都需要配置守護程序，它會同時連線本地和遠端集群。在當前jewel版本中，主要是實現兩個守護程序之間一對一的關係，而在未來將會擴充套件到1對n。這樣，在jewel以後的版本中，你將能夠配置乙個集群備份到多個目標備份集群中。
實現原理
rbd mirror的實現依賴於rbd 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複製。
具體的操作步驟可用檢視：
通過在單個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，配置複雜，鎖失敗等問題被廢棄，如
新版 multisite 沿用記日誌再同步的架構，**基本重寫，引入了 boost 的協程框架，配置更清晰。同乙個域下多 zone之間的資料為多主模式，可以同時寫；元資料為主從模式，由主zone寫入並同步到從zone，保證元資料一致性。並且即將支援桶級同步。最近主線合併了同步模型的外掛程式框架，使用者可以自定義外掛程式來對接 elasticsearch 實現元資料索引，或者自定義的向雲端備份等操作。
通過簡短的兩篇文章簡單介紹了ceph在災備方面的三大神兵利器以及實現原理解析。文章涉及的比較基礎，加上作者水平有限，希望本關卡能夠給予ceph新手參考。轉眼間第七篇文章也結束了，剩下最後的運維關卡了，預知後事如何，請期待最後的《運維&演練》。
從傳統運維到雲運維演進歷程之軟體定義儲存（二）
上回書說到一般企業使用ceph會經歷幾個關卡 硬體選型 部署調優 效能測試 架構災備設計 部分業務上線測試 執行維護 故障處理 預案演練等 今天來重點講下部署調優關卡。許多ceph新手在測試環節以及預生產的時候會對ceph集群的部署以及調優產生困擾，a公司運維小哥也遇到了部署和調優問題。下面來看看a...
雲計算運維
雲計算運維預習第三天 今天是我第一寫部落格，心裡還有很忐忑的，害怕別人看更害怕別人不看，在部落格裡也溜了幾個月，裡面的大神真的好多啊，好厲害，希望有大神能夠指點一二，能力相當的交流切磋。這個購買阿里雲好像還真的沒有什麼說的，現在就記住按量付費or包年包月，好像都還挺貴的，就華北的便宜一點，還有就是雲...
雲計算運維思考
雖然離開h公司公有雲運維崗位有一段時間了，但仍然在斷斷續續思考公有雲該如何做才能運維好，最近順手翻起 google sre運維之道 思考再三，對雲計算的本質和運維做乙個簡單總結。雲計算的本質是將計算機的基礎能力 硬體能力，軟體能力 以便捷的方式提供給需要的個人或組織使用，是一種能力和資源的使用方式。...