一种节点故障的处理方法、装置、存储介质和电子设备与流程

本申请涉及计算机领域，尤其涉及一种节点故障的处理方法、装置、存储介质和电子设备。

背景技术：

目前，为了实现集群存储的高可用性，可将集群中每两个节点设置为一组，同组之内的两个节点对应的软件和硬件是完全相同的。从而，在同组中的任一个节点出现故障的情况下，同组中的另外一个节点可接替该组的故障节点对外提供服务。

但是，由于在同组中的一个节点正常运行的过程中，同组中的另外一个节点是无法提供服务的，所以这种设置方式至少存在着浪费资源的问题。

技术实现要素：

本申请实施例的目的在于提供的一种节点故障的处理方法、装置、存储介质和电子设备，以解决现有技术中存在着的浪费资源的问题。

第一方面，本申请实施例提供了一种节点故障的处理方法，该处理方法应用于分布式文件系统，该处理方法包括：第二节点在确定第一节点故障的情况下，从配置文件中解析出第一节点的资源信息，其中，配置文件记录有分布式文件系统中每个节点的资源信息，第一节点的资源信息包括第一节点对应的存储设备信息和第一节点的服务；第二节点根据存储设备信息，挂载存储设备信息对应的存储设备，并启动第一节点的服务。

因此，本申请实施例通过在第一节点故障的情况下，可从系统中的正常节点中选取一个第二节点来接管第一节点的服务，相比于现有的为每个运行节点都配置备份节点的方案，由于本申请实施例无需再为每个节点设置备份节点，从而不仅提高了节点资源的利用率，还能够降低成本。

在一个可能的实施例中，在从配置文件中解析出第一节点的资源信息之前，处理方法还包括：第二节点对挂载在第二节点的共享卷中的锁文件执行加锁操作；第二节点在共享卷中的接管信息文件中写入接管信息，其中，接管信息为表示第二节点接管第一节点的服务的信息；第二节点对锁文件执行解锁操作。

因此，本申请实施例可通过往接管信息文件中写入接管信息，从而防止出现多个节点均接管第一节点的服务导致的存储的数据不一致的问题。

在一个可能的实施例中，处理方法还包括：在第一节点恢复正常的情况下，第二节点接收第一节点发送的资源释放请求；第二节点根据资源释放请求，停止第一节点的服务，并释放资源信息对应的资源；第二节点生成携带有释放完成的反馈信息；第二节点向第一节点发送反馈信息。

因此，本申请实施例中的第一节点在确定第二节点已经释放资源完毕的情况下，开始故障节点的恢复过程，从而避免了两个节点同时访问同一个磁盘所导致的磁盘数据损坏的问题。

此外，本申请实施例中的节点在恢复后，其可将之前的业务自动切回，从而实现负载均衡，避免单个节点长时间、高负载运行。

在一个可能的实施例中，在第二节点根据存储设备信息，挂载存储设备信息对应的存储设备，并启动第一节点的服务之后，处理方法还包括：第二节点获取自身的节点状态信息，其中，节点状态信息包括第二节点接管第一节点的服务的信息；第二节点向后台服务器发送节点状态信息，以便于后台服务器监控第二节点。

因此，本申请实施例可实现集群中的各个节点的监控，以及还实现了相关事件的展示(例如，可通过图形界面来进行展示)，从而极大地方便了用户。

第二方面，本申请实施例提供了一种节点故障的处理装置，该处理装置应用于分布式文件系统中的第二节点，该处理装置包括：解析模块，用于在确定第一节点故障的情况下，从配置文件中解析出第一节点的资源信息，其中，配置文件记录有分布式文件系统中每个节点的资源信息，第一节点的资源信息包括第一节点对应的存储设备信息和第一节点的服务；挂载启动模块，用于根据存储设备信息，挂载存储设备信息对应的存储设备，并启动第一节点的服务。

在一个可能的实施例中，处理装置还包括：加锁模块，用于对挂载在第二节点的共享卷中的锁文件执行加锁操作；写入模块，用于在共享卷中的接管信息文件中写入接管信息，其中，接管信息为表示第二节点接管第一节点的服务的信息；解锁模块，用于对锁文件执行解锁操作。

在一个可能的实施例中，所述处理装置还包括：接收模块，用于在所述第一节点恢复正常的情况下，接收所述第一节点发送的资源释放请求；释放模块，用于根据所述资源释放请求，停止所述第一节点的服务，并释放所述资源信息对应的资源；生成模块，用于生成携带有释放完成的反馈信息；第一发送模块，用于向所述第一节点发送反馈信息。

在一个可能的实施例中，所述处理装置还包括：获取模块，用于获取自身的节点状态信息，其中，所述节点状态信息包括所述第二节点接管所述第一节点的服务的信息；第二发送模块，用于向后台服务器发送所述节点状态信息，以便于所述后台服务器监控所述第二节点。

第三方面，本申请实施例提供了一种存储介质，该存储介质上存储有计算机程序，该计算机程序被处理器运行时执行第一方面或第一方面的任一可选的实现方式所述的方法。

第四方面，本申请实施例提供了一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当所述电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行第一方面或第一方面的任一可选的实现方式所述的方法。

第五方面，本申请提供一种计算机程序产品，所述计算机程序产品在计算机上运行时，使得计算机执行第一方面或第一方面的任意可能的实现方式中的方法。

为使本申请实施例所要实现的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例提供的一种分布式文件系统的示意图；

图2示出了本申请实施例提供的一种节点故障的处理方法的流程图；

图3示出了本申请实施例提供的一种释放资源的方法的流程图；

图4示出了本申请实施例提供的一种节点故障的处理方法的具体流程图；

图5示出了本申请实施例提供的一种节点故障的处理装置的结构框图；

图6示出了本申请实施例提供的一种电子设备的结构框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

在大数据时代的今天，云计算、云存储高速发展以及物联网的兴起导致数据呈爆炸式增长，其中非结构数据更是占据了全球数据的90％，于是一种基于横向扩展存储架构的集群nas(networkattachedstorage，网络附属存储)诞生了，有别于传统的san(storageareanetwork，存储区域网络)和nas，它是一种新的存储构架，主要面向文件级别的存储。

此外，它不但集中了san和nas的优点，还具备了它们不具备的一些优点，例如，容量和性能线性扩展等。随着集群nas不断地扩容，其性能也会随之提升，理论上，达到一定规模的集群nas在性能上可以胜过一个san系统，并且其成本远远低于san系统。现今，集群nas已经到了全球市场的广泛认可，成为了主流的存储技术之一。

在存储领域中，存储系统的高可用性一直是关注的重点，随着用户对存储系统的高可用性需求不断变化，高可用性也在不断向前发展。同时，现有的高可用的方案包括磁盘级的高可用、节点级的高可用和共享级的高可用。

其中，磁盘级的高可用是指损坏部分磁盘不影响集群的正常使用。以及，磁盘级的高可用性的做法主要包括：使用磁盘阵列raid01、磁盘阵列raid5和磁盘阵列raid10等磁盘阵列的方式来保护磁盘数据；以及，磁盘阵列中的两个控制器互为备份，一个控制器失效以后还有剩余的控制器可用。

但是，对于磁盘级的高可用来说，在整个节点(或者服务器)宕机的情况下，则磁盘阵列或者双控磁盘阵列就无法使用了，即存储系统不可用。

以及，节点级的高可用为可将集群中每两个节点设置为一组，同组之内的两个节点对应的软件和硬件是完全相同的。从而，在同组中的任一个节点出现故障的情况下，同组中的另外一个节点可接替该组的故障节点对外提供服务。

但是，对于节点级的高可用来说，这种设置方式至少存在着浪费节点资源和成本比较高的问题。

以及，共享级的高可用可以是指共享文件的高可用，也可以是指共享级的高可用。共享级的高可用，与通用集群存储的使用方式有关。通用集群存储，通常会提供一个统一命名空间给用户，这也是分布式文件系统的设计最根本的目的，将零散的存储集合起来。但通常最后都是通过共享协议的方式将这个存储提供给用户，例如，服务器信息块(servermessageblock，smb)、网络文件系统(networkfilesystem，nfs)或者文件传输协议(filetransferprotocol，ftp)等。

也就是说，在集群中的一定数量节点出现故障的情况下，整个集群的smb、nfs和ftp等服务仍然可以正常使用。

但是，对于共享级的高可用来说，其至少存在着不能很好的支持存储区域网络(storageareanetwork，san)共享磁盘的问题。

基于此，本申请实施例巧妙地提出了一种节点故障的处理方案，通过第二节点在确定第一节点故障的情况下，从配置文件中解析出包括第一节点对应的存储设备信息和第一节点的服务的第一节点的资源信息，以及第二节点根据存储设备信息，挂载存储设备信息对应的存储设备，并启动第一节点的服务。其中，配置文件记录有分布式文件系统中每个节点的资源信息。

因此，本申请实施例通过在第一节点故障的情况下，可从系统中的正常节点中选取一个第二节点来接管第一节点的服务，相比于现有的为每个运行节点都配置备份节点的方案，由于本申请实施例无需再为每个节点设置备份节点，从而本申请不仅可以提高节点资源的利用率，还能够降低成本。

为了便于理解本申请实施例，首先在此对本申请实施例中的一些术语进行解释如下：

名词“高可用性”：它通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。

名词“轻量级的集群数据库(clustertrivialdatabase，ctdb)”：它可设置在集群中的每个节点上，并监控整个分布式文件系统中各个节点的网络状态，还可通过定时器来触发事件，定时对当前节点的服务、设备等进行监控，若当前节点的状态发生变化，则会将信息与其他节点进行同步，并触发相应的事件。

例如，ctdb可通过运行监控脚本，来监控当前节点的共享服务的状态。

再例如，在确定分布式文件系统中的某个节点出现故障(例如，宕机、断电或者断网等)的情况下，集群中的每个正常节点的ctdb均可生成接管事件。其中，接管事件用于指示当前节点中的高可用模块接管故障节点的服务。

应理解，虽然上面对ctdb的一些功能进行了描述，但是，本领域的技术人员应当理解，该ctdb还可具备其他的功能，本申请实施例并不局限于此。

例如，该ctdb还可给集群中的各个节点分配ip地址等。

名词“高可用模块”：它可用于接管故障节点(例如，第一节点等)的资源和释放之前接管的故障节点(例如，第一节点等)的资源。

应理解，高可用模块也可称为高可用系统。

名词“dns”：它可用于从主机名到ip地址的转换。

名词“存储模块”：它可提供对应的文件接口，由于其提供文件接口，从而其可提供存储服务。

应理解，存储模块也可称为存储服务。

请参见图1，图1示出了本申请实施例提供的一种分布式文件系统100的示意图。如图1所述的分布式文件系统100包括第一节点110、第二节点120和分别与第一节点110和第二节点120连接的共享存储设备。

其中，第一节点110中可设置有第一ctdb111、第一高可用模块112和第一存储模块(未示出)。以及，第二节点120中可设置第二ctdb121和第二高可用模块122和第二存储模块(未示出)。

这里需要说明的，在第一节点110提供存储服务的过程中，第二节点120也可提供存储服务，即第一节点110和第二节点120都可以是提供服务的节点。

为了便于理解本申请实施例，下面通过具体的实施例来进行描述。

具体地，在确定第一节点110出现故障的情况下，第二节点120中的第二ctdb121可通过定时器触发生成接管事件。以及，第二ctdb121可将接管事件发送到第二高可用模块122。

以及，第二高可用模块122可根据接管事件，查询第二节点120的配置文件。以及，由于分布式文件系统100中的每个节点的配置文件均记录有分布式文件系统100中每个节点的资源信息，从而第二高可用模块122可获取到第一节点110的资源信息。其中，第一节点110的资源信息包括第一节点110对应的存储设备信息和第一节点110的服务的信息。

以及，第二高可用模块122可根据第一节点110对应的存储设备信息，挂载存储设备信息对应的存储设备，并在第二节点120启动第一节点110故障前的服务。

此外，在第一节点110恢复正常后，第一节点110可向第二节点120发送资源释放请求。对应地，第二节点120接收第一节点110发送的资源释放请求。

此外，这里需要说明的是，第一节点110恢复之后，第一节点110的存储服务恢复之前，第一节点110向第二节点120发送资源释放请求。

以及，第二节点120可根据资源释放信息，停止之前接管的第一节点110的服务，然后再释放其之前接管的第一节点110的资源(或者说，第一节点110的服务对应的资源)，并向第一节点110反馈释放完成的信息。

此外，在第一节点110接收到第二节点120返回的已经释放的信息之后，第一节点110开始恢复存储服务。

需要说明的是，本发明实施例提供的节点故障的处理方案还可以进一步拓展到其它合适的分布式文件系统中，而不限于图1所示的分布式文件系统100。

例如，虽然图1中仅示出了2个节点，但本领域的技术人员应当理解，在实际应用的过程中，该分布式文件系统100可以包括更多的节点。

再例如，虽然图1示出了第一节点110中设置的模块，但本领域的技术人员应当理解，该第一节点110还可设置有其他的模块(其他的模块可包括初始化模块和终止化模块。其中，初始化模块可用于在节点重启之后，对节点进初始化；终止化模块可用于清理节点中的配置文件，从而实现相关服务的停止，同时，该终止化模块也可用于修复配置文件等)。

对应地，集群中的其它节点同样也可设置有其它的模块，本申请实施例并不局限于此。

请参见图2，图2示出了本申请实施例提供的一种节点故障的处理方法的流程图。如图2所示的处理方法包括：

步骤s210，第二节点在确定第一节点故障的情况下，从配置文件中解析出第一节点的资源信息。其中，配置文件记录有分布式文件系统中每个节点的资源信息，第一节点的资源信息可包括第一节点对应的存储设备信息和第一节点的服务。

应理解，每个节点的资源信息均可包括各个节点对应的存储设备信息和各个节点的服务的信息。

还应理解，存储设备信息所包含的信息可根据实际需求来进行设置，只要保证能够根据存储设备信息挂载相应的存储设备即可，本申请实施例并不局限于此。

例如，在共享存储设备为san存储设备的情况下，该存储设备信息可包括san存储信息和分布式文件系统的卷信息等。其中，san存储信息可包括访问san存储设备的ip地址、磁盘名称(例如，iqn)等。

还应理解，第一节点的服务所对应的具体服务可根据实际需求来进行设置，本申请实施例并不局限于此。

例如，第一节点的服务可为存储服务等。

为了便于理解本申请实施例，下面通过具体的实施例来进行描述。

具体地，在分布式文件系统中的各个正常节点(包括第二节点)中的ctdb达成共识后(或者说，各个正常节点就“第一节点发生故障”，达成共识)，各个正常节点中的ctdb可通过对应的定时器触发生成接管事件，并将接管事件发送到各自对应的高可用模块。其中，共识是指集群中各个正常节点都认为发生了某件事或者认同了某个信息。

此外，分布式文件系统中的各个节点均可设置有共享卷，且每个节点都可访问对应的共享卷。以及，共享卷可存储有记录信息。其中，共享卷是分布式文件系统中的一个卷，每个节点可把这个卷挂载到自己上面，后续在每个节点上都可以访问这个卷了。

应理解，记录信息所对应的具体信息可根据实际需求来进行设置，本申请实施例并不局限于此。

例如，记录信息可以包括某故障节点a被某个节点b所接管等。

从而，各个节点中的高可用模块均可对挂载在对应的节点的共享卷中的锁文件执行加锁操作(例如，第二节点中的高可用模块可对挂载在第二节点的共享卷中的锁文件执行加锁操作)。其中，锁文件可用于对对应的接管信息文件进行保护。

此外，由于各个节点中的高可用模块对锁文件加锁成功的顺序或者时间可能是不一样的，且第一个获得锁的节点可接管故障节点的服务，并在共享卷中添加记录信息，所以在对锁文件执行加锁操作成功后，当前节点中的高可用模块可查询对应的共享卷中的记录信息，以确定共享卷中是否记录有故障节点已经被接管的信息。

此外，这里需要说明的是，对于共享卷来说，共享卷在每个节点的挂载点存在对应的接管信息文件，各个节点可在对应的接管信息文件中写入接管信息。其中，接管信息文件用于记录接管信息。

其中，在接管信息文件中没有记录该故障节点被接管的信息的情况下，该高可用模块可在接管信息文件中写入故障节点被当前节点接管的信息；在接管信息文件中记录有故障节点被接管的信息的情况下，则当前节点不接管该故障节点。

随后，该高可用模块可对锁文件执行解锁操作。

应理解，虽然上面以在锁文件上进行加锁或者解锁为例来进行描述的，但本领域的技术人员应当理解，还可通过其他的方式来实现加锁或者解锁，本申请实施例并不局限于此。

例如，第二节点在确定第一节点故障的情况下，第二节点中的高可用模块可对锁文件执行加锁操作。以及，在加锁成功的情况下，第二节点中的高可用模块可通过查询共享卷中的接管信息文件，确定第一节点还没有被接管，则第二节点中的高可用模块可在接管信息文件中写入用于表示第二节点接管第一节点的服务的信息。最后，第二节点中的高可用模块对对应的锁文件执行解锁操作。

进而，在共享卷中记录有用于表示第二节点接管第一节点的服务的信息的情况下，由于分布式文件系统中的每个节点的配置文件均记录有分布式文件系统中每个节点的资源信息，第二节点可通过查询配置文件，确定第一节点对应的资源信息。

步骤s220，第二节点根据存储设备信息，挂载存储设备信息对应的存储设备，并启动第一节点的服务。

应理解，第二节点根据存储设备信息，挂载存储设备信息对应的存储设备，并启动第一节点的服务的具体过程可根据实际需求来进行设置，本申请实施例并不局限于此。

为了便于理解本申请实施例，下面通过具体的实施例来进行描述。

具体地，在存储设备信息包括卷信息和san存储信息的情况下，第二节点中的高可用模块可根据存储设备信息挂载san中的存储设备，并修改第二节点中的分布式文件系统的配置文件。随后，第二节点中的高可用模块重启第二节点的分布式文件系统的服务，以便在第二节点上启动第一节点的服务，且此时存储设备上的卷恢复使用。随后，第二节点通知集群中的其它节点更新dns。从而，在第一节点故障之后，存储系统的cifs、nfs、ftp、s3等服务，不受影响，用户可以继续访问。

应理解，dns的更新方式可根据实际需求来进行设置，本申请实施例并不局限于此。

例如，在第二节点接管第一节点的服务的情况下，其它节点可更新dns，以便将dns中的第一节点的主机名所对应的ip地址修改成第二节点的ip地址。

再例如，可通过修改linux操作系统中的配置文件/etc/hosts来更新dns。

步骤s230，在第一节点恢复正常的情况下，第二节点停止之前接管的第一节点的服务，并将之前接管的资源进行释放，以便于第一节点重新接管相关资源。

具体地，如图3所示，图3示出了本申请实施例提供的一种释放资源的方法的流程图。如图3所示的方法包括：

步骤s310，在第一节点恢复正常的情况下，第一节点向第二节点发送资源释放请求。对应地，第二节点接收第一节点发送的资源释放请求。

步骤s320，第二节点根据资源释放请求，停止之前接管的第一节点的服务，并释放第一节点的资源信息对应的资源。

步骤s330，第二节点生成携带有释放完成的反馈信息。

步骤s340，第二节点向第一节点发送反馈信息。

步骤s350，第一节点重新接管资源信息对应的资源。

具体地，第一节点可将存储信息对应的存储设备挂载到本地，并重新启动(或者恢复)第一节点的服务。

此外，这里还需要说明的是，该第一节点还可执行加锁操作。以及，在加锁成功的情况下，该第一节点还可从对应的共享卷中删除第二节点写入的接管信息。以及，在从共享卷中删除了上述接管信息以后，第一节点可执行解锁操作。

步骤s360，第一节点向集群中的其它节点发送通知信息。对应地，其它节点接收第一节点发送的通知信息。

步骤s370，其它节点根据通知信息，对各自的dns进行更新。

例如，其它节点可对dns进行更新，以便将dns中的第一节点的主机名所对应的ip地址修改成第一节点的ip地址。

此外，还需要说明的是，集群中的各个正常节点均可获取自身的节点状态信息。以及，各个正常节点可向web管理系统的后台服务器发送自身的节点状态信息，以便于后台服务器监控各个节点。以及，后台服务器还可展示各个节点的节点状态信息。

应理解，节点状态信息所包含的信息可根据实际需求来进行设置，本申请实施例并不局限于此。

例如，节点状态信息可包括第二节点接管第一节点的服务，还可以包括第二节点释放了第一节点的相关资源等。

对应地，后台服务器展示的节点状态信息也可根据实际需求来进行设置，本申请实施例并不局限于此。

例如，后台服务器可展示分布式文件系统中的宕机、接管、恢复等事件。

另外，还需要说明的是，在集群中包含有n个节点的情况下，通过本申请实施的方案，其可允许n-2台节点宕机。其中，n为大于等于3的正整数。

此外，在集群包含有2个节点的情况下，其最多可允许1个节点宕机。

因此，本申请实施例通过在第一节点故障的情况下，可从系统中的正常节点中选取一个第二节点来接管第一节点的服务，从而相比于现有的为每个运行节点都配置备份节点的方案，由于本申请实施例无需再为每个节点设置备份节点，从而不仅提高了节点资源的利用率，还能够降低成本。

为了便于理解本申请实施例，下面通过具体的实施例来进行描述。

如图4所示，图4示出了本申请实施例提供的一种节点故障的处理方法的具体流程图。如图4所示的处理方法可应用于第二节点，该处理方法包括：

步骤s410，触发接管事件。

步骤s420，根据接管事件，查询本地的配置文件，以确定故障节点的卷信息以及san存储信息。

此外，这里需要说明的是，在步骤s410和步骤s420之间，第二节点可对挂载在第二节点的共享卷中的锁文件执行加锁操作。随后，在加锁成功的情况下，第二节点可查询共享卷中的接管信息文件，以获知故障节点是否已经被其它节点所接管。以及，在故障节点被其它节点接管的情况下，第二节点就不再接管此故障节点；在故障节点没有被其它故障节点接管的情况下，第二节点对锁文件执行解锁操作，并执行步骤s420。

步骤s430，根据故障节点的san存储信息，挂载san集群中的存储设备，并修改第二节点中的分布式文件系统的配置文件。

步骤s440，第二节点中的高可用模块可重启第二节点的分布式文件系统的服务，以便在第二节点上启动第一节点的服务。

步骤s450，第二节点可通知集群中的其他节点更新dns。

应理解，上述节点故障的处理方法仅是示例性的，本领域技术人员根据上述的方法可以进行各种变形，变形之后的方案也处在本申请的保护范围内。

例如，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

请参见图5，图5示出了本申请实施例提供的一种节点故障的处理装置500的结构框图，应理解，该处理装置500与上述图2至图4方法实施例中的第二节点对应，能够执行上述方法实施例中的第二节点相关的各个步骤，该处理装置500具体的功能可以参见上文中的描述，为避免重复，此处适当省略详细描述。该处理装置500包括至少一个能以软件或固件(firmware)的形式存储于存储器中或固化在处理装置500的操作系统(operatingsystem，os)中的软件功能模块。具体地，该处理装置500包括：

解析模块510，用于在确定第一节点故障的情况下，从配置文件中解析出第一节点的资源信息，其中，配置文件记录有分布式文件系统中每个节点的资源信息，第一节点的资源信息包括第一节点对应的存储设备信息和第一节点的服务；挂载启动模块520，用于根据存储设备信息，挂载存储设备信息对应的存储设备，并启动第一节点的服务。

在一个可能的实施例中，该处理装置500还包括：加锁模块(未示出)，用于对挂载在第二节点的共享卷中的锁文件执行加锁操作；写入模块(未示出)，用于在共享卷中的接管信息文件中写入接管信息，其中，接管信息为表示第二节点接管第一节点的服务的信息；解锁模块(未示出)，用于对锁文件执行解锁操作。

在一个可能的实施例中，该处理装置500还包括：接收模块(未示出)，用于在第一节点恢复正常的情况下，接收第一节点发送的资源释放请求；释放模块，用于根据资源释放请求，停止所述第一节点的服务，并释放资源信息对应的资源；生成模块(未示出)，用于生成携带有释放完成的反馈信息；第一发送模块(未示出)，用于向第一节点发送反馈信息。

在一个可能的实施例中，该处理装置500还包括：获取模块(未示出)，用于获取自身的节点状态信息，其中，节点状态信息包括第二节点接管第一节点的服务的信息；第二发送模块(未示出)，用于向后台服务器发送节点状态信息，以便于后台服务器监控第二节点。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置的具体工作过程，可以参考前述方法中的对应过程，在此不再过多赘述。

图6示出了本申请实施例提供的一种电子设备600的结构框图。如图6所示，电子设备600可以包括处理器610、通信接口620、存储器630和至少一个通信总线640。其中，通信总线640用于实现这些组件直接的连接通信。其中，本申请实施例中设备的通信接口620用于与其他节点设备进行信令或数据的通信。处理器610可以是一种集成电路芯片，具有信号的处理能力。上述的处理器610可以是通用处理器，包括中央处理器(centralprocessingunit，简称cpu)、网络处理器(networkprocessor，简称np)等；还可以是数字信号处理器(digitalsignalprocessing，简称dsp)、专用集成电路(applicationspecificintegratedcircuit，简称asic)、现场可编程逻辑门阵列(fieldprogrammablegatearray，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器610也可以是任何常规的处理器等。

存储器630可以是，但不限于，随机存取存储器(randomaccessmemory，简称ram)，只读存储器(readonlymemory，简称rom)，可编程只读存储器(programmableread-onlymemory，简称prom)，可擦除只读存储器(erasableprogrammableread-onlymemory，简称eprom)，电可擦除只读存储器(electricerasableprogrammableread-onlymemory，简称eeprom)等。存储器630中存储有计算机可读取指令，当所述计算机可读取指令由所述处理器610执行时，电子设备600可以执行方法实施例中的方法。例如，在电子设备600设置在第二节点中的情况下，存储器630中存储有计算机可读取指令，当所述计算机可读取指令由所述处理器610执行时，电子设备600可以执行上述图2至图4方法实施例中第二节点侧的各个步骤。

电子设备600还可以包括存储控制器、输入输出单元、音频单元、显示单元。

所述存储器630、存储控制器、处理器610、外设接口、输入输出单元、音频单元、显示单元各元件相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通信总线640实现电性连接。所述处理器610用于执行存储器630中存储的可执行模块，例如电子设备600包括的软件功能模块或计算机程序。

输入输出单元用于提供给用户输入数据实现用户与其他设备的交互。所述输入输出单元可以是，但不限于，鼠标和键盘等。

音频单元向用户提供音频接口，其可包括一个或多个麦克风、一个或者多个扬声器以及音频电路。

显示单元在所述电子设备与用户之间提供一个交互界面(例如用户操作界面)或用于显示图像数据给用户参考。在本实施例中，所述显示单元可以是液晶显示器或触控显示器。若为触控显示器，其可为支持单点和多点触控操作的电容式触控屏或电阻式触控屏等。支持单点和多点触控操作是指触控显示器能感应到来自该触控显示器上一个或多个位置处同时产生的触控操作，并将该感应到的触控操作交由处理器进行计算和处理。

可以理解，图6所示的结构仅为示意，所述电子设备600还可包括比图6中所示更多或者更少的组件，或者具有与图6所示不同的配置。图6中所示的各组件可以采用硬件、软件或其组合实现。

本申请提供一种存储介质，该存储介质上存储有计算机程序，该计算机程序被处理器运行时执行实施例所述的方法。

本申请还提供一种计算机程序产品，所述计算机程序产品在计算机上运行时，使得计算机执行方法实施例所述的方法。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统的具体工作过程，可以参考前述方法中的对应过程，在此不再过多赘述。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁盘、光盘或者固态硬盘等各种可以存储程序代码的介质。需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。