13倍性能，3倍稳定性提升！UCloud云硬盘做了这些事-ucloud云怎么样

近期，我们推出高性能SSD云盘，满足用户对高性能的场景需求。SSD云盘相比普通云盘，IOPS提升了13倍，稳定性提升了3倍，平均时延降低了10倍。为了做到这些，我们从去年10月份开始对云盘的架构进行了重新设计，充分减少时延和提升IO能力;并通过复用部分架构和软件，提供性能更好、更稳定的普通云盘;同时逐步引入Stack/Kernel Bypass技术，打造下一代超高性能存储。新架构推出后，已服务了现网用户的3400多个云盘实例，总存储容量达800TB，集群每秒IOPS均值31万。

架构升级要点

通过对现阶段问题和需求的分析，我们整理了这次架构升级的具体要点：

1、解决原有软件架构不能充分发挥硬件能力的局限;

2、支持SSD云盘，提供QOS保证，充分发挥后端NVME物理盘的IOPS和带宽性能，单个云盘IOPS可达2.4W;

3、支持更大容量云盘，32T甚至更大;

4、充分降低IO流量的热点问题;

5、支持并发创建几千块云盘，支持并发挂载几千块云盘;

6、支持老架构云盘在线向新架构迁移，支持普通云盘在线迁移至SSD云盘。

新架构改造实践

改造一：IO路径优化

老架构中，整个IO路径有三大层，第一层宿主Client侧，第二层Proxy侧，第三层存储Chunk层。Proxy负责IO的路由获取以及缓存;IO的读写转发到下一层存储层，负责IO写三份复制。

而新架构中，路由获取交给了Client，IO读写Client可直接访问存储Chunk层，写三份复制也交给了Chunk。整个IO路径变成了2层，一层是宿主Client侧, 另一层存储Chunk层。

架构升级之后，对读IO，一次网络请求直达到后端存储节点，老架构都是2次。对写IO，主副本IO一次网络请求直达后端存储节点，另外2副本经过主副本，经历两次网络转发，而老架构三个副本均为两次。读IO时延平均降低0.2-1ms，写尾部时延减低，也有效的降低总体时延。

改造二：元数据分片

分布式存储中，会将数据进行分片，从而将每个分片按多副本打散存储于集群中。如下图，一个200G的云盘，如果分片大小是1G，则有200个分片。老架构中，分片大小是1G，在实际业务过程中我们发现，部分业务的IO热点集中在较小范围内，如果采用1G分片，普通SATA磁盘性能会很差。并且在SSD云盘中，也不能均匀的将IO流量打散到各个存储节点上。

新架构中，我们支持了1M大小的分片。1M分片，可以充分使用整个集群的能力。高性能存储中，因为固态硬盘性能较好，业务IO热点集中在较小范围内，也能获得较好的性能。

但UCloud元数据采用的是预分配和挂载方案，申请云盘时系统直接分配所有元数据并全部加载到内存。分片过小时，需要同时分配或挂载的元数据量会非常大，容易超时并导致部分请求失败。

例如，同时申请100块300G的云盘，如果按1G分片，需要同时分配3W条元数据;如果按照1M分片，则需要同时分配3000W条元数据。

为了解决分片变小导致的元数据分配/挂载失败问题，我们尝试改变IO时的分配策略，即云盘挂载时，将已分配的元数据加载到内存中。IO时，如果IO范围命中已经分配路由，则按内存中的路由进行IO;如果IO范围命中未分配路由，则实时向元数据模块请求分配路由，并将路由存储在内存中。

按IO时分配，如果同时申请100块300G的云盘, 同时挂载、同时触发IO，大约会产生1000 IOPS，偏随机。最坏情况会触发1000* 100 = 10W 元数据分配。在IO路径上，还是存在较大消耗。

最终，新架构中我们放弃了中心节点存储分片元数据的方案，采用了以一套统一规则去计算获取路由的方案。

该方案中，Client 端和集群后端采用同样的计算规则R(分片大小、pg个数、映射方法、冲突规则);云盘申请时，元数据节点利用计算规则四元组判断容量是否满足;云盘挂载时，从元数据节点获取计算规则四元组; IO时，按计算规则R(分片大小、pg个数、映射方法、冲突规则)计算出路路由元数据然后直接进行IO。通过这种改造方案，可以确保在1M数据分片的情况下，元数据的分配和挂载畅通无阻，并节省IO路径上的消耗。

改造三：支持SSD高性能云盘

通过上述对比可以看到，NVME固态硬盘性能百倍于机械盘，但需要软件的配套设计，才能利用NVME固态硬盘的能力。

SSD云盘提供QoS保证，单盘IOPS：min{1200+30*容量，24000} 对于SSD云盘，传统的单线程模式会是瓶颈，难以支持后端NVME硬盘几十万的IOPS以及1-2GB的带宽，所以我们采用了多线程模型。

为了较快推出SSD云盘，我们还是采用了传统TCP网络编程模型，未使用KernelBypass。同时，通过一些软件细节的优化，来减少CPU消耗。

目前，单个线程写可达6WIOPS，读可达8W IOPS，5个线程可以基本利用NVME固态硬盘的能力。目前我们能提供云盘IO能力如下：

改造四：防过载能力

对于普通云盘，新架构的软件不再是瓶颈，但一般的机械硬盘而言，队列并发大小只能支持到32-128左右。100块云盘，持续同时各有几个IO命中一块物理HDD磁盘时，因为HDD硬盘队列并发布较小，会出现较多的io_submit耗时久或者失败等问题。Client侧判断IO超时后，会重试IO发送，造成Chunk端TCP缓冲区积压越来越多的IO包，越来越多的超时积压在一起，最终导致系统过载。

对于普通云盘，需控制并发提交队列大小，按队列大小，依次遍历所有云盘，下发各云盘的IO，如上图的1、2、3。实际代码逻辑里，还需要考虑云盘大小的权重。

对于SSD云盘来说，传统的单个线程会是瓶颈，难以支持几十万的IOPS以及1-2GB的带宽。

压测中，我们模拟了热点集中在某个线程上的场景，发现该线程CPU基本处于99%-100%满载状态，而其它线程则处于空闲状态。后来，我们采用定期上报线程CPU以及磁盘负载状态的方式，当满足某线程持续繁忙而有线程持续空闲时，选取部分磁盘分片的IO切换至空闲线程，来规避部分线程过载。

改造五：在线迁移

老架构普通云盘性能较差，部分普通云盘用户业务发展较快，希望从普通云盘迁移至SSD云盘，满足更高的业务发展需要。目前线上存在2套老架构，为了快速达到在线迁移的目的，我们第一期决定从系统外围支持在线迁移。

迁移流程如下：

1、后端设置迁移标记;

2、Qemu连接重置到Trans Client;

3、写IO流经过Trans Client到Trans模块，Trans模块进行双写：一份写老架构，一份写新架构;

4、Trigger遍历磁盘, 按1M大小触发数据命令给Trans触发数据后台搬迁。未完成搬迁前，IO读经Trans向旧架构Proxy读取;

5、当全部搬迁完成后，Qemu连接重置到新架构Client，完成在线迁移。

加一层Trans及双写，使迁移期间存在一些性能损耗。但对于普通云盘，迁移期间可以接受。我们目前对于新架构也正在建设基于Journal的在线迁移能力，目标在迁移期间，性能影响控制在5%以下。

经过上述系列改造，新的云硬盘架构基本完成了最初的升级目标。目前，新架构已经正式上线并成功运用于日常业务当中。在这里，也谈谈我们正在研发的几项工作。

1、容量具备无限扩展能力

每个可用区，会存在多个存储集群Set. 每个Set可提供1PB左右的存储(我们并没有让集群无限扩容)。当Set1的云盘需要从1T扩容至32T 、100T时，可能会碰到Set1的容量不足的问题。

因此，我们计划将用户申请的逻辑盘，进行分Part, 每个Part可以申请再不用的Set中，从而具备容量可以无限扩展的能力。

2、超高性能存储

近10年，硬盘经过 HDD -> SATA SSD -> NVME SSD的发展。同时，网络接口也经历了10G -> 25G -> 100G的跨越式发展。然而CPU主频几乎没有较大发展，平均在2-3GHZ，我们使用的一台物理机可以挂6-8块NVME盘，意味着一台物理机可以提供300-500万的IOPS。

传统应用服务器软件模式下，基于TCP的Epoll Loop, 网卡的收发包，IO的读写要经过用户态、内核态多层拷贝和切换，并且需要靠内核的中断来唤醒，软件很难压榨出硬件的全部能力。例如在IOPS和时延上，只能靠叠加线程去增加IOPS，然而，IOPS很难随着线程的增加而线性增长，此外时延抖动也较高。