关于做者
我是王盼，网易数帆存储团队负责人，资深系统开发工程师，具备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！