标签：网易 云盘 Curve 存储 Ceph IO 主机

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

 

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

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

标签：网易,云盘,Curve,存储,Ceph,IO,主机
来源： https://www.cnblogs.com/163yun/p/16419955.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。