本申请涉及分布式存储技术领域，具体而言，涉及一种worm状态监控转移方法及装置。
背景技术：
在文件存储系统中，文件的元数据(metadata)记录了文件的属性，如文件存储位置、大小、存储时间等，通过元数据可以进行文件查找、文件记录、存储位置记录、访问授权等工作。在分布式系统中，常通过元数据服务器(英文：metadataserver，简称：mds)对文件的元数据进行管理，并对外提供文件系统服务。
目前，mds有两种重用的架构。一种为一主多备架构，该架构是由1台mds作为主mds负责文件系统的管理，其他元数据作为备用仅在主元数据服务工作异常时启用；另一种为多活动mds模式，该模式是多个mds同时工作，不同mds管理不同文件的元数据。
在例如金融证券、政法、电信、医疗信息等领域的存储系统中，对数据文件的安全性有较高要求，现有技术常通过一次写入多次读取(英文：writeoncereadmany，简称：worm)功能对数据进行保护。worm功能是根据携带在元数据中的worm信息，对文件进行保护，防止文件被读取或修改。但是，现有技术的worm功能仅支持在一主多备的mds架构上实现，尚不支持在多活动mds架构上实现。
技术实现要素：
有鉴于此，本申请提供了一种worm状态监控转移方法及装置，解决了多个活动mds架构上不能实现worm功能的问题。
第一方面，本申请提供一种worm状态监控转移方法，应用于分布式存储系统中的第一mds，所述第一mds配置有worm文件列表，所述worm文件列表用于记录需要进行worm状态监控的文件的元数据；所述方法包括：
当需要将由所述第一mds进行worm状态监控的第一文件切换至由除所述第一mds之外的其他mds进行监控时，在所述其他mds中为所述第一文件确定至少一个监控所述第一文件worm状态的第二mds；
向所述第二mds发送第一worm添加消息，使所述第二mds根据所述worm添加消息，获取所述第一文件的元数据，并根据所述第一文件的元数据携带的worm信息对所述第一文件进行worm状态监控；
从所述第一mds的worm文件列表中删除所述第一文件的元数据的记录。
第二方面，本申请提供一种worm状态监控转移装置，应用于分布式存储系统中的第一mds，所述第一mds配置有worm文件列表，所述worm文件列表用于记录需要进行worm状态监控的文件的元数据；所述装置包括：
选择模块，用于当需要将由所述第一mds进行worm状态监控的第一文件切换至由除所述第一mds之外的其他mds进行监控时，在所述其他mds中为所述第一文件确定至少一个监控所述第一文件worm状态的第二mds；
通知模块，用于向所述第二mds发送第一worm添加消息，使所述第二mds根据所述worm添加消息，获取所述第一文件的元数据，并根据所述第一文件的元数据携带的worm信息对所述第一文件进行worm状态监控；
删除模块，用于从所述第一mds的worm文件列表中删除所述第一文件的元数据的记录。
第三方面，本公开提供一种mds，包括处理器及和机器可读存储介质，所述机器可读存储介质存储有能够被所述处理器执行的机器可执行指令，处理器执行所述机器可执行指令以实现本公开提供的worm状态监控转移方法。
相对于现有技术而言，本申请具有以下有益效果：
本申请提供的worm状态监控转移方法及装置，在多活动mds的分布式系统架构中，当第一mds检测到其管理第一文件需要切换至除所述第一mds之外的由其他mds管理时，为所述第一文件选取第二mds，并通知第二mds接管第一文件的元数据，以对第一文件的worm状态进行监控。如此，实现了多活动mds场景下，当管理文件的mds切换时，worm状态的监控也可以随之转移，使得worm功能可以在多活动mds架构上实现。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1为一主多备mds架构的示意图；
图2为多活动mds架构的示意图；
图3为本申请实施例提供的worm状态监控转移方法的流程示意图之一；
图4为本申请实施例提供的worm状态监控转移方法的流程示意图之二；
图5为本申请实施例提供的元数据添加阶段的流程示意图；
图6为本申请实施例提供的worm文件列表遍历阶段的流程示意图；
图7为本申请实施例提供的元数据删除阶段的流程示意图；
图8为本申请实施例提供的mds的硬件结构示意图；
图9为本申请实施例提供的worm状态监控转移装置的示意图之一；
图10为本申请实施例提供的worm状态监控转移装置的示意图之二。
图标：100-存储节点；110-osd；200-mds；210-worm状态监控转移装置；211-选择模块；212-通知模块；213-删除模块；214-接收模块；215-添加模块；216-监控模块；220-机器可读存储介质；230-处理器；240-系统总线。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。
因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。
在本申请的描述中，需要说明的是，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
在本申请的描述中，还需要说明的是，除非另有明确的规定和限定，术语“设置”、“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本申请中的具体含义。
在一些采用对象存储的分布式系统中，每个存储节点可以包括多个对象存储设备(英文：object-basedstoragedevice，简称：osd)，文件被分成多个数据分片后，被存储于不同数据节点的osd中。
在一主多备的mds架构下，请参照图1，主要由1个mds200管理所有文件的元数据，进行文件查找、文件记录、存储位置记录、访问授权等工作，并对外提供文件系统。例如，文件a、文件b、文件c均被分成多个分片存储于不同存储节点100的osd110中，并统一由mds-a管理这些文件的元数据。
在图1所示架构中，mds-a会维护配置一个worm文件列表，该worm文件列表中记录了需要进行worm状态监控的文件(以下简称worm文件)。mds-a会定时遍历该worm文件列表，获取worm文件的元数据。根据元数据中携带的worm信息(如，保护期时长等)及元数据中的其他参数(如文件创建时间等)，mds-a判断worm文件的worm状态，worm状态包括未保护状态、保护状态、追加状态或过期状态。
然后，mds-a再根据worm状态判断worm文件是否可以被修改或删除。其中，处于未保护状态的worm文件可以被删除和修改，保护状态的worm文件不能被删除和修改，追加状态的worm文件只能追加写且不能被删除，处以过期状态的worm文件可以被删除，但是不能被修改。
在多活动mds模式下，请参照图2，分布式系统中存在多个mds200同时对文件进行管理，每个mds200负责一部分文件的元数据管理。其中，管理某个文件的元数据的mds被称为这个文件的权威mds(authoritativemds，简称auth-mds)。例如，在图2所示场景中，文件d的元数据d由mds-d管理，则mds-d为文件d的权威mds，文件e的元数据e由mds-e管理，则mds-e为文件e的权威mds。
经发明人研究发现，在图1所示一主多备的mds架构中，由于只有1个mds200提供服务，不存在管理元数据的mds200切换，即，在使用worm功能时，也只有1个mds200根据其worm文件列表进行worm状态的监控。所以在一主多备的mds架构中可以较为容易地实现worm功能。
而在图2所示多活动mds架构中，存在多个mds200同时对文件的元数据进行管理，根据各mds200的运行状态或一些具体的场景要求，可能管理某个元数据的权威mds会在多个mds200中切换。而在权威mds发生切换后，由于mds200的worm文件列表没有发生改变，新的权威mds不能及时开始对新纳入管理的文件的worm状态进行监控，导致新纳入管理的文件worm状态不再发生改变，影响worm文件的安全性。
故在本实施例中，提出一种应用于图2所示在多活动mds架构中worm状态监控转移方法，使的worm功能可以在多活动mds架构中实现，下面对本实施例提供的方案进行详细阐述。
在本实施例中，在一些情况下，元数据的权威mds可能发生改变，例如，某个mds负载过重，需要将其管理一部分元数据转由其他mds管理，即将一部分元数据的权威mds切换为其他mds。在这种情况下，为保证worm文件的worm状态监控也能继续顺利进行，本实施例提供一种，worm状态监控转移方法，下面对该方法的各个步骤进行详细阐述。
步骤s310，当需要将由第一mds进行worm状态监控的第一文件切换至由除第一mds之外的其他mds进行监控时，在其他mds中为第一文件确定至少一个监控第一文件worm状态的第二mds。
在本实施例中，第一mds及第二mds并不特指某个mds，第一文件也不特指某个文件，当某个mds需要将其管理的文件转给其他mds管理时，该mds即作为第一mds，该mds需要转给其他mds管理的文件即作为第一文件，接管该mds转出文件的其他mds即作为第二mds。第一文件可以是一个也可以是多个。
例如，请再次参照图2，mds-b作为文件b的权威mds，在需要将文件b切换至由其他mds管理时，则mds-b作为第一mds，文件b作为第一文件。若mds-b为将mds-c确定为文件b新的权威mds，则mds-c作为第二mds。
在本实施例中，触发第一mds将第一文件状给其他mds管理的条件可以为多种。
例如，在一种实施方式中，当第一mds当前管理的元数据达到一定阈值时，可以认为该第一mds的负载较重，需要将其管理的部分第一文件转由其他mds管理。此时该第一mds可以分别获取其他mds中每个mds的运行负载变量参数，运行负载变量参数用于表征mds的运行负载状态。然后比较第一mds与每个mds的运行负载变量参数。根据比价结果，从其他mds中确定出第二mds。
在另一种实施方式中，可能根据一些具体场景的需要，管理员需要手动将第一mds管理某个第一文件重新指定新的权威mds对该第一文件进行管理。此时，第一mds可以接收用户输入的选择操作指令，选择操作指令包括用户选择出的mds的标识，根据mds的标识，确定第二mds。
步骤s320，向第二mds发送第一worm添加消息，使第二mds根据worm添加消息，获取第一文件的元数据，并根据第一文件的元数据携带的worm信息对第一文件进行worm状态监控。
其中，第一worm添加消息携带有第一文件的元数据，第一文件的元数据用于使第二mds通过接收到的第一worm添加消息中获取第一文件的元数据，并将第一文件的元数据记录至第二mds的worm文件列。
步骤s330，从第一mds的worm文件列表中删除第一文件的元数据的记录。
如此，实现了多活动mds场景下，当管理文件的mds切换时，worm状态的监控也可以随之转移，使得worm功能可以在多活动mds架构上实现。
可选地，在本实施例的一种实施方式中，第一mds在步骤s320中，将第一文件的元数据作为第一worm添加消息发送给第二mds，使第二mds将第一文件的元数据记录至该第二mds的worm文件列表。同时在步骤s330中，第一mds将其worm文件列表中记录的第一文件的元数据删除。
如此，第一mds直接将第一文件作为第一worm添加消息发送给第二mds，使第二mds接收到第一文件的元数据后，可以立即开始对第一文件worm状态的监控。
可选地，在本实施例的另一种实施方式中，在步骤s310中，第一mds在其他mds中为第一文件确定至少一个监控第一文件worm状态的第二mds的步骤之后，将所述第一文件的元数据发送给所述第二元数据服务器，并为所述第一元数据服务器的worm文件列表中已发送给所述第二元数据服务器的所述第一文件的元数据添加预设标识。
接着，在步骤s320中，第一mds在周期性地锁定worm文件列表并遍历worm文件列表中记录的元数据，若检测到带有预设标识的第一文件的元数据，则向该第一文件对应第二mds发送第一worm添加消息，第一worm添加消息包括第一文件的元数据的标识，第一worm添加消息用于使第二mds在接收到第一worm添加消息时，根据所述第一文件的元数据的标识，将第一文件的元数据记录至该第二mds的worm文件列表。
也就是说，第一文件在发送元数据时不对worm文件列表本身进行处理，仅对worm文件列表中已发送的第一文件的元数据进行标记，然后在周期性遍历worm列表的时统一处理带标记的第一文件的元数据。如此，防止了worm文件列表被频繁加锁解锁，可以减轻了第一mds的与运行负担。
然后，在步骤s330中，第一mds在接收到第二mds根据第一worm添加消息反馈的添加成功通知时，从该第一mds的worm文件列表中删除第一文件的元数据的记录。
如此，第一mds在确定第二mds将第一文件的元数据添加至该第二mds的worm文件列表后再解除对第一文件worm状态的监控，使得worm状态监控的可靠性更高。
可选地，在本实施例中，第一mds也可以接管其他mds管理的元数据，请参照图4，worm处理方法还可以包括步骤s410及步骤s430。
步骤s410，第一mds接收第三mds发送的第二worm添加消息，第二worm添加消息由第三mds在需要将由第三mds进行worm状态监控的第二文件切换至由第一mds进行监控时发送。
同样地，在本实施例中，第三mds并不特指某个mds，第二文件也不特指某个文件，当某个mds需要将其管理的文件转给第一mds管理时，该mds即作为第三mds，该mds需要转给第一mds管理的文件即作为第二文件。第二文件可以是一个也可以是多个。
步骤s420，根据第二worm添加消息，获取第二文件的元数据并记录至第一mds的worm文件列表。
在本实施例中，第一mds可以接收第三mds发送的第二文件的元数据后，将第二文件的元数据记录至该第一mds的worm文件列表。
步骤s430，根据worm文件列表，对第一mds管理范围内的元数据的worm状态进行监控。
在将第二文件的元数据添加至worm文件列表后，在周期性遍历worm文件列表的过程中也可以对新纳入该第一mds管理的worm文件进行worm状态的监控。
在本实施例中，当不进行权威mds切换时，每个mds会维护各自的worm文件列表，worm文件列表中记录有需要进行worm状态监控的文件的元数据。mds会定时遍历worm文件列表，根据worm文件列表中记录的元数据判断对应文件的worm状态，并根据worm状态对文件进行保护。
可选地，为了减少worm文件列表中记录的数据量，提高遍历效率，在本实施例中，可以仅将worm状态可能发生改变的文件的元数据记录至worm文件列表。
例如，各mds可以在检测到缓存中有新的需要进行worm状态监控的文件加入时，mds判断该文件是否为需要进行worm状态监控的worm文件，若是，则获取新加入缓存的worm文件的元数据，并将该新加入缓存的worm文件的元数据记录至该mds的worm文件列表。其中，缓存中有新的文件加入的情况包括创建新的文件或将磁盘中文件加载到缓存。worm文件列表中记录的信息为元数据在缓存中的地址指针。
为了使本领域技术人员更好地理解本申请实施例提供的技术方案，下面结合一种具体应用场景对本申请实施例提供的技术方案进行说明。
在本实施例中，第一mds进行worm状态监控的步骤可以包括元数据添加阶段和worm文件列表遍历阶段。
请参照图5，元数据添加阶段中，可以包括步骤s511至步骤s513。
步骤s511，第一mds检测到有新文件创建、从磁盘加载已有文件至缓存或接收到第三mds发送的第二worm添加消息时，进入步骤s512。
步骤s512，创建并填充新的元数据结构体。
在本实施例中，当第一mds检测到新文件创建时，可以获取该文件的元数据。当第一mds检测到从磁盘加载之前持久化的文件至缓存时，同时可以获得之前持久化的该文件的元数据。第一mds还可以直接接收第三mds发送第二文件的元数据。
第一mds在缓存中创建新的元数据结构体，并根据获得元数据填充该元数据结构体。然后进入步骤s513。
步骤s513，判断该元数据是否需加入worm文件列表。
若该元数据对应的文件需要进行worm状态监控，则需要将该元数据加入worm文件列表，进入步骤s514。
步骤s514，加锁保护worm文件列表。
在本实施例中，为防止其他进程同时对worm文件列表进行修改，在第一mds需要先对worm文件列表枷锁保护。
步骤s515，将该元数据的地址指针记录至worm文件列表。
步骤s516，解锁worm文件列表。
基于上述设计，第一mds在对自身管辖范围内元数据进行管理的通常情况下及接管其他mds的元数据的特殊情况下都能将需要进行worm状态监控的文件的元数据添加至worm文件列表。
请参照图6，以第一mds先将第一文件的元数据发送给第二mds，然后在遍历worm文件列表时发送第一worm添加消息的前提为例，worm文件列表遍历阶段中，可以包括步骤s611至步骤s620。
步骤s611，加锁保护worm文件列表。
步骤s612，检测worm文件列表是否为空。
若不为空，则进入步骤s613。
若为空，则进入步骤s621，结束本次遍历。
步骤s613，检测是否遍历完worm文件列表。
若已遍历完worm文件列表，则进入步骤s621，结束本次遍历。
若未遍历完worm文件列表，则进入步骤s614。
步骤s614，从worm文件列表提取一个尚未为检测过的元数据，判断该元数据是否带有预设标识。
若该元数据带有预设标识，则该元数据为需要转由其他mds管理的第一文件的元数据，进入步骤s615。
若该元数据不带有预设标识，则进入步骤s617。
步骤s615，向该第一文件对应第二mds发送第一worm添加消息，使第二mds在接收到第一worm添加消息时，将第一文件的元数据记录至该第二mds的worm文件列表。然后进入步骤s615。
步骤s616，在接收到第二mds根据第一worm添加消息反馈的添加成功通知时，进入步骤s620。
步骤s617，根据该元数据中携带worm信息判断对应的文件worm状态是否发生变化。
在本实施例中，worm状态的变化包括未保护状态切换到保护状态、追加状态切换到保护状态或保护状态切换到过期状态。
若worm状态不发生变化，则重新进入步骤s613。
若worm状态发生了变化，则进入步骤s618。
步骤s618，设置新的worm状态，并根据新的worm状态对相应的文件的访问权限进行控制。然后进入步骤s619。
步骤s619，判断是否需要将该元数据从worm文件列表移除。
在本实施例中，若文件的worm状态为过期状态，则该文件的worm状态将不再会继续改变，故不需要对该文件继续监控，所以在本步骤中，若检测到文件的worm状态为过期时，则从worm文件列表中移除该文件的元数据。
若不需要将该元数据从worm文件列表移除，则重新进入步骤s613。
若需要将该元数据从worm文件列表移除，则进入步骤s620。
步骤s620，将该元素从worm文件列表移除，然后重新进入步骤s612。
步骤s621，解锁worm文件列表，结束遍历。
另外，第一mds对worm状态的监控还可以包括元数据删除阶段，请参照图7，元数据删除阶段可以包括步骤s711至步骤s715。
步骤s711，当检测到文件删除或缓存中的文件被移除时，进入步骤s712。
在本实施例中，当第一mds管理的文件被删除时，被删除的文件不在需要进行worm状态监控，则触发进入步骤s712。当第一mds缓存中的文件因长时间未使用，被移存至磁盘时，文件的worm状态将暂时无法改变，则触发进入步骤s712。
步骤s712，检查该文件对应的元数据是否需要从worm文件列表中删除。
在本实施例中，若该文件时之前需要进行worm状态监控的文件，则worm文件列表中记录有该文件元数据的地址指针，则进入步骤s713。
步骤s713，加锁保护worm文件列表。
步骤s714，将该文件对应的元数据从worm文件列表中删除。
步骤s715，解锁worm文件列表。
本实施例提供的worm状态监控转移方法，在元数据的权威mds切换时，通过mds至今的信息交互，是worm状态的监控也随之转移，如此，使得worm功能在多活动mds架构中也可以实现。
请参照图8，图8为本公开实施例提供的一种mds200的硬件结构示意图。所述mds200包括worm状态监控转移装置210、存储器220及处理器230。
请参照图8，图8为本公开示例提供的一种mds200的硬件结构示意图。该mds200可包括处理器230、存储有机器可执行指令的机器可读存储介质220。处理器230与机器可读存储介质220可经由系统总线240通信。并且，通过读取并执行机器可读存储介质220中与worm状态监控逻辑对应的机器可执行指令，处理器230可执行上文描述的worm状态监控方法。
请参照图9，本实施例还提供一种应用于图2所示mds200的worm状态监控转移装置210，从功能上划分，worm状态监控转移装置210可以包括选择模块211、通知模块212及删除模块213。
选择模块211，用于当需要将由第一mds进行worm状态监控的第一文件切换至由除第一mds之外的其他mds进行监控时，在其他mds中为第一文件确定至少一个监控第一文件worm状态的第二mds。
本实施例中，选择模块211可用于执行图3所示的步骤s310，关于选择模块211的具体描述可参对步骤s310的描述。
具体地，选择模块211具体用于，分别获取所述其他元数据服务器中每个元数据服务器的运行负载变量参数，所述运行负载变量参数用于表征元数据服务器的运行负载状态；比较所述第一元数据服务器与所述每个元数据服务器的运行负载变量参数；根据比较结果，从所述其他元数据服务器中确定出所述第二元数据服务器；
或者，
接收用户输入的选择操作指令，所述选择操作指令包括所述用户选择出的元数据服务器的标识；根据所述元数据服务器的标识，确定所述第二元数据服务器。
通知模块212，用于向第二mds发送第一worm添加消息，使第二mds根据worm添加消息，获取第一文件的元数据，并根据第一文件的元数据携带的worm信息对第一文件进行worm状态监控。
本实施例中，通知模块212可用于执行图3所示的步骤s220，关于通知模块212的具体描述可参对步骤s220的描述。
删除模块213，用于从第一mds的worm文件列表中删除第一文件的元数据的记录。
本实施例中，删除模块213可用于执行图3所示的步骤s330，关于删除模块213的具体描述可参对步骤s330的描述。
基本一步地，请参照图10，worm状态监控转移装置210还可以包括接收模块214、添加模块215及监控模块216。
接收模块214，用于接收第三mds发送的第二worm添加消息，第二worm添加消息由第三mds在需要将由第三mds进行worm状态监控的第二文件切换至由第一mds进行监控时发送。
本实施例中，接收模块214可用于执行图4所示的步骤s410，关于接收模块214的具体描述可参对步骤s410的描述。
添加模块215，用于根据第二worm添加消息，获取第二文件的元数据并记录至第一mds的worm文件列表。
本实施例中，添加模块215可用于执行图4所示的步骤s420，关于添加模块215的具体描述可参对步骤s420的描述。
监控模块216，用于根据worm文件列表，对第一mds管理范围内的元数据的worm状态进行监控。
本实施例中，监控模块216可用于执行图4所示的步骤s430，关于监控模块216的具体描述可参对步骤s430的描述。
综上所述，本申请提供的worm状态监控转移方法及装置，在多活动元数据服务器的分布式系统架构中，当第一mds器检测到其管理第一文件需要切换至由其他元数据服务器管理时，为所述第一文件选取第二元数据服务器，并通知第二元数据服务器接管第一文件的元数据，以对第一文件的worm状态进行监控。如此，实现了多活动元数据服务器场景下，当管理文件的元数据服务器切换时，worm状态的监控也可以随之转移，使得worm功能可以在多活动元数据服务器架构上实现。
在本申请所提供的实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。
所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个机器可读存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。例如，图2所示的mds200可以包括处理器及和机器可读存储介质，所述机器可读存储介质存储有能够被所述处理器执行的机器可执行指令，所述处理器执行所述机器可执行指令以实现本申请提供的worm状态监控转移方法。
需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。