CN102132540B - 网络存储 - Google Patents
网络存储 Download PDFInfo
- Publication number
- CN102132540B CN102132540B CN200980133056.1A CN200980133056A CN102132540B CN 102132540 B CN102132540 B CN 102132540B CN 200980133056 A CN200980133056 A CN 200980133056A CN 102132540 B CN102132540 B CN 102132540B
- Authority
- CN
- China
- Prior art keywords
- storage resources
- request
- data
- buffer
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/30—Managing network names, e.g. use of aliases or nicknames
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/457—Network directories; Name-to-address mapping containing identifiers of data entities on a computer, e.g. file names
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
Abstract
一种包括计算机程序产品的***、方法、以及装置,用于接收数据传输请求,该数据传输请求包括要与一个或多个基于网络的存储资源元件相关联地执行的访问操作的规范,该规范包括用于一个或多个基于网络的存储资源元件的各自的永久可完全解析标识符,并根据访问操作的规范处理访问操作以实现数据网络上节点之间的数据传输。
Description
技术领域
本发明涉及网络存储。
背景技术
如今,在多种配置中使用分布式数据存储***。例如,存储区域网络(SAN)用于将一个或多个服务器计算机与一个或多个存储设备耦合。在一些情况下,在每个均具有启动器(其为目标存储设备处的远程存储单元提供本地接口)的服务器中使用互联网SCSI(iSCSI)协议。这些服务器可有效地使用远程存储器(其对于那些服务器好似本地的一样)。
诸如亚马逊S3***(Amazon S3 system)的其他分布式存储***利用基于Web的协议向远程客户端提供存储服务。例如,用户可以读、写、或删除存储在远程互联网可访问的存储***中的文件。
在这种分布式存储***中,由***的客户端做出的访问请求可抽象化,从而存储设备(诸如,磁盘)上的数据的物理排列以及缓冲器的使用对用户是隐藏的,其对客户端是不可见的。
发明内容
一般来说,在一方面,本发明提供了一种计算机执行方法,该方法包括接收数据传输请求,该请求包括要与一个或多个基于网络的存储资源元件相关联地执行的访问操作的规范,其中,该规范包括用于一个或多个基于网络的存储资源元件相应的永久可完全解析标识符;并根据规范处理访问操作以实现数据网络上节点间的数据传输。
本发明的一些方面可包括一个或多个以下特征。
可接收来自数据网络上的第一节点的数据传输请求,访问操作的处理影响数据网络上第一节点与第二节点间的数据传输。
第一节点可管理第一组基于网络的存储资源元件,该第一组基于网络的存储资源元件之一与规范中提供的第一永久可完全解析标识符关联,第二节点可管理第二组基于网络的存储资源元件,该第二组基于网络的存储资源元件之一与规范中提供的第二永久可完全解析标识符关联。
与第一永久可完全解析标识符关联的第一组单元可以代表数据传输请求的数据源,与第二永久可完全解析标识符关联的第二组单元可以代表数据传输请求的数据目的地。
与第一永久可完全解析标识符关联的第一组单元可以表示数据传输请求的数据目的地;与第二永久可完全解析标识符关联的第二组单元可以表示数据传输请求的数据源。
可接收来自数据网络上的第一节点的数据传输请求,访问操作的处理实现数据网络上的第二节点与第三节点之间的数据传输。
可由数据网络上的第二节点接收数据传输请求。
可由数据网络上的第四节点接收数据传输请求。
第二节点可以管理第一组基于网络的存储资源元件,第一组基于网络的存储资源元件之一与规范中提供的第一永久可完全解析标识符关联;第三节点可以管理第二组基于网络的存储资源元件,第二组基于网络的存储资源元件之一与规范中提供的第二永久可完全解析标识符关联。
访问操作的规范可包括数据传输请求类型,该类型包括以下之一:读(READ)请求类型、写(WRITE)请求类型、移动(MOVE)请求类型。
访问操作的规范可进一步包括以下信息,其指定要执行的访问操作的同步或异步本质。
访问操作的规范可进一步包括以下信息,其指定基于时间的周期,在此周期内将影响数据传输。
访问操作的规范可进一步包括以下信息,其指定基于时间的周期,在此周期内将执行访问操作。
访问操作的规范可进一步包括以下信息,其唯一地标识会话环境,在该会话环境内将执行访问操作。
访问操作的规范可进一步包括以下信息,其表明接收的数据传输请求是特定会话数据传输请求中的最后一个。
访问操作的规范可进一步包括一旦完成数据传输就提示生成确认的信息。
访问操作的规范可进一步包括一旦满足事件条件就提示生成状态更新的信息。
用于基于网络存储资源元件的每个永久可完全解析标识符均包括统一资源标识符(URI)。
可根据HTTP语法或其扩展来指定数据传输请求。
一般来说,在另一方面,本发明提供了一个***,其包括:数据网络上的节点;由数据网络上的一个或多个节点管理的存储资源,其中,存储资源的每一个元件在***内均是由永久可完全解析标识符唯一寻址的;以及机器可读介质,其存储可执行指令以使机器接收数据传输请求,该请求包括要与一个或多个基于网络的存储资源元件相关联地执行的访问操作规范,其中,该规范包括用于一个或多个基于网络的存储资源元件的相应的永久可完全解析标识符,以及根据规范来处理访问操作以实现数据网络上节点之间的数据传输。
第一存储资源的每个可寻址元件均可与符合直接寻址机制的名称关联,该寻址机制指定第一存储资源上的物理位置。
第一存储资源的每个元件均可与符合抽象寻址机制的名称关联,该寻址机制指定第一存储资源的逻辑单元数。
第一存储资源的每个元件均可与符合寻址机制的名称关联,该机制使用直接寻址和抽象寻址的结合。
第一存储资源的元件可与符合第一寻址机制的名称关联,第二存储资源的元件可与符合与第一寻址机制不同的第二寻址机制的名称关联。
本发明的方面可以具有一个或多个以下优点。
统一命名方法(例如,基于URI语法)简化数据传输的协调。例如,不需要基于命名的会话,所以不需要会话相关的信息来解决传输请求引用何存储位置。
基于Web的协议(其允许底层存储位置的规范(例如,基于存储设备上数据的物理布局))的使用对于选择所期望的存储特性提供了一定程度的控制。例如,数据可选择性地存储在磁盘驱动器的不同部分,以提供可达到的不同传输速率。
暴露详细的存储特性(例如,物理存储位置和缓冲)可为性能密集型应用程序(其对底层存储方法进行抽象)提供更多的控制。
在数据传输请求的递归级别处使用相同的协议,这允许在不修改服务器接口的情况下引入请求的嵌套。例如,从客户端到存储服务器的直接请求可由从客户端到集合服务器的请求代替,该集合服务器接下来产生对于存储服务器的多个独立请求以影响传输。
对于数据传输请求中三方、四方、或更多数目方的明确支持,这允许避免数据吞吐量和协调瓶颈的数据传输方法的规范。
这些方面和特征可以用于包括但不限于以下各项的多种情形:用于网络附属存储(web Attached Storage)和/或表示性状态传输(RESTful)存储。
在一方面,一般来说,在分布式内容存储器和访问***中的存储服务器提供一种机制,其利用指定的语义模型动态地建立缓冲器。例如,在利用缓冲器用于中间存储器的内容传输期间,语义模型支持单缓冲器和多缓冲器的分布式控制。
在另一个方面,一般来说,一种方法包括:检查与所期望的数据传输关联的特性(诸如,内容单元),然后基于检查结果选择第一存储资源的特性。然后,所期望的数据传输受到影响而使用第一存储资源元件。
一些方面可包括一个或多个以下特征。
检查与所期望的数据传输关联的特征包括检查内容单元的特征。
检查与所期望的传输关联的特征包括检查以下至少一个:内容单元特征,所期望的传输的通信特征,以及所期望传输的源地址和/或目的地址。
选择第一存储资源元件的特征包括从一组预先定义的存储资源元件类型中进行选择。在一些实施例中,此选择是根据与资源元件相关联的语义模型做出的。在一些实施例中,此选择是通过缓冲器类型(其可以包括缓冲器语义的类型)做出的。
选择第一存储资源元件的特征包括选择用于第一存储资源元件的参数。例如,选择用于第一存储资源元件的参数包括选择第一存储资源元件的大小。
使用第一存储资源元件影响内容单元的期望传输包括将数据从期望传输的源传递至第一存储资源元件,并将数据从第一元件传递至期望传输的目的地。
该方法包括根据所选择的特征来请求形成第一存储资源元件。
该方法包括提供指令,以使用第一存储资源元件将数据从期望传输的源传输至期望传输的目的地。
在另一个方面,一般来说,一种方法包括:根据与存储资源元件相关联的语义模型的选择来接收第一存储资源元件选择。然后,形成第一存储资源元件。接下来,使用所形成的第一存储资源元件接收影响内容单元的期望传输的指令。
一些方面可包括一个或多个以下特征。
方法包括为形成的第一存储资源元件提供地址。
接收用于影响期望传输的指令包括接收指定所形成的第一存储元件的地址的指令。
形成第一存储资源元件包括根据选择的语义模型形成缓冲器存储元件。
在另一个方面,一般来说,分布式存储器和访问***包括:多个存储服务器以及耦合存储服务器的通信链路。存储服务器包括第一存储服务器,其被配置为根据用于存储资源的语义模型的选择来建立第一存储资源。每个存储服务器均包括一个接口,其根据公共协议接受数据传输指令。这些指令根据存储资源的公共命名方法来标识数据传输终端。
一些方面还包括一个或多个以下特征。
第一存储服务器包括接口,其根据公共协议接受数据传输指令,该公共协议根据公共命名方法标识所建立的第一存储资源。
第一存储资源包括缓冲器。
另一方面,一般来说,存储服务器包括:第一数据存储设备,控制器,第二存储设备,以及用于接受数据传输请求的接口。该接口被配置为接受数据传输请求,其包括:(a)在第一存储设备与第二存储设备之间的数据传输请求,以及(b)在第二存储设备和该服务器外部位置之间的数据传输请求。接口可以被进一步配置为接受数据传输请求,其包括(c)在第一存储设备和服务器外部位置之间的数据传输请求。
一些方面可以包括一个或多个以下特征。
第一存储设备包括永久存储设备,第二存储设备包括易失性存储设备。
接口进一步被配置为接受请求以在第二存储设备中建立存储元件。
接口进一步被配置为接受第二存储设备中存储单元的特征。
另一个方面,一般来说,分布式的内容存储和访问***包括:实施语义模型的存储资源,该语义模型经由中间存储设备允许对内容传输进行分布式控制。例如,对于经由中间缓存器传输数据的请求,其并不一定需要在所请求的传输期间对于缓存器的额外的读写控制。
一些方面可以包括一个或多个以下优点。
实现用于中间缓冲器的特定语义模型能够对缓冲器的读和写进行分布式控制,而无需要求一方经由缓冲器请求数据传输以保持对传输的细节控制。例如,可以避免在请求者与驻存该缓冲器的服务器之间的紧密同步。
为中间缓冲器提供可选的语义模型,能够为内容传输的请求者提供灵活性,从而允许请求者选择适合于应用程序或基础设施约束的缓冲器语义。
对于缓冲器特性(诸如像语义模型的类型、大小、和位置)提供显式控制,更具体地,允许在更精细的层面而非根据整个存储设备或***对缓冲器特性进行控制,其可以极大地改善在使用固定类型的缓冲器而没有对缓冲器特性进行实质控制的场景的性能。
这种优势类型的一个实施例发生于当访问存储在包括不同类型数据的存储资源(例如,存储在磁盘或磁盘阵列上)中的数据时。例如,一些数据可能包括相对长的、顺序访问的部分(例如,数字化电影),但其可能不会经历频繁的重复访问,而其他的数据可能包括相对短的、被重复访问的部分(例如,数字化广告)。用于顺序访问的较长部分的适当缓冲安排可以是双重缓冲方法,其从存储设备至缓冲器潜在地使用比从缓冲器到客户端设备的传输大小更大的传输尺寸。对相对较短部分的合适的方法可以涉及使用缓冲池,其在最近最少使用(LRU)方法中被重新使用。再者,缓冲器的特性可以依赖于特定传输的特性。例如,长度、数据率、到客户端设备的信道特性(例如,抖动率),在客户端设备处缓冲器特性可能是决定用于特定传输的缓冲器的具体参数和缓冲方法类型的所有因素。
这种优势类型的另一实施例发生于当它对于基于缓冲器的地理位置或网络拓扑位置选择缓冲器的位置是合适的时候。作为一个实施例,其可能对于传输到特定的客户端设备(即,那些连接到特定的访问网络中的设备)使用一个缓冲器位置可能是合适的,并且对于到其他客户端设备的传输使用其它缓冲器位置可能是合适的。在一些实施例中,这些缓冲器可以有多个端口(如,网络连接),利用不同的端口对其进行特定寻址,其提供对于特定存储设备和特定客户端设备的连接。
在显式缓冲优势的另一个实施例中,可以建立缓冲器链(或其他拓扑结构,诸如具有与客户端关联的根以及与存储设备关联的叶的树)用于向特定客户端的数据传输。例如,一些缓冲器可以用于为向客户端的传输提供集合数据和/或数据排序的功能。
具有一组预先配置缓冲器(其可以通过具体的参数来实体化或从缓冲池分配)类型的优点在于,在存储***与另一数据源或目的地之间传输的请求者还可以选择用于特定传输的适当类型的缓冲器。此选择可以依赖于更高级的逻辑,如监控工作负载和设备以及通信链路的特性。
另一优点涉及使用嵌套数据传输请求。例如,第一客户端可请求协调器将数据从源传输到目的地。该协调可采取请求的特性,选择(例如,实体化或分配)适当的缓冲器(类型,地址,大小等),以及递归地发布用作第二嵌套客户端的进一步请求,以影响从源到缓冲器以及从缓冲器到目的地的传输。按照这种方式,缓冲器的选择和使用逻辑对初始的请求者来说是隐藏的,但仍是基于请求的整体特性来进行选择的。
另一优点可以包括使用目前所使用的硬件架构,但提供不同的访问协议。例如,具有磁盘驱动器、控制器、以及缓冲器的***可以被重新配置以允许对磁盘驱动器的直接寻址和/或对附至控制器的缓冲器的显式寻址,该控制器被配置为在磁盘驱动器(或以最小的缓冲)与外部接口之间、在磁盘驱动器与集成缓冲器之间、以及在缓冲器和外部接口之间进行直接的数据传递。控制器还可以被配置为使用集成设备中的整体缓冲存储器,为不同类型和特定参数提供建立单独缓冲器的功能。
另一个优点是显式缓冲器和存储设备可以在整体***(例如,附至存储设备的网络或智能存储***)内集成,而同时为不同类型的传输提供不同缓冲器类型的选择。
为存储设备和缓冲器提供统一寻址和访问协议(例如,使用具有基于URI的缓冲器寻址规范的基于HTTP协议和存储设备寻址)的一个优点在于简化了复杂***的部署和修改。
一般来说,在一个方面,本发明提供了一种***,其具有可以共同地执行***的服务和功能的部件。这些部件是作为至少属于第一部件集合和第二部件集合来管理的。第一部件集合的部件以时间上实质独立于第二部件集合的部件的时标操作。第一部件集合的部件具有第一组时间要求,而第二部件集合的部件具有实质不同的第二组时间要求。
本发明的一些方面可包括以下一项或多项。
***的部件可进一步作为属于第三部件集合来管理。第三部件集合的部件以时间上实质独立于第一部件集合以及第二部件集合的时标操作。第三部件集合的部件具有第三组时间要求,第三组时间要求实质不同于第一组时间要求和第二组时间要求这两者。
各部件集合的部件均按照特定集合一致性模型来内部协调各自的操作。
部件可驻存在多个通过数据网络互连的节点上。
第一部件集合的部件可驻存在通过数据网络互连的第一多个节点上,第二部件集合的部件可驻存在通过数据网络互连的第二多个节点上。
第一部件集合的部件可驻存在通过数据网络互连的第一多个节点上,第一多个节点包括第一节点,第二部件集合的部件可专有地驻存在第一节点上。
至少一个部件集合实施一致性方法,以保持对于该部件集合的部件可访问的共享状态。
***的外部接口可通过多个部件集合而展露。
一般来说,在另一个方面,本发明提供了一种***,其具有共同地执行***功能的部件。部件被作为属于以下级中的相应级来管理:***级、内容级、会话级、访问级、以及传输级。每一个级的部件均以时间上实质独立于任何一个其它级的部件的时标来操作,且每个级的部件均具有实质上不同于任何一个其他级的部件的时间要求。
本发明的一些方面可包括一个或多个以下特征。
每个级的部件均可按照特定级的一致性模型来内部协调各自的操作。
***级的部件可共同执行提供了***的管理以及整体可视性的功能。
内容级的部件可共同地执行对***上的内容存储进行组织和管理的功能。
会话级的部件可共同执行会话管理功能。会话管理功能可以包括以下一项或多项:会话开始、会话终止、特定会话资源分配。
访问级的部件可共同地执行实现了与一个或多个存储资源元件相关联的数据传输的功能。
传输级的部件可共同地执行功能,以执行数据传输。
部件可以驻存在通过数据网络互连的多个节点上。
一般来说,另一方面,本发明提供了一种方法,其包括管理***的元件作为至少属于第一部件集合和第二部件集合,使第一部件集合的部件能够在时间上实质独立于第二部件集合的部件所操作的时标来操作,以及根据第一组时间要求来内部协调由第一部件集合的部件所执行的操作,单独地根据不同的第二组时间要求来内部协调由第二部件集合的部件所执行的操作。
本发明的一些方面可以包括以下一个或多个特征。
该方法可进一步包括在不需要协调相异请求的情况下,实现第一部件集合的部件与第二部件集合的部件之间的请求的通信。
该方法可进一步包括在不考虑与相应通信关联的部件的协调要求的情况下,实现通过级对之间的通信。
该方法可进一步包括实现通过以不同时标操作的部件对之间的通信。
在一方面,一般来说,分布式***驻存在多个互连的节点上。***包括多个级,每个级均包括多个驻存在***节点上的部件。每个级均在该级的分布式部件中独立地实施一致性方法。***在级接口之间均有互连。在不确保对于其它级的接口处接收到的请求的一致性的情况下,每个级均在一个或多个节点处提供对于其他级的接口。在一个实施例中,***应用于存储器和多媒体内容访问,其中,传输级包括用于在节点间进行内容传输的部件,***级包括用于管理***的配置信息的部件。
一些方面可以包括以下一个或多个优点。
不同级处部件的独立协调允许使用不同的协调方法(各协调方法对该级提供的功能均是合适的)。这可提供整体性能优势,并可简化整个***的规范以及开发。
在一个级处实施的协调方法与在另外一个级处的性能要求隔离。例如,在一个级处阻挡的功能并不直接影响另外一个级处的定时性能功能。
通过避免级之间的一致性保证来简化软件的开发或其他级的规范。例如,允许以任意次序来处理内部级请求而没有在级内施加或施加极少的额外一致性要求。
其他的一般方面包括上述方面和特征的其他结合,且其他方面和特征可以表述为方法、装置、***、计算机程序产品以及其他方面。
本发明的其他特征和优点通过下面的描述和权利要求变得显而易见。
附图说明
图1是分布式数据存储***的框图。
图2是数据存储服务器的框图。
图3a是基本的数据传输流的梯形图。
图3b是基本的数据传输流的梯形图。
图4是复杂的四路数据传输流的梯形图。
图5是复杂的四路数据传输流的梯形图。
图6是***的框图。
图7是读缓冲器的状态图。
图8是写缓冲器的状态图。
图9是读/写缓冲器的状态图。
图10是双缓冲器的状态图。
图11是FIFO缓冲器的状态图。
图12是***的框图。
图13是流程图。
图14是***的框图。
图15示出了示例性内容存储和传送***。
具体实施方式
参考图1,***100利用基于网络的存储。数据网络120链接网络上的多个节点110、130、&140,从而在节点间可传输命令和数据。节点包括多个数据服务器140,其提供通过网络用于存储和访问数据的机制。节点还包括多个客户端110,其能充当各种作用,包括:发起节点间的数据传输、发送至数据服务器的数据源、以及从数据服务器发送的数据目的地。在一些实施例中,节点可作为客户端或服务器130,或作为客户端和服务器这两者130。应当注意,在本说明书中,比在两方“客户端/服务器”交互的环境中更为宽泛地使用术语“客户端”。应当注意,这里描述的“节点”不是必须区别于数据网络上的计算机,而可表示执行相应功能的部件。部件可一起驻存在数据网络中的特定计算机上,或部件的功能是分布在多台计算机上。
一般来说,***中的数据处理涉及参与了承担一种或多种角色的数据处理的节点。这些角色包括:数据处理的请求者,其可被称为“客户端”角色;控制处理的协调器(或“执行者”),其也可被称为“服务器”角色;数据的源(“数据源”);以及数据的目的地(“数据目的地”)。如上所述,客户端110通常可以充当请求者、数据源、或数据目的地的角色。例如,在一些处理中,单个客户端110可同时充当请求者和特定的数据处理的数据源或数据目的地的角色,而在其他处理中,一个客户端可以是处理的请求者,另一个客户端是数据源或数据目的地。通常,数据服务器可以充当协调器(执行者/服务器)、数据源、或数据目的地。在一些处理中,单个数据服务器140可同时充当执行者以及或是数据源或是数据目的地的角色。
节点130在不同的处理中可充当不同的角色,或作为整个处理的一部分。例如,一个节点可以作为用于一个处理的服务器,但作为用于另一处理的客户端。由于单个处理可以是较大处理的一部分,因此节点130在整个处理(其作为较小处理的集合而执行)过程中可同时作为客户端和服务器。节点130在单个处理中可以充当所有的角色(请求者、协调器、数据源、数据目的地)。
一般来说,每一个数据服务器140均负责管理至少一个数据存储资源150(通常是物理数据存储介质)。数据存储资源的实施例包括:磁盘、光盘和基于电路的内存。数据存储资源可以是易失性的或非易失性的。存储资源甚至可以是一个或多个其他的数据服务器。在图1中,将存储资源150示为与存储服务器140分离,但应当理解,存储资源可与存储服务器集成(如,在单个的计算机***内)。同样地,存储服务器140与存储资源150之间的通信链路可以通过网络120,或可完全独立于该网络(例如,使用***中的另一网络或节点之间的直接连接)。
数据服务器140通过与该服务器关联的寻址机制来向客户端110提供对于存储资源150的访问。寻址机制的实施例包括直接寻址机制和抽象寻址机制。直接寻址机制的实施例是通过存储资源上的物理地址,如通过特定的磁盘、柱面、磁头、和扇区。这种直接寻址能够给与客户端快速控制数据存储位置。抽象寻址机制的实施例包括使用逻辑块数或其他名字空间到存储位置的映射。例如,一种机制可使用虚拟的“单元”数并允许客户端指定资源、偏移量、和范围。用于资源的寻址机制可以使用直接寻址和抽象寻址的结合,例如,使用逻辑单元数,还使用逻辑单元中的物理磁盘道和扇区。
***100使用全球唯一命名机制,其中,每个存储资源以及每个资源的各可寻址部分均具有全球唯一名称。由数据服务器使用的资源寻址机制在服务器名称空间内是唯一的。每个服务器均还具有唯一的标识符。对每个寻址资源来说此结合是全球唯一的名称。在一些实施例中,***使用基于统一资源标识符(URI)指定资源地址的命名机制,标识唯一的名称空间以及该名称空间内的唯一地址。在一些实施例中,URI还指定网络位置,如作为统一资源定位符(URL)。关于URI(以及作为子集的URL)的更多信息在统一资源标识符(URI)中是可获得的:Generic Syntax,Berners-Lee et al.,Internet Engineering Task Force Standard 66,NetworkWorking Group RFC3986,2005年1月。
一般来说,URI指定由存储服务器管理的存储资源的一部分包括了以下部分:其将存储服务器的网络地址或主机名称指定为(例如)与互联网域名服务器(DNS)兼容的名称,其可以用于提供动态地址翻译服务。有关DNS的更多信息可参见Domain Names-Concepts and Facilities,Mockapetris,Network Working Group RFC 1034,1987年11月,以及DomainNames-Implementation and Specification,Mockapertris,Network WorkingGroup RFC 1035,1987年11月。在一个实施例中,URI还包括以下部分,其标识资源以及诸如查询指示符(“?”)或段指示符(“#”)的分隔符,在其后提供了存储资源的特定部分的规范。资源命名机制还可结合用于扩展性的版本信息。在一些实施例中,会话命名机制并入URI。
一个示例性URI地址是:
http://server1.example.com/unit#0-1000000
在该实施例中,
·URI-机制,http,标识访问协议按照HTTP语法,
·URI-主机,server1.example.com,标识数据服务器(其也能够以IP地址的形式表示,如,10.0.0.1),
·最后的URI-路径段,unit1,标识资源(如,磁盘),
·URI段指示符,#,作为分隔符来使用,
·前连字符URI-段部分,0,表示零偏移量(即,该资源的开始),以及
·后连字符URI-段部分,1000000,表示一百万字节的范围。
另一个示例性URI地址是:
http://server1.example.com/unit1?offset=0&extent=1000000
在该实施例中,
·URI-机制,http,标识名称按照HTTP语法,
·URI-主机,server1.example.com,标识数据服务器(其也能够以IP地址的形式表示,如10.0.0.1),
·最后的URI-路径段,unit1,标识资源(例如,磁盘),
·URI查询指示符,?,作为分隔符来使用,
·后分隔符节是“查询”,其被和(&)分割成段
·每一个查询段均具有三个部分:标签、分割等号(=)、以及数据
·段标签“偏移量”表示段数据,0表示零偏移量,以及
·段标签“范围”表示段数据,1000000表示一百万字节的范围。[应当注意,也可使用其他标签产生相同效果,如,“o”用于偏移量,“e”用于范围。]
另一个示例性URI地址是:
http://server1.example.com/unit1/0/1000000
在该实施例中,
·URI-机制,http,标识名称按照HTTP语法,
·URI-主机,server1.example.com,标识数据服务器(其也能够以IP地址的形式表示,如10.0.0.1),
·剩下的URI-路径由三段组成:
·第一段,unit1,标识资源(如,磁盘),
·第二段,0,表示零偏移量,以及
·第三段,1000000,表示一百万字节的范围。
其他URI寻址机制也是可能的。
一般来说,存储服务器140执行由客户端110发起的数据处理的检索操作和数据存储。在一些实施例中,处理由客户端110发起,其发送指定将要执行的动作的请求(如,消息、指令、命令、或其他通信形式),以及与该动作相关联的相关地址(如,用于数据源或数据目的地的数据资源URI)。请求也可包括额外的控制信息。在一些实施例中,请求的一些部分由语境来推断。可基于URI的使用来定义请求协议。如下面进一步讨论的,在一些实施例中,定义请求协议以利用超文本传输协议(HTTP)。有关HTTP更多信息可参见Hypertext Transfer Protocol--HTTP/1.1,Fielding etal.,World Wide Web Consortium(W3C),Network Working Group RFC 2616,1999年6月。使用HTTP可实现简化分布在网络上的网络存储设备的操作。例如,HTTP响应一般是按照在连接上接收到的与该响应关联的请求的相同顺序而从服务器通过连接发送至客户端。使用HTTP还提供简单的防火墙穿透,充分理解协议行为,以及简化的服务器开发。
继续参考图1,一般来说,客户端110通过网络120向数据服务器140递交请求。请求包括在存储资源150上存储数据的请求或从资源上检索数据的请求。
写请求是客户端110对数据服务器140的请求,以在由数据服务器140管理的存储资源150上存储数据。一个写请求可以是阻塞或非阻塞的,可以要求完成通知或未完成通知,且可使用请求客户端110作为数据源或使用另一节点作为数据源。
读请求是客户端110对于数据服务器140的请求,以访问由数据服务器140管理的存储资源150上的数据。读请求可以是阻塞或非阻塞的,可以要求完成通知或未完成通知,且可使用请求客户端110作为数据目的地或使用另一节点作为数据目的地。
在一些实施例中,***支持同步阻塞(还被称为“即时的”)以及异步非阻塞(或“预先安排的”)请求这两者。在从客户端发送到数据服务器的即时请求中,客户端与数据服务器之间的交互直到数据传输本身完成时才会完成。在异步请求中,客户端与数据服务器之间的交互通常是在实际数据传输完成之前就完成了。例如,服务器可检验该请求的有效性并返回对于所请求的数据传输在数据传输完成或开始之前已经调度的确认。
请求可以被构造为两方处理,其中,请求客户端110或是数据源或是数据目的地,数据服务器140是相对的数据目的地或数据源。从客户端的视角,这种请求可以被合适地称为“读”或“写”。即,“读”请求发起从数据服务器到客户端的传输,而“写”请求发起从客户端到服务器的传输。对于客户端与服务器之间的两方处理来说,在一些实施例中,正从客户端发送或正发送至客户端的数据可以包括在提供了请求本身的相同交互中。例如,两方“写”请求可包括要被写入的数据作为即时处理的一部分。
客户端110还可发起该客户端在其中既不是数据源也不是数据目的地的处理。在一个这种例子中,客户端发起三方处理,其中,客户端110向第一数据服务器140发送请求,该请求指定要在第一数据服务器140与第二数据服务器140之间传输的数据。从第二数据服务器的视角来看,这种请求可以被合适地称为“读”或“写”。即,这种“读”请求发起从第一数据服务器到第二数据服务器的传输,而“写”请求发起从第二服务器到第一服务器的传输。尽管当请求者既不是数据目的地也不是数据源时,可使用术语“读”和“写”,但也可以使用术语“移动”。客户端110向数据服务器140发送“移动”请求,指定另一数据服务器140作为数据源或作为数据目的地。在一些实施例中,“移动”请求指定请求者(例如)以执行两方处理。
在一些实施例中,***支持四方处理,其中,客户端向节点发送请求,以指定数据源和数据目的地,这两者均不是发起客户端或作用于此请求的节点。即,请求者(第一方)指令协调器(第二方)从数据源(第三方)移动数据至数据目的地(第四方)。此处理还可描述为“移动”。
在多方处理中,在一些实施例中,由客户端请求的数据传输可以作为单独交互执行。例如,在客户端与服务器之间的两方处理的情况下,使用回叫模块可将数据传输作为由数据服务器发起的一个或多个二次交互来执行。应当注意,这种单独交互通常对即时请求和异步请求都是兼容的。在客户端既不是数据源也不是数据目的地的多方处理情况下,数据服务器可以类似地发起单独交互,以执行客户端请求的数据传输。使用相同的协议或其他协议,可将处理中的任何请求递归地转换成一个或多个请求。使用相同的协议可创建统一递归协议,其允许任何一个请求扩展成任何数目的请求以及允许任何数目的请求聚集成单个请求。
网络存储允许客户端以最低的抽象水平来明确具体地控制存储资源的使用。传统的资源管理职责可以在服务器级处执行或让位给用户。例如,服务器可以在没有任何一致性保证和/或没有任何分配要求的情况下执行。此外,尽管执行可能并入一些会话语法概念,但对于会话的使用没有做出要求。可通过确认或事件消息处理事件匹配。数据服务器还可扩展,例如,支持更多语义增强的存储资源,其可充当缓冲器的角色以及中间动态创建的数据目的地。
一般来说,数据服务器140从多个不同的客户端110接收请求,该请求与至网络120上的多个客户端和/或数据服务器的数据传输或来自网络120上的多个客户端和/或数据服务器的数据传输相关联。在数据服务器的不同实施例中,例如,在整个***的相同实施例中使用不同的实施例,可以使用不同的调度方法以服务于来自客户端的请求。作为一个实施例,可使用未完成客户端请求的先进先出(FIFO))队列。其他实施例可涉及出序和多线程服务请求。
参考图2,在一个实施例中,数据存储服务器240管理对于一个或多个存储资源250的访问。资源控制器252用作存储资源250与任何试图移动数据的事物之间的接口。如果使用一个资源控制器252,则可保持逻辑至物理地址的映射。通过资源调度器230对资源控制器252进行访问,该资源调度器管理请求队列232和响应队列234。资源调度器230管理请求队列232的次序。在一个实施方式中,队列是作为先进先出(FIFO)队列来操作的。在另一实施方式中,根据存储资源来管理请求队列。在另一实施方式中,管理请求队列以满足请求约束,例如,基于何时开始或结束(如,限期)数据传输来处理请求。在另一实施方式中,管理请求队列以解决请求约束和资源优化这两者。例如,请求队列被作为一系列时隙或二进制文件(bin)来处理。在较短时段内具有限期的请求进入第一二进制文件,具有稍晚限期的请求进入稍后的二进制文件。接着,由资源效果来进一步优化每一个时隙或二进制文件。例如,在资源是物理磁盘的情况下,组织各二进制文件以优化寻道(seek)和旋转延迟(如,进行组织,从而当处理二进制文件时磁盘磁头不需要倒转方向)。例如,可利用基于电路的内存来实现资源调度器队列232和234。如果资源调度器过载(例如,请求超出可用的内存空间),则利用合适的状态通知(如,“资源忙碌”)来拒绝请求。
由请求处理器220处理资源请求。请求处理器220自处理器队列222处工作。每一个请求被解析和验证224,然后递交给合适的资源接口226。资源接口226向资源调度器递交该请求。经由出口队列218返回资源状态(如,请求被调度/资源忙碌)或响应(如,请求完成)。在一些实施方式中,附加特征利用会话(其被会话监控器228监控)。
通过数据网络120实现数据服务器240与请求者之间的通信。数据服务器240包括用于处理网络连接和通信的收发器210。请求到达收发器210处,并经由分配器212发送到请求处理器220。一台数据服务器240可具有多个请求处理器220,例如,对于每一个可用处理核具有一个处理器。分配器212为每一个请求选择请求处理器220,将该请求放置在所选择的处理器的队列222中。例如,可由下一个可用的处理器确定该选择。在一些实施方式中,专门的处理器期望处理特定类型或形式的请求。在这些实施方式中,分配器212基于请求类型或形式相应地选择请求处理器。例如,通过使用专门请求的特定端口来实现该处理。专门的请求可以是可替代的请求格式或该实施方式使用的通用格式的受限子集。多个请求处理器(其中,一些或所有已专门化)可用于分布数据服务器工作负载。
数据服务器可处理来自多个客户端的请求。在一些实施方式中,当客户端向服务器写数据时,可产生与其他请求的冲突。例如,从地址读数据的结果依赖于最终写到此地址的数据。当读和写请求同时到达时,它们执行的顺序将会影响读操作的结果。这就是所谓的数据一致性问题。可以实现数据服务器以解决一致性问题,例如,通过将对于资源的访问限制为单个会话并且严格排序在该会话内的请求。一个足够严格的排序是要求服务器仅在已完成任何之前接收的相同地址空间中的写操作之后才处理操作。可采用访问管理器来阻止客户端意外阻塞其他客户端或引起资源死锁。
在一些实施方式中,在客户端之间或在来自单个客户端的请求内没有进行一致性检验的情况下,数据服务器可以处理来自多个客户端的请求。这种方法将对于这些问题的管理移到了数据服务器的范围之外,其为数据服务器的实现提供了更大的灵活性,这能潜在地增加整个***的性能。
在数据服务器具有多个处理器的实现方式中,在单个客户端的请求内可有潜在额外的一致性问题。在一些实施方式中,处理来自单个连接的请求,从而避免了一致性问题。例如,一个连接上的所有请求分配到相同处理器。在一些实施例中,处理器能够检查每一个请求,并在所有其他处理器中查找冲突并停止该处理器直到冲突清除为止。
通信网络120是任何传输数据的设备的网络。可以按照多种方式来实现这种网络。例如,通信网络可包括以下各项中的一种或其组合:互联网、局域网(LAN)或其他本地网络、专有网络、公共网络、普通老式电话***(POTS)或其他类似的有线或无线网络。通信网络还可包括额外的元件,例如,通信链路、代理服务器、防火墙或其他安全机制、互联网服务提供商(ISP)、网守(gatekeeper)、网关、交换机、路由器、集线器、客户终端、以及其他元件。通过通信网络的通信可包括诸如调制解调器链路、以太网链路、电缆、点对点链路、红外连接、光纤链路、无线链路、蜂窝链路、蓝牙卫星链路以及其他类似链路的通信链路的任何结合和任何类型。使用任何可用的通信协议(诸如,TCP/IP)来实现通过网络的数据传输。可以利用诸如加密、安全协议、或其他类型类似机制的机制来确保通过通信网络的通信。
数据服务器管理对于数据资源的访问。当请求到达服务器以使用资源时,数据服务器或者立刻执行该请求或者调度一个或更多将来的操作以满足该请求。如果服务器无法完成这些事情之一,则利用拒绝或错误消息来响应请求。可用一个或多个将来的操作满足的请求是异步请求。异步请求可立刻被执行或被调度(如,派至稍后执行的工作队列)。
参考图3a,客户端302向服务器304递交请求320。服务器304处理该请求,并向客户端302递交响应330。请求320可以是写入附带该请求的数据,在此情形下响应330可以是确认或错误消息。请求320可以是读取由该请求标识的数据,在此情形下响应330可以是数据本身或错误消息。其他的请求也是可能的。
参考图3b,客户端312向第一服务器314递交三方请求340。服务器314可以利用表明该请求被调度342的消息或错误消息进行响应,或甚至完全没有响应。例如,服务器314通过向第二服务器316发送子请求350以及处理来自第二服务器316的响应352来执行所请求的操作。一旦完成,在一些实施例中,服务器314就可以向客户端312发送完成消息354。如果客户端312没有阻塞对于完成的等待,则该请求是异步的。
在一些实施例中,服务器314可使用多个子请求350以完成初始请求340。在一些情形下,例如,为了平衡网络流量负载或优化存储资源性能,顺序执行或可以潜在地无序执行多个子请求。可参考图4和图5,通过下面进一步描述的四方实施例进一步加以证明。
可以在一个会话环境(其可以是逻辑的或明确的)内执行请求。会话是客户端与服务器之间的关系。它独立于两个装置使用何连接或连接组来进行通信。例如,可以使用会话,以通过请求组管理短暂的服务器资源的使用。由请求组使用的短暂的服务器资源绑定至会话。在一些实施方式中,可通过可以形成为URI的唯一名称来标识会话。
例如,会话可以被命名为:
http://server1.example.com/sessions/049AF012
在该实施例中,
·URI-机制,http,标识名称遵循HTTP语法,
·URI-主机,server1.example.com,标识数据服务器(其还可以是IP地址的形式,如10.0.0.1),
·URI-路径段,sessions,标识该URI为会话,
·最后的URI-路径段,049AF012,是在server1名称空间内的示例性会话ID。
在一个示例性实现方式中,可以使用HTTP协议来定义数据传输操作。引用HTTP RFC(2616)的第1.4部分:“HTTP协议是请求/响应协议。客户端通过与服务器的连接向服务器发送请求,其是以请求方法、URI,和协议版本的形式,然后是MIME-like消息,其包括请求修饰符、客户端信息、以及可能的主体内容。服务器用状态行进行响应,其包括消息的协议版本和成功或错误的代码,接着是包含服务器信息、实体元信息、以及可能的实体主体内容的MIME-like消息。”该MIME-like消息是请求的主体,并且可以包括自定义参数。本文使用的示例性协议使用该空间以包括数据传输操作的参数。
读、写、以及移动请求可以形成为HTTP请求。可使用HTTP POST、GET、或PUT。利用请求所包括的参数可表征该请求。例如,请求参数可以是HTTP请求头(如,POST请求)的一部分,或在另一实施例中其是请求URL(如,查询指示符之后的段)的一部分。推荐的参数是:
·REQUEST={“MOVE”|“READ”|“WRITE”}
·SOURCE=URI
·DESTINATION=URI
·ASYNC={“TRUE”|“FALSE”}
·DEADLINE=TimeInterval
·SESSION=URI
·COMPLETE={“TRUE”|“FALSE”}
·CONFIRM=URI
该REQUEST参数指定请求类型。在一些实施方式中,值为“MOVE”、“READ”、和“WRITE”。在一些实施方式中,由于不同的数据传输请求类型可以由参数(如,源和目的地)区分,因此请求简单地为“MOVE”。在一些实施方式中,没有REQUEST类型。例如,所有没有请求类型的请求都被当作MOVE。在另一实施例中,使用HTTP GET和HTTP PUT提供请求的指示。例如,GET可表明READ,PUT可表明WRITE。在一些实施方式中,使用ASYNC参数区分同步和异步版本。在一些实施方式中,所有的请求都是异步的,则消除了对ASYNC参数的需求。
SOURCE参数指定在用于满足请求的操作中数据源的URI地址。写请求可包括要写入的数据而非指定源地址。在使用HTTP GET和HTTPPUT以表明请求类型的实施方式中,可以暗示SOURCE。GET暗示协调器是源,PUT暗示请求者是源。可以使用SOURCE参数代替此暗示。
DESTINATION参数指定在用于满足请求的操作中数据目的地的URI地址。如果目标地地址指示空间小于要传输的数据,则协调器应该拒绝该请求。在读操作中,数据可包括在响应中。在使用HTTP GET和HTTP PUT以表明请求类型的实施方式中,可以暗示DESTINATION。GET暗示请求者是目的地,PUT暗示协调器是目的地。可以使用DESTINATION参数代替此暗示。
并不总是需要ASYNC参数。当根据REQUEST参数或HTTP请求类型来区别同步请求和异步请求并不清晰时,使用ASYNC参数来进行区分。如果设置为“TRUE”,则表明是异步请求。如果设置为“FALSE”,则表明是同步请求。取决于实现方式,POST可以默认为或是“TRUE”或是“FALSE”。如果具有ASYNC设置为“TRUE”的请求丢失了必要的源或目的地(明确的或是适当地暗示),则不执行任何数据传输。然而,协调器可以将该动作认为是来自请求者的提示,该请求者随后可能使用一部分或全部所请求的资源。
DEADLINE参数不是必需的。出于调度的目的,使用该参数以指定“需要内的”时间。如果请求者指定了限期,倘若协调器不能够调度请求以满足限期则协调器必须拒绝该请求。参数值是TimeInterval,其是指定时间量的数字。通过接受具有限期的请求,协调器承诺在时间量消逝之前完成请求操作的操作。如果有必要,则由请求者决定对于在将请求传输到协调器期间预期的网络延迟进行补偿。如果有必要,则由协调器决定对于在传输数据期间预期的网络延迟进行补偿。如果协调器未在指示的时间完成数据传输,则其可能继续尝试或可以终止操作并用合适的错误事件告知请求者。限期不一定是超时要求。限期向协调器传达来自请求者的调度信息。
SESSION参数不是必需的。当提供会话URI时,协调器在给定会话的语境内执行满足请求的操作。如果没有给定会话,则使用默认会话语境。
COMPLETE参数不是必需的。当提供会话URI且complete参数设置为“TRUE”时,其表明该请求是此连接上相关请求组中的最后一个。
CONFIRM参数不是必需的。当提供确认URI时,在已满足请求时,协调器将包含请求消息表达的消息发送至由URI标识的确认资源。当目的地是永久性存储时,只有在数据被永久性存储时才会发送确认消息。
在使用HTTP实现的示例性实施方式中,请求参数被放置在请求的MIME-like主体或在URL中(例如)作为请求指示符之后的段。使用MIME-like主体用于MOVE的HTTP POST请求的实施例类似于:
“POST/V01.01/unit/”SP S-URL SP“HTTP/1.1
“HOST:“<aaa.bbb.ccc.ddd>:<ppppp>
“Content-Length:”20*DIGIT
“Source:”A-URL //NULL URL indicates no explicit Source
“Destination:”A-URL//NULL URL indicates no explicitDestination
“Confirm:”A-URL//NULL URL indicates no explicit Confirm
“Content-Range:“bytes”SP Start“-”End“/*”
where:Start=20*DIGIT
End=20*DIGIT
“Content-Type:appl ication/octet-stream”
“Status:”=“200 OK”|“400 Bad Request”|“404 Not Found”|
“499 Request Aborted”500 Internal Server Error”|
“500 Internal Server Error”|NULL
应当注意,第一行中的S-URL指定操作的协调器。如果Source、Destination、或Confirm为空(NULL),则它们被默认至S-URL。例如,没有源(source)的POST意味着源URL是由S-URL指定的。示例性S-URL格式如下:
/unit/UNIT?offset=OFFSET&extent=EXTENT&deadline=DEADLINE&async=BOOL
where:
UNIT=10*DIGIT
OFFSET=20*DIGIT
EXTENT=20*DIGIT
DEADLINE=10*DIGIT
BOOL=“true”|“false”
还应当注意,在这些实施例中的固定长度区域(指示的,如,10*DIGIT或20*DIGIT)都不是必需的。它们是如何按照向后兼容方式约束HTTP语法的实施例,以对于非常高性能处理进行优化。还可预想可扩充的可变长度的实施方式。
中断请求也可以作为HTTP请求来形成。所推荐的参数是:
·REQUEST=“ABORT”
·DESTINATION=URI
·SESSION=URI
REQUEST参数指定请求类型为中断。中断操作执行最大努力来终止先前传送的、对于资源的请求。
DESTINATION参数指定用于资源的URI地址。当接收到中断请求时,或是允许继续完成对于该资源的未完成传输操作或是终止该操作。协调器应当中断操作至其这样做没有过度的复杂性和/或不利性能影响的程度。从调度队列移走挂起操作等同于终止该操作。对于中断请求的响应表示被终止的未完成操作。
SESSION参数不是必需的。当提供会话URI时,协调器应该试图中断绑定至给定会话的请求。如果没有给定会话,则协调器应该试图中断绑定至默认会话的请求。
事件消息也可以作为HTTP请求形成。所推荐的参数是:
·REQUEST=“EVENT”
·RESOURCE=URI
·STATUS={“CONFIRM”|“FAILURE”|“RETRY”|“ABORT”|“BUSY”}
·SESSION=URI
REQUEST参数指定请求类型为事件。事件操作是由协调器发起的、到请求设备的消息交换,其表示在执行异步请求中存在的状态条件。如果默认的请求类型是事件,则请求参数可以是可选择的参数。
RESOURCE参数指定用于该消息的相关资源,或是产生事件的异步操作的源或目的地。
STATUS参数表示事件的状况。提供的列表是非穷举的。状态参数可以作为可扩展的枚举来实现,其表示非正常状况。给定的实施例可指出:
·CONFIRM-所请求的操作确认完成
·FAILURE-所请求的操作没有完成就已终止
·RETRY-协调器在执行所请求的操作时遇到问题,但是其继续尝试该操作
·ABORT-所请求的操作因ABORT操作而终止
·BUSY-协调器因过载而不能调度或完成所请求的操作
SESSION参数不是必需的。当提供会话URI时,其表示产生事件的异步操作的会话。
也能够使用额外的请求分配资源的空间、建立缓冲器、或数据服务器支持的其他操作。
协调器能通过执行一个或多个阻塞传输来满足异步传输的职责。它能够发起其自身的异步传输。它甚至能使用可替换的传输协议,例如iSCSI或PCI Express。协调器仅有责任尝试传输并管理请求,从而在传输的关联限期内完成传输。应当注意,操作可以递归转换成构成操作。从一个节点角度,单个操作可以转换成多个操作。多个操作可以转换为单个操作。初始的操作和经转换的操作可使用相同的基于URI的协议。例如,协调器可指示目的地服务器从源服务器读数据。目的地服务器实际上可以执行一组读操作,其加在一起构成所请求的读。在另一实施例中,客户端可向协调器服务器递交一组写请求,在协调器服务器中数据将被写入目的地服务器。协调器可将写请求集合成单个写请求至目的地服务器。任何请求都可用这种方式处理。在一些情况下,利用每一个均传递请求至其他服务器的一系列服务器,递归将非常深。
参考图4,作为四方处理的实施例,请求者客户端402可以请求协调器服务器404管理第一数据服务器406与第二数据服务器408之间的数据传输,在408中数据并不是必须经过协调器404传输的。在该实施例中,客户端请求420可以简单地是在限期内移动数据。在接收到确认响应440之后,客户端可以假定请求将会被满足。然后,协调器服务器404发出一组请求以进行数据传输。例如,初始请求442被发送到第一数据服务器406,由初始服务器响应460确认或拒绝该初始请求。在一些实施例中,直到所请求的处理完成才发送响应。第一数据服务器406通过将请求462发送至第二数据服务器408来执行所请求的处理。以数据响应480来回复该请求。例如,如果服务器请求462是READ,则数据响应480可以是数据本身。在另一实施例中,如果服务器请求462是WRITE,则数据响应480可以是确认。可替换地,响应480可以是错误消息。第一数据服务器406也可向协调器404发送最终的服务器响应464。
在协调器404协调处理时,其可发出任何数目的额外请求446。每一个额外的请求均遵循类似的模式490,其具有对于额外请求的可能初始服务器响应466、额外的服务器请求462、额外的数据响应482、以及对于额外请求的最终服务器响应470。应当注意,任何一个请求可以递归转换成一个或多个满足该一个请求的新请求。同样地,任何数目的请求可以集合成一个请求。而且,四个角色(客户端、协调器、源、以及目的地)可以是单独的***或一些***可承担多个角色。即,四方可以存在于一个、两个、三个、或四个物理位置中。
当整个处理完成时,协调器可向客户端402发送最终响应448。最终响应448可指出原始的客户端请求420已被满足,或存在错误。在一些实现方式中,没有最终响应448。在一些实现方式中,只有在错误情况时才有最终响应448。该处理可以在会话环境下发生。
参考图5,在更具体的实施例中,请求者客户端502向协调器服务器504发送客户端请求520。在该实施例中,请求520是用于数据从源(第一数据服务器506)移动至目的地(第二数据服务器508)。例如,协调器504可将初始协调器响应540发送至客户端502,以确认或拒绝请求520。协调器504确定如何最好地实现该移动,在该实施例中,其决定经由其自身将数据从源506移动至目的地508。即,例如,原因是在两个服务器之间没有更好(如,更快的)数据路径存在。对另一实施例,这可以是因为使数据从源506直接流向目的地508将会以不可接受的方式减缓更好的路径。不管是何具体原因,协调器服务器504向第一数据服务器506发送第一MOVE(或,READ)请求542。第一数据服务器506以或是错误消息或是所请求的数据来响应560。接着,协调器服务器504向第二数据服务器508写数据。
应当注意,该实施例证明了将此动作划分成一组经分割的协调器请求(A、B、&C),其可以形成为MOVE或WRITE。分割数只是一个实施例;在实践中可使用任何数目的分割。一些经分割的请求甚至可以采取可替换路线和/或利用协调器服务器504作为客户端而形成四方请求。在该实施例中,三个分割(A、B、&C)无序发送,且以一种方式证明请求不需被序列化或等待响应。更具体地,在该实施例中,向第二数据服务器508发送部分A 524,第二数据服务器508以部分A响应526回复。例如,该响应可以是确认或错误消息。在一些实现方式中,没有响应或只有在错误情形下才有响应。协调器服务器504发送经分割的协调器请求部分C 528,第二数据服务器508以部分C响应530回复。在该实施例中,不需要协调器服务器等待响应。在接收确认消息(如,部分C响应530)之前,协调器服务器可以发送额外的请求,如,经分割的协调器请求部分B 532。协调器服务器504发送经分割的协调器请求部分B 532,第二数据服务器508以部分B响应534进行响应。
在满足客户端请求520之后,协调器服务器504可以向客户端502发送最终响应548。响应548可以是成功确认或错误指示。该处理可在会话背景下发生。
数据服务器也可支持客户端分配的缓冲器元件,以在分段数据传输中提供数据资源的明确使用。可以扩展上述提出的协议以允许客户端分配缓冲器资源。在缓冲排列中,请求者能够请求使用缓冲器,控制缓冲器的使用期限和创建,继续直接地寻址存储资源,以及直接地寻址缓冲器。缓冲器的直接寻址允许缓冲器一旦被创建就可以像其他任何存储资源一样使用,即使是在缓冲器的约束内。缓冲器可以被绑至会话,并且当会话终止时被释放。缓冲器可具有关联的语义,例如,排队语义,减少所需的通信和同步以完成复杂处理。在有效带宽不是统一的情况下、在资源和最终目的地地理上离得很远的情况下、或在资源的可用性具有诸如可用性或速度的额外约束的情况下,可以将缓冲器用于分段传输。其他用途还包括独立于在***中别处使用的缓冲器大小而保持磁盘分配单元的大小。缓冲器以及其他动态创建的存储资源也可用于其他目的,例如,优化特定的使用模式内容可用性。
上述的图1至图5描述了用于内容存储和传输的***的各个方面。如上所述,在一些实施方式中,这种***包括分布式***内的多个节点,其提供对于存储资源的接口。例如,这些节点提供存储功能,用于在内容传输期间或是永久或是短暂的方式来保持数字内容。
一般来说,上述***包括对一种使用协议访问存储资源的方法的描述,涉及由第一方(“请求者”)接收请求,由第二方(“协调器”)协调以将数据从第三方(“数据源”)移动至第四方(“数据目的地”)。一般来说,第一方、第二方、第三方和第四方的组合可以是以不同角色作用的同一方。一般来说,所描述的请求不一定依赖于具有先进的语义模型的存储资源。
在一些实施方式中,使用语义缓冲器,其是更宽泛概念的语义存储资源的子类。这些缓冲器本质上是网络可访问资源,其可以约束协议也能增强协议。例如,一个缓冲器可定义缓冲器资源,以具有可以通过规范缓冲器资源的行为的访问协议而被调用的特定方法。
如下文中结合图6至图13所使用的,术语语义约束或语义模型涉及基于请求的内容来约束请求的处理。例如,处理可涉及到是否接受或拒绝请求以及对于何时实际处理请求的次序约束。例如,在结合图1至图5的上述对于存储资源的请求的多个实施例中,几乎没有任何约束应用到是否接受请求(假设其很好地形成且语义上是有意义的,例如,提到的已知存储资源)或请求被处理的顺序。
在内容存储和访问***的一些版本中,语义约束可基于所接收的请求顺序对处理请求(该请求对于存储资源而做出)的顺序施加约束。这种约束的一个实施例是,要求在存储设备中位置处写内容的请求必须在处理随后接收的对于从该位置读内容的请求之前完成。这种约束可以简化请求者的操作,其可以顺次发出多个请求。
在一些内容存储和访问***的版本中,使用语义约束以提供多个相关数据传输的分布协调方式,从而可以在没有实质正在进行的同步的情况下,有效地执行传输。在一些实施例中,协调涉及到使用中间存储资源,该存储资源实际上在从永久存储资源到内容的最终目的地的内容传输期间用作缓冲器。下面用于这种缓冲器的存储技术很大程度上是独立于语义模型的,例如,利用正在使用的磁盘或是固态存储技术。应当注意,在一些实施例中,中间存储并不暗含一定绑定至特定的存储设备或子***,而能够被直接配置和管理。
现在参考图6,示例性***600示范了语义约束的数据传输***的环境。请求者660做出协调器650的一个或多个请求,以在数据源610与数据目的地630之间实现传输。对于一些这种请求,请求者660利用中间存储服务器640,该服务器支持实现下面描述的一个或多个语义模型的缓冲器存储资源。在图6中,示出了连接***的部件的公共网络620。应当注意,一般来说,可以使用单独的网络,例如,使用不同的网络来用于内容从数据源610至缓冲器服务器640的传输,该网络与用在缓冲器服务器640与数据目的地630之间传输的网络不同。还应当注意,在一些实施例中,协调器也表现为缓冲器服务器。
在一些实施例中,请求者660进行选择以使用中间缓冲器服务器640,其涉及到的情形是在数据源与缓冲器服务器之间的通信特性(如,最大吞吐量、延迟、抖动等)不同于(如,实质上大于或实质上小于)缓冲器服务器与数据目的地之间的通信特性。
在一些实施例中,缓冲器服务器包括预定缓冲器。例如,正如以上结合图1至图5所描述的,使用命名机制,每一个缓冲器,更具体地,在存储缓冲器内存储位置的具体范围是可寻址的,在该命名机制中利用统一资源标识符(URI)指定缓冲器地址,标识用于缓冲器服务器的唯一名称空间以及在该名称空间内的唯一资源地址。有关URI的更多信息可在Uniform Resource Identifier(URI):Generic Syntax,Berners-Lee et al.,IntenetEngineering Task Force Standard 66,Network Working Group RFC 3986,2005年1月中得到。缓冲器也可绑至会话,从而当会话终止时,便释放缓冲器和任何关联的资源。
在一些实施例中,例如,基于所需原则来动态建立(如,分配)和释放缓冲器。例如,除了来自请求者(如,直接到缓冲器服务器,或经由协调器)的数据传输请求之外,请求者还可以发送缓冲器建立请求,例如,提供由缓冲器实现的语义模型的大小和规范,进而接收适当建立的存储资源(该情况中是缓冲器)的名称。在一些实施例中,基于涉及经命名的缓冲器的传输请求,对于举例说明缓冲器的请求是暗示的。在一些实施例中,要建立的资源的语义模型的规范可形成为来自一组已知模型(有或没有额外的参数)的选择,或者在一些实施例中,其可以形成为模型的详细规范。在一些实施方式中,存储资源在请求之前就存在,并且仅分配给请求者。在一些实施方式中,存储资源是为请求者专门建立的,并且当释放时其被销毁。
对于建立缓冲器的请求可包括资源空间(例如内存或磁盘空间)的预留或分配规范以及对于如何访问资源空间的语义约束。一旦成功建立,缓冲器服务器返回用于缓冲器的唯一标识符,允许直接(但语义上受约束)地访问由缓冲器控制的资源空间。建立缓冲器的过程可以由单一命令或通过客户端首先分配或预留资源空间然后请求缓冲器联系该空间的一系列命令来实现。一旦映射到资源空间,缓冲器能执行地址翻译和范围核对,从而映射的资源空间从偏移量0到缓冲器大小减1是可字节寻址的。通过缓冲器将资源访问限制到与缓冲器联系的资源空间。任何将访问超出缓冲器范围之外的资源空间的请求都会被拒绝。
缓冲器的语义约束构成一组如何以及何时可以访问资源空间的规则。如约束所要求的,缓冲器服务器通过环境地允许、排队、或拒绝请求来执行这些约束。语义约束的实施例可以是要求向资源空间写数据的第一请求必须在兑现任何从该资源空间读数据的请求之前完成。根据约束所决定的,读请求可被拒绝或排队等候延迟处理。语义约束减少前期的往返延迟,不然其是由终端到终端的同步产生的。即,没有添加的约束,客户端能通过等待至所分配的中间资源的每一个传输来协调数据到分配空间以及从分配空间的移动,以在发送任何从分配的中间资源的读指令之前完成,反之亦然。
不同的约束组适合于不同的访问类型。例如,缓冲器可以面向其后跟随多个读请求的单个写,缓冲器可以面向其后跟随单个读请求的多个写请求,或缓冲器可以面向不同程度的并发读和写。其他使用类型也可以由适当排列的缓冲器来处理。这些实施例中的一些在这里详述。应当注意,与其他网络存储操作一样,操作可以递归转换成构成操作。因此,从客户端角度,单个写可以转化为多个写。多个写或读可以转化为相应的单个写或读。
基本缓冲器
基本缓冲器不执行除了地址翻译和范围核对之外的功能。在这种情况下,同步是客户端的唯一职责。
读缓冲器
图7代表读缓冲器的状态转换。一经创建,缓冲器就处于空状态702,在该状态中,缓冲器等待向缓冲器写数据的请求(缓冲器写请求),并拒绝从缓冲器读数据的所有请求(缓冲器读请求)。一旦接收到缓冲器写请求,缓冲器就转换至写状态704,在该状态中,其使所有新缓冲器读请求排队等待直到所有的写请求完成为止。当写请求全部完成时,缓冲器转换至读状态706,在该状态中,其处理所有的缓冲器读请求直到接收到缓冲器写或缓冲器中断请求为止。一旦接收到写请求,缓冲器返回至写状态704,在该状态中其停止移除排队的读请求并排队任何新的读请求。该语义模型可要求轻(light)客户端同步,如在发出写操作之前完成所有的读操作。在一些实现方式中,在读队列中设置标记,并处理该读队列直到该标记。在一些实现方式中,使用多个读队列,其中,使用新队列来接收在写请求之后到达的读请求,而较早的队列继续被处理。这些模型也要求轻客户端同步,以阻止在读取数据期间的写入。如果在写状态704或读状态706中发生错误,缓冲器转换至清除错误状态760并中断所有排队的操作或可有效中断正在进行的操作。然后,缓冲器返回到空状态702。一旦接收到中断请求,缓冲器转换至中断状态780,并中断所有排队的操作或能有效中断正在进行的操作。然后,缓冲器返回到空状态702。
缓冲器写请求是指定缓冲器资源为数据传输目的地的写请求。如果写操作会溢出缓冲器,则请求被拒绝。
当使用读缓冲器和多个写请求时,缓冲器获益于使用表明写请求已完成的明确操作。写操作的暗示检测也是可能的。在一些实现方式中,因为操作可以从它们被服务器接收到的时刻就进行异步处理,也可使用刷新操作数以确保写操作(其完成一系列写操作)实际上是缓冲器能看到的系列中最后一个操作(这是引起缓冲器状态改变的操作)。在一些实现方式中,写请求中的信息(如,使用HTTP范围头或HTTP扩展头)使得缓冲器跟踪和检测何时已完成对于所有旨在被写入的数据的写入成为了可能。写完成的隐含检测在多种情况下是可能的,多种情况包括了要写入的数据量已知(如,在一个或多个写请求中表明),期望的写请求编号已知(如,表明请求是总数Y中的编号X),缓冲期空间被完全使用,或在预设的时间窗内未接收到写请求。
缓冲器读请求是指定缓冲器资源作为数据传输源的读请求。如果读操作会在缓冲器之外读取,则该请求被拒绝。当写操作正在进行中,在写请求被阻塞(排队)后接收缓冲器读请求。无此保护时,在写请求之前接收到的读请求被处理。在读之后有对于正在进行读取的缓冲器的区域产生影响的写,则读的结果是不确定的。客户端的职责是读请求跟随有相同区域的写请求,以(例如)通过发布冲突写之前等待写完成为止,以使用更合适的缓冲器或同步操作。使用提到的关于写完成检测的相同技术,读完成的检测可以是明示的或暗示的,例如,该技术包括读请求的列举或当整个缓冲器已经被读时预测读完成。这些检测读或写请求完成的技术可以与这里所述的任何语义模型一起使用。
写缓冲器
图8表示写缓冲器的状态转换。一旦创建,缓冲器就处于空状态802,在该状态中其等待向缓冲器写数据的请求(缓冲器写请求),并阻止从缓冲器读数据的所有请求(缓冲器读请求)。一旦接收到缓冲器写请求,缓冲器就转换至写状态804,在该状态中其执行所有接收到的写请求直到其接收到读请求为止。当缓冲器接收到读请求,其转换至读状态806,在该状态中其处理所有的缓冲器读请求直到读请求完成或接收到缓冲器中断请求为止。当处于读状态806时,写缓冲器排队所有的写请求。当读完成时,缓冲器转换回写状态804,并继续处理写请求。如果在写状态804或读状态806发生错误,则缓冲器转换至清除错误状态860,并中断所有排队的操作或可有效中断正在进行的操作。然后,缓冲器返回到空状态802。一旦接收到中断请求,缓冲器转换成中断状态880,并中断所有排队的操作或可有效中断正在进行的操作。然后,缓冲器返回到空状态802。
缓冲器写请求是指定缓冲器资源作为数据传输目的地的写请求。如果写操作会溢出缓冲器,则请求被拒绝。当读操作正在进行时,对于写缓冲器的写请求被阻塞(排队)。
缓冲器读请求是指定缓冲器资源作为数据传输源的读请求。如果读操作会在缓冲器以外读取,则此请求被拒绝。当使用多个读请求和一个写缓冲器时,缓冲器受益于使用表示读请求已经完成的操作。
在写之后跟随了对于正在写入的缓冲器的区域的写,则写的结果是不确定的。客户端的职责是写请求跟随有相同区域的读请求,以(例如)通过发布冲突读之前等待写完成为止,以使用更合适的缓冲器或同步操作。
读/写缓冲器
图9表示读/写缓冲器的状态转换。一旦创建,则缓冲器处于写状态904。如果缓冲器处于空状态902,它自动前进至写状态904。在写状态904中,读/写缓冲器执行接收的所有写请求,直到所有的写已经完成。缓冲器可接收明确的‘写完成’指示或它可隐含确定完成。在写状态904时,接收的读请求排队。一旦在写状态404时接收到最后的写请求,则缓冲器转换成读状态906。在读状态906,缓冲器执行所有排队的请求以及随后接收到的读请求直到所有读已完成为止。缓冲器可接收明确的‘读完成’指示或它可隐含确定完成。尽管完成在‘读完成’指示之前接收的读请求,以及排队在‘读完成’指示之后接收的读请求,但读请求不是必须按照任何特定的顺序执行的。如果该实现方式将‘读完成’指示绑定至读请求,则读请求和‘读完成’指示被处理,就像它们是在独立的消息中接收的,其中,读请求首先到达。一旦接收到‘读完成’指示,缓冲器转换回写状态904。
如果在写状态904或读状态906中发生错误,缓冲器转换至清除错误状态960,并中断所有排队的操作或可有效中断正在进行的操作。然后,缓冲器返回到空状态902。一旦接收到中断请求,缓冲器转换到中断状态980,并中断所有排队的操作或可有效中断正在进行的操作。然后,缓冲器返回到空状态902。
当读/写缓冲器处于读状态906时,它也将继续执行接收到的任何写请求,但是将会忽略任何‘写完成’指示。也就是,‘写完成’指示不被排队或记录。当缓冲器处于读状态906时,所做出的写请求可使正在被写的缓冲器的区域的读请求的结果不确定。客户端的职责是在没有读完成通知的情况下使用写请求,(例如)通过在发出冲突写之前等待直到读完成为止,以使用更合适的缓冲器或同步操作。
双缓冲器
图10表示双缓冲器实施例的状态转换。由双缓冲器管理的资源分成两个区。这些区可以是单个资源区域或两个不同的资源区域。一旦创建,双缓冲器就处于载入状态1004。如果缓冲器处于空状态1002,则其自动前进至载入状态1004。在载入状态1004中,双缓冲器执行所有接收的写请求,直到其接收到写完成通知或隐含确定两个区之一的写完成为止。为了方便,这是区1而仍在被写入的区是区2。在载入状态1004中,当双缓冲器接收到用于区1的写完成通知,则其转换到读-写状态1006。在读-写状态1006,双缓冲器处理用于区1的所有读请求以及用于区2的所有写请求。用于区2的读请求和用于区1的写请求则排队。在读-写状态1006,当双缓冲器接收到用于区2的写完成通知,则其转换到读-读状态1008。在读-读状态1008,双缓冲器处理所有的读请求,并排队所有的写请求。在读-读状态1008,当双缓冲器接收到用于区1的读完成通知,则其转换成读-写状态1010。读-写状态1010和读-写状态1006一样,其操作在相对区。在读-写状态1010,当双缓冲器接收到用于区2的写完成通知时,则其转换成读-读状态1012。除了接收区2的读完成通知将缓冲器推进下一个状态之外,读-读状态1012与读-读状态1008相同。在读-读状态1012,当双缓冲器接收到用于区2的读完成通知,则其转换成读-写状态1006。
读、写、错误、和中断(1060、1080)的处理与读/写缓冲器(960、980)相同。客户端经由完成通知来负责协调访问。
N-缓冲器
除了支持N个区之外,N-缓冲器与双缓冲器相同。
FIFO缓冲器
参考图11,先进先出(FIFO)缓冲器可使用语义约束来简化寻址。从先前留下的写请求中选择所有对于FIFO缓冲器的写请求。从先前留下的读请求中选择所有从FIFO缓冲器的读请求。向FIFO缓冲器资源的写具有以下效果:将数据写入紧接在缓冲器的当前有效内容之后的缓冲器部分。从FIFO缓冲器资源读具有以下效果:能从缓冲器开始转移数据,然后有效地将缓冲器剩下的有效内容向前移动同样数目。例如,通过更新缓冲器的逻辑到物理地址的映射,能够实现这种移动。
如果缓冲器是空,那么对于有足够空间的FIFO缓冲器的写不需要被拒绝。在一个实现方式中,由于先前写入的有效内容而能引起缓冲器溢出的写具有以下效果:在执行写之前,首先以溢出量来向前移动缓冲器的有效内容。也就是,可以通过抛弃缓冲器前部的一些有效数据来创建空间。取决于实现方式,向大于缓冲器的FIFO缓冲器的写或是被拒绝或是被截断。
图11表示FIFO缓冲器的状态转换。一旦创建,缓冲器就处于空状态1102,在该状态其等待向缓冲器写数据的请求(缓冲器写请求),并拒绝从缓冲器读数据的所有请求(缓冲器读请求)。一旦接收到缓冲器写请求,缓冲器就转换成写状态1104,在该状态其执行接收的所有写请求。当缓冲器接收到具有充足数据的读请求,则它转换成写-读状态1106,在该状态中缓冲器只要有充足的数据就处理所有的读请求或处理所有的读请求直到接收到缓冲器中断请求。当处于写-读状态1106时,写缓冲器继续处理所有的写请求。如果在缓冲器有充足的数据满足该请求之前读请求到达,则该请求排队。如果缓冲器在写-读状态1106,其转换回写状态1104,并排队读请求直到有充足的数据或直到接收到缓冲器中断请求为止。如果在写状态1104或在写-读状态1106发生错误,则缓冲器转换成清除错误状态1160,并中断所有排队的操作或可有效中断正在进行的操作。然后,缓冲器返回到空状态1102。一旦接收到中断请求,缓冲器转换成中断状态1180,并中断所有排队的操作或可有效中断正在进行的操作。然后,缓冲器返回到空状态1102。
在遵循上述FIFO方法的一些实施例中,FIFO仅需要(1+F)*Size,而不是使用2*Size双缓冲器来获得读与写之间的并发,其中F小于1并且由填充和清空缓冲器预期的延迟确定。
如上所述,在一些实施例中,按特定传输(即,诸如特定电影的特定内容单元的传输)的需要来分配缓冲器。分配可能需要创建缓冲器或从可用缓冲器中进行选择。当不再需要缓冲器时,就将其释放-或是销毁该缓冲器或是将其恢复到可用状态。在每个传输中使用的缓冲器大小和类型是由处理需求而确定的。可以由请求客户端或协调器命令(例如,按照对于客户端透明的方式)缓冲器的使用。
参考图12,在特定实施例中,请求者1260向协调器1250发送数据传输请求1272。请求1272用于协调器1250,以协调从源1210向目的地1230的数据移动。协调器1250分析请求,在该实施例中,确定适合于传输的缓冲器具体类型和位置。协调器1250向缓冲器服务器1240发送请求1274。请求1274用于缓冲器服务器1240,以分配所确定的适合于传输的合适的缓冲器大小和类型。在一些情况下,缓冲器服务器1240可以从现有可替换缓冲器1244组中分配缓冲器1242。在一些情况下,缓冲器服务器1240可以通过分配空间和指派对于空间的语义约束、创建新的缓冲器来分配缓冲器1242。然后,协调器1250影响经由缓冲器1242从源1210到目的地1230的数据传输。例如,协调器1250将请求1276发送至源1210(其用于向缓冲器写入数据的源)。协调器1250还将请求1278发送至目的地1230(其用于从缓冲器读取数据的目的地)。应当注意,缓冲器的语义可以协调涉及缓冲器的读和写,例如,其阻塞读直到相应的写产生合适的可用数据。当处理完成时,协调器1250可以向缓冲器服务器1240发送请求以释放缓冲器。
参考图13,流程图表示该操作类型。请求者[R]请求协调器[C]从源[S]向目的地[D]传输数据(1310)。然后,协调器分析请求的传输以确定是否应使用缓冲器(1320)。如果不需要缓冲器,则协调器在没有缓冲器的情况下执行传输(1324)。如果应该使用缓冲器,则协调器分析请求的传输以确定缓冲器最合适的大小和类型(1330)。然后,协调器请求中间缓冲器服务器[I]分配缓冲器[B](1340)。缓冲器服务器可以通过或是创建新的缓冲器或是通过选择和预定现有缓冲器来分配缓冲器。然后,协调器请求从源向缓冲器传输数据(1350)。由于现在缓冲器中有数据,则协调器请求数据目的地从缓冲器向目的地传输数据(1360)。缓冲器可能小于要移动数据的总大小。协调器可以重复(1364)从源向缓冲器(1350)以及从缓冲器向目的地(1360)移动数据的处理,直到移动所有数据为止。在一些情况下,接下来协调器请求缓冲器服务器释放缓冲器(1370)。
在一些实施例中,客户端请求分配缓冲器,然后把它当作用于将来处理的存储资源。例如,客户端可以期望将会有数个数据目的地,并希望使用缓冲器作为中转区。一旦源被读进缓冲器,则接着各种目的地从缓冲器接收数据,其减少了在源上以及在连接到源的网络上的负载。
上述图1至图13描述了用于内容存储和传送的***的方面。参考图14,在一些实施方式中,这种***1400驻存在大量的分布式计算平台1410上,该平台可以称为由通信网络(图14中未示出)耦合的“节点”。例如,大量的计算机通过诸如基于互联网协议(IP)的局域数据网络或广域数据网络的一个或多个数据网络来互连。为了避免随着节点数目增加到(例如)数百或数千节点或更多的限制(例如,通信瓶颈、潜在的死锁等),一种协调节点操作的方法涉及分割用于实施各种执行各种功能和/或为多个不同组1420提供服务的部件1415。在不旨在通过使用这些术语暗示这些组任何特定特性单独情况下,下面将这些组称为“独立协调域”或“级(planes)”。
每一级1420均与一个或多个其他级通信,至少一些级与***的外部客户端1430通信。在一些实施方式中,级被排列为线性序列,每一级均与序列中相邻的级通信,但是一般来说,每一级并不限于与特定的其他级通信。
在一些实施例中,级之间的通信基于请求-确认方法,在该方法中请求消息从一级传递到另一级,一段时间之后,回传确认和/或请求的动作已经完成的指示。
作为可以被分成级的内容存储和访问***的部件1415的实施例,其是用于以下功能的部件:对于存储在***中特定的内容项用于共同处理内容存储资源的分配。例如,这些部件负责确定保存了电影的数字表示的特定磁盘驱动器可以被稍后访问,用于呈现给观众。分配功能要求不同节点间一定程度的协调,例如,以避免以下情况:不同节点中的每一个均接受不同的新内容项,但以冲突或其他不期望的方式将相同的存储资源分配给不同的新项。
作为可以被分组至级1420的部件1415的另一实施例,其以实质上不同于其他级的时标操作。例如,负责***中的从节点到节点的低层数据传输的部件以本质上比负责为加入到***的新内容项分配资源的部件更快的时标进行操作。与其他级相比,这种组件也可以具有非常不同的节点间协调要求,例如,以在没有要求在驻存该级的所有节点中的集中协调的情况下,在两个或多个节点间使用通信协议以保持整个级期望的一致性。
一般来说,每一个级1420均包括驻存在***的多个不同节点1410上的部件1415,每一级均实现独立的方法以在级内为控制的资源在部件间保持特定的一致性模型。例如,在部件分配共享资源的级中,级的部件根据用于该级的一致性模型进行操作,该部件确保不会以冲突的方式疏忽地分配资源。
级间的通信被分布,例如,利用存在于***的任何节点处级间(即,级的部件间)的单独通信路径。一般来说,将部件分组至级使得在级间的交互不需要实际上同步或级间的其他协调类型。例如,由控制级的外部接口提供的一致性模型可能实质上弱于用于级内的内部功能的一致性模型。
在一些实施方式中,级间提供的一致性模型并没有对于在不同的通信端口处做出的请求的执行顺序提供保证。例如,如果在不同的节点以一顺序做出两个请求,并不确保会以该顺序处理请求,甚至如果在一个节点处以一定顺序做出两个请求,处理请求的顺序也是无法保证的。使用这种一个弱一致性模型,为其他级提供服务的级,在不需要根据受限的一致性模型协调其部件的情况下,无约束地实施其内部操作。在其他实施方式中,控制级可通过其外部接口提供稍微更受限的一致性模型,例如,在一个节点处保持顺序但在不同的节点中未保持顺序。一般来说,用于级的内部一致性模型比通过级的外部接口所提供的一致性模型更受限制。
利用这种级间相对弱同步,内部一致性的实现方式可以适合于级内所执行的功能,并可以提供期望的扩展特性。例如,在资源分配功能的情况下,一个极端是,分配信息集中在单个节点处,而其他节点与此中央节点通信所有的请求。这种实现方式可提供简单性,但可能具有不期望的通信特性,例如,不期望地导致与中央节点的大量通信或不期望地导致中央节点处理请求的延迟。在另外的实现方式中,分布分配信息以避免大量的节间通信。例如,在不同节点处的部件可以通信以预先分配一部分共享资源(其将用于处理由外部接口到节点处级的请求),并且部件可以相对慢地通信和/或用相对少的数据以保持在每个节点处预先分配的空闲资源量的平衡。然而,应当注意,分配信息的内部一致性的实现方式独立于级的外部一致性。例如,在一个节点首先做出的请求可能不会得到响应于在另一节点处做出的稍后请求所提供的资源。因为级并不确保外部请求的顺序,因此一般来说存在更多和优选的内部一致性的可替换实现方式,以实现由级的部件所实现的期望功能。
在对于内部请求一致性进行限制或对其没有做出保证的实施方式中,每个级均负责实现其自身的一致性。例如,如果第一级要求在相同或不同节点做出第二请求之前来完全服务第二级的第一请求,第一级必须等待以确定请求已经完成,例如,在发出第二请求之前,通过从第二级接收确认。
如上所述,在一些实施方式中,功能至不同的级的划分至少部分地基于在级内功能操作不同时标。例如,在以相对慢的时标和相对弱的延迟要求进行执行的级中,产生较高延迟的协调方法可能是可接受的。例如,在级内的任何时刻只有单个节点能访问共享资源的令牌传递或锁定方法可以是这种协调方法的一个实施例。另一方面,在另一级处数据传输功能可能无法容忍可由这种协调方法所引入的延迟。通过将功能分至不同级,保持每个级内的一致性的方法可以适应于每个级中功能操作(如,延迟要求)的时标。
在一些实施方式中,不同节点的不同级处的部件可以分离成节点处的不同进程单元。这种进程单元的实施例是操作***进程、轻量进程、以及线程。例如,通过使每个进程仅属于单个级,避免或最小化了级间的交互(例如阻塞交互)。在一些实施方式中,执行进程单元的调度和/或优先化方法可以匹配不同级的需求。例如,特定的级可以具有高于其他级的优先权,因此其可以先于其他级占有执行,并且在时间共享方法中可以具有与其他级不同的时间片持续时间。
在一些实施方式中,级内的通信可使用不同于级间通信的通信资源。例如,可以使用单独的网络在数据传输级中部件间传递数据,而不同网络可用于在其他级处和级间通信。类似地,在不同级处可使用不同类型的通信方法。例如,在特定的级处可以使用分组交换的数据通信,在其他级(例如在数据传输级)处可以使用专用的点对点通信。
参考图15,内容存储和传送***1500的实施例使用五个独立的协调域或级1510-1550。每个级支持分布式的相关和协同功能组,其能不依赖于级间的严格协调而在正常条件下操作。存在着级间的状态和环境与级间的消息传输之间的映射。移动或降低级间协调要求有助于改进***的性能和可扩展性。
图15中所示的五个级包括以下。
·***级1510部件提供整个***的总体可视性和管理;***级具有整个***的视野
·内容级1520部件组织和管理如何在***上存储内容
·会话级1530部件发起会话、终止会话、分配支持会话所需的资源、以及一般地管理会话
·访问级1540部件从存储器请求数据传输
·传输级1550部件执行数据传输
最严格的实时性能要求是在图15中所示***的访问1540和传输1550级中。其他三个级通常具有弱严格的性能需求,并可以根据性能以外的因素(例如,实现难易、设备成本、特征的丰富性、或扩展的难易)被优化。如上所述,尽管不一定统一分布在***的每个节点,但每个级本身是一个分布式***环境,并可以被认为是在整个***中存在。
在该示例性应用中,***级1510具有整个***的总体可视性和管理。***级包括配置管理、***控制、***监控、和事件/状态记录功能。用于***级中所执行的操作没有(或相对弱的)实时性能需求。在一些实施方式中,***级中所有操作是尽最大努力执行的,并且可以按照不影响其他级中的操作的实时要求的方式来实现。***级的部件可以为***提供外部接口,例如,管理客户端访问***状态信息。
配置管理(***级的一个功能),其保持***中所有部件的总体连接映射,下至各单独的可引用或可替代部件(例如,磁盘驱动器或主板)的细节水平的完整拓扑结构。配置管理功能保持关于***中每个部件功能(例如,健康状况和性能监控)的信息,如,关于额定参数的磁盘性能。在***操作期间动态更新配置信息,以在发生改变时反映***的当前状态。应当注意,***级内可用的配置信息可能暂时地与***的真实状态稍不同步。但是,执行***级内的实现逻辑,从而没出现跨***的操作问题。例如,如果***的真实状态使得基于级内状态的操作失败,则每个操作负责调解。
由内容级使用配置信息以确定如何最有效地分配内容。由会话级使用配置信息和当前的***状态,以确定如何给会话分配***资源。在***级内,由***管理和控制部件使用配置信息。例如,如果特定的磁盘开始显示出可能失败的迹象,则可以调度用于该磁盘的维护,并且从该磁盘移除内容和负载。当***正常操作但其开始达到操作阈值(如,较少的剩余存储容量)时,出现另一个实施例。由***的其他部件的需求来确定有关每个部件残留信息量和类型。***级中很多功能和操作是由***管理需求和特定应用的使用需求驱动的。
内容级1520提供整个***中的总体内容管理。内容级包括内容供应功能和用于保持供应结果的对象目录。在内容级中执行的操作没有严格的实时性能要求;所有的操作都尽最大努力,并可以按照不影响其他级中操作的实时要求的方式来执行。
内容供应功能负责对于存储器的内容分配和指派。确定如何供应内容,以优化***中使用该内容的操作对象。这种对象包括可访问性(通俗性)、恢复性、以及完整性。也可包括额外的目标(如,安全性、拓扑相似性、或地理相似性)以及还可以依赖于特定***装置的特征。再者,内容可以具有生命周期模型,其描述供应对象如何随时间变化。内容供应可遵循预先设定的计划,根据模式选择方案的参数选择多个预先设定计划之一,或使用自动化的过程接近最优排列。
在一些实施方式中,在***正常操作期间,使用选择模式以供应内容。单独的内容具有操作对象(诸如可访问性、恢复性、以及完整性的特定值)。选择一个计划以供应满足操作对象的内容。内容级负责该处理。
会话级1530体现和支持一个或多个媒体访问机制。媒体访问机制的实施例包括HTTP访问、Windows Media ServerTM、FlashServerTM,Helix DNATM服务器,和其他这种访问机制。会话级部件管理用于访问机制而创建的会话并且管理服务这些会话所需的资源。会话级中主要功能部件包括访问机制服务器(如,媒体服务器),许可(包括会话管理),资源预留(和管理),以及对象访问和传输。会话级包括对于***外部客户端的接口,例如,从***请求特定的内容。
会话级在整个***中桥接(bridge)实时和非实时操作。除了访问和传输相关操作之外,操作没有严格的实时性能要求。会话级操作通常具有软实时性能要求,这意味着这种操作具有定义的性能对象但没有严格的实时约束。没有对于其他级中非实时操作的实时依赖性。严格的实时依赖性在会话级内局部化并被分离,这意味着会话协调要求是局部化和界限化(如,在会话内而不是在会话间的协调)。会话级操作可以依赖访问和传输级操作的严格实时性能特征。
访问机制请求创建来自许可部件的会话。一般来说,由于对该机制的外部请求(如,利用视窗媒体服务器访问机制,远程视窗媒体客户端发起流),因此访问机制可实现此操作。许可部件负责确定是否有充足的***资源以准许所请求的会话。如果充足的资源是可用的,则创建会话并预留在会话持续或占用期间所需的资源;如果没有充足的资源,则拒绝会话创建请求。最后,当不再需要会话或根据请求,则终止会话,并释放所预留的资源。
每个访问机制可以有一个稍微不同的会话概念。例如,一个特定的访问机制可能不需要在整个会话持续期间预留资源,在这种情形下,如何和/或何时发生资源预留可以不同于基本机制。许可部分地依赖于在内容供应和***配置期间做出的决定。本质上,尽管在不同的时间级中被分离和操作,但***配置、内容供应、以及许可仍然是协作的。
***被配置为支持预期的额定工作负载(即,模型工作负载)。在正在进行的内容供应期间,根据***上所请求的来供应内容。如果供给总体上是成功的,则总体供应将支持所规定的工作负载,该负载大概相当于预期的额定负载或在预期的额定负载范围内。当请求每一个新的会话时,其资源要求已被分解成***配置和供应。因此,对于是否支持一个新会话的决定是查找新会话是否适合规定的工作负载的快速问题。
如果新会话偏离规定的工作负载,但仍然可以被支持,则能够创建此会话,并且可以信号通知其他操作以确定***是否应该被重新供应或重新配置。如果新会话会超过规定的工作负载,则可以信号通知其他操作以确定***是否应该被重新供应、重新配置、或升级。
访问和传输级提供数据移进或移出存储器的机制。访问和传输是单独的级但概念上紧密链接。访问级做出的请求导致传输级中数据传输。在一个示例性配置中,在访问服务器和存储服务器之间桥接访问和传输。存储服务器主要在传输和访问级的时间环境下操作。
访问级1540和传输级1550的每个部件均具有显著的实时性能要求。一种关系存在于会话级、访问级、和传输级中各自的实时要求之间,但此关系限于单独的请求。在请求之间没有顺序规则-请求顺序和传输完成顺序并不保存。
作为级操作的实施例,会话级中媒体服务器部件向访问级1540的数据存储访问部件发出对于数据块的请求,其有选择地指定需要数据的特定时间(限期)以满足其同步传送要求。为了满足对于数据块的请求,访问级中数据存储访问部件向存储子***做出请求以(例如)从磁盘存储器获取数据。
在一些实施方式中,存储子***是***中的节点,其驻存在访问级和传输级。由访问级中存储子***中的部件请求数据,并由传输级中存储子***的部件接收该请求。传输级不需要确保来自访问级的请求的操作顺序。然后,传输级中传输部件向媒体服务器(其是会话级的一部分)传送所获取的数据。媒体服务器部件的限期是在整个操作链。
当未完成的请求数目增加时(例如,随着同时会话数目的增加),可能出现复杂性。对于每个期限,访问延迟(如,磁盘的寻道时间)是很重要的,并且多个传输面临冲突(如,因为它们在网络中发生)。在具有15000个会话的示例性配置中,所有的会话都具有严格的实时要求,在4个存储器和4个访问服务器中请求总共37.5Gbs。在存在磁盘、服务器、和其他部件故障时,***需要以可预见或规定的水平继续操作并提供服务。设计多个级方法以通过减少同步点(如,根据一致性模型,进程在此点被阻塞,等待其他进程达到一定状态)来实现性能水平。
明确的分离访问和传输消除了对磁盘调度、缓冲器管理、以及数据传输的限制,使得每一个均能够被局部地(如,在单个级内)优化。普遍降低了在访问和传输级内对于协调的需要,并且由在会话许可、内容供应、以及***配置期间做出的决定对其进行管理。访问和传输级内的功能从很多这些决定中分离。抽象工作负载和所供应的工作负载提供隐含协调和同步的环境。因此,只要访问和传输在供应的工作负载所指示的界限内,就可以很大程度地避免明确的协调。通常,存储服务器内或在其之间的请求间不需要隐含协调。消除这种限制移除了对于缩放的主要障碍。
除了内容存储和传送***之外,上述方法适用于其他***。例如,可使用这些方法对具有一个或多个管理和协调功能组以及一个或多个时间决定功能组的其他分布式***进行寻址。
一般来说,设计方法主要显现在***的运行时间实现方式中,例如,在进程及其进程间通信的要求。在一些实现方式中,分离成不同的级显现在***规范中,但可能不一定明确地显现在运行实现方式中。例如,编译(或其他软件构建进程)可以采取不同级的规范,并将它们组合成用于不同节点操作的规范。
在一些实施例中,一些级在软件中实现而其他级在硬件中实现。例如,快速时标级可以根据硬件中级的规范来实现,而慢速时标级可以在软件中实现。
一般来说,本说明书中所描述的***元件和功能操作可以在数字电子电路、或在计算机硬件、固件、软件、或其组合中实现。它们可以作为计算机程序产品(即,确实体现在例如机器可读存储设备的信息载体或传播信号中的计算机程序)来实现,用于由例如可编程处理器、计算机、或多个计算机的数据处理装置执行或控制数据处理装置的操作。可以按照包括了编译或解释语言的任何形式的编程语言来编写计算机程序,并且可以按照包括了作为独立程序、或作为模块、部件、子程序、或适合在计算环境使用的其他单元的任何形式来部署计算机程序。可以部署计算机程序使其在一台计算机或是在一个站点处或是分布在多个地点处并由通信网络连接的多台计算机上执行。
上述的方法步骤可以通过一个或多个可编程处理器执行,该处理器执行计算机程序以通过对输入数据进行操作并产生输出来执行功能。还可以通过例如FPGA(现场可编程门阵列)或ASIC(特定用途集成电路)的特殊目的逻辑电路来执行方法步骤,并且本发明的装置可以实现为例如FPGA(现场可编程门阵列)或ASIC(特定用途集成电路)的特殊目的逻辑电路。
本说明书中所描述的***和所有功能操作可以在数字电子电路、或在计算机硬件、固件、软件、或其组合中实现。该***可以作为计算机程序产品(即,确实体现在例如机器可读存储设备的信息载体或传播信号中的计算机程序)来实现,用于由例如可编程处理器、计算机、或多个计算机的数据处理装置执行或控制数据处理装置的操作。可以按照包括了编译或解释语言的任何形式的编程语言来编写计算机程序,并且可以按照包括了作为独立程序、或作为模块、部件、子程序、或适合在计算环境使用的其他单元的任何形式来部署计算机程序。可以部署计算机程序使其在一台计算机或是在一个站点处或是分布在多个地点处并由通信网络连接的多台计算机上执行。上述的方法步骤可以通过一个或多个可编程处理器执行,该处理器执行计算机程序以通过对输入数据进行操作并产生输出来执行功能。还可以通过例如现场可编程门阵列(FPGA)或特定用途集成电路(ASIC)的特殊目的逻辑电路来执行方法步骤,并且***的装置可以实现为例如现场可编程门阵列(FPGA)或特定用途集成电路(ASIC)的特殊目的逻辑电路。
通过举例的方式,适合计算机程序执行的处理器包括通用和专用微处理器,和任何种类数字计算机的任何一个或多个处理器。一般来说,处理器接收从只读存储器或随机存取存储器或两者的指令和数据。计算机的主要部件是用于执行指令的处理器以及用于存储指令和数据的一个或多个存储设备。一般来说,计算机还包括例如磁盘、磁光盘、或光盘的一个或多个用于存储数据的大规模存储设备,或计算机运行地耦合以接收来自一个或多个大规模存储设备的数据或向其传输数据或是这两者。适合具体化计算机程序指令和数据的信息载体包括非易失性内存,通过举例的方式,其包括如EPROM、EEPROM、和闪存设备的半导体存储设备;例如内部硬盘或可移动硬盘的磁盘;磁光盘;以及CD-ROM和DVD-ROM磁盘。可以通过特殊用途的逻辑电路来补充处理器和内存,或其可以并入逻辑电路中。
应当理解,前面的描述旨在阐述而非限制***的范畴,***的范围由所附权利要求的范畴来限定。其他实施方式在以下权利要求的范围内。
Claims (10)
1.一种用于网络存储的方法,包括:
由网络设备接收对于在第一存储资源的多个存储资源元件中的一个存储资源元件的第一可寻址部分与第二存储资源的多个存储资源元件中的一个存储资源元件的第二可寻址部分之间传输数据的请求,所述第一存储资源与第一寻址机制相关联,并且所述第二存储资源与不同于所述第一寻址机制的第二寻址机制相关联;
由所述网络设备确定标识所述第一可寻址部分的第一标识符以及标识所述第二可寻址部分的第二标识符,所述第一标识符和所述第二标识符被包括在所述请求中;
由所述网络设备基于所述第一寻址机制和所述第一标识符,标识所述第一存储资源的所述多个存储资源元件中的所述一个存储资源元件的所述第一可寻址部分;
由所述网络设备基于所述第二寻址机制和所述第二标识符,标识所述第二存储资源的所述多个存储资源元件中的所述一个存储资源元件的所述第二可寻址部分;以及
由所述网络设备基于所标识的所述第一可寻址部分和所标识的所述第二可寻址部分,导致所述数据在所述第一存储资源的所述多个存储资源元件中的所述一个存储资源元件与所述第二存储资源的所述多个存储资源元件中的所述一个存储资源元件之间的传输。
2.根据权利要求1所述的方法,其中所述网络设备管理所述第一存储资源的所述多个存储资源元件,另一网络设备管理所述第二存储资源的所述多个存储资源元件,
其中导致所述数据的所述传输包括:
从所述第一可寻址部分接收所述数据,
基于接收所述数据而生成第二请求,所述第二请求包括:
将接收到的所述数据写入所述第二可寻址部分的指令;
所述第二标识符;以及
接收到的所述数据,以及
向所述另一网络设备传输所述第二请求,以导致接收到的所述数据被写入所述第二可寻址部分。
3.根据权利要求1所述的方法,其中所述请求包括超文本传输协议HTTP请求。
4.根据权利要求1所述的方法,其中所述请求包括超文本传输协议HTTP请求,所述HTTP请求包括以下之一:将所述HTTP请求标识为同步请求的信息,或将所述HTTP请求标识为异步请求的信息。
5.根据权利要求1所述的方法,其中所述请求包括标识用于在所述第一存储资源的所述多个存储资源元件中的所述一个存储资源元件与所述第二存储资源的所述多个存储资源元件中的所述一个存储资源元件之间传输所述数据的时间量的信息,并且
所述方法还包括:
确定所述时间量是否足以使所述数据在所述第一存储资源的所述多个存储资源元件中的所述一个存储资源元件与所述第二存储资源的所述多个存储资源元件中的所述一个存储资源元件之间传输,以及
当所述时间量不足以使所述数据在所述第一存储资源的所述多个存储资源元件中的所述一个存储资源元件与所述第二存储资源的所述多个存储资源元件中的所述一个存储资源元件之间传输时,向所述请求的发送方发送响应,指示所述请求被拒绝。
6.根据权利要求1所述的方法,其中所述请求还包括将所述请求标识为与一个会话相关联的多个请求中的最后一个请求的信息。
7.一种用于网络存储的***,包括:
由多个节点中的一个或多个节点管理的多个存储资源,每个所述存储资源与不同的标识符相关联,所述标识符标识特定寻址机制以用于对每个存储资源的一个或多个存储元件的物理位置进行寻址;以及
所述多个节点中的所述一个或多个节点中的第一节点,用以:
接收传输存储于所述多个存储资源的第一存储资源中的第一物理位置的数据的请求,接收的所述请求包括超文本传输协议HTTP请求,并且所述HTTP请求包括第一标识符和第二标识符,所述第一标识符标识所述第一存储资源中的所述第一物理位置,所述第二标识符标识所述多个存储资源中的第二存储资源中的第二物理位置;
处理接收的所述请求,在处理接收的所述请求时,所述第一节点用以:
基于与所述第一存储资源相关联的所述第一标识符,标识所述第一存储资源中的所述数据的所述第一物理位置的第一地址,所述第一地址符合所述第一存储资源的第一寻址机制,以及
基于与所述第二存储资源相关联的所述第二标识符,标识所述第二存储资源中的所述第二物理位置的第二地址,所述第二地址符合所述第二存储资源的第二寻址机制;以及
基于处理接收的所述请求,导致所述数据从所述第一存储资源中的所述第一物理地址向所述第二存储资源中的所述第二物理地址的传输。
8.根据权利要求7所述的***,其中所述多个存储资源的中的存储资源的每一个部分与以下至少一项相关联:
与直接寻址机制相关联的第一标识信息,所述直接寻址机制指定所述存储资源上的物理位置;或者
与抽象寻址机制相关联的第二标识信息,所述抽象寻址机制指定所述存储资源的逻辑单元数目。
9.根据权利要求7所述的***,其中所述多个存储资源中的存储资源的每个部分均与如下标识信息相关联,所述标识信息与使用直接寻址和抽象寻址的组合的寻址机制相关联。
10.根据权利要求7所述的***,其中所述第一存储资源的一个或多个部分与第三标识符相关联,所述第三标识符与不同于所述第一寻址机制和所述第二寻址机制的第三寻址机制相关联,以及
其中所述第一存储资源的一个或多个部分与第四标识符相关联,所述第四标识符相关联,所述第四标识符与不同于所述第一寻址机制、所述第二寻址机制和所述第三寻址机制的第四寻址机制相关联。
Applications Claiming Priority (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/170,787 | 2008-07-10 | ||
US12/170,769 US20100011091A1 (en) | 2008-07-10 | 2008-07-10 | Network Storage |
US12/170,787 US8706900B2 (en) | 2008-07-10 | 2008-07-10 | Dynamic storage resources |
US12/170,624 US8650270B2 (en) | 2008-07-10 | 2008-07-10 | Distributed computing with multiple coordinated component collections |
US12/170,769 | 2008-07-10 | ||
US12/170,624 | 2008-07-10 | ||
PCT/US2009/050057 WO2010006132A2 (en) | 2008-07-10 | 2009-07-09 | Network storage |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102132540A CN102132540A (zh) | 2011-07-20 |
CN102132540B true CN102132540B (zh) | 2015-06-10 |
Family
ID=41151915
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN200980133056.1A Active CN102132540B (zh) | 2008-07-10 | 2009-07-09 | 网络存储 |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP2297921B1 (zh) |
CN (1) | CN102132540B (zh) |
WO (1) | WO2010006132A2 (zh) |
Families Citing this family (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7779175B2 (en) | 2007-05-04 | 2010-08-17 | Blackwave, Inc. | System and method for rendezvous in a communications network |
US8954976B2 (en) | 2008-07-10 | 2015-02-10 | Juniper Networks, Inc. | Data storage in distributed resources of a network based on provisioning attributes |
US8887166B2 (en) | 2008-07-10 | 2014-11-11 | Juniper Networks, Inc. | Resource allocation and modification using access patterns |
US8650270B2 (en) | 2008-07-10 | 2014-02-11 | Juniper Networks, Inc. | Distributed computing with multiple coordinated component collections |
US9176779B2 (en) | 2008-07-10 | 2015-11-03 | Juniper Networks, Inc. | Data access in distributed systems |
US8099402B2 (en) | 2008-07-10 | 2012-01-17 | Juniper Networks, Inc. | Distributed data storage and access systems |
US8706900B2 (en) | 2008-07-10 | 2014-04-22 | Juniper Networks, Inc. | Dynamic storage resources |
US8191070B2 (en) | 2008-07-10 | 2012-05-29 | Juniper Networks, Inc. | Dynamic resource allocation |
US8364710B2 (en) | 2008-07-10 | 2013-01-29 | Juniper Networks, Inc. | Model-based resource allocation |
US9066141B2 (en) | 2009-01-21 | 2015-06-23 | Juniper Networks, Inc. | Resource allocation and modification using statistical analysis |
US9438665B1 (en) | 2013-06-18 | 2016-09-06 | Amazon Technologies, Inc. | Scheduling and tracking control plane operations for distributed storage systems |
US10931776B2 (en) | 2013-12-31 | 2021-02-23 | International Business Machines Corporation | Adaptive data fetching from network storage |
CN107566505A (zh) * | 2017-09-15 | 2018-01-09 | 郑州云海信息技术有限公司 | 数据存储资源管理方法、主节点、***、装置及存储介质 |
US11422864B2 (en) | 2018-09-28 | 2022-08-23 | Convida Wireless, Llc | Advanced resource link binding management |
GB2579071B (en) | 2018-11-19 | 2022-03-02 | Canon Kk | Method and apparatus for processing requests for thumbnail images in a video surveillance system |
US11153165B2 (en) | 2019-11-06 | 2021-10-19 | Dell Products L.P. | System and method for providing an intelligent ephemeral distributed service model for server group provisioning |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1652090A (zh) * | 2005-02-23 | 2005-08-10 | 北京邦诺存储科技有限公司 | 网络存储***中的数据管理方法及其构建的网络存储*** |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030229689A1 (en) * | 2002-06-06 | 2003-12-11 | Microsoft Corporation | Method and system for managing stored data on a computer network |
US7120654B2 (en) * | 2002-08-20 | 2006-10-10 | Veritas Operating Corporation | System and method for network-free file replication in a storage area network |
US20060190552A1 (en) * | 2005-02-24 | 2006-08-24 | Henze Richard H | Data retention system with a plurality of access protocols |
US7620981B2 (en) * | 2005-05-26 | 2009-11-17 | Charles William Frank | Virtual devices and virtual bus tunnels, modules and methods |
US20060274787A1 (en) * | 2005-06-07 | 2006-12-07 | Fong Pong | Adaptive cache design for MPT/MTT tables and TCP context |
-
2009
- 2009-07-09 EP EP09790203.5A patent/EP2297921B1/en active Active
- 2009-07-09 CN CN200980133056.1A patent/CN102132540B/zh active Active
- 2009-07-09 WO PCT/US2009/050057 patent/WO2010006132A2/en active Application Filing
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1652090A (zh) * | 2005-02-23 | 2005-08-10 | 北京邦诺存储科技有限公司 | 网络存储***中的数据管理方法及其构建的网络存储*** |
Also Published As
Publication number | Publication date |
---|---|
EP2297921B1 (en) | 2021-02-24 |
WO2010006132A3 (en) | 2010-03-04 |
EP2297921A2 (en) | 2011-03-23 |
WO2010006132A2 (en) | 2010-01-14 |
CN102132540A (zh) | 2011-07-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102132540B (zh) | 网络存储 | |
RU2649788C1 (ru) | Способ и система для обработки запроса на транзакцию в распределенных системах обработки данных | |
US20100011091A1 (en) | Network Storage | |
US8706900B2 (en) | Dynamic storage resources | |
CN110462589A (zh) | 本地装置协调器中的按需代码执行 | |
US7490111B2 (en) | Efficient handling of mostly read data in a computer server | |
US20220150181A1 (en) | Distributed database-driven resource management and locking in a cloud native mobile core network node architecture | |
US7853701B2 (en) | Method for intelligent, self-managed, decentralized connection pool management pool | |
US8650270B2 (en) | Distributed computing with multiple coordinated component collections | |
CN103155522B (zh) | 在交通工具和远程应用服务器之间进行通信的方法和*** | |
CN103596066B (zh) | 一种数据处理方法及装置 | |
KR100911058B1 (ko) | 메타데이터 서버 검색 방법 | |
CN103312624A (zh) | 一种消息队列服务***和方法 | |
US20120239620A1 (en) | Method and system for synchronization mechanism on multi-server reservation system | |
JP7118726B2 (ja) | ワークフローエンジンフレームワーク | |
CN103947140A (zh) | 用于位置无关软件的需求驱动的部署的***和方法 | |
JP2000500940A (ja) | レジストリ通信ミドルウェア | |
CN105122772A (zh) | 通过头部交换服务器状态和客户端信息以用于请求管理和负载平衡 | |
CN100544347C (zh) | 在单个***中支持多个本机网络协议实现 | |
CN104160680A (zh) | 用于透明代理缓存的欺骗技术 | |
CN104662539A (zh) | 存储并检索数据的方法和*** | |
KR100989976B1 (ko) | 가변적인 토큰 활성화를 구비한 링 네트워크 | |
CN100353307C (zh) | 一种存储***以及存储数据的方法和读取数据的方法 | |
CN102316154A (zh) | 优化对基于联盟基础结构的资源的访问 | |
CN112637037A (zh) | 跨地域容器通讯***、方法、存储介质及计算机设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C53 | Correction of patent of invention or patent application | ||
CB02 | Change of applicant information |
Address after: California, USA Applicant after: Juniper Networks, Inc. Address before: California, USA Applicant before: Jungle network |
|
COR | Change of bibliographic data |
Free format text: CORRECT: APPLICANT; FROM: NETSCREEN TECHNOLOGIES INC. TO: JUNIPER NETWORKS INC. |
|
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |