一种基于检查点的应用转储和恢复方法、设备及存储介质与流程

未命名 08-22 阅读:149 评论:0


1.本技术涉及云计算技术领域,尤其涉及一种基于检查点的应用转储和恢复方法、设备及存储介质。


背景技术:

2.公共云面向多租户环境,对客户的各种突发性需求提供弹性供给的计算能力。通常许多hpc(high performance computing,高性能计算)应用都属于重载型应用,对计算资源的负载压力很大,并且很多应用需要多节点并行计算,因此,在云环境下,支持hpc应用弹性使用计算资源,是降低客户的总体拥有成本的一种重要手段。
3.目前,云环境中计算节点的结构不断多样化,在计算节点上支持应用运行的底层逻辑也不断多样化,这导致按照传统的检查点和恢复(checkpoint and restart,cr)方案将hpc应用的内存数据简单地进行拷贝后,经常出现hpc应用无法恢复的问题,从而无法支持hpc应用弹性使用计算资源。


技术实现要素:

4.本技术的多个方面提供一种基于检查点的应用转储和恢复方法、设备及存储介质,用以更好地支持应用的转储和恢复。
5.本技术实施例提供一种基于检查点的应用转储方法,适用于计算节点,所述计算节点上装配有目标特定设备,所述方法包括:
6.响应于针对目标应用的检查点创建指令,获取所述目标特定设备在所述目标应用下的状态描述信息,所述状态描述信息用于支持将所述目标特定设备在所述目标应用下的设备状态恢复至当前检查点;
7.将所述状态描述信息添加至为所述目标应用构建的检查点文件中;
8.对所述检查点文件进行转储,以在将所述目标应用恢复至所述当前检查点时基于所述状态描述信息对所述目标特定设备的设备状态进行恢复。
9.本技术实施例还提供一种基于检查点的应用恢复方法,适用于计算节点,所述计算节点上装配有目标特定设备,所述方法包括:
10.响应于将目标应用恢复至指定检查点的恢复指令,获取所述目标应用在所述指定检查点对应的检查点文件;
11.从所述检查点文件中读取所述目标特定设备在所述目标应用下的状态描述信息;
12.根据所述状态描述信息,将所述目标特定设备在所述目标应用下的设备状态恢复至所述指定检查点,以将所述目标应用恢复至所述指定检查点。
13.本技术实施例还提供一种计算节点,包括存储器、处理器和通信组件;
14.所述存储器用于存储一条或多条计算机指令;
15.所述处理器与所述存储器和所述通信组件耦合,用于执行所述一条或多条计算机指令,以用于执行前述的基于检查点的应用转储方法或前述的基于检查点的应用恢复方
法。
16.本技术实施例还一种存储计算机指令的计算机可读存储介质,当所述计算机指令被一个或多个处理器执行时,致使所述一个或多个处理器执行前述的基于检查点的应用转储方法或前述的基于检查点的应用恢复方法。
17.在本技术实施例中,在基于检查点对目标应用进行转储的过程中,开拓性地提出了为计算节点上装配的目标特定设备整合出在目标应用下的状态描述信息,并将该状态描述信息添加到为目标应用构建的检查点文件中,这样,检查点文件中除了包含传统的应用恢复所需内容外,还增加了用于支持将目标特定设备在目标应用下的设备状态恢复至指定检查点的状态描述信息。在此基础上,在基于检查点对目标应用进行恢复的过程中,可从检查点文件中读取到该状态描述信息,并基于该状态描述信息将目标特定设备在目标应用下的设备状态恢复至指定检查点,这可为目标应用提供正确的设备状态,从而保证目标应用的正常恢复。因此,本技术实施例中,通过对转储过程和恢复过程的改造,可保证目标应用在使用到有状态的特定设备的情况下,依然可以正常恢复。
附图说明
18.此处所说明的附图用来提供对本技术的进一步理解,构成本技术的一部分,本技术的示意性实施例及其说明用于解释本技术,并不构成对本技术的不当限定。在附图中:
19.图1为本技术一示例性实施例提供的一种基于检查点的应用转储方法的流程示意图;
20.图2为本技术一示例性实施例提供的一种基于检查点的应用转储方法的逻辑示意图;
21.图3为本技术一示例性实施例提供的一种基于检查点的应用恢复方法的流程示意图;
22.图4为本技术一示例性实施例提供的一种基于检查点的应用恢复方法的逻辑示意图;
23.图5为本技术另一示例性实施例提供的一种计算节点的结构示意图。
具体实施方式
24.为使本技术的目的、技术方案和优点更加清楚,下面将结合本技术具体实施例及相应的附图对本技术技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本技术一部分实施例,而不是全部的实施例。基于本技术中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本技术保护的范围。
25.目前,经常出现hpc应用无法恢复的问题,从而无法支持hpc应用弹性使用计算资源。为此,本技术的一些实施例中:在基于检查点对目标应用进行转储的过程中,开拓性地提出了为计算节点上装配的目标特定设备整合出在目标应用下的状态描述信息,并将该状态描述信息添加到为目标应用构建的检查点文件中,这样,检查点文件中除了包含传统的应用恢复所需内容外,还增加了用于支持将目标特定设备在目标应用下的设备状态恢复至指定检查点的状态描述信息。在此基础上,在基于检查点对目标应用进行恢复的过程中,可从检查点文件中读取到该状态描述信息,并基于该状态描述信息将目标特定设备在目标应
用下的设备状态恢复至指定检查点,这可为目标应用提供正确的设备状态,从而保证目标应用的正常恢复。因此,本技术实施例中,通过对转储过程和恢复过程的改造,可保证目标应用在使用到有状态的特定设备的情况下,依然可以正常恢复。
26.以下结合附图,详细说明本技术各实施例提供的技术方案。
27.图1为本技术一示例性实施例提供的一种基于检查点的应用转储方法的流程示意图,图2为本技术一示例性实施例提供的一种基于检查点的应用转储方法的逻辑示意图。该方法可由数据处理装置执行,该数据处理装置可实现为软件、硬件或软件与硬件的结合,该数据处理装置可集成在计算节点中。参考图1,该方法可包括:
28.步骤100、响应于针对目标应用的检查点创建指令,获取目标特定设备在目标应用下的状态描述信息,状态描述信息用于支持将目标特定设备在目标应用下的设备状态恢复至当前检查点;
29.步骤101、将状态描述信息添加至为目标应用构建的检查点文件中;
30.步骤102、对检查点文件进行转储,以在将目标应用恢复至当前检查点时基于状态描述信息对目标特定设备的设备状态进行恢复。
31.本实施例提供的应用转储方法,可适用于需要对应用进行转储-恢复的场景中。例如,在云环境中支持应用弹性使用资源的场景;又例如,基于检查点的自动容错场景,等。本实施例对应用场景不做限定。
32.检查点和恢复技术(checkpoint and restart,cr)是一种后向恢复技术。通过在应用正常运行过程中设置检查点,保存对应的检查点文件,可支持将应用回滚到检查点,并从检查点开始重新执行应用,而不再需要从源头执行应用。其中,检查点可理解为应用在某一时刻的快照。目前,检查点和恢复技术的原理是将应用的内存数据构建为检查点文件,并对检查点文件进行持久化存储,以在需要的时候基于检查点文件在原计算节点或者新的计算节点上为应用恢复内存数据,从而将应用恢复至检查点。其中,内存数据中存储的基本是进程本身的状态及操作系统环境等原本即维护在内存中的信息,在此不做过多举例。
33.但是,发明人在研究过程中发现,按照传统的检查点和恢复(checkpoint and restart,cr)方案将应用的内存数据简单地进行拷贝后,经常出现应用无法恢复的问题,为此,本实施例提供出一种改进方案,以改善应用无法恢复的问题。
34.参考图2,本实施例中,计算节点上可装配特定设备,计算节点上的特定设备的数量可以是一个或多个,特定设备的类型可以是一种或多种,本实施例对此不做限定。计算节点上承载的应用可使用这些特定设备。其中,本实施例中的计算节点可以是云服务器或者服务器集群等,本实施例对此不做限定。
35.本实施例中,特定设备通常为有状态设备,可包括但不限于有状态的io设备或有状态的异构加速设备等。其中,有状态(stateful)设备是指以设备状态作为行为指导的一类设备,也即是,设备状态会影响该类设备的行为。若应用需要调用目标特定设备,则计算节点需要为目标特定设备计算出在目标进程下设备状态,并返回给目标应用,以供目标应用基于计算出的该设备状态执行对目标特定设备的操作,因此,使目标应用获取到目标特定设备的正确设备状态是保证目标应用正常运行的必要条件。但是,上述针对设备状态的计算过程,对于目标应用的内存数据来说是透明的且无感的,也即是,特定设备中的状态值并不包含在内存数据中,这导致,按照传统的检查点和恢复方案对内存数据进行拷贝并无
法实现对设备状态的转储。可以理解的是,正是由于设备状态无法被正确地转储,导致传统的检查点和恢复方案下经常出现应用无法恢复的问题。
36.为此,本实施例中,开拓性地提出了为计算节点上装配的特定设备整合出其在目标应用下的状态描述信息,以支持对设备状态的转储和恢复。
37.为便于描述,本实施例中,将以计算节点上装配的目标特定设备作为示例进行技术方案的说明,应当理解的是,目标特定设备可以是计算节点上装配的任意一个被目标应用所使用到的特定设备。而从目标应用的视角来说,其在计算节点上所使用到的特定设备则可以是多个,对于目标应用在计算节点上所使用到的除目标特定设备之外的其它特定设备,也可采用本实施例提供的技术方案进行处置。
38.参考图1,在步骤100中,可响应于针对目标应用的检查点创建指令,获取目标特定设备在目标应用下的状态描述信息。
39.本实施例中,状态描述信息用于支持将目标特定设备在目标应用下的设备状态恢复至当前检查点。也即是,在后续的应用恢复过程中,可基于状态描述信息将目标特定设备在目标应用下的设备状态,恢复至当前检查点时面向目标应用所应呈现的设备状态。为此,本实施例中的状态描述信息可包含为特定设备计算设备状态过程中所需用到的各项信息。
40.正如前文提及的,计算节点需要为目标特定设备计算出在目标进程下设备状态,并返回给目标应用,以供目标应用基于计算出的该设备状态执行对目标特定设备的操作,因此,特定设备中记录的状态值和最终返回给目标应用的设备状态可能是不一致的。其中,特定设备中记录的状态值和最终返回给目标应用的设备状态可能是不一致是一种比较常规的现象,导致这种现象的原因有很多。例如,某个特定设备的当前设备状态需要参考其上一次的设备状态(可称为上下文信息)才能确认,则在确定本次当前设备状态的过程中,除了要从该特定设备中读取状态值之外,还需要结合其上一次的设备状态,才能计算出当前设备状态并返回给应用。显然,返回给应用的当前设备状态与从该特定设备中读取的状态值并不一致。
41.为此,本实施例提出,在状态描述信息中除了包含原本记录在特定设备中的状态值之外,还包含用于进行设备状态计算过程中所需使用到的其它信息,以支持在恢复过程中正确恢复设备状态。
42.应当理解的是,对于不同类型的特定设备,状态描述信息中所包含的信息项可能不完全相同,这与特定设备的内部工作原理等相关。本实施例中,对状态描述信息中包含的信息项不做限定。几种示例性的信息项可以是特定设备中设备寄存器的标识、设备寄存器的属性、设备寄存器的状态值、设备内存的状态值、设备驱动软件的状态值、用于支持状态转换的上下文信息和/或用于支持状态映射的映射关系中等。其中,设备寄存器的属性可包括但不限只读、只写、需模拟或需映射等。设备寄存器的状态值是指设备寄存器中记录的状态数据,这些状态数据可作为计算特定设备的设备状态的依据。值得说明的是,本实施例中,可按需设定状态描述信息中包含的信息项,而并不限于此。可知,本实施例中的状态描述信息中不仅包含了目标特定设备中记录的各种状态值,还包含了上下文信息及映射关系等辅助信息,以支持对设备状态的正确恢复。
43.本实施例中,可采用多种实现方式来获取目标特定设备在目标应用下的状态描述信息,在一种可选的实现方式中:可确定目标特定设备对应的目标设备类型;调用目标设备
类型所适配的数据采集接口,采集目标特定设备在目标应用下的状态描述信息。其中,不同设备类型适配不同的数据采集接口,数据采集接口中定义有其支持的设备类型下所需采集的信息项及采集逻辑。
44.在该实现方式中,考虑到为不同类型的特定设备计算设备状态时所需的信息项可能不完全相同,而不同类型的特定设备对相关信息项的存储位置及存储方式等也可能存在差别。为此,在该实现方式中,可预先开发多种数据采集接口,不同设备类型可适配不同的数据采集接口。并且,在数据采集接口中可预先定义好其所支持的设备类型下所需采集的信息项和采集逻辑。其中,数据采集接口中信息项和采集逻辑可参考特定设备的产品手册、操作系统中与特定设备相关的其他处理逻辑等进行定义,在此不做具体限定。基于此,在该实现方式中,可通过调用合适的数据采集接口,全面且准确地获取到目标特定设备在目标应用下的状态描述信息。
45.当然,本实施例中还可采用其它实现方式来获取目标特定设备在目标应用下的状态描述信息。这里的主要构思是开拓性地提出了收集和整合用于支持将目标特定设备在目标应用下的设备状态恢复至当前检查点的各种信息项,而对于收集和整合所采用的实现手段则可以是灵活多样的,本实施例对此不做限定。
46.参考图1,在步骤101中,可将步骤100中获取到的状态描述信息添加至为目标应用构建的检查点文件中。
47.其中,检查点文件可以是按照传统的检查点和恢复技术构建而成的,本实施例对传统的检查点文件中包含的内容不做限定,也不做过多说明,关于这部分可参考现有的关于检查点文件的相关资料。这样,在步骤101中可理解为在传统检查点文件中添加了本实施例开拓性提出的状态描述信息。
48.应当理解的是,在步骤100和101中,仅是以目标特定设备为例呈现了获取状态描述信息并添加至检查点文件的步骤逻辑,实际应用中,计算节点上其它特定设备在目标应用下的状态描述信息也会被获取并添加至检查点文件中。这样,从计算节点的视角来看,其上为目标应用所生成的检查点文件中将包含传统检查点文件内容以及目标应用在当前检查点对应的时刻之前所使用到的各个特定设备各自在目标应用下的状态描述信息。
49.在此基础上,参考图1,在步骤102中,可对检查点文件进行转储,以在将目标应用恢复至当前检查点时基于状态描述信息对目标特定设备的设备状态进行恢复。
50.实际应用中,可将步骤101中为目标应用在当前检查点下所生成的检查点文件转储至持久化存储资源中。这里,并不限定持久化存储资源的类型,可以是云盘或云数据库等。
51.至此,完成了对本次检查点创建指令的响应。本实施例中,后续还可继续在计算节点上发起针对目标应用的检查点创建指令,以为目标应用创建更多检查点,而相应的检查点文件也均可实现持久化存储。这样,在后续对目标应用进程恢复时,可按需指定期望恢复的检查点,并以指定检查点对应的检查点文件作为恢复的基础。
52.可以理解的是,由于本实施例中的检查点文件中包含了前述的状态描述信息,因此,基于检查点文件进行应用恢复时,除了能获得传统的恢复成果之外,还可实现对特定设备在目标应用下的设备状态进行恢复,以保证目标应用在恢复后的正常运行。
53.本实施例中,对于hpc应用等需要多个进程并行且多个进程可能分布在不同计算
节点上的重载型应用,可在对目标应用进程转储的过程中,通过设定超时时间,来避免承载目标应用的多个计算节点中出现计算节点过早退出的问题。另外,若在计算目标特定设备在目标应用下的设备状态过程中需要使用它其它计算节点上的相关数据,这些数据也将作为状态描述信息中的信息项而被携带在检查点文件中。这也进一步保证了在对这类应用进行恢复的过程中,可实现多个计算节点上设备状态的一致性,避免出现错误。基于此,在实际应用中,可支持将带状态的hpc负载(也即是涉及到设备状态的hpc应用)进行转存储,从而可实现无障碍的hpc应用迁移,进而更好地支持集群扩缩容或者让后提交优先级更高的多节点并行作业能提前执行,达到提高资源利用率的目的。
54.综上,本实施例中,在基于检查点对目标应用进行转储的过程中,开拓性地提出了为计算节点上装配的目标特定设备整合出在目标应用下的状态描述信息,并将该状态描述信息添加到为目标应用构建的检查点文件中,这样,检查点文件中除了包含传统的应用恢复所需内容外,还增加了用于支持将目标特定设备在目标应用下的设备状态恢复至指定检查点的状态描述信息。在此基础上,在基于检查点对目标应用进行恢复的过程中,可从检查点文件中读取到该状态描述信息,并基于该状态描述信息将目标特定设备在目标应用下的设备状态恢复至指定检查点,这可为目标应用提供正确的设备状态,从而保证目标应用的正常恢复。因此,本技术实施例中,通过对转储过程和恢复过程的改造,可保证目标应用在使用到有状态的特定设备的情况下,依然可以正常恢复。
55.在上述或下述实施例中,可采用多种实现方式来支持在步骤100中获取目标特定设备在目标应用下的状态描述信息的操作。
56.在一种优选的实现方案中:在当前检查点对应的时刻之前,若监听到目标应用中的目标进程发起针对目标特定设备的状态访问操作,则获取状态访问操作对应的状态描述数据,状态访问操作对应的状态描述数据用于计算需返回目标进程的设备状态;将目标特定设备在目标进程下的状态描述数据,更新为状态访问操作对应的状态描述数据。其中,目标进程可以是目标应用中运行在计算节点上且在当前检查点对应的时刻之前使用过目标特定设备的任意进程。
57.在该实现方案中,考虑到目标特定设备的设备状态是因目标应用的不断操作而不断变化的,而目标应用在对目标特定设备操作之前通常需要发起针对目标特定设备的状态访问操作,以获取到目标特定设备的实时状态,因此,这里以状态访问操作为单位,获取每个状态访问操作对应的状态描述信息。应当理解的是,与状态描述信息的定义相适配地,状态描述数据可用于支持将目标特定设备在目标进程下的设备状态恢复至当前检查点。
58.这样,基于该实现方案,状态描述信息中可包含目标特定设备在目标应用中至少一个进程下的状态描述数据。
59.实际应用中,对于目标应用中的目标进程来说,其在当前检查点对应的时刻之前可能会多次发起针对目标特定设备的状态访问操作,本实施例中,并无需保留全部状态访问操作对应的状态描述数据,而是可仅保留目标进程在当前检查点对应的时刻之前最后一次针对目标特定设备发起的状态访问操作对应的状态描述数据即可。保留的该状态描述数据足够支持将目标特定设备在目标进程下的设备状态恢复至当前检查点了。
60.为此,在该实现方案中提出了将目标特定设备在目标进程下的状态描述数据,更新为状态访问操作对应的状态描述数据。也即是,在当前检查点对应的时刻之前,可在每次
发生目标进程针对目标特定设备的状态访问操作时,都执行上述的更新操作,从而实现目标特定设备在目标应用下的状态描述信息中仅保留目标特定设备在目标应用中至少一个进程下的最新的状态描述数据即可。这可有效减少应用转储的数据代价。
61.承接前述实施例中提及的数据采集接口,在该实现方案中,可在发生状态访问操作时,通过调用合适的数据采集接口而为状态访问操作获取到对应的状态描述数据。
62.这样,在当前检查点对应的时刻之前,可不断地整合目标特定设备在目标应用下的状态描述信息,以支持在步骤100中响应于针对目标应用的检查点创建指令而获取到目标特定设备在目标应用下的状态描述信息。
63.优选地,可为目标应用分配指定内存区域,并将目标特定设备在目标应用下的状态描述信息存储在该指定内存区域中,当然,同样地,其它特定设备在目标应用下的状态描述信息也可存储在该指定内存区域中。基于此,在上述实现方案中:可在该指定内存区域中,将目标特定设备在目标进程下的状态描述数据,更新为状态访问操作对应的状态描述数据。也即是,目标应用中每发生一次针对目标特定设备的状态访问操作,即可触发一次针对该指定内存区域的更新操作,该更新操作用于更新该指定内存区域中存储的相应状态描述数据。这样,可在目标应用运行过程中,不断更新该指定内存区域,以在该指定内存区域中维护各个特定设备在目标应用下的状态描述信息。
64.基于该指定内存区域,在步骤101中,可将该指定内存区域中的数据添加至为目标应用构建的检查点文件中。也即是,除了按照传统方案对目标应用的传统内存数据进行转储之外,还提出了将这里为目标应用额外分配的指定内存区域中的内存数据也进行转储。
65.当然,除了上述示例性的实现方案外,本实施例中,还可采用其它实现方案整合目标特定设备在目标应用下的状态描述信息。例如,在接收到检查点创建指令后,回溯目标应用中各个进程各自对目标特定设备发起的最后一次状态访问操作,并为回溯的各个状态访问操作获取对应的状态描述数据,等。本实施例对状态描述信息的维护方式不做限定。
66.综上,本实施例中,可采用各种实现方案在计算节点中维护目标特定设备在目标应用下的状态描述信息,以支持在步骤100中可在发生检查点创建指令时,全面且准确地获取到目标特定设备在目标应用下的状态描述信息。
67.在上述或下述实施例中,还可在目标应用运行之前,在计算节点上启动预置的守护进程。并可由该守护进程来执行前述的步骤100-101。示例性地,在步骤100中,该守护进程可从为目标应用分配的指定内存区域中读取到目标特定设备在目标应用下的状态描述信息,在步骤101中,则可由该守护进程将读取到的状态描述信息添加到为目标应用构建的检查点文件中;以及在步骤102中,可由该守护进程对检查点文件进行转储。
68.另外,在目标应用在计算节点上的运行期间,也可由该守护进程为目标应用维护相关的状态描述信息。也即是,可由该守护进程调用合适的数据采集接口而获取到相关状态访问操作对应的状态描述数据,并更新至指定内存区域中。
69.这里可以存在两种可能的设计构思:
70.在一种设计构思中,在计算节点中,可按照传统的设备状态响应方式向目标应用中的各个进行返回目标特定设备的设备状态。传统的响应方式中可能由计算节点的操作系统或者由特定设备的设备控制器等来完成设备状态的计算工作。而本实施例中的守护进程仅承担状态描述数据的获取工作,并不参与设备状态响应工作。
71.在另一种设计构思中,在计算节点中,可拦截目标应用中各个进程针对目标特定设备发起的各个状态访问操作,而由本实施例中的守护进程代为操作。这种设计构思下,可利用预置的守护进程基于获取到的状态描述数据,计算需返回目标进程的设备状态;利用守护进程将计算出的设备状态返回至目标进程,作为对状态访问操作的响应。其中,可在守护进程中预先定义针对设备状态的计算逻辑,实际应用中,可参考传统设备状态响应方式中的计算逻辑进行定义。另外,现代操作系统都可提供用户空间对内核空间的跟踪。例如,对于linux操作系统,可以使用preload和ptrace机制截获各种路径上用户进程对设备访问。因此,这里可采用各种可行方案实现对状态访问操作的拦截。
72.对于上述两种设计构思进行如下说明:在后一种设计构思中,设备状态的计算工作实质已经脱离了计算节点的操作系统环境等相关依赖环境,而是由守护进程基于获取到的状态描述信息来独立完成设备状态的计算。这种脱离依赖环境的设备状态计算方式,可在应用恢复过程中发挥更明显的优势,这是由于,在应用恢复过程中,可能已经更换了计算节点,原本的依赖环境可能并无法完全恢复,而守护进程则可脱离相关的依赖环境,而基于检查点文件中携带的状态描述信息正确计算出相关的设备状态,从而实现设备状态的正确恢复。
73.通过上述说明可知,在进行应用转储之前,计算节点中采用上述的两种设计构思均可实现本实施例中所需的应用转储效果。对于后一种设计构思,一方面在应用转储过程中可更好地避免对状态访问操作的遗漏,从而更好地保证为目标应用维护的状态描述信息的完整性;另一方面,守护进程内部定义的处理逻辑可直接复用至应用恢复时所处的计算节点上,实现应用转储和恢复两个过程的呼应。
74.综上,本实施例中,可通过在计算节点上启动预置的守护进程,而实现本实施例中的应用转储逻辑,而且,该守护进程可使得设备状态的计算工作脱离计算节点中的依赖环境,从而避免因依赖环境无法完全恢复而导致的应用恢复错误问题。
75.图3为本技术一示例性实施例提供的一种基于检查点的应用恢复方法的流程示意图。图4为本技术一示例性实施例提供的一种基于检查点的应用恢复方法的逻辑示意图。该方法可由数据处理装置执行,该数据处理装置可实现为软件、硬件或软件与硬件的结合,该数据处理装置可集成在计算节点中。参考图3,该方法可包括:
76.步骤300、响应于将目标应用恢复至指定检查点的恢复指令,获取目标应用在指定检查点对应的检查点文件;
77.步骤301、从检查点文件中读取目标特定设备在目标应用下的状态描述信息;
78.步骤302、根据状态描述信息,将目标特定设备在目标应用下的设备状态恢复至指定检查点,以将目标应用恢复至指定检查点。
79.参考图2,本实施例中的计算节点上可装配有多个特定设备,计算节点上的特定设备的数量可以是一个或多个,特定设备的类型可以是一种或多种,本实施例对此不做限定。计算节点上承载的应用可使用这些特定设备。为便于描述,本实施例中,将以计算节点上装配的目标特定设备作为示例进行技术方案的说明,应当理解的是,目标特定设备可以是计算节点上装配的任意一个被目标应用所使用到的特定设备。而从目标应用的视角来说,其在计算节点上所使用到的特定设备则可以是多个,对于目标应用在计算节点上所使用到的除目标特定设备之外的其它特定设备,也可采用本实施例提供的技术方案进行设备状态恢
复。
80.本实施例中,特定设备通常为有状态设备,可包括但不限于有状态的io设备或有状态的异构加速设备等。关于有状态设备的定义在此不再重复赘述。
81.其中,本实施例中的检查点文件中除了包含传统检查点和恢复方案中设计到的应用恢复所需内容之外,还包含了计算节点上至少一个特定设备在目标应用下的状态描述信息,而目标特定设备在目标应用下的状态描述信息可用于支持将目标特定设备在目标应用下的设备状态恢复至指定检查点。
82.本实施例中并不限定检查点文件的生成方案,本实施例中可采用图1所示的基于检查点的应用转储方法来生成本实施例中所需的检查点文件,相关的技术细节可参考前文实施例,在此不做重复说明。但本实施例中生成检查点文件的方案并不限于此。
83.另外,本实施例中的检查点文件可存储在持久化存储资源中,在步骤300中,可从持久化存储资源中读取到目标应用在指定检查点对应的检查点文件。本实施例中,目标应用可具有多个检查点,在步骤300中的恢复指令中可指明所需恢复至的指定检查点。
84.参考图3,在步骤301中,可从检查点文件中读取目标特定设备在目标应用下的状态描述信息。其中,可选地,状态描述信息中包含目标特定设备在目标应用中至少一个进程下的状态描述数据。与状态描述信息的定义相适配地,状态描述数据则是用于支持将目标特定设备在目标进程下的设备状态恢复至指定检查点。
85.基于此,在步骤302中,可根据从检查点文件中读取出的状态描述信息,将目标特定设备在目标应用下的设备状态恢复至指定检查点,以将目标应用恢复至指定检查点。
86.本实施例中的状态描述信息可包含为特定设备计算设备状态过程中所需用到的各项信息。应当理解的是,对于不同类型的特定设备,状态描述信息中所包含的信息项可能不完全相同,这与特定设备的内部工作原理等相关。本实施例中,对状态描述信息中包含的信息项不做限定。几种示例性的信息项可以是特定设备中设备寄存器的标识、设备寄存器的属性、设备寄存器的状态值、设备内存的状态值、设备驱动软件的状态值、用于支持状态转换的上下文信息和/或用于支持状态映射的映射关系中等。其中,设备寄存器的属性可包括但不限只读、只写、需模拟或需映射等。设备寄存器的状态值是指设备寄存器中记录的状态数据,这些状态数据可作为计算特定设备的设备状态的依据。值得说明的是,本实施例中,可按需设定状态描述信息中包含的信息项,而并不限于此。
87.因此,在步骤302的设备状态恢复过程中,可能存在多种情况,本实施例针对几种示例性的情况分别提供了如下的可选恢复方案:
88.一种示例性的情况下:若目标特定设备在目标应用中目标进程下的状态描述数据中指示第一设备寄存器的属性为需模拟,则基于状态描述数据中与第一设备寄存器关联的上下文信息,模拟第一设备寄存器的状态转换过程,以将第一设备寄存器在目标进程下的设备状态恢复至指定检查点;其中,第一设备寄存器为目标特定设备所包含的任一设备寄存器,目标进程为目标应用中运行在计算节点上的任意进程。
89.另一种示例性的情况下:若状态描述数据中指示第一设备寄存器的属性为需映射,则基于状态描述数据中与第一设备寄存器关联的映射关系,对第一设备寄存器提供的状态值进行映射,以将第一设备寄存器在目标进程下的设备状态恢复至指定检查点。
90.举例来说,若第一设备寄存器中记录的其中一个状态值为dma访问地址,但是,由
于更换了计算节点,而第一设备寄存器中记录的是通常是操作系统所分配的dma访问地址,该dma访问地址在不同的计算节点的硬件环境中可能对应的是不同的内存地址。这里,则可基于状态描述数据中携带的地址映射关系,将第一寄存器中记录的dma访问地址映射至正确的地址,并将正确的地址返回给目标进程,这可保证目标地址后续按照正确的地址向目标特定设备发起dma操作指令。
91.也即是,可根据目标特定设备中不同设备寄存器的属性,而对各个设备寄存器采用合适的恢复逻辑进行设备状态的恢复,以保证各个设备寄存器的设备状态得以正确恢复。
92.本实施例中,可在计算节点上运行预置的守护进程,并利用守护进程实施上述的应用恢复方案。
93.基于此,在步骤302中,可在守护进程中预先定义好各种属性下的恢复逻辑,这样,守护进程可按照合适的恢复逻辑,从检查点文件携带的状态描述信息读取到计算所需的信息项,从而对各个设备寄存器的设备状态进行正确恢复。
94.本实施例中的计算节点可以是目标应用转储前所处的原计算节点,当然,也可以是新的计算节点。本实施例中,只需保证计算节点上装配有目标应用所需使用的特定设备即可。
95.在一种优选的实现方案中:可在目标应用的恢复过程中,监听目标应用中各个进程对目标特定设备发起的状态访问操作,并在监听到状态访问操作之后,在执行步骤301和步骤302。
96.在该实现方案中,可拦截监听到的状态访问操作;
97.利用预置的守护进程从检查点文件中读取拦截的状态访问操作对应的状态描述数据,计算需返回目标进程的设备状态,目标进程为发起该状态访问操作的进程;
98.利用守护进程将计算出的设备状态返回至目标进程,作为对状态访问操作的响应。
99.这样,在该实现方案中,在发生状态访问操作时,不再执行传统的设备状态响应逻辑,而是由守护进程代为进行设备状态计算。而守护进程可脱离原计算节点上的依赖环境完成设备状态计算,只需从检查点文件中读取正确地的状态描述数据,并运行内部预先定义好的合适的恢复逻辑,即可计算出正确的设备状态。这样,即使应用恢复时所处的计算节点不再具备原计算节点的完整依赖环境,也可基于守护进程而在应用恢复时所处的计算节点上正确恢复目标特定设备在目标应用下的设备状态,从而保证目标应用的正常恢复。
100.在该实现方案中,守护进程可在监听到目标进程针对目标特定设备发起的首次或最早的n次状态访问操作时,按照前述的代为操作逻辑向目标进程返回设备状态。目标进程后续针对目标特定设备发起的状态访问操作则可按照传统的设备状态响应方式进行处置。当然,也可一致保持由守护进程按照前述的代为操作逻辑向目标进程发起的的每一次状态访问操作返回设备状态,而彻底禁用传统的设备状态响应方案。在此不做限定。
101.综上,本实施例中,开拓性地提出了将目标特定设备在目标应用下的状态描述信息携带在为目标应用构建的检查点文件中,这样,检查点文件中除了包含传统的应用恢复所需内容外,还增加了用于支持将目标特定设备在目标应用下的设备状态恢复至指定检查点的状态描述信息。在此基础上,在基于检查点对目标应用进行恢复的过程中,可从检查点
文件中读取到该状态描述信息,并基于该状态描述信息将目标特定设备在目标应用下的设备状态恢复至指定检查点,这可为目标应用提供正确的设备状态,从而保证目标应用的正常恢复。因此,本技术实施例中,通过对转储过程和恢复过程的改造,可保证目标应用在使用到有状态的特定设备的情况下,依然可以正常恢复。
102.另外,本实施例提供的应用转储和恢复方法可应用至hpc集群系统中,实现带状态多进程并行作业的转储和恢复。这可以提高hpc集群系统利用率,增加集群吞吐量,节省成本。通过对hpc作业的转存储,通过调度后恢复可以实现作业迁移集中,从而可以腾出更多的可用节点给后面的作业或者释放掉空闲节点。还可实现让后提交的优先级更高的集群作业能够,实现无感知抢占。以往对于并行作业需要抢占,往往是在作业系统里简单杀掉正在执行作业,从而让高优先级作业有资源得到调度运行,通过本方案对并行作业的检查点和恢复可以实现多机作业抢占。另外,还可提供集群资源维护便利。当有集群节点运维动作需要实施时,系统管理员可以将待操作的节点上的作业迁临时转存储,然后即可实施资源维护操作,等待节点维护完成之后再进行恢复。基于此,再结合hpc集群系统中的调度算法和策略,可使得hpc集群系统在运维、故障处理等方面获益。
103.需要说明的是,在上述实施例及附图中的描述的一些流程中,包含了按照特定顺序出现的多个操作,但是应该清楚了解,这些操作可以不按照其在本文中出现的顺序来执行或并行执行,操作的序号如801、802等,仅仅是用于区分开各个不同的操作,序号本身不代表任何的执行顺序。另外,这些流程可以包括更多或更少的操作,并且这些操作可以按顺序执行或并行执行。
104.图5为本技术另一示例性实施例提供的一种计算节点的结构示意图。如图5所示,该计算设备包括:存储器50、处理器51以及目标特定设备52。
105.处理器51,与存储器50耦合,用于执行存储器50中的计算机程序,以用于:
106.响应于针对目标应用的检查点创建指令,获取目标特定设备52在目标应用下的状态描述信息,状态描述信息用于支持将目标特定设备52在目标应用下的设备状态恢复至当前检查点;
107.将状态描述信息添加至为目标应用构建的检查点文件中;
108.对检查点文件进行转储,以在将目标应用恢复至当前检查点时基于状态描述信息对目标特定设备52的设备状态进行恢复。
109.在一可选实施例中,状态描述信息中包含目标特定设备52在目标应用中至少一个进程下的状态描述数据,在响应于针对目标应用的检查点创建指令之前,处理器51还可用于:
110.在当前检查点对应的时刻之前,若监听到目标应用中的目标进程发起针对目标特定设备52的状态访问操作,则获取状态访问操作对应的状态描述数据,状态访问操作对应的状态描述数据用于计算需返回目标进程的设备状态;
111.将目标特定设备52在目标进程下的状态描述数据,更新为状态访问操作对应的状态描述数据;
112.其中,目标进程为目标应用中运行在计算节点上的任意进程。
113.在一可选实施例中,处理器51在获取状态访问操作对应的状态描述数据时,具体可用于:
114.确定目标特定设备52对应的目标设备类型;
115.调用目标设备类型所适配的数据采集接口,采集状态访问操作对应的状态描述信息;
116.其中,不同设备类型适配不同的数据采集接口,数据采集接口中定义有其支持的设备类型下所需采集的信息项及采集逻辑。
117.在一可选实施例中,处理器51还可用于:
118.拦截状态访问操作;
119.利用预置的守护进程基于获取到的状态描述数据,计算需返回目标进程的设备状态;
120.利用守护进程将计算出的设备状态返回至目标进程,作为对状态访问操作的响应。
121.在一可选实施例中,状态描述信息包括目标特定设备52中设备寄存器的标识、设备寄存器的属性、设备寄存器的状态值、设备内存的状态值、设备驱动软件的状态值、用于支持状态转换的上下文信息和用于支持状态映射的映射关系中的一种或多种。
122.在一可选实施例中,状态描述信息存储在为目标应用分配的指定内存区域中,处理器51在将目标特定设备52在目标进程下的状态描述数据,更新为状态访问操作对应的状态描述数据息时,具体可用于:
123.将指定内存区域中,将目标特定设备52在目标进程下的状态描述数据,更新为状态访问操作对应的状态描述数据。
124.在一可选实施例中,处理器51还可用于:
125.响应于将目标应用恢复至当前检查点的恢复指令,获取目标应用在当前检查点对应的检查点文件;
126.从检查点文件中读取状态描述信息;
127.基于状态描述信息,将目标特定设备52在目标应用下的设备状态恢复至当前检查点,以将目标应用恢复至当前检查点。
128.在一可选实施例中,目标特定设备52为有状态的网络设备或有状态的异构加速设备等有状态设备。
129.在另一些可能的设计方案中,还可基于图5所示的计算节点提供基于检查点的应用恢复方案。在这些可能的设计方案中,处理器51可用于执行存储器50中的计算机程序,以用于:
130.响应于将目标应用恢复至指定检查点的恢复指令,获取目标应用在指定检查点对应的检查点文件;
131.从检查点文件中读取目标特定设备52在目标应用下的状态描述信息;
132.根据状态描述信息,将目标特定设备52在目标应用下的设备状态恢复至指定检查点,以将目标应用恢复至指定检查点。
133.在一可选实施例中,状态描述信息中包含目标特定设备52在目标应用中至少一个进程下的状态描述数据,处理器51在根据状态描述信息,将目标特定设备52在目标应用下的设备状态恢复至指定检查点时,具体可用于:
134.若目标特定设备52在目标应用中目标进程下的状态描述数据中指示第一设备寄
存器的属性为需模拟,则基于状态描述数据中与第一设备寄存器关联的上下文信息,模拟第一设备寄存器的状态转换过程,以将第一设备寄存器在目标进程下的设备状态恢复至指定检查点;
135.其中,第一设备寄存器为目标特定设备52所包含的任一设备寄存器,目标进程为目标应用中运行在计算节点上的任意进程。
136.在一可选实施例中,处理器51还可用于:
137.若状态描述数据中指示第一设备寄存器的属性为需映射,则基于状态描述数据中与第一设备寄存器关联的映射关系,对第一设备寄存器提供的状态值进行映射,以将第一设备寄存器在目标进程下的设备状态恢复至指定检查点。
138.进一步,如图5所示,该计算节点还包括:通信组件53、电源组件54等其它组件。图5中仅示意性给出部分组件,并不意味着计算节点只包括图5所示组件。另外,图5所示的计算节点可以是云服务器或者是多个云服务器组成的逻辑节点,在此不做限定。
139.值得说明的是,上述关于计算节点各实施例中的技术细节,可参考前述的方法实施例中的相关描述,为节省篇幅,在此不再赘述,但这不应造成本技术保护范围的损失。
140.相应地,本技术实施例还提供一种存储有计算机程序的计算机可读存储介质,计算机程序被执行时能够实现上述方法实施例中可由计算设备执行的各步骤。
141.上述图5中的存储器,用于存储计算机程序,并可被配置为存储其它各种数据以支持在计算平台上的操作。这些数据的示例包括用于在计算平台上操作的任何应用程序或方法的指令,联系人数据,电话簿数据,消息,图片,视频等。存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现,如静态随机存取存储器(sram),电可擦除可编程只读存储器(eeprom),可擦除可编程只读存储器(eprom),可编程只读存储器(prom),只读存储器(rom),磁存储器,快闪存储器,磁盘或光盘。
142.上述图5中的通信组件,被配置为便于通信组件所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络,如wifi,2g、3g、4g/lte、5g等移动通信网络,或它们的组合。在一个示例性实施例中,通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中,所述通信组件还包括近场通信(nfc)模块,以促进短程通信。例如,在nfc模块可基于射频识别(rfid)技术,红外数据协会(irda)技术,超宽带(uwb)技术,蓝牙(bt)技术和其他技术来实现。
143.上述图5中的电源组件,为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理系统,一个或多个电源,及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。
144.本领域内的技术人员应明白,本技术的实施例可提供为方法、系统、或计算机程序产品。因此,本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
145.本技术是参照根据本技术实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流
程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
146.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
147.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
148.还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个
……”
限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
149.需要说明的是,本技术所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等),均为经用户授权或者经过各方充分授权的信息和数据,并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准,并提供有相应的操作入口,供用户选择授权或者拒绝。
150.以上所述仅为本技术的实施例而已,并不用于限制本技术。对于本领域技术人员来说,本技术可以有各种更改和变化。凡在本技术的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本技术的保护范围之内。

技术特征:
1.一种基于检查点的应用转储方法,适用于计算节点,所述计算节点上装配有目标特定设备,所述方法包括:响应于针对目标应用的检查点创建指令,获取所述目标特定设备在所述目标应用下的状态描述信息,所述状态描述信息用于支持将所述目标特定设备在所述目标应用下的设备状态恢复至当前检查点;将所述状态描述信息添加至为所述目标应用构建的检查点文件中;对所述检查点文件进行转储,以在将所述目标应用恢复至所述当前检查点时基于所述状态描述信息对所述目标特定设备的设备状态进行恢复。2.根据权利要求1所述的方法,所述状态描述信息中包含所述目标特定设备在所述目标应用中至少一个进程下的状态描述数据,在响应于针对目标应用的检查点创建指令之前,所述方法还包括:在所述当前检查点对应的时刻之前,若监听到所述目标应用中的目标进程发起针对所述目标特定设备的状态访问操作,则获取所述状态访问操作对应的状态描述数据,所述状态访问操作对应的状态描述数据用于计算需返回所述目标进程的设备状态;将所述目标特定设备在所述目标进程下的状态描述数据,更新为所述状态访问操作对应的状态描述数据;其中,所述目标进程为所述目标应用中运行在所述计算节点上的任意进程。3.根据权利要求2所述的方法,所述获取所述状态访问操作对应的状态描述数据,包括:确定所述目标特定设备对应的目标设备类型;调用所述目标设备类型所适配的数据采集接口,采集所述状态访问操作对应的状态描述信息;其中,不同设备类型适配不同的数据采集接口,数据采集接口中定义有其支持的设备类型下所需采集的信息项及采集逻辑。4.根据权利要求2所述的方法,还包括:拦截所述状态访问操作;利用预置的守护进程基于获取到的所述状态描述数据,计算需返回所述目标进程的设备状态;利用所述守护进程将计算出的所述设备状态返回至所述目标进程,作为对所述状态访问操作的响应。5.根据权利要求1-4任一项所述的方法,所述状态描述信息包括所述目标特定设备中设备寄存器的标识、设备寄存器的属性、设备寄存器的状态值、设备内存的状态值、设备驱动软件的状态值、用于支持状态转换的上下文信息和用于支持状态映射的映射关系中的一种或多种。6.根据权利要求2所述的方法,所述状态描述信息存储在为所述目标应用分配的指定内存区域中,将所述目标特定设备在所述目标进程下的状态描述数据,更新为所述状态访问操作对应的状态描述数据息,包括:将所述指定内存区域中,将所述目标特定设备在所述目标进程下的状态描述数据,更新为所述状态访问操作对应的状态描述数据。
7.根据权利要求1所述的方法,还包括:响应于将所述目标应用恢复至所述当前检查点的恢复指令,获取所述目标应用在所述当前检查点对应的检查点文件;从所述检查点文件中读取所述状态描述信息;基于所述状态描述信息,将所述目标特定设备在所述目标应用下的设备状态恢复至所述当前检查点,以将所述目标应用恢复至所述当前检查点。8.根据权利要求1所述的方法,所述目标特定设备为有状态的网络设备或有状态的异构加速设备。9.一种基于检查点的应用恢复方法,适用于计算节点,所述计算节点上装配有目标特定设备,所述方法包括:响应于将目标应用恢复至指定检查点的恢复指令,获取所述目标应用在所述指定检查点对应的检查点文件;从所述检查点文件中读取所述目标特定设备在所述目标应用下的状态描述信息;根据所述状态描述信息,将所述目标特定设备在所述目标应用下的设备状态恢复至所述指定检查点,以将所述目标应用恢复至所述指定检查点。10.根据权利要求9所述的方法,所述状态描述信息中包含所述目标特定设备在所述目标应用中至少一个进程下的状态描述数据,根据所述状态描述信息,将所述目标特定设备在所述目标应用下的设备状态恢复至所述指定检查点,包括:若所述目标特定设备在所述目标应用中目标进程下的状态描述数据中指示第一设备寄存器的属性为需模拟,则基于所述状态描述数据中与所述第一设备寄存器关联的上下文信息,模拟所述第一设备寄存器的状态转换过程,以将所述第一设备寄存器在所述目标进程下的设备状态恢复至所述指定检查点;其中,所述第一设备寄存器为所述目标特定设备所包含的任一设备寄存器,所述目标进程为所述目标应用中运行在所述计算节点上的任意进程。11.根据权利要求10所述的方法,还包括:若所述状态描述数据中指示所述第一设备寄存器的属性为需映射,则基于所述状态描述数据中与所述第一设备寄存器关联的映射关系,对所述第一设备寄存器提供的状态值进行映射,以将所述第一设备寄存器在所述目标进程下的设备状态恢复至所述指定检查点。12.一种计算节点,包括存储器、处理器和通信组件;所述存储器用于存储一条或多条计算机指令;所述处理器与所述存储器和所述通信组件耦合,用于执行所述一条或多条计算机指令,以用于执行权利要求1-8任一项所述的基于检查点的应用转储方法或权利要求9-11任一项所述的基于检查点的应用恢复方法。13.一种存储计算机指令的计算机可读存储介质,当所述计算机指令被一个或多个处理器执行时,致使所述一个或多个处理器执行权利要求1-8任一项所述的基于检查点的应用转储方法或权利要求9-11任一项所述的基于检查点的应用恢复方法。

技术总结
本申请实施例提供一种基于检查点的应用转储和恢复方法、设备及存储介质。开拓性地提出了为计算节点上装配的目标特定设备整合出在目标应用下的状态描述信息,并将该状态描述信息添加到为目标应用构建的检查点文件中。在此基础上,在基于检查点对目标应用进行恢复的过程中,可从检查点文件中读取到该状态描述信息,并基于该状态描述信息将目标特定设备在目标应用下的设备状态恢复至指定检查点,这可为目标应用提供正确的设备状态,从而保证目标应用的正常恢复。因此,本申请实施例中,通过对转储过程和恢复过程的改造,可保证目标应用在使用到有状态的特定设备的情况下,依然可以正常恢复。恢复。恢复。


技术研发人员:林沐晖
受保护的技术使用者:阿里巴巴(中国)有限公司
技术研发日:2023.05.24
技术公布日:2023/8/21
版权声明

本文仅代表作者观点,不代表航空之家立场。
本文系作者授权航家号发表,未经原创作者书面授权,任何单位或个人不得引用、复制、转载、摘编、链接或以其他任何方式复制发表。任何单位或个人在获得书面授权使用航空之家内容时,须注明作者及来源 “航空之家”。如非法使用航空之家的部分或全部内容的,航空之家将依法追究其法律责任。(航空之家官方QQ:2926969996)

飞行汽车 https://www.autovtol.com/

分享:

扫一扫在手机阅读、分享本文

相关推荐