关于云原生:Curve-替换-Ceph-在网易云音乐的实践

39次阅读

共计 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

  1. 业务侧

i. 依据咱们云音乐利用场景,Ceph 云盘次要存在二大痛点:

性能差:因为单卷性能差(次要是 IO 时延高,IOPS 上不去,并且容易受到集群内其余高负载卷的影响),因而只能用于系统盘,或者作为云盘供给用打印日志,无奈撑持中间件业务应用。

IO 抖动:通过咱们察看发现 IO 时延超出 2s 就可能会导致磁盘 util 100%,业务就会大面积告警,申请沉积,重大状况下会引发雪崩效应;依据前 2 年的察看,Ceph 云盘 IO 抖动的十分频繁(根本每月都有),抖动时长也达分钟级,因而有很多外围利用都切换到了本地存储来躲避相似问题。

ii. Curve 云盘劣势:

抖动:自从应用 Curve 云盘后,磁盘 IO util 监控再也没有呈现过因分布式存储系统导致的 100% 告警,业务运行的稳定性失去极大晋升,外围业务也逐渐迁回了 Curve 云盘(毕竟云盘的高空间利用率、可靠性、可迁移性、疾速恢复能力也是业务十分看重的)。

性能:等同硬件下,Curve 单卷性能是 Ceph 卷的 2 倍 +,时延也大大低于 Ceph,具体性能比照能够参考下图:

  1. 运维侧

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

正文完
 0