写在前面
首先，需要说明的是，我一直认为 Ceph 是非常优秀的开源存储软件，想起来我接触 Ceph 也有好些年了，Ceph 除了为我带来知识上的收获，还为我带来生活上的温饱，所以我对 Ceph 充满了感恩与 Respect。
其次，尽管已经在存储这块领域涉猎了好几年，但我依然只算得上存储新人，因为存储涉及到的领域是既宽广又深入。存储的数据对于任何一家公司来说都是无价的资产，所以作为一个存储人有必要永远保持一颗敬畏之心，敬畏自己敲下的每一行代码，敬畏自己敲下的每一个线上命令。
存储抑或云计算的圈子其实很小，所以非常荣幸借 Curve 这样一个开源项目，能与那些既陌生又熟悉的存储人一起交流与学习。
我在网易做 Ceph
好风凭借力，存储其实很难作为一款独立的产品提供给用户使用，也正因为如此，Ceph 先后借着 OpenStack 和 K8S 这两股东风获得了快速的发展，逐渐成为了开源领域的明星产品。
网易这边差不多是15年开始关注 Ceph 的，基本上算是一个早期的阶段。最开始我们是基于 OpenStack 使用 Ceph 块存储提供虚拟机，15年左右其实也是移动互联网蓬勃发展的好时机，那时候网易集团先后孵化了网易云音乐，网易严选，网易考拉等业务，借着这些业务的发展，我们使用 Ceph 的体量也得到了飞速的发展，比如15年的时候我们可能整个也就几百个 osd，16年的时候已经有5000+个osd，17年有15000+个osd，到了18年已经有30000+个osd，同时最大规模的单集群达到了4000+个osd。
17年左右，随着 K8S 的应用以及普及，公司内外的很多业务都开始拥抱容器化了，在当时的场景下，Ceph 文件存储便逐渐有超越 Ceph 块存储之势。我们也在这一阶段开始把 Ceph 的版本切换到 L 版本。
在从事 Ceph 这段时间里，我虽然做了一些事情，但坦率地讲，做的事情并不多，以前跟圈里从事 Ceph 的小伙伴们聊天，大家经常会开玩笑说我们其实不算是研发(懂的都懂，这里为了不招职业黑，原话就不贴了，哈哈)。
因为所做的事情确实并不多，所以几句话就足以总结我这几年做过的事情：维护了几个还算大的 Ceph 集群；分析并优化了几项 Ceph 的性能；优化了几项 Ceph 的抖动问题；完善了 Ceph 的运维体系；向社区提交了几个简单的 PR。奥，还有，拯救了几次线上集群，或许，这几年里，也只有少数的这几个时刻，让我觉得自己像是一个超级马里奥。
Curve：缘起
缘起1：来自业务的无数次diss
对于大规模线上集群来说的话，坏盘，慢盘，raid卡故障或者是服务器故障等异常场景是很频繁的。但是因为 Ceph 三副本的强一致性协议，那么需要三副本均写完了，才能返回给业务写成功。所以这时，但凡有一个点异常了，写IO便迟迟无法返回给客户端；更为要紧的是，Ceph 的池化概念导致了属于该池子的所有业务卷都会受影响。
所以往往就是 Ceph 线上但凡有一处异常，便会导致大面积的用户卷IO发生卡顿。由于像网易云音乐以及电商这些业务的用户对卡顿是非常敏感的，所以每到这时业务这个甲方爸爸便会找到我们，要求我们给出解决方案。
缘起2:降本增效
众所周知，Ceph 的均衡性现在还不是特别好(当然，现在有自动均衡，但是我理解线上应该不敢轻易上这功能；至于pg upmap的话运维就比较麻烦了)。
对于线上 Ceph 集群来说，不同硬盘使用率差别可能有百分之二三十。但是问题在于，Ceph 集群存在着短板效应，尤其是 Ceph 的老版本，一个osd full了，整个集群就不可服务IO了；后续版本的话一个osd满了，它对应的pool所属的所有卷便都不能服务IO了。
所以，线上的现实就是，Ceph 集群的平均使用率到了百分之七十多，大家就会赶紧想着扩容，要不然万一某个osd写满了，那可能就要full跑路了。
这个问题势必就带来了成本上的大幅上升，明明才使用百分之七十多，却要着急扩容。如果你要扩容，那势必会增加服务器，增加硬盘，增加网络以及机房托管费等层层费用开销。
缘起3：性能
当前来说的话，是希望我们的存储能够支撑数据库场景。
Ceph 的性能优化也一直是社区的一个方向，但是基于 Ceph 的架构和功能比较复杂，所以这个优化过程是一个长期的过程。
基于这几个主要方面的原因，我们开始了 Curve 的研发。Curve 在稳定性方面，线上大规模稳定运行了两年多，无任何 SLA 损失；在成本方面，由于 Curve 出色的均衡性，集群使用率可以接近百分之百；在性能方面，Curve 的性能在大多数场景下均是优于 Ceph 的，具体情况可以参见 Curve GitHub 主页：
https://github.com/opencurve/curve
Curve：现状，未来
Curve 项目2020年正式开源，今年6月份被正式接纳为 CNCF 沙箱(Sandbox)项目；网易基于开源 Curve 的商业化版本今年7月份通过信创认证。Curve 愿景：替代 Ceph 的国产开源项目。
Curve 的块存储已经在线上大规模稳定运行两三年，Curve 文件存储第一个正式稳定版本于今年发布，目前正在持续完善和场景落地中。
对于块存储 ，稳定性和可用性已经有比较好的保证，并且当前也有着不错的性能；而我们也有更高的目标，目前正在与云原生数据库团队合作，打造更加高性能的支撑数据库存算分离的块存储。
对于文件存储 ，我们期望打造性能与成本可兼得的云原生文件系统。
- 普用性：大家可以对接通用的的对象存储系统(比如aws s3,nos,minio等等)；
- 高性能：数据后端可以直接使用 Curve 块存储(这一块，Curve也是完全开源的)；
- 低成本：数据后端可以直接只用对象存储；另外，我们也可以把Curve块存储作为对象存储的缓存层。
对于EC ，有不少社区同学关心这一块，当前 Curve EC 功能正由社区小伙伴驱动在完善这一块，不久后也会跟大家见面，也欢迎更多的社区同学来参与共建。
Curve 推荐词
如果要我给大家推荐 Curve 几个关键词的话，我想我会用上以下几个关键词：稳定性；低成本；高性能；国产开源，信创认证；残缺美 。
Curve 作为一款年轻的开源存储系统，与 Ceph 相比肯定有很多不足之处。但是Curve 相比 Ceph，在某些方面也有着一定的优势，所以如果这些优势正好也是您所关注的，那么也非常荣幸，能有机会向您推荐 Curve。
稳定性
如前文所述，Ceph 在各种硬件异常导致的单副本产生故障时，会造成大面积的SLA损失，Curve 则不会有任何SLA损失。
成本
Curve 相较于Ceph更优的均衡性，可以降低扩容要求，减少大量硬件成本。
性能
Curve 之初，就是为了解决大多数场景下 Ceph 的性能缺陷。
国产开源，信创认证
Curve 社区的发起者和参与者目前主要都在国内，能形成更好的交流氛围与途径。当前国际形势下，建设国产自主可控体系、大力发展信创产业已成为“数字基建”的目标，Curve 获得国家工业信息安全发展研究中心的信创认证，验证了 Curve 与信创供应链中其他产品的高度兼容适配。
残缺美
Ceph 是一款优秀的开源存储软件，发展了十几年，但 Ceph 的功能已经非常完善，想要参与社区或者精通 Ceph 是一件非常难的事情。而 Curve 才开源两年，尤其是 Curve 文件存储，正是因为 Curve 的不完善，Curve 社区接下来才有更多的事情要做，所以我们也更加渴望与期盼更多的社区朋友跟我们一起发展一起来玩，让我们都能成为国内开源存储的一份子。
写在最后
写这篇文章其实很惶恐，但若能藉此让朋友们知道我现在正在做什么，甚或能再增加三两志同道合的知己，一起做有趣且有价值的的事情，那便是我莫大的荣幸了。