一种残膜回收机防缠绕挑膜装置的制 一种秧草收获机用电力驱动行走机构

存储设备中的元数据处理方法及相关设备与流程

2021-12-17 20:52:00 来源:中国专利 TAG:

存储设备中的元数据处理方法及相关设备
1.本技术要求于2020年06月11日提交的申请号为202010526832.2、发明名称为“一种存储系统、存储节点和数据存储方法”的中国专利申请的优先权,其全部内容通过引用结合在本技术中。
技术领域
2.本技术涉及存储技术领域,特别涉及一种存储设备中的元数据处理方法及相关设备。


背景技术:

3.为了保证数据的查询,对于存储设备中存储的数据,还配置有该数据的元数据。元数据用于指示该数据的存储位置。在写入数据时,通常需要同时写入该数据的元数据。而在读取数据时,则先需要获取该数据的元数据,以便于基于该元数据读取数据。因此在读写数据的过程中,如何对元数据进行处理在一定程度上影响了该存储设备的读写效率。


技术实现要素:

4.本技术提供了一种存储设备中的元数据处理方法及相关设备,可以提高存储设备读写数据的效率。该技术方案如下:
5.第一方面,提供了一种存储设备中的元数据处理方法。在该方法中,存储设备中的网卡接收输入输出(input/output,io)请求,该io请求包括读数据请求或写数据请求。网卡执行该io请求所对应的元数据处理任务。在网卡确定该元数据处理任务执行失败的情况下,网卡请求存储设备中的中央处理器(central processing unit,cpu)执行该元数据处理任务。
6.在本技术中,为了减缓cpu处理数据的压力,网卡在接收到io请求时,并不直接将该io请求转移给cpu,而是由网卡先执行该元数据处理任务。如果元数据处理任务执行失败,则请求cpu执行该元数据处理任务。如此,可以避免io请求所对应的元数据处理任务全部由网卡执行、或者全部由cpu执行。因此,存储设备便可自适应地从cpu中卸载部分的元数据处理任务给网卡,不仅可以减轻cpu的数据处理压力,还可以避免由于网卡处理元数据带来的时延过长,从而提高存储设备读写数据的效率。
7.基于第一方面提供的方法,在一种可能的实现方式中,网卡包含内存,该元数据处理任务执行失败的情况包括:网卡的内存不足以提供该元数据处理任务所需的内存资源。
8.在网卡执行元数据处理任务的过程中,如果网卡的可用内存不足以提供该元数据处理任务所需的内存,网卡则可以确定该元数据处理任务执行失败。如此,网卡可以在执行元数据处理任务的过程中,快速判断该元数据处理任务是否失败,提高了执行元数据处理任务的灵活性。
9.基于第一方面提供的方法,在一种可能的实现方式中,当io请求是读数据请求时,元数据处理任务执行失败的情况包括:读数据请求携带的逻辑地址的地址长度超过长度阈
值。
10.在读数据请求的场景中,如果由网卡来直接读取逻辑地址的地址长度超过长度阈值的数据,由于网卡需要多次交互才能读取到该数据,导致网卡读取数据所需时间较长。因此,在本技术中,如果读数据请求携带的逻辑地址的地址长度超过长度阈值,则请求cpu执行元数据处理任务,以提高读取逻辑地址的地址长度超过长度阈值的数据的效率。
11.基于第一方面提供的方法,在一种可能的实现方式中,存储设备包括第一索引库和第二索引库,第一索引库存储的元数据的数据量小于第二索引库存储的元数据的数据量。这种场景下,当io请求是读数据请求时,该元数据处理任务执行失败的情况包括:网卡在第一索引库中未获取到读数据请求对应的元数据。此时,网卡请求存储设备中的cpu执行元数据处理任务包括:网卡指示cpu从第二索引库获取读数据请求对应的元数据。
12.此外,由于从第一索引库中获取元数据所需要处理的数据量小于从第二索引库中获取元数据所需要处理的数据量,因此,在本技术实施例中,可以由网卡先从第一索引库中获取元数据,在网卡没有从第一索引库中获取到元数据的情况下,再由cpu从第二索引库中获取元数据,从而提高获取元数据的效率。
13.基于第一方面提供的方法,在一种可能的实现方式中,第一索引库包括热点数据的元数据,第二索引库包括非热点数据的元数据。
14.上述第一索引库中包括热点数据的元数据,由于热点数据为访问频率较高的数据,因此,将热点数据的元数据单独存放在一个索引库可以提高读取热点数据的元数据的效率。
15.基于第一方面提供的方法,在一种可能的实现方式中,当io请求是写数据请求时,该元数据处理任务为存储写数据请求对应的元数据。
16.基于第一方面提供的方法,在一种可能的实现方式中,当io请求是读数据请求时,该元数据处理任务为获取读数据请求对应的元数据。
17.在本技术中,在不同的io请求中,元数据处理任务所需执行的操作也不同。
18.基于第一方面提供的方法,在一种可能的实现方式中,该io请求对应的元数据用于指示该io请求对应的数据的存储位置。
19.在本技术实施例中,io请求对应的元数据包括数据的存储位置相关的信息,以便于在读数据场景中,网卡基于索引库便可获取到数据的存储位置相关的信息,从而使得网卡可以绕过cpu读取到数据,提高了存储设备读取数据的效率。
20.基于第一方面提供的方法,在一种可能的实现方式中,元数据包括键-值对,键-值对中的键指示与io请求对应的数据的逻辑地址,键-值对中的值指示与io请求对应的数据的物理地址。
21.通过上述键-值对可以在元数据中存储数据的逻辑地址和物理地址之间的对应关系,以实现网卡基于索引库便可获取到数据的存储位置相关的信息的技术效果,从而使得网卡可以绕过cpu读取到数据,提高了存储设备读取数据的效率。
22.基于第一方面提供的方法,在一种可能的实现方式中,元数据包括键-值对,键-值对中的键指示与io请求对应的数据的逻辑地址,键-值对中的值指示与io请求对应的数据的指纹信息。
23.由于通过数据的指纹信息可以继续查询到数据的物理地址,因此上述方式同样可
以实现网卡基于索引库便可获取到数据的存储位置相关的信息的技术效果,从而使得网卡可以绕过cpu读取到数据,提高了存储设备读取数据的效率。
24.基于第一方面提供的方法,在一种可能的实现方式中,存储设备是存储阵列,或者是分布式存储系统中的一个存储节点。本技术实施例提供的方法可以应用于单一存储设备中,也可以应用于分布式存储系统的某个存储节点上。
25.第二方面、提供了一种存储设备中的元数据处理方法。在该方法中,存储设备中的网卡接收多个io请求,该io请求包括读数据请求或写数据请求,网卡确定该io请求的数量超过设定的数量阈值时,网卡请求存储设备中的cpu处理这多个io请求中的至少一个io请求所对应的元数据处理任务。
26.在本技术中,可以基于io请求的数量对当前要处理的元数据执行任务的执行结果进行预判,当io请求的数量超过一定数量时,预判网卡无法成功执行该元数据处理任务,此时则可以请求cpu来执行元数据处理任务。不仅提高了元数据处理的灵活性。还可以实现网卡和cpu自适应动态执行元数据处理任务。至少一个io请求可以是多个io请求中的部分io请求,也可以是全部io请求。如此,便可自适应地从cpu中卸载部分的元数据处理任务给网卡,不仅可以减轻cpu的数据处理压力,还可以避免由于网卡处理元数据带来的时延过长,从而提高存储设备读写数据的效率。
27.当io请求的数量超过一定数量后,可以由cpu处理全部的io请求,也可以由cpu处理一部分,网卡处理另一部分,提高了处理元数据的灵活性。
28.基于第二方面提供的方法,在一种可能的实现方式中,当io请求是写数据请求时,元数据处理任务为存储写数据请求对应的元数据。
29.基于第二方面提供的方法,在一种可能的实现方式中,当io请求是读数据请求时,元数据处理任务为获取读数据请求对应的元数据。
30.基于第二方面提供的方法,在一种可能的实现方式中,该io请求对应的元数据用于指示该io请求对应的数据的存储位置。
31.基于第二方面提供的方法,在一种可能的实现方式中,元数据包括键-值对,键-值对中的键指示与io请求对应的数据的逻辑地址,键-值对中的值指示与io请求对应的数据的物理地址。
32.基于第二方面提供的方法,在一种可能的实现方式中,元数据包括键-值对,键-值对中的键指示与io请求对应的数据的逻辑地址,键-值对中的值指示与io请求对应的数据的指纹信息。
33.基于第二方面提供的方法,在一种可能的实现方式中,存储设备是存储阵列,或者是分布式存储系统中的一个存储节点。
34.以上元数据的相关解释的有益效果可以参考第一方面提供的元数据处理方法中相关实现方式的技术效果,在此不再赘述。
35.第三方面,提供了一种元数据处理装置,元数据处理装置具有实现上述第一方面中元数据处理方法的功能。元数据处理装置包括至少一个模块,该至少一个模块用于实现上述第一方面所提供的元数据处理方法。
36.第四方面,提供了一种元数据处理装置,元数据处理装置具有实现上述第二方面中元数据处理方法的功能。元数据处理装置包括至少一个模块,该至少一个模块用于实现
上述第二方面所提供的元数据处理方法。
37.第五方面,提供了一种网卡,网卡包括通信接口和处理器,通信接口用于和存储设备中的cpu通信,处理器该用于实现上述第一方面或第二方面中任一项的方法的功能。
38.第六方面,提供了一种存储设备,该存储设备包括网卡和cpu;
39.该网卡,用于接收io请求,执行io请求所对应的元数据处理任务,在网卡确定元数据处理任务执行失败的情况下,请求cpu执行元数据处理任务,该io请求包括读数据请求或写数据请求;
40.该cpu,用于基于网卡的请求,执行元数据处理任务。
41.具体实现方式可以参考第一方面提供的存储设备中的元数据处理方法的实现方式,在此不再赘述。
42.网卡包含内存,元数据处理任务执行失败的情况包括:网卡的内存不足以提供元数据处理任务所需的内存资源。
43.基于第六方面提供的存储设备,在一种可能的实现方式中,当io请求是读数据请求时,元数据处理任务执行失败的情况包括:读数据请求携带的逻辑地址的地址长度超过长度阈值。
44.基于第六方面提供的存储设备,在一种可能的实现方式中,存储设备包括第一索引库和第二索引库,第一索引库存储的元数据的数据量小于第二索引库存储的元数据的数据量,当io请求是读数据请求时,元数据处理任务执行失败的情况包括:网卡在第一索引库中未获取到读数据请求对应的元数据;网卡请求存储设备中的cpu执行元数据处理任务包括:网卡指示cpu从第二索引库获取读数据请求对应的元数据。
45.基于第六方面提供的存储设备,在一种可能的实现方式中,第一索引库包括热点数据的元数据,第二索引库包括非热点数据的元数据。
46.基于第六方面提供的存储设备,在一种可能的实现方式中,当io请求是写数据请求时,元数据处理任务为存储写数据请求对应的元数据。
47.基于第六方面提供的存储设备,在一种可能的实现方式中,当io请求是读数据请求时,元数据处理任务为获取读数据请求对应的元数据。
48.基于第六方面提供的存储设备,在一种可能的实现方式中,io请求对应的元数据用于指示io请求对应的数据的存储位置。
49.基于第六方面提供的存储设备,在一种可能的实现方式中,元数据包括键-值对,键-值对中的键用于指示与io请求对应的数据的逻辑地址,键-值对中的值用于指示与io请求对应的数据的物理地址。
50.基于第六方面提供的存储设备,在一种可能的实现方式中,元数据包括键-值对,键-值对中的键用于指示与io请求对应的数据的逻辑地址,键-值对中的值用于指示与io请求对应的数据的指纹信息。
51.基于第六方面提供的存储设备,在一种可能的实现方式中,存储设备是存储阵列,或者是分布式存储系统中的一个存储节点。
52.第七方面,提供了一种存储设备,该存储设备包括网卡和cpu;
53.该网卡,用于接收多个输入输出io请求,在确定io请求的数量超过设定的数量阈值时,请求cpu处理多个io请求中的至少一个io请求所对应的元数据处理任务;
54.该cpu,用于基于网卡的请求,执行至少一个io请求所对应的元数据处理任务。
55.具体实现方式可以参考第二方面提供的存储设备中的元数据处理方法的实现方式,在此不再赘述。
56.基于第七方面提供的存储设备,在一种可能的实现方式中,至少一个io请求是多个io请求中的所有io请求。
57.基于第七方面提供的存储设备,在一种可能的实现方式中,至少一个io请求是多个io请求的子集;网卡还用于执行多个io请求中除至少一个io请求之外的其余io请求所对应的元数据处理任务。
58.基于第七方面提供的存储设备,在一种可能的实现方式中,当io请求是写数据请求时,元数据处理任务为存储写数据请求对应的元数据。
59.基于第七方面提供的存储设备,在一种可能的实现方式中,当io请求是读数据请求时,元数据处理任务为获取读数据请求对应的元数据。
60.基于第七方面提供的存储设备,在一种可能的实现方式中,io请求对应的元数据用于指示io请求对应的数据的存储位置。
61.基于第七方面提供的存储设备,在一种可能的实现方式中,元数据包括键-值对,键-值对中的键指示与io请求对应的数据的逻辑地址,键-值对中的值用于指示与io请求对应的数据的物理地址。
62.基于第七方面提供的存储设备,在一种可能的实现方式中,元数据包括键-值对,键-值对中的键用于指示与io请求对应的数据的逻辑地址,键-值对中的值用于指示与io请求对应的数据的指纹信息。
63.第八方面,提供了一种计算机可读存储介质,计算机可读存储介质中存储有指令,当其在计算机上运行时,使得计算机执行上述第一方面或第二方面的元数据处理方法。
64.第九方面,提供了一种包含指令的计算机程序产品,当其在计算机上运行时,使得计算机执行上述第一方面或第二方面的元数据处理方法。
65.上述第三方面至第九方面所获得的技术效果与第一方面或第二方面中对应的技术手段获得的技术效果近似,在这里不再赘述。
附图说明
66.图1是本技术实施例提供的一种存储系统的架构示意图;
67.图2是本技术实施例提供的另一种存储系统的架构示意图;
68.图3是本技术实施例提供的一种存储设备中的元数据处理方法流程图;
69.图4是本技术实施例提供的另一种存储设备中的元数据处理方法流程图;
70.图5是本技术实施例提供的另一种存储设备中的元数据处理方法流程图;
71.图6是本技术实施例提供的另一种存储设备中的元数据处理方法流程图;
72.图7是本技术实施例提供的一种元数据处理装置的示意图;
73.图8是本技术实施例提供的另一种元数据处理装置的示意图。
具体实施方式
74.为使本技术的目的、技术方案和优点更加清楚,下面将结合附图对本技术实施方
式作进一步地详细描述。
75.在对本技术实施例进行详细解释说明之前,先对本技术实施例的应用场景进行解释说明。
76.存储系统中索引库的性能对存储系统整体的性能影响很大,索引库用于存储元数据,通常采用一定的数据结构来存储。元数据是描述数据的各种属性的数据,它包括数据的逻辑地址与物理地址之间的映射关系,或者其他描述数据的存储位置,以及描述各个数据之间关系的信息。其中,逻辑地址是对上层应用呈现的地址,物理地址用于指示该数据存储在存储介质的什么位置。在读数据时,往往只能从读数据请求中获取待读取数据的逻辑地址,这就需从索引库获取所述逻辑地址对应的物理地址,从物理地址指示的空间中获取所述数据。写数据时,需将数据的物理地址以及物理地址与逻辑地址的映射关系存储至索引库,以便下次读取该数据时使用。
77.由此可知,存储系统在进行数据访问(数据访问是指读数据或写数据)时,同时会访问索引库。本技术实施例提供的元数据处理方法就应用于上述对索引库进行访问的场景中。
78.下面对本技术实施例涉及的存储系统的架构进行解释说明。如图1所示,本实施例提供的存储系统包括主机集群和存储节点集群。
79.其中,主机集群包括一个或多个主机100(图1中示出了两个主机100,但不限于两个主机100)。主机100是用户侧的一种计算设备,如服务器、台式计算机等。主机100上运行有应用程序(application)101(简称应用)和客户端(client)程序102(简称客户端)。应用101是对用户呈现的各种应用程序的统称。客户端102用于接收由应用101触发的输入输出(input/output,io)请求,并且与存储节点200交互,向存储节点200发送该io请求。客户端102还用于接收来自存储节点的数据,并向应用101转发该数据。客户端102还可以是由位于主机100内部的硬件组件来实现。可以理解的是,当客户端102是软件程序时,客户端102的功能由主机100所包含的处理器运行该程序来实现。主机集群中的任意一个客户端102可以通过网络访问存储节点集群中的任意一个存储节点200。
80.存储节点集群包括一个或多个存储节点200(图1中示出了三个存储节点200,但不限于三个存储节点200),各个存储节点200之间可以通过互联网协议(internet protocol,ip)网络或者其他网络互联。存储节点200是一种存储设备,如服务器或者存储阵列的控制器等。在硬件上,如图1所示,存储节点200至少包括处理器202、内存203、网卡201和硬盘204。
81.其中,处理器202是一个中央处理器(central processing unit,cpu),用于处理来自存储节点200外部的io请求,或者存储节点200内部生成的请求。
82.内存203用于临时存储从主机100接收的数据或内部读取的数据。存储节点200接收主机100发送的多个写数据请求时,可以将这多个写数据请求中的数据暂时保存在内存203中。当内存203中的数据总量达到一定阈值时,将内存203中存储的数据下盘到硬盘204中存储。内存203包括易失性存储器,例如随机访问存储器(random-access memory,ram)。内存203可具有保电功能,保电功能是指系统发生掉电又重新上电时,内存203中存储的数据也不会丢失。通常情况下,具有保电功能的内存被称为非易失性存储器。
83.需要说明的是,内存203可以是存储节点自身的内存。也可以是从共享内存池
(global memory pool)中划分出给存储节点使用的内存。该共享内存池是预先在各个存储节点上创建的,其存储空间由各个存储节点上的内存或其他存储器提供。各个存储节点在使用时可以向该共享内存池申请一部分存储空间作为自己的内存。
84.网卡201用于与主机100通信。具体的,存储节点200可通过网卡201接收来自主机100的请求,或者通过网卡201向主机100发送请求。
85.硬盘204用于存储数据,可以是磁盘或者其他类型的存储介质,例如固态硬盘或者叠瓦式磁记录硬盘等。需要说明的是,图1所示的存储系统中的硬盘可以为存储节点内部的硬盘。可选地,硬盘也以为存储节点外接的其他存储设备上的硬盘。此时,在功能上,存储节点200主要用于对数据进行计算或存储,对数据进行计算主要包括元数据管理、重复数据删除、虚拟化存储空间以及地址转换等。
86.其中,元数据管理可以是指从索引库中读写或更新元数据。比如,将元数据存储至索引库或者从索引库中读取元数据等。重复数据删除是指在存储数据时,如果存储节点中已经保存有与待存储数据相同的数据,则不存储该数据。其中,判断是否有相同的数据,是通过数据的指纹信息来判断的,指纹信息用于唯一标识该数据。指纹信息可以存储在存储节点的某个数据库中。比如,当存储节点上部署有索引库时,该数据库可以为存储节点上的索引库。可选地,该数据库也可以为独立于索引库的其他数据库。
87.虚拟化存储空间是指将硬盘提供的存储空间虚拟化为逻辑单元,从而提供主机能够感知的逻辑地址。地址转换是指将某个逻辑地址转换为物理地址,或者将某个物理地址转换为逻辑地址。
88.另外,存储节点200还可以包括总线(图1中未示出)用于存储节点200内部各组件之间的通信。
89.本实施例提供的另一种存储系统的网络架构可参考图2,如图2所示,在这种网络架构中,应用101和客户端102部署在存储节点200内部,所以应用101可直接通过存储节点200中的客户端102触发io请求(本实施例中的io请求包括写数据请求或读数据请求),由该存储节点200处理,或者发送给其他存储节点200处理。此时,客户端102向存储节点200发送的io请求具体是指客户端102向处理器202发送io请求。对于图2所示的网络架构,如果图2中的硬盘为存储节点200内部的硬盘,则io请求从客户端102到达硬盘204时不需要经过其他网络。如果图2中的硬盘为存储节点200外接的其他存储设备上的硬盘,则io请求从客户端102到达硬盘204时需要经过一跳网络(存储节点和硬盘所在的其他存储设备之间)。而图1所示的网络架构,io请求从客户端102到达硬盘204时至少需要经过一跳网络(主机与存储节点之间的网络)。除此之外,存储节点200所包含的组件及其功能与图1中的存储节点200类似,这里不再赘述。
90.对于图1或图2所示的存储系统,可以在每个存储节点上部署索引库,此时索引库用于存储相应存储节点上存储的数据的元数据。这种部署索引库的场景可以称为分布式部署索引库。在分布式部署索引库的场景中,每个存储节点上的索引库可以部署在该存储节点的内存中,也可以部署在该存储节点的硬盘上。
91.可选地,还可以集中在存储系统中某个存储节点上部署一个索引库,该索引库用于存储整个存储系统中存储的数据的元数据。这种部署索引库的场景可以称为集中式部署索引库。在集中式部署索引库的场景中,该集中部署的索引库可以部署在这个存储节点的
内存中,也可以部署在这个存储节点的硬盘中。
92.此外,考虑到存储系统中的热点数据为经常使用的数据,因此可以将热点数据的元数据单独存储在一个索引库中。将热点数据之外的数据或包括热点数据的元数据存储在另一个索引库中。其中,热点数据是指访问频率大于热度阈值的数据,本技术实施例的访问频率可以通过单位时间内数据的访问次数来确定。如此,本技术实施例提供的索引库便可分为第一索引库和第二索引库。其中,第一索引库中存储的是热点数据的元数据。第二索引库中存储有包括热点数据和非热点数据的元数据,或者第二索引库中存储除热点数据之外非热点数据的元数据。示例性的,第一索引库中的元数据可以通过哈希(hash)表的方式存储。第二索引库中的元数据可以通过树形结构来存储。此时,第一索引库还可称为哈希表索引库,第二索引库还可称为树形结构索引库。
93.在索引库包括第一索引库和第二索引库的情况下,如果需要从索引库中查询元数据,便可先从第一索引库中查询该元数据。如果第一索引库中没有查询到该元数据,则再从第二索引库中查询该元数据。如此,避免了直接从全量的索引库中查询该元数据,从而提高查询该元数据的效率。
94.此外,索引库中可以采集键-值对的方式存储某个数据的元数据中的信息。比如,当io请求对应的元数据用于指示该io请求对应的数据的存储位置时,键-值对中的键指示数据的逻辑地址,键-值对中的值指示数据的物理地址。此时,键-值对用于存储数据的逻辑地址和物理地址之间的映射关系。可选地,键-值对中的键指示数据的逻辑地址,键-值对中的值指示数据的指纹信息。该指纹信息前述已经说明,在此不再赘述。通过指纹信息可以继续查询到该数据的物理地址。
95.上述是以键-值对为例说明索引库中的元数据的存储方式。可选地,索引库中的元数据还可以采用其他方式存储,在此不再一一举例说明。
96.此外,如果存储节点上部署的索引库包括第一索引库和第二索引库,则第一索引库可以存储在该存储节点的内存中,第二索引库存储在该存储节点的硬盘中。可选地,第一索引库和第二索引库可以均存储在存储节点的内存中,或者,均存储在存储节点的硬盘中。本技术实施例并不限定第一索引库和第二索引库的具体存储位置。
97.另外,图1或图2所示的存储系统还包括存储池,存储池用于提供存储空间,该存储空间来源于存储节点200中的硬盘204。
98.硬盘204所提供的存储空间的实际地址并不直接给暴露给存储节点200或主机100。在实际应用中,各个存储节点200中包含的部分或全部硬盘204组成所述存储池,每个硬盘204被划分为若干个块(chunk),来自不同硬盘204或者不同存储节点200的多个块组成一个存储对象,存储对象是存储池的最小分配单位。当存储节点向存储池申请存储空间时,存储池可以提供一个或多个存储对象给存储节点。存储节点进一步将存储对象提供的存储空间虚拟化为逻辑单元(logical unit,lu)提供给主机100使用。每个逻辑单元具有唯一的逻辑单元号(logical unit number,lun)。由于主机100能直接感知到逻辑单元号,本领域技术人员通常直接用lun代指逻辑单元。每个lun具有lun id,用于标识lun。数据位于一个lun内的具体位置可以由起始地址和该数据的长度(length)确定。对于起始地址,本领域技术人员通常称作逻辑块地址(logical block address,lba)。可以理解的是,lun id、lba和length这三个因素标识了一个确定的地址段。主机10生成的读数据请求,通常在该读数据
请求中携带lun id、lba和length,这三个因素可以称为数据的逻辑地址。
99.此外,上述图1或图2所示的存储系统属于分布式部署的场景,在存储系统分布式部署的场景中,存储系统包括多个存储节点。可选地,本技术也可以应用在集中式存储的场景中,例如在单个存储阵列内部或者单个存储节点内部实现本技术的元数据处理方法。存储阵列是至少一个控制器与多个硬盘的组合,该方法可以由所述控制器执行。单个存储节点可以是图1或图2所示的任意一个存储节点200。
100.上述内容用于对本技术实施例涉及的存储系统的网络架构进行解释说明。下面对本技术实施例提供的元数据处理方法进行详细解释说明。
101.图3是本技术实施例提供的一种存储设备中的元数据处理方法流程图。该存储设备可以为图1或图2中任一存储节点。如图3所示,该方法包括如下几个步骤。
102.步骤301:存储设备中的网卡接收io请求,该io请求包括读数据请求或写数据请求。
103.io请求为图1或图2所示的主机中的客户端发送的数据访问请求。对于图1或图2所示的存储系统,客户端根据io请求需要访问的数据的地址以及预设的算法计算获得对应的存储节点,并向对应的存储节点发送针对该io请求。对于图1所示的场景,主机中的客户端将io请求发送至存储节点中的网卡,网卡接收到该io请求时,通过本技术提供的方法对该io请求进行处理。对于图2所示的场景,主机中的客户端将io请求仍然发送至存储节点中的网卡,由网卡统一通过本技术提供的方法对该io请求进行处理。
104.此外,io请求为写数据请求时,该写数据请求包括待存储数据以及待存储数据的逻辑地址。待存储数据的逻辑地址包括lun id,lba和length。存储设备需要执行的操作包括:将写数据请求所对应的数据存储至存储设备、将该数据的逻辑地址与物理地址之间的对应关系存储至索引库。io请求为读数据请求时,该读数据请求包括待读取数据的逻辑地址。存储设备需要执行的操作包括:从索引库获取读数据请求携带的逻辑地址所对应的物理地址,根据获取的物理地址读取数据。
105.当数据的逻辑地址与物理地址之间的对应关系采用键-值(key-value)对的方式时,io请求为写数据请求时,存储设备需向索引库中存储一个键-值对。io请求为读数据请求时,存储设备需从索引库中获取一个键-值对。
106.此外,由于网卡可能短时间内接收到大量的io请求,而网卡处理每个io请求均需要使用一定的时长,因此,网卡接收io请求后,还可以将该io请求添加到任务队列中。按照任务队列中的顺序依次通过下述步骤对各个io请求进行处理。
107.步骤302:网卡执行io请求所对应的元数据处理任务。
108.在本技术实施例中,元数据处理任务是指处理与io请求对应的数据的元数据的查询或修改任务。比如,当io请求为写数据请求时,该io请求所对应的元数据处理任务为将写数据请求对应的元数据存储至索引库,完成对索引库的更新。该写数据请求对应的元数据包括待存储的数据的物理地址或者所述物理地址与逻辑地址的映射关系,或者其他地址索引信息。当io请求是读数据请求时,该io请求所对应的元数据处理任务为查询所述索引库以获取读数据请求对应的元数据。比如,获取该读数据请求携带的逻辑地址所对应的物理地址。
109.由于网卡执行元数据处理任务需要使用一定的内存资源,所述内存资源主要来自
于网卡自己所包含的内存。因此,在一种可能的实现方式中,网卡可以基于可用的内存资源来判断元数据处理任务的执行情况。具体地,网卡确定执行元数据处理任务所需的内存资源,如果网卡可用的内存不足以提供所需的内存资源时,则网卡确定元数据处理任务执行失败。如果网卡可用的内存足以提供所需的内存资源,则由网卡执行元数据处理任务。也即是,在本技术实施例中,元数据处理任务执行失败的情况包括:网卡的内存不足以提供该元数据处理任务所需的内存资源。
110.上述网卡可用的内存资源是指网卡的内存中的剩余空间。此外,网卡的内存资源除了来自网卡自身的内存之外,也可以是从共享内存池中划分给网卡使用的一部分内存,本技术实施例对此不做具体限定。关于共享内存池已经在图1和图2所示的系统架构中进行了介绍,在此不再赘述。
111.此外,由于io请求通常有时延要求,因此,在另一种可能的实现方式中,网卡在接收到io请求后,执行元数据处理任务,并在执行的过程中实时确定执行元数据处理任务已经花费的时长。如果该时长超过时延阈值,则网卡判定元数据处理任务的执行失败。
112.上述时长阈值为设置的时长,该时长阈值可以由管理员基于网卡的性能设置。
113.在上述实现方式中,网卡在接收到io请求后,直接执行元数据处理任务,并统计执行元数据处理任务已经花费的时长,在已经花费的时长超过时长阈值后,则不继续执行元数据处理任务了,而是通过下述步骤303来完成元数据处理任务的执行。
114.需要说明的是,上述基于内存资源或时延来判断元数据处理任务是否执行失败实现方式可以应用在读数据请求中,也可以应用在写数据请求中。此外,网卡也可以通过其他方式来判断元数据处理任务是否执行失败,在此不再一一举例说明。
115.步骤303:在网卡确定元数据处理任务执行失败的情况下,网卡请求存储设备中的cpu执行该元数据处理任务。
116.基于步骤302可知,网卡获取的元数据处理任务的执行结果是网卡在执行元数据处理任务过程中得到的。因此,请求cpu来执行元数据处理任务可以是指请求cpu重新执行该元数据处理任务,也可以是指请求cpu执行网卡未完成的剩下的元数据处理任务。
117.上述网卡请求cpu执行该元数据处理任务的实现方式可以为:网卡向cpu发送任务执行请求。该任务执行请求指示cpu执行该io请求对应的元数据处理任务。cpu接收到该任务执行请求时,便可执行该元数据处理任务。该任务执行请求可以携带该io请求的标识,以便cpu直接基于该io的标识执行该io请求对应的元数据处理任务。此外,该任务执行请求还可以携带用于表示网卡执行该元数据处理任务的执行进度的信息,以便cpu直接基于该io的标识和该元数据处理任务的执行进度,继续执行网卡未完成的剩下的元数据处理任务。
118.需要说明的是,在执行元数据处理任务时,如果通过cpu完成索引库的更新和查询等操作,优点是可以处理比较复杂的索引库,但同时也会带来处理操作在cpu上进行调度的开销,增加了访问的时延。另一种方式是通过高性能的网卡(如单侧远程直接内存访问(one-sided remote direct memory access,one-sided rdma)的处理能力来访问索引库。但由于网卡不能处理过于复杂的索引库,另外在处理效率上也有一定的限制,所以网卡处理索引库往往需要多次网络交互才能完成,对性能也有负面的影响。
119.因此,在本技术实施例中,为了减缓cpu处理数据的压力,网卡在接收到io请求时,并不直接将该io请求转移给cpu,而是由网卡先获取元数据处理任务的执行结果。如果执行
结果为失败,则请求cpu执行该io请求所对应的元数据处理任务。如此,可以避免io请求所对应的元数据处理任务全部由网卡执行、或者全部由cpu执行。因此,存储设备便可自适应地从cpu中卸载部分的元数据处理任务给网卡,不仅可以减轻cpu的数据处理压力,还可以避免由于网卡处理元数据带来的时延过长。
120.图3所示的实施例是网卡在执行元数据处理任务的过程中判断出元数据处理任务是否执行失败。可选地,在本技术实施例中,网卡还可以在执行元数据处理任务前对元数据处理任务的执行结果进行预判。如果预判该元数据处理任务的执行结果为失败,则请求cpu来处理该元数据处理任务。
121.图4所示的实施例用于对这种预判的情况进行解释说明。如图4所示,该存储设备中的元数据处理方法包括如下几个步骤。
122.步骤401:存储设备中的网卡接收多个io请求,该io请求包括读数据请求或写数据请求。
123.步骤401的解释说明可以参考图3实施例中步骤301的解释说明,在此不再赘述。
124.步骤402:网卡确定多个io请求的数量超过设定的数量阈值时,网卡请求存储设备中的cpu处理多个io请求中的至少一个io请求所对应的元数据处理任务。
125.当接收到的多个io请求的数量超过数量阈值时,执行这些io请求对应的元数据处理任务需要处理的数据量比较大,从而导致执行这些io请求对应的元数据处理任务所需的时长也较大,因此,为了避免网卡直接执行这些io请求对应的元数据处理任务的时延较大,网卡可以请求cpu来处理io请求。也即是,网卡直接通过接收到io请求的数量来预判是由自身执行元数据处理任务,还是由cpu来执行元数据处理任务。
126.上述网卡请求cpu执行至少一个io请求所对应的元数据处理任务的实现方式可以为:网卡向cpu发送任务执行请求。该任务执行请求指示cpu执行这至少一个io请求所对应的元数据处理任务。cpu接收到该任务执行请求时,便可执行这至少一个io请求所对应的元数据处理任务。
127.在一种可能的实现方式中,步骤402中网卡可以请求cpu处理这多个io请求中全部的io请求。此时步骤402中的至少一个io请求是步骤401中多个io请求中的所有io请求。
128.在一种可能的实现方式中,步骤402中网卡可以请求cpu处理这多个io请求中的一部分的io请求,网卡自身处理另一部分io请求。此时步骤402中的至少一个io请求是多个io请求的子集。这种实现方式中,网卡执行步骤401中多个io请求中除至少一个io请求之外的其余io请求所对应的元数据处理任务。
129.在网卡请求cpu处理这多个io请求中的一部分的io请求时,网卡可以基于自身当前可用内存来确定自身能够处理的io请求的数量,然后将超出该数量之外的其他io请求作为上述至少一个io请求。关于网卡可用内存可以参考图3所示实施例中的相关解释,在此不再赘述。
130.需要说明的是,图4所示的实施例可以应用于读数据请求中,也可以应用于写数据请求中。此外,图4所示的实施例中的元数据处理任务的解释可以参考图3实施例中相关内容的解释,在此不再赘述。
131.由此可知,在本技术实施例中,可以基于io请求的数量对当前要处理的元数据执行任务的执行结果进行预判,当io请求的数量超过一定数量时,预判网卡无法成功执行该
元数据处理任务,此时则请求cpu来执行元数据处理任务。上述预判的方式不仅提高了元数据处理的灵活性,还可以实现网卡和cpu自适应动态执行元数据处理任务。如此,便可自适应地从cpu中卸载部分的元数据处理任务给网卡,不仅可以减轻cpu的数据处理压力,还可以避免由于网卡处理元数据带来的时延过长,从而提高存储设备读写数据的效率。
132.此外,图4所示的实施例是基于io请求的数量对当前要处理的元数据执行任务的执行结果进行预判。可选地,对于任一io请求,网卡还可以预估执行该io请求对应的元数据处理任务的时长;如果该时长超过时延阈值,则网卡判定元数据处理任务的执行结果为失败。进而请求cpu来执行该元数据处理任务。
133.上述执行元数据处理任务的时长为网卡预先估计的执行该元数据处理任务所需的时长。也即是,网卡在真正执行元数据处理任务之前先预估时长,基于预估的时长来判断由自身来执行元数据处理任务还是由cpu来执行。其中,网卡可以获取该io请求加入的任务队列中从队首到该io请求的长度、以及每个io请求的平均处理时长,根据这两个信息来预估处理该io请求所需的时长。
134.可选地,网卡也可以通过其他方式来预判自身执行元数据处理任务、还是由cpu来执行该元数据处理任务,在此不再一一举例说明。
135.上述图3和图4所示的实施例均可以应用在io请求为写数据请求的场景中,或者应用在io请求为读数据请求的场景中。下面分别以io请求为写数据请求和读数据请求为例再次解释说明本技术实施例提供的元数据处理方法。
136.图5是本技术实施例提供的一种写数据场景中的元数据处理方法流程示意图。如图5所示,该方法包括如下几个步骤。
137.步骤501:客户端通过网卡发送写数据请求给存储节点的网卡,该写数据请求指示存储数据并更新索引库中该数据对应的元数据。
138.步骤502:存储节点的网卡将该写数据请求放入网卡控制的任务队列,网卡按照任务队列中的顺序执行任务队列中的写数据请求。
139.当io请求为写数据请求时,网卡在执行元数据处理任务之前,先通过下述步骤503将写数据请求中的待存储数据存储起来,并通过下述步骤504基于待存储数据的物理地址执行元数据处理任务。其中,待存储的数据的物理地址可以由客户端预先从存储节点中获取,本技术实施例并不限定客户端如何确定待存储数据的物理地址。
140.步骤503:网卡写入待存储数据。
141.在本技术实施例中,网卡可以通过写前日志(write-ahead logging,wal)的方式写入待存储数据。
142.写前日志是一种用于保证数据完整性的技术,简单来说就是,在真正执行写数据请求之前,先将执行写数据操作这件事记录下来,所述记录就是日志,并将数据缓存在内存。后续如果有对数据的修改,所有的修改记录也保存在所述日志中。先将日志持久化存储至硬盘中,日志保存成功之后,再执行将内存中的数据存储到硬盘的操作。在存储的过程,无论在哪一步操作中出现错误,都可以根据硬盘中保存的日志回放一遍,得到正确的结果。在实际应用中,由于写数据请求所携带的待存储数据的数据量通常比较大,操作繁琐,并且写数据不一定是顺序写,如果每一次操作都要等待结果写入硬盘才能执行下一次操作,效率很低。而写前日志的方式,由于日志的数据量很小,并且是顺序写,因此可以提高写效率。
通常情况下,日志包括但不限于:所述待存储数据(日志所包含的待存储数据与前面的描述的待存储数据的格式不同),接收所述待存储数据的时间,对应的操作类型(例如是写指令还是读指令),所述待存储数据的访问地址等。
143.按照写前日志的方式执行写数据请求,先写日志,再写数据,存储设备中内存中存储的数据可以累积到一定程度再一次性下刷到硬盘,由此可以减少向存储节点的硬盘中写入数据的次数,从而节省网络资源。另外,由于在数据存储至硬盘之前日志已经持久化存储在硬盘中了,所以即使存储数据的过程中发生故障,也可以通过回放日志来恢复数据。
144.需要说明的是,上述wal方式仅仅是网卡写入待存储数据的一种可能的实现方式,本技术实施例并不限定网卡写入待存储数据的实现方式。
145.此外,待存储的数据可以存储在前述的全局内存池并通过非易失介质持久化。待存储数据的元数据包括的物理地址和逻辑地址之间的映射关系可以以键-值对方式存储。此时键-值对中的值中编码的内容可以为全局内存池的物理地址,使得后续网卡处理读数据请求时能够绕过cpu直接读取到数据物理地址,提高了读取数据的效率。
146.步骤504:网卡对更新索引库所需的内存资源进行判断。如果网卡可用的内存能够满足更新过程所需的内存资源,则网卡执行元数据处理任务。
147.上述网卡执行元数据处理任务是指:网卡将该数据的元数据存储至索引库,以完成对索引库的更新。此时,客户端发送的写数据请求处理成功。
148.在索引库包括第一索引库和第二索引库的情况下,网卡执行元数据处理任务具体包括以下三种实现方式:
149.第一种可能的实现方式,如果第一索引库中存储的热点数据的元数据,第二索引库中存储的是热点数据之外非热点数据的元数据,则网卡执行元数据处理任务是指网卡仅更新第一索引库。后续由cpu基于数据淘汰算法确定该数据为非热点数据后,便可将该数据的元数据迁移至第二索引库,并删除第一索引库中该元数据。
150.第二种可能的实现方式,如果第一索引库中存储的热点数据的元数据,第二索引库中存储的是热点数据和非热点数据的元数据,则网卡执行元数据处理任务可以是指仅更新第一索引库,由cpu后台完成将该元数据同时存储至第二索引库,以完成第二索引库的更新,元数据存储至第二索引库之后,第一索引库中的元数据也不会删除。
151.第三种可能的实现方式,如果第一索引库中存储的热点数据的元数据,第二索引库中存储的是热点数据和非热点数据的元数据,则网卡执行元数据处理任务也可以是指网卡同时更新第一索引库和第二索引库。
152.另外,上述网卡判断可用内存是否足以提供执行元数据处理任务所需的内存资源的实现方式可以为:网卡确定需要向索引库中存储的元数据,然后确定是否需要向索引库重新分配内存才能存储该元数据。如果需要向索引库中重新分配内存才能存储该元数据,则确定网卡的内存不足以提供所需的内存资源。如果不需要向索引库重新分配内存,网卡也能向索引库中存储该元数据,则确定网卡的内存足以提供所需的内存资源。
153.步骤505:如果更新索引库过程比较复杂导致网卡可用的内存不能够满足更新过程所需的内存资源,则网卡将该元数据处理任务交给cpu处理,由cpu完成索引库中元数据的更新。同时网卡将任务队列中关于该数据的任务标识为正在被cpu处理,之后到达的关于同一个数据的请求在任务队列中排队,暂不被处理,直到cpu处理完成,后到达的关于同一
个数据的更新请求才开始处理。但不被cpu处理的其他数据的io请求仍然由网卡通过上述步骤501至步骤504处理io请求,不必等待。
154.在步骤505中,由cpu完成索引库中元数据的更新可以是指:由cpu来执行整个元数据处理任务,也即是,由cpu来完成将该待存储数据的元数据存储至索引库,以完成索引库的更新。
155.此时,在索引库包括第一索引库和第二索引库的情况下,cpu执行元数据处理任务的实现方式可以参考步骤505中网卡执行元数据处理任务的实现方式,在此不再赘述。
156.可选地,步骤505中由cpu完成索引库中元数据的更新可以是指:由cpu完成网卡执行元数据处理任务过程中剩下的任务。在此不再详细说明。
157.步骤506:cpu处理复杂的索引库更新操作,完成对索引库的更新。此时,客户端发送的写数据请求处理成功。此外,网卡还将任务队列中关于数据的任务标记为已被cpu处理完成。
158.综上所述,在本技术实施例中,为了减缓cpu处理数据的压力,存储节点的网卡在接收到写数据请求时,并不直接将该写数据请求转移给cpu,而是由网卡先预判该写数据请求所对应的元数据处理任务的执行结果。如果执行结果为失败,则请求cpu执行该写请求所对应的元数据处理任务。如此,可以避免写请求所对应的元数据处理任务全部由网卡执行、或者全部由cpu执行。由此可知,本技术实施例提供了一种网卡和cpu自适应动态执行元数据处理任务的方法。如此,便可自适应地从cpu中卸载部分的元数据处理任务给网卡,不仅可以减轻cpu的数据处理压力,还可以避免由于网卡处理元数据带来的时延过长。
159.需要说明的是,图5所示的实施例是以网卡基于内存资源来确定写数据请求所对应的元数据处理任务的执行结果为例进行说明。可选地,网卡还可以基于其他实现方式确定该元数据处理任务的执行结果,具体实现方式参考图3所示的实施例,在此不再详细阐述。
160.图6是本技术实施例提供的一种读数据场景中的元数据处理方法流程示意图。如图6所示,该方法包括如下几个步骤。
161.步骤601:客户端通过网卡发送读数据请求给存储节点的网卡,该读数据请求指示读取某个逻辑地址上的数据或指示读取大范围逻辑地址上的数据。
162.当io请求为读数据请求时,除了图3所示的实施例步骤302中通过内存资源或时延来判断元数据处理任务的执行结果是否失败,还可以基于该读数据请求携带的逻辑地址的地址长度来确定元数据处理任务的执行结果。比如,当该读数据请求携带的逻辑地址的地址长度超过长度阈值时,为了避免网卡需要多次交互才能获取待读取数据,此时读数据请求可以由cpu处理。也即是,当该读数据请求携带的逻辑地址的地址长度超过长度阈值时,网卡确定读数据请求所对应的据处理任务执行失败。如果该读数据请求携带的逻辑地址的地址长度低于长度阈值时,则可以由网卡来执行元数据处理任务,然后网卡再通过实际执行元数据处理的情况继续判断是否请求cpu执行元数据处理任务。
163.下述步骤602和步骤603用于上述内容进行解释说明。
164.步骤602:如果读数据请求携带的逻辑地址的地址长度低于长度阈值时,则由网卡执行元数据处理任务。
165.在索引库包括前述的第一索引库和第二索引库的情况下,基于前述对第一索引库
和第二索引库的解释可知,第二索引库中存储的元数据的数据量大于第一索引库中元数据的数据量,因此从第二索引库中获取元数据所消耗的资源量大于从第一索引库中获取元数据所消耗的资源量。所以,由网卡执行元数据处理任务的实现方式可以为:网卡从第一索引库中获取读数据请求携带的逻辑地址对应的物理地址;如果没有在第一索引库中查询到读数据请求携带的逻辑地址对应的物理地址,则确定执行元数据处理任务失败。此时通过步骤603请求cpu执行元数据处理任务。
166.上述长度阈值可以为相邻两个逻辑地址之间的差值,也可以为指定长度,本技术实施例对此不做限定。
167.比如,当读数据请求指示读取某个逻辑地址区上的数据时,可以由网卡先在第一索引库中执行该读数据请求所对应的元数据处理任务。如果该元数据处理任务执行失败,则通过下述步骤603请求cpu在第二索引库中执行该元数据处理任务。
168.步骤603:网卡在接收到读数据请求时,如果读数据请求携带的逻辑地址的地址长度超过长度阈值时,则确定元数据处理任务的执行失败。这种情况下,网卡请求cpu执行该元数据处理任务。或者,在上述步骤602中网卡没有在第一索引库中成功执行该元数据处理任务,则网卡同样请求cpu来执行该元数据处理任务。
169.也即是,在步骤603中,有两种场景需要cpu来执行元数据处理任务。第一种场景为:读数据请求携带的逻辑地址的地址长度低于长度阈值,但是网卡没有在第一索引库中查询到待读取数据的元数据。第二种场景为:读数据请求携带的逻辑地址的地址长度超过长度阈值。
170.在上述第一种场景中,由于网卡已经在第一索引库中查询过该元数据,且查询结果为没有查询到,因此,cpu执行该元数据处理任务是指:cpu从第二索引库中获取待读取数据的元数据。
171.在上述第二种场景中,如果第一索引库中存储的热点数据的元数据,第二索引库中存储的是热点数据之外其他数据的元数据,则由cpu执行该元数据处理任务可以是指:cpu从第一索引库和第二索引库中获取待读取数据的元数据。
172.此外,在上述第二种场景中,如果第一索引库中存储的热点数据的元数据,第二索引库中存储的是包括热点数据和非热点数据的元数据,则cpu执行该元数据处理任务可以是指:cpu从第二索引库中获取待读取数据的元数据。这样做的技术效果是:能够避免cpu重复从第一索引库中查询该元数据。
173.步骤604:cpu执行元数据处理任务,以实现在索引库上完成查询工作,客户端发送的读数据请求处理成功。
174.步骤604中,cpu可以通过步骤603中所示的不同场景分别进行索引库的查询工作。
175.步骤605:如果cpu在索引库上查询不到该数据请求携带的逻辑地址对应的物理地址,继续查询过滤器,如果过滤器指示该逻辑地址不在性能更低的存储层,返回数据读取失败消息,否则继续在低性能存储层中查询该逻辑地址所对应的数据。
176.为了进一步提高读取数据的效率,存储系统可以将部分很少被访问到的数据存储到性能更低的存储层(tier)。其中,性能更低的存储层可以为图1或图2所示的硬盘中的部分或全部存储空间。索引库中并没有存储性能更低的存储层中的数据的元数据。而是针对该性能更低的存储层配置一个过滤器(filter),该过滤器的功能用于查询某个数据是否存
储在该性能更低的存储层中。
177.因此在步骤605中,如果cpu在索引库中也没有查询到读数据请求携带的逻辑地址对应的物理地址,则通过过滤器继续查询。如果通过过滤器查询到待读取数据在性能更低的存储层中,则从该性能更低的存储层中读取数据。如果通过过滤器也无法查询到待读取数据,则cpu向客户端返回数据读取失败消息。
178.此外,需要说明的是,上述图6所示的实施例中,如果该读数据请求携带的逻辑地址的地址长度低于长度阈值时,则可以由网卡基于第一索引库执行元数据处理任务,然后由网卡基于第一索引库中的执行结果来判断是否请求cpu在第二索引库中执行元数据处理任务。可选地,网卡也可以不考虑读数据请求携带的逻辑地址的地址长度,直接由网卡先基于第一索引库执行元数据处理任务,然后网卡根据元数据处理任务的执行结果来判断是否请求cpu在第二索引库中执行元数据处理任务。在此不再详细说明。
179.图7是本技术实施例提供的一种元数据处理装置,该装置部署在存储系统的网卡中。如图7所示,该装置700包括:
180.接收模块701,用于接收io请求,该io请求包括读数据请求或写数据请求。具体实现过程参考图3实施例中的步骤301。
181.执行模块702,用于执行io请求所对应的元数据处理任务。具体实现过程参考图3实施例中的步骤302。
182.请求模块703,用于在确定元数据处理任务执行失败的情况下,请求存储设备中的中央处理器cpu执行元数据处理任务。具体实现过程参考图3实施例中的步骤303。
183.需要说明的是,图1或图2所示的网卡上可包括用于通信的通信接口和具有处理功能的组件比如处理器(图1或图2中并未示出)。此时,图7中的接收模块701和请求模块703可以由图1或图2中的网卡上的通信接口来实现。图7中的执行模块702可以由图1或图2中的网卡上具有处理功能的组件来实现。可选地,图7所示的模块也可以均由网卡上具有处理功能的组件来实现,本技术实施例对此不做具体限定。
184.可选地,网卡包含内存,元数据处理任务执行失败的情况包括:网卡的内存不足以提供元数据处理任务所需的内存资源。
185.可选地,当io请求是读数据请求时,元数据处理任务执行失败的情况包括:读数据请求携带的逻辑地址的地址长度超过长度阈值。
186.可选地,当io请求是读数据请求时,存储设备包括第一索引库和第二索引库,第一索引库存储的元数据的数据量小于第二索引库存储的元数据的数据量,元数据处理任务执行失败的情况包括:网卡在第一索引库中未获取到读数据请求对应的元数据;网卡请求存储设备中的cpu执行元数据处理任务包括:网卡指示cpu从第二索引库获取读数据请求对应的元数据。
187.可选地,第一索引库包括热点数据的元数据,第二索引库包括非热点数据的元数据。
188.可选地,当io请求是写数据请求时,元数据处理任务为存储写数据请求对应的元数据。
189.可选地,当io请求是读数据请求时,元数据处理任务为获取读数据请求对应的元数据。
190.可选地,该io请求对应的元数据用于指示该io请求对应的数据的存储位置。
191.可选地,元数据包括键-值对,键-值对中的键指示与io请求对应的数据的逻辑地址,键-值对中的值指示与io请求对应的数据的物理地址。
192.可选地,元数据包括键-值对,键-值对中的键指示与io请求对应的数据的逻辑地址,键-值对中的值指示与io请求对应的数据的指纹信息。
193.可选地,该存储设备是存储阵列,或者是分布式存储系统中的一个存储节点。
194.在本技术实施例中,为了减缓cpu处理数据的压力,网卡在接收到io请求时,并不直接将该io请求转移给cpu,而是由网卡先执行该元数据处理任务。如果执行失败,则请求cpu执行该io请求所对应的元数据处理任务。如此,可以避免io请求所对应的元数据处理任务全部由网卡执行、或者全部由cpu执行。因此,存储设备便可自适应地从cpu中卸载部分的元数据处理任务给网卡,不仅可以减轻cpu的数据处理压力,还可以避免由于网卡处理元数据带来的时延过长。
195.需要说明的是:上述实施例提供的元数据处理装置在处理元数据时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将设备的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的元数据处理装置与元数据处理方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
196.图8是本技术实施例提供的一种元数据处理装置,该装置部署在存储系统的网卡中。如图8所示,该装置800包括:
197.接收模块801,用于接收多个输入输出io请求,io请求包括读数据请求或写数据请求。具体实现方式可以参考图4实施例中的步骤401。
198.请求模块802,用于确定io请求的数量超过设定的数量阈值时,请求存储设备中的中央处理器处理多个io请求中的至少一个io请求所对应的元数据处理任务。具体实现方式可以参考图4实施例中的步骤402。
199.需要说明的是,图1或图2所示的网卡上可包括用于通信接口和具有处理功能的组件比如处理器(图1或图2中并未示出)。此时,图8中的接收模块801和请求模块80可以由图1或图2中的网卡上的通信接口来实现。可选地,也可以由网卡上的其他具有处理功能的组件来实现。本技术实施例对此不做具体限定。
200.可选地,至少一个io请求是多个io请求中的所有io请求。
201.可选地,至少一个io请求是多个io请求的子集,该装置还包括:
202.执行模块,用于执行多个io请求中除至少一个io请求之外的其余io请求所对应的元数据处理任务。
203.可选地,该io请求对应的元数据用于指示该io请求对应的数据的存储位置。
204.可选地,元数据包括键-值对,键-值对中的键指示与io请求对应的数据的逻辑地址,键-值对中的值指示与io请求对应的数据的物理地址。
205.可选地,元数据包括键-值对,键-值对中的键指示与io请求对应的数据的逻辑地址,键-值对中的值指示与io请求对应的数据的指纹信息。
206.可选地,该存储设备是存储阵列,或者是分布式存储系统中的一个存储节点。
207.在本技术实施例中,可以基于io请求的数量对当前要处理的元数据执行任务的执
行结果进行预判,当io请求的数量超过一定数量时,预判网卡无法成功执行该元数据处理任务,此时则可以请求cpu来执行元数据处理任务。不仅提高了元数据处理的灵活性。还可以实现网卡和cpu自适应动态执行元数据处理任务。如此,便可自适应地从cpu中卸载部分的元数据处理任务给网卡,不仅可以减轻cpu的数据处理压力,还可以避免由于网卡处理元数据带来的时延过长,从而提高存储设备读写数据的效率。
208.需要说明的是:上述实施例提供的元数据处理装置在处理元数据时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将设备的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的元数据处理装置与元数据处理方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
209.在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意结合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机指令时,全部或部分地产生按照本技术实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如:同轴电缆、光纤、数据用户线(digital subscriber line,dsl))或无线(例如:红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如:软盘、硬盘、磁带)、光介质(例如:数字通用光盘(digital versatile disc,dvd))、或者半导体介质(例如:固态硬盘(solid state disk,ssd))等。
210.本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
211.以上所述为本技术提供的实施例,并不用以限制本技术,凡在本技术的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本技术的保护范围之内。
再多了解一些

本文用于企业家、创业者技术爱好者查询,结果仅供参考。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

相关文献