高带宽低延时远程flash访问架构

SSDFans 2023-10-20 06:33

TI MCU方案：电动汽车实时控制 【TI资料】基于新型C29内核的MCU技术资料

ReFlex - Remote Flash ≈ Local Flash

一种提供高带宽低延时和多租户场景下可保证的服务质量的远程flash访问架构

一、背景

对NVMe Flash的远程访问实现了数据中心内Flash容量以及IOPS的灵活扩展和高利用率。但是，现有的用于远程Flash访问的系统会带来巨大的性能开销，或者无法隔离共享每个Flash设备的多个远程clients。

二、问题与挑战

在实现对Flash的远程访问方面存在重大挑战。

要实现低延迟，需要在server和client的网络和存储层上将处理开销降至最低。除了低延迟之外，每台服务器还必须以最低成本实现高吞吐量，从而使一个或多个NVMe Flash设备且具有少量CPU cores的机器达到饱和。此外，要管理共享一个Flash设备的多个租户之间的干扰以及Flash设备的不均匀读写行为，需要一种隔离机制，以保证所有租户的可预测性能。最后，在共享程度，部署规模和用于远程连接的网络协议方面需要具有灵活性。现有的仅软件用于远程Flash访问的选项（例如iSCSI或基于事件的服务器）无法达到性能预期。最近提出的硬件加速选件，例如基于RDMA架构的NVMe，缺乏性能隔离，并且部署灵活性有限。

由于读、写干扰的影响，可预测的性能对于NVMe Flash设备是一个挑战。图1绘制了Flash上的尾部读取延迟（第95个百分位数）与各种读写比率的工作负载的吞吐量（IOPS）的关系。尾部读取延迟取决于吞吐量（负载）和读写比率。对于我们测试过的所有NVMe Flash设备，此行为都是典型的，因为写入操作速度较慢，并且触发磨损平衡和垃圾回收活动，这些活动无法始终被隐藏。当单个应用程序使用本地Flash设备时，可以管理读/写干扰，但是对于远程Flash和共享同一设备但彼此不知道的多个租户而言，这成为一个巨大的挑战。

三、ReFlex设计

1.数据平面架构

ReFlex紧密集成了网络和存储层，提供了对远程Flash的低延迟和高吞吐量访问。它通过TCP和UDP等通用网络协议为任意大小的逻辑块提供远程读/写请求。ReFlex主要是软件系统，它利用NIC和NVMe Flash设备中的硬件虚拟化功能直接在硬件队列上运行，并有效地在NIC和Flash设备之间转发请求和数据，而无需拷贝。

每个ReFlex服务器线程使用专用core，可以直接和排它地访问网络队列对以进行数据包的接收/发送，并使用NVMe队列进行Flash命令的提交/完成。

图2展示了ReFlex服务器线程的执行模型，该线程处理传入的Flash读/写请求。首先，NIC接收网络数据包，然后通过DMA将其传送到网络栈提供的预分配的内存缓冲区（1）。ReFlex线程轮询接收描述符环，并通过以太网驱动程序和网络栈（例如TCP/IP）处理数据包，从而生成事件条件，指示新消息的可用性（2）。同一线程使用libix（类似于Linux libevent的库）来处理事件。这涉及切换到服务器代码，以解析消息，提取IO请求，执行访问控制检查以及提交Flash read/write系统调用之前所需的任何其他存储协议的处理（3）。然后，线程切换到系统调用处理并执行IO调度，以在共享ReFlex服务器的所有租户之间实施SLO。调度之后，请求将通过NVMe提交队列提交给Flash设备（4）。Flash设备执行读/写IO，并通过DMA将数据传送到预分配的用户空间缓冲区（或从预分配的用户空间缓冲区获取数据）（7）。线程轮询完成队列（5），并提供完成事件（6）。事件回调通过libix执行并发出send系统调用（7）。最后，线程处理send系统调用，以通过网络栈将请求的数据传递回发起方（8）。执行模型支持每条网络消息多个IO请求以及跨多个网络消息的大型IO。

2.调度机制

QoS调度程序允许ReFlex为共享服务器中Flash设备的租户提供性能保证。租户是一种逻辑抽象，用于说明和执行服务级别目标（SLO）。SLO在特定吞吐量和读/写比率下指定尾部读取延迟的限制。例如，租户可以以80％的读取比率注册具有200us读取尾部延迟（95％百分数）的50K IOPS的SLO。除了此类延迟关键（LC）租户，这些租户在尾部延迟和吞吐量方面保证了分配，ReFlex还为尽力而为（BE）租户提供服务，这些租户可以机会使用任何未分配或未使用的Flash带宽并容忍较高的延迟。租户定义可以由成千上万的网络连接共享，这些连接来自运行任何应用程序的不同客户端计算机。应用程序可以使用多个租户为不同的数据流请求单独的SLO。

在Flash设备访问上强制执行SLO有两个因素。首先，设备可以支持的最大带宽（IOPS）取决于它在所有租户中看到的请求的总体读写比率。其次，读取请求的尾部等待时间取决于总体读取/写入比率和当前带宽负载。因此，QoS调度程序需要全局可见性和对Flash上的总负载以及未完成的IO操作类型的控制。我们使用请求代价模型来说明每个Flash IO对读取尾部延迟的影响，并使用一种新颖的调度算法来保证所有租户和所有数据平面线程之间的SLO。

1) 请求代价模型

针对ReFlex服务器中部署的每种类型的Flash设备校准成本模型。首先，对于具有各种读写比率和请求大小的工作负载，我们使用本地Flash测量了尾部等待时间与吞吐量的关系（请参见图1中的4KB示例）。由于写入请求的成本取决于垃圾回收和页面擦除事件的频率，因此我们保守地使用随机写入模式来触发最坏的情况。接下来，我们使用曲线拟合来得出C（I / O type，r）

2) 调度算法

QoS调度器构建在成本模型之上，保持延迟关键租户的尾端延迟和吞吐量的SLO，同时允许尽力交付型租户以公平的方式利用剩余的吞吐量。

token管理

QoS调度器以等于Flash设备在给定尾端延迟SLO上可以支持的最大加权IOPS（上述的成本模型）的速率生成token。ReFlex在所有共享一个Flash设备的延迟关键租户中执行最严格的延迟SLO。在它们的SLO指示的读写比加权情况下，延迟关键(LC)租户被提供能够满足它们IOPS SLO的token供应。由调度程序生成但未分配给延迟关键的token将在尽力交付型租户之间公平分配。当调度程序将租户的请求提交到Flash设备时，它会根据每个请求的成本来花费租户的token。

每个ReFlex线程将Flash请求排入每个租户的软件队列中。当线程到达数据平面执行模型中的QoS调度步骤时，线程使用计算排队请求的加权成本，并将所有允许的请求提交给Flash设备，从而逐渐花费每个租户的token。根据线程负载和批处理因子，执行模型每0.5us至100us进入一次调度回合。通过对控制平面和批处理大小限制确保调度程序调用之间的时间不超过最严格SLO的5%。必须进行频繁的调度，以避免过多的排队延迟并保持NVMe设备的高利用率。

其次，ReFlex采用自适应批处理请求，以分摊开销并提高预取和指令缓存效率。在低负载下，将立即处理传入数据包或已完成的NVMe命令。随着负载的增加，NIC接收和NVMe完成队列将填满，并为批量处理多个传入数据包或多个完成的访问提供了机会。批大小随负载增加而增加，但上限为64，以避免过多的延迟。不同于传统的批处理，后者需要在带宽和延迟之间进行权衡，自适应批处理在高吞吐量和低延迟之间实现了良好的平衡。