IOFlow: A Software-Defined Storage Architecture

摘要

在数据中心，IO路径存储很长也很复杂，IO路径存储中有许多层或不透明的接口。这使得实施端到端的政策非常难，端到端的政策暗示着IO流的性能和路由。端到端的政策需要IO不同的流路径和控制平台上全部可见。本文设计了IOFlow，这是一个使用了逻辑控制平台使得可以获得高级流的策略。IOFlow在数据层增加了一个抽象队列，将数据层暴露给了控制中心。控制者可以在每一个独立层传输政策进去该队列进行决策。控制者也可以选择多个层去实施该政策。

本文在操作系统2个关键的层次--管理程序中的驱动层和服务器层建立了队列和控制功能。IOFlow 不需要程序或者VM进行改变,这是可扩展性的一个关键。我们部署了40Gbps的网络和存储设备这样一个模型去进行一个小实验。同时建立一个控制程序，该程序允许广泛的支持多点流政策，这是在今天很难实现的。

1 介绍

近年来，在企业级数据中心2种趋势获得共识--物理服务器虚拟化和存储虚拟化。在物理服务器上的虚拟机呈现了一个虚拟磁盘。在共享存储服务器上虚拟磁盘是一个简单的大文件，该文件是能通过共享数据中心网络可以获取的。虽然这种趋势带来了降低成本、容易管理等优势，但是讽刺的是这也能导致增加了端到端的复杂度。从VM中的一个IO路径请求到存储后端是很复杂的，需要通过许多层。在每一层请求也许表示的不同。例如，文件IO请求像在VM中一次读、写、创建会形成在管理程序中的一个IO请求块。反过来，在以太网包中的IO块在存储服务器中通过该网络最后其他文件IO请求和块设备请求。

像这样的复杂意味着执行着端到端的政策是很难得。它需要沿着IO路径层去解决内容不同的请求。此外，该政策也许需要在每一层都执行。简单策略是管理一个点到点的IO流，即所有从一个端到到其他端点的IO。多点流政策甚至更难执行。

这篇文章提出了IOFlow,是一个在数据中心允许端到端策略的一个构架。该策略特别的处理从VM到共享存储的IO流。

流的命名是这样的{VM，操作，文件，共享}.例如一个用户有100个VM，执行的数据文件是“dataset A”,则该政策可以写成{VM 1-100,*,*,"dataset A"}.

IOFlow由3部分组成。

第一部分是一个逻辑控制中心发现数据平台层和维护一个层次数据中心拓扑图。

第二部分是数据平台队列允许对不同的IO请求进行不同处理。该部分暴露了一个简单的控制接口，该接口指定了低级的标识，使得能够用来指示请求到队列中去。该接口允许控制者创建队列、动态配置他们的服务器和路由属性。例如，通过配置一个特殊速率的队列到服务器，控制者可以确保IO流能到达。

第三部分，我们制定了一个简单的接口在控制器和控制程序，该程序可以构建到顶层。程序的翻译策略通过控制器进入特殊层配置散播。

对于IOFlow来说，控制器是全局可见的。这就允许控制应用程序去使用中心算法去翻译策略到配置段。

速度限制是很困难的，是由于IO操作和处理时间是IO类型的非线性函数，数据本地化，机器类型请求不同的关系。

我们在操作系统2个关键的层次--管理程序中的驱动层和服务器层建立了队列和控制功能，这允许我们可以执行未修改的应用和VM。我们也增加了控制到其他的可选择阶段：一个恶意软件扫描设备驱动，一个在VM上OS的客户文件系统，还有网络驱动。

2、范围和挑战

本文侧重于企业级数据中心管理。这样的数据中心组成了计算和存储服务器。计算服务器是虚拟的，主机虚拟机

每一个数据中心的使用者或租用者是分配了一个VM组，能够在VM中运行任意的应用。存储服务器扮演着前后端存储。存储通常是虚拟化的。即VM往往不知道连接结构和存储配置的细节。VM 提出了虚拟磁盘或者一个在存储服务器简单的大文件（VHD）。这种存储虚拟化简化了管理任务和对存储失败的处理。

计算和存储服务器是通过网络交换机进行连接的，网络交换机携带着VM和从VM到存储的存储流量之间的IP流量.

我们的设计能够容纳所有的这些。在本文中我们关注的仅仅是从VM到存储的IO请求。我们也叫上数据中心应经提供了适当的在存储服务器上的性能瓶颈：小的IO请求是典型是典型的中断限制--大的IO请求被存储后端带宽或者服务器网络连接所限制。

IOFlow的设计目标是小型的媒介数据中心。我们将扩展的工作放到未来来完成。

2.1政策示例

在企业级数据中一个关键的挑战是对于存储IO流执行管理政策。不像一个网络流指的是一个在2个端点间的传输连接，我们使用了术语“流”去定义所有的IO请求至一个单一的政策应用。所有流能够可以与一个或多个源端点和一个或多个目的端点。流端点使用了像VM名称是为了源和文件名、共享目的地名一样高级标示符命名。为了便于说明，下面我们使用了一个例子来表示流流政策的格式：{[Set of VMs],[Set of storage shares]}->Polocy.我们关注于这个指示了和流的路由的政策。这样的政策可以通过数据中心管理员指定，软件管理在数据中心或通过租用者自己。

政策P1，{VM p,Share X}->Bandwidth B.VM p运行一个SQL客户端，该客户端在共享存储X中获取SQL数据文件

为了确保好的查询性能，p是是要保证带宽，当B访问该共享存储时。

政策P2，{P,X}->Min bandwidth B.类似于政策1，但是当其他VM是空闲时，P是允许超过其他带宽保证的。

政策P3。{P，X}->Sanitizq.VM p 是IO必须通过处理层路由流量。

政策P4。{P,X}->High priority.VM p 允许一个SQL客户端，该客户端可以访问SQL日志文件在共享存储X中。为了确保低延迟对于日志的操作。p的存储过程在端到端的路径中需要高优先对待。

政策P5，{|p,q,r|,|X,Y|}->Bandwidth B.VMs p,q和r属于同一个租用者，当访问共享X、Y时，这样就能保证带宽B。

政策P1-P4指定点到点流的处理而P5适用于多点流。

2.2 挑战

我们使用上面的示例来强调为什么IO流政策是很难再今天的数据中心实施的。

差别对待。为了执行政策，沿着流路径的层次需要处理基于它们内容的不同的包。例如，考虑政策P1。从VMP遍历存储流。。为了执行这个政策，至少需要这些层需要能够去控制请求从VM p到共享X的速率。

流名称解析。流指定使用高层的名称，例如VM 和共享名称。然而，个别层也许不能识别这些名称，因此，他们也许不能归属于一个请求到这个流中。例如对于政策P1，从VM P任何的层去分析X都能够作为实施点，然后每层仅仅只有观察到相同低层次的标示符的请求然后遍历他们。共享X流的目的地也许作为一个文件系统出现在VN和OS的guest中，出现作为一个块设备的内部管理程序。因此，流名称需要去重新解析进入低级别的标示符，以此可以访问独立的层。

分布式执行。

动态执行。

控制许可。

总之，为了执行流政策，需要数据平台支持不同的传输和在控制平台上全局可见。这种可见性允许控制算法映射到底层标示符，来确定是否一个政策是可执行的，执行去哪，以及如何动态的改变执行规则。这个激励我们对基于控制设计，这正是我们接下来要描述的。

3、Design

IOFlow,是一个在数据中心允许端到端策略的一个构架，它能确保在多个客户数据中IO流政策可用。

IOFlow 需要沿着IP路径层去实现一个简单的控制接口与7个API调用。完成这些API的层次被称为“stages”

,一个逻辑控制中心使用了这些API去配置stages去使得本地决策可用使得端到端的策略可用使用。

Stages.图一显示了在一个典型的数据中心沿着IO栈的关键层次。这些的serve都可以看成stages.

在我们的原型中，我们实现了SMB客户端和SMB服务端（在存储服务器）。作为stages执行性能的政策。

SMB是一个分布式IO协议，它可以允许宇RDMA。我们还实现了网络驱动作为IOFlow stages.

每一个stage实现传输路径通过队列的不同。队列规则映射到单独的IO请求到队列中。stage的控制API显示与表2.这些API允许控制器去发现IO头部，和能够使用分配包到队列中去。（getQueueInfo）.此外，它还 允许控制器去创建队列规则（createQueueRule）和配置队列属性(configureQueueRouting). 队列有服务器属性，用来管理他们服务器的速度和路由属性，该路由属性决定着下一个stage。

Controller.控制器是一个逻辑控制中心发现数据平台层和维护一个层次数据中心拓扑图。它

它暴露了这种拓扑和独立的1111