导读：Curve 是一款高性能、易运维、云原生的开源分布式存储系统(CNCF Sandbox)。可应用于主流的云原生基础设施平台：对接 OpenStack 平台为云主机提供高性能块存储服务；对接 Kubernetes 为其提供 RWO、RWX 等类型的持久化存储卷；对接 PolarFS 作为云原生数据库的高性能存储底座，完美支持云原生数据库的存算分离架构。
Curve 亦可作为云存储中间件使用 S3 兼容的对象存储作为数据存储引擎，为公有云用户提供高性价比的共享文件存储。
本文将介绍Curve块存储相关的部分，并分享Curve在一些场景的应用。
全文目录：
- 分布式存储介绍
- Curve架构及介绍
- Curve主要亮点
- Curve RoadMap
- 问答环节
01 分布式存储介绍
1.分布式存储的分类
首先简单介绍一下分布式存储的分类。分布式存储可以分为三类：对象存储、文件存储和块存储。对象存储在互联网中应用的比较多，比如一个对象、一个图片、一个音频，这种可以通过PUT GET接口来进行存储。文件存储与传统意义的文件系统的区别是，它是分布式的，传统的项目对应的是Ext4，或者是NTFS。块存储，就是所谓的云盘。
2. 分布式存储的要素
下面介绍一下分布式存储在设计时的一些要素。首先，需要大容量的硬盘空间，并且可以随机写，还有最重要的是要保证服务的质量，数据不能丢失，还要保证它的可用性。
要素可以拆解为以下三方面：
①第一是高性能。在分布存储里面，存储节点会非常多，所以要知道数据存在什么位置以及如何去取。
②第二是可用性。要保证数据的可靠性，避免数据丢失，并且保证在机器故障时数据的读写是能够正常运行的。
③第三是可扩展性。如果容量用完了，可以新增机器扩展容量。
数据分布，主要有两种，一个是无中心节点，另一个是有中心节点。
另外一个比较重要的点是一致性协议。首先是Ceph的强一致性。在分布式系统中，一致性是指在多个副本之间保持数据一致。在RADOS中，数据被分割成多个对象，每个对象都有多个副本，这些副本分布在集群的不同节点上。当一个对象被修改时，Ceph会确保所有的副本都被同时更新，从而保证了强一致性。第二是Raft算法，他只需要大多数副本保证更新完成就可以认为成功了。
02 Curve架构及介绍
1. 项目介绍
关于Curve，我们的愿景是希望打造一款性能比较好，适用多种场景的，并且是围绕开源的云原生分布式存储系统。目前，Curve已经捐赠给CNCF基金会，并成为其生态系统中的一个项目。Curve提供块存储和文件存储两种方式，以满足不同应用的需求。
对于Curve块存储，它具有快照克隆恢复功能，主要应用场景包括OpenStack云主机和Kubernetes持久存储卷。对于共享需求，Curve提供文件存储；对于性能要求较高且无共享需求的场景，建议使用Curve块存储。
Curve还与阿里巴巴的PolarDB进行了联合，作为其底层存储运行。此外，Curve也在AI训练领域得到了广泛应用。Curve在过去几年中通过了信创认证，并获得了工信部组织的中国开源创新大赛二等奖。
2. Curve的架构介绍
Curve的整体架构是以硬盘为单位进行空间分配，每个硬盘被划分为多个segment，而每个segment又包含多个chunk。引入segment的概念是为了减少原数据的量。类似于Ceph中的一个硬盘对应一个节点，Curve中的一个硬盘对应一个服务组件，由一个磁盘进程进行管理。
Curve采用了Raft协议作为其一致性协议的选择。这是因为Curve项目的背景与我们在网易的实际业务需求有关。在网易的业务中，之前大部分业务使用的是Ceph。然而，在使用Ceph过程中，一旦用户更换硬盘或某个机器发生故障，会导致业务出现卡顿，这是业务方无法接受的。因此，这促使我们进行Curve的研发。基于这个背景，我们选择了Raft协议。
选择Raft协议的原因有两个方面：一是Raft协议具有较高的可用性，相对于Ceph的强一致性模型，在集群中出现一些问题时，可用性不会受到太大影响。另一个原因是Raft协议相对较容易理解。
在Curve的开发过程中，我们希望能够快速迭代，并避免重复开发组件。为了实现这一目标，我们选择了百度的Braft和brpc这两个被广泛认可为优秀的组件作为底层基础。我们在这两个组件的基础上也进行了一系列的开发工作。
03 Curve的主要亮点
Curve的主要亮点是以下四个方面：
下面将逐一展开介绍。
1. 高性能
Curve在随机读写方面表现优于Ceph。然而，我们也要承认目前存在一个问题：在大块顺序读写方面，Curve的性能差于于Ceph。我们正在进行后续的优化工作，以改进这方面的性能表现。
在性能方面，我们的目标是支持云原生数据库，因为云原生数据库对性能要求较高。除了支持阿里巴巴的PolarDB数据库，我们还支持网易内部的其他数据库。我们致力于提供高性能的存储解决方案，以满足不同数据库的需求。
在数据库方面，我们引入了SPDK（Storage Performance Development Kit）和RDMA（Remote Direct Memory Access）技术。这两种技术已经在2023年上半年上线。然而，在实施过程中，我们也面临了一些问题和挑战。以下是一些典型的例子：
RDMA对网络质量要求较高。当用户的网络质量较差时，可能会出现丢包或拥塞现象，而这对性能的影响明显高于TCP。为了解决这个问题，我们实现了网络链路的自动切换机制。当用户的网络质量较差时，系统会自动切换到TCP来应对这个问题。
在将NVMe绑定到SPDK后，它将没有盘符。然而，缺少盘符会导致线上监控失效。对于一个存储系统来说，缺乏监控是不可接受的。为了解决这个问题，我们利用SPDK提供的一系列脚本进行了内部适配，以确保监控的正常运行。这些问题和挑战是我们在引入SPDK和RDMA技术时所面临的，我们正在努力解决它们，以提供更稳定和可靠的存储解决方案。
第三个挑战是关于Brpc的RDMA支持。在当时，Brpc的RDMA功能并不完善。因此，我们对Brpc的RDMA进行了支持。由于RDMA支持是一个较为常见的技术，我们对Brpc的RDMA进行了文档介绍和代码方面的比较。如果您对此感兴趣，欢迎加入我们的微信群进行学习和交流。
第四个挑战是关于零拷贝技术。在引入SPDK后，我们希望引入零拷贝技术。然而，零拷贝技术在实施过程中有很多要求。因此，我们对这项技术进行了一些探索和研究。最终，我们成功实现了零拷贝技术，并且我们的技术和性能得到了显著提升。
在混合存储方面，我们利用了bcache来实现。为什么要采用混合存储呢？因为使用NVMe或者SSD可能会在性能和成本方面遇到一些瓶颈。因此，我们希望能够利用HDD作为数据盘，类似于Ceph中的HDD，而利用高性能存储设备来提升低速磁盘的IO性能。为了实现这一目标，我们采用了bcache技术。
bcache技术在我们的架构中起到了重要作用。在最初的设计中，我们使用了一个NVMe硬盘和几块数据盘。然而，如果NVMe硬盘发生故障，那么整个数据盘的数据都会丢失。为了解决这个问题，我们采用了raid技术，以提供冗余备份。此外，我们还对bcache进行了优化。在优化过程中，我们遇到了一些问题，例如发现bcache的writeback机制会失效，即使写入的数据量未达到阈值。最终，我们发现这是一个bug，并进行了修复。有关这个bug的详细记录可以在上面图片的链接中找到。
在处理bcache Gc的影响方面，我们也进行了一些工作。例如，我们采取了分离的策略，将WAL单独放置在NVMe设备中，而不放在bcache Gc的范围内。通过这样的方式，我们能够减少bcache Gc对系统性能的影响。
第三个问题也是非常重要的，尽管在最初的测试中可能不容易发现，但我们花了相当长的时间来定位它。我们发现在测试集群性能时，重复测试可能导致性能下降。最终的定位结果表明，这实际上是由于NVMe硬盘本身存在的问题。在持续写入的情况下，NVMe硬盘的性能可能会下降。这与硬盘的SAD和OP空间有关。通过适当设置OP空间，可以提升硬盘的性能。
此外，我们还了解到三星的企业级硬盘可能存在一些问题，例如固件支持方面。有关这方面的详细记录可以在下面图片的参考链接中找到。如果您对此感兴趣，欢迎参考相关文档。
在高性能方面，我们仍然有许多工作要做。正如之前提到的，我们的随机读写性能要比Ceph好得多，但在顺序读写方面则差于Ceph。因此，我们将重点优化顺序读写性能，这是我们后续工作的重点之一。
另一个重要工作是本地快照的支持。目前，我们的快照功能将快照上传到S3存储。然而，对于一些用户来说，他们对数据的安全性要求更高，可能没有使用S3存储。因此，我们非常关注本地快照的支持，以满足这些用户的需求(本地快照功能已经开发完成，预计Q4可release)。
还有其它一些计划，可以查看相关的road map以获取更多信息。
2. 易运维
Curve是一个易运维的存储系统。即使对于不熟悉Curve的人来说，根据我们的文档，只需要花费十几分钟的时间就能够将Curve部署起来。除了部署易用性方面，我们还支持在Kubernetes云原生环境中进行部署。我们提供了类似于Operator的解决方案，使得Curve的部署和运维更加简单。目前，我们已经支持了基本的部署易用性，例如Operator，但还有一些高级功能，如自动升级，尚未完全实现，我们将在后续继续努力。
3. 更稳定
Curve在稳定性方面具有显著优势。正如之前提到的，我们选择开发Curve的原因之一就是为了提高系统的稳定性，这也是我们从Ceph中获得的经验。此外，热升级也是Curve的一个亮点。关于热升级的详细信息，您可以在我们的文档中找到相关介绍。
在Curve的开发过程中，我们对质量要求非常高。我们进行了单元测试、集成测试以及各种其他类型的测试，以确保系统的稳定性和可靠性。我们注重测试的全面性和多样性，以确保Curve在各种异常场景下都能表现出色。
4. 高质量
对于Curve项目，当开发者提交一个PR时，会自动触发CI流程。CI流程包括单元测试、集成测试和系统测试等多个测试环节。只有当CI流程通过并且测试通过后，PR才会被合并入代码库。这样的流程确保了代码的质量和稳定性。
在技术架构的先进性方面，简要介绍两个关键点。首先是中心化节点，它充当集群的中心，可以感知集群的负载容量和异常情况，并进行资源调度和数据均衡。其次是文件池的chunkfilepool，它通过降低文件原数据的开销来提高性能，同时也支持快照功能。目前，我们使用的是快照S3，这使得用户可以方便地与S3或其他对象存储进行对接。
04 RoadMap
最后来分享一下后续的计划。
除了CurveBS，我们还有Curve FS作为另一个重点方向。Curve BS已经在网易进行了两三年的大规模线上运行，数据非常稳定，目前主要是在进行支持一些高级特性方面的工作。而Curve FS在2022年6月份完成了第一个release版本并上线。截至目前，Curve FS的开发时间只有大约一年左右，还有很多工作要做。特别是在AI时代，我们希望Curve能够在支持AI方面做得更好，这也是我们的一个亮点。当然，除了支持Ai，我们还在开发其他场景的支持，例如ES和传统的接口，如HDFS。
本文主要介绍了Curve BS，如果大家对于Curve FS有兴趣，也可以加入我们的微信群。我们的微信群是一个技术交流群，除了讨论Curve，还有其他技术话题。感谢大家的关注，本次分享就到这里。谢谢！
05 问答环节
Q：Curve写入代码性能比Ceph低吗？
A：在性能方面，Curve在随机写方面表现比Ceph要好很多，但在顺序写方面则差于Ceph。这主要是因为Ceph在过去使用了双写的机制，导致日志和数据都需要写入两次。为了解决这个问题，Ceph后来采用了BlueStore引擎，使得大块写入时只需写入数据一次，从而减少了原数据的写入量。然而，Curve目前仍然存在日志和数据写入两份的问题，因为它使用了Raft机制。这导致了带宽的利用率不高，性能相对于Ceph较差。因此，我们的重点之一是优化Curve的顺序写性能，特别是在KBS（Kernel Block Service）方面。我们目前正在进行这方面的工作。
Q：我了解Curve，请提供CurveFS和CurveBS他们之间的区别和联系？
A：Curve FS是一个文件系统，而Curve BS是一个块存储系统。与Ceph相比，Curve有一个有趣的特点是Curve FS和Curve BS可以进行联动。这意味着Curve FS的数据既可以存储在S3中，也可以存储在Curve BS中。这是与Ceph相比的一个亮点。通过这种联动，我们可以根据性能需求直接对接Curve BS，或者根据成本需求直接对接S3。这是我们的一个亮点，为用户提供了更大的灵活性和选择性。
Q：SPD跟RDMA什么时候开源？
A：关于SPDK和RDMA，我们在GitHub上已经有一个版本可用。在上半年，我们在这方面进行了大量的工作，并且在不久前进行了上线。目前，我们正在整理相关的源代码和其他资料。预计在第四季度我们将完成整理工作并达到一个稳定的状态。
Q：Curve如何对接K8S?在这一方面做了一些什么事情？
A：Curve有一个重要亮点是易运维，我们开发了CurveAdm工具。CurveAdm工具通过容器化技术实现了部署和易运维的功能，这只是其中的一小部分。此外，我们还支持与云原生环境结合，我们已经通过Operator实现了这一功能。
GitHub：https://github.com/opencurve/curve
官网：https://opencurve.io/
用户论坛：https://ask.opencurve.io/
微信群：搜索群助手微信号 OpenCurve_bot