存储器端存储请求管理的制作方法
【专利说明】
[0001] 本申请是申请日为2009年9月18日申请号为200980142588. 1(国际【申请号】PCT/ US2009/057590)发明名称为"存储器端存储请求管理"的发明专利申请的分案申请。
技术领域
[0002] 本发明涉及存储请求管理，且更具体而言，涉及I/O请求的存储器端管理。
【背景技术】
[0003] 数据库系统的主要作用是解释数据对象的高级抽象声明，且操纵和搜索这些对 象。理想地，这些声明和操纵通过数据库系统被有效地解释为发送给简单的、线性寻址的、 封闭的、持续的存储装置的I/O请求。通常，数据库系统必须为多个应用执行这种解释。这 些应用可以使用跨越不同用户和方案安全级别的多个数据库、应用类型、数据库会话类型 以及I/O请求的优先权和类别。
[0004] 在很多情形中，I/O请求被发送到存储系统的顺序影响着系统的效率。例如，当小 的高优先级I/O请求和大的低优先级I/O请求都需要被发送到存储系统时，在小的高优先 级I/O请求之前发送大的低优先级I/O请求对于数据库服务器而言就不是高效的。
[0005] 已经开发了各种技术来确保I/O请求以智能方式发送到存储系统。例如，此处通 过引用包括在此的名为"Management Of Shared Storage I/O Resources"的美国专利申 请No. 11/716, 364描述了用于在数据库服务器中将I/O请求排队且以智能方式将这些请求 发布到存储系统的技术。然而，使得数据库服务器以智能方式发布I/O请求并不确保存储 系统优化处理I/O请求。
[0006] 具体而言，存储系统典型地以先进先出（FIFO)为基础处理I/O请求。就这方面而 言，存储系统从FIFO处理偏离，所述偏离涉及I/O请求的重新排序以改善磁盘效率。在1/ 0请求之后执行这种重新排序，而没有任何目的。因此，当多个数据库服务器向相同的存储 系统（或者存储系统内的相同存储装置）发送用于多个数据库的I/O请求时，存储系统可 能在处理较高优先级I/O之前终止处理较低优先级I/O请求，即使每个独立数据库服务器 以最优的序列独立向存储系统发送其I/O请求。
[0007] 多种类型的工作负荷和数据库通常共享存储器。遗憾的是，在共享存储器上运行 多种类型的工作负荷和数据库通常导致应用和混合工作负荷之间的性能和响应时间问题。 例如，对一个产品数据仓库进行大规模并行查询会影响对另一产品数据仓库的关键查询的 性能。而且，数据仓库上的数据负荷会影响也运行在相同数据仓库上的关键查询的性能。通 过过度供应存储系统可以减轻这些问题，但是这消除了共享存储器的成本节省益处。还可 以在非峰值时间调度非关键任务，但是这种手工的处理是费力的。当数据库具有行为不协 调的不同管理员时，这变得不可能。
[0008] 本部分中描述的方法是应当追求的方法，但是不必是原先考虑到或追求的方法。 因此，除非明确声明，不应当假设本部分中描述的任意方法限定仅包括在本部分中的现有 技术。
【附图说明】
[0009] 在附图中，通过举例的方式而非限制的方式说明本发明，附图中，相似的参考标号 表示相似的元件，且其中：
[0010] 图1是配置成从多个I/O请求者接收I/O请求且智能地排列I/O请求的存储服务 器的框图；
[0011] 图2是说明根据本发明的实施例，各个请求元数据值如何可以映射到消费者组的 框图；
[0012] 图3是根据本发明的实施例的三阶段选择策略的框图；
[0013] 图4是说明根据本发明的实施例的逐幸存组策略的框图；
[0014] 图5是说明根据本发明的实施例的逐幸存组策略的两个阶段的框图；以及
[0015] 图6是可以实现本发明的实施例的计算装置的框图。
【具体实施方式】
[0016] 下面的描述中，用于解释目的，涉及各种特定细节以提供本发明的透彻的理解。然 而，很明显，本发明可以不使用这些特定细节实践。在其他情形中，以框图形式示出了已知 结构和装置以避免不必要地模糊本发明。
[0017] 概览
[0018] 此处描述了用于至少部分地基于I/O请求的一个或多个逻辑特性在存储系统内 管理I/O请求被存储系统处理的序列的技术。逻辑特性例如可以包括：提交I/O请求的用 户的身份、提交I/O请求的服务、I/O请求所针对的数据库、I/O请求映射的消费者组的指 示、发布该I/O请求的原因、I/O请求的优先级类别等。这种逻辑特性基本不同于I/O请求 的物理特性，I/O请求的物理特性诸如是I/O请求所针对的数据的存储位置以及该I/O请 求指定的I/O操作中涉及的数据量。
[0019] 代替或除了在向存储系统发布I/O请求的I/O请求者内执行的任意管理，可以采 用此处描述的内存储（in-storage) I/O管理技术。当在此使用时，"I/O请求者"表示向存 储系统发布I/O请求的任意实体。I/O请求者例如可以是响应于从数据库应用接收的数据 库命令发布I/O请求的数据库服务器。然而，此处描述的技术不限于任意特定类型的I/O 请求者。
[0020] 因为存储系统处理引导到存储系统内的存储装置的所有I/O请求，存储系统比1/ 0请求者更好地用于做出关于如何调度已经引导到这些存储装置的I/O请求的智能调度判 断。例如，存储系统能够判断目标为特定存储装置的高优先级I/O请求应在目标为相同存 储装置的低优先级I/O请求之前被处理，即使两个请求来自不同I/O请求者且目标为两个 不同的数据库。
[0021] 包含在存储系统内用于管理I/O请求的逻辑此处被称为存储系统的"存储服务 器"。存储服务器可以通过在作为存储系统的一部分的处理器上执行的软件、通过硬布线逻 辑、或者通过软件和硬件的任意组合实现。存储服务器接收了但仍未被发布的I/O请求（例 如，已添加到存储系统的输出队列）此处被称为"悬置I/O请求"。已发布到存储装置但是 仍未完成的I/O请求此处被称为"未决I/O请求"。
[0022] 与I/O请求相关的工作的逻辑特性通常对于存储系统并不可用。因此，在一个实 施例中，I/O请求的逻辑特性以"请求元数据"的方式从其他实体被传递到存储系统。例如， 在一个实施例中，I/O请求者向存储服务器提供请求元数据以及I/O请求。如上面所解释， 请求元数据指定关于I/O请求代表的工作的逻辑特性。基于这些逻辑特性、调度策略和选 择策略，存储服务器判断何时发布每个I/O请求。如下面更详细描述，存储服务器可以立即 发布I/O请求，或者可以将该请求入队以用于延期发布。
[0023] 在一个实施例中，当多于一个I/O请求悬置且调度策略指示I/O请求应被发布时， 由一个或多个选择策略确定哪个悬置I/O请求需要发布。在选择策略中指定的各种策略可 以在各个阶段应用。在每个阶段中，被认为是选择候选的悬置I/O请求的数目基于属于该 阶段的策略减小。当悬置I/O请求的仅一个非空等待队列保留为候选时，存储服务器选择 位于等待队列的头部的I/O请求以供处理。
[0024] 可以在选择策略中指定的策略的示例包括：
[0025] · 70 %的存储性能容量应被分配给数据仓库财务，且30 %的存储性能容量应被分 配给数据仓库销售
[0026] ?产品数据库应具有高于测试和开发数据库的优先级
[0027] · OLTP工作负荷应具有高于维护工作负荷的优先级
[0028] 示例性系统
[0029] 图1是可以实现此处描述的I/O请求管理技术的系统的框图。参考图1，存储系统 100为若干不同应用130、132、134、136和138使用的数据提供存储。这些应用通过向I/O 请求者120、122和124发送命令而间接利用存储系统100。例如，应用130、132、134、136和 138可以是各种数据库应用，且I/O请求者120、122和124可以是通过存储、检索和操作存 储在存储装置104和106上分布的数据库上的数据而应答数据库命令的数据库服务器。
[0030] 在所示实施例中，应用130和132与I/O请求者交互，应用134与I/O请求者122 交互，且应用136和138与I/O请求者124交互。在实际的实现中，与I/O请求者并发交互 的应用的数目和类型可以变化。
[0031] 如上所述，I/O请求者120、122和124可以实现某种形式的内部I/O请求调度策 略。然而，例如当I/O请求者120和I/O请求者122均提交目标为存储装置104的I/O请 求时，这些内部策略不确保智能调度。为了在这种情况下智能地管理I/O请求，向存储服务 器102等级策略，且存储服务器102向输入I/O请求应用这些策略。
[0032] 调度和选择策略
[0033] 根据一个实施例，在存储服务器102内存在两个单独的策略：调度策略和选择策 略。调度策略确定应当何时发布I/O。例如，调度策略可以目标在于保持吞吐量合理地高。 在这种情况下，存储服务器102将允许相对大数目的未决I/O。一旦达到此限制，就将对1/ O排队。另一示例是目标在于保持延迟合理地低的调度策略。在这种情况下，存储服务器 102将允许相对小数目的未决I/O。在任一情况中，一旦达到该限制，任何新的I/O将排队。 当未决I/O的数目（磁盘上的当前I/O负载）到达某级别时，出现"饱和"。
[0034] 基于调度策略，当存储服务器102决定发布I/O请求时，存储服务器102基于选择 策略决定发布哪个I/O。此处描述的技术可以与任意选择策略一起使用。用于解释目的， 此后将描述各种类型的选择策略。然而，此处描述的技术并不依赖于使用