云盘为云服务器提供高可用、高可靠、持久化的数据块级随机存储,其性能和数据可靠性尤为重要。UCloud 根据以往的运营经验,在过去一年里重新设计了云盘的底层架构,在提升普通云盘性能的同时,完成了对 NVME 高性能存储的支持。本文从 IO 路径优化、元数据分片、支持 NVME 等技术维度着手,详细讲解了 UCloud 云硬盘的架构升级和性能提升策略。
IO 路径优化
过去,IO 读写需要经过三层架构,请求首先通过网络,访问 proxy 代理服务器(proxy 主要负责 IO 的路由获取、缓存、读写转发以及 IO 写操作的三份复制),最后到达后端存储节点。老的架构里,每一次读 / 写 IO 都需要经过 2 次网络转发操作。
为了降低延时,优化后的方案将 proxy 负责的功能拆分,定义由 client 负责 IO 的路由获取、缓存,以及将 IO 的读写发送到主 chunk 当中,由主 chunk 负责 IO 写的三份复制。架构升级之后,IO 的读写只需经过两层架构,尤其对于读 IO 而言,一次网络请求可直达后端存储节点,其时延平均可降低 0.2-1ms。
元数据分片
分布式存储会将数据进行分片,从而将每个分片按多副本打散存储于集群中。老架构中,UCloud 支持的分片大小是 1G。但是,在特殊场景下(如业务 IO 热点局限在较小范围内),1G 分片会使普通 SATA 磁盘的性能非常差,并且在 SSD 云盘中,也不能均匀的将 IO 流量打撒到各个存储节点上。所以新架构中,UCloud 将元数据分片调小,支持 1M 大小的数据分片。
分片过小时,需要同时分配或挂载的元数据量会非常大,容易超时并导致部分请求失败。这是由于元数据采用的是预分配和挂载,申请云盘时系统直接分配所有元数据并全部 load 到内存。
例如,同时申请 100 块 300G 的云盘,如果按 1G 分片,需要同时分配 3W 条元数据;如果按照 1M 分片,则需要同时分配 3000W 条元数据。
为了解决性能瓶颈,团队采用放弃路由由中心元数据节点分配的方式。该方案中,Client 端和集群后端采用同样的计算规则 R(分片大小、pg 个数、映射方法、冲突规则);云盘申请时,元数据节点利用计算规则四元组判断容量是否满足;云盘挂载时,从元数据节点获取计算规则四元组; IO 时,按计算规则 R(分片大小、pg 个数、映射方法、冲突规则)计算出路路由元数据然后直接进行 IO。通过这种改造方案,可以确保在 1M 数据分片的情况下,元数据的分配和挂载畅通无阻,并节省 IO 路径上的消耗。
对 NVME 高性能存储的支持
NVME 充分利用 PCI-E 通道的低延时以及并行性极大的提升 NAND 固态硬盘的读写性能和降低时延,其性能百倍于 HDD。目前常用的基于 NAND 的固态硬盘可支持超 10W 的写 IOPS、40-60W 的读 IOPS 以及 1GB-3GB 读写带宽,为支持 NVME,软件上需要配套的优化设计。
首先,传统架构采用单线程传输,单个线程写 IOPS 达 6W,读 IOPS 达 8W,难以支持后端 NVME 硬盘几十万的 IOPS 以及 1-2GB 的带宽。为了利用 NVME 磁盘的性能,需要将单线程传输改为多线程传输,系统定期上报线程 CPU 以及磁盘负载状态,当满足某线程持续繁忙、而有线程持续空闲情况时,可将选取部分磁盘分片的 IO 切换至空闲线程,目前 5 个线程可以完全发挥 NVME 的能力。
此外,在架构优化上,除了减少 IO 路径层级以及更小分片外,UCloud 在 IO 路径上使用内存池、对象池,减少不停的 new delete,同时尽量用数组索引,减少查询消耗,并避免字符串比较以及无谓的拷贝,最终充分地发挥 NVME 磁盘性能。
UCloud 将于 11 月 16 日在上海举办 UCloud Tech Talk。更多信息请访问: https://www.bagevent.com/event/2007613
作者简介
彭晶鑫,现任 UCloud 块存储研发部负责人。曾负责百度移动云应用服务后端多项研发工作。目前就职于 UCloud,负责分布式块存储,分布式 CDP 系统, 分布式文件存储的研发和运营工作,对服务后端技术、存储技术,高性能服务有相当丰富的研发经验。
评论 2 条评论