一种存储单元的启动前校验方法及装置与流程

文档序号:16467877发布日期:2019-01-02 22:53阅读:152来源:国知局
一种存储单元的启动前校验方法及装置与流程

本申请涉及计算机技术领域,尤其涉及一种存储单元的启动前校验方法及装置。



背景技术:

目前,在一个服务器上会存在多个存储单元,且每个存储单元会对应挂载一个物理盘,现有的存储单元的启动方式一般包括udev和systemd两种方式。其中,udev规则会先挂载物理盘,再启动存储单元主进程;而systemd既可以先挂载物理盘,再启动存储单元主进程,又可以直接启动存储单元主进程。

由于每个存储单元使用的物理盘的容量不同,所以,每个存储单元的存储能力也各不相同,比如1t和2t的盘,权重可能是0.5和1,存储单元权重与物理盘容量成正比。

服务器在部署存储单元时,会将自己的存储单元权重上报给监控模块,这就出现一个问题,若物理盘没有挂载而直接启动了存储单元主进程,会导致进程启动失败,并且在部署时会将错误的权重上报给监控模块,从而导致服务器系统异常。



技术实现要素:

本申请实施例的主要目的在于提供一种存储单元的启动前校验方法及装置,能够保证存储单元的主进程正常启动。

本申请实施例提供的一种存储单元的启动前校验方法,包括:

在所述存储单元的主进程启动之前,判断挂载目录与所述挂载目录的父目录是否具有同一设备号,其中,所述挂载目录为所述存储单元对应的物理盘所挂载的目录;

若否,则启动所述存储单元的主进程;

若是,则进行异常处理。

可选的,所述进行异常处理,包括:

检测当前场景是否属于所述存储单元的部署场景;

若是,则不再上报所述存储单元的权重值。

可选的,所述检测当前场景是否属于所述存储单元的部署场景之后,包括:

通过正常退出命令,停止尝试重启所述存储单元的主进程。

可选的,所述正常退出命令为stop命令。

可选的,所述停止尝试重启所述存储单元的主进程之后,还包括:

将重启所述存储单元的主进程的失败次数清零。

本申请实施例还提供了一种存储单元的启动前校验装置,包括:

设备号对比单元,用于在所述存储单元的主进程启动之前,判断挂载目录与所述挂载目录的父目录是否具有同一设备号,其中,所述挂载目录为所述存储单元对应的物理盘所挂载的目录;

正常处理单元,用于若挂载目录与所述挂载目录的父目录不具有同一设备号,则启动所述存储单元的主进程;

异常处理单元,用于若挂载目录与所述挂载目录的父目录具有同一设备号,则进行异常处理。

可选的,所述异常处理单元包括:

检测子单元,用于检测当前场景是否属于所述存储单元的部署场景;

上报子单元,用于若当前场景属于所述存储单元的部署场景,则不再上报所述存储单元的权重值。

可选的,所述异常处理单元还包括:

退出子单元,用于在所述检测子单元检测到当前场景属于所述存储单元的部署场景之后,通过正常退出命令,停止尝试重启所述存储单元的主进程。

可选的,所述正常退出命令为stop命令。

可选的,所述异常处理单元还包括:

清零子单元,用于在所述退出子单元停止尝试重启所述存储单元的主进程之后,将重启所述存储单元的主进程的失败次数清零。

本申请实施例提供的存储单元的启动前校验方法及装置,在所述存储单元的主进程启动之前,判断挂载目录与所述挂载目录的父目录是否具有同一设备号,其中,所述挂载目录为所述存储单元对应的物理盘所挂载的目录;若否,则启动所述存储单元的主进程;若是,则进行异常处理。本申请实施例在启动存储单元的主进程之前,对存储单元对应的物理盘是否挂载进行提前检测,当检测到挂载目录与所述挂载目录的父目录具有同一设备号时,则可确定未挂载物理盘,在此种情形下,将无法成功启动存储单元的主进程,所以可不启动存储单元的主进程,而是走异常处理程序,从而降低了服务器运行资源的浪费。

进一步地,在非异常情形下,即物理盘已挂载且当前场景属于所述存储单元的部署场景,需要将所述存储单元的正确权重上报监控模块;在进行异常处理时,若当前场景属于所述存储单元的部署场景,则不再上报所述存储单元的权重值,该步骤可以防止因为未挂载物理盘导致的向监控模块上报错误权重的风险。其次,通过正常退出命令,停止尝试重启所述存储单元的主进程,该步骤停止了启动存储单元主进程,避免了systemd后续不必要的启动主进程的尝试。最后,将重启所述存储单元的主进程的失败次数清零,该步骤可在在挂载物理盘时,第一时间启动存储单元主进程,加快主进程的启动速度。可见,通过这些优化,可以优化异常处理流程,避免了不必要的尝试,并保证了异常情况解决后以最快速度恢复系统,减少了不必要的时间损耗,提高了服务器系统的运行性能。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种存储单元的启动前校验方法的流程示意图;

图2为本申请实施例提供的一种挂载物理盘前后的挂载目录和挂载目录的父目录示意图;

图3为本申请实施例提供的一种异常处理流程图;

图4为本申请实施例提供的一种systemd监控进程示意图;

图5为本申请实施例提供的一种存储单元的启动前校验方法的组成示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。

为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对本申请实施例或现有技术描述中所涉及的关键术语作简单地介绍。

udev:udev是linuxkernel2.6系列的设备管理器。它主要的功能是管理/dev目录底下的设备节点。它的工作原理是当系统启动时如果一个新设备连接被kernel监测到,会根据配置的规则(rules)进行相应的处理。而存储单元配置的规则是当检测到存储单元的挂载盘时,会将挂载盘挂载到对应存储单元的目录上,然后再启动该存储单元主进程。并且处理该设备时会将设备加锁(lock),然后再进行后续操作,其中,多个设备共用一个锁。

systemd:systemd是linux下的一种init软件,由lennartpoettering带头开发,并在lgpl2.1及其后续版本许可证下开源发布。它的工作原理是通过配置不同的service和target组合(target相当于多个service的集合),target直接可以相互依赖和关联,启动target就会依次启动target包含的所有service。

物理盘:物理盘是用于实际存储的硬盘,如stat硬盘、sas硬盘、ssd固态硬盘等。

存储单元权重:因为每个存储单元使用的物理盘的容量不同,所以每个存储单元在分布式文件系统的存储能力也各不相同。存储单元权重与存储单元使用的物理盘容量成正比。比如1t的物理盘和2t的物理盘,权重可能是0.5和1。

目前,在一个服务器上会存在多个存储单元,且每个存储单元会对应挂载一个物理盘,现有的存储单元的启动方式一般包括udev和systemd两种方式。

其中,udev方式的规则是先挂载物理盘,再启动存储单元主进程。而systemd方式的规则既可以先挂载物理盘,再启动存储单元主进程;又可以直接启动存储单元主进程。其中,服务器的存储单元实际上是对应物理盘的存储单元。而在存储单元主进程的实际启动进程中,这两种规则都有可能发生没有挂载物理盘而直接启动存储单元主进程的情况,如果发生这种情况将会导致进程启动失败,并且在部署时会将错误的权重上报给监控模块,从而导致系统异常。

为解决上述缺陷,本申请实施例提供了一种存储单元的启动前校验方法,可以在存储单元主进程启动之前,检测存储单元对应的物理盘是否被挂载,在出现未挂载的异常情况下,对该异常情况进行处理,避免了不必要的启动尝试,并可以在异常情况解决后,能够最快的恢复系统,减少了不必要的时间损耗,提高了系统的运行性能。

参见图1,为本申请实施例提供的一种存储单元的启动前校验方法的流程示意图,包括以下步骤s101-s103:

s101:在所述存储单元的主进程启动之前,判断挂载目录与所述挂载目录的父目录是否具有同一设备号,其中,所述挂载目录为所述存储单元对应的物理盘所挂载的目录;若否,则执行s102;若是,则执行步骤s103。

在本实施例中,只有当物理盘被挂载上时,才可以按照正常步骤启动存储单元的主进程,否则会导致启动失败。因此,在存储单元的主进程启动之前,需要判断是否已挂载物理盘,判断的方法是:判断挂载目录与所述挂载目录的父目录是否具有同一设备号,若不具有同一设备号,则说明已挂载上物理盘;若具有同一设备号,则说明未挂载上物理盘。

其中,每一存储单元对应的物理盘都有其指定的挂载目录,该挂载目录的父目录是指挂载目录的上一级目录。其中,当未挂载物理盘时,挂载目录与挂载目录的父目录具有相同的设备号;当挂载物理盘时,挂载目录具有的设备号会变成所述物理盘对应的设备号。而挂载目录的父目录具有的设备号不会因为是否挂载物理盘而改变。因此,当挂载目录与挂载目录的父目录具有相同的设备号时,则说明物理盘没有被挂载上;当挂载目录与挂载目录的父目录具有不相同的设备号时,则说明物理盘已经被挂载上。

其中,判断挂载目录与所述挂载目录的父目录是否具有同一设备号的具体方案是:在存储单元主进程启动前通过脚本(比如shell、python等)检查挂载目录和挂载目录的父目录是否具有一个设备号。

下面举例说明这种实施例。

如图2所示,图2展示了一种挂载物理盘之前与之后的挂载目录和挂载目录的父目录示意图。其中,图中的sdb盘是一种物理盘;将挂载目录记为part1,挂载目录的父目录记为var。

其中,当未挂载sdb盘时,part1和var具有的设备号都是258,此情形下part1和var具有相同的设备号;当挂载sdb盘时,part1具有的设备号变成sdb盘对应的设备号,即为196,而var具有的设备号不因挂载sdb盘而改变,仍为258,此情形下part1和var具有不相同的设备号。因此,可根据判断挂载目录与所述挂载目录的父目录是否具有同一设备号得知是否挂载上物理盘。

s102:启动所述存储单元的主进程。

在本实施例中,根据所述挂载目录与所述挂载目录的父目录具有不相同的设备号可知已经挂载上物理盘,在这种情形下可以按照正常步骤启动所述存储单元的主进程。此外,若当前场景属于所述存储单元的部署场景,需要将所述存储单元的正确权重上报监控模块。

s103:进行异常处理。

在本实施例中,根据所述挂载目录与所述挂载目录的父目录具有相同的设备号可知未挂载上物理盘,在这种情形下,因无法成功启动存储单元的主进程,故而,可以不尝试启动存储单元的主进程,而可以走异常处理程序。

在本实施例的一种实现方式中,如图3所示,本步骤s103中的所述进行异常处理可以包括如下步骤s301-s303:

s301:检测当前场景是否属于所述存储单元的部署场景;若是,则不再上报所述存储单元的权重值。

在本实施例中,所述存储单元的部署场景是服务器需要开启存储单元主进程的场景。所述当前场景是否属于所述存储单元的部署场景,即在当前场景下服务器是否需要开启存储单元主进程。在未挂载物理盘的情况下,需要判断当前场景是否属于所述存储单元的部署场景,如果当前场景不属于所述存储单元的部署场景,则无需挂载物理盘;如果当前场景属于所述存储单元的部署场景,则需要挂载物理盘;对于需要挂载物理盘而物理盘又未挂载的情况,如果将错误的权重上报给监控模块的话会导致系统异常,从而影响服务器的工作。因此通过该步骤可以防止因为未挂载物理盘导致的向监控模块上报错误权重的风险。

s302:若检测到当前场景属于所述存储单元的部署场景之后,通过正常退出命令,停止尝试重启所述存储单元的主进程。

s303:在停止尝试重启所述存储单元的主进程之后,将重启所述存储单元的主进程的失败次数清零。

对于步骤s302-s303,以systemd的启动方式为例。在该实施例中,systemd可以监控启动存储单元的主进程。具体为:如果未挂载物理盘去启动存储单元的主进程,则该进程会被异常退出。当进程被异常退出时,systemd可以在限定的时间范围内每隔一段时间尝试启动一次。其中,可以控制重试的次数,超过一定的次数就放弃重试。例如图4所示,图4(a)中展示了systemd监控进程。其中,systemd限定的时间范围是3min,当进程被异常退出时,systemd每隔20s会尝试启动一次,重试的次数为3次,如果重试次数超过3次就放弃重试。图4(b)展示了systemd在以3min的时间范围为一个周期进行重试的过程示意图。其中,当进程被异常退出时,systemd间隔20s后进行第一次尝试启动,第一次尝试重启后进程再次被异常退出;在此次异常退出后间隔20s后systemd进行第二次尝试启动,第二次尝试重启后进程再次被异常退出;在此次异常退出后间隔20s后systemd进行第三次尝试启动,第三次尝试重启后进程再次被异常退出。在第三次进程被异常退出后,systemd就放弃重试。在整个过程达到3min后将再次进行重试。其中,如果进程不是异常退出而是正常退出则systemd不会进行重试,因此,通过所述通过正常退出命令停止尝试重启存储单元的主进程,在未挂载物理盘的情况下,放弃了启动存储单元主进程,优化了流程;且停止启动存储单元主进程,避免了systemd后续不必要的启动主进程的尝试。

其中,systemd启动方式的正常退出命令可以是stop命令。

其中,如图4(b),systemd的监控过程有2种情形:1、如图4(b)中的(1)-(3),在每次间隔时间中,如果没有将重启的次数清零,则即使异常退出的原因已消除,也无法尝试重启,必须等间隔时间满后才可尝试重启;2、如图4(b)中的(4),在第三次异常退出后,如果没有将重启的次数清零,则即使异常退出的原因已消除,也无法启动,只能超过限定时间范围3min后才可重启。因此,步骤s303中将重启所述存储单元的主进程的失败次数清零,即可在挂载物理盘时,第一时间启动存储单元主进程,加快主进程的启动速度。

综上,本申请实施例提供的存储单元的启动前校验方法,在所述存储单元的主进程启动之前,判断挂载目录与所述挂载目录的父目录是否具有同一设备号,其中,所述挂载目录为所述存储单元对应的物理盘所挂载的目录;若否,则启动所述存储单元的主进程;若是,则进行异常处理。本申请实施例在启动存储单元的主进程之前,对存储单元对应的物理盘是否挂载进行提前检测,当检测到挂载目录与所述挂载目录的父目录具有同一设备号时,则可确定未挂载物理盘,在此种情形下,将无法成功启动存储单元的主进程,所以可不启动存储单元的主进程,而是走异常处理程序,从而降低了服务器运行资源的浪费。

进一步地,在非异常情形下,即物理盘已挂载且当前场景属于所述存储单元的部署场景,需要将所述存储单元的正确权重上报监控模块;在进行异常处理时,若当前场景属于所述存储单元的部署场景,则不再上报所述存储单元的权重值,该步骤可以防止因为未挂载物理盘导致的向监控模块上报错误权重的风险。其次,通过正常退出命令,停止尝试重启所述存储单元的主进程,该步骤停止了启动存储单元主进程,避免了systemd后续不必要的启动主进程的尝试。最后,将重启所述存储单元的主进程的失败次数清零,该步骤可在在挂载物理盘时,第一时间启动存储单元主进程,加快主进程的启动速度。可见,通过这些优化,可以优化异常处理流程,避免了不必要的尝试,并保证了异常情况解决后以最快速度恢复系统,减少了不必要的时间损耗,提高了服务器系统的运行性能。

参见图5,为申请本实施例提供的一种存储单元的启动前校验装置的组成示意图,该装置包括:

设备号对比单元s501,用于在所述存储单元的主进程启动之前,判断挂载目录与所述挂载目录的父目录是否具有同一设备号,其中,所述挂载目录为所述存储单元对应的物理盘所挂载的目录;

正常处理单元s502,用于若否,则启动所述存储单元的主进程;

异常处理单元s503,用于若是,则进行异常处理。

在本实施例的一种实现方式中,所述异常处理单元包括:

检测子单元,用于检测当前场景是否属于所述存储单元的部署场景;

上报子单元,用于若当前场景属于所述存储单元的部署场景,则不再上报所述存储单元的权重值。

在本实施例的一种实现方式中,所述异常处理单元还包括:

退出子单元,用于在所述检测子单元检测到当前场景属于所述存储单元的部署场景之后,通过正常退出命令,停止尝试重启所述存储单元的主进程。

在本实施例的一种实现方式中,所述正常退出命令为stop命令。

在本实施例的一种实现方式中,所述异常处理单元还包括:

清零子单元,用于在所述退出子单元停止尝试重启所述存储单元的主进程之后,将重启所述存储单元的主进程的失败次数清零。

通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到上述实施例方法中的全部或部分步骤可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如rom/ram、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者诸如媒体网关等网络通信设备,等等)执行本申请各个实施例或者实施例的某些部分所述的方法。

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

还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下,在其它实施例中实现。因此,本申请将不会被限制于本文所示的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1