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/curve/blob/master/docs/cn/nebd.md
-
微信群:请搜索添加或搜索群助手微信号 OpenCurve_bot