1. ScaleIO、VSAN、MFS、Ceph這幾種存儲方案的區別是什麼
ScaleIO:使用彈性聚合軟體產品來革新數據存儲，該軟體產品利用本地磁碟來創建伺服器存儲區域網路 (SAN)。純軟體方式的基於伺服器的存儲區域網路 (SAN)，將存儲和計算資源聚合到一起，形成單層的企業級存儲產品。 ScaleIO 存儲彈性靈活，可以提供可線性擴展的性能。 其橫向擴展伺服器 SAN 體系結構可以從幾個伺服器擴展至數千伺服器。
基本適用於全平台。https://community.emc.com/thread/198500
VSAN：VMware Virtual SAN™ 是面向虛擬環境中超聚合的軟體定義存儲.Virtual SAN 是第一款專為 vSphere 環境設計的策略驅動型存儲產品，可幫助用戶實現存儲調配和管理的簡化和優化。 通過使用虛擬機級存儲策略，Virtual SAN 可自動將需求與底層存儲資源進行動態匹配。藉助 Virtual SAN，許多手動存儲任務都可以實現自動化，從而提供更加高效和經濟實惠的運維模式。對比 ScaleIO，它是僅限於VMware虛擬化平台的。
參考鏈接：Virtual SAN：軟體定義的共享存儲 | VMware 中國
MFS 是分布式文件系統，可參考：分布式存儲系統MFS -
Ceph是一個 Linux PB 級分布式文件系統。
2. Ceph 架構與原理
Ceph 是一個開源項目，它提供軟體定義的、統一的存儲解決方案 。Ceph 是一個具有高性能、高度可伸縮性、可大規模擴展並且無單點故障的分布式存儲系統 。
Ceph 是軟體定義存儲解決方案
Ceph 是統一存儲解決方案
Ceph 是雲存儲解決方案
高可用性
高擴展性
特性豐富
Ceph獨一無二地統一的系統提供了對象存儲、塊存儲和文件存儲功能。Ceph存儲集群由幾個不同的軟體守護進程組成（比較重要的兩個是MON和OSD），每個守護進程負責Ceph的一個獨特功能並將值添加到相應的組件中。
RADOS是CEPH存儲系統的核心,也稱為Ceph 存儲集群。Ceph的數據訪問方法(如RBD,CephFS,RADOSGW，librados)的所有操作都是在RADOS層之上構建的。當Ceph 集群接收到來自客戶端的請求時,CRUSH演算法首先計算出存儲位置,最後將這些對象存儲在OSD中,當配置的復制數大於1時,RADOS負責的形式將數據分發到集群內的所有節點,最後將這些對象存儲在OSD中。當配置的復制數大於1時,RADOS負責數據的可靠性,它復制對象，創建副本並將它們存儲在不同的故障區域中。
RADOS包含兩個核心組件: OSD和MON
OSD 是Ceph 存儲集群中最重要的一個基礎組件，他負責將實際的數據以對象的形式存儲在每一個集群節點的物理磁碟中。對於任何讀寫操作，客戶端首先向MON請求集群MAP，然後客戶端舊可以直接和OSD進行I/O操作。
一個Ceph 集群包含多個OSD。一個典型的Ceph集群方案會為集群節點上的每個物理磁碟創建一個ODS守護進程,這個是推薦的做法。OSD上的每個對象都有一個主副本和幾個輔副本,輔副本分散在其他OSD。一個OSD對於一些對象是主副本，同時對於其他對象可能是輔副本，存放輔副本的OSD主副本OSD控制,如果主副本OSD異常(或者對應的磁碟故障),輔副本OSD可以成為主副本OSD。
OSD是有一個已經存在的Linux文件系統的物理磁碟驅動器和OSD服務組成。Ceph 推薦OSD使用的文件系統是XFS。OSD的所有寫都是先存到日誌,再到存儲.
MON 負責監控整個集群的健康狀況。它以守護進程的形式存在,一個MON為每一個組件維護一個獨立的MAP,如OSD，MON,PG,CRUSH 和MDS map。這些map 統稱為集群的MAP。MON 不為客戶端存儲和提供數據,它為客戶端以及集群內其他節點提供更新集群MAP的服務。客戶端和集群內其他節點定期與MON確認自己持有的是否是集群最新的MAP.一個Ceph集群通常包含多個MON節點,但是同一時間只有一個MON。
librados是一個本地的C語言庫，通過它應用程序可以直接和RADOS通信，提高性能
Ceph 塊存儲，簡稱 RBD，是基於 librados 之上的塊存儲服務介面。RBD 的驅動程序已經被集成到 Linux 內核（2.6.39 或更高版本）中，也已經被 QEMU/KVM Hypervisor 支持，它們都能夠無縫地訪問 Ceph 塊設備。Linux 內核 RBD（KRBD）通過 librados 映射 Ceph 塊設備，然後 RADOS 將 Ceph 塊設備的數據對象以分布式的方式存儲在集群節點中
RGW，Ceph對象網關，也稱做RADOS網關，它是一個代理，可以將HTTP請求轉換為RADOS，也可以把RADOS轉換為HTTP請求，從而提供restful介面，兼容S3和Swift。Ceph對象網關使用Ceph對象網關守護進程(RGW)與librgw、librados交互。Ceph對象網關支持三類介面：S3、Swift、管理API（通過restful介面管理Ceph集群）。RGW有自己的用戶管理體系
Ceph 元數據伺服器服務進程，簡稱 MDS。只有在啟用了 Ceph 文件存儲（CephFS）的集群中才需要啟用 MDS，它負責跟蹤文件層次結構，存儲和管理 CephFS 的元數據。MDS 的元數據也是以 Obejct 的形式存儲在 OSD 上。除此之外，MDS 提供了一個帶智能緩存層的共享型連續文件系統，可以大大減少 OSD 讀寫操作頻率。
CephFS在RADOS層之上提供了一個兼容POSIX的文件系統。它使用MDS作為守護進程，負責管理其元數據並將它和其他數據分開。CephFS使用cephfuse模塊（FUSE）擴展其在用戶空間文件系統方面的支持（就是將CephFS掛載到客戶端機器上）。它還允許直接與應用程序交互，使用libcephfs庫直接訪問RADOS集群。
Ceph管理器軟體，可以收集整個集群的所有狀態。有儀錶板插件
一個對象通常包含綁定在一起的數據和元數據，並且用一個全局唯一的標識符標識。這個唯一的標識符確保在整個存儲集群中沒有其他對象使用相同的對象ID，保證對象唯一性。基於文件的存儲中，文件大小是有限制的，與此不同的是，對象的大小是可以隨著大小可變的元數據而變得很大。對象不使用一個目錄層次結構或樹結構來存儲，相反，它存儲在一個包含數十億對象且沒有任何復雜性的線性地址空間中。對象可以存儲在本地，也可以存放在地理上分開的線性地址空間中，也就是說，在一個連續的存儲空間中。任何應用程序都可以基於對象ID通過調用restful API從對象中獲取數據。這個URL可以以同樣的方式工作在網際網路上，一個對象ID作為一個唯一的指針指向對象。這些對象都以復制的方式存儲在OSD中，因為能提供高可用性。
對於Ceph集群的一次讀寫操作，客戶端首先聯系MON獲取一個集群map副本，然後使用對象和池名/ID將數據轉換為對象。接著將對象和PG數一起經過散列來生成其在Ceph池中最終存放的那一個PG。然後前面計算好的PG經過CRUSH查找來確定存儲或獲取數據所需的主OSD的位置。得到准確的OSD ID之後，客戶端直接聯系這個OSD來存取數據。所有這些計算操作都由客戶端來執行，因此它不會影響Ceph集群的性能。一旦數據被寫入主OSD，主OSD所在節點將執行CRUSH查找輔助PG和OSD的位置來實現數據復制，進而實現高可用。
簡單地說，首先基於池ID將對象名和集群PG數應用散列函數得到一個PG ID，然後，針對這個PG ID執行CRUSH查找得到主OSD和輔助OSD，最後寫入數據。
PG是一組對象地邏輯集合，通過復制它到不同的OSD上來提供存儲系統的可靠性。根據Ceph池的復制級別，每個PG的數據會被復制並分發到Ceph集群的多個OSD上。可以將PG看成一個邏輯容器，這個容器包含多個對象，同時這個邏輯容器被映射到多個OSD。
計算正確的PG數對一個Ceph存儲集群來說是至關重要的一步。PG數計算公式如下
Ceph池是一個用來存儲對象的邏輯分區，每個池都包含一定數量的PG，進而實現把一定數量的對象映射到集群內部不同OSD上的目的。每一個池都是交叉分布在集群所有節點上的，這樣就能提供足夠的彈性。池可以通過創建需要的副本數來保障數據的高可用性。
Ceph的池還支持快照功能，我們可以使用ceph osd pool mksnap命令來給特定的池製作快照。此外，Ceph池還允許我們為對象設置所有者和訪問許可權。
數據管理始於客戶端向Ceph池中寫數據。一旦客戶端准備寫數據到Ceph池中，數據首先寫入基於池副本數的主OSD中。主OSD再復制相同的數據到每個輔助OSD中，並等待它們確認寫入完成。只要輔助OSD完成數據寫入，就會發送一個應答信號給主OSD。最後主OSD再返回一個應答信號給客戶端，以確認完成整個寫入操作。
3. CentOS 7部署 Ceph分布式存儲架構
隨著OpenStack日漸成為開源雲計算的標准軟體棧，Ceph也已經成為OpenStack的首選後端存儲。Ceph是一種為優秀的性能、可靠性和可擴展性而設計的統一的、分布式文件系統。
Ceph是一個開源的分布式文件系統。因為它還支持塊存儲、對象存儲，所以很自然的被用做雲計算框架openstack或cloudstack整個存儲後端。當然也可以單獨作為存儲，例如部署一套集群作為對象存儲、SAN存儲、NAS存儲等。
前三台伺服器增加一塊硬碟/dev/sdb實驗, 創建目錄並掛載到/var/local/osd{1,2,3};
規范系統主機名添加hosts文件實現集群主機名與主機名之間相互能夠解析（host 文件添加主機名不要使用fqdn方式）可用 hostnamectl set-hostname [name] 設置分別打開各節點的 /etc/hosts 文件，加入這四個節點ip與名稱的對應關系:
在管理節點使用ssh-keygen 生成ssh keys 發布到各節點
第一步：增加 yum配置文件(各個節點都需要增加yum源) vim /etc/yum.repos.d/ceph.repo
或阿里的ceph源
復制配置文件到其它節點和客戶端
在ceph1更新軟體源並安裝ceph-deploy 管理工具
配置文件的默認副本數從3改成2，這樣只有兩個osd也能達到 active+clean 狀態，添加行 osd_pool_default_size = 2
(如果網路源安裝失敗，手工安裝epel-release 然後安裝yum –yinstall cep-release再yum –y install ceph ceph-radosgw)
錯誤參考： https://blog.csdn.net/yenai2008/article/details/72457463
添加osd節點 (所有osd節點執行)
我們實驗准備時已經創建目錄/var/local/osd{id}
（用ceph-deploy把配置文件和admin密鑰拷貝到所有節點，這樣每次執行Ceph命令行時就無需指定monitor地址和ceph.client.admin.keyring了）
以上基本上完成了ceph存儲集群的搭建。
其中： <pg_num> = 128 ,
關於創建存儲池
確定 pg_num 取值是強制性的，因為不能自動計算。下面是幾個常用的值：
隨著 OSD 數量的增加，正確的 pg_num 取值變得更加重要，因為它顯著地影響著集群的行為、以及出錯時的數據持久性（即災難性事件導致數據丟失的概率）。
創建好存儲池後，你就可以用 fs new 命令創建文件系統了
ceph fs new <fs_name> cephfs_metadata cephfs_data
其中： <fs_name> = cephfs 可自定義
在這里想起沒在/etc/fstab配置ceph1、ceph2、ceph3的sdb自動掛載。
ceph在開源社區還是比較熱門的，但是更多的是應用於雲計算的後端存儲。所以大多數在生產環境中使用ceph的公司都會有專門的團隊對ceph進行二次開發，ceph的運維難度也比較大。但是經過合理的優化之後，ceph的性能和穩定性都是值得期待的。
清理機器上的ceph相關配置
可以參考內容： http://blog.51cto.com/12270625/1887648
4. ceph好學么
好學。
Ceph是一個統一的分布式存儲系統，設計初衷是提供較好的性能、可靠性和可擴展性。
Ceph項目最早起源於Sage就讀博士期間的工作（最早的成果於2004年發表），並隨後貢獻給開源社區。在經過了數年的發展之後，目前已得到眾多雲計算廠商的支持並被廣泛應用。RedHat及OpenStack都可與Ceph整合以支持虛擬機鏡像的後端存儲。
5. CEPH和NFS什麼區別哪個更好
ceph是分布式存儲系統
NFS是文件存儲系統，無優劣的說法，主要看實際的使用場景。
ceph提供的類型更多，如塊、對象等，性能更好，NFS提供的文件系統單一，但是操作簡單。
6. 雲計算分布式存儲是用ceph還是hadoop
ceph是一個分布式存儲的開源方案。
hadoop是一個開源大數據平台方案。大數據平台中也有存儲的部分，一般是用hdfs。
7. 分布式存儲技術有哪些
中央存儲技術現已發展非常成熟。但是同時，新的問題也出現了，中心化的網路很容易擁擠，數據很容易被濫用。傳統的數據傳輸方式是由客戶端向雲伺服器傳輸，由伺服器向客戶端下載。而分布式存儲系統QKFile是從客戶端傳送到 N個節點，然後從這些節點就近下載到客戶端內部，因此傳輸速度非常快。對比中心協議的特點是上傳、下載速度快，能夠有效地聚集空閑存儲資源，並能大大降低存儲成本。
在節點數量不斷增加的情況下，QKFile市場趨勢開始突出，未來用戶數量將呈指數增長。分布式存儲在未來會有很多應用場景，如數據存儲，文件傳輸，網路視頻，社會媒體和去中心化交易等。網際網路的控制權越來越集中在少數幾個大型技術公司的手中，它的網路被去中心化，就像分布式存儲一樣，總是以社區為中心，面向用戶，而分布式存儲就是實現信息技術和未來網際網路功能的遠景。有了分布式存儲，我們可以創造出更加自由、創新和民主的網路體驗。是時候把網際網路推向新階段了。
作為今年非常受歡迎的明星項目，關於QKFile的未來發展會推動互聯網的進步，給整個市場帶來巨大好處。分布式存儲是基於網際網路的基礎結構產生的，區塊鏈分布式存儲與人工智慧、大數據等有疊加作用。對今天的中心存儲是一個巨大的補充，分布式時代的到來並不是要取代現在的中心互聯網，而是要使未來的數據存儲發展得更好，給整個市場生態帶來不可想像的活力。先看共識，後看應用，QKFile創建了一個基礎設施平台，就像阿里雲，阿里雲上面是做游戲的做電商的視頻網站，這就叫應用層，現階段，在性能上，坦白說，與傳統的雲存儲相比，沒有什麼競爭力。不過另一方面來說，一個新型的去中心化存儲的信任環境式非常重要的，在此環境下，自然可以衍生出許多相關應用，市場潛力非常大。
雖然QKFile離真正的商用還有很大的距離，首先QKFile的經濟模型還沒有定論，其次QKFile需要集中精力發展分布式存儲、商業邏輯和 web3.0，只有打通分布式存儲賽道，才有實力引領整個行業發展，人們認識到了中心化存儲的弊端，還有許多企業開始接受分布式存儲模式，即分布式存儲 DAPP應用觸達用戶。所以QKFile將來肯定會有更多的商業應用。創建超本地高效存儲方式的能力。當用戶希望將數據存儲在QKFile網路上時，他們就可以擺脫巨大的集中存儲和地理位置的限制，用戶可以看到在線存儲的礦工及其市場價格，礦工之間相互競爭以贏得存儲合約。使用者挑選有競爭力的礦工，交易完成，用戶發送數據，然後礦工存儲數據，礦工必須證明數據的正確存儲才能得到QKFile獎勵。在網路中，通過密碼證明來驗證數據的存儲安全性。采礦者通過新區塊鏈向網路提交其儲存證明。通過網路發布的新區塊鏈驗證，只有正確的區塊鏈才能被接受，經過一段時間，礦工們就可以獲得交易存儲費用，並有機會得到區塊鏈獎勵。數據就在更需要它的地方傳播了，旋轉數據就在地球范圍內流動了，數據的獲取就不斷優化了，從小的礦機到大的數據中心，所有人都可以通過共同努力，為人類信息社會的建設奠定新的基礎，並從中獲益。
8. ceph分布式存儲為啥
Ceph是根據加州大學Santa Cruz分校的Sage Weil的博士論文所設計開發的新一代自由軟體分布式文件系統，其設計目標是良好的可擴展性(PB級別以上)、高性能及高可靠性。
Ceph其命名和UCSC（Ceph 的誕生地）的吉祥物有關，這個吉祥物是「Sammy」，一個香蕉色的蛞蝓，就是頭足類中無殼的軟體動物。這些有多觸角的頭足類動物，是對一個分布式文件系統高度並行的形象比喻。
其設計遵循了三個原則：數據與元數據的分離，動態的分布式的元數據管理，可靠統一的分布式對象存儲機制。本文將從Ceph的架構出發，綜合性的介紹Ceph分布式文件系統特點及其實現方式。
更多技術細節參考網頁鏈接
9. ceph：rados淺析
在傳統分布式存儲架構中，存儲節點往往僅作為被動查詢對象來使用，隨著存儲規模的增加，數據一致性的管理會出現很多問題。
而新型的存儲架構傾向於將基本的塊分配決策和安全保證等操作交給存儲節點來做，然後通過提倡客戶端和存儲節點直接交互來簡化數據布局並減小io瓶頸。
RADOS就是這樣一個可用於PB級規模數據存儲集群的可伸縮的、可靠的對象存儲服務。它包含兩類節點：存儲節點、管理節點。它通過利用存儲設備的智能性，將諸如一致性數據訪問、冗餘存儲、錯誤檢測、錯誤恢復分布到包含了上千存儲節點的集群中，而不是僅僅依靠少數管理節點來處理。
RADOS中的存儲節點被稱為OSD(object storage device)，它可以僅由很普通的組件來構成，只需要包含CPU、網卡、本地緩存和一個磁碟或者RAID，並將傳統的塊存儲方式替換成面向對象的存儲。
在PB級的存儲規模下，存儲系統一定是動態的：系統會隨著新設備的部署和舊設備的淘汰而增長或收縮，系統內的設備會持續地崩潰和恢復，大量的數據被創建或者刪除。RADOS通過 cluster map來實現這些，cluster map會被復制到集群中的所有部分（存儲節點、控制節點，甚至是客戶端），並且通過怠惰地傳播小增量更新而更新。cluster map中存儲了整個集群的數據的分布以及成員。
通過在每個存儲節點存儲完整的cluster map，存儲設備可以表現的半自動化，通過peer-to-peer的方式（比如定義協議）來進行數據備份、更新，錯誤檢測、數據遷移等等操作。這無疑減輕了佔少數的monitor cluster（管理節點組成的集群）的負擔。
一個RADOS系統包含大量的OSDs 和 很少的用於管理OSD集群成員的monitors。OSD的組成如簡介所說。而monitor是一些獨立的進程，以及少量的本地存儲，monitor之間通過一致性演算法保證數據的一致性。
存儲節點集群通過monitor集群操作cluster map來實現成員的管理。cluster map 描述了哪些OSD被包含進存儲集群以及所有數據在存儲集群中的分布。
cluster map不僅存儲在monitor節點，它被復制到集群中的每一個存儲節點，以及和集群交互的client。
當因為一些原因，比如設備崩潰、數據遷移等，cluster map的內容需要改變時，cluster map的版本號被增加，map的版本號可以使通信的雙方確認自己的map是否是最新的，版本舊的一方會先將map更新成對方的map，然後才會進行後續操作。
首先，如下圖，總體說下RADOS的存儲層次，RADOS中基本的存儲單位是對象，一般為2MB或4MB，當一個文件要存入RADOS時，首先會被切分成大小固定的對象（最後一個對象大小可能不同），然後將對象分配到一個PG（Placement Group）中，然後PG會復制幾份，偽隨機地派給不同的存儲節點。當新的存儲節點被加入集群，會在已有數據中隨機抽取一部分數據遷移到新節點。這種概率平衡的分布方式可以保證設備在潛在的高負載下正常工作。更重要的是，數據的分布過程僅需要做幾次隨機映射，不需要大型的集中式分配表。
對於每個層次的詳細說明：
2.Object—— RADOS的基本存儲單元。Object與上面提到的file的區別是，object的最大size由RADOS限定（通常為2MB或4MB），以便實現底層存儲的組織管理。因此，當上層應用向RADOS存入size很大的file時，需要將file切分成統一大小的一系列object（最後一個的大小可以不同）進行存儲。
各層次之間的映射關系：
前面的介紹中已經提到，由若干個monitor共同負責整個RADOS集群中所有OSD狀態的發現與記錄，並且共同形成cluster map的master版本，然後擴散至全體OSD以及client。OSD使用cluster map進行數據的維護，而client使用cluster map進行數據的定址。
monitor並不主動輪詢各個OSD的當前狀態。相反，OSD需要向monitor上報狀態信息。常見的上報有兩種情況：一是新的OSD被加入集群，二是某個OSD發現自身或者其他OSD發生異常。在收到這些上報信息後，monitor將更新cluster map信息並加以擴散。其細節將在下文中加以介紹。
Cluster map的實際內容包括：
（1） Epoch，即版本號。cluster map的epoch是一個單調遞增序列。epoch越大，則cluster map版本越新。因此，持有不同版本cluster map的OSD或client可以簡單地通過比較epoch決定應該遵從誰手中的版本。而monitor手中必定有epoch最大、版本最新的cluster map。當任意兩方在通信時發現彼此epoch值不同時，將默認先將cluster map同步至高版本一方的狀態，再進行後續操作。
（2）各個OSD的網路地址。
（3）各個OSD的狀態。OSD狀態的描述分為兩個維度：up或者down（表明OSD是否正常工作），in或者out（表明OSD是否在至少一個PG中）。因此，對於任意一個OSD，共有四種可能的狀態：
（4）CRUSH演算法配置參數。表明了Ceph集群的物理層級關系（cluster hierarchy），位置映射規則（placement rules）。
根據cluster map的定義可以看出，其版本變化通常只會由（3）和（4）兩項信息的變化觸發。而這兩者相比，（3）發生變化的概率更高一些。這可以通過下面對OSD工作狀態變化過程的介紹加以反映。
一個新的OSD上線後，首先根據配置信息與monitor通信。Monitor將其加入cluster map，並設置為up且out狀態，再將最新版本的cluster map發給這個新OSD。
收到monitor發來的cluster map之後，這個新OSD計算出自己所承載的PG（為簡化討論，此處我們假定這個新的OSD開始只承載一個PG），以及和自己承載同一個PG的其他OSD。然後，新OSD將與這些OSD取得聯系。如果這個PG目前處於降級狀態（即承載該PG的OSD個數少於正常值，如正常應該是3個，此時只有2個或1個。這種情況通常是OSD故障所致），則其他OSD將把這個PG內的所有對象和元數據復制給新OSD。數據復制完成後，新OSD被置為up且in狀態。而cluster map內容也將據此更新。這事實上是一個自動化的failure recovery過程。當然，即便沒有新的OSD加入，降級的PG也將計算出其他OSD實現failure recovery。
如果該PG目前一切正常，則這個新OSD將替換掉現有OSD中的一個（PG內將重新選出Primary OSD），並承擔其數據。在數據復制完成後，新OSD被置為up且in狀態，而被替換的OSD將退出該PG（但狀態通常仍然為up且in，因為還要承載其他PG）。而cluster map內容也將據此更新。這事實上是一個自動化的數據re-balancing過程。
如果一個OSD發現和自己共同承載一個PG的另一個OSD無法聯通，則會將這一情況上報monitor。此外，如果一個OSD deamon發現自身工作狀態異常，也將把異常情況主動上報給monitor。在上述情況下，monitor將把出現問題的OSD的狀態設為down且in。如果超過某一預訂時間期限，該OSD仍然無法恢復正常，則其狀態將被設置為down且out。反之，如果該OSD能夠恢復正常，則其狀態會恢復為up且in。在上述這些狀態變化發生之後，monitor都將更新cluster map並進行擴散。這事實上是自動化的failure detection過程。
對於一個RADOS集群而言，即便由數千個甚至更多OSD組成，cluster map的數據結構大小也並不驚人。同時，cluster map的狀態更新並不會頻繁發生。即便如此，Ceph依然對cluster map信息的擴散機制進行了優化，以便減輕相關計算和通信壓力：
基於上述機制，Ceph避免了由於cluster map版本更新而引起的廣播風暴。這雖然是一種非同步且lazy的機制，但根據論文中的結論，對於一個由n個OSD組成的Ceph集群，任何一次版本更新能夠在O(log(n))時間復雜度內擴散到集群中的任何一個OSD上。
一個可能被問到的問題是：既然這是一種非同步和lazy的擴散機制，則在版本擴散過程中，系統必定出現各個OSD看到的cluster map不一致的情況，這是否會導致問題？答案是：不會。事實上，如果一個client和它要訪問的PG內部的各個OSD看到的cluster map狀態一致，則訪問操作就可以正確進行。而如果這個client或者PG中的某個OSD和其他幾方的cluster map不一致，則根據Ceph的機制設計，這幾方將首先同步cluster map至最新狀態，並進行必要的數據re-balancing操作，然後即可繼續正常訪問。
10. Ceph為什麼越來越火國內使用ceph較為成功的存儲廠商有哪些
Ceph是當前非常流行的開源分布式存儲系統，具有高擴展性、高性能、高可靠性等優點，同時提供塊存儲服務(rbd)、對象存儲服務(rgw)以及文件系統存儲服務(cephfs)。目前也是OpenStack的主流後端存儲，隨著OpenStack在雲計算領域的廣泛使用，ceph也變得更加炙手可熱。國內目前使用ceph搭建分布式存儲系統較為成功的企業有x-sky,深圳元核雲，上海UCloud等三家企業。