CN1790413A

CN1790413A - 用于管理数据移植的方法和***

Info

Publication number: CN1790413A
Application number: CNA2005101246601A
Authority: CN
Inventors: 克斯图维·达斯古普塔; 罗赫特·杰安; 尤彭德拉·沙玛; 阿克斯哈特·沃玛
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2004-12-14
Filing date: 2005-11-14
Publication date: 2006-06-21
Also published as: US20060129771A1

Abstract

方法600在在线数据存储***中执行数据移植任务。方法计算615移植实用性，移植实用性是为完成数据移植任务所花费的时间的函数和生成用于执行数据移植任务的移植请求，其中数据移植任务被划分成子任务以及对于每个子任务生成一个移植请求。方法600然后确定625用于执行移植实用性的移植截止期；和分配630奖励值给接收的客户存储请求，这些奖励值代表通过执行客户存储请求所生成的收益；和分配630奖励值给移植请求，这些奖励值代表通过执行数据移植任务所生成的收益以及是基于预期的客户存储请求的奖励分发、可用的存储容量、剩余的移植请求的数目、和移植实用性。方法630还这样地调度635移植请求和客户存储请求，以使得赢得的总的奖励最大化；以及执行640请求的调度表，以便执行数据移植任务。

Description

用于管理数据移植的方法和***

技术领域

本发明涉及用于管理数据存储器的数据移植的方法、设备和计算机程序。移植被管理为满足对于移植实用性和数据接入性能的竞争要求、或其它商业对象、以及具有用于数据存储服务供应商的应用。

背景技术

管理存储***的花费近年来由于这些***为克服数据速率增长而逐渐形成的复杂性已大大地上涨。结果，越来越趋向于把存储资源统一成单个大规模***，以便更好地资源利用和减少对于熟练的存储***管理人员的需要。在其中部门计算和存储资源经常不再是分离的而是一起合并在服务于所有的部门的需要的数据中心的企业中，这是显然的。这种趋势也表现在由小规模和中等规模企业对于管理的存储服务供应商(SSP)的存储要求超过发源上。在SSP基础结构中，资源在具有不同的QoS(服务质量)要求以及伴随的收益的应用/客户之间共享。非常自然地，最大努力服务模型不适于这种情形。而是，在供应商与客户之间签署规定QoS保证连同对于满足、超过、或破坏这些保证的收益条款的精巧的服务水平协议(SLA)。

在今天的电子商务环境下，总是预期这些***是在线的和以保证的QoS级提供接入数据。同时***必须不断演进，以便操控各种因素，如由于现有的和新的客户而造成的数据量的增加、工作负荷的季节性变化、对于替换***部件以处理故障的需要、以及跟上技术改变的步伐。这常常需要重新组织数据以及随之而来的重新配置基础存储硬件，更通常地称为数据移植。移植牵涉到两个不同的部分：形成其中详细说明要移动的数据以及数据的起源和目的地的移植计划，以及通过把数据移到特定的目的地执行移植计划。至今为止，移植总是被认为低优先级的活动以及在客户活动性较低的夜里和周末期间实行。然而，在今天的总是接通的电子商务情形下，很难有像这样的不工作的时间间隔。而且，在许多情形下，延迟移植任务到以后的时间会导致供应商的重大的收益损失。例如考虑，在盘阵列中的一个或多个盘显示在不久的将来有故障的标记。在这种情形下，数据必须在实际故障的概率变为太高之前从这个盘阵列很好地被移植。因此，在这种情形下几乎总有对于竞争移植的硬截止期。在另一种情形下，SSF答应附加的容量或在给定的时间框架中对于客户的改进的QoS保证。这可牵涉到存储域网(SAN)重新配置，引导必须在答应的时间框架中完成的数据移植，以避免引起的惩罚。

分级结构的存储管理(HSM)在某些***中被使用来从昂贵的但高性能的SCSI盘中移动不太经常使用的数据到便宜的但低性能的盘，使能更好的资源利用。最近，在其中***管理由商业策略驱动的基于策略的存储管理(PBSM)方面也做了很多工作。这些***的一个重要的目标是保证正确的数据在正确的时间处在正确的位置。这常常使得必须在不同的时间提供不同的QoS保证的卷中来回移动数据。

一般说来，移植总是导致对于供应商具有比起初始配置更大的商业价值的***配置。因此，重要的是以除了它的原始性能影响以外考虑移植的总的商业通用性的方式执行移植计划。

今天用于数据移植的最流行的方法是在客户活动性较低的夜里和周末期间作为维护活动实行移植实用性。如上所述，这种方法在今天的、预期一天24小时、一星期7天运行的电子商务环境下是不可行的。虽然现有的存储管理工具，像Veritas卷管理程序和HP-UX逻辑卷管理程序，在移植过程期间继续提供数据接入，但它们不提供用于管理移植对于客户QoS目标的性能影响的任何设施。Veritas卷管理程序确实提供用于调节数据移植的速率的参数vol_defalut_I/Odelay，但它是非自适应的以及不考虑移植截止期。

C.Lu等的文章，“Aqueduct：Online Data MigratI/On withPerformance Guarantees”，Proc.of USENIX Conference on File andStorage Technologies，2002，219-230(此后称为Aqueduct)描述了控制理论方法，保证关于移植计划执行对于客户性能的影响的统计约束限制。Aqueduct方法不断监视客户工作负荷以及调整移植工作负荷，使得只消耗留下未使用的那些资源。虽然就对客户性能的影响而言，这个方法比起非自适应方法执行性能好得多，但它总是把移植看作为低优先级任务，这种任务以没有保证的截止期的最大的努力的方式被执行。在负荷重的***中，这会导致不可预测的长的移植持续时间。数据移植在这些环境下常常需要精确地修正***配置以减轻过载。

最近，几个研究者解决了服务供应商的利润最大化。大多数用于各种请求的资源的这些地址分配归类到QoS保证，所以资源被最佳地利用，由此使得供应商的利润最大化。一个这样的技术在A.Verma等，“AdmissI/On Control for Profit MaximizatI/On of NetworkedService Provider”，Proc.InternatI/Onal World Wide Web conference，pp 128-137，2003(此后称为A.Verma等)。A.Verma等解决用于联网的服务供应商的利润最大化的许可控制的问题。然而，A.Verma等的方法没有提供用于管理移植对于客户QoS目标的性能影响的任何设施。

发明内容

本发明的一个方面提供一种管理在线数据存储***的数据移植的方法。方法包括以下步骤：生成调度表，调度表包括对于执行数据移植任务的子任务的数据移植请求和对于执行客户存储操作的客户I/O存储请求，其中调度表是对于移植实用性要求和客户性能要求生成的；以及执行请求的调度表，以便执行数据移植任务。

优选地，方法响应于接收的存储接入请求和数据移植请求确定和调整数据移植的速率，以达到移植实用性要求而同时满足其它商业对象，诸如使得存储接入性能或由存储服务供应商从处理存储接入操作获得的收益最大化。

移植实用性的想法表示通常是为完成移植所花费的预期的时间的函数。移植实用性要求可包括明显地规定的用于完成数据移植的截止期(例如，在客户与存储服务供应商之间的SLA)。替换地，有效的截止期或移植实用性函数可以从可用的带宽和SLA规定的性能约定进行计算。一个例子是其中性能约定或SLA规定的奖励和惩罚，使得移植必须增加存储接入带宽和避免延时，或抢先地代替显示可能故障的记号的***部件。

多个移植实用性函数可被实施。例如，如果在截止期内无法完成移植会导致对于可用性的主要的影响(诸如因为预测的部件故障或安排的***停机)，SLA有关的奖励步骤函数可能是适当的。在对于正在进行的I/O性能需要移植而没有具体的完成截止期的情形下，不同的移植实用性函数是适当的。在后者的例子中，用于移植完成的目标截止期和移植速率可以通过施加总的性能最大化的目的而被确定。

操作的调度表优选地对于在线数据存储***的一组操作要求被生成，该操作要求组组合一组移植实用性要求与存储接入要求。存储接入要求可以根据处理存储接入要求的性能(例如，通过量或延时最小化)，或根据商业对象一诸如在移植实用性要求的约束条件下最大化存储服务供应商从处理存储接入请求(通过参考SLA规定的奖励和惩罚)赢得的收益--而被规定。因此，使能响应于工作负荷变化调整移植速率，使得潜在的存储接入奖励的损失最小化而同时保证在目标截止期内完成移植。方法优选地使用存储接入请求的到达的短期预测来确定适当的移植速率。这样的预测优选地连同计算的请求到达速率的长期平均值一起被利用。

优选地，方法相对于客户I/O工作负荷，分配移植实用性给数据移植任务，获取移植任务的真正的商业价值。优选的方法包括用于分配奖励值给各个移植请求的机制，这些移植请求构成能够将移植请求与客户I/O请求进行比较的移植任务。方法使用V的许可控制与调度方法的变例，通过由***获取的总的奖励最大化的目标以集成的方式调度客户I/O和移植请求。这个方法的重要的特性是，它不单调整移植速率以吸收空闲***容量，而且在***过载时它可以实际上给予优先级给移植请求优于客户I/O请求，以使得取得的奖励最大化。这个方法具有重要的好处：它在给定长期客户业务量统计特性后总是导致可预测的移植完成截止期。这些特性使得它在今天的面向服务的环境下是极其有用的。

本发明的另一个方面提供数据存储***，它包括用于生成调度表的模块，调度表包括对于执行数据移植任务的子任务的数据移植请求和对于执行客户存储操作的客户I/O存储请求，其中调度表是对于移植实用性要求和客户性能要求生成的；以及用于执行请求的调度表以便执行数据移植任务的模块。

如上所述的方法的步骤和***的部件可以以计算机程序代码被实施，它控制在其上执行代码的数据处理设备的操作的性能。计算机程序可被做成为作为包括被记录在记录媒体上的程序代码的程序产品是可用的，或对于经由数据传送媒体下载是可用的。

附图说明

现在将参照附图描述本发明的多个优选实施例，其中：

图1显示存储服务供应商(SSP)***的示意图；

图2A显示对于两个盘配置C_i和C_j相对于时间的SSP***的示例性收益分布的图；

图2B显示相对于时间在配置C_j中超过C_i的SSP***的示例性收益增益的图；

图3显示相对于奖励的请求的示例性容量分布的图；

图4显示相对于延时的示例性非增加的移植实用性函数的图；

图5A显示示例性客户I/O输入请求组的图；

图5B显示由现有技术Verma SRJF处理过程生成的输出请求组的图；以及

图6显示由图1的SSP***实施的、执行数据移植的方法的流程图。

具体实施方式

为了更好地了解实施例，在第1节中描述按照优选实施例的存储服务供应商(SSP)***的概貌。在第2节，列出SSP***的更详细的说明。在第3节，更详细地描述由SSP***执行的奖励分配与许可控制操作。在第4节，讨论关于在实际的设置中SSP***的实施方案的某些问题。在第5节，详细描述用于执行数据移植的方法。最后，在第6节，进行总结。

1.SSP***概貌

现在转到图1，图上显示按照优选实施例的存储服务供应商(SSP)***100的示意图。SSP***100操纵在大规模存储域网(SAN)***102上的客户数据。存储***102包含被组织成盘阵列104的大量盘。盘阵列104是一系列盘，它把单个大的逻辑存储装置的提取部分呈现给***的其余部分。这个提取部分在这里被称为逻辑单元(LU)。这些资源被具有不同的服务质量(QoS)要求以及伴随的收益的多个客户/应用共享。应用通过连接来自一个或多个逻辑单元(LU)的空间被分配以存储空间；连接的存储空间被称为逻辑卷(LV)。请求流106涉及到来自客户或客户类的I/O请求的聚集，和作为通过流被接入的数据的逻辑分组的存储(注意，术语顾客和客户在这个说明中可以交换地使用，以及具有相同的意义)。SSP***100适配于接收多个这样的请求流106。

在优选的***100中，在SSP***100的运营商--即服务供应商--与客户之间典型地存在有合同。这些合同通常规定(1)供应商预期满足的某些QoS保证，和(2)由供应商在满足这些保证时生成的收益。合同是基于在每个客户与服务供应商之间的服务水平约定(SLA)，它规定对于服务类别的这些QoS约束限制、这些保证得以保证的花费模型、以及来自客户的每个类别请求的预期的级别。优选的***100集中在提供等待时间约束限制(截止期)，因为这些约束限制比起通过量约束限制实施难得多，以及常常是用于客户应用的主要准则。

优选的***100是SLA-驱动的SSP***，其中客户I/O请求与奖励和惩罚相联系。在优选的***100中，对于在QoS约束限制内为请求提供服务得到奖励。当请求完全没有被提供服务或在QoS约束限制以外提供服务时，也可以引起惩罚。而且，对于为附加请求提供服务，或超过QoS要求，有可能(取决于SLA技术条件)获取额外奖励。

为此，SSP***100包括服务质量管理器模块108，它接收与被包含在各个客户SLA中的QoS要求有关的客户I/O流106和数据116作为输入。QoS管理器108，响应于这些客户I/O请求和移植请求，生成用于接入存储域网102的请求的队列120。QoS管理器108又包括许可控制器和请求调度表子模块(AC)，用于使得通过为这些请求提供服务而生成的收益最大化。优选地，QoS管理器106是具有软件代码模块的形式，它被装载在控制SAN的计算机中并在该计算机上执行。QoS管理器106的操作将在下面较详细地描述。

为了确保服务水平保证，SSP***100另外具有数据移植装置110，112，114，所以***可以调节到动态容量和/或性能要求。事实上，SSP***100适合于执行所有的大移植实用性任务，包括备份、归档、和复制。像Aqueduct那样的以前的方案通过使用在为客户请求提供服务以后可用的空闲带宽移植在线数据。实质上，移植被当作不保证截止期(完成时间)的低优先级最大努力活动被处理。然而，有些情形其中移植计划与截止期有关，例如，由于对于在故障之间的平均时间内完成恢复的需要所强加的计划。在另外的情形下，像SAN重新配置，早期移植可提高***性能和使得由SLA违例引起的收益损失最小化。优选的SSP***100与Aqueduct方法的不同的处在于，它以这样的方式执行移植任务以使得不单考虑它对客户应用的影响，而且也考虑在满足这些截止期或为供应商生成附加收益方面它的总的商业实用性。

为了达到这一点，优选的SSP***100包括移植函数计算器114，用于计算移植实用性，这里使用的术语移植实用性被表示为对于完成移植花费的时间的函数。正好像在I/O奖励的情形下，有效的实用性函数考虑服务供应商的商业对象。例如，考虑存储器S从配置C_i中的源设备到配置C_j中的目的地设备的移植。移植在时间0开始和在时间D结束。直观地，移植实用性曲线在0和D之间的时间t时的斜率给出在时间t的收益损失的速率，因为到配置C_f的移植在时间t尚未完成。这里隐含的假设是移植计划者规定配置C_f，以使得配置C_f比起初始的配置C_i为供应商产生更好的商业价值。

应当指出，对于移植请求的适当的实用性函数的设计(以及用于I/O请求的奖励模型)，或多或少是设计人的怪念头。然而，它通常相应于根据供应商的商业对象规定的服务水平约定和移植约束限制。而且，通过适当地改变到奖励(实用性)函数，可以使用相同的技术，以解决通常的使得供应商的商业对象最大化的问题。

现在参照图1，优选的SSP***100还包括卷管理器110，它在移植任务被发起时发送移植I/O请求112到QoS管理器108。移植实用性函数计算器114根据客户116和移植商业对象计算移植实用性，以及把这个函数传送到QoS管理器108。QoS管理器108然后分配奖励给每个移植I/O请求，它取决于预期的客户I/O请求的奖励、在时间t可用的盘容量、在时间t剩余的移植请求和移植实用性。许可控制器和请求调度表子模块(AC)然后根据这些奖励这样地许可和调度客户I/O和移植I/O请求，以使得服务供应商的利润(奖励)最大化。

在这一节的剩余部分，详细阐述用于客户(移植)请求的多个设计奖励(实用性)函数，这样，它可被使用于现实的情形。

1.1I/O奖励模型

在优选的***100中，每个客户I/O请求r_j被表示为r<α_j，s_j，Г_j，R_j(δ)>，其中α_j是请求的到达时间，s_j是请求的服务时间，Γ_j是与r_j有关的流，以及R_j(δ)是由请求生成的奖励，如果它以时间δ的延时被提供服务。应当指出，对于I/O请求的奖励被表示为请求所面临的延时的函数。优选地，只考虑随延时增加而不增加的那些奖励函数。对于在时间δ内被提供服务的客户请求r_j的奖励R_j(δ)的自然解译是服务供应商在为具有延时δ的r_j提供的服务从客户获取的收益。

通常的奖励函数允许***100灵活性使得各种各样的对象函数最佳化，取决于SLA技术说明和服务供应商的商业对象。供应商-中心模型具有正比于服务时间的奖励。另外，奖励可被使用来根据由它们的请求生成的收益(即，SLA类别)提供区分的QoS给客户。在用户-客户情形下，可以形成反映总的客户满意度的奖励。例如，如果SSP规定用户满意度为在等待时间约束限制内被提供服务的请求的95％，则它可以缩放具有大量I/O请求在不久以前耽误截止期的客户的奖励。在对象是使得聚集的延时最小化的情形下，可以使用随延时线性减小的奖励模型。

通过允许不同的I/O请求具有不同的奖励函数，***100可以有效地处理其中不同的客户(流)具有不同的SLA约束限制和收益的情形。注意到，这允许***100处理混合的-媒体工作负荷，其中不同种类的工作负荷具有不同的实用性函数。例如，线性减小的奖励函数似乎适用于文件***工作负荷。对于流动的媒体工作负荷，耽误它的等待时间约束限制(截止期)的请求的奖励可以是零。因此，在这种情形下的适当的奖励函数是阶跃函数。在这些情形下，QoS管理器108的许可控制器和请求调度表子模块(AC)能够使得收益最大化，其中对于不同的请求有不同的奖励函数。而且，许可控制器和请求调度表子模块(AC)适用于拒绝请求的“正确的”子组，这样，其余请求可以在它们的QoS约束限制内被提供服务。简单地说，SSP***100能够使得通过考虑与各个I/O请求有关的奖励(和惩罚)而生成的收益最大化。

1.2移植实用性模型

用于存储器的移植实用性U_m(t)被表示为相对于完成移植所花费的时间t的函数。像在I/O奖励的情形下，有效的实用性函数考虑服务供应商的商业对象。

考虑其中移植请求需要在某个截止期T_max内完成。在这种情形下，相应的存储器S的移植实用性被定义为如下：

U_{m} (t) = \begin{matrix} \{\begin{matrix} U & ift \leq T_{\max} \\ 0 & otherwise \end{matrix} - - - (1) \end{matrix}

其中U是在满足移植截止期时由供应商赢得的收益。换句话说，移植实用性可以由简单的阶跃函数表示，其中耽误约定的截止期的移植任务的奖励是零。常常是按照奖励不可能直接获取移植实用性，但在如工人生产率、对于***故障的更好的恢复那样的某些商业对象中，把它看作为增益的指示符仍旧是有用的。

在不存在截止期时，存储器的移植仍旧可导致更好的配置和为服务供应商获取附加收益(可能由于较少的SLA违例)。在这种情形下，移植实用性可被描述为相对于延时(t)的通用函数。优选地，仅仅使用随延时的增加而不增加的实用性函数。

为了更清晰地了解移植实用性，可参考图2A和图2B。图2A显示对于两个盘配置C_i和C_j相对于时间的SSP***100的示例性收益分布的图。R(C_i)和R(C_j)分别代表对于两个不同的盘配置C_i和C_f从为客户请求提供服务所生成的(预期的)收益。正如可以看到的，对于配置C_f随时间的预期的收益比起对于配置C_i的预期的收益增加，因此在这种情形下，随着从配置C_i移植到配置C_f将有财政利益。现在转到图2B，图上显示相对于时间在配置C_j中超过C_i的SSP***的示例性收益增益的图。正如可以看到的，SSP***的收益增益是随时间t的非递减函数，正如图2B上的虚线表示的。相应的移植实用性U只是收益增益的倒数，因此是时间t的非递加函数(由实线给出)。

2.用于执行数据移植的SSP***

SSP***100调度移植任务，以使得由供应商生成的总的收益--即，从满足客户请求以及执行移植任务所生成的收益的总和--成为最大化。为此，移植任务--即，需要从源SLV移动到目的地TLV的存储器--被认为是与用于任务的带宽(容量)要求B_m(即，对于移植所需要的数据量)和移植实用性U_m(t)有关的。另外，输入的n客户请求的组连同对于满足(违反)SLA约束限制的奖励(惩罚)被认为与这些要求有关。用于数据转移的总的盘容量被表示为C。

在其中对于移植没有设置的截止期的情形下，SSP***100按照以下公式通过找出用于移植的完成时间T_m而使得总的收益最大化。

\max_{T_{m}} [Σ_{i = 1}^{n} R_{i} (δ_{i}) + U_{m} (T_{m})] - - - (2)

其中δ_i是完成第i客户请求花费的时间，以及由移植和I/O请求使用的总的容量不大于可用的盘容量C。

在其中移植任务有设置的截止期T_max的情形下，SSP***100通过求解以下最佳化问题而使得总的收益最大化。

\max_{T_{m} \leq T_{\max}} [Σ_{i = 1}^{n} R_{i} (δ_{i}) + U_{m} (T_{m})] - - - (3)

2.1用于在线移植的基于调度的方法

SSP***100按以下方式调度移植任务。首先，SSP***100的卷管理器110把需要移植的存储器S划分成小的、固定的尺寸的子存储器，它们可以一次一个地被移植，在步骤中称为子任务。可以设想，随着硬盘技术的进步(即，通过LVM镀银色操作施加的减小的额外开销)，子存储器的尺寸可被做成为相对更小，允许对于移植速率进行细小增益控制。为了简化起见，某个移植子任务被称为一个移植请求。

SSP***100的重要的部分是QoS管理器108的许可控制器和请求调度表子模块(AC)。许可控制器和请求调度表子模块(AC)使用到达(和服务)时间的预期的分布用于调度将来的I/O请求。QoS管理器108分配收益R_m(t)给移植请求，该收益取决于对于I/O的预期的长期奖励分发、在时间t的可用的盘容量、在时间t剩余的移植请求的数目、和移植实用性。接着，许可控制器和请求调度表子模块(AC)使用Verma等的在线许可控制过程的变例，以使得由为I/O和移植请求提供服务所生成的SSP***100的收益最大化。

当移植被发起时，卷管理器119发送移植I/O请求到QoS管理器。移植实用性函数计算器114根据客户SLA 116和***管理人员输入118计算移植实用性函数。根据客户SLA 116和移植实用性函数，QoS管理器108许可和调度请求，这样，它使得服务供应商的利润最大化。

在下一节，描述当(1)在截止期的情形下移植实用性是阶跃函数，和(2)移植实用性是通用的时间函数时奖励如何分配给移植请求。

3.用于移植请求的奖励分配

为了便于说明由QoS管理器108进行的奖励分配，考虑在时间T₀存储器S从一个卷到另一个卷的移植，以及令B_m是需要被移植的数据量，以及C表示总的可用的盘容量。而且，许可控制器和请求调度表子模块(AC)适合于实施以下的最佳许可控制方法(OAC)。在任何给定的时刻，OAC把没有被拒绝的所有的请求按每个单位容量的奖励进行分类。然后它选择它可以处理而不违反容量约束限制的那样多的请求。现在考虑其中请求在时间T₀+kt，k∈N到达的简单的情形，其中所有的请求具有等于l的长度。在这种情形下，OAC方法也是最佳的。由许可控制器和请求调度表子模块(AC)使用的通用许可控制方法在后面稍微详细地说明，但该方法和以上简单的情形有助于懂得移植请求的奖励形成。

3.1具有截止期的移植

SSP***100可以工作在多个模式的一个模式。在SSP***100的第一模式下，设定对于移植的预期的截止期，例如6小时。在这种情形下，只要移植在接近于截止期的时间完成(例如，对于6小时的移植任务违反5分钟)，最好服务供应商不招致惩罚。

SSP***100在这个第一模式下利用用于移植请求的奖励函数，以使得许可控制器子模块这样地选择请求(I/O和移植)以使得预期的截止期被满足和由于移植引起的I/O奖励的损失最小化。

为了说明起见，令T_max表示对于移植的预期的截止期。移植实用性函数计算器114在这种第一模式下利用阶跃函数。例如，移植的实用性是U，如果它在截止期以前完成的话，以及否则是零(阶跃函数)。令C_m＝B_m/(T_max-T₀)表示对于满足截止期的移植所需要的平均带宽。而且，令N_m是需要被调度的移植请求的总数，以及N^t _m是在时间t剩余的移植请求的数目。

移植请求的潜在的奖励被规定为R_m，这样，

λ {&Integral;}_{R_{m}}^{\infty} c_{r} p_{r} \leq C - C_{m} - - - (4)

其中c_r是由具有奖励r的客户I/O请求所使用的长期预期的容量，λ是在任何给定的时间存在的客户I/O请求的长期预期的数目，以及p_r是客户I/O请求具有奖励r的概率。

公式4保证在为移植请求提供服务后可用的盘容量是足够服务于具有比起移植请求的潜在的奖励更高的奖励的所有的I/O请求。SSP***100计算这些数值c_r和λ的长期预报值，以便确定移植请求的潜在的奖励R_m。为了说明公式4起见，现在参考图3，图上显示相对于奖励R的请求λc_rp_r的示例性容量分布的图。图3上的区域A_l表示由移植请求所花费的预期的容量以及区域A_h表示由这样的高奖励I/O请求所花费的预期的容量。后者等于在为移植请求提供服务后可用的容量。

为了确保SSP***100在截止期前服务于所有的移植请求，QoS管理器106按照下式分配实际的奖励R_m(t)给在时间t的移植请求：

R_{m} (t) = \{\begin{matrix} 0 & if \frac{U}{N_{m}^{t}} < R_{m}, \\ R_{m} & otherwise \end{matrix} - - - (5)

其中R_m是由公式4给出的潜在奖励，以及N^t _m是在时间t剩余的移植请求的数目。

其中R_m(t)不同于R_m的情形是指其中移植具有这样的低的实用性以使得截止期只能通过拒绝具有更高的奖励的I/O请求才可满足的情形。在这种情形下，所有的移植请求通过设置它们的奖励为0而被拒绝。实际上，由于移植任务典型地是与足够高的实用性有关的，这预期是不发生的。

通过以上的用于移植的奖励模型和假设所有的统计估值是精确的，由许可控制器和请求调度表子模块(AC)使用的最佳许可控制(OAC)服务于在区域A_h(图3)中所有的请求以及移植请求。换句话说，如果移植请求的(潜在的)奖励是R_m，由OAC方法进行移植的预期的完成时间是T_max。另外，OAC方法服务于在区域A_h中所有的请求以及拒绝在区域A_l中所有的请求，由此使得由服务供应商生成的收益最小化。由许可控制器和请求调度表子模块(AC)使用的OAC方法将在下面在第3.3节中多少详细地描述。

3.1.1施加严格的移植截止期

在SSP***100的另一个模式下，SSP***100对于移植施加严格的截止期。在这个模式下，如果和只有在任务在时间T_max内完成时，移植实用性是U。

在这种情形下，SSP***100扩展与移植请求有关的奖励，以使得截止期决不被违反。例如，考虑其中移植请求的拒绝有时将导致耽误截止期(即使在移植被给予从t以后的所有的盘带宽)的情形。然后，奖励函数由下式替代：

R_{m} (t) = \frac{U}{N_{m}^{t}} - - - (6)

对于所有其它时间，QoS管理器108使用公式5来分配移植请求的奖励。

3.2具有通用实用性函数的移植

如在第1节中讨论的，有其中移植实用性可被表示为相对于延时t的通用函数的情形。在这样的情形下，即使要完成移植的时间(即，截止期)也是不明显的。

在这种情形下，SSP***100工作在另一个模式下。即，QoS管理器108首先计算对于要被完成的移植的最佳目标截止期，然后分配奖励给移植请求，这样，通过为I/O和移植请求提供服务生成的总的收益(奖励)被最大化。

在这个模式后面的概念是基于上述的严格的截止期模式的扩展。即，空间被划分成(每单位容量的)高的和低的奖励请求。我们给出可证明的最佳目标截止期，而不要严格求解最佳化问题(具有潜在的非凸起的约束限制)。具体地，QoS管理器108按照以下公式计算要完成的移植的目标截止期T：

\frac{B_{m}}{T_{opt}} = C_{m} - - - (7)

{| \frac{{δU}_{m} (t)}{δT} |}_{T_{opt}} = C_{m} (R_{m} - R_{l}), - - - (8)

其中R_l表示具有小于R_m的奖励的请求的长期平均奖励。换句话说，R_l表示在区域A_l(图3)中的请求的长期平均奖励。

现在转到图4，图上显示相对于延时T的示例性非递增的移植实用性函数的图。正如可以看到的，最佳目标截止期T_opt被标识在这个时间，其中移植实用性U_m(t)的斜率等于奖励R_m减去具有小于R_m的奖励的请求的平均奖励。

换句话说，如果U_m(t)是对于延时的凸起的函数，则T_opt是使得对于OAC方法的总的预期的收益(I/O奖励和移植请求的和值)最大化。由许可控制器和请求调度表子模块(AC)使用的OAC方法将在下面在第3.3节中多少详细地描述，但首先我们提供说明这个基本概念的直观的证明。

假设有一个具有截止期T’的调度表T，它比起具有截止期T_opt的任何调度表，具有更大的总的实用性。

如果T’＞T_opt，则T在时间T_opt服务于更多的I/O请求(和更少的移植请求)。然而，这样的请求预期为具有小于R_m的每单位容量的奖励。另一方面，通过延长移植截止期单位时间造成的移植实用性的损失大于R_m-R_l(由于U_m(t)的凸起性)。而且，延长移植导致在时间T_opt后的某些I/O请求的拒绝。由于这个移植造成的每单位时间I/O奖励的损失等于R_l。另外，应当指出，如果我们在任何时间服务于k个移植请求，则预期的I/O奖励损失大于kR_m。因此，通过在时间T_opt为额外的I/O请求提供服务造成的总的实用性的预期的增加小于通过在T_opt后的任何时间把移植延时1个时间单位或通过拒绝更多的I/O请求为额外的请求提供服务造成的实用性的损失。

类似地，如果T’＜T_opt，则容易看到由T拒绝的某些I/O请求预期大于或等于R_m的奖励。因此，通过延时而服务于一个这样的请求导致小于R_m-R_l的移植实用性的损失(由于Urn的凸起性)。而且，由于在T_opt后的这样的移植造成的预期的I/O奖励损失是R_l。因此，再次地，通过比T_opt更加早完成移植造成的预期的I/O奖励损失大于移植实用性的增加量与赢得的预期的附加I/O奖励的总和。

一旦目标截止期被标识，程序过程的其余部分是与具有截止期的情形相同的。即，对于移植所需要的平均带宽C_m被设置为B_m/T_opt，然后非严格的截止期公式4和5被使用来计算移植请求R_m，即，T_max由T_opt代替，以及在第3.1节中描述的非严格截止期方法被使用来计算移植奖励。潜在的(和实际的)奖励值对于每个剩余的移植请求被分配。在这种方式下，SSP***使用客户请求的长期平均到达速率和它们的相关的奖励，来确定用于移植的最佳截止期，即，可使得从完成移植和服务于适当的组的请求而赢得的奖励最佳化的截止期。

这个最佳的截止期然后被使用来计算移植的平均速率和移植奖励。对于固定的截止期，用于移植请求的奖励通过使用请求的预期的长期奖励分发被计算。

优选地，QoS管理器108通过使用二等分求解方程4，7，8。所有的曲线是逐段直线的事实允许它快速找到解。

3.3对于利润最大化的许可控制

一旦QoS管理器分配奖励给请求，许可控制器和请求调度表子模块(AC)就执行以下的利润最大化处理过程。许可控制器和请求调度表子模块(AC)取一组n个请求作为输入，其中每个请求r_i可被表示为R{arrivalTime(a_i)，serviceTime(s_i)，reward(R_i)，responseTimeBound(b_i)，capacity(c_i)，serviceClass(Cl_i)}。这些请求是I-O以及移植请求。为了说明许可控制器和请求调度表子模块(AC)的操作，把C定义为可用的增益的总的容量以及把T_tot定义为所考虑的总的时间。在具有截止期的移植的情形下，这被取为等于移植的长度或移植截止期。然而，实际上，许可控制器和请求调度表子模块(AC)被使用，即使没有移植在进行，以及T_tot是某个适当地规定的长的时间间隔。

许可控制器和请求调度表子模块(AC)适合于找到请求的调度表(x_i，t)，这样，在这个时间间隔上总的收益按以下公式被最大化：

MAX Σ_{i = 1}^{n} R_{i} Σ_{i = 1}^{T_{tot}} X_{i, t} - - - (9)

Σ_{i = 1}^{n} c_{i} p_{i, t} \leq C

time t；

Σ_{i = 1}^{T_{tot}} x_{i, t} \leq 1

request i；

这样，

x_{i, t} = \{\begin{matrix} 1 if r_{i} is scheduled at time t \\ and (t + s_{i} - a_{i}) < b_{i} \\ 0 o t h e r w i s e \end{matrix}

p_{i, t} = \{\begin{matrix} 1 &ForAll; t : (t &Element; (r, r + s_{i} - 1) \\ and x_{ir} = 1) \\ 0 otherwise \end{matrix}

其中

Σ_{l = 1}^{T_{tot}} x_{i, l} = 0

是指请求被拒绝。将会看到，这个问题可能建模为带宽分配问题，它即使在归一化的离线设置下也知道是NR-Hard的。而且，问题需要在其中作出拒绝请求的判决的在线设置下在不知道被调度为以后达到的请求的条件下被求解。

3.3.1BSRJF过程

Verma等描述在其中所有的请求具有相同的奖励的情形下用于利润最大化的概率最佳在线处理过程(SRJF)，然后对于一般情形把它扩展为局部最佳的处理过程(BSRJF)。它们也提供处理过程的在线版本。为了完整性，这些处理过程概述如下：

Verma在线处理过程(SRJF)，代替首先为短工作(SJF)提供服务，首先使用最短的剩余的时间，组合选择短的和具有较少的冲突的请求的工作的概念，它在操作***域中被使用来使得等待时间最小化。在本上下文中萌芽SJF的唯一差别在于，冲突组被限制为未决定的请求组，即，既没有被拒绝也没有被提供服务的请求。加到Verma SRJF处理过程的输入是一个请求表，它被称为未决定的表；以及输出是服务表和拒绝表。服务表是那些被接受、即许可的、用于调度的请求的表。例如，假设输入请求表被显示于图5A，以及接着是Verma SRJF处理过程。Verma SRJF处理过程按次序取请求，通过到达时间被分类，即，r₁，r₂，r₃，r₄，r₅，和r₆。Verma SRJF处理过程首先考虑r₁。应当指出，具有短于r₁的剩余时间的冲突的请求是r₃。另外，即使在服务于r₃后，Verma SRJF处理过程将具有空闲的容量用于服务于r₁。因此Verma SRJF处理过程将接受r₁。Verma SRJF处理过程然后考虑r₂，以及拒绝它，因为在服务于r₁后留下的容量中，Verma处理过程不能服务于r₂和r₃。通过更短的剩余时间准则，选择r₃超过r₂。因此，V处理过程拒绝r₂和服务于r₃。在第二组请求中，以类似的方式选择r₄。但在r₅与r₆之间，虽然r₆是更短的，但它在r₅后结束，所以选择r₅。SRJF处理过程的输出显示于图5B。

为此，Verma把他们的SRJF处理过程定义为：

定义1：最短的剩余工作第一处理过程(SRJF)：请求按它们到达的次序进行排序。然后r_i被提供服务，如果在保留用于所有的未决定的请求r_j的容量后有留下的容量的话，这样，a_j+s_j＜a_j+s_b。否则，r_i被拒绝。

Verma等也说明，一旦处理过程从未决定的表中取一个请求，它或者被接受(许可)或者被拒绝。它不返回到未决定的表。

上述的Verma等的在线SRJF处理过程需要有关请求的到达和服务时间的先验信息。然而，这样的信息在实际的许可控制情形下是不可用的。另外，请求具有响应时间的QoS约束边界，以及只在QoS约束边界被违反之前才能被延时。

因此，请求的到达速率和服务时间分布的短期预测被利用来解决在实际的在线设置值的请求最大化问题。

由于最短的剩余工作第一(SRJF)处理过程取按它们的到达时间分类的请求，所以容易把它变换成在线处理过程。Verma在线SRJF处理过程然后如下地工作。当请求到达时，检验这个请求是否可被提供服务，给出预期在将来的请求被提供服务之前结束的将来的请求的预期数目。为了进一步说明，如果请求在时间t到达以及具有10的服务时间，则SRJF处理过程找出预期数目的、将在(t+1)，(t+2)，…，(t+9)，以及在(t+10)之前结束的请求，即，预期在当前的请求结束之前要被提供服务的所有的这些请求。这确保SRJF处理过程使得在预期的意义上被提供服务的请求的总数最大化，即，如果假设的分布正好是请求的组，它应当使得被提供服务的数目最大化。而且，如果请求不能立即被提供服务，则在拒绝后重新检验条件，直到响应时间边界可能被违反的这样的时间为止。为了进一步说明，如果具有a_i＝T，s_i＝10和b_i＝20的请求通过SRJF准则不能被立即提供服务，则它在时间(T+10)之前被重新评估，并在该时间后它最后被拒绝。

Verma SRJF处理过程的伪代码在下面过程。

L ＝请求的平均容量，

P_r(i) ＝发生事件i的概率

E ＝具有与各个随机变量有关的所有的参数的随机请求

ρ ＝折扣比

1 Function SRJF schedule

2 for every element j in the available array A[1，…，d]

3 futureRequests[j]＝L*Pr(s_E＜＝(d-j))

4 backlog＝0

5 for k＝1 to j

6 backlog+futureRequests[k]*Pr(s_E＞＝(j-k))

7 end-for

8 capLeft＝available[j]-ρ*(backlog +futureRequests[j])

9 if(capLeft＜＝1)

10 return false

11 end-if

12 end-for

13 return true

14 end function

折扣比ρ起到两个作用。它获取预测的可信度以及将来的折扣比。具有高的错误概率的预测器具有远小于1的p，因为futureRequest的估值可以是偏离余量的。另一方面，精巧的预测器具有ρ+1。对于实际的服务部署，服务供应商应当从取决于所使用的预测器ρ的缺省值开始，和收敛到对于她最佳的数值。还应当指出，在请求r被SRJF调度表拒绝一次的情形下，它被重新调用，直至如果它还被延时，当请求r的QoS约束边界不能被满足时的这样的时间为止。

另外，当请求R₁(具有奖励r₁和结束时间d₁)到达时，决定水平线被定义为在R₁的开始与结束之间的时间。根据已被调度的请求，对于决定水平线计算空闲容量数组，被称为可用的数组。可用的数组按时间加索引指数。在数组中的每个项t代表在时间t可用的资源量，如果没有许可另外的请求的话。上述的SRJF调度表函数在处理当前的请求R1时利用这个可用的数组。Verma等还描述他们的SRJF处理过程到一般情形的扩展(BSRJF)，其中所有的奖励和惩罚是不相等的。在这方面，Verma等作出以下的定义。

定义2：把在时间t的请求r_i的冲突的组C^t _i定义为在时间t之前还没有被拒绝的、以及或者(a)a_i+s_i＞a_j和a_i+s_i＜a_j+s_j或者(b)a_j+s_j＞a_i和a_i+s_i＜＞a_j+s_j的所有的这样的请求的组。

另外，对于请求r_i的高奖励的冲突的组C’_i被定义为C^t _i的子组，这样，在C’_i中所有的请求是与C’_i中所有的其它的请求不冲突的。而且，在C’_i中所有的请求的奖励和惩罚的总和大于请求r_i的奖励和惩罚的总和。

Verma等的在线BSRJF实际上拒绝对于其存在C’_i的所有的请求r_i。它找出对于每个r_i的所有的候选的，以及用于它们的预先保留的容量。如果在预先保留后留下空闲容量，则r_i被提供服务。这实际上导致局部最佳性条件。

在它们的BSRJF的在线版本中，对于这样的C’_i候选者计算奖励和惩罚的预期的数目，即，计算以后到达的非传统的请求组的预期的奖励和惩罚的总和。把这个和值与所考虑的当前的请求的奖励进行比较。如果所保存的预期的奖励和惩罚的和值超过当前的请求的奖励，则用于r_i的容量被保留。这确保r_i只在没有预期的以后被拒绝的C’_i才被提供服务。

这是通过用下式代替第3行的在线SRJF伪代码而被引入的：

futureRequests [j] = L * Σ_{i = 1}^{d - j} (\Pr (s_{E} = i) * f (d, i, j));

其中

f (d, i, j) = 1, if &Exists; k &Element; N : R_{m} \leq {\tilde{R}}_{si} + \Pr ((s_{E} = \tilde{s}) \leq (d - j - i) / k)) * k * ({\tilde{R}}_{\tilde{s}} + {\tilde{P}}_{\tilde{s}})

＝对于具有服务时间s的请求的预期的(平均)奖励

＝对于具有服务时间s的请求的预期的(平均)惩罚

应当指出，现在的容量没有保留用于所有的早先结束的请求，而是只用于属于这样的组C’_i的那些请求。在在线情形下的VermaBSRJF处理过程不再保证最佳解，而值保证在某种意义下局部最佳的解。这是因为没有单个请求r_i可以从解决方案中由某个C’_i代替以及解决方案将改进。然而，可以存在有一组这样的r_i可以被去除以及解可以增加。

Verma等描述以下的例子，说明他们的BSRJF处理过程与他们的在线SRJF处理过程的差别。如果长度为10时间单位的请求r_i在时间单位50开始以及通过处理成功地经历来到第55个时间单位，而与跨度从55-58的请求r_j冲突，则BSRJF处理过程可以选择r_i，如果长度为2的请求(它可适合于58-60)的概率乘以一个请求的惩罚小于在r_i和r_j的纯奖励的差值的话。更精确地，如果对于预期的请求k有下式成立，则资源不保留用于r_j，而支持r_i：

\Pr (s_{k} < = 2) ({\tilde{R}}_{k} + {\tilde{R}}_{k}) < = R_{i} + P_{i} - (R_{j} + P_{j})

这里，许可较大长度的请求r_i，这可以拒绝接受以后的预期较短的请求r_j，但在剩余的时间中有另一个请求r_k的概率是非常低的，即，C’_i＝r_j U r_k的奖励和惩罚的预期的和值小于R_i+P_i。可以指出，在这个公式内在线SRJF可被看作为代表对于所有的这样的候选者C’_i的容量，而不管由C’_i的生成的收益。

3.3.2察觉移植的BSRJF

图1的许可控制器和请求调度表子模块(AC)实施上述的BSRJF处理过程的变例。多半地，SPP***100不引用像BSRJF的惩罚。然而，惩罚的概念可以通过让奖励等于奖励与惩罚的和值(因为请求的拒绝导致等于丢失的奖励与引起的惩罚的和值的损失)而被引入到SSP***100的变例。将会看到，BSRJF处理过程在接受请求用于提供服务之前预先保留容量用于具有高的奖励惩罚的请求。这种预先保留需要有关预期将来到达的请求的信息。Verma等的处理过程使用预测器来生成请求的短期预报，以便预先保留容量。本SSP***100优选地通过使用任何已知的基于时间系列的预测处理过程估计预期的I-O请求的短期预报。然而，移植请求和它们的奖励被决定性地生成。考虑一个例子，在启动移植时，移植请求的数目等于盘的总的容量。然而，当移植请求得到服务时，在任何给定的时间到达的移植请求的数目减小。而且，这样的移植请求的时间奖励在截止期接近时可以改变。为了归因于这个事实，BSRJF处理过程被修正，以区分I-O与移植请求。

用于判决具有奖励R_m的请求(移植或I-O)r_m是否应当被提供服务的修正的BSRJF处理过程的伪代码在下面给出。以粗线表示的行[9，10]是不同于Verma等的BSRJF处理过程的行。

用于标题为SCHEDULE的修正的BSRJF处理过程的伪代码

L＝请求到达速率乘以平均请求容量

P_r(i)＝发生事件i的概率

E ＝具有与各个随机变量有关的所有的参数的随机请求

p ＝将来的折扣比

f (d, i, j) = 1, if &Exists; k &Element; N : R_{m} \leq {\tilde{R}}_{si} + \Pr ((s_{E} = \tilde{s}) \leq (d - j - i) / k)) * k * ({\tilde{R}}_{\tilde{s}})

＝对于具有服务时间s的请求的预期的(平均)奖励

1 function SCHEDULE

2 for every element j in the available arrayA[1…d]

3 - - futureRequests [j] = L * Σ_{i = 1}^{d - j} (\Pr (s_{E} = i) * f (d, i, j))

4 backlog＝0

5 for k＝1 to j

6 backlog＝backlog+

7 futureRequests[k]*Pr(s_E≥(j-k))

8 end-for

9 futureMigReq＝getNumMigReq(j，R_m)

10 capLeft＝available[j]-futureMigReq-ρ*(backlog+futureRequests[j])

11 if(capLeft≤1)

12 return false

13 end-if

14 end-for

15 return true

16 end function

为了预先保留用于移植请求的容量，修正的BSRJF处理过程，在任何时间T_j，保持移植的状态(在时间T_j之前完成的预期数目的移植请求)和确定待决的移植请求的数目和它们的奖励。在任何时间，为了估计在以后的时间T_j完成的移植请求的数目，假设在T与T_j之间被提供服务的数目等于所需要的平均移植速率，即，假设在每个时间T_k：T＜T_k＜T_j，将得到服务的移植请求的数目等于所需要的长期平均移植速率。察觉移植的BSRJF算法因此分开地计算用于I-O和移植请求的futureRequest(将来请求)数组。如果移植请求具有大于所考虑的请求r_m的每单位容量的奖励，则GetNumMigRey子过程返回这样的待决的移植请求的数目。如果移植请求具有较低的奖励，则它返回0以及没有容量被保留用于移植，而同时做出对于r_m的许可控制决定。为了估计由任何类别的将来的I-O请求使用的容量L，它使用类似于Verma等的预测器。处理过程的其余部分是与BSRJF相同的。

将会看到，由于f(d，i，j)对于不同的服务类别的请求产生不同的数值，所以需要对于每个服务类别独立地执行支持环。不明显地说保持伪代码为更加可读的。

4实施问题

4.1通过松弛的预测错误自适应

上述的奖励函数是基于以高的精确度知道I-O请求的奖励分发的假设。然而，在实际的***中，这可能不总是这种情形。有某些情形，其中以高的精确度知道长期统计值。然而，还可以具有其它的情形，其中只知道这样的数值的估值(例如，具有短截止期的移植)。SSP***100应当优选地处理预测中的这样的错误。

为此，在用于具有截止期的移植情形的移植奖励(即，在公式5的RHS上)中引入slack(t)^1-c的因子，其中slack被定义为

slack (t) = \frac{N_{M}^{t}}{D - t} - - - (10)

其中D＝T_max以及N^tM是在时间t剩余的移植请求的数目，和c是可信度比值。如果长期分布数值是相当精确的，则c→1以及自适应因子趋向于1。另一方面，如果可信度是低的，则c→0以及SSP***尝试快速适配到当前的业务量，因此确保移植速率快速变化以及移植在接近于截止期时完成。

4.2周期性地重新计算统计数值

松弛因子允许SSP***适配于预测中的错误，以及确保移植不太快速和不太缓慢地完成，因为长期平均是不正确的。在实际的***中，这样的鲁棒性是宁愿的。然而，在其中没有规定截止期的通常的情形下，这个简单的增强不一定能够使得SSP***鲁棒的。这是因为识别目标截止期的处理过程取决于各种曲线的特性。因此，如果在移植期间发现移植以比起平均移植速率更慢的步伐进行，则***不一定必须提高移植速率。这是因为，如果没有错误，所计算的移植持续时间可能小于最佳移植持续时间。了解所有这些的一个简单的方法是：目标截止期不是固定的，而是取决于图4的斜率、图3的曲线下面的面积、和相关的公式7，8。

因此，如果移植显示或者耽误目标截止期或者太早完成的趋势，则最好是SSP***重新计算目标截止期，而不是迫使移植速率以便满足原先的截止期。而且，对于非常长的移植任务，即使这样的长期平均可随时间改变，以及可能必须重新计算移植截止期和奖励。因此，在实际的实施方案中，SSP***优选地在适当地选择的时间间隔后重新计算目标截止期和移植奖励，以使得***适配于工作负荷改变以及使得它更可靠。

5.用于执行数据移植的优选的方法

现在来看图6，图中显示由SSP***100实现的、执行数据移植的方法600的流程图。这个方法600是在SSP***100上为客户提供存储服务的主要方法的子处理过程，以及一旦这个方法被实施610，就需要在SSP***100上执行数据移植任务。在方法600开始610后，对于数据移植任务计算615适用的移植实用性函数。典型地，这样的移植实用性函数在其中需要在某个截止期T_max之前完成移植任务的情形下可以取阶跃函数的形式，或在其中没有特定的截止期的情形下可以取更一般的、非递增的时间的函数的形式。移植实用性函数可以由用户根据客户服务水平协议和按照供应商的商业对象规定的移植约束限制被人工地规定。第2.2节更详细地描述这样的移植实用性函数。

一旦移植任务被请求，方法600就生成相应于请求的移植任务的一系列子任务的一系列移植请求。这样，移植任务可以在一系列子任务中被执行，其中每个子任务相应于要被移植的移植存储器S的、相等尺寸的子存储器。SSP***100的卷管理器优选地响应于初始移植任务请求生成这些系列的移植请求。

在生成一系列移植请求后，方法600然后确定625相应的移植任务的移植截止期T_max。在其中有特定的目标截止期T_s的情形下，移植截止期T_max被设置为Ts。另一方面，在没有用于完成移植任务的特定截止期的场合下，方法600按照以上第3.2节中列出的公式(7)和(8)计算最佳目标截止期T_opt，以及把T_max设置为T_opt。

在确定移植截止期T_max后，方法600然后分配630奖励首先给客户I/O请求以及然后给移植请求。这些客户奖励按第2.1节中描述的方式被计算和被分配给客户I/O请求。至于移植请求，在其中只要移植是在接近截止期T_max的时间完成，服务供应商没有引入惩罚的情形下，用于移植请求的奖励按照第3.1节的公式(4)和(5)进行计算。然而，在用于移植的截止期T_max是严格的时间的场合下，奖励按照第3.1.1和3.1节的公式(6)和(5)进行计算。在两种情形下，根据对于I/O请求的预期的长期奖励分发、在时间t的可用的盘容量、在时间t的剩余的移植请求的数目以及移植实用性把奖励分配给移植请求。

在分配奖励给移植请求和客户I/O请求，方法600然后许可和生成请求的调度表635，使得收益最大化(奖励)。这个步骤635是通过在以上第3.3节多少详细地描述的、Verma等的处理过程被执行。方法600然后执行请求的调度表，以便执行数据移植和/或客户存储接入操作。在执行请求的调度表640后，方法600然后终结645。

这样，方法600把移植任务划分成小的子任务或移植请求。它使用客户I/O请求的奖励和移植实用性函数来分配奖励给这样的移植请求。I/O和移植请求然后由许可控制器处理，它使得赢得的总的奖励最大化。这种基于收益的方法计算和分配对于允许该方法在规定的时间之前完成移植的移植请求的最佳奖励。这个方法具有优点：它很好地适用于I/O业务量；它在高优先级I/O请求的业务量时间间隔期间降低移植的速率以及当这样的高的奖励I/O请求在数目上较少时提高后来的移植速率。

优选地，上述的方法600实施松弛因子，以允许方法600适配于预测的错误以及确保它不太快或太早完成移植，因为长期平均是不精确的。还优选地，方法在适当地选择的时间间隔后重新计算目标截止期和移植奖励，以使得方法600适配于工作负荷改变以及使得它更鲁棒。

6.结论

可以对于这里描述的技术和安排做出各种替换和修正，正如本领域技术人员所知的。

Claims

1.一种用于数据存储***的管理数据移植任务的方法，其中该方法包括以下步骤：

生成调度表，调度表包括对于执行数据移植任务的子任务的数据移植请求和对于执行客户存储操作的客户I/O存储请求，其中调度表是对于移植实用性要求和客户性能要求生成的；以及

执行请求的调度表，以便执行数据移植任务。

2.权利要求1的方法，其中这样生成调度，以使得数据移植的速率响应于接收的客户I/O存储请求和数据移植请求被调整，以便达到在移植与客户I/O存储请求之间的平衡。

3.权利要求1的方法，其中这样生成调度表：以使得数据移植的速率响应于接收的客户I/O存储请求和数据移植请求被调整，以便达到移植实用性要求而同时使得由数据存储***赢得的奖励最大化。

4.权利要求3的方法，其中生成步骤包括以下子步骤：

分配奖励值给各个客户存储请求；以及

分配奖励值给构成移植任务的各个客户移植请求；

比较移植请求的奖励与客户存储请求，以使得所述奖励最大化。

5.权利要求1的方法，其中这样生成调度表，以使得数据移植的速率响应于接收的客户I/O存储请求和数据移植请求被调整，以便达到移植实用性要求而同时使得客户存储性能最大化。

6.一种在在线数据存储***中管理数据移植任务的方法，其中该方法包括以下步骤：

计算移植实用性，移植实用性是为完成数据移植任务所花费的时间的函数；

生成用于执行数据移植任务的移植请求，其中数据移植任务被划分成子任务以及对于每个子任务生成一个移植请求；

确定用于执行移植实用性的移植截止期；

分配奖励值给接收的客户存储请求，这些奖励值代表通过执行客户存储请求生成的收益；

分配奖励值给移植请求，这些奖励值代表通过执行数据移植任务生成的收益以及是基于预期的客户存储请求的奖励分发、可用的存储容量、剩余的移植请求的数目、和移植实用性；

这样调度移植请求和客户存储请求，以使得赢得的总的奖励最大化；以及

执行请求的调度表，以便执行数据移植任务。

7.权利要求6的方法，其中数据移植任务被规定为在截止期内完成，以及确定步骤把移植截止期设置为规定的截止期。

8.权利要求7的方法，其中移植实用性函数是以下形式的阶跃函数：

U_{m} (t) = \{\begin{matrix} U & ift \leq T_{\max} \\ 0 & otherwise \end{matrix}

其中U是通过满足截止期Tmax赢得的奖励。

9.权利要求6的方法，其中对于数据移植任务的完成没有规定的截止期，以及确定步骤确定移植截止期为使得预期赢得的总的奖励最大化的最佳目标截止期。

10.权利要求9的方法，其中移植实用性函数是随延时增加而非增加的。

11.权利要求10的方法，其中最佳目标截止期T_opt按照下式进行计算：

\frac{B_{m}}{T_{opt}} = C_{m}

{| \frac{{δU}_{m} (t)}{δT} |}_{T_{opt}} = R_{m} - R_{l},

其中R₁表示具有小于R_m的奖励的客户存储请求的长期平均奖励，其中R_m表示要被分配给移植请求的潜在的奖励，B_m是对于满足截止期的数据移植任务所需要的带宽，C_m是对于满足截止期的数据移植任务所需要的平均带宽，U_m(t)是移植实用性函数。

12.权利要求8或11的方法，其中分配奖励给移植请求的步骤按照下式执行：

R_{m} (t) = \{\begin{matrix} 0 & if \frac{U}{N_{m}^{t}} < R_{m}, \\ R_{m} & otherwise \end{matrix}

其中R_m(t)是在时间t分配给移植请求的奖励，N^t _m是在时间t剩余的移植请求的数目，R_m是由以下公式给出的潜在奖励

λ {&Integral;}_{R_{m}}^{\infty} c_{r} p_{r} \leq C - C_{m}

其中c_r是由具有奖励r的客户存储请求所使用的预期的容量，λ是在给定的时间存在的客户存储请求的预期的数目，p_r是客户存储请求具有奖励r的概率，C是数据存储***的总的可用的存储容量，以及C_m表示对于满足移植截止期的数据移植任务所需要的平均带宽。

13.权利要求6的方法，其中用于移植的截止期是严格的截止期，在于移植必须在预定的截止期内完成，以及确定步骤把移植截止期设置为规定的截止期。

14.权利要求13的方法，其中分配奖励给移植请求的步骤按照下式执行：

R_{m} (t) = \frac{U}{N_{m}^{t}}

λ {&Integral;}_{R_{m}}^{\infty} c_{r} p_{r} \leq C - C_{m}

其中c_r是由具有奖励r的客户存储请求所使用的预期的容量，λ是在给定的时间存在的客户存储请求的预期的数目，p_r是客户存储请求具有奖励r的概率，C是数据存储***的总的可用的存储容量，C_m表示对于满足移植截止期的数据移植任务所需要的平均带宽，以及U是通过满足截止期赢得的奖励。

15.权利要求6的方法，其中预期的客户存储请求的奖励分发是基于客户存储请求的长期平均值。

16.权利要求15的方法，其中该方法还包括以下步骤：

调整具有可信度因子的分配的移植奖励，以校正长期平均值的预测中的任何错误。

17.权利要求6的方法，其中该方法还包括以下步骤：

在选择的时间间隔后重新计算移植截止期和移植奖励。

18.权利要求6的方法，其中调度步骤包括以下子步骤：

许可调度比起当前考虑的用于调度的客户存储请求具有更大的每单位容量的奖励的那些移植请求。

19.如权利要求6中要求的方法，其中该方法利用预期的客户存储请求的长期和短期预报来调度移植请求，以便确保所述移植截止期被满足和移植被调节成适应客户存储请求的业务量中的突发。

20.一种适用于管理数据移植任务的数据存储***，其中该***包括：

用于生成调度表的装置，调度表包括对于执行数据移植任务的子任务的数据移植请求和对于执行客户存储操作的客户I/O存储请求，其中调度表是对于移植实用性要求和客户性能要求生成的；以及

用于执行请求的调度表以便执行数据移植任务的装置。

21.一种在线数据存储***，用于执行客户存储操作和适用于执行数据移植任务，其中该***包括：

用于计算移植实用性的装置，移植实用性是为完成数据移植任务所花费的时间的函数；

用于生成用于执行数据移植任务的移植请求的装置，其中数据移植任务被划分成子任务以及对于每个子任务生成一个移植请求；

用于确定用于执行移植实用性的移植截止期的装置；

用于分配奖励值给接收的客户存储请求的装置，这些奖励值代表通过执行客户存储请求生成的收益；

用于分配奖励值给移植请求的装置，这些奖励值代表通过执行数据移植任务生成的收益以及是基于预期的客户存储请求的奖励分发、可用的存储容量、剩余的移植请求的数目、和移植实用性；

用于这样地调度移植请求和客户存储请求以使得赢得的总的奖励最大化的装置；以及

用于执行请求的调度表以便执行数据移植任务的装置。

22.一种用于数据存储***的管理数据移植任务的计算机程序产品，该计算机程序产品包括被记录在计算机可读媒体上、用于执行以下步骤的计算机软件：

生成调度表，调度表包括对于执行数据移植任务的子任务的数据移植请求和对于执行客户存储操作的客户I/O存储请求，其中调度表是对于移植实用性要求和客户性能要求生成的。

23.一种在在线数据存储***中用于执行数据移植任务的计算机程序产品，该计算机程序产品包括被记录在计算机可读媒体上、用于执行以下步骤的计算机软件：

确定用于执行移植实用性的移植截止期；

这样地调度移植请求和客户存储请求，以使得赢得的总的奖励最大化；以及

执行请求的调度表，以便执行数据移植任务。