CN109002478A - 分布式文件***的故障处理方法及相关设备 - Google Patents

Abstract

本申请实施例公开了一种分布式文件***的故障处理方法及相关设备，该分布式文件***中包含有至少一个监控服务Mon，用于提高了故障定位的效率。本申请实施例方法包括：获取所述至少一个Mon中各个Mon的状态信息，所述状态信息用于描述Mon在运行过程中产生的各种属性信息；根据所述状态信息，判断所述各个Mon中是否存在预设故障类型的目标Mon；若存在所述预设故障类型的目标Mon，执行与所述预设故障类型对应的故障处理程序。

Description

分布式文件***的故障处理方法及相关设备

技术领域

本申请涉及文件***领域，尤其涉及一种分布式文件***的故障处理方法及相关设备。

背景技术

计算机通过文件***管理和存储数据，而信息***时代中，由于可以获取到的数据成指数倍的增长，单纯通过增加硬盘个数来扩展计算机文件***的存储容量的方式，在数据存储和管理方面的表现都差强人意。分布式文件***可以有效解决上述问题：将固定于某个地点的某个文件***，扩展到任意多个地点/多个文件***，众多的存储节点组成一个文件***网络。每个存储节点可以分布在不同的地点，通过网络进行存储节点间的通信和数据传输。

在分布式文件***中配置有监控服务(monitor，Mon)，Mon用于监控分布式文件***的状态，同时辅助维护状态的变化。Mon采用集群模式，每个存储节点上都配置有Mon，为了保证Mon无单点故障，需要保证Mon的数量为奇数,在部署2×N+1个Mon时，***最多允许N个Mon同时出现故障。

在现有技术提供的文件***中，当集群中某一Mon出现故障时，需要由现场人员向研发人员描述从故障开始的各个操作，再逐个排除导致故障的各个操作，最终经过测试复现故障状态，才能获知故障原因，上述由研发人员现场进行Mon故障定位的方式，耗费时间长，故障定位效率低下。

发明内容

本申请实施例提供了一种分布式文件***故障处理方法，用于提高故障定位的效率。

第一方面，本申请实施例提供一种分布式文件***的故障处理方法，该分布式文件***中包含有至少一个Mon，该方法包括：

获取至少一个Mon中各个Mon的状态信息，该状态信息用于描述Mon在运行过程中产生的各种属性信息；

根据该状态信息，判断该各个Mon中是否存在预设故障类型的目标Mon；

若存在预设故障类型的目标Mon，执行与该预设故障类型对应的故障处理程序。

第二方面，本申请实施例还提供一种分布式文件***，该分布式文件***中包含有至少一个Mon，该分布式文件***包括：

获取单元，用于获取该至少一个Mon中各个Mon的状态信息，该状态信息用于描述Mon在运行过程中产生的各种属性信息；

判断单元，用于根据该状态信息，判断该各个Mon中是否存在预设故障类型的目标Mon；

执行单元，用于当存在该预设故障类型的目标Mon时，执行与该预设故障类型对应的故障处理程序。

第三方面，本申请实施例提供一种服务器，所述服务器包括：处理器和存储器，所述存储器中存储有前述第一方面中所述的分布式文件***的故障处理的指令；

所述处理器用于执行存储器中存储的分布式文件***的故障处理的指令，执行如前述第一方面中所述的分布式文件***的故障处理方法的步骤。

第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有分布式文件***的故障处理的指令，当其在计算机上运行时，使得计算机执行前述第一方面中所述的分布式文件***的故障处理方法的步骤。

从以上技术方案可以看出，本申请实施例具有以下优点：

根据各个Mon的状态信息，判断各个Mon中是否存在预设故障类型的目标Mon，当存在预设故障类型的目标Mon时，则执行对应的故障处理程序。也即当Mon出现故障时，只要发生的故障为预设的故障类型，不再需要现场人员配合研发人员进行现场Mon故障定位，根据各个Mon的状态信息即可确定故障类型，提高了故障定位的效率，且在对故障定位后执行对应的故障处理程序，提高了整个故障处理过程的效率。

附图说明

图1为本申请实施例提供的分布式文件***的结构示意图；

图2为本申请实施例提供的分布式文件***的故障处理方法的一种流程示意图；

图3为本申请实施例提供的分布式文件***的故障处理方法的另一种流程示意图；

图4为本申请实施例提供的分布式文件***的故障处理方法的又一种流程示意图；

图5为本申请实施例提供的分布式文件***的故障处理方法的再一种流程示意图；

图6为本申请实施例提供的分布式文件***的故障处理方法的另一种流程示意图；

图7为本申请实施例提供的分布式文件***的故障处理方法的又一种流程示意图；

图8为本申请实施例提供的分布式文件***的一种结构示意图；

图9为本申请实施例提供的服务器的一种结构示意图。

具体实施方式

本申请实施例提供了一种分布式文件***的故障处理方法，用于提高故障定位的效率。本申请实施例还提供了相应的分布式文件***、服务器及计算机可读存储介质。以下分别进行详细说明。

如图1所示，分布式文件***由多个存储节点10组成，多个存储节点10可以分布于同一地点，也可以分布于任意多个地点，多个存储节点10之间通过网络20进行通信和数据传输。

其中，分布式文件***包括浪潮分布式存储***ICFS***、大规模分散文件***(*** file system，GFS)、集群文件***Lustre或其他分布式文件***等，在本实施例及后续实施例中，仅以分布式文件***为ICFS***为例进行说明。

网络20可以是有线网络或无线网络，无线网络可以是WAN(广域网)、无线网络、点对点网络、星形网络、令牌环网络或其它无线网络等，在本申请实施例中不受限制。

为了监控分布式文件***的状态，每个存储节点10上均配置有Mon，也即与每个存储节点10对应有Mon节点，各个Mon之间能够进行通信连接，形成一个Mon集群。该各个Mon用于监控***的各个存储节点10提供的数据服务和元数据服务(MetaDataService，MDS)状态是否正常。

下面对本申请中的分布式文件***的故障处理方法进行详细描述，请参阅图2，本申请实施例提供的一种分布式文件***的故障处理方法实施例包括：

201、服务器获取该至少一个Mon中各个Mon的状态信息。

本实施例中，由于分布式文件***中包含有至少一个Mon，在该至少一个Mon中各个Mon运行过程中，会产生各种属性信息。该分布式文件***的服务器预存有各个Mon的状态信息，该状态信息用于描述Mon在运行过程中产生的上述各种属性信息。

其中，Mon的状态信息可以包括健康状态信息，例如时钟迟延；也可以包括运行状态信息，例如运行状态为活跃up或者停止down；还可以包括存储状态信息，例如存储装置的剩余空间、存储位置，还可以包括其他类型的状态信息等，具体此处不再一一赘述。

本实施例中，服务器可根据接收到的指令，获取该各个Mon的状态信息，作为示例，例如当服务器接收到icfs mon dump指令时，获取预存的各个Mon的状态信息，以检测各个Mon的运行状态；服务器也可根据接收到的其他指令获取各个Mon的状态信息，具体此处不做限定。

服务器也可以根据服务器的设定，获取该各个Mon的状态信息，作为示例，例如每隔固定时长获取一次Mon的状态信息，例如每隔24小时获取一次；作为另一示例，例如在固定的时间点获取，例如每天早上8点获取各个Mon的状态信息等，应当理解，此处对触发服务器获取各个Mon的状态信息的举例仅为方便理解本方案，具体实现方式应结合实际需求灵活设定。

202、服务器根据该状态信息，判断该各个Mon中是否存在预设故障类型的目标Mon，若存在预设故障类型的该目标Mon，进入步骤203；若不存在预设故障类型的该目标Mon，进入步骤204。

本实施例中，服务器中预先设定有与预设故障类型对应的故障判断条件，服务器在获取到各个Mon的状态信息后，依次判断该各个Mon的状态信息是否满足预设的故障判断条件，当目标Mon的状态信息满足预设的故障判断条件时，确定目标Mon存在对应的故障。

其中，预设故障类型包括时钟漂移、Mon震荡、Mon停止、Mon所在存储装置的空间不足或者其他类型Mon故障等，具体此处不做限定。

故障判断条件可以为时钟迟延是否超过预设阈值、预设时长内运行状态切换次数是否超过预设阈值或者其他故障判断条件等，具体此处不做限定。

203、服务器执行与该预设故障类型对应的故障处理程序。

本实施例中，服务器中预先设定有与预设故障类型对应的故障处理程序，当服务器确定存在预设故障类型的目标Mon时，也即确定了Mon的故障类型，服务器执行与该故障类型对应的故障处理程序。

204、服务器执行其他程序。

本实施例中，根据各个Mon的状态信息，判断各个Mon中是否存在预设故障类型的目标Mon，当存在预设故障类型的目标Mon时，则执行对应的故障处理程序。也即当Mon出现故障时，只要发生的故障为预设的故障类型，不再需要现场人员配合研发人员进行现场Mon故障定位，根据各个Mon的状态信息即可确定故障类型，提高了故障定位的效率，且在对故障定位后执行对应的故障处理程序，提高了整个故障处理过程的效率。

Mon可能存在不同类型的预设故障，而不同的故障类型对应不同的判断条件，且不同的故障类型对应不同的故障处理程序，基于不同类型的Mon故障，下面分别进行说明：

一、时钟漂移

当分布式文件***中各个Mon的时钟不同步时，会出现时钟漂移的现象，具体参阅图3，本申请实施例中，分布式文件***的故障处理方法的一个实施例包括：

301、服务器获取该至少一个Mon中各个Mon的状态信息。

本实施例中，步骤301与前述图2所示实施例中步骤201类似，此处不再赘述。

302、服务器判断该各个Mon中是否存在该时钟迟延超过预设阈值的该第一Mon，若存在，进入步骤303；若不存在，进入步骤306。

本实施例中，预设的故障类型为时钟漂移，与时钟漂移对应的判断条件为判断Mon的时钟迟延是够超过预设阈值，其中，时钟迟延的预设阈值可以为0.05秒，也可以为0.04秒，还可以为0.06秒等，在本实施例及后续实施例中，仅以时钟迟延的预设阈值为0.05秒为例进行说明。

服务器在获取到各个Mon的状态信息中包含的时钟迟延后，逐个判断每个Mon的时钟迟延是否超过了0.05秒。

303、服务器确定存在该时钟漂移的该第一Mon。

本实施例中，当服务器检测到存在时钟迟延超过0.05秒的第一Mon时，则确定该第一Mon存在时钟漂移的故障，作为示例，例如ICFS health(ICFS的健康状态信息)输出mon.caddr 10.10.0.1:6789/0clock skew 0.08235s>max 0.05s时，代表地址为10.10.0.1的mon.c的时钟有0.08235s的延迟，存在时钟漂移的故障，在上述示例中，第一Mon为地址为10.10.0.1的mon.c。应当理解，上述示例仅为方便理解本方案，对输出指令、第一Mon等信息的选择，此处不做限定。

304、服务器关闭该第一Mon所在的该分布式文件***的防火墙。

本实施例中，如果分布式文件***的防火墙打开，会影响各个存储节点之间的通 信，所以在对各个Mon设置时钟同步之前，需要检查并关闭防火墙。可以通过输入iptables– list指令的形式来检测防火墙是否已经打开，例如返回的信息为reject-with icmp-host- prohibited时，证明防火墙处于开启状态，则查看防火墙规则配置，并关闭防火墙。

305、服务器对该各个Mon设置时钟同步。

本实施例中，服务器可以通过重新启动网络时间协议(network time protocol，NTP)服务器的方式重新执行时钟同步操作，以对Mon设置时钟同步。

服务器也可以使用crontab(定时执行任务)指令来设置时钟同步，作为示例，例如需要每分钟同步一次，则在输入crontab-e后，在编辑框中输入*****/usr/sbin/ntpdate210.72.145.44。

应当理解，服务器还可以通过其他方式对该各个Mon设置时钟同步，此处不再一一赘述。

306、服务器执行其他程序。

本实施例中，可根据Mon的状态信息检测到各个Mon中是否时钟漂移的故障，由于当时钟不同步时，会导致各个Mon之间通信阻塞，本方案在检测到存在时钟漂移的第一Mon后，关闭防火墙并对各个Mon设置时钟同步，以保障各个Mon的正常运行。

二、Mon震荡

当Mon发生震荡时会使得***监控服务进程僵死，具体表现为Mon的运行状态不停的切换，具体参阅图4，本申请实施例中，分布式文件***的故障处理方法的另一个实施例包括：

401、服务器获取该至少一个Mon中各个Mon的状态信息。

本实施例中，步骤401与前述图2所示实施例中步骤201类似，此处不再赘述。

402、在预设时长内，服务器判断该各个Mon中是否存在该运行状态的切换次数超过预设阈值的该第二Mon，若存在，进入步骤403；若不存在，进入步骤406。

本实施例中，Mon的状态信息包括Mon的运行状态，预设的故障类型为Mon震荡，与Mon震荡对应的判断条件为判断预设时长内Mon运行状态的切换次数是否超过预设阈值。

其中，预设时长可以为10秒、30秒或60秒等，Mon运行状态的切换一次可以为Mon的运行状态由down切换为up，也可以为Mon的运行状态由up切换为down等，切换次数的预设阈值可以为20次、30次等，应当理解，此处举例，仅为方便理解本方案，具体对时长、运行状态的切换或切换次数的阈值的设定，此处不做限定。

403、服务器确定存在该Mon震荡的该第二Mon。

本实施例中，当服务器在预设时长内，检测到存在运行状态的切换次数超过预设阈值的第二Mon时，则确定该各个Mon中存在有Mon震荡故障的第二Mon，作为示例，例如当服务器在30秒内，检测到存在运行状态切换次数超过30次的目标Mon，则确定该目标Mon为有Mon震荡的第二Mon。

404、服务器将与该第二Mon对应的部署目录修改为与第一固态硬盘对应的部署目录。

本实施例中，部署目录指对分布式文件***中数据的物理存储位置进行统计后形成的逻辑上的目录，可通过部署目录确定数据的物理存储位置。

本实施例中，服务器可以通过systemctl stop icfs-mon@*的指令使所有Mon处于停止服务状态，在确定第二Mon后，获取与第二Mon节点对应的第一固态硬盘的部署目录，并将第二Mon的部署目录修改为该第一固态硬盘的部署目录，其中，服务器可以通过执行修改脚本./monmodify的方式完成配置文件icfs.conf中对第二Mon的部署目录的修改。

405、服务器修改该第二Mon的心跳检测频率。

本实施例中，服务器可以通过调整Mon与MDS的通信参数，以修改心跳检测频率，具体为修改Mon的配置文件icfs.conf中MDS的心跳检测时间，并修改MDS的配置文件icfs.conf中的MDS心跳发送时间，作为示例，例如将MDS的心跳检测时间设置为mds_beacon_grace＝100，即100秒检测一次MDS的心跳，将MDS的心跳发送时间设置为mds_beacon_interval＝20，即MDS每隔20秒发送一次心跳。应当理解，此处举例仅为方便理解本方案，具体对心跳检测时间、心跳发送时间设定的选择，应结合实际情侣灵活设定，此处不做限定。

本实施例中，在修改该第二Mon的心跳检测频率之后，服务器重启各个Mon的服务。

406、服务器执行其他程序。

本实施例中，根据各个Mon的状态信息，检测到存在Mon震荡的第二Mon时，将该第二Mon的数据移动到固态硬盘中，并修改Mon与MDS之间的心跳检测频率，由于Mon发生震荡时，Mon的运行状态在down和up之间反复切换，从而导致***的监控服务进程僵死，本方案中可及时解决Mon震荡的故障，从而提高***监控服务的稳定性。

三、Mon停止

当某一Mon发生Mon停止的故障时，会导致该Mon所在节点的操作***的监控服务停止，进而影响到各个Mon的正常通信，从而导致各个Mon节点之间存储的数据不一致。具体参阅图5，本申请实施例中，分布式文件***的故障处理方法的又一个实施例包括：

501、服务器获取该至少一个Mon中各个Mon的状态信息。

本实施例中，步骤501与前述图2所示实施例中步骤201类似，此处不再赘述。

502、服务器判断该各个Mon中是否存在该运行状态为停止的时长超过预设阈值的该第三Mon，若存在，进入步骤503；若不存在，进入步骤509。

本实施例中，Mon的状态信息包括Mon的运行状态，预设的故障类型为Mon停止，与Mon停止对应的判断条件为判断Mon运行状态为down的时长是否超过预设阈值。其中，时长的预设阈值可以为10秒、15秒、20秒等，具体此处不做限定。

503、服务器确定存在该Mon停止的该第三Mon。

本实施例中，当服务器检测到存在运行状态为down的时长超过预设阈值的目标Mon时，则确定该目标Mon为有Mon停止的第三Mon，作为示例，例如当服务器检测到存在运行状态为down的时长超过10秒的目标Mon时，则确定该目标Mon为有Mon停止的第三Mon。

504、服务器获取该第三Mon监控的存储节点。

本实施例中，服务器在确定该第三Mon后，确定该第三Mon监控的存储节点。

505、服务器删除该第三Mon。

本实施例中，由于配置文件icfs.conf的配置项中Mon节点配置信息和节点的网络配置信息中均包含有对第三Mon的配置信息，在删除该第三Mon时，服务器需要删除与该第三Mon关联的配置信息和第三Mon的数据。

为了删除与该第三Mon关联的配置信息，服务器需要修改配置文件icfs.conf配置项，删除mon_host、mon_initial_members中关于的Mon节点配置信息和节点的网络配置信息中关于第三Mon的配置，并执行icfs-deploy mon destroy inspur01指令以减少Mon节点数量。

由于无论是是分布式文件***中没有固态硬盘，第三Mon节点的数据直接部署在默认目录下，还是分布式文件***中存在固态硬盘，第三Mon节点的数据部署在固态硬盘上，第三Mon的挂载目录均为/var/lib/icfs/mon/，所以在删除第三Mon的数据时，需要删除节点inspur04上的/var/lib/icfs/mon目录下第三Mon的数据。

应当理解，上述举例中对部署目录的描述仅为方便理解本方案，具体部署目录的设定可根据是实际情况灵活设定，此处不做限定。

506、服务器在该存储节点上添加新的Mon。

本实施例中，服务器添加新的Mon时，需要建立新的Mon的地址与服务器中该新的Mon的主机名称的对应关系，并修改配置文件icfs.conf的配置项中Mon节点配置信息和节点的网络配置信息，作为示例，例如在所有Mon节点上添加新的Mon的IP地址与该新的Mon的主机名称的对应关系，并将该对应关系添加至/etc/hosts文件下，并修改配置文件icfs.conf中配置项信息，也即在mon_host、mon_initial_members中添加该新的Mon节点和新的Mon节点的网络配置信息并执行指令以增加Mon节点数量。

507、服务器将与该新的Mon对应的部署目录由该第二固态硬盘的部署目录修改为默认部署目录。

本实施例中，当第三Mon的数据部署在与固态硬盘对应的目录，而不是默认目录时，作为示例，例如第三Mon的部署目录是/var/lib/icfs/osd/icfs-x，而不是默认目录/var/lib/icfs/mon/时，在增加新的Mon后，需要进行Mon数据迁移。

服务器进行Mon数据迁移需要停止新的Mon节点上的Mon服务，作为示例，例如服务器通过执行systemctl stop icfs-mon.target指令停止节点上的服务，进一步的还可以通过ps-ef|grep icfs-mon.target指令检查新的Mon是否还有进程在运行，若无进程，则说明新的Mon服务已经停止。

在确定新的Mon节点上的Mon服务停止后，可以进行Mon目录拷贝工作，作为示例，例如获取新的Mon节点所存储的第二固态硬盘的部署目录，并将新的Mon的部署目录由该第二固态硬盘的部署目录修改为默认部署目录，并修改配置文件icfs.conf，在其中添加对新的Mon节点的部署目录的说明。

应当理解，上述示例中仅为方便理解本方案，具体对目录、指令的描述需结合实际情况灵活设定，此处不做限定。

508、服务器启动该新的Mon。

本实施例中，步骤507为可选步骤，若第三Mon的数据部署在默认目录下时，在执行步骤506后可直接执行步骤508；若第三Mon的数据部署在固态硬盘对应的部署目录下时，则需要执行步骤508。

509、服务器执行其他程序。

本实施例中，根据各个Mon的状态信息，检测到存在Mon停止的第三Mon时，删除该第三Mon，并建立新的Mon以及时替代第三Mon提供监控服务，从而保证各个Mon提供监控服务的连续性。

四、Mon所在存储装置的空间不足

当Mon所在存储装置的空间不足时，会出现Mon退出从而无法提供服务的情况。具体参阅图6，本申请实施例中，分布式文件***的故障处理方法的又一个实施例包括：

601、服务器获取该至少一个Mon中各个Mon的状态信息。

本实施例中，步骤601与前述图2所示实施例中步骤201类似，此处不再赘述。

602、服务器判断该各个Mon中是否存在该存储装置的剩余空间低于预设阈值的该第四Mon，若存在，进入步骤603；若不存在，进入步骤606。

本实施例中，Mon的状态信息包括Mon所在存储装置的剩余空间，预设的故障类型为Mon所在存储装置的空间不足，与Mon所在存储装置的空间不足对应的判断条件为判断Mon所在存储装置的剩余空间是否低于预设阈值。

603、服务器确定该第四Mon所在存储装置的空间不足。

本实施例中，当服务器判断存在所在存储装置的剩余空间低于预设阈值的目标Mon时，确定该目标Mon为有存储装置的空间不足故障的第四Mon。

604、服务器获取该第四Mon所在存储装置中存储的临时文件。

本实施例中，服务器在确定第四Mon后，通过配置文件中该第四Mon的部署目录确定该第四Mon所在硬盘，并查看该硬盘空间占用情况，并删除该硬盘中存储的临时文件。

其中，可以通过输入du-sh*指令的方式查看硬盘空间的使用情况，可以根据文件的名称来区分是否为临时文件。

605、服务器删除该临时文件。

本实施例中，服务器在确定第四Mon所在存储位置中存储的临时文件后，删除该临时文件，并重新启动该第四Mon。

606、服务器执行其他程序。

本实施例中，根据各个Mon的状态信息，检测到所在存储装置的空间不足的第四Mon时，确定该第四Mon所在的硬盘，删除该硬盘中存储的临时文件，从而保证各个Mon提供监控服务的连续性。

应当理解，上述图3、图4、图5和图6分别对应Mon的不同类型的故障，在分布式文件***中，可以同时设置上述四种类型的故障，例如，预设的故障类型同时包括时钟漂移、Mon震荡、Mon停止和Mon所在存储装置的空间不足；也可以是上述四种类型故障的任意组合，例如，预设的故障类型为时钟漂移和Mon震荡，预设的故障类型为Mon震荡和Mon停止，预设的故障类型为时钟漂移、Mon震荡和Mon停止等，此处不再一一列举。

以下结合图7，对预设的故障类型同时包括时钟漂移、Mon震荡、Mon停止和Mon所在存储装置的空间不足的情形进行详细描述，本申请实施例提供的又一种分布式文件***的故障处理方法实施例包括：

701、服务器获取该至少一个Mon中各个Mon的状态信息。

本实施例中，步骤701与前述图2所示实施例中步骤201类似，此处不再赘述。

702、服务器判断该各个Mon中是否存在该时钟迟延超过预设阈值的该第一Mon，若存在，进入步骤703；若不存在，进入步骤706。

703、服务器确定存在该时钟漂移的该第一Mon。

704、服务器关闭该第一Mon所在的该分布式文件***的防火墙。

705、服务器对该各个Mon设置时钟同步。

本实施例中，步骤702至705与前述图3中步骤302至305类似，此处不再赘述。

706、服务器在预设时长内，判断该各个Mon中是否存在该运行状态的切换次数超过预设阈值的该第二Mon，若存在，进入步骤707；若不存在，进入步骤710。

707、服务器确定存在该Mon震荡的该第二Mon。

708、服务器将与该第二Mon对应的部署目录修改为与第一固态硬盘对应的部署目录。

709、服务器修改该第二Mon的心跳检测频率。

本实施例中，步骤706至709与前述图4中步骤402至405类似，此处不再赘述。

710、服务器判断该各个Mon中是否存在该运行状态为停止的时长超过预设阈值的该第三Mon，若存在，进入步骤711；若不存在，进入步骤717。

711、服务器确定存在该Mon停止的该第三Mon。

712、服务器获取该第三Mon监控的存储节点。

713、服务器删除该第三Mon。

714、服务器在该存储节点上添加新的Mon。

715、服务器将与该新的Mon对应的部署目录由该第二固态硬盘的部署目录修改为默认部署目录。

716、服务器启动该新的Mon。

本实施例中，步骤710至716与前述图5中步骤502至508类似，此处不再赘述。

717、服务器判断该各个Mon中是否存在该存储装置的剩余空间低于预设阈值的该第四Mon，若存在，进入步骤718；若不存在，且存在故障Mon，进入步骤721。

718、服务器确定该第四Mon所在存储装置的空间不足。

719、服务器获取该第四Mon所在存储装置中存储的临时文件。

720、服务器删除该临时文件。

本实施例中，步骤717至720与前述图6中步骤602至605类似，此处不再赘述。

721、服务器输出该分布式文件***的***日志。

本实施例中，当服务器确定不存在预设故障类型的目标Mon，且存在故障Mon时，获取该分布式文件***的***日志并输出。

本实施例中，当服务器检测到存在故障Mon，但不是预设的故障类型时，服务器输出该分布式文件***的***日志，研发人员可根据***日志进行检测以定位故障原因，不再需要由现场人员向研发人员描述从故障开始的各个操作，再根据描述反复测试以复现故障状态，从而提高了Mon故障定位的效率。

图8是本发明实施例提供的分布式文件***的一种结构示意图，该分布式文件***中包含有至少一个监控服务Mon，该分布式文件***包括：

获取单元801，用于获取该至少一个Mon中各个Mon的状态信息，该状态信息用于描述Mon在运行过程中产生的各种属性信息；

判断单元802，用于根据该状态信息，判断该各个Mon中是否存在预设故障类型的目标Mon；

执行单元803，用于当存在预设故障类型的该目标Mon时，执行与该预设故障类型对应的故障处理程序。

进一步的，该状态信息包括时钟迟延，该预设故障类型包括时钟漂移，该目标Mon包括第一Mon，该判断单元802包括：

第一判断子单元8021，用于判断该各个Mon中是否存在该时钟迟延超过预设阈值的该第一Mon；

第一确定子单元8022，用于当存在时，确定存在该时钟漂移的该第一Mon；

该执行单元803包括：

关闭子单元8031，用于关闭该第一Mon所在的该分布式文件***的防火墙；

同步子单元8032，用于对该各个Mon设置时钟同步。

进一步的，该状态信息包括运行状态，该故障类型包括Mon震荡，该目标Mon包括第二Mon，该判断单元802包括：

第二判断子单元8023，用于在预设时长内，判断该各个Mon中是否存在该运行状态的切换次数超过预设阈值的该第二Mon；

第二确定子单元8024，用于当存在时，确定存在该Mon震荡的该第二Mon；

该执行单元803包括：

第一修改子单元8033，用于将与该第二Mon对应的部署目录修改为与第一固态硬盘对应的部署目录；

第二修改子单元8034，用于修改该第二Mon的心跳检测频率。

进一步的，该状态信息包括运行状态，该故障类型包括Mon停止，该目标Mon包括第三Mon，该判断单元802包括：

第三判断子单元8025，用于判断该各个Mon中是否存在该运行状态为停止的时长超过预设阈值的该第三Mon；

第三确定子单元8026，用于当存在时，确定存在该Mon停止的该第三Mon；

该执行单元803包括：

第一获取子单元8035，用于获取该第三Mon监控的存储节点；

第一删除子单元8036，用于删除该第三Mon；

添加子单元8037，用于在该存储节点上添加新的Mon；

启动子单元8038，用于启动该新的Mon。

进一步的，与该第三Mon的存储节点对应的存储装置为第二固态硬盘，该执行单元803还包括：

第三修改子单元8039，用于将与该新的Mon对应的部署目录由该第二固态硬盘的部署目录修改为默认部署目录。

进一步的，该状态信息包括存储装置的剩余空间，该故障类型包括Mon所在存储装置的空间不足，该目标Mon包括第四Mon，该判断单元802包括：

第四判断子单元8027，用于判断该各个Mon中是否存在该存储装置的剩余空间低于预设阈值的该第四Mon；

第四确定子单元8028，用于当存在时，确定该第四Mon所在存储装置的空间不足；

该执行单元803包括：

第二获取子单元80310，用于获取该第四Mon所在存储装置中存储的临时文件；

第二删除子单元80311，用于删除该临时文件。

进一步的，该分布式文件***还包括：

输出单元804，用于当不存在该预设故障类型的目标Mon，且存在故障Mon时，输出与该故障Mon关联的***日志，该***日志为该分布式文件***的日志。

本实施例中，分布式文件***中各单元执行的流程与前述图2至图7所示实施例中服务器所执行的流程类似，此处不再赘述。

本实施例中，根据获取单元801获取的各个Mon的状态信息，判断单元802判断各个Mon中是否存在预设故障类型的目标Mon，当存在预设故障类型的目标Mon时，执行单元803执行对应的故障处理程序。也即当Mon出现故障时，只要发生的故障为预设的故障类型，不再需要现场人员配合研发人员进行现场Mon故障定位，根据各个Mon的状态信息即可确定故障类型，提高了故障定位的效率，且在对故障定位后执行对应的故障处理程序，提高了整个故障处理过程的效率。

本申请实施例中还提供一种服务器，参见图9，该服务器900可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器901和存储器902(例如一个或一个以上海量存储设备)。其中，存储器902可以是短暂存储或持久存储。存储在存储器902上的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，处理器901可以设置为与存储器902通信，在服务器900上执行存储器902中的一系列指令操作。

服务器900还可以包括一个或一个以上输入输出单元903，一个或一个以上电源904，一个或一个以上有线或无线网络接口905。

在本发明的一些实施例中，处理器901、存储器902、输入输出单元903、电源904和有线或无线网络接口905可通过总线或其它方式连接，图9中以通过总线连接为例。

该存储器中存储有前述图2至图7所示实施例中描述的分布式文件***的故障处理的指令；

该处理器用于执行存储器中存储的分布式文件***的故障处理的指令，执行如前述图2至图7所示实施例中描述的分布式文件***的故障处理方法的步骤。

本申请实施例中还提供一种计算机可读存储介质，该计算机可读存储介质中存储有分布式文件***的故障处理的指令，当其在计算机上运行时，使得计算机执行如前述图2至图7所示实施例中描述的分布式文件***的故障处理方法的步骤。

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

在本申请所提供的几个实施例中，应该理解到，所揭露的***，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (10)

1.一种分布式文件***的故障处理方法，其特征在于，所述分布式文件***中包含有至少一个监控服务Mon，所述方法包括：

获取所述至少一个Mon中各个Mon的状态信息，所述状态信息用于描述Mon在运行过程中产生的各种属性信息；

根据所述状态信息，判断所述各个Mon中是否存在预设故障类型的目标Mon；

若存在所述预设故障类型的目标Mon，执行与所述预设故障类型对应的故障处理程序。

2.根据权利要求1所述的方法，其特征在于，所述状态信息包括时钟迟延，所述预设故障类型包括时钟漂移，所述目标Mon包括第一Mon，

所述判断所述各个Mon中是否存在预设故障类型的目标Mon包括：

判断所述各个Mon中是否存在所述时钟迟延超过预设阈值的所述第一Mon；

若存在，则确定存在所述时钟漂移的所述第一Mon；

所述执行与所述预设故障类型对应的故障处理程序包括：

关闭所述第一Mon所在的所述分布式文件***的防火墙；

对所述各个Mon设置时钟同步。

3.根据权利要求1所述的方法，其特征在于，所述状态信息包括运行状态，所述故障类型包括Mon震荡，所述目标Mon包括第二Mon，

所述判断所述各个Mon中是否存在预设故障类型的目标Mon包括：

在预设时长内，判断所述各个Mon中是否存在所述运行状态的切换次数超过预设阈值的所述第二Mon；

若存在，则确定存在所述Mon震荡的所述第二Mon；

所述执行与所述预设故障类型对应的故障处理程序包括：

将与所述第二Mon对应的部署目录修改为与第一固态硬盘对应的部署目录；

修改所述第二Mon的心跳检测频率。

4.根据权利要求1所述的方法，其特征在于，所述状态信息包括运行状态，所述故障类型包括Mon停止，所述目标Mon包括第三Mon，

所述判断所述各个Mon中是否存在预设故障类型的目标Mon包括：

判断所述各个Mon中是否存在所述运行状态为停止的时长超过预设阈值的所述第三Mon；

若存在，则确定存在所述Mon停止的所述第三Mon；

所述执行与所述预设故障类型对应的故障处理程序包括：

获取所述第三Mon监控的存储节点；

删除所述第三Mon；

在所述存储节点上添加新的Mon；

启动所述新的Mon。

5.根据权利要求4所述的方法，其特征在于，与所述第三Mon的存储节点对应的存储装置为第二固态硬盘，

在所述启动所述新的Mon之前，所述方法还包括：

将与所述新的Mon对应的部署目录由所述第二固态硬盘的部署目录修改为默认部署目录。

6.根据权利要求1所述的方法，其特征在于，所述状态信息包括存储装置的剩余空间，所述故障类型包括Mon所在存储装置的空间不足，所述目标Mon包括第四Mon，

所述判断所述各个Mon中是否存在预设故障类型的目标Mon包括：

判断所述各个Mon中是否存在所述存储装置的剩余空间低于预设阈值的所述第四Mon；

若存在，则确定所述第四Mon所在存储装置的空间不足；

所述执行与所述预设故障类型对应的故障处理程序包括：

获取所述第四Mon所在存储装置中存储的临时文件；

删除所述临时文件。

7.根据权利要求1至6任一权利要求所述的方法，其特征在于，所述方法还包括：

若不存在所述预设故障类型的目标Mon，且存在故障Mon，输出所述分布式文件***的***日志。

8.一种分布式文件***，其特征在于，所述分布式文件***中包含有至少一个监控服务Mon，所述分布式文件***包括：

获取单元，用于获取所述至少一个Mon中各个Mon的状态信息，所述状态信息用于描述Mon在运行过程中产生的各种属性信息；

判断单元，用于根据所述状态信息，判断所述各个Mon中是否存在预设故障类型的目标Mon；

执行单元，用于当存在预设故障类型的所述目标Mon时，执行与所述预设故障类型对应的故障处理程序。

9.一种服务器，其特征在于，所述服务器包括：处理器和存储器，所述存储器中存储有权利要求1-7任一所述的分布式文件***的故障处理的指令；

所述处理器用于执行存储器中存储的分布式文件***的故障处理的指令，执行如权利要求1-7任一所述的分布式文件***的故障处理方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有分布式文件***的故障处理的指令，当其在计算机上运行时，使得计算机执行上述权利要求1-7任一所述的方法。