1 maps 更新
1.1 更新規則
Because cluster map changes may be frequent, as in a very large system where OSDs failures and recoveries are the norm, updates are distributed as incremental maps(增量更新): small messages describing the differences between two successive epochs. In most cases, such updates simply state that one or more OSDs have failed or recovered, although in general they may include status changes for many devices, and multiple updates may be bundled together to describe the difference between distant map epochs.
由於RADOS集羣坑內包含成千上萬的設備，簡單的廣播Map更新消息到每個節點是不實際的.
- map增量更新,只描述變化信息,通常是一個或多個節點錯誤或恢復
- 間隔比較長的map,將多個跟新捆綁.一次更新
- 將壓力轉移到OSD間通信,OSD和client通訊,OSD自己相互更新map
一個OSD與其他Peer聯繫時都會共享和更新Map
心跳消息會週期的交換以檢測異常保證更新快速擴散，對於一個有n個OSD的集羣，用到的時間爲O（logn）。
所有的RADOS消息（包括從客戶端發起的消息，以及從其他OSD發起的消息）都攜帶了發送端的map epoch，以保證所有更新操作都能夠在最新的版本上保持一致。如果一個客戶端因爲使用了一個過期的map，發送一個IO到一個錯誤的OSD，OSD會回覆一個適當的增量，客戶端再重新發送這個請求到正確的OSD。這就避免了主動共享map到客戶端，客戶端會在與Cluster聯繫的時候更新。大部分時候，他們都會在不影響當前操作的時候學到更新，讓接下來的IO能夠準確的定位。
解析 Ceph : OSD , OSDMap 和 PG, PGMap
http://www.wzxue.com/ceph-osd-and-pg/
Monitor 作爲Ceph的 Metada Server 維護了集羣的信息，它包括了6個 Map，分別是 MONMap，OSDMap，PGMap，LogMap，AuthMap，MDSMap。其中 PGMap 和 OSDMap 是最重要的兩張Map.
這時它們的通信就會附帶上 OSDMap 的 epoch
Ceph 通過管理多個版本的 OSDMap 來避免集羣狀態的同步，這使得 Ceph 絲毫不會畏懼在數千個 OSD 規模的節點變更導致集羣可能出現的狀態同步。
1.2 OSDmap過程
- 新osd啓動
因此該 OSD 會向 Monitor 申請加入，Monitor 再驗證其信息後會將其加入 OSDMap 並標記爲IN，並且將其放在 Pending Proposal 中會在下一次 Monitor “討論”中提出，OSD 在得到 Monitor 的回覆信息後發現自己仍然沒在 OSDMap 中會繼續嘗試申請加入，接下來 Monitor 會發起一個 Proposal ，申請將這個 OSD 加入 OSDMap 並且標記爲 UP 。然後按照 Paxos 的流程，從 proposal->accept->commit 到最後達成一致，OSD 最後成功加入 OSDMap 。當新的 OSD 獲得最新 OSDMap 發現它已經在其中時。這時，OSD 才真正開始建立與其他OSD的連接，Monitor 接下來會開始給他分配PG。 - osd down
這個 OSD 所有的 PG 都會處於 Degraded 狀態。然後等待管理員的當一個 OSD 因爲意外 crash 時，其他與該 OSD 保持 Heartbeat 的 OSD 都會發現該 OSD 無法連接，在彙報給 Monitor 後，該 OSD 會被臨時性標記爲 OUT，所有位於該 OSD 上的 Primary PG 都會將 Primary 角色交給其他 OSD(Monitor 維護了每個Pool中的所有 PG 信息.下一步決策
2 Ceph OSDMap 機制淺析
SDMap 機制主要包括如下3個方面：
- Monitor 監控 OSDMap 數據，包括 Pool 集合，副本數，PG 數量，OSD 集合和 OSD 狀態。
- OSD 向 Monitor 彙報自身狀態，以及監控和彙報 Peer OSD 的狀態。
- OSD 監控分配到其上的 PG , 包括新建 PG , 遷移 PG , 刪除 PG 。
在整個 OSDMap 機制中，OSD充分信任 Monitor, 認爲其維護的 OSDMap 數據絕對正確，OSD 對 PG 採取的所有動作都基於 OSDMap 數據，也就是說 Monitor 指揮 OSD 如何進行 PG 分佈
3 PG Map
3.1 PG 自己維護,恢復,遷移
從上面的描述中我們可以瞭解到 Monitor 掌握了整個集羣的 OSD 狀態和 PG 狀態，每個PG都是一部分 Object 的擁有者，維護 Object 的信息也每個 PG 的責任，Monitor 不會掌握 Object Level 的信息。因此每個PG都需要維護 PG 的狀態來保證 Object 的一致性。但是每個 PG 的數據和相關故障恢復、遷移所必須的記錄都是由每個 PG 自己維護，也就是存在於每個 PG 所在的 OSD 上。
PGMap 是由 Monitor 維護的所有 PG 的狀態，每個 OSD 都會掌握自己所擁有的 PG 狀態，PG 遷移需要 Monitor 作出決定然後反映到 PGMap 上，相關 OSD 會得到通知去改變其 PG 狀態。在一個新的 OSD 啓動並加入 OSDMap 後，Monitor 會通知這個OSD需要創建和維護的 PG ，當存在多個副本時，PG 的 Primary OSD 會主動與 Replicated 角色的 PG 通信並且溝通 PG 的狀態，其中包括 PG 的最近歷史記錄。通常來說，新的 OSD 會得到其他 PG 的全部數據然後逐漸達成一致，或者 OSD 已經存在該 PG 信息，那麼 Primary PG 會比較該 PG 的歷史記錄然後達成 PG 的信息的一致。這個過程稱爲 Peering ，它是一個由 Primary PG OSD 發起的“討論”，多個同樣掌握這個 PG 的 OSD 相互之間比較 PG 信息和歷史來最終協商達成一致。
在 Ceph 中，PG 存在多達十多種狀態和數十種事件的狀態機去處理 PG 可能面臨的異常
寫得不錯的文章
Ceph：pg peering過程分析
https://www.ustack.com/blog/ceph%EF%BC%8Dpg-peering/?print=yes
4 放置組計算
放置組,根據通過對象名的hash值
pgid = (r, hash(o)&m)
o對象名,r負載份數,m位掩碼 &按位與, pgid放置組號
m = 2^k−1, number of placement groups 放置組個數
CRUSH是穩定的
當一個（或多個）設備加入或離開集羣，放置組原來的存儲位置不變; CRUSH只轉移足夠的數據來保持數據均勻分佈.
Ceph的Monitor集羣會計算每個PG所對應的OSD，並將這個信息保存在Cluster Map中
該OSD收到寫請求的時候先檢查比對Client的自己的epoch，如果一致則查找pg_id對應的active OSD list
OSDMap 機制和 CRUSH 算法一起構成了 Ceph 分佈式架構的基石。
Monitor 作爲Ceph的 Metada Server 維護了集羣的信息，它包括了6個 Map，分別是 MONMap，OSDMap，PGMap，LogMap，AuthMap，MDSMap。其中 PGMap 和 OSDMap 是最重要的兩張Map
Monitor集羣內部通過Paxos協議來維護Cluster Map的數據一致性。實現上Monitor採用了Lease機制簡化Paxos協議，這種簡化協議僅允許系統中只有一個Monitor能夠進行寫入，這個Monitor稱爲Leader。初始時所有的Monitor先選舉出一個Leader，該Leader將協調其他Monitor的Cluster Map的更新。每隔固定週期Leader向其他Monitor發放Lease，持有Lease的Monitor才能夠對外提供讀服務（否則認爲該Monitor上的數據已經過時，不能提供讀服務）。
Monitor集羣不會主動去檢測OSD的狀態，OSD也不會定期向Monitor彙報狀態，OSD狀態報告主要是通過下面三種方式：1）Client在讀取某個OSD內容時發現OSD宕機，並報告給Monitor集羣；2）OSD在給其他OSD同步數據或者交換心跳信息時發現OSD宕機，報告給Monitor集羣；3）新上線或者恢復的OSD主動向Monitor集羣報道自己新的狀態。這樣設計的原因在於Ceph需要支持PB級的數據存儲，系統中可能有成千上萬的OSD，正常情況下並不需要這些檢測網絡信息，保證Monitor集羣最小化有利於系統的擴展性。同樣Cluster Map的增量變化大部分情況也不是由Monitor集羣直接同步給各個OSD，而是各個OSD中相互同步最新的Cluster Map信息。
rados分佈算法在2.4節已經講過了,map更新logn次便可以更新完畢.
當集羣增多,設備故障就好更加頻發,更新次數就好增加.因爲map更新和交互只發生在共享相同PG的OSD間,上限正比於單個OSD接收上的副本個數.
In simulations under near-worst case propagation circumstances with regular map updates, we found that update duplicates approach a steady state even with exponential cluster scaling. In this experiment, the monitors share each map update with a single random OSD, who then shares it with its peers. In Figure 3 we vary the cluster size x and the number of PGs on each OSD (which corresponds to the number of peers it has) and measure the number of duplicate map updates received for every new one (y).Update duplication approaches a constant level—less than 20% of μ—even as the cluster size scales exponentially, implying a fixed map distribution overhead.
We consider a worst case scenario in which the only OSD chatter are pings for failure detection, which means that, generally speaking,OSDs learn about map updates (and the changes known by their peers) as slowly as possible. Limiting map distribution overhead thus relies only on throttling the map update frequency, which the monitor cluster already does as a matter of course.
5 論文
論文列表
https://tobegit3hub1.gitbooks.io/ceph_from_scratch/content/architecture/papers.html
6 OSD個數
RAM內存
元數據服務器和監視器必須可以儘快地提供它們的數據，所以他們應該有足夠的內存，至少每進程 1GB 。 OSD 的日常運行不需要那麼多內存（如每進程 500MB ）差不多了；然而在恢復期間它們佔用內存比較大（如每進程每 TB 數據需要約 1GB 內存）。通常內存越多越好。
根據經驗， 1TB 的存儲空間大約需要 1GB 內存。
另外每個 OSD 守護進程佔用一個驅動器。
7 CRUSH 算法
Ceph剖析：數據分佈之CRUSH算法與一致性Hash
http://blog.csdn.net/xingkong_678/article/details/51530836
bucket類型
bucket分爲4種類型
一般bucket,正常的bucket和錯誤的bucket互不影響
CRUSH源碼分析
http://way4ever.com/?p=123
假設我組建一套存儲系統，有3個機架(host)，每個機架上有4臺主機(host)，每個主機上有2個磁盤(device)，則一共有24個磁盤。預計的擴展方式是添加主機或者添加機架。
我們的bucket有三種: root、rack、host。root包含的item是rack，root的結構是straw。rack包含的item是host，rack的結構是tree。host包括的item是device，host的結構式uniform。這是因爲每個host包括的device的數量和權重是一定的，不會改變，因此要爲host選擇uniform結構，這樣計算速度最快。
CRUSH詳解
https://tobegit3hub1.gitbooks.io/ceph_from_scratch/content/architecture/crush.html
一個robust解決方案是把數據隨機分佈到存儲設備上，這個方法能夠保證負載均衡，保證新舊數據混合在一起。但是簡單HASH分佈不能有效處理設備數量的變化，導致大量數據遷移。ceph開發了CRUSH（Controoled Replication Under Scalable Hashing），一種僞隨機數據分佈算法，它能夠在層級結構的存儲集羣中有效的分佈對象的副本。CRUSH實現了一種僞隨機(確定性)的函數，它的參數是object id或object group id，並返回一組存儲設備(用於保存object副本)。CRUSH需要cluster map(描述存儲集羣的層級結構)、和副本分佈策略(rule)。
處理設備變化,減少數據遷移
CRUSH有兩個關鍵優點：
1) 任何組件都可以獨立計算出每個object所在的位置(去中心化)。
2) 只需要很少的元數據(cluster map)，只要當刪除添加設備時，這些元數據才需要改變。
集羣結構變化
當集羣架構發生變化後情況就比較複雜了，例如在集羣中添加節點或者刪除節點。在添加的數據進行移動時，CRUSH的mapping過程所使用的按決策樹中層次權重算法比理論上的優化算法∆w /w更有效。在每個層次中，當一個香港子樹的權重改變分佈後，一些數據對象也必須跟着從下降的權重移動到上升的權重。由於集羣架構中每個節點上僞隨機位置決策是相互獨立的，所以數據會統一重新分佈在該點下面，並且無須獲取重新map後的葉子節點在權重上的改變。僅僅更高層次的位置發送變化時，相關數據纔會重新分佈。這樣的影響在圖3的二進制層次結構中展示了出來。
8 RGW和Block
9 對象存儲的優點
面向對象存儲14個優點，你知不知道？
http://www.chinastor.com/a/jishu/0R42a42011.html
面向對象存儲所需要知道的十四大問題
1. 存儲成本與數據價值一致
2. 較RADI更好地數據可用性
3. 性能呈現集羣性
當新服務器運行在額外增添的對象存儲集羣設備上，性能就可以突破瓶頸實現進程和I/O大規模並行讀寫。這一點特別適合於多媒體文件存儲和讀取。
4. 提供無限容量和可擴展性
面向對象存儲系統中，沒有目錄層次結構（樹），對象的存儲位置可以存儲在不同的目錄路徑中易變檢索。這就使得對象存儲系統可以精準到每個字節，而且不受文件（對象）數量、文件大小和文件系統容量的限制。
5. 內置歸檔和規範
6. 文件系統無法實現的元數據利用
面向對象存儲系統可以不需要文件名、日期和其他文件屬性就可以查找文件。他們還可以使用元數據應用服務水平協議（SLA），路由協議，備災和災難恢復，備份和數據刪除刪除以及自動存儲管理。這些是文件系統所不能解決的問題。
7. 無需備份
8. 自動負載平衡
9. 常規移植
10. 無需硬件鎖定
根據存檔和法規要求，存儲的數據需要保持數年。技術更新的成本和複雜性是一個需要考慮的重要因素，特別是連接到昂貴的專有硬件平臺系統，這種因素更加需要予以重視。部署只有軟件的對象存儲系統而無需考慮底層硬件，允許用戶選擇使用任何一種商業服務器技術和無中斷升級（當新硬件被推出的時候）。
11. 更高的磁盤利用率
12. 高可用性和災難恢復
13. 化繁爲簡
14. 新舊互不干擾
在學習CRUSH之前，需要了解以下的內容。
CRUSH算法接受的參數包括cluster map，也就是硬盤分佈的邏輯位置，例如這有多少個機房、多少個機櫃、硬盤是如何分佈的等等。cluster map是類似樹的多層結果，子節點是真正存儲數據的device，每個device都有id和權重，中間節點是bucket，bucket有多種類型用於不同的查詢算法，例如一個機櫃一個機架一個機房就是bucket。
另一個參數是placement rules，它指定了一份數據有多少備份，數據的分佈有什麼限制條件，例如同一份數據不能放在同一個機櫃裏等的功能。每個rule就是一系列操作，take操作就是就是選一個bucket，select操作就是選擇n個類型是t的項，emit操作就是提交最後的返回結果。select要考慮的東西主要包括是否衝突、是否有失敗和負載問題。
算法的還有一個輸入是整數x，輸出則是一個包含n個目標的列表R，例如三備份的話輸出可能是[1, 3, 5]。
http://blog.csdn.net/XingKong_678/article/details/51526627
Uniform: 這種桶用完全相同的權重匯聚設備。例如，公司採購或淘汰硬件時，一般都有相同的物理配置（如批發）。當存儲設備權重都相同時，你可以用 uniform 桶類型，它允許 CRUSH 按常數把副本映射到 uniform 桶。權重不統一時，你應該採用其它算法。
適用於很少增加刪除設備的場景
增加機器後所有數據需要重新分佈
List: 這種桶把它們的內容匯聚爲鏈表。它基於 RUSH P 算法，一個列表就是一個自然、直觀的擴張集羣：對象會按一定概率被重定位到最新的設備、或者像從前一樣仍保留在較老的設備上。結果是優化了新條目加入桶時的數據遷移。然而，如果從鏈表的中間或末尾刪除了一些條目，將會導致大量沒必要的挪動。所以這種桶適合永不或極少縮減的場景。
增加機器時移動的數據是最優的
– 和UniformBucket不同不需要重新分佈數據
– 只需要從原先的機器上遷移數據到新機器
• 減少機器時需要數據重新分佈
Tree: 它用一種二進制搜索樹，在桶包含大量條目時比 list 桶更高效。它基於 RUSH R 算法， tree 桶把歸置時間減少到了 O(log n) ，這使得它們更適合管理更大規模的設備或嵌套桶。
Straw: list 和 tree 桶用分而治之策略，給特定條目一定優先級（如位於鏈表開頭的條目）、或避開對整個子樹上所有條目的考慮。這樣提升了副本歸置進程的性能，但是也導致了重新組織時的次優結果，如增加、拆除、或重設某條目的權重。 straw 桶類型允許所有條目模擬拉稻草的過程公平地相互“競爭”副本歸置。
增加刪除機器時的數據移動量都是最優的
CRUSH Maps
CRUSH 圖主要有 4 個主要段落。
1. 設備 由任意對象存儲設備組成，即對應一個 ceph-osd 進程的存儲器。 Ceph 配置文件裏的每個 OSD 都應該有一個設備。
2. 桶類型： 定義了 CRUSH 分級結構裏要用的桶類型（ types ），桶由逐級匯聚的存儲位置（如行、機櫃、機箱、主機等等）及其權重組成。
3. 桶例程： 定義了桶類型後，還必須聲明主機的桶類型、以及規劃的其它故障域。
4. 規則： 由選擇桶的方法組成。
10 map管理
Montior Map： 包含集羣的 fsid 、位置、名字、地址和端口，也包括當前版本、創建時間、最近修改時間。要查看監視器圖，用 ceph mon dump 命令。
OSD Map： 包含集羣 fsid 、創建時間、最近修改時間、存儲池列表、副本數量、歸置組數量、 OSD 列表及其狀態（如 up 、 in ）。要查看OSD運行圖，用 ceph osd dump 命令
。
PG Map：：** 包含歸置組版本、其時間戳、最新的 OSD 運行圖版本、佔滿率、以及各歸置組詳情，像歸置組 ID 、 up set 、 acting set 、 PG 狀態（如 active+clean ），和各存儲池的數據使用情況統計。
CRUSH Map：：** 包含存儲設備列表、故障域樹狀結構（如設備、主機、機架、行、房間、等等）、和存儲數據時如何利用此樹狀結構的規則。要查看 CRUSH 規則，執行 ceph osd getcrushmap -o {filename} 命令；然後用 crushtool -d {comp-crushmap-filename} -o {decomp-crushmap-filename} 反編譯；然後就可以用 cat 或編輯器查看了。
MDS Map： 包含當前 MDS 圖的版本、創建時間、最近修改時間，還包含了存儲元數據的存儲池、元數據服務器列表、還有哪些元數據服務器是 up 且 in 的。要查看 MDS 圖，執行 ceph mds dump 。
map
11 參考
Ceph集羣在系統擴容時觸發rebalance的機制分析
http://my.oschina.net/linuxhunter/blog/637737
