共计 3104 个字符，预计需要花费 8 分钟才能阅读完成。
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
- 业务侧
i. 依据咱们云音乐利用场景，Ceph 云盘次要存在二大痛点：
性能差：因为单卷性能差（次要是 IO 时延高，IOPS 上不去，并且容易受到集群内其余高负载卷的影响），因而只能用于系统盘，或者作为云盘供给用打印日志，无奈撑持中间件业务应用。
IO 抖动：通过咱们察看发现 IO 时延超出 2s 就可能会导致磁盘 util 100%，业务就会大面积告警，申请沉积，重大状况下会引发雪崩效应；依据前 2 年的察看，Ceph 云盘 IO 抖动的十分频繁（根本每月都有），抖动时长也达分钟级，因而有很多外围利用都切换到了本地存储来躲避相似问题。
ii. Curve 云盘劣势：
抖动：自从应用 Curve 云盘后，磁盘 IO util 监控再也没有呈现过因分布式存储系统导致的 100% 告警，业务运行的稳定性失去极大晋升，外围业务也逐渐迁回了 Curve 云盘（毕竟云盘的高空间利用率、可靠性、可迁移性、疾速恢复能力也是业务十分看重的）。
性能：等同硬件下，Curve 单卷性能是 Ceph 卷的 2 倍 +，时延也大大低于 Ceph，具体性能比照能够参考下图：
- 运维侧
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
