CN114328421A - 元数据服务架构管理方法、计算机***、电子设备及介质 - Google Patents
元数据服务架构管理方法、计算机***、电子设备及介质 Download PDFInfo
- Publication number
- CN114328421A CN114328421A CN202210261242.0A CN202210261242A CN114328421A CN 114328421 A CN114328421 A CN 114328421A CN 202210261242 A CN202210261242 A CN 202210261242A CN 114328421 A CN114328421 A CN 114328421A
- Authority
- CN
- China
- Prior art keywords
- metadata
- server
- storage area
- management method
- metadata 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.)
- Granted
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
一种元数据服务架构管理方法、计算机***、电子设备及介质,元数据服务架构包括多个元数据服务器,该管理方法包括:将文件***中的元数据划分为多个元数据片段并分别存储在不同的元数据存储区域中;每个元数据服务器管理至少一个元数据存储区域。该管理方法减少了***异常时数据的流动和交互,简化了元数据的管理,加速了元数据服务器的切换、升级等流程。
Description
技术领域
本公开的实施例涉及一种用于元数据服务架构的管理方法、计算机***、电子设备及计算机可读存储介质。
背景技术
文件***是操作***用于明确存储设备或分区上的文件的方法和数据结构,即在存储设备上组织文件的方法。操作***中负责管理和存储文件信息的软件称为文件管理***,简称文件***。从***角度来看,文件***是对文件存储设备的空间进行组织和分配,负责文件存储并对存入的文件进行保护和检索的***。具体地说,文件***负责为用户建立文件、存入、读出、修改、转储文件,控制文件的存储,当用户不再使用时撤销文件等。元数据是文件***的关键数据,记录了文件的各种属性。文件***的元数据需要持久保存在磁盘上。
发明内容
本公开至少一个实施例提供一种用于元数据服务架构的管理方法,该元数据服务架构包括多个元数据服务器,该管理方法包括:将文件***中的元数据划分为多个元数据片段并分别存储在不同的元数据存储区域中;每个元数据服务器管理至少一个元数据存储区域。
例如,在本公开至少一个实施例提供的管理方法中,不同的元数据片段存储在不同的元数据存储区域中,不同的元数据服务器管理不同的元数据存储区域,不同的元数据存储区域所存储的元数据片段不同。
例如,在本公开至少一个实施例提供的管理方法中,将文件***中的元数据划分为多个元数据片段并分别存储在不同的元数据存储区域中,包括:根据目录特性将元数据划分为多个元数据片段;根据各个元数据服务器的负载确定多个元数据片段各自的存储位置并进行存储。
例如,在本公开至少一个实施例提供的管理方法中,每个元数据服务器管理至少一个元数据存储区域,包括:每个元数据服务器为不同的元数据存储区域中的元数据创建不同的缓存;读取元数据存储区域中的元数据并加载到对应的缓存中。
例如,在本公开至少一个实施例提供的管理方法中,元数据服务器配置为管理缓存的创建、数据加载和淘汰、缓存的释放。
例如,本公开至少一个实施例提供的管理方法,还包括:响应于文件***启动,为每个元数据服务器分配元数据。
例如,在本公开至少一个实施例提供的管理方法中,响应于文件***启动,为每个元数据服务器分配元数据,包括:响应于文件***启动,利用监控模块统计元数据服务器的信息和元数据存储区域的信息;监控模块中的元数据存储区域管理模块将元数据存储区域分配给不同的元数据服务器;元数据存储区域管理模块建立元数据存储区域和元数据服务器之间的映射信息,并将映射信息发送给元数据服务器;元数据服务器响应于接收到映射信息,为每个元数据存储区域分配缓存,并分别加载各个元数据存储区域中的元数据到对应的缓存中。
例如,本公开至少一个实施例提供的管理方法,还包括:将发生故障的元数据服务器管理的元数据存储区域进行重新分配。
例如,在本公开至少一个实施例提供的管理方法中,将发生故障的元数据服务器管理的元数据存储区域进行重新分配,包括:响应于元数据服务器发生故障,元数据存储区域管理模块统计需要重新分配的元数据存储区域;根据元数据服务器的负载情况,元数据存储区域管理模块将发生故障的元数据服务器管理的元数据存储区域分配给其它元数据服务器。
例如,在本公开至少一个实施例提供的管理方法中,元数据存储区域管理模块统计需要重新分配的元数据存储区域,包括:元数据服务器周期性地向监控模块发送心跳信息,心跳信息包括元数据服务器的状态和所管理的各个元数据存储区域的状态;监控模块根据元数据服务器发送的心跳信息更新监控模块中记录的元数据服务器的状态;响应于监控模块未接收到心跳信息的时间超过阈值时间,监控模块认定元数据服务器故障且元数据服务器管理的元数据区域需要被重新分配。
例如,在本公开至少一个实施例提供的管理方法中,元数据存储区域管理模块将发生故障的元数据服务器管理的元数据存储区域分配给其它元数据服务器,包括:监控模块响应于检测到发生故障的元数据服务器,根据负载均衡策略将发生故障的元数据服务器管理的元数据存储区域重新分配给其它元数据服务器;更新监控模块中记录的元数据存储器区域和元数据服务器之间的映射信息,并将更新后的映射信息发送给各个元数据服务器;元数据服务器响应于接收到更新后的映射信息,基于更新后的映射信息确定是否需要接管其它元数据服务器的元数据存储区域,并且,在需要接管其它元数据服务器的元数据存储区域的情形,在该元数据服务器上创建新的缓存并加载所接管的元数据存储区域的元数据。
例如,本公开至少一个实施例提供的管理方法,还包括:在元数据服务架构中增加元数据服务器,并利用增加的元数据服务器接管元数据。
例如,在本公开至少一个实施例提供的管理方法中,利用增加的元数据服务器接管元数据,包括:增加的元数据服务器向监控模块注册,监控模块更新映射信息;监控模块将更新后的映射信息发送给元数据服务架构中的所有元数据服务器;各个元数据服务器将不再管理的元数据对应的缓存释放;增加的元数据服务器创建缓存并加载要接管的元数据。
本公开至少一个实施例还提供一种计算机***,包括多个元数据服务器和多个元数据存储区域,计算机***运行有文件***,文件***中的元数据被划分为多个元数据片段并分别存储在不同的元数据存储区域中,每个元数据服务器被配置为管理多个元数据存储区域中的至少一个元数据存储区域,每个元数据存储区域被配置为存储对应的元数据。
例如,本公开至少一个实施例提供的计算机***,还包括监控模块,监控模块被配置为记录多个元数据服务器的信息和多个元数据存储区域的信息,并管理多个元数据服务器与多个元数据存储区域之间的映射关系。
本公开至少一个实施例还提供一种电子设备,包括:处理器;以及存储器,存储有计算机可执行指令,计算机可执行指令在被处理器执行时实现根据本公开至少一个实施例提供的用于元数据服务架构的管理方法。
本公开至少一个实施例还提供一种计算机可读存储介质,用于非瞬时性地存储计算机可执行指令,计算机可执行指令在被处理器执行时实现根据本公开至少一个实施例提供的用于元数据服务架构的管理方法。
附图说明
为了更清楚地说明本公开实施例的技术方案,下面将对实施例的附图作简单地介绍,显而易见地,下面描述中的附图仅仅涉及本公开的一些实施例,而非对本公开的限制。
图1A示出了一种实现多元数据服务架构的模式示意图;
图1B示出了另一种实现多元数据服务架构的模式示意图;
图2A示出了本公开至少一个实施例提供的一种元数据服务架构的结构示意图;
图2B示出了本公开至少一个实施例提供的一种用于元数据服务架构的管理方法的示意性流程图;
图3A示出了本公开至少一个实施例提供的管理方法的步骤S103的示意性流程图;
图3B示出了本公开至少一个实施例提供的监控模块的结构示意图;
图4A示出了本公开至少一个实施例提供的步骤S104的示意性流程图;
图4B示出了图4A中步骤S401的示意性流程图;
图4C示出了图4A中步骤S402的示意性流程图;
图4D示出了本公开至少一个实施例提供的元数据服务器切换方式的一个示例的示意图;
图5A示出了步骤S105中的利用增加的元数据服务器接管元数据的示意性流程图;
图5B示出了本公开至少一个实施例提供的元数据服务器扩容的一个示例的示意图;
图6示出了本公开至少一个实施例提供的一种计算机***的示意框图;
图7为本公开一些实施例提供的一种电子设备的示意框图;
图8为本公开一些实施例提供的另一种电子设备的示意框图;
图9为本公开一些实施例提供的一种存储介质的示意图。
具体实施方式
为使本公开实施例的目的、技术方案和优点更加清楚,下面将结合本公开实施例的附图,对本公开实施例的技术方案进行清楚、完整地描述。显然,所描述的实施例是本公开的一部分实施例,而不是全部的实施例。基于所描述的本公开的实施例,本领域普通技术人员在无需创造性劳动的前提下所获得的所有其他实施例,都属于本公开保护的范围。
除非另外定义,本公开使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本公开中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性,而只是用来区分不同的组成部分。同样,“一个”、“一”或者“该”等类似词语也不表示数量限制,而是表示存在至少一个。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同,而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接,而是可以包括电性的连接,不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系,当被描述对象的绝对位置改变后,则该相对位置关系也可能相应地改变。
随着文件***的规模越来越大,提供元数据服务的元数据服务器的负担越来越重,元数据的管理也越来越复杂。在分布式文件***中,单一元数据服务器会成为整个***的瓶颈,所以通常的***都会采用多元数据服务器架构,即***中同时有多个元数据服务器协同提供元数据服务。对于分布式文件***而言,多个元数据服务器如何分工、如何保持数据的一致性以及发生故障后如何切换等问题是这类架构要解决的关键问题。
图1A示出了一种实现多元数据服务架构的模式示意图。
如图1A所示,***的元数据存储在一个同一个元数据存储区域上,多个元数据服务器按照一定的策略加载不同的元数据提供元数据服务。例如,元数据服务器1、元数据服务器2和元数据服务器3都从同一个元数据存储区域加载元数据。每个元数据服务器的缓存中缓存的内容是***所有元数据的一部分,该元数据服务器不会处理缓存在其它元数据服务器上的元数据。在这种模式下,***的元数据都保存在同一个元数据存储区域上,不同的元数据服务器按照一定的策略加载不同的元数据,根据要访问的元数据向不同的元数据服务器发送元数据请求。
在这种模式下,元数据被集中存储,便于维护,整个***中只有一个元数据存储区域,不会出现不同的元数据存储区域上的数据不一致的情况。并且,也方便在元数据存储区域上增加加速模块,如缓存等,以提高元数据的访问速度。但是这种架构的缺点也在于集中的元数据存储区域,集中的元数据存储区域容易成为整个***访问的瓶颈,随着***中的元数据越来越多,要读取某个文件的元数据时,寻址时间会越来越长。在元数据服务器切换及扩容/缩容时,当其中一个元数据服务器发生故障或者需要扩容一个新的元数据服务器时,在原来的元数据服务器上缓存的元数据需要切换到***中的其它元数据服务器上。其它元数据服务器需要重新计算并协商各自需要新增管理哪些元数据,协商的流程比较复杂,需要的时间较长。在进行元数据服务器切换或扩容/缩容操作时,客户端在访问数据的时候不确定应该访问***中的哪个元数据服务器,需要经过多次重定向,导致客户业务变慢。
图1B示出了另一种实现多元数据服务架构的模式示意图。
如图1B所示,***中存在多个元数据存储区域,每个元数据存储区域都保存***完整的元数据镜像,即***中一个文件的元数据会被写多份到所有的元数据存储区域中。元数据服务器按照一定的策略选择加载不同的元数据提供元数据服务。每个元数据服务器的缓存中只保留该元数据服务器管理的元数据。
如图1B所示,***中存在元数据存储区域1、元数据存储区域2和元数据存储区域3(这些元数据存储区域可以是单独的用于存储的服务器或存储设备,也可以是元数据服务器上的存储介质),每个元数据存储区域上都保存有***完整的元数据,相当于***的元数据保存了很多份。每个元数据服务器被分配管理一部分元数据,它只读写属于自己管理范围的元数据。当元数据服务器需要写元数据到元数据存储区域时,先写到跟自己关联的元数据存储区域上。例如,元数据服务器1和元数据存储区域1相关联,元数据服务器2和元数据存储区域2相关联,元数据服务器3和元数据存储区域3相关联。各个元数据存储区域之间有数据同步的模块,负责将一个元数据存储区域写入的数据同步到其它元数据存储区域上,最后达到所有的元数据存储区域都保存相同数据的状态。
***按照哈希值计算文件应该由哪个元数据服务器管理,每个元数据服务器都负责一部分哈希值。例如,元数据服务器1负责哈希值0x0~0x554,元数据服务器2负责哈希值0x555~0xAA9,元数据服务器3负责哈希值0XAAA~0xFFE。客户端需要访问文件时,根据文件名计算出哈希值,然后向负责该哈希值的元数据服务器发送请求。元数据被写入指定元数据服务器管理的元数据存储区域就返回响应,对于新写入的元数据,后台会慢慢在各个元数据存储区域之间同步,最后保证所有的元数据存储区域都存储有这个数据。
在这种模式下,元数据被存储在多个元数据存储区域中,即使有一个元数据存储区域损坏,仍然能从其它的元数据存储区域上读出所有的元数据。每个元数据服务器访问自己对应的元数据存储区域,数据访问瓶颈小。但是在这种模式下,遍历目录下的文件比较耗时。由于***中的元数据是按照哈希值打散在不同的元数据服务器上管理,在遍历大目录的时候,需要到其他节点上分别获取子目录和文件的属性,耗时比较长。扩容的时候需要将***的元数据都复制一份,需要复制的数据量比较大,多份存储需要的存储空间也比较大。元数据的异步复制需要一段时间,当一个元数据存储区域故障后,最新写入的文件可能还没来得及同步到其它的元数据存储区域上,会导致部分数据丢失或者不一致。
本公开至少一个实施例提供一种用于元数据服务架构的管理方法,该元数据服务架构包括多个元数据服务器,该管理方法包括:将文件***中的元数据划分为多个元数据片段并分别存储在不同的元数据存储区域中;每个元数据服务器管理至少一个元数据存储区域。
本公开实施例提供的管理方法将元数据划分到多个不同的存储区域存储,每个存储区域分属不同的元数据服务器管理,每个服务器管理一个或多个元数据存储区域,减少了***异常时数据的流动和交互,简化了元数据的管理,加速了元数据服务器的切换、升级等流程。
下面结合附图对本公开的实施例进行详细说明,但是本公开并不限于这些具体的实施例。
图2A示出了本公开至少一个实施例提供的一种元数据服务架构的结构示意图。
如图2A所示,***中存在3个元数据服务器(元数据服务器1~元数据服务器3),共有9个元数据存储区域用于存储元数据(元数据存储区域1~元数据存储区域9),这3个元数据服务器分别管理其中3个元数据存储区域。例如,元数据服务器1管理元数据存储区域1、元数据存储区域2以及元数据存储区域3,元数据服务器2管理元数据存储区域4、元数据存储区域5以及元数据存储区域6,元数据服务器3管理元数据存储区域7、元数据存储区域8以及元数据存储区域9。例如,这些元数据存储区域可以是单独的用于存储的服务器或存储设备,也可以是元数据服务器上的存储介质,本公开的实施例对此不作限制。
每个元数据服务器会为不同元数据存储区域上的元数据创建不同的缓存,元数据服务器管理缓存的创建、数据加载和淘汰、缓存的销毁等,各个缓存之间数据隔离且没有交互。每个缓存对应于一个元数据存储区域。例如,元数据服务器1创建了缓存1、缓存2和缓存3,缓存1用于加载元数据存储区域1中的元数据,缓存2用于加载元数据存储区域2中的元数据,缓存3用于加载元数据存储区域3中的元数据。元数据服务器2创建了缓存4、缓存5和缓存6,分别用于加载元数据存储区域4~元数据存储区域6中的元数据。元数据服务器3创建了缓存7、缓存8和缓存9,分别用于加载元数据存储区域7~元数据存储区域9中的元数据。
需要说明的是,本公开的实施例中,元数据服务器的数量和元数据存储区域的数量不受限制,可以为任意个数,这可以根据实际需求而定,本公开的实施例对此不作限制。例如,元数据存储区域的数量可以大于或等于元数据服务器的数量。
图2B示出了本公开至少一个实施例提供的一种用于元数据服务架构的管理方法的示意性流程图。
如图2B所示,该管理方法包括如下的步骤S101~S102。
步骤S101:将文件***中的元数据划分为多个元数据片段并分别存储在不同的元数据存储区域中。
步骤S102:每个元数据服务器管理至少一个元数据存储区域。
例如,在本公开的一些实施例中,步骤S101可以包括:根据目录特性将元数据划分为多个元数据片段;根据各个元数据服务器的负载确定多个元数据片段各自的存储位置并进行存储。
这里,根据目录特性对元数据进行划分是指,在划分元数据时,没有采用完全哈希的策略,对于目录下的文件,其元数据被写在与目录相同的元数据存储区域上,而该目录下的子目录的元数据通过一定的哈希算法存储到其它的元数据存储区域。通过这种方式,一方面保证了元数据在各个元数据存储区域上数据均衡,另一方面将文件的元数据和其父目录保存在同一个元数据存储区域,也避免了在遍历目录时频繁访问其它节点导致的访问速度变慢的问题。当然,本公开的实施例不限于此,根据目录特性对元数据进行划分,可以不仅仅考虑父目录/子目录的因素,还可以考虑目录的特点、目录数量、目录分支数量、复杂程度等因素,从而进行元数据的划分,本公开的实施例对此不作限制。
例如,在本公开的一些实施例中,不同的元数据片段存储在不同的元数据存储区域中,不同的元数据服务器管理不同的元数据存储区域。例如,不同的元数据存储区域所存储的元数据片段不同,也即是,不同的元数据存储区域所存储的元数据片段没有重复的部分,一个元数据片段仅存储在一个元数据存储区域中,不存在镜像备份。
例如,如图2A所示,不同的元数据片段可以存储在元数据存储区域1~元数据存储区域9中的任一个中,元数据服务器1管理元数据存储区域1~3,元数据服务器2管理元数据存储区域4~6,元数据服务器3管理元数据存储区域7~9。
例如,在本公开的一些实施例中,步骤S102可以包括:每个元数据服务器为不同的元数据存储区域中的元数据创建不同的缓存;读取元数据存储区域中的元数据并加载到对应的缓存中。
例如,在本公开的一些实施例中,元数据服务器配置为管理缓存的创建、数据加载和淘汰、缓存的释放。
例如,在文件***中,元数据服务器负责从磁盘上读取元数据并加载到自己的缓存中,向客户端提供元数据服务。***新增文件时,需要先把元数据写到元数据服务器的缓存中,元数据服务器处理后再统一写到磁盘上。
例如,如图2A所示,元数据服务器1为元数据存储区域1中的元数据创建缓存1,为元数据存储区域2中的元数据创建缓存2,为元数据存储区域3中的元数据创建缓存3,读取元数据存储区域1中的元数据并加载到缓存1中,读取元数据存储区域2中的元数据并加载到缓存2中,读取元数据存储区域3中的元数据并加载到缓存3中。
例如,本公开至少一个实施例提供的管理方法,还包括步骤S103:响应于文件***启动,为每个元数据服务器分配元数据。
图3A示出了本公开至少一个实施例提供的步骤S103的示意性流程图。
如图3A所示,步骤S103包括如下的步骤S301~S304。
步骤S301:响应于文件***启动,利用监控模块统计元数据服务器的信息和元数据存储区域的信息。
在文件***中,存在一个监控模块,该监控模块监控***中各个元数据服务器的运行情况,包括元数据、元数据服务器以及客户端等。当***中的元数据服务器出现问题后,监控模块更新本地记录的元数据服务器的状态,根据元数据服务器的状态更新各个元数据服务器与元数据存储区域的映射关系,并生成一个***内各元数据服务器的映射信息同步给其它元数据服务器或客户端,其它元数据服务器根据更新后的映射信息调整自己的业务。在监控模块中增加元数据存储区域管理模块,该元数据存储区域管理模块用于管理元数据存储区域的状态,并记录元数据服务器和其管理的元数据存储区域的映射关系。
图3B示出了本公开至少一个实施例提供的监控模块的结构示意图。
如图3B所示,监控模块除了包括元数据服务器管理模块、数据服务器管理模块和客户端管理模块之外,新增了元数据存储区域管理模块。关于该元数据存储区域管理模块的说明可参考上文内容,此处不再赘述。
返回至图3A,步骤S302~S304如下。
步骤S302:监控模块中的元数据存储区域管理模块将元数据存储区域分配给不同的元数据服务器。
步骤S303:元数据存储区域管理模块建立元数据存储区域和元数据服务器之间的映射信息,并将映射信息发送给元数据服务器。
步骤S304:元数据服务器响应于接收到映射信息,为每个元数据存储区域分配缓存,并分别加载各个元数据存储区域中的元数据到对应的缓存中。
当***启动的时候,监控模块会统计***中元数据服务器的信息和元数据存储区域的信息,元数据存储区域管理模块负责把元数据存储区域分配给不同的元数据服务器管理,建立它们的对应关系得到映射信息,然后把这个映射信息推送给元数据服务器。元数据服务器在接收到这个映射信息后,为对应管理的每个元数据存储区域分配一块缓存,并分别加载各个元数据存储区域上的元数据到对应的缓存中。
例如,返回至图2B,本公开至少一个实施例提供的管理方法,还包括步骤S104:将发生故障的元数据服务器管理的元数据存储区域进行重新分配。
图4A示出了本公开至少一个实施例提供的步骤S104的示意性流程图。
如图4A所示,步骤S104包括如下的步骤S401~S402。
步骤S401:响应于元数据服务器发生故障,元数据存储区域管理模块统计需要重新分配的元数据存储区域。
例如,图3B所示的监控模块中增加的元数据区域管理模块记录了***中所有元数据存储区域的状态,以及各个元数据存储区域属于哪个元数据服务器管理。由此,当某个元数据服务器发生故障时,可以统计出该故障的元数据服务器所管理的元数据存储区域,这些元数据存储区域即为需要重新分配的元数据存储区域。
步骤S402:根据元数据服务器的负载情况,元数据存储区域管理模块将发生故障的元数据服务器管理的元数据存储区域分配给其它元数据服务器。
当***中某个元数据服务器发生故障,监控模块中的元数据存储区域管理模块可以查询该元数据服务器上关联的元数据存储区域,并检查其它状态正常的元数据服务器的负载情况,把这些没有被管理的元数据存储区域分配给其他元数据服务器中负载较小的元数据服务器,或者分配给负载未饱和的元数据服务器。
在文件***中有元数据服务器发生故障时,该元数据服务器之前管理的元数据存储区域整体转换到其它元数据服务器上管理,不需要做数据迁移,接管的元数据服务器也不需要计算缓存中需要加载哪些元数据,只需要为新接管的元数据存储区域创建一个新的缓存,然后从该元数据存储区域上加载元数据就可以。客户端在获得最新的元数据存储区域和元数据服务器的映射信息之后,就可以将请求发送到对应的元数据服务器上进行处理。切换后加载数据不需要对元数据做单独区分,可以批量加载,因而元数据服务器接管新的元数据存储区域的速度非常快,基本不会影响业务访问。
图4B示出了图4A中步骤S401的示意性流程图。
如图4B所示,步骤S401中的元数据存储区域管理模块统计需要重新分配的元数据存储区域可以包括如下的步骤S411~S413。
步骤S411:元数据服务器周期性地向监控模块发送心跳信息,心跳信息包括元数据服务器的状态和所管理的各个元数据存储区域的状态。
步骤S412:监控模块根据元数据服务器发送的心跳信息更新监控模块中记录的元数据服务器的状态。
步骤S413:响应于监控模块未接收到心跳信息的时间超过阈值时间,监控模块认定元数据服务器故障且元数据服务器管理的元数据区域需要被重新分配。
例如,可以利用心跳机制来监控元数据服务器的状态。例如,在一些示例中,监控模块根据元数据服务器发送的心跳信息更新监控模块中记录的各个元数据服务器的状态。当元数据服务器发生故障,超过一段时间没有给监控模块发送心跳信息,监控模块就认为这个元数据服务器故障,需要将其管理的元数据存储区域重新分配给其它元数据服务器。需要说明的是,本公开的实施例中,可以采用任意适用的方式来监控元数据服务器的状态从而统计需要重新分配的元数据存储区域,而不限于采用上述心跳机制,这可以根据实际需求而定,本公开的实施例对此不作限制。
图4C示出了图4A中步骤S402的示意性流程图。
如图4C所示,步骤S402中的元数据存储区域管理模块将发生故障的元数据服务器管理的元数据存储区域分配给其它元数据服务器可以包括如下的步骤S421~S423。
步骤S421:监控模块响应于检测到发生故障的元数据服务器,根据负载均衡策略将发生故障的元数据服务器管理的元数据存储区域重新分配给其它元数据服务器。
步骤S422:更新监控模块中记录的元数据存储器区域和元数据服务器之间的映射信息,并将更新后的映射信息发送给各个元数据服务器。
步骤S423:元数据服务器响应于接收到更新后的映射信息,基于更新后的映射信息确定是否需要接管其它元数据服务器的元数据存储区域,并且,在需要接管其它元数据服务器的元数据存储区域的情形,在该元数据服务器上创建新的缓存并加载所接管的元数据存储区域的元数据。
例如,监控模块检测到有发生故障的元数据服务器后,根据负载均衡策略将其上管理的元数据存储区域重新分配给其它元数据服务器管理,并更新监控模块中记录的元数据服务器和元数据存储区域的对应关系,即映射信息,并将更新后的映射信息推送给***中的各个元数据服务器。例如,在一些示例中,负载均衡策略可以指尽量使各个元数据服务器用于管理各个元数据存储区域的开销相差较小,从而在整体上达到较优的性能。元数据服务器在接收到新的映射后,如果发现需要接管其它元数据存储区域,就会在本服务器上为接管的元数据服务器开辟一段新的缓存,然后开始加载这个元数据存储区域的数据。同时文件***的客户端也会收到监控模块推送的映射信息,客户端根据更新后的映射信息就可以正确推算出要访问的文件由哪个元数据服务器管理,并给该元数据服务器发送消息。
图4D示出了本公开至少一个实施例提供的元数据服务器切换方式的一个示例的示意图。
如图4D所示,监控模块400管理整个***的状态,元数据服务器1~3定时向监控模块400发送心跳信息,包括自己的状态以及自己管理的各个元数据存储区域的状态。假设元数据服务器1发生故障,超过一段时间没有给监控模块发送心跳信息,监控模块超过一段时间没有接收到元数据服务器1发送的心跳信息,因此判断元数据服务器1发生故障,将其管理的元数据存储区域重新分配给其它元数据服务器,原来由元数据服务器1管理的元数据存储区域1和元数据存储区域2切换到元数据服务器2上管理,原来由元数据服务器1管理的元数据存储区域3切换到元数据服务器3上管理。
通过上述方式,在元数据服务器切换所管理的元数据的时候不需要迁移数据,也不影响其它未出故障的元数据服务器上可被访问的数据,元数据服务器接管新的元数据存储区域的速度很快。客户端也能很快重新定位到新的元数据服务器,不需要经过多次重定向,访问基本不受影响。
当***的规模不断扩大,***中数据越来越多时,元数据服务器可能会成为整个***的访问瓶颈,这时候考虑扩充元数据服务器的数量来解决***的瓶颈问题。扩容的流程跟元数据切换类似,当***中扩充一个元数据服务器时,需要把原来元数据服务器上管理的元数据存储区域分配给新元数据服务器。
例如,返回至图2B,本公开至少一个实施例提供的管理方法,还包括步骤S105:在元数据服务架构中增加元数据服务器,并利用增加的元数据服务器接管元数据。
图5A示出了步骤S105中的利用增加的元数据服务器接管元数据的示意性流程图。
如图5A所示,步骤S105中的利用增加的元数据服务器接管元数据包括如下的步骤S501~S504。
步骤S501:增加的元数据服务器向监控模块注册,监控模块更新映射信息。
步骤S502:监控模块将更新后的映射信息发送给元数据服务架构中的所有元数据服务器。
步骤S503:各个元数据服务器将不再管理的元数据对应的缓存释放。
步骤S504:增加的元数据服务器创建缓存并加载要接管的元数据。
例如,当有新的元数据服务器加入时,监控模块增加关于新的元数据服务器的映射信息,同时启动对元数据存储区域的重新分配。监控模块会检查当前正在服务的元数据服务器的负载情况,把一部分元数据存储区域分配给新的元数据服务器管理。例如,可以将负载较重的元数据服务器管理的一部分元数据存储区域分配给新的元数据服务器管理。
图5B示出了本公开至少一个实施例提供的元数据服务器扩容的一个示例的示意图。
如图5B所示,在***中原来有两个元数据服务器(元数据服务器1和元数据服务器2),6个元数据存储区域(元数据存储区域1~元数据存储区域6)分属于两个不同的元数据服务器管理,元数据服务器1管理元数据存储区域1~元数据存储区域3,元数据服务器2管理元数据存储区域4~元数据存储区域6。
当***中再扩展一个元数据服务器(元数据服务器3)后,这个元数据服务器会向监控模块500注册,监控模块500把新注册的元数据服务器3加到自己的地图(map)中,同时启动对元数据存储区域的重新分配,将原来分属于元数据服务器1和元数据服务器2管理的元数据存储区域3和元数据存储区域6分配给元数据服务器3管理,监控模块500将新生成的映射信息推送给***所有的元数据服务器。
元数据服务器1接收到映射信息后,根据映射信息获知自己不再管理元数据存储区域3,元数据服务器2接收到映射信息后,根据映射信息获知自己不再管理元数据存储区域6,于是分别把要去除的元数据存储区域的数据对应的缓存直接释放掉。元数据服务器3接收到映射信息后,根据映射信息获知自己要接管这两个元数据存储区域,因此在自己的缓存中新建两个缓存(缓存3和缓存6),分别加载各个元数据存储区域(元数据存储区域3和元数据存储区域6)的数据到各自的缓存中。
***中的客户端接收到新的映射信息后,根据映射信息获知新增的元数据服务器3及其接管的元数据存储服务,此后操作元数据存储区域3和元数据存储区域6上的数据的请求都会发送给元数据服务器3处理。由此,不需要做数据迁移,从而快速完成新的元数据服务器对元数据的接管。
需要说明的是,本公开对上述步骤S103~S105的执行顺序不做限制,也不要求执行步骤S103~S105中的所有步骤,可以根据实际情况增减步骤。
本公开至少一个实施例还提供一种计算机***。该计算机***将元数据划分到多个不同的存储区域存储,每个存储区域分属不同的元数据服务器管理,每个服务器管理一个或多个元数据存储区域,减少了***异常时数据的流动和交互,简化了元数据的管理,加速了元数据服务器的切换、升级等流程。
图6示出了本公开至少一个实施例提供的一种计算机***600的示意框图,该计算机***600可以用于执行图2B所示的管理方法。
如图6所示,计算机***600包括多个元数据服务器601和多个元数据存储区域602。
每个元数据服务器601被配置为管理多个元数据存储区域中的至少一个元数据存储区域。
每个元数据存储区域602被配置为存储对应的元数据。
例如,文件***中的元数据被划分为多个元数据片段并分别存储在不同的元数据存储区域中。
例如,在本公开的一些实施例中,计算***600还包括监控模块603。
监控模块603被配置为记录多个元数据服务器的信息和多个元数据存储区域的信息,并管理多个元数据服务器与多个元数据存储区域之间的映射关系。
例如,元数据服务器601可以采用任意架构的服务器,例如X86或ARM架构等。元数据服务器601可以是物理的服务器,也可以是虚拟服务器,可以为分布式或集中式,本公开的实施例对此不作限制。元数据服务器601的数量和元数据存储区域602的数量可以根据实际需求而定,本公开的实施例对此不作限制。元数据存储区域602可以是单独的用于存储的服务器或存储设备,也可以是元数据服务器上的存储介质,本公开的实施例对此不作限制。
例如,计算机***600可以采用硬件、软件、固件以及它们的任意可行的组合实现,本公开对此不作限制。
上述计算机***600的技术效果与图2B所示的管理方法的技术效果相同,在此不再赘述。
本公开的至少一个实施例还提供了一种电子设备,该电子设备包括处理器和存储器。存储器上存储有计算机可执行指令,计算机可执行指令在被处理器执行时可以实现本公开至少一实施例提供的管理方法。
图7为本公开一些实施例提供的一种电子设备700的示意框图。如图7所示,该电子设备700包括处理器710和存储器720。存储器720用于存储计算机可执行指令(例如一个或多个计算机程序模块)。处理器710用于运行计算机可执行指令,计算机可执行指令被处理器710运行时可以执行上文所述的管理方法中的一个或多个步骤。存储器720和处理器710可以通过总线***和/或其它形式的连接机构(未示出)互连。
例如,处理器710可以是中央处理单元(CPU)、图形处理单元(GPU)或者具有数据处理能力和/或程序执行能力的其它形式的处理单元。例如,中央处理单元(CPU)可以为X86或ARM架构等。处理器710可以为通用处理器或专用处理器,可以控制电子设备700中的其它组件以执行期望的功能。
例如,存储器720可以包括一个或多个计算机程序产品的任意组合,计算机程序产品可以包括各种形式的计算机可读存储介质,例如易失性存储器和/或非易失性存储器。易失性存储器例如可以包括随机存取存储器(RAM)和/或高速缓冲存储器(cache)等。非易失性存储器例如可以包括只读存储器(ROM)、硬盘、可擦除可编程只读存储器(EPROM)、便携式紧致盘只读存储器(CD-ROM)、USB存储器、闪存等。在计算机可读存储介质上可以存储一个或多个计算机程序模块,处理器710可以运行一个或多个计算机程序模块,以实现电子设备700的各种功能。在计算机可读存储介质中还可以存储各种应用程序和各种数据以及应用程序使用和/或产生的各种数据等。
需要说明的是,本公开的实施例中,电子设备700的具体功能和技术效果可以参考上文中关于管理方法的描述,此处不再赘述。
图8为本公开一些实施例提供的另一种电子设备的示意框图。该电子设备800例如适于用来实施本公开实施例提供的管理方法。电子设备800可以是终端设备或计算机***等。需要注意的是,图8示出的电子设备800仅仅是一个示例,其不会对本公开实施例的功能和使用范围带来任何限制。
如图8所示,电子设备800可以包括处理装置(例如中央处理器、图形处理器等)810,其可以根据存储在只读存储器(ROM)820中的程序或者从存储装置880加载到随机访问存储器(RAM)830中的程序而执行各种适当的动作和处理。在RAM 830中,还存储有电子设备800操作所需的各种程序和数据。处理装置810、ROM 820以及RAM 830通过总线840彼此相连。输入/输出(I/O)接口850也连接至总线840。
通常,以下装置可以连接至I/O接口850:包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置860;包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置870;包括例如磁带、硬盘等的存储装置880;以及通信装置890。通信装置890可以允许电子设备800与其他电子设备进行无线或有线通信以交换数据。虽然图8示出了具有各种装置的电子设备800,但应理解的是,并不要求实施或具备所有示出的装置,电子设备800可以替代地实施或具备更多或更少的装置。
例如,根据本公开的实施例,上述管理方法可以被实现为计算机软件程序。例如,本公开的实施例包括一种计算机程序产品,其包括承载在非暂态计算机可读介质上的计算机程序,该计算机程序包括用于执行上述管理方法的程序代码。在这样的实施例中,该计算机程序可以通过通信装置890从网络上被下载和安装,或者从存储装置880安装,或者从ROM820安装。在该计算机程序被处理装置810执行时,可以实现本公开实施例提供的管理方法中限定的功能。
本公开至少一个实施例提供一种计算机可读存储介质,用于非暂时性存储计算机可执行指令,计算机可执行指令在被处理器执行时实现本公开至少一实施例提供的管理方法。
图9为本公开一些实施例提供的一种存储介质的示意图。如图9所示,存储介质900用于存储计算机可执行指令910。例如,当计算机可执行指令910由计算机执行时可以执行根据上文所述的管理方法中的一个或多个步骤。关于存储介质900的详细说明和技术效果可以参考上文中关于管理方法的描述,此处不再赘述。
有以下几点需要说明:
(1)本公开实施例附图只涉及到本公开实施例涉及到的结构,其他结构可参考通常设计。
(2)在不冲突的情况下,本公开的实施例及实施例中的特征可以相互组合以得到新的实施例。
以上所述,仅为本公开的具体实施方式,但本公开的保护范围并不局限于此,本公开的保护范围应以所述权利要求的保护范围为准。
Claims (17)
1.一种用于元数据服务架构的管理方法,其中,所述元数据服务架构包括多个元数据服务器,所述管理方法包括:
将文件***中的元数据划分为多个元数据片段并分别存储在不同的元数据存储区域中;
每个所述元数据服务器管理至少一个所述元数据存储区域。
2.根据权利要求1所述的管理方法,其中,不同的元数据片段存储在不同的元数据存储区域中,不同的元数据服务器管理不同的元数据存储区域,不同的元数据存储区域所存储的元数据片段不同。
3.根据权利要求1所述的管理方法,其中,将所述文件***中的元数据划分为所述多个元数据片段并分别存储在不同的元数据存储区域中,包括:
根据目录特性将所述元数据划分为所述多个元数据片段;
根据各个元数据服务器的负载确定所述多个元数据片段各自的存储位置并进行存储。
4.根据权利要求1所述的管理方法,其中,每个所述元数据服务器管理至少一个所述元数据存储区域,包括:
每个所述元数据服务器为不同的元数据存储区域中的元数据创建不同的缓存;
读取所述元数据存储区域中的元数据并加载到对应的缓存中。
5.根据权利要求1-4中的任一项所述的管理方法,其中,所述元数据服务器配置为管理缓存的创建、数据加载和淘汰、缓存的释放。
6.根据权利要求1-4中的任一项所述的管理方法,还包括:
响应于所述文件***启动,为每个所述元数据服务器分配元数据。
7.根据权利要求6所述的管理方法,其中,响应于所述文件***启动,为每个所述元数据服务器分配元数据,包括:
响应于所述文件***启动,利用监控模块统计所述元数据服务器的信息和所述元数据存储区域的信息;
所述监控模块中的元数据存储区域管理模块将所述元数据存储区域分配给不同的元数据服务器;
所述元数据存储区域管理模块建立所述元数据存储区域和所述元数据服务器之间的映射信息,并将所述映射信息发送给所述元数据服务器;
所述元数据服务器响应于接收到所述映射信息,为每个所述元数据存储区域分配缓存,并分别加载各个元数据存储区域中的元数据到对应的缓存中。
8.根据权利要求1-4中的任一项所述的管理方法,还包括:
将发生故障的元数据服务器管理的元数据存储区域进行重新分配。
9.根据权利要求8所述的管理方法,其中,将发生故障的元数据服务器管理的元数据存储区域进行重新分配,包括:
响应于所述元数据服务器发生故障,所述元数据存储区域管理模块统计需要重新分配的元数据存储区域;
根据所述元数据服务器的负载情况,所述元数据存储区域管理模块将发生故障的元数据服务器管理的元数据存储区域分配给其它元数据服务器。
10.根据权利要求9所述的管理方法,其中,所述元数据存储区域管理模块统计需要重新分配的元数据存储区域,包括:
所述元数据服务器周期性地向监控模块发送心跳信息,其中,所述心跳信息包括所述元数据服务器的状态和所管理的各个元数据存储区域的状态;
所述监控模块根据所述元数据服务器发送的所述心跳信息更新所述监控模块中记录的所述元数据服务器的状态;
响应于所述监控模块未接收到所述心跳信息的时间超过阈值时间,所述监控模块认定所述元数据服务器故障且所述元数据服务器管理的元数据区域需要被重新分配。
11.根据权利要求9所述的管理方法,其中,所述元数据存储区域管理模块将发生故障的元数据服务器管理的元数据存储区域分配给其它元数据服务器,包括:
监控模块响应于检测到发生故障的元数据服务器,根据负载均衡策略将所述发生故障的元数据服务器管理的元数据存储区域重新分配给其它元数据服务器;
更新所述监控模块中记录的所述元数据存储器区域和所述元数据服务器之间的映射信息,并将更新后的映射信息发送给各个元数据服务器;
所述元数据服务器响应于接收到所述更新后的映射信息,基于所述更新后的映射信息确定是否需要接管其它元数据服务器的元数据存储区域,并且,在需要接管其它元数据服务器的元数据存储区域的情形,在该元数据服务器上创建新的缓存并加载所接管的元数据存储区域的元数据。
12.根据权利要求1-4中的任一项所述的管理方法,还包括:
在所述元数据服务架构中增加元数据服务器,并利用增加的元数据服务器接管所述元数据。
13.根据权利要求12所述的管理方法,其中,利用增加的元数据服务器接管所述元数据,包括:
所述增加的元数据服务器向监控模块注册,所述监控模块更新映射信息;
所述监控模块将更新后的映射信息发送给所述元数据服务架构中的所有元数据服务器;
各个元数据服务器将不再管理的元数据对应的缓存释放;
所述增加的元数据服务器创建缓存并加载要接管的元数据。
14.一种计算机***,包括多个元数据服务器和多个元数据存储区域,其中,
所述计算机***运行有文件***,所述文件***中的元数据被划分为多个元数据片段并分别存储在不同的元数据存储区域中,
每个元数据服务器被配置为管理所述多个元数据存储区域中的至少一个元数据存储区域,
每个元数据存储区域被配置为存储对应的元数据。
15.根据权利要求14所述的计算机***,还包括监控模块,其中,
所述监控模块被配置为记录所述多个元数据服务器的信息和所述多个元数据存储区域的信息,并管理所述多个元数据服务器与所述多个元数据存储区域之间的映射关系。
16.一种电子设备,包括:
处理器;以及
存储器,存储有计算机可执行指令,
其中,所述计算机可执行指令在被所述处理器执行时实现根据权利要求1-13中任一项所述的用于元数据服务架构的管理方法。
17.一种计算机可读存储介质,用于非瞬时性地存储计算机可执行指令,
其中,所述计算机可执行指令在被处理器执行时实现根据权利要求1-13中任一项所述的用于元数据服务架构的管理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210261242.0A CN114328421B (zh) | 2022-03-17 | 2022-03-17 | 元数据服务架构管理方法、计算机***、电子设备及介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210261242.0A CN114328421B (zh) | 2022-03-17 | 2022-03-17 | 元数据服务架构管理方法、计算机***、电子设备及介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN114328421A true CN114328421A (zh) | 2022-04-12 |
CN114328421B CN114328421B (zh) | 2022-06-10 |
Family
ID=81034102
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210261242.0A Active CN114328421B (zh) | 2022-03-17 | 2022-03-17 | 元数据服务架构管理方法、计算机***、电子设备及介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114328421B (zh) |
Citations (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101567003A (zh) * | 2009-05-27 | 2009-10-28 | 清华大学 | 并行文件***中资源的管理和分配方法 |
CN101999225A (zh) * | 2008-03-13 | 2011-03-30 | 哈里公司 | 用于将来自故障服务器的客户端负载在存储区域网络(san)中的剩余服务器之间分配的***和方法 |
US20110219106A1 (en) * | 2010-03-05 | 2011-09-08 | Solidfire, Inc. | Data Deletion in a Distributed Data Storage System |
CN103699585A (zh) * | 2013-12-06 | 2014-04-02 | 华为技术有限公司 | 文件的元数据存储以及文件恢复的方法、装置和*** |
CN105471695A (zh) * | 2014-08-21 | 2016-04-06 | 西安慧泽知识产权运营管理有限公司 | 一种存储区域网络虚拟化管理方法 |
CN106648457A (zh) * | 2016-09-27 | 2017-05-10 | 华为数字技术(成都)有限公司 | 更新反向映射元数据的方法及装置 |
US9720921B1 (en) * | 2011-08-10 | 2017-08-01 | Nutanix, Inc. | Mapping structure for maintaining metadata for snapshots in a virtualized storage environment |
CN107844592A (zh) * | 2017-11-17 | 2018-03-27 | 北京盛和大地数据科技有限公司 | 一种查询元数据的方法和装置 |
CN108271420A (zh) * | 2016-11-02 | 2018-07-10 | 华为技术有限公司 | 管理文件的方法、文件***和服务器*** |
CN109299056A (zh) * | 2018-09-19 | 2019-02-01 | 潍坊工程职业学院 | 一种基于分布式文件***的数据同步方法和装置 |
CN110046133A (zh) * | 2019-04-12 | 2019-07-23 | 苏州浪潮智能科技有限公司 | 一种存储文件***的元数据管理方法、装置及*** |
CN110149409A (zh) * | 2019-06-04 | 2019-08-20 | 平安科技(深圳)有限公司 | 云主机元数据服务管理方法、***、设备及存储介质 |
CN111427841A (zh) * | 2020-02-26 | 2020-07-17 | 平安科技(深圳)有限公司 | 数据管理方法、装置、计算机设备和存储介质 |
CN112667577A (zh) * | 2020-12-25 | 2021-04-16 | 浙江大华技术股份有限公司 | 一种元数据管理方法、元数据管理***及存储介质 |
-
2022
- 2022-03-17 CN CN202210261242.0A patent/CN114328421B/zh active Active
Patent Citations (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101999225A (zh) * | 2008-03-13 | 2011-03-30 | 哈里公司 | 用于将来自故障服务器的客户端负载在存储区域网络(san)中的剩余服务器之间分配的***和方法 |
CN101567003A (zh) * | 2009-05-27 | 2009-10-28 | 清华大学 | 并行文件***中资源的管理和分配方法 |
US20110219106A1 (en) * | 2010-03-05 | 2011-09-08 | Solidfire, Inc. | Data Deletion in a Distributed Data Storage System |
US9720921B1 (en) * | 2011-08-10 | 2017-08-01 | Nutanix, Inc. | Mapping structure for maintaining metadata for snapshots in a virtualized storage environment |
CN103699585A (zh) * | 2013-12-06 | 2014-04-02 | 华为技术有限公司 | 文件的元数据存储以及文件恢复的方法、装置和*** |
CN105471695A (zh) * | 2014-08-21 | 2016-04-06 | 西安慧泽知识产权运营管理有限公司 | 一种存储区域网络虚拟化管理方法 |
CN106648457A (zh) * | 2016-09-27 | 2017-05-10 | 华为数字技术(成都)有限公司 | 更新反向映射元数据的方法及装置 |
CN108271420A (zh) * | 2016-11-02 | 2018-07-10 | 华为技术有限公司 | 管理文件的方法、文件***和服务器*** |
CN107844592A (zh) * | 2017-11-17 | 2018-03-27 | 北京盛和大地数据科技有限公司 | 一种查询元数据的方法和装置 |
CN109299056A (zh) * | 2018-09-19 | 2019-02-01 | 潍坊工程职业学院 | 一种基于分布式文件***的数据同步方法和装置 |
CN110046133A (zh) * | 2019-04-12 | 2019-07-23 | 苏州浪潮智能科技有限公司 | 一种存储文件***的元数据管理方法、装置及*** |
CN110149409A (zh) * | 2019-06-04 | 2019-08-20 | 平安科技(深圳)有限公司 | 云主机元数据服务管理方法、***、设备及存储介质 |
CN111427841A (zh) * | 2020-02-26 | 2020-07-17 | 平安科技(深圳)有限公司 | 数据管理方法、装置、计算机设备和存储介质 |
CN112667577A (zh) * | 2020-12-25 | 2021-04-16 | 浙江大华技术股份有限公司 | 一种元数据管理方法、元数据管理***及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN114328421B (zh) | 2022-06-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10838829B2 (en) | Method and apparatus for loading data from a mirror server and a non-transitory computer readable storage medium | |
US20190004863A1 (en) | Hash-based partitioning system | |
US9852151B1 (en) | Network system to distribute chunks across multiple physical nodes with disk support for object storage | |
US20190146675A1 (en) | On-demand storage provisioning using distributed and virtual namespace management | |
US20140351636A1 (en) | Method, device, and system for data reconstruction | |
US9733989B1 (en) | Non-disruptive load-balancing of virtual machines between data centers | |
CN111124475B (zh) | 存储管理的方法、电子设备和计算机可读存储介质 | |
US20160294930A1 (en) | Service migration across cluster boundaries | |
BR112014030364B1 (pt) | Sistema de plataforma multicamada para acessar pelo menos uma imagem virtual usada por pelo menos uma máquina virtual e método para gerenciar uma plataforma multicamada a acessar pelo menos uma imagem virtual usada por pelo menos uma máquina virtual | |
US20210185142A1 (en) | Cache storage for streaming data | |
US12045207B2 (en) | Distributed file system that provides scalability and resiliency | |
US20230221897A1 (en) | Implementing coherency and page cache support for a storage system spread across multiple data centers | |
US20240143233A1 (en) | Distributed File System with Disaggregated Data Management and Storage Management Layers | |
US11675545B2 (en) | Distributed storage system and storage control method | |
US20220391361A1 (en) | Distributed File System with Reduced Write and Read Latencies | |
CN113190619B (zh) | 分布式kv数据库的数据读写方法、***、设备和介质 | |
CN114328421B (zh) | 元数据服务架构管理方法、计算机***、电子设备及介质 | |
US11531483B2 (en) | Direct data placement | |
CN114930281A (zh) | 动态自适应分区分割 | |
US9372700B2 (en) | Network boot system | |
US10929168B2 (en) | Enhanced data storage and versioning of virtual nodes in a data processing environment | |
JP2010237742A (ja) | 仮想マシンサーバ、仮想マシン制御方法及び仮想マシン制御プログラム | |
KR101754713B1 (ko) | 비대칭 분산 파일 시스템, 연산 분배 장치 및 방법 | |
CN113590309B (zh) | 一种数据处理方法、装置、设备及存储介质 | |
JP7021742B2 (ja) | 情報処理装置、情報処理方法、プログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40066400 Country of ref document: HK |