關於做者
我是王盼，網易數帆存儲團隊負責人，資深系統開發工程師，具備10年雲計算行業從業經驗，作過幾年Libvirt、OpenStack開發，也作過一年多Ceph（主要是H版本）的維護調優，對計算虛擬化、雲計算平臺、分佈式存儲系統等均有必定的開發和運維經驗，我的技術博客：http://aspirer.wang/前端
Curve是咱們團隊寄予厚望的開源存儲項目，寫這篇科普文章，旨在讓對分佈式存儲系統（Ceph、Curve等）感興趣的運維、測試、開發人員，或者對底層存儲系統感興趣的雲計算平臺開發人員，更加了解咱們的項目。如欲對文中內容深刻研討，可添加微信號opencurve加入Curve用戶羣溝通交流。也歡迎關注每週五晚19:00點的Curve技術直播。git
Curve新版本介紹
9月下旬咱們發佈了curve的最新版本v1.1，這個版本重點是性能優化，不管是單client仍是10 client場景下，相比v1.0版本，都有至少30%以上的提高，其中提高尤爲明顯的是4k隨機讀寫場景下的性能（具體可參考releasenote），大部分場景下的提高都達到70%以上，部分場景性能幾乎提高一倍，可謂是飛躍性的進步。這一個版本兌現了7月份curve發佈時許下的性能提高30%的承諾，並帶來了一點驚喜。github
固然咱們不會知足於當前的性能，咱們能夠清晰的看到，在大IO場景下curve還有很大的提高空間，這也是curve團隊小夥伴們正在努力優化的，另外小IO場景下咱們觀察到也有較大的提高空間，期待curve下一個版本也能給你們帶來驚喜。算法
下面的性能對比數據中curve部分如無特殊說明都是基於v1.1版本測試的。數據庫
參考：https://github.com/opencurve/curve/blob/master/CHANGELOG-1.1.md後端
架構
Ceph
架構圖參考官網：https://docs.ceph.com/en/latest/architecture/api
ceph是基於crush算法的去中心化分佈式存儲架構，最大的優點是不須要元數據服務器，client每次下發IO請求能夠本身經過crush算法（輸入osdmap、對象名等）計算存儲節點和存儲設備（osd）以及數據存儲的大概位置（pg），不須要元數據服務器的好處是不會引發性能瓶頸和可用性、可擴展性之類的問題，沒有元數據分區、失效等問題，但無中心化的設計也會帶來容量不均衡等問題。緩存
但ceph也有一個mon集羣，用來管理基本的存儲集羣拓撲結構（monmap、osdmap、pgmap等）、容量、存儲集羣各組件狀態等信息，並經過Paxos協議保持多mon節點的可用性、可靠性和一致性，在集羣穩定運行過程當中，正常IO請求是不須要與mon集羣交互的，可是在集羣有異常，好比節點、磁盤上下線等場景下，仍是要mon介入以便確認副本狀態等信息，不然client和osd之間沒法達成一致，或者說沒辦法確認應該跟誰通訊。對應到存儲節點，每一個節點上通常都有多個磁盤（osd）來提供物理存儲空間，每一個osd上面又承載多個pg（管理數據副本一致性的最小單位），每一個pg管理多個對象（rbd、fs、rgw等存儲類型的數據存儲對應到osd上都是已對象的形式來存儲的，所以不考慮前面的3種具體形態，只有osd和mon的存儲系統又叫rados）。性能優化
pg裏的對象在磁盤上的管理形式當前主要是直接存儲在裸盤上（老版本是文件系統如xfs），爲了能找到對象數據的位置（邏輯位置到物理位置映射關係），每一個osd還要維護一份本身的元數據信息（固然還能夠保存對象的其餘信息如omap，以及osd自身的空間使用狀況等，還有pg的log信息），一般使用rocksdb（老版本是leveldb）。因爲rocksdb自己屬於LSM類型的存儲引擎，所以須要常常性的進行compaction操做，這一操做過程當中就會致使性能波動（磁盤壓力或rocksdb自己性能影響）。服務器
在集羣中存儲節點或存儲設備上下線過程當中，pg爲了保證數據的一致性，須要經由mon來確認各個副本的狀態，若是有副本下線，須要補充新的副本，若是副本上線則要同步落後的數據給他，在數據同步以前pg須要經歷一個叫peering的階段（osdmap可能會變化），用來找到權威的副本而且告知mon當前pg能夠對外提供IO讀寫服務了，peering階段完成前不能對外服務，這一階段若是花費的時間稍長就會致使client端IO時延變長（俗稱IO抖動，表現通常爲util升高）。
節點下線的時候若是沒有及時通知mon進行peering（osdmap仍是舊的），client端和主osd就會認爲下線的osd還處於在線狀態，繼續等待其返回或直到超時，新版本優化了下線流程不是死等超時，能夠主動發現osd網絡故障進而推斷出其已下線，加速進入peering階段，減小IO抖動時長。
ceph另外一個問題是因爲其要求3副本寫入強一致，必須等待全部副本寫入（至少是wal寫入完畢）才能返回給client成功消息，因此一旦有一個副本（含主）磁盤響應慢或者存儲機異常，就會致使IO請求時延飆高致使IO抖動，可是這個機制帶來的好處是，ceph能夠支持任意副本數的存儲池（好比經常使用的1~3）。另外在副本增量恢復過程當中（recovery），有讀（主副本）寫（任意副本）請求的時候也要等恢復完畢以後才能提供服務，也是會在必定程度上影響IO時延。
在集羣規模達到幾百臺的場景下，ceph的抖動問題很是突出，所以針對H版本咱們定製開發及優化了不少功能，好比數據均衡工具、backport下線主動發現機制、優化peering耗時，恢復速度控制、實現異步恢復等，另外咱們也配置了數量衆多的監控告警，以便及時發現問題節點、osd進行故障處理。
參考資料：
-
https://docs.ceph.com/en/latest/
-
http://aspirer.wang/?cat=1
Curve
架構圖參考官網：https://opencurve.github.io/
curve是網易徹底自主研發的新一代分佈式存儲系統，其架構中包含一箇中心化的元數據管理服務MDS（經過ectd選出主從實現高可用），配合etcd存儲引擎來保存集羣的元數據信息，包括系統的拓撲信息（相似ceph的osdmap）；文件系統的Namespace ( 樹形目錄結構，文件和目錄，目錄元信息等 )，相似ceph的crush ；Copyset ( Raft 複製組) 位置信息，copyset相似ceph的pg。MDS在必定程度上與ceph的mon集羣類似。MDS還感知集羣狀態並進行合理調度，包括感知Chunkserver上下線、收集Chunkserver負載信息、集羣負載均衡與故障修復，中心化架構的優點在於數據均衡比較容易實現，劣勢在於容易帶來擴展性的瓶頸，curve經過避免核心IO路徑上與MDS交互的方案來規避這一問題（只有管控操做如建立刪除卷等須要MDS），咱們模擬過上百近千臺存儲機場景下，MDS都不是瓶頸，更大規模的場景還須要進一步驗證。
curve的chunkserver相似ceph的osd，都是經過管理物理磁盤並存儲用戶數據的，當前1.0版本的chunkserver更接近於FileStore實現，經過ext4文件系統來管理chunk元數據，不須要依賴rocksdb等嵌入式數據庫（所以每一個chunk擴展屬性還不支持，但針對塊存儲場景目前尚未此類需求）。curve數據存儲的最小單元是 chunk（相似ceph的對象），管理chunk的基本單位是Copyset（相似ceph的pg），每一個copyset搭配一個raft複製組來保證數據多副本的一致性和容災能力。raft是多數一致性協議，好處是不須要等全部副本寫入（至少是wal），大多數寫入便可返回client端，極大的減小了長尾效應帶來的影響，同時也避免了單個節點或磁盤異常（慢盤壞盤、節點超載等）場景下的IO抖動問題，不足是不能支持單副本場景（3副本中有2副本損壞的緊急場景），也即3副本至多容忍損壞一個，不然就不能提供服務（ceph配置min_size爲1能夠支持但不太建議，單副本長期運行一旦壞盤會致使數據丟失）。curve能夠在節點、chunkserver上下線時主動進行數據的再均衡，而且支持恢復帶寬控制（這一點ceph也作的不太好，尤爲是L及以前的版本，都是經過控制併發及強制sleep來控制，很難精確控制帶寬）。chunkserver的wal寫入和一致性保證都是由braft來管理的，所以其業務邏輯很是簡單，代碼量也較少，開發者很容易上手（固然要深刻理解brpc、braft仍是會有一些挑戰）。
curve client端實現了一些卷讀寫接口如AioWrite、AioRead、Open、Close、StatFile、Extend等，用來給qemu虛擬機、curve-nbd等應用提供卷的IO操做接口，client還要跟MDS交互實現對元數據的增刪改查（如卷的增刪改查等，接口不列出來了）。client還會對io進行切分，能對inflight io數量進行控制。Client還支持熱升級，能夠在上層應用（qemu、curve-nbd等）無感知的狀況下進行client sdk版本變動。
curve的快照系統與ceph相比也不太同樣，ceph快照是保存在ceph自身存儲系統裏面（rados層）的，支持以對象或者存儲池爲粒度進行快照，curve則是要導出到S3接口兼容的存儲系統。兩種架構各有優劣，保存本系統好處是不須要導出導入，節省時間，但會帶來性能開銷，可靠性也會有必定影響（若是丟數據則快照也不能倖免），保存到外部系統，則能夠作更多的事情，好比快照壓縮等，性能也更優（多級快照場景更加明顯，不須要逐層查找對象進行IO讀寫）。
參考：
-
https://opencurve.github.io/
-
https://github.com/opencurve/curve/blob/master/README.md
-
https://docs.ceph.com/en/latest/architecture/
功能
從功能方面來對比Curve和Ceph確定是不公平的，畢竟ceph已經發展了10年了，curve纔剛剛開源出來，不過能夠簡單看下兩者在塊存儲方面的功能對比，讓你們對curve有個更直觀的瞭解。
經常使用功能方面，curve和ceph都支持卷建立、刪除，支持掛載到qemu、物理機（nbd）使用，支持擴容，支持快照及恢復。
ceph提供了一些高級功能（L版本），好比rbd-mirror、layering support、striping、exclusive lock、object map等，大部分通常用戶是用不到的，或者是針對快照等場景進行的優化。更高版本的ceph提供了QoS功能。
curve提供的高級功能包括client QoS（經過限制inflight io實現）、client sdk熱升級等，都是很是實用的功能。ceph的client端qos老版本還不太支持（好比L版本），當前咱們H版本都是在應用層作的（好比qemu、nbd設備的cgroup等）。
ceph支持EC pool，但塊存儲場景下通常不太會使用到。
ceph的控制檯功能比較簡單不能知足產品化需求，固然curve尚未開發控制檯，可是監控告警因爲是基於bvar來作的，所以配合grafana和prometheus能夠方便的實現可視化監控，而且展現的信息量很是豐富。ceph的監控更多的是經過ceph-mgr配合prometheus來作但可展現的監控項不是很豐富，或者基於perf counter功能本身封裝，整體來講不夠便利。
其餘有些功能方面的差別已經在架構部分作了說明，這裏再也不復述。
參考：http://aspirer.wang/?p=1456
性能
性能方面，小IO場景下curve具備比較大的優點，尤爲是最近發佈的v1.1版本，性能更是提高了一大截。大IO狀況下，curve還有較大的提高空間，尤爲是時延方面還比較高，這也是curve團隊當前的重點工做方向。我相信有了小IO場景優化經驗，大IO場景優化起來也會比較駕輕就熟。
| 項目 | 配置 |
|---|---|
| 存儲機 | Dell R730xd * 6臺 |
| CPU | Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz * 2 |
| MEM | 256G |
| NIC | Intel Corporation 82599EB 10-Gigabit SFI/SFP+ * 2 |
| OS | Debian GNU/Linux 9 |
| Kernel | 4.9.65-netease #1 SMP Thu Aug 2 03:02:48 |
| curve版本 | v1.1-0beta |
| ceph版本 | Luminous 12.2.13 |
| client host | Dell R730xd * 2臺 |
| fio版本 | 3.13 |
咱們內部測試對比數據以下（因爲集羣軟硬件配置和ceph調優手段不盡相同，數據僅供參考）：
單卷：
| 項目 | Ceph | Curve |
|---|---|---|
| 4k randwrite (128 iodepth) | iops: 39700, latency-avg: 3.2ms, latency-99: 4ms | iops：109000, latency-avg: 1.1ms, latency-99: 2ms |
| 4k randread (128 iodepth) | iops: 41700, latency-avg: 3.1ms, latency-99: 3.4ms | iops：128000, latency-avg: 1.0ms, latency-99: 1.5ms |
| 512k write (128 iodepth) | bps: 2076MB/s(單節點帶寬已打滿), latency-avg: 31ms, latency-99: 116ms | bps: 204MB/s, latency-avg: 314ms, latency-99: 393ms |
| 512k read (128 iodepth) | bps: 2056MB/(單節點帶寬已打滿)s, latency-avg: 31ms, latency-99: 144ms | bps: 995MB/s, latency-avg: 64ms, latency-99: 92ms |
10卷：
| 項目 | Ceph | Curve |
|---|---|---|
| 4k randwrite (128 iodepth) | iops: 185000, latency-avg: 7ms, latency-99: 24ms | iops：262000, latency-avg: 4.9ms, latency-99: 32ms |
| 4k randread (128 iodepth) | iops: 330000, latency-avg: 3.7ms, latency-99: 6ms | iops：497000, latency-avg: 2.7ms, latency-99: 6ms |
| 512k write (128 iodepth) | bps: 3172MB/s(單節點帶寬已打滿), latency-avg: 44ms, latency-99: 182ms | bps: 1122MB/s, latency-avg: 569ms, latency-99: 1100ms |
| 512k read (128 iodepth) | bps: 4440MB/(單節點帶寬已打滿)s, latency-avg: 28ms, latency-99: 129ms | bps: 3241MB/s, latency-avg: 200ms, latency-99: 361ms |
注：Ceph版本爲L，N版本經測試與L相差不大，相關配置項爲默認值。
參考：https://github.com/opencurve/curve/blob/master/CHANGELOG-1.1.md
運維
運維這方面，主要討論部署和平常維護兩塊：
| 項目 | ceph | curve |
|---|---|---|
| 部署 | ceph-deploy，新版本是ceph-adm | ansible |
| 維護 | 命令集（ceph/rbd/rados/...） | curve_ops_tool |
兩個項目把集羣部署起來都還算簡單，ceph-deploy有個問題，部署比較慢，要串行操做，爲此咱們還優化了一下ceph-deploy工具。ceph部署完服務纔算第一步，後面還要建立crush rule（這個若是沒有通過深刻研究，仍是有比較高的門檻的），配置pool的各項參數等操做。
curve應該只須要修改幾個比較簡單的配置文件（playbook的yaml），就能夠一鍵部署搞定了，相對比較簡單。
維護的話，ceph一大問題是常常遇到慢盤、壞盤，影響client的IO，用戶常常抱怨（會收到一堆util超過90%告警），長時間抖動要幫用戶手工解決（停掉慢盤osd），或者短期的抖動要幫用戶確認是否ceph致使的util飆高。爲此咱們也作了大量的工做來搞定這一場景（如增長各類監控，進行巡檢等及時發現問題，甚至發現慢盤自動中止osd等等），但總歸是治標不治本，只能儘可能規避。
除了抖動，還有容量均衡問題（沒有中心化的調度節點，只能根據使用狀況進行osd的pg數量調整），集羣縮容問題等比較難處理，老版本的pg數量不支持減小，是個比較大的問題（L版本也只能增長pg，更新的版本才支持減小pg），以及縮容後，即便只剩下少許的卷，也很難遷移到其餘存儲池（qemu用到了存儲池，能夠遷移到其餘root rule，可是pg數量沒法減小也是個問題），致使存儲池使用的存儲節點很難下線。
擴容場景下，除非新建root rule和存儲池，不然ceph須要對已有數據進行遷移均衡到新增長的節點上，這方面curve也是相似的（物理池邏輯與ceph的root rule相似），curve的好處是能夠作到精確的帶寬控制，減小對正常業務的影響。
平常的壞盤替換場景下，ceph能夠作到只遷移一次數據（L版本，H版本還不太行），也即壞盤下線的時候不作數據遷出，新盤上線時進行數據恢復便可（固然也能夠作到自動遷出和遷入）。curve的話當前是下線自動遷出，上線自動遷入。兩者區別不大，curve好處依然是精確帶寬控制。
壓力檢測是一個比較困難的場景（如何找出壓力比較大的client，並及時對其進行限制防止雪崩效應？），也是一個強需求（雖然client有qos，但集羣通常都有性能超售，部分client壓力飆升可能影響整個集羣），ceph場景下，因爲只能看到集羣壓力狀況，很難作到全部client的聚集（當前是qemu端作的監控）和分析（固然可能跟咱們使用的自研監控服務不支持這種場景有必定關係），致使很難找出那個或者那些影響了整個集羣的client。通常咱們都是用土方法，查看壓力大的osd，打開message日誌，找出消息比較多client ip，而後再根據client的監控狀況判斷是否跑滿，同時找出一樣業務的其餘虛擬機，而後逐個進行限速處理。這一過程確定比較耗時耗力，還不必定準確（可能新版本已經支持了單個rbd卷的性能統計）。curve場景下就比較簡單了，看下grafana的client監控，找到壓力大的client對其進行限速便可。
監控告警也是一大運維重點，ceph的話能夠基於perf counter機制來作一部分，作不了的能夠本身定製化擴展。也能夠基於ceph-mgr+prometheus+grafana來作，通常還要配合存儲節點的NODE_EXPORTER來作會比較全面。咱們內部沒有用這套機制，是基於自研的監控系統來作的，主要是用到了perf counter+監控腳本模式。
相比ceph的模式，curve基於bvar+prometheus+grafana，監控指標拉取更及時，都是秒級的，能夠實時顯示性能、時延曲線。bvar另一個好處是它對外提供的是http api，不是perf counter那種命令行，也就是說不須要在本地部署agent或者腳本便可拉取數據，管理起來比較方便。
參考：
-
https://github.com/opencurve/curve/blob/master/docs/cn/monitor.md
-
https://github.com/opencurve/curve/blob/master/docs/cn/deploy.md#多機部署
-
https://docs.ceph.com/en/latest/mgr/prometheus/
學習曲線
純使用
若是是運維人員想使用ceph或curve，或者對比2者進行選型，那我這篇文章基本上能夠作爲參考了。
ceph運維上手仍是比較複雜的，要對各類概念、配置參數（L版本單單osd配置項我粗略看了下就有400多個，大部分配置項都要經過閱讀源碼來真正理解其意義和用途）、各類監控指標有比較清晰的理解，還要對各類pg狀態有深刻理解，各類異常要能找到對應的解決方案，固然網上各類調優文檔也有不少能夠拿來參考，若是沒有深刻的使用經驗和測試比較，這些調優文檔也有可能與你的使用場景不符，甚至可能帶來反作用。
curve的代碼註釋（含配置項）很是完善，配置項也比較少（粗略看了下client、chunkserver、mds等所有加起來跟osd的配置項數量差很少），每一個配置都有詳細的解釋，即便不明白也能夠隨時諮詢咱們的開發人員。集羣狀態也比較容易理解，沒有那麼多的incomplete、peering、degraded、undersize、recoverying、remapped、stale...
運維相關的部署維護監控告警方面，也是curve更容易上手一些，上面已有對比說明。
開發者
上面的架構對比已經說明了問題，curve架構很是簡潔易懂（raft也比Paxos簡單多了），不須要花費太多時間就能理解代碼邏輯，上手進行開發測試。
更重要的是，不論對純使用的運維人員仍是開發者來講，curve的資料原文都是中文版本的，對國內用戶來講都特別友好（另外還有微信羣能夠即時溝通）。
可擴展性/可塑性
功能
ceph的功能已經足夠多了，號稱統一存儲平臺。所以功能這塊擴展性或者可塑性已經不大。
curve的話還很是年輕，它從架構設計之初就考慮到後續支持擴展各類存儲場景的（塊、對象、EC、其餘引擎等等），當前的發展方向也還在逐步摸索，咱們會根據公司內部和存儲業界最新動向來及時調整規劃，緊跟IT架構演進趨勢。咱們也歡迎各路同仁加入討論和開發，一塊兒發展curve。
咱們近期的roadmap主要集中在以下幾個方向：
-
雲原生數據庫支持：爲MySQL提供分佈式存儲後端
-
雲原生容器平臺支持：容器雲、中間件的存算分離（curve-nbd替換本地data盤、支持相似cephfs的文件存儲）
-
做爲ceph的前端緩存集羣：相似ceph的cache tier
-
發展開源社區：吸引我的、企業開發者，加入TOP開源基金會
各個方向都能拆分出很是多的功能、性能、穩定性等方面的需求。中長期的規劃可能會發生比較大的變化，這裏就不列出來了。
性能
性能一直是curve重點關注的方向，除了上面已經給出的數據，後續curve還會花費大量資源在性能優化上，近兩年的目標是支持雲原生數據庫和給k8s集羣提供存儲服務（前期可能考慮用nbd盤替換k8s節點本地盤，後期可能考慮開發相似cephfs的文件系統功能），雖然v1.1版本相比v1.0有了很大提高，當前離目標仍是有必定差距的。io_uring、QUIC、spdk、rdma、25G網卡等新技術都在考慮當中，nvme/傲騰、40G網絡等新硬件也在調研。curve近幾年沒有商業化或者盈利的打算，所以不會把各類優化手段和方案保留自用，都會毫無保留的開源出來。
ceph的性能也一直在改進，但因爲其架構和功能比較複雜，牽一髮而動全身，因此只能用全新的版本和架構來作（基於spdk/seastor等的SEASTORE），由於要保持功能的兼容性，當前看起來還須要較長時間才能正式發佈。大部分sds廠商都是基於現有的架構進行優化改進，具體優化到什麼程度，要看各家的實力和人力投入如何，可是通常來講他們的優化都是做爲競爭力保留的，不太會開放給外部。
參考：
-
https://docs.ceph.com/en/latest/dev/seastore/
社區
ceph的社區活躍度確定是很高的，curve剛剛開源，不少人還不瞭解。
ceph是一個成熟的國際化的開源社區，新人想參與進去提交pr仍是有較高的難度的（通常是從編寫測試用例、簡單的bug修復入手），功能性的pr通常都是比較核心的開發人員才容易被接受（這一點跟Linux內核社區很類似）。
而curve剛剛起步，目前重點仍是吸引國內開發者，一是便於溝通交流（能夠微信添加opencurve拉你進交流羣），二是鑑於當前國際形式也更傾向於爲國內用戶服務。剛剛起步的好處是，咱們對全部的pr都很是歡迎，而且要求會相對比較低（可能你提交的pr不太符合規範，咱們能夠幫忙修改完善，可能你的pr沒有考慮全面，咱們能夠給你提供修改建議和設計思路），有任何想法均可以在羣裏或者issue上提出來，目的是鼓勵你們積極參與進來。企業用戶若是有交流的想法，也能夠與咱們聯繫面談，若是roadmap或需求有匹配的地方能夠合做開發，提升研發效率、節約人力成本。
後續curve也會考慮加入某個開源組織（基金會），但目前主要仍是關注自身的功能和性能問題，待條件成熟會有進一步的動做。
curve的roadmap可參考：https://github.com/opencurve/curve/wiki/Roadmap
應用規模
當前來講兩者也沒有可比性，畢竟ceph已經發展了10年，而curve纔剛剛開源3個多月（內部開發2年多）。單就網易內部使用狀況來講，ceph上線將近5年了，節點最多時數千臺（隨着業務從OpenStack轉向K8s，集羣規模有所減小），curve上線1年多，卷數量數千，而且一直穩定運行無任何SLA損失，這一點據我瞭解ceph當初上線時也沒有作到的，curve的開發質量可見一斑。業務方通過這一年多時間測試觀察，已經逐步創建起了對curve的信心，這一點從近期curve卷的使用量大幅增長能夠明顯感受出來（咱們給業務方提供了ceph、curve兩種卷類型，他們能夠自行選擇建立哪一種類型的卷），近2個月以來curve卷數量已翻了一番，咱們預估明年集團內部使用量會有爆發式增加。
相關活動預告：網易數帆Curve核心開發團隊將帶來精心準備的 Curve 新一代分佈式存儲技術系列公開課（直播+回放），每週五晚19:00爲你們揭開 Curve 技術的奧妙及Curve社區的規劃。本週五，將由網易數帆資深系統開發工程師查日蘇帶來「Curve核心組件之ChunkServer數據節點」的分享，敬請收看：Curve核心組件之ChunkServer！