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磁盘性能。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。