Curve 替换 Ceph 在网易云音乐的实践

Curve 块存储已在生产环境上线使用近三年，经受住了各种异常和极端场景的考验，性能和稳定性均超出核心业务需求预期

网易云音乐背景

网易云音乐是中国领先的在线音乐平台之一，为音乐爱好者提供互动的内容社区。网易云音乐打造了一个大型、富有活力且坚固、快速成长的业态，为用户提供以社区为中心的在线音乐服务及社交娱乐服务。其标志性重点产品包括 “网易云音乐” 及附属的社交娱乐产品，如 “LOOK 直播”、“声波” 及 “音街”，通过科技驱动的工具让音乐爱好者自主发掘、享受、分享并创作不同的音乐和音乐衍生内容，并与他人互动。

云音乐云盘业务背景

云音乐使用云盘的业务主要包括主站、UGC、曲库等 Java 应用，其中主站是云音乐核心业务，需要提供最高等级的 SLA 保障（年可用率 >=99.99%），面对提供上亿级用户量稳定的云音乐体验，这一直以来也是我们的重难点。2019 年之前云音乐主要使用 Ceph 云盘，众所周知，Ceph 在大规模场景下存在性能缺陷，且很难保证我们在各种异常 (坏盘慢盘、存储机宕机、存储网络拥塞等) 场景下云盘 IO 响应时延不受影响；Ceph 云盘的 IO 抖动问题，我们曾尝试花很多人力精力做优化改造，但都只是稍微有所缓解，无法彻底解决；性能问题也投入大量人力进行分析优化，但仍然不能达到预期，因此我们才立项了解 Curve 块存储分布式存储系统。

Curve 块存储介绍

Curve 块存储可以良好适配主流云计算平台，并且具备高性能、易运维、稳定不抖动等优势。我们在实际应用中，使用 Curve 块存储对接 Cinder 作为云主机云盘存储后端，对接 Nova 作为云主机系统盘，对接 Glance 作为镜像存储后端。在创建云主机过程中，Nova 会通过 Curve 块存储提供的 Python SDK 克隆出新卷作为云主机系统盘使用。在创建云盘过程中，Cinder 会通过 Python SDK 创建空卷或者通过已有的卷快照克隆出新卷，之后可以挂载到云主机上作为云盘使用。云主机使用 Libvirt 作为虚拟化管控服务，使用 QEMU/KVM 作为虚拟化引擎。Curve 块存储为 Libvirt/QEMU 提供了驱动库，编译后就可以直接使用 Curve 卷作为远端存储，不需要把 Curve 块存储卷挂载到本地。

为什么选择 Curve

1. 业务侧

i. 根据我们云音乐应用场景，Ceph 云盘主要存在二大痛点：

性能差：由于单卷性能差（主要是 IO 时延高，IOPS 上不去，并且容易受到集群内其他高负载卷的影响），因此只能用于系统盘，或者作为云盘供应用打印日志，无法支撑中间件业务使用。

IO 抖动：经过我们观察发现 IO 时延超出 2s 就可能会导致磁盘 util 100%，业务就会大面积告警，请求堆积，严重情况下会引发雪崩效应；根据前 2 年的观察，Ceph 云盘 IO 抖动的非常频繁（基本每月都有），抖动时长也达分钟级，因此有很多核心应用都切换到了本地存储来规避类似问题。

ii. Curve 云盘优势：

抖动：自从使用 Curve 云盘后，磁盘 IO util 监控再也没有出现过因分布式存储系统导致的 100% 告警，业务运行的稳定性得到极大提升，核心业务也逐步迁回了 Curve 云盘（毕竟云盘的高空间利用率、可靠性、可迁移性、快速恢复能力也是业务非常看重的）。

性能：同等硬件下，Curve 单卷性能是 Ceph 卷的 2 倍 +，时延也大大低于 Ceph，具体性能对比可以参考下图：

2. 运维侧

i. 根据我们云音乐运维场景，Ceph 的痛点主要有如下：

服务升级：常见的需要升级客户端的场景包括 bug 修复、新功能增强以及版本升级这几个方面，我们遇到过一个 Ceph 社区消息模块 32 位序号溢出的 bug，该 bug 会在长期运行的客户端出现，造成 IO hang，客户端和服务端都需要更新版本才能解决。更新客户端的时候有两种选择，一是重启云主机的 QEMU 进程，二是对云主机执行热迁移操作 live migration，这两个操作在少量云主机场景下可行性比较高，但如果对成百上千台云主机进行类似操作，显然可操作性非常低，业务显然无法接受。另外服务端升级在重启 OSD 进程时也会造成一定的 IO 抖动，需要在业务低峰期操作，并且需要业务临时关闭磁盘 util 告警。

性能：运维人员主要关注存储集群整体性能，若集群总容量和总性能不匹配，容易导致容量充足的情况下性能却不足的问题，要么少创建卷导致容量浪费，要么继续创建卷但是会影响单卷的 IO 时延和吞吐，另外 Ceph 集群卷数量到达一定规模后，随着卷数量的增加，其集群整体性能也是逐渐下降的，这就导致单卷的性能受到更大的影响。

算法：受限于 CRUSH 算法限制，Ceph 的 OSD 之间数据分布非常不均衡，空间浪费严重，据我们观察，最高和最低的 OSD 空间使用率差值可以达到 50%，经常需要进行数据均衡操作，但在数据均衡过程中会产生大量的数据迁移操作，导致 IO 抖动，另外数据均衡也不能完美的解决 OSD 容量使用不均衡问题。

IO 抖动：坏盘换盘，节点宕机，高 IO 负载，扩容（不新增 pool，新增太多 pool 会导致 OpenStack 维护变复杂）数据均衡，网卡丢包，慢盘等等。

ii. 相对来说 Curve 在上述几个方面具备显著优势：

服务升级：客户端支持热升级，操作过程中 QEMU 进程不需要重启，也不需要迁移，毫秒级影响对云主机内业务几乎无感，热升级相关架构设计可以参考①。Curve 服务端升级时，得益于 quorum 机制的一致性协议 raft，只要做到按副本域升级，就可以保证对业务 IO 的影响在秒级，IO 时延不超过 2s 就不会导致 util 100%。

性能：Curve 集群可以在同等容量规模下，创建更多的卷，并且保持稳定的性能输出。

算法：Curve 数据分配由中心化的 MDS 服务进行，可以保证非常高的均衡性，最高和最低的 chunkserver 空间利用率偏差不超过 10%，也就不需要做数据均衡操作。

IO 抖动：Ceph 云盘容易发生 IO 抖动的场景下，Curve 云盘表现更稳定，Curve VS Ceph 具体如下图：

使用 Curve 落地成果

Curve 块存储已在生产环境上线使用近三年，经受住了各种异常和极端场景的考验，性能和稳定性均超出核心业务需求预期，常见故障场景下未产生明显 IO 抖动，服务端及客户端版本升级也未影响业务正常运行，这充分证明我们当时的选择是正确的，另外还要感谢 Curve 团队的同学在我们使用的过程中给予的帮助。目前：云音乐使用 Curve 块存储作为云主机的云盘和系统盘，其中系统盘通常为固定容量 40GB 或 60GB 两种规格，云盘容量最小 50GB，最大支持 4TB（此为软性限制，Curve 云盘实际支持创建 PB 级卷）。

后续规划

结合 Curve 块存储方面：

探索基于 Curve 块存储的云原生中间件场景，例如将改造后的 Redis、Kafka、消息队列等服务运行在 Curve 块存储卷上，减少故障切换时间。

上线基于 CurveBS+PolarFS+MySQL 的云原生数据库。

其他存量使用 Ceph 云盘、本地存储的云主机切换到 Curve 块存储卷。

目前 Curve 团队也在全力开发共享文件存储服务，网易内部基于 OpenStack 的私有云 2.0 平台已经逐渐演进到基于 Kubernetes 的 3.0 平台，业务对于 ReadWriteMany 的类型的 PVC 卷的需求已经越来越迫切，Curve 团队开发了 Curve 分布式共享文件系统，该系统支持将数据存储到 Curve 块存储后端或者兼容 S3 协议的对象存储服务，后续也将尽快上线使用。

参考：

① https://github.com/opencurve/...

GitHub：https://github.com/opencurve/...

微信群：请搜索添加或搜索群助手微信号 OpenCurve_bot