共享存储设备，如何实现差异化 IO 分配策略

关注

发布于: 23 小时前

随着 5G、大数据、区块链、物联网以及人工智能等技术在各行业不断渗透，企业对于数据存储及实时处理的需求日益提高，现代数据中心的规模也随着应用服务需求的增长而越来越大，简单通过采购更多服务器扩展集群会引起更高的运营成本与电力消耗，而且数据中心资源利用率低、利用率不够弹性已逐步成为云计算进一步发展的制约因素。为了降低采购成本，目前业务厂商比较行之有效的方式是通过业务混部来提升硬件（CPU 和存储）资源利用率。这就需要 NVMe SSD 存储设备具备像多命名空间和加权轮询技术，实现在共享存储设备资源时，根据业务的优先级，提供差异化 IO 分配策略。

集群负载和业务混部

现代数据中心集群的负载可以简单分为两类，一类是延时敏感的在线服务，一旦服务崩溃或者延时过大，将导致用户体验不佳，需要留有较多的资源余量以应对突发的请求高峰；另一类是离线批处理作业，虽然资源消耗较大，但是对延时相对不敏感，可以容忍一定范围内执行时间的调整。

因此业务厂商利用在线服务与离线服务批处理作业的差异性，将二者混合部署在同一个生产集群，这就可能出现在同一台物理机上，不仅有在线业务之间的混部，也有离线业务之间的混部，以及在线和离线业务的混部。这就需要对两种负载实现差异化资源分配，在保证 QoS（Quality of Service，服务质量）的基础上提高资源利用率。

处理 IO 的两种仲裁机制

主机接口负责主机与 SSD 之间的通信和数据传输，接受和解析 I/O 请求，维护一条或者多条请求队列（Submission Queue，SQ）。主机和 SSD 通信时，通常会建立多条队列，每个队列里又可以建立多个请求。有序的处理这些请求通常有两种仲裁方式，一种是轮询算法（Round Robin），一种是加权轮询算法（Weighted Round Robin，简称 WRR）。

如果 NVMe SSD 采用了轮询算法（Round Robin），即所有命令队列（包括管理队列 Admin Submission Queue，ASQ）按照相同优先级轮询。

但面对在线和离线业务这种混部场景，不同性能需求的应用程序共享存储设备，需要对不同业务 IO 处理分出轻重缓急。这就需要 SSD 支持加权轮询算法，根据应用的不同优先级提供差异化 IO 分配策略。

企业级 SSD 支持加权轮询算法

支持加权轮询算法的企业级 NVMe SSD，队列分成 3 类严格优先级，优先级从高到低依次为管理 Admin 类、紧急 Urgent 类和优先级 Priority 类。创建和删除 IO 队列、获取 SSD 的 log 数据、固件升级等管理命令都是通过管理命令队列提交，其优先级也最高（严格优先级 1）。紧急队列优先级低于管理队列，处于第二阶梯（严格优先级 2）。处于第三级（严格优先级 3）的 IO 队列又被划分 3 种不同权重优先级，包括高 High、中 Medium、低 Low，这也是本文讨论的重点。有了这个权重等级，SSD 就可以根据主机端设置及分配的 IO 命令优先级，依次完成对每个队列命令的处理，实现对上层应用优先级的处理及反馈。

主机端队列优先级

主机内存中包括两个命令队列，Submission Queue （SQ）和 Completion Queue（CQ）。主机通过 SQ 告知 SSD 的控制器要处理的命令，控制器通过 CQ 告知主机已经被处理完毕的命令以及这些命令执行的状态。如果要使用 NVMe SSD 的加权轮询功能，需要端到端支持，也就是从 NVMe SSD 设备端到 Kernel 层面都需要支持加权轮询算法。一种常用方式是通过 SPDK 的软件栈，实现每个不同优先级 core 绑定 1 个 IO 队列(包含 1 个 SQ，1 个 CQ)。