具有自动负荷平衡和性能调节的高可用网络文件管理器的制造方法

具有自动负荷平衡和性能调节的高可用网络文件管理器的制造方法
【专利摘要】提供用于经由群的多个节点导出一个或多个文件系统的技术。导出的文件系统中的一个或多个可以经由群的单个节点同时导出。创建束、或群中的节点与文件系统之间的映射。束表示分配给节点的工作量。响应于故障转移、新节点增加到群、或响应于负荷平衡确定，束被从一个节点重新分配到群中的另一个节点。
【专利说明】具有自动负荷平衡和性能调节的高可用网络文件管理器
【技术领域】
[0001]本发明涉及文件系统，并且更具体地涉及管理导出一个或多个文件系统的节点群。
【背景技术】
[0002]自从网络文件系统(NFS)协议于1984年开发以来，客户端设备的用户已能够通过网络以类似于局部存储器被访问的方式访问文件。NFS后的基本前提是简单客户端/服务器模型。在NFS服务器上的目录被共享，NFS客户端挂接那些目录，并且然后对客户端机器上的用户看来像仅仅是另一个文件系统。
[0003]下列是典型的Unix式情况的示例，其中一个机器(客户端)需要访问存储在另一个机器(NFS服务器)上的数据。首先，NFS服务器执行NFS守护过程(默认作为nfsd运行)以便使得它的数据一般可用于客户端。第二，管理员通过导出目录的名称和参数(通常利用/etc/exports配置文件和exportfs命令)确定使得什么数据可用。第三，NFS服务器的安全管理保证它可以承认和批准验证的客户端。第四，NFS服务器的网络配置保证适当的客户端可以通过任何隔火墙系统与NFS服务器协商。第五，客户端机器请求访问导出的数据，通常通过发出mount命令。此步骤可以包括NFS客户端询问NFS服务器(利用rpcbind)NFS服务器正在使用哪一个端口、NFS客户端连接到NFS服务器(利用nfsd)、以及nfsd将请求传递给mountd。如果每个步骤成功,客户端机器的用户然后可以观看并且在允许的参数之内与NFS服务器上挂接的文件系统交互。
[0004]当前网络文件服务器向许多客户端导出文件系统。这些文件系统在可用性方面受限制，因为当服务文件系统的节点故障时，没有新的请求被服务直到节点恢复并且开始再次服务文件系统。在用于提供高可用的网络文件系统的一个可能的方法中，两个节点每个服务不同的文件系统。如果一个节点故障，则另一个节点承担失败的节点的文件系统的导出。但是，NFS客户端必须被配置为通过多个节点挂接相同的文件系统。这被称为“多个挂接点”。以这种方式，NFS客户端必须被配置为知道节点什么时候故障以便试图通过另一个挂接点(即，另一个节点)访问相同的数据。
[0005]此外，节点可以从客户端容易地获得超负荷的处理I/O。由于I/O可以利用所有可用的网络和存储器带宽接管系统，因此其它客户端可以发觉自己急需1/0，等待小的时间窗口以获得从网络文件服务器返回的它们需要的信息。不存在已知的提供性能调节和负荷平衡的高可用解决方案。
[0006]本节中描述的方法是可以追随的方法，而不是已被预先构思或者追随的必然方法。因此，除非另有陈述，不假定本节中描述的方法中的任何一个仅仅由于它们包含在本节中而获得现有技术的承认。
【专利附图】

【附图说明】
[0007]在附图中:[0008]图1是描述根据本发明的实施例的示例文件系统架构的方框图；
[0009]图2是描述根据本发明的实施例的用于处理文件系统请求的过程的流程图；
[0010]图3是描述根据本发明的实施例的示例文件系统架构的方框图；
[0011]图4是描述根据本发明的实施例的用于对从群中去除群节点做出响应的过程的流程图；
[0012]图5是描述根据本发明的实施例的用于负荷平衡节点群的过程的流程图；以及
[0013]图6是示出了可以实施本发明的实施例的计算机系统的方框图。
【具体实施方式】
[0014]在下面说明中，为了说明目的，阐述许多的细节以便提供对本发明的更彻底的理解。但是，本领域技术人员将清晰，在没有这些细节的情况下也可以实践本发明。在其它实例中，公知的结构和设备以方框图形式示出以便避免不必要地模糊本发明。
[0015]概述
[0016]为节点群提供用于处理以由群导出的一个或多个文件系统为目标的文件系统请求的技术。群中的每个节点被分配零个或多个束，每个束表示工作量。束是群节点与文件系统之间的关联。在一个实施方式中，群的单个节点接收以由群导出的任一文件系统为目标的所有文件系统请求。单个节点基于一个或多个因素，诸如当前负荷，将文件系统请求路由到群节点中的一个，所述因素可以被反映在分配给群中的每个节点的束的数目中。在另一个实施方式中，文件系统请求在没有通过负责路由请求的群中的中间节点的情况下被发给群节点。在每个群节点上的负荷可以通过使得(例如DNS)映射被更新来管理，以使得将已经被发给特定群节点的未来文件系统请求代之以被发送给群中的另一个节点。同样，在故障转移情况中，以失败节点为目标的未来请求被发给依然健在的节点。
[0017]本发明的实施例不局限于任一特定网络文件系统协议。网络文件系统协议的非限制示例包括NFS (网络文件系统)、GFS (Google文件系统)、和CIFS (公共互联网文件系统)，也称为服务器消息块(SMB)。
[0018]单一命名空间
[0019]根据本发明的实施例，节点群与单一命名空间相关联。换句话说，客户端设备访问由节点群导出的一个或多个文件系统，就像客户端设备与单一节点交互一样。存在管理文件系统请求的节点群的事实对客户端设备是透明的。因此，由节点群导出的每个文件系统(可能有仅仅一个文件系统)经由单一逻辑(例如，IP)地址被访问。客户端设备可以经由DNS查找确定逻辑地址，其将群的主机名解析为逻辑地址。来自于客户端设备的每个文件系统请求利用逻辑地址作为目的地被发送，不管多少节点目前在群中、多少节点已经从群中移除、以及多少节点已被增加到群。
[0020]图1是描述根据本发明的实施例的文件系统架构100的方框图。文件系统架构100包括客户端设备110A-C、网络120、群130、以及文件系统140A-C。尽管仅仅描述三个客户端设备110A-C，但是本发明的其它实施例可以包括比三个多或少。类似地，尽管仅仅描述三个文件系统140A-C，但是本发明的其它实施例可以包括比三个多或少。
[0021]客户端设备110A-C被配置为生成并发送通过网络120发送并且送往群130并针对一个或多个文件系统140A-C处理的文件系统请求。常见的文件系统请求是读和写请求。一个或多个客户应用可以运行在客户端设备IlOA-C的每一个上。此类客户应用发起文件系统请求，其由运行在客户端设备上的文件系统客户端(例如NFS客户端)生成并且发送给群130。
[0022]网络120可以由提供图1的客户端设备110A-C与群130之间的数据交换的任何介质或机制执行。网络的示例包括但不限于诸如局域网(LAN)、广域网(WAN)、以太网或互联网、或一个或多个地面、卫星或无线链路之类的网络。
[0023]群130包括路由节点132和群节点134A-B。尽管仅仅描述两个群节点134A-B，但是本发明的其它实施例可以包括多于两个。群节点134A-B的每一个包括一个或多个处理器和存储器。同样，群节点134A-B的每一个运行被配置为导出一个或多个文件系统140A-C、从路由节点132接收文件系统请求、并访问存储在文件系统中它导出的数据的至少一个文件系统服务器。便于说明，假定每个群节点134A-B运行单一文件系统服务器并且由文件系统服务器执行的动作归于运行对应的文件系统服务器的群节点。
[0024]如果群130支持多个文件系统协议，则每个群节点将需要运行多个过程(例如，每个协议一个过程)以便服务符合那些协议的请求。例如，如果群130支持CIFS和NFS，则每个群节点134A-B将运行SMB过程和NFSD过程。但是，路由节点132不需要运行多个过程。这是因为路由通常出现在比文件系统协议的服务更低的层。路由节点132仅需要检查到来的分组以便将分组引导到适当的群节点。分组指示文件系统和导出类型。
[0025]文件系统140A-C的至少一个经由群节点134A-B中的多个节点导出。换句话说，多个群节点134A-B被配置为访问一个或多个文件系统140A-C。
[0026]在实施例中，每个文件系统140A-C包括一个或多个存储器盘。在有关实施例中，单个存储器盘被分区以使得文件系统的至少两个分配给存储器盘的不同部分。
[0027]以文件系统140A_C(由群130导出)中的一个为目标的每个文件系统请求被发给路由节点132(与群节点134A-B中的任何一个相反，每个可以与不同的逻辑地址相关联)。尽管被描写成与群节点134A-B分开的节点或计算设备，但是路由节点132可以包括与群节点134A-B的一个相同的功能。路由节点132也不同于每个群节点134A-B，因为路由节点132基于一个或多个标准或因素(例如，群节点134A-B中的每个节点的当前负荷)将客户端请求路由到群中多个节点中的一个。
[0028]在实施例中，如果路由节点132被从群130中“移除”(例如，路由节点132损坏、断电、或关机)，则群130中的另一个节点接管路由节点的角色。群130中的其它节点可以是群节点134A-B中的一个或是承担路由节点132的角色的单独“待机”节点。
[0029]路由节点132与主机名相关联，这里称为“群主机名”。群主机名表示群130的主机名，即使群130包括多个节点。客户端设备110A-C可以经由DNS查找请求发现路由节点132的逻辑地址(以下称为“群地址”)。客户端设备110A-C将群地址看作是导出每个文件系统140A-C的节点的逻辑地址。在发现群地址之后，客户端设备110A-C发送包括作为目的地址的群地址的文件系统请求。网络120将文件系统请求路由到路由节点132，其与群地址关联(例如，在ARP表中)。
[0030]为了客户端设备发现在其中要挂接的文件系统，管理员可以定义服务器上的一连串挂接点并且预先配置每个客户端以经由节点名(例如，群主机名)和导出的位置(协议相关的，但是对于NFS将是目录)访问文件系统。不需要配置的“发现”可以以多个方式执行。本发明的实施例不局限于由客户端设备使用以发现文件系统的任一特定技术。
[0031]束
[0032]被分配给群中的每个节点(例如，群130中的群节点134A-B)的“工作”量在这里被称为“束”。在单一命名空间上下文中，“束”由群节点134A-B中的一个与文件系统之间的映射或关联表示。束可以被认为二元组:〈CNID，FSID〉，其中“CNID”是指“群节点标识符”，其识别群节点134A-B中的一个，并且“FSID”是指“文件系统标识符”，其识别由群130导出的文件系统140A-C中的一个。
[0033]在相关的实施例中，束也包括文件系统协议(被称为“导出”)。两个文件系统请求可以以相同的文件系统为目标但是使用不同的导出或文件系统协议。因此，束可以被认为是多元组:〈CNID，export，FSID〉。束可以是二元组，如果群节点134A-B仅仅支持单个文件系统协议。
[0034]因此，束表示到群节点的工作分配。例如，两个束可以被分配给群节点134A而五个束可以分配给群节点134B。
[0035]在实施例中，每个群节点134A-B与虚拟地址(这里称为“VIP”)相关联。地址是“虚拟的”，因为到一个群节点的VIP分配可以变化。例如，群节点134A可以在时间10处与特定VIP相关联。稍后，在时间20处，特定VIP被分配给群节点134B。因此，在时间20后发送到特定VIP的每个文件系统请求将被路由到群节点134B，而不是群节点134A。在此实施例中，束可以是VIP与文件系统之间的关联。因此，代替或除了 CNID之外，束可以包括VIP。
[0036]束的分配由运行在路由节点132或至少群节点134A-B的子集上的束管理软件执行。束管理软件被配置为做出关于负荷平衡、性能调节、以及对节点从/到群130的移除与增加做出响应的智能判定。
[0037]如果束由二元组表示，则若对应的文件系统是一个或多个最近文件系统请求的目标，则束可以被认为“活动的”。例如，如果群130在特定时间段(例如，30秒)之内接收对文件系统140A的文件系统请求，则与文件系统140A相关联的束被认为活动的。作为另一个示例，群130在特定时间段(例如，90秒)之内必须接收对文件系统140A的至少两个文件系统请求，以便使文件系统140A被认为活动的。因为许多文件系统协议无状态，所以陈旧的方案可以用来确定“活动性”。例如，最近的请求可以增加活动计数并且慢慢地“老化”，直到那些请求不再对束的活动负荷计数。此类情况处理其中文件系统具有不正在访问、但可能将来访问文件系统的客户端的情况。
[0038]类似地，如果束由多元组表示，则若结合对应的导出对应的文件系统在最近的文件系统请求中被频繁地使用，则束可以被认为是“活动的”。
[0039]路由文件系统请求
[0040]图2是描述根据本发明的实施例的用于处理文件系统请求的过程200的流程图。在步骤210处，路由节点132从客户端设备(例如，客户端设备110A)接收文件系统请求。
[0041]在步骤220处，响应于接收文件系统请求，路由节点132确定群节点134A-B中的一个以路由文件系统请求。在束由二元组表示的情况下，此确定可以包括确定哪一个文件系统在文件系统请求中被识别。如果束由多元组表示，则此确定另外可以包括确定文件系统协议的导出，其由文件系统请求指示。[0042]路由节点132选择群节点134A-B中的一个以基于一个或多个标准或因素路由文件系统请求。此类标准的非限制示例包括高速缓存考虑(例如，在群节点134A-B中的特定节点是否已经处理来自于相同客户端设备并且以相同文件系统为目标的文件系统请求)、每个群节点134A-B的当前负荷、每个群节点134A-B正在处理和/或排对的文件系统请求的类型、发起文件系统请求的客户端应用的类型、群节点是否正在经受或经受了危急的存储故障、和/或附接于群节点的存储器的类型(例如，直接、网络、SSD，等等)。一个群节点134A-B的当前负荷可以包括下列的一个或多个:分配给群节点的束(或“活动”束)的数目、群节点的CPU使用、群节点的存储器使用、群节点的I/O使用、由群节点导出的文件系统的数目、或由群节点排队的文件系统请求的数目。
[0043]关于当前负荷的统计量可以由路由节点132以多种方式接收。例如，每个群节点134A-B可以被配置为自动地并且定期(例如，每5秒)将此类统计量发送到路由节点132。如另一个示例，路由节点132只是在向每个群节点134A-B发出对此类统计量的请求以后接收统计量。此类请求可以响应于路由节点132接收新文件系统请求而被发送。另外，此类请求可以只响应于路由节点132接收不是任一束的一部分的文件系统请求而被发送。
[0044]如果高速缓存被考虑，则来自于特定客户端设备中的每个后续的文件系统请求(在初始文件系统请求之后)很可能被路由到处理初始文件系统请求的群节点，即使群节点可以具有相对于群130中的其它群节点较高的当前负荷。一个原因是当路由文件系统请求到另一个群节点时存在效率成本。“初始”群节点可以使响应于文件系统请求所需的信息存储在它的高速缓存中。如果另一个群节点接收文件系统请求，则该另一个群节点可以不得不(a)请求来自于初始群节点的信息或(b) (I)等待初始群节点将它的高速缓存刷入到盘(即，一个或多个文件系统)并且然后(2)请求来自于盘中的数据。这两个可替换方案在时间和资源方面是高成本的。这些替换方案被称为“无效”节点的高速缓存。“高速缓存”成本(在时间和资源使用方面)可以被估计并且用在220的群节点选择步骤中。
[0045]在步骤230处，在将文件系统请求路由到在步骤220中选择的群节点134A-B中的一个之前，路由节点132可以变更文件系统请求以使得文件系统请求对选择的群节点看来似乎来源于路由节点132。例如，路由节点132(1)用路由节点132的地址(例如，IP或MAC地址)替换在文件系统请求中指示的源地址以及(2)用与选择的群节点相关联的地址替换在文件系统请求中指示的目的地址。执行这样的变更以使得群节点假定路由节点132是“客户端”并且用于响应文件系统请求的代码不需要改变。这样的变更利用路由表和标准协议。客户端看请求如同来自于路由节点并且群节点看请求如同来自于路由节点。这允许使得分组被从公共网络改变到私有网络(其可以快几个数量级)，以及提供“欺骗”客户端所必需的伪装。这样的布置也提供如果所有请求是公共的则不在那里的安全性级别。
[0046]在步骤240处，路由节点132将(修改的)文件系统请求发送到选择的群节点。在这一点上，文件系统请求被认为处于“私有网络”。
[0047]在步骤250处，选择的群节点接收并且处理文件系统请求(例如，通过请求来自于文件系统140A-C中的一个的数据)并且生成文件系统响应。
[0048]在步骤260处，路由节点132从选择的群节点接收文件系统响应。
[0049]在步骤270处，路由节点132修改文件系统响应以使得文件系统响应对发送文件系统请求的客户端设备看来似乎来自于路由节点132而不是来自于选择的群节点。例如，路由节点132(1)用与路由节点132相关联的地址(例如，IP地址)替换文件系统响应中的源地址以及(2)用与发送在步骤210中接收的文件系统请求的客户端设备相关联的地址替换在文件系统响应中指示的目的地址。
[0050]在步骤280处，路由节点132将(修改的)文件系统响应发送到发送文件系统请求的客户端设备。
[0051]改变群中节点的数目
[0052]因为路由节点132是群的“门面”，由于来自于客户端设备的所有文件系统请求被引导到路由节点132，并且路由节点132 “后面”的群对那些客户端设备是透明的(或不可见的)，所以群130中的节点的数目在对客户端设备或对路由节点132的路由逻辑没有任何修改的情况下可以改变。此外，群130不必须是脱机的以便将群节点增加到群130或从群130中移除群节点。反而，在路由节点132接收文件系统请求的同时，群节点可以被增加并且群节点可以被移除。
[0053]例如，如果群节点134A从群130移除，则路由节点132不将群节点134A认为是在从客户端设备110A-C中的一个路由文件系统请求时选择的潜在节点。作为另一个示例，如果新的群节点被增加到群130，则路由节点132在选择文件系统请求将被路由到的群节点时考虑新的群节点。
[0054]负荷平衡
[0055]在先前方法中，因为文件系统被经由单个节点导出，所以挂接文件系统的每个客户端设备将文件系统请求引导到那个节点。因此，在节点群中，群中的一个节点可以处理许多文件系统请求同时群中的其它节点仍然是空闲的。没有办法在群中所有节点之间平衡群中的负荷。
[0056]在实施例中，对群节点134A-B执行一个或多个负荷平衡技术。再次，因为来自于客户端设备的所有文件系统请求被引导到路由节点132所以路由节点132方面是群的“门面”并且路由节点132 “后面”的群对那些客户端设备是透明的(或不可见的)，所以在群130上的负荷在没有对客户端设备任何修改的情况下可以改变。
[0057]群130的负荷平衡包括将束分配到每个群节点134A-B以使得每个群节点134A-B被分配相等数目的束(例如，每个2个束)或以使得没有群节点被分配的束比分配给任一其它群节点的束多于两个或更多个束(例如，2个束到群节点134A以及3个束到群节点134B)。
[0058]群130的负荷平衡可以响应于一个或多个事件出现。此类事件的非限制示例包括从群130中移除节点、将新的节点增加到群130、将文件系统增加到文件系统140A-C、以及从文件系统140A-C移除文件系统。
[0059]负荷平衡标准的非限制示例包括分配给每个群节点134A-B的束的数目、每个群节点134A-B当前正在处理和/或排队的文件系统请求的数目、以及将高速缓存的数据从一个群节点转移到另一个群节点的估计(或实际)成本。
[0060]例如，如果群节点134A被分配五个束而群节点134B不被分配任何束(或被分配一定时间量内没有对其接收到文件系统请求的一个或多个束)，则分配给群节点134A的五个束的一个或多个被分配给群节点134B。如果五个束中的一个在以对应文件系统为目标的文件系统请求的频率显著地大于与其它束相关联的频率方面是非常“活动的”，则仅仅那个“活动的”束可以被再分配到群节点134B。
[0061]性能调节
[0062]在实施例中，路由节点132在确定如何路由文件系统请求时应用一个或多个性能调节技术。涉及负荷平衡和性能调节。虽然负荷平衡包括均匀地在群中的节点当中分布负荷(由分配给每个群节点的束的数目反映)，但是性能调节一般涉及即时性能并且可以包括考虑附加因素，诸如发起文件系统请求的客户应用类型。因此，性能调节倾向于比负荷平衡更复杂。
[0063]性能调节可以利用监控某些因素的软件来实现。在路由节点132(和/或一个或多个群节点134A-B)上运行的性能调节软件确定如何基于某些启发法重新分配束。启发法的示例是如果在特定群节点上的CPU( S卩，中央处理单元)使用达到90%，则分配给特定群节点的至少一个束被重新分配给另一个群节点。可替换地，性能调节软件执行更复杂的逻辑，诸如概率模型，其示例包括马尔可夫网络和贝叶斯定理网络。此类概率模型接受多个输入，诸如I/O吞吐量、存储器(例如，RAM)使用、CPU使用、存储器类型和访问、访问特征(例如，随机的、连续的、读与写)、以及网络使用。基于概率模型，性能调节软件可以确定群节点134A-B中的一个是否可能有提供附加束的问题并且可以展开其余的束以及重新分配当前运行的束以较好地在整个群130当中分布负荷。
[0064]参考以上涉及的“存储器类型和访问”，不同类型的存储器具有不同的访问特征。例如，SSD尽管相对昂贵，但是对于读和写很快速并且具有非常低的访问时间。SSD对频繁地改变或需要被很快访问(诸如数据库索引)的数据适用或对库存项目计数适用。硬盘驱动器相对于平均访问时间是慢的，但是具有许多存储空间。硬盘对诸如数据库(巨大的)或记录文件(非随即访问、低的写和读速度)之类的项目适用。可移除的介质对备份适用，因为它们一般在大小上很大，但是也倾向于具有慢的访问时间。相对于访问类型，“直接附接”(即，机器中的驱动，或附有短线缆)一般是最快速的。另一个访问类型是存储阵列网络，其通常是光纤信道，将大的盘阵列附接到多个机器。另一个访问类型是网络存储器，诸如ISCSI。类似于介质的每个访问类型对改变存储器类型是有用的。
[0065]例如，群节点134A被分配两个束:束I和束2。束I被导出到十个客户端。与束I相关联的导出的文件系统大量使用随机1/0，这耗尽存储系统。群130中的一个或多个节点(例如，路由节点132)可能检测这一点并且将束2移动到群节点134B (即使群节点134B可能已经被分配两个束)以使得利用由束2指示的导出的文件系统的客户端不会继续看见性能下降。
[0066]性能调节可以提供若干益处，包括附加负荷平衡特征。因为底层的文件系统是群文件系统，所以文件系统可以被从多个群节点(包括整个群、单个机器、或任何一个子集的组合)中同时导出。这允许性能调节系统自动地设置从其它节点中的附加导出以保证系统保持负荷平衡。
[0067]备份路由节点
[0068]在实施例中，如果路由节点132失败、损坏、或被卸下,贝U另一个节点承担相同的角色。该另一个节点这里被称为“备份路由节点”。备份路由节点可以是群节点134A-B中的一个或可以是“待机”节点，其目的是如果路由节点132被移除则执行路由节点132的功能。在备份路由节点承担路由节点132的角色之后，则以路由节点132为目标的后续的文件系统请求被发给备份路由节点。
[0069]备份路由节点可以通过使得路由节点132的逻辑地址(与路由节点132相关联)与物理地址之间的映射被更新来实现此任务。此映射可以被存储在交换机中的ARP ( S卩，地址解析协议)表或群130外的路由器中。通过使得路由节点132的物理地址被替换为备份路由节点的物理地址来更新映射。以这种方式，包括作为目的地的逻辑地址的任何未来的文件系统请求将被路由到备份路由节点。
[0070]多个命名空间
[0071]根据本发明的实施例，节点群与多个命名空间相关联。换句话说，客户端设备发现群的各个节点并且与那些节点交互(“直接”)，与将所有文件系统请求引导到单个节点(诸如先前描述的单一命名空间实施方式中的路由节点132)相反。因此，客户端设备可以知道群中的每个节点。客户端设备可以经由DNS查找确定每个群节点的逻辑地址，DNS查找将群节点的主机名解析为逻辑地址。
[0072]图3是描述根据本发明的实施例的示例文件系统架构300的方框图。文件系统架构300包括客户端设备310A-C、网络320、群130、以及文件系统340A-C。尽管仅仅描述三个客户端设备310A-C，但是本发明的其它实施例可以包括比三个多或少。类似地，尽管仅仅描述三个文件系统340A-C，但是本发明的其它实施例可以包括比三个多或少。
[0073]客户端设备310A-C被配置为生成并发送通过网络320发送的并且被引导到群330并针对一个或多个文件系统140A-C处理的文件系统请求。
[0074]网络320可以由图3的提供客户端设备310A-C与群330之间的数据交换的任何介质或机制执行。网络的示例包括但不限于诸如局域网(LAN)、广域网(WAN)、以太网或互联网、或一个或多个地面、卫星或无线链路之类的网络。
[0075]群330包括群节点332A-C。尽管仅仅描述了三个群节点332A-C，但是本发明的其它实施例可以包括比三个多或少。群节点332A-C中的每个节点被配置为处理针对一个或多个文件系统340A-C的文件系统请求。文件系统340A-C的至少一个可以经由群节点332A-C中的多个节点导出(例如，在不同的时间点)。
[0076]群330中的每个群节点与虚拟地址(这里称为“VIP”)相关联。地址是“虚拟的”，因为到一个群节点的VIP分配可以变化。例如，群节点332A可以在时间10处与特定VIP相关联。稍后，在时间20处，特定VIP被分配给群节点332B。因此，发送到特定VIP的每个文件系统请求将被路由到群节点332B，而不是群节点332A。
[0077]此外，群330中的一个或多个节点可以与多个虚拟地址相关联。这个情况可能由于下面更详细描述的多个命名空间束的分配。
[0078]多个命名空间束
[0079]在多个命名空间上下文中，“束”是虚拟地址(或VIP)与文件系统之间的映射或关联。在此上下文中，束可以被认为是二元组:〈VIP，文件系统〉。在相关的实施例中，束也包括文件系统协议(被称为“导出”)。两个文件系统请求可以利用相同的VIP但是利用不同的导出或文件系统协议以相同的文件系统为目标。因此，多个命名空间束可以被认为是多元组:〈VIP，导出，文件系统〉。多个命名空间束可以是二元组，如果群节点332A-C仅仅支持单个文件系统协议。
[0080]在实施例中，多个命名空间多元组(或二元组)包括多个VIP。换句话说，单个文件系统可以经由多个VIP可访问。
[0081]束的分配是由运行在群节点332A-C的至少一个子集上的束管理软件执行的。束管理软件可以做出关于负荷平衡、性能调节、以及对节点从群330的移除做出响应的智能判定。
[0082]故障转移
[0083]如果群节点332A-C中的一个被从群330中“移除”(例如，路由节点332A损坏、断电、或关闭)，则群330中的另一个节点(例如，群节点332B)接管移除的群节点的处理。
[0084]图4是描述根据本发明的实施例的用于响应于从群330中移除群节点的处理400的流程图。在此示例中，群节点332A“失败”。群节点332A被分配一个或多个束。处理400中的步骤可以由运行在群节点332b和332C的每一个上的束管理软件执行。同样，在此示例中，分配给群330中的每个群节点的束是多元组。
[0085]在步骤410处，群节点332B和/或群节点332C检测群节点332A已经失败。此检测可以基于群节点332A在预期计划的关闭时发送给群节点332B和332C的每一个的“关闭”消息。可替换地，此检测可以基于群节点332B和/或群节点332C没有从群节点332A接收到调度的消息或信号一段时间或没有从群节点332A接收到对由群节点332B或群节点332C发送的消息的响应。
[0086]在步骤420处，分配给群节点332A的束被识别。例如，确定束1、2、和3被分配给群节点332A。
[0087]在步骤430处，在步骤420中识别的每个束被重新分配给群330中的另一个节点。在上述示例中，束I和2可以被重新分配给群节点332B并且束3可以被重新分配给群节点332C。重新分配基于一个或多个因素。在实施例中，做出束重新分配以使得分配给群330中的所有节点的所有束被相等地或尽可能相等地分配。
[0088]例如，群节点332B和332C的当前负荷被确定并且用于重新分配束1_3。在群节点332A故障或移除时，束4和5被分配给群节点332B并且束6、7、和8被分配给群节点332C。束1-3可以被重新分配以保证群节点332B和332C的每一个被分配相等(或接近相等)数目的束。因此，束I和2可以被重新分配给群节点332B和并且束3可以被重新分配给群节点332C以使得每个群节点被分配四个束。
[0089]在有关的实施例中，步骤430包括识别与群节点332B和332C相关联的一个或多个特征、发起文件系统请求的客户端应用类型、和/或文件系统请求的类型和频率。特征(例如，CPU使用、存储器使用、网络使用)和/或上面相对于性能调节讨论到的一个或多个其它因素可以用以重新分配在步骤420中识别的束。
[0090]在步骤440处，对于每个重新分配的束，由束指示的每个VIP与群节点332A的物理(例如，MAC)地址之间的映射被更新以反映不同的物理地址。不同的物理地址是在步骤430中束被重新分配到的群节点的物理地址。映射可以被反映在将逻辑(例如，IP)地址映射到物理(例如，MAC)地址的(例如，网络320中的交换机或路由器的)ARP表中。以这种方式，其目的地地址是重新分配的束的VIP的任何进一步文件系统请求将被发送给束被重新分配到的群节点。例如，如果束3被重新分配给群节点332C，则被发送的具有束3的VIP作为目的地址的任何文件系统请求将被发送给群节点332C。
[0091]以这种方式，客户端设备310A-C中没有一个需要知道群330的多个节点。从客户端设备310A-C的视角中，客户端设备310A-C在试图访问特定文件系统时仅仅与单个节点交互。换句话说，客户端不需要具有用于相同文件系统的多个挂接点。
[0092]负荷平衡
[0093]负荷平衡也可能在多个命名空间情况中。如果客户端设备(或，更具体地，运行在客户端设备上的文件系统客户端过程)挂接主机名，则群330中的节点的负荷平衡是可能的。但是，如果客户端设备挂接IP地址，则群330中的节点的负荷平衡不是可能的。
[0094]图5是描述根据本发明的实施例的用于负荷平衡群330的处理500的流程图。处理500的步骤可以由运行在一个或多个群节点332A-C上的负荷平衡软件执行。
[0095]在步骤510处，确定群330中的每个节点的当前负荷。当前负荷可以被反映在分配给每个群节点的束的数目中。另外或可替换，当前负荷可以被反映在每个群节点的CPU使用、每个群节点的存储器使用、每个群节点的I/O使用、和/或当前由每个群节点服务或处理的文件系统请求的类型中。
[0096]群330中的每个节点的当前负荷可以被连续地或以一定间隔(例如，每分钟)确定。另外或可替换，可以响应于特定事件的发生确定当前负荷，诸如在每个新文件系统请求之后。
[0097]在步骤520处，来自于群节点332A-C的一个中的一个或多个束确定被重新分配给群330的一个或多个其它群节点。例如，在重新分配之前，束1-5被分配给群节点332A，束6-8被分配给群节点332B，以及束9-10被分配给群节点332C。确定束4要被重新分配给群节点332B并且束5要被重新分配给群节点332C。
[0098]在步骤530处，做出束重新分配。在实施例中，对于每个束重新分配，更新主机名-地址映射。主机名-地址映射可以被反映在由网络320中的名称服务器维护的DNS表中。此类映射更新是动态DNS的示例。主机名-地址映射的逻辑地址被替换为束被重新分配到的群节点的逻辑地址。可替换地，DNS管理员可能已经配置DNS别名以使得名称服务器使用循环解析或故障转移解析以映射到活动的主机。
[0099]在有关的实施例中，使得此类主机名-地址映射被更新不是可能的。反而，运行在客户端设备上的文件系统客户端被配置为使用不同的VIP。文件系统客户端可以确定，接收对它的文件系统请求之一的响应所花费的时间是长的。另外或可替换，群节点332A-C中的一个在访问相同的文件系统时通知文件系统客户端使用不同的VIP(例如，其可以在通知中被识别)。
[0100]给出以上所述示例，对于束4，主机名-地址映射(其指示群节点332A的逻辑地址)被更新以指示群节点332B的逻辑地址。已经具有被解析到群节点332A的逻辑地址的更新的主机名-地址映射的主机名的客户端设备将继续向群节点332A的逻辑地址发送文件系统请求。但是，随着时间，那些客户端设备可以“忘记”逻辑地址；在这种情况下，那些客户端设备将使得主机名被“重新解析”，在这种情况下“新的”逻辑地址(即，群节点332B的)将被发现。此外，紧接在映射更新之后，识别主机名的任何未来的名称解析请求将解析到群节点332B的逻辑地址。
[0101]硬件总览
[0102]根据一个实施例，由一个或多个专用的计算设备执行这里描述的技术。专用的计算设备可以是执行技术的硬线，或可以包括被永久编程以执行技术的诸如一个或多个专用集成电路(ASIC)或现场可编程门阵列(FPGA)之类的数字电子设备，或可以包括被编程以按照固件、存储器、其它存储器、或组合中的程序指令执行技术的一个或多个通用的硬件处理器。此类专用的计算设备也可以组合自定义硬线逻辑、ASIC、或具有自定义程序以实现技术的FPGA。专用的计算设备可以是桌上型计算机系统、便携式计算机系统、手持设备、网络设备或合并硬线和/或程序逻辑以执行技术的任何其它设备。
[0103]例如，图6是示出了可以实施本发明的实施例的计算机系统600的方框图。计算机系统600包括总线602或用于通信信息的其它通信机制，和用于处理信息的被耦接到总线602的硬件处理器604。硬件处理器604可以是例如，通用的微处理器。
[0104]计算机系统600也包括诸如随机存取存储器(RAM)或其它动态存储器之类的耦接到总线602的以用于存储要由处理器604运行的信息和指令的主存储器606。主存储器606也可以用于在执行由处理器604运行的指令期间存储临时变量或其它中间信息。此类指令当存储在处理器604可访问的非瞬时存储介质时，将计算机系统600渲染成被定制以执行指令中指定的操作的专用机器。
[0105]计算机系统600还包括只读存储器(ROM)608或耦接到总线602的用于存储用于处理器604的静态信息和指令的其它静态存储器设备。诸如磁盘、光盘、或固态驱动器之类的存储设备610被提供并且耦接到总线602以用于存储信息和指令。
[0106]计算机系统600可以经由总线602被连接到诸如阴极射线管(CRT)之类的用于向计算机用户显示信息的显示器612。包括字母数字和其它键的输入设备614被耦接到总线602以向处理器604通信信息和命令选择。用户输入设备的另一个类型是用于向处理器604通信方向信息和命令选择并用于控制光标在显器上移动的光标控制616,诸如鼠标、跟踪球、或光标方向键。此输入设备通常具有两轴的两个自由度，第一轴(例如，X)和第二轴(例如，y)，其允许设备指定平面中的位置。
[0107]计算机系统600可以利用与计算机系统结合使得或编程计算机系统600成为专用机器的定制的硬线逻辑、一个或多个ASIC或FPGA、固件和/或程序逻辑执行这里描述的技术。根据一个实施例，由计算机系统600响应于运行包含在主存储器606中的一个或多个指令的一个或多个序列的处理器604执行这里的技术。此类指令可以从诸如存储设备610之类的另一个存储介质被读入到主存储器606。包含在主存储器606中的指令序列的运行使得处理器604执行这里描述的处理步骤。在可替换实施例中，硬线电路可以被软件指令代替或与软件指令结合使用。
[0108]这里使用的术语“存储介质”是指存储使得机器以特定方式操作的数据和/或指令的任何非瞬时介质。此类存储介质可以包括非易失性介质和/或易失性介质。非易失性介质包括例如诸如存储设备610之类的光盘或磁盘。易失性介质包括动态存储器，诸如主存储器606。存储介质的常见形式包括例如，软盘、软磁盘、硬盘、固态驱动器、磁带、或任何其它磁数据存储介质、CD-ROM、任何其它光数据存储器介质、具有孔穴类型的任何物理介质、RAM、PROM和EPROM、FLASH-EPROM、NVRAM、任何其它存储器芯片或盒。
[0109]存储介质与传输介质不同但是可以被结合传输介质使用。传输介质参与在存储介质之间转移信息。例如，传输介质包括同轴电缆、铜线和光纤，包括总线602的线路。传输介质也可以采取声波或光波的形式，诸如那些在放射波和红外线数据通信期间生成的。
[0110]各种形式的介质可以被包含在向用于运行的处理器604传送一个或多个指令的一个或多个序列中。例如，指令可以最初被携带在远程计算机的磁盘或固态驱动器上。远程计算机可以将指令加载到它的动态存储器中并将指令通过电话线利用调制解调器发送。计算机系统600本地的调制解调器可以在电话线上接收数据并且使用红外线发送器将数据转换到红外线信号。红外检测器可以接收在红外线信号中携带的数据并且适当的电路可以在总线602上放置数据。总线602将数据携带到主存储器606，处理器604从主存储器606检索并运行指令。由主存储器606接收到的指令可以可选地在由处理器604运行之前和之后被存储在存储设备610中。
[0111]计算机系统600也包括耦接到总线602的通信接口 618。通信接口 618提供耦接到被连接到本地网络622的网络链路620的双向数据通信。例如，通信接口 618可以是综合服务数字网(ISDN)卡、电缆调制解调器、卫星调制解调器、或提供到对应类型的电话线的数据通信连接的调制解调器。如另一个示例，通信接口 618可以是提供到兼容的局域网(LAN)的数据通信连接的LAN卡。也可以执行无线链路。在任何此类实施方式中，通信接口618发送并接收传送表示各种类型信息的数字数据流的电的、电磁的或光信号。
[0112]网络链路620通常经由一个或多个网络向其它数据设备提供数据通信。例如，网络链路620可以经由本地网络622向主机624或由互联网服务供应商(ISP)626操作的数据装置提供连接。ISP626随后经由现在普通被称为“互联网”628的全球分组数据通信网络提供数据通信业务。本地网络622和互联网628两者都使用传送数字数据流的电的、电磁的或光信号。往返于计算机系统600传送数字数据、经由各网络的信号和网络链路620上并经由通信接口 618的信号是传输介质的示例形式。
[0113]计算机系统600可以经由网络、网络链路620和通信接口 618发送消息并接收包括程序代码的数据。在互联网示例中，服务器630可以经由互联网628、ISP626、本地网络622和通信接口 618发送用于应用程序的请求码。
[0114]接收到的代码可以被处理器604按照接收的运行，和/或存储在存储设备610或其它非易失性存储器中用于稍后运行。
[0115]在上述说明书中，已经参考可以在实施方式之间不同的许多细节描述了本发明的实施例。因此，说明书和附图应当被认为是说明性的，而不是限制的意义上的。本发明范围的唯一并专用的指示、和由 申请人:指定的本发明范围的内容是由此本申请发出的权利要求书集合的文字和等效范围，以此类权利要求发出的特定形式，包括任何后续校正。
【权利要求】
1.一种方法，包括: 确定多个群节点中的第一群节点不能对文件系统请求做出响应； 响应于确定所述多个群节点中的第一群节点不能对文件系统请求做出响应，使得特定的地址到地址映射被更新； 其中所述特定的地址到地址映射将第一节点的逻辑地址映射到物理地址； 其中所述特定的地址到地址映射被更新以将物理地址替换为所述多个群节点中的不同于第一群节点的第二群节点的物理地址； 其中所述方法由一个或多个计算设备执行。
2.如权利要求1所述的方法，其中所述特定的地址到地址映射被存储在地址解析协议(ARP)表中。
3.如权利要求1所述的方法，其中所述多个群节点中的多个群节点导出一个或多个文件系统的特定文件系统。
4.如权利要求1所述的方法，还包括:响应于确定所述多个群节点中的第一群节点不能对文件系统请求做出响应: 识别与第一群节点相关联的多个逻辑地址； 其中使得所述特定的地址到地址映射被更新包括使得第二地址到地址映射被更新；其中所述第二地址到地址映射将所述多个逻辑地址中的第二逻辑地址映射到第一节点的物理地址； 其中所述第二地址到地址映射被更新以将所述物理地址替换为与所述多个群节点中的不同于第一群节点的第三群节点的物理地址。
5.如权利要求1所述的方法，其中第三群节点不同于第二群节点。
6.如权利要求1所述的方法，其中: 节点群的每个节点与映射到逻辑地址的主机名相关联； 所述方法还包括使得识别(I)第一主机名和(2)与所述多个群节点中的第三群节点相关联的第三逻辑地址的映射被更新以将第三逻辑地址替换为与所述多个群节点中的第四群节点相关联的第二逻辑地址； 所述第三节点不同于第四节点。
7.如权利要求6所述的方法，其中所述映射由将主机名映射到逻辑地址的名称服务器维护。
8.如权利要求6所述的方法，其中: 使得映射被更新包括确定是否分布所述多个群节点的当前负荷； 确定是否分布当前负荷包括确定分配给所述多个群节点的每个群节点的束的数目。
9.如权利要求1所述的方法，还包括存储识别多个束的数据，其中所述多个束中的每个束被分配给所述多个群节点中的一个群节点，其中所述多个束的每个束与一个或多个逻辑地址和多个文件系统的导出的文件系统相关联。
10.一种方法，包括: 通过网络从客户端设备在路由节点处接收文件系统请求， 由路由节点确定多个群节点中的哪一个群节点将要处理所述文件系统请求； 其中确定哪一个群节点将要处理所述文件系统请求包括基于一个或多个标准，从所述多个群节点中确定特定群节点，以及 响应于确定所述特定群节点，由路由节点将文件系统请求发送到所述特定群节点。
11.如权利要求10所述的方法，其中: 所述文件系统请求包括与发送所述文件系统请求的客户端设备相关联的地址； 所述方法还包括，在将所述文件系统请求发送到所述特定群节点之前，由路由节点将所述地址替换为与所述特定路由节点相关联的地址。
12.如权利要求10所述的方法，还包括: 从所述特定节点接收对文件系统请求的响应； 向发送所述文件系统请求的客户端设备发送基于来自于所述特定群节点的响应的文件系统响应。
13.如权利要求12所述的方法，其中: 所述响应包括与所述特定群节点相关联的地址； 所述方法还包括，在将所述文件系统响应发送到该发送文件系统请求的客户端设备之前，由路由节点将所述地址替换为与所述特定路由节点相关联的地址。
14.如权利要求10所述的方法，还包括: 确定所述路由节点不能处理文件系统请求；以及 响应于确定所述路由节点不能处理文件系统请求，使得后续的文件系统请求被引导到不同于所述路由节点的第二路由节点。
15.如权利要求14所述的方法，其中: 使得后续的文件系统请求被引导到第二路由节点包括使得特定逻辑地址与特定物理地址之间的映射被更新； 所述特定物理地址是所述路由节点的物理地址； 所述映射通过将所述特定物理地址替换为第二路由节点的第二物理地址来被更新。
16.如权利要求10所述的方法，其中与所述多个群节点中的每个群节点相关联的一个或多个标准指示分配给所述每个群节点的束的数目。
17.如权利要求10所述的方法，其中与节点群中的所述每个节点相关联的一个或多个标准指示所述每个节点的当前负荷，其中所述每个节点的当前负荷包括所述每个节点的CPU使用、所述每个节点的存储器使用、在所述每个节点处排队的文件系统请求的数目、或所述每个节点的I/O使用中的一个或多个。
18.如权利要求10所述的方法，其中所述多个群节点中的多个群节点导出一个或多个文件系统的特定文件系统。
19.存储指令的一个或多个存储介质，所述指令在由一个或多个处理器执行时，使得执行在权利要求1-18的任何一个中所述的方法。
【文档编号】H04L29/08GK103975571SQ201280060079
【公开日】2014年8月6日 申请日期:2012年10月19日 优先权日:2011年10月20日
【发明者】F·S·格鲁夫, G·桑德森, D·A·小格雷夫斯 申请人:甲骨文国际公司