CN108647248B

CN108647248B - WORM state monitoring transfer method and device

Info

Publication number: CN108647248B
Application number: CN201810340072.9A
Authority: CN
Inventors: 魏东
Original assignee: New H3C Technologies Co Ltd Chengdu Branch
Current assignee: New H3C Technologies Co Ltd Chengdu Branch
Priority date: 2018-04-16
Filing date: 2018-04-16
Publication date: 2021-03-09
Anticipated expiration: 2038-04-16
Also published as: CN108647248A

Abstract

In a distributed system architecture of multiple active metadata servers, when a first MDS detects that a first file managed by the first MDS needs to be switched to be managed by other metadata servers, a second metadata server is selected for the first file, and the second metadata server is informed to take over metadata of the first file, so that the WORM state of the first file is monitored. Therefore, under the multi-activity metadata server scene, when the metadata server for managing the file is switched, the monitoring of the WORM state can be transferred along with the switching, so that the WORM function can be realized on the multi-activity metadata server architecture.

Description

WORM state monitoring transfer method and device

Technical Field

The application relates to the technical field of distributed storage, in particular to a method and a device for monitoring and transferring a WORM state.

Background

In a file storage system, Metadata (Metadata) of a file records attributes of the file, such as file storage location, size, storage time and the like, and file searching, file recording, storage location recording, access authorization and the like can be performed through the Metadata. In a distributed system, a Metadata Server (MDS) is often used to manage Metadata of a file and provide file system services to the outside.

Currently, there are two architectures for MDS to reuse. One is a main multi-backup framework, the framework is that 1 MDS is used as a main MDS to be responsible for the management of a file system, and other metadata is used as a backup to be started only when the main metadata service works abnormally; the other is a multi-active MDS mode, in which multiple MDSs operate simultaneously, and different MDSs manage metadata of different files.

In a storage system in the fields of financial securities, politics, telecommunications, medical information, and the like, there is a high requirement on the security of data files, and in the prior art, data is often protected by a Write Once Read Many (WORM) function. The WORM function is to protect a file from being read or modified according to WORM information carried in metadata. However, the WORM function in the prior art only supports the implementation on a master-standby MDS architecture, and does not support the implementation on a multi-active MDS architecture.

Disclosure of Invention

In view of this, the present application provides a method and an apparatus for monitoring and transferring a WORM status, which solve the problem that a plurality of active MDS architectures cannot implement a WORM function.

In a first aspect, the present application provides a method for monitoring and transferring a WORM state, which is applied to a first MDS in a distributed storage system, where the first MDS is configured with a WORM file list, and the WORM file list is used to record metadata of a file that needs to be monitored for the WORM state; the method comprises the following steps:

when a first file which is monitored by the first MDS in the WORM state needs to be switched to be monitored by other MDS except the first MDS, determining at least one second MDS which monitors the WORM state of the first file for the first file in the other MDS;

sending a first WORM adding message to the second MDS, enabling the second MDS to acquire metadata of the first file according to the WORM adding message, and monitoring the WORM state of the first file according to WORM information carried by the metadata of the first file;

deleting a record of metadata of the first file from the WORM file list of the first MDS.

In a second aspect, the present application provides a WORM state monitoring transfer apparatus, which is applied to a first MDS in a distributed storage system, where the first MDS is configured with a WORM file list, and the WORM file list is used to record metadata of a file that needs to be subjected to WORM state monitoring; the device comprises:

the device comprises a selection module, a first management module and a second management module, wherein the selection module is used for determining at least one second MDS for monitoring the WORM state of a first file for the first file in other MDS when the first file monitored by the WORM state of the first MDS needs to be switched to be monitored by other MDS except the first MDS;

a notification module, configured to send a first WORM addition message to the second MDS, enable the second MDS to obtain metadata of the first file according to the WORM addition message, and perform WORM state monitoring on the first file according to WORM information carried by the metadata of the first file;

a deletion module to delete a record of metadata of the first file from a WORM file list of the first MDS.

In a third aspect, the present disclosure provides a MDS, which includes a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor, the processor executing the machine-executable instructions to implement the WORM state monitoring transfer method provided by the present disclosure.

Compared with the prior art, the method has the following beneficial effects:

according to the WORM state monitoring transfer method and device, in a distributed system architecture of multiple active MDSs, when a first MDS detects that a first file managed by the first MDS needs to be switched to be managed by other MDSs except the first MDS, a second MDS is selected for the first file, and the second MDS is informed to take over metadata of the first file, so that the WORM state of the first file is monitored. Therefore, under the multi-activity MDS scene, when the MDS of the management file is switched, the monitoring of the WORM state can be transferred along with the management file, so that the WORM function can be realized on the multi-activity MDS architecture.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained from the drawings without inventive effort.

FIG. 1 is a schematic diagram of a master multi-standby MDS architecture;

FIG. 2 is a schematic diagram of a multi-activity MDS architecture;

FIG. 3 is a flowchart illustrating a WORM state monitoring transition method according to an embodiment of the present disclosure;

FIG. 4 is a second flowchart of a WORM state monitoring transition method according to an embodiment of the present application;

FIG. 5 is a schematic flow chart illustrating a metadata adding phase according to an embodiment of the present disclosure;

FIG. 6 is a flowchart illustrating a traversal phase of a WORM file list according to an embodiment of the present application;

FIG. 7 is a schematic flow chart illustrating a metadata deletion phase according to an embodiment of the present application;

fig. 8 is a schematic hardware structure diagram of an MDS according to an embodiment of the present application;

FIG. 9 is a diagram illustrating a WORM state monitoring and transferring apparatus according to an embodiment of the present disclosure;

fig. 10 is a second schematic diagram of a WORM status monitoring and transferring apparatus according to an embodiment of the present application.

Icon: 100-a storage node; 110-OSD; 200-MDS; 210-WORM state monitoring transfer means; 211-a selection module; 212-a notification module; 213-delete module; 214-a receiving module; 215-add module; 216-a monitoring module; 220-a machine-readable storage medium; 230-a processor; 240-system bus.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. The components of the embodiments of the present application, generally described and illustrated in the figures herein, can be arranged and designed in a wide variety of different configurations.

Thus, the following detailed description of the embodiments of the present application, presented in the accompanying drawings, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments of the application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures.

In the description of the present application, it is noted that the terms "first", "second", "third", and the like are used merely for distinguishing between descriptions and are not intended to indicate or imply relative importance.

In the description of the present application, it is further noted that, unless expressly stated or limited otherwise, the terms "disposed," "mounted," "connected," and "connected" are to be construed broadly, e.g., as meaning either a fixed connection, a removable connection, or an integral connection; can be mechanically or electrically connected; they may be connected directly or indirectly through intervening media, or they may be interconnected between two elements. The specific meaning of the above terms in the present application can be understood in a specific case by those of ordinary skill in the art.

In some distributed systems using Object-based Storage, each Storage node may include a plurality of Object-based Storage devices (OSDs), and after being divided into a plurality of data slices, the files are stored in the OSDs of different data nodes.

Under an MDS architecture with one master and multiple slaves, please refer to fig. 1, which mainly uses 1 MDS200 to manage metadata of all files, perform file searching, file recording, storage location recording, access authorization and other tasks, and provide a file system to the outside. For example, file A, file B, and file C are each stored in OSD110 of different storage nodes 100 in multiple slices, and metadatA of these files is managed uniformly by MDS-A.

In the architecture shown in FIG. 1, MDS-A maintains and configures A WORM file list in which files that need WORM status monitoring (hereinafter referred to as WORM files) are recorded. MDS-A will periodically traverse the WORM file list to obtain the metadatA of the WORM file. According to the WORM information (such as the protection period duration and the like) carried in the metadatA and other parameters (such as the file creation time and the like) in the metadatA, the MDS-A judges the WORM state of the WORM file, wherein the WORM state comprises an unprotected state, A protected state, an added state or an expired state.

MDS-A then determines whether the WORM file can be modified or deleted based on the WORM status. Wherein the WORM file in the unprotected state can be deleted and modified, the WORM file in the protected state cannot be deleted and modified, the WORM file in the appended state can only be additionally written and cannot be deleted, and the WORM file in the expired state can be deleted but cannot be modified.

In the multi-active MDS mode, referring to fig. 2, a plurality of MDSs 200 exist in the distributed system to manage files simultaneously, and each MDS200 is responsible for metadata management of a portion of files. The MDS that manages metadata of a certain file is referred to as an Authoritative MDS (Auth-MDS for short) of the file. For example, in the scenario shown in fig. 2, the metadata D of the file D is managed by MDS-D, and then MDS-D is the authoritative MDS of the file D, and the metadata E of the file E is managed by MDS-E, and then MDS-E is the authoritative MDS of the file E.

The inventor has found that, in the MDS architecture with one master and multiple slaves shown in fig. 1, because only 1 MDS200 provides services, there is no MDS200 switch for managing metadata, that is, when the WORM function is used, only 1 MDS200 monitors the WORM status according to the WORM file list. WORM functionality can be more easily implemented in a master-slave MDS architecture.

In the multi-active MDS architecture shown in fig. 2, a plurality of MDSs 200 manage metadata of a file at the same time, and an authoritative MDS that may manage a certain metadata may be switched among the plurality of MDSs 200 according to an operation state of each MDS200 or some specific scenario requirements. After the authoritative MDS is switched, because the WORM file list of the MDS200 is not changed, the new authoritative MDS cannot timely start to monitor the WORM state of the newly-incorporated managed file, so that the WORM state of the newly-incorporated managed file is not changed any more, and the security of the WORM file is influenced.

Therefore, in the embodiment, a method for monitoring and transferring a WORM status in a multi-active MDS architecture as shown in fig. 2 is provided, so that the WORM function can be implemented in the multi-active MDS architecture.

In this embodiment, in some cases, the authoritative MDS of the metadata may change, for example, a certain MDS is overloaded, and a part of metadata managed by the certain MDS needs to be transferred to be managed by another MDS, that is, the authoritative MDS of the part of metadata is switched to another MDS. In this case, in order to ensure that the WORM status monitoring of the WORM file can be continued successfully, the embodiment provides a WORM status monitoring transfer method, and the steps of the method are explained in detail below.

Step S310, when the first file which is monitored by the first MDS in the WORM state needs to be switched to be monitored by other MDS except the first MDS, at least one second MDS which monitors the WORM state of the first file is determined for the first file in other MDS.

In this embodiment, the first MDS and the second MDS do not refer to a certain MDS, the first file does not refer to a certain file, when a certain MDS needs to transfer a file managed by the certain MDS to other MDSs for management, the MDS is used as the first MDS, the MDS needs to transfer the file managed by the other MDS is used as the first file, and the other MDS taking over the MDS to transfer the file is used as the second MDS. The first file may be one or a plurality of files.

For example, referring again to FIG. 2, MDS-B serves as the authoritative MDS for file B, and when file B needs to be switched to be managed by other MDSs, MDS-B serves as the first MDS, and file B serves as the first file. And if the MDS-B is the authority MDS which determines the MDS-C as the file B, the MDS-C is taken as the second MDS.

In this embodiment, the condition for triggering the first MDS to manage the first file to the other MDSs may be various.

For example, in one embodiment, when the metadata currently managed by a first MDS reaches a certain threshold, the first MDS may be considered to be heavily loaded, and a portion of the first file managed by the first MDS needs to be transferred to other MDSs for management. At this time, the first MDS may respectively obtain an operation load variable parameter of each of the other MDSs, and the operation load variable parameter is used to characterize an operation load state of the MDS. The operational load variable parameters of the first MDS are then compared to each MDS. And determining the second MDS from other MDSs according to the price comparison result.

In another embodiment, the administrator may need to manually reassign the first MDS to manage a first file to a new authoritative MDS to manage the first file, possibly as needed for some particular scenarios. At this time, the first MDS may receive a selection operation instruction input by the user, where the selection operation instruction includes an identifier of the MDS selected by the user, and determine the second MDS according to the identifier of the MDS.

Step S320, sending the first WORM addition message to the second MDS, so that the second MDS obtains the metadata of the first file according to the WORM addition message, and performs WORM status monitoring on the first file according to the WORM information carried by the metadata of the first file.

The first WORM addition message carries metadata of the first file, and the metadata of the first file is used for enabling the second MDS to acquire the metadata of the first file through the received first WORM addition message and record the metadata of the first file to a WORM file column of the second MDS.

In step S330, the record of the metadata of the first file is deleted from the WORM file list of the first MDS.

Therefore, under the multi-activity MDS scene, when the MDS of the management file is switched, the monitoring of the WORM state can be transferred along with the management file, so that the WORM function can be realized on the multi-activity MDS architecture.

Optionally, in an implementation manner of this embodiment, in step S320, the first MDS sends the metadata of the first file to the second MDS as a first WORM addition message, so that the second MDS records the metadata of the first file to a WORM file list of the second MDS. Also in step S330, the first MDS deletes the metadata of the first file recorded in its WORM file list.

Therefore, the first MDS directly sends the first file to the second MDS as the first WORM addition message, so that the second MDS can immediately start monitoring the WORM state of the first file after receiving the metadata of the first file.

Optionally, in another implementation manner of this embodiment, in step S310, after the step of determining, by the first MDS, at least one second MDS that monitors the WORM state of the first file for the first file in other MDSs, the first MDS sends metadata of the first file to the second metadata server, and adds a preset identifier to the metadata of the first file that has been sent to the second metadata server in the WORM file list of the first metadata server.

Next, in step S320, the first MDS periodically locks the WORM file list and traverses the metadata recorded in the WORM file list, and if the metadata of the first file with a preset identifier is detected, a first WORM addition message is sent to the first file corresponding to the second MDS, where the first WORM addition message includes an identifier of the metadata of the first file, and the first WORM addition message is used to enable the second MDS to record the metadata of the first file into the WORM file list of the second MDS according to the identifier of the metadata of the first file when receiving the first WORM addition message.

That is, the first file does not process the WORM file list itself when sending metadata, marks only the metadata of the first file already sent in the WORM file list, and then processes the marked metadata of the first file collectively when periodically traversing the WORM list. Thus, the WORM file list is prevented from being frequently locked and unlocked, and the operation burden of the first MDS can be relieved.

Then, in step S330, the first MDS deletes the record of the metadata of the first file from the WORM file list of the first MDS upon receiving the addition success notification fed back by the second MDS according to the first WORM addition message.

In this way, the first MDS cancels monitoring of the WORM state of the first file after determining that the second MDS adds the metadata of the first file to the WORM file list of the second MDS, so that the reliability of WORM state monitoring is higher.

Optionally, in this embodiment, the first MDS may also take over metadata managed by other MDSs, and referring to fig. 4, the WORM processing method may further include step S410 and step S430.

Step S410, the first MDS receives a second WORM addition message sent by the third MDS, and the second WORM addition message is sent by the third MDS when the second file whose WORM status is monitored by the third MDS needs to be switched to be monitored by the first MDS.

Similarly, in this embodiment, the third MDS does not refer to a certain MDS, the second file does not refer to a certain file, when a certain MDS needs to transfer a file managed by the third MDS to the first MDS for management, the third MDS is used, and the file managed by the first MDS is used as the second file. The second file may be one or a plurality of files.

Step S420, according to the second WORM addition message, obtain metadata of the second file and record the metadata to the WORM file list of the first MDS.

In this embodiment, after the first MDS can receive the metadata of the second file sent by the third MDS, the metadata of the second file is recorded in the WORM file list of the first MDS.

Step S430, according to the WORM file list, monitoring the WORM state of the metadata in the first MDS management range.

After the metadata of the second file is added to the list of WORM files, monitoring of WORM status can also be performed on WORM files newly incorporated into the first MDS management during periodic traversal of the list of WORM files.

In this embodiment, when the authoritative MDSs are not switched, each MDS maintains a respective WORM file list, and metadata of files that need to be subjected to WORM status monitoring is recorded in the WORM file list. The MDS regularly traverses the WORM file list, judges the WORM state of the corresponding file according to the metadata recorded in the WORM file list, and protects the file according to the WORM state.

Alternatively, in order to reduce the amount of data recorded in the WORM file list and improve the traversal efficiency, in the present embodiment, only the metadata of the file whose WORM state may be changed may be recorded to the WORM file list.

For example, each MDS may, when detecting that a new file requiring WORM state monitoring is added to the cache, determine whether the file is a WORM file requiring WORM state monitoring, if so, obtain metadata of the new-added-to-cache WORM file, and record the metadata of the new-added-to-cache WORM file into a WORM file list of the MDS. The condition that a new file is added into the cache comprises creating a new file or loading a file in a disk into the cache. The information recorded in the WORM file list is an address pointer of the metadata in the cache.

In order to enable those skilled in the art to better understand the technical solution provided by the embodiments of the present application, the technical solution provided by the embodiments of the present application is described below with reference to a specific application scenario.

In this embodiment, the step of the first MDS performing WORM status monitoring may include a metadata addition phase and a WORM file list traversal phase.

Referring to fig. 5, the metadata adding stage may include steps S511 to S513.

Step S511, when the first MDS detects that a new file is created, an existing file is loaded from the disk to the cache, or a second WORM addition message sent by the third MDS is received, step S512 is entered.

In step S512, a new metadata structure is created and populated.

In this embodiment, when the first MDS detects the creation of a new file, the metadata of the file may be obtained. When the first MDS detects that a previously persisted file is loaded from disk into cache, the metadata for the previously persisted file may be obtained at the same time. The first MDS may also receive metadata directly from the third MDS that sent the second file.

The first MDS creates a new metadata structure in the cache and populates the metadata structure based on the obtained metadata. And then proceeds to step S513.

Step S513, determine whether the metadata needs to be added into the WORM file list.

If the file corresponding to the metadata needs to perform WORM status monitoring, the metadata needs to be added into the WORM file list, and the process proceeds to step S514.

Step S514, lock protection WORM file list.

In this embodiment, to prevent other processes from modifying the WORM file list at the same time, the WORM file list needs to be flaked first at the first MDS.

In step S515, the address pointer of the metadata is recorded in the WORM file list.

Step S516, unlock WORM file list.

Based on the above design, the first MDS can add the metadata of the file that needs WORM status monitoring to the WORM file list both in the normal case of managing the metadata in its jurisdiction and in the special case of taking over the metadata of other MDSs.

Referring to fig. 6, taking the premise that the first MDS first sends the metadata of the first file to the second MDS, and then sends the first WORM addition message when traversing the WORM file list, the traversal stage of the WORM file list may include steps S611 to S620.

In step S611, the list of WORM files is protected by locking.

Step S612, whether the WORM file list is empty is detected.

If not, the process proceeds to step S613.

If it is empty, the process proceeds to step S621, and ends the traversal.

Step S613 detects whether the WORM file list is traversed.

If the WORM file list is traversed, step S621 is performed to end the traversal.

If the WORM file list is not traversed, the process goes to step S614.

In step S614, a metadata that has not been detected is extracted from the WORM file list, and it is determined whether the metadata carries a predetermined identifier.

If the metadata has the preset identifier, the metadata is metadata of the first file that needs to be managed by another MDS, and step S615 is performed.

If the metadata does not have the preset identifier, the process proceeds to step S617.

Step S615, sending a first WORM addition message to the second MDS corresponding to the first file, so that the second MDS records the metadata of the first file to a WORM file list of the second MDS when receiving the first WORM addition message. Then, the process proceeds to step S615.

Step S616, when receiving the addition success notification fed back by the second MDS according to the first WORM addition message, proceeds to step S620.

In step S617, whether the WORM status of the corresponding file changes is determined according to the WORM information carried in the metadata.

In this embodiment, the change in WORM state includes a switch from an unprotected state to a protected state, a switch from an appended state to a protected state, or a switch from a protected state to an expired state.

If the WORM status is not changed, the process re-enters step S613.

If the WORM status has changed, the process proceeds to step S618.

Step S618 sets a new WORM status, and controls access rights to the corresponding file according to the new WORM status. Then, the process proceeds to step S619.

In step S619, it is determined whether the metadata needs to be removed from the WORM file list.

In this embodiment, if the WORM status of the file is expired, the WORM status of the file will not be changed any more, so that the file does not need to be monitored continuously.

If the metadata does not need to be removed from the WORM file list, step S613 is re-entered.

If the metadata needs to be removed from the WORM file list, the process proceeds to step S620.

In step S620, the element is removed from the WORM file list and then step S612 is re-entered.

And step S621, unlocking the WORM file list and finishing traversal.

In addition, the monitoring of the WORM status by the first MDS may further include a metadata deletion phase, and referring to fig. 7, the metadata deletion phase may include steps S711 to S715.

In step S711, when it is detected that the file is deleted or the file in the cache is removed, the process proceeds to step S712.

In this embodiment, when the file managed by the first MDS is deleted, and the deleted file does not need WORM status monitoring, the process goes to step S712. When the file in the first MDS cache is moved to the disk because it is not used for a long time, the WORM status of the file cannot be changed temporarily, and the process goes to step S712.

In step S712, it is checked whether the metadata corresponding to the file needs to be deleted from the WORM file list.

In this embodiment, if the file needs to be WORM status monitored before the file is, the address pointer of the file metadata is recorded in the WORM file list, and the process proceeds to step S713.

Step S713, lock protection WORM file list.

In step S714, the metadata corresponding to the file is deleted from the WORM file list.

Step S715, unlocking the WORM file list.

In the method for monitoring and transferring the WORM state provided by this embodiment, when the authoritative MDS of the metadata is switched, monitoring of the WORM state is transferred through information interaction up to now of the MDS, so that the WORM function can be implemented in the multi-active MDS architecture.

Referring to fig. 8, fig. 8 is a schematic diagram of a hardware structure of an MDS200 according to an embodiment of the present disclosure. The MDS200 includes a WORM state monitoring transfer device 210, a memory 220, and a processor 230.

Referring to fig. 8, fig. 8 is a schematic diagram of a hardware structure of an MDS200 according to an example of the present disclosure. The MDS200 may include a processor 230, a machine-readable storage medium 220 storing machine-executable instructions. The processor 230 and the machine-readable storage medium 220 may communicate via a system bus 240. Also, by reading and executing machine-executable instructions in the machine-readable storage medium 220 corresponding to the WORM condition monitoring logic, the processor 230 can perform the WORM condition monitoring methods described above.

Referring to fig. 9, the present embodiment further provides a WORM status monitoring and transferring apparatus 210 applied to the MDS200 shown in fig. 2, wherein the WORM status monitoring and transferring apparatus 210 is functionally divided into a selection module 211, a notification module 212 and a deletion module 213.

A selecting module 211, configured to determine, among other MDSs, at least one second MDS monitoring the WORM status of the first file for the first file when the first file monitored by the WORM status of the first MDS needs to be switched to be monitored by other MDSs except the first MDS.

In this embodiment, the selecting module 211 can be used to execute step S310 shown in fig. 3, and the detailed description about the selecting module 211 can refer to the description about step S310.

Specifically, the selecting module 211 is specifically configured to obtain an operation load variable parameter of each metadata server in the other metadata servers, where the operation load variable parameter is used to represent an operation load state of the metadata server; comparing the operational load variable parameters of the first metadata server and each metadata server; determining the second metadata server from the other metadata servers according to the comparison result;

alternatively, the first and second electrodes may be,

receiving a selection operation instruction input by a user, wherein the selection operation instruction comprises an identifier of a metadata server selected by the user; and determining the second metadata server according to the identifier of the metadata server.

The notification module 212 is configured to send the first WORM addition message to the second MDS, enable the second MDS to obtain the metadata of the first file according to the WORM addition message, and perform WORM state monitoring on the first file according to the WORM information carried by the metadata of the first file.

In this embodiment, the notification module 212 may be configured to execute step S220 shown in fig. 3, and the detailed description about the notification module 212 may refer to the description about step S220.

A deletion module 213 is configured to delete the record of the metadata of the first file from the WORM file list of the first MDS.

In this embodiment, the deleting module 213 may be configured to execute step S330 shown in fig. 3, and the detailed description about the deleting module 213 may refer to the description about step S330.

Basically, referring to fig. 10, the WORM status monitoring transferring apparatus 210 may further include a receiving module 214, an adding module 215 and a monitoring module 216.

A receiving module 214, configured to receive a second WORM addition message sent by the third MDS, where the second WORM addition message is sent by the third MDS when the second file whose WORM status is monitored by the third MDS needs to be switched to be monitored by the first MDS.

In this embodiment, the receiving module 214 may be configured to execute step S410 shown in fig. 4, and reference may be made to the description of step S410 for a detailed description of the receiving module 214.

And an adding module 215, configured to obtain metadata of the second file according to the second WORM addition message, and record the metadata to the WORM file list of the first MDS.

In this embodiment, the adding module 215 can be used to execute step S420 shown in fig. 4, and the detailed description about the adding module 215 can refer to the description about step S420.

And the monitoring module 216 is configured to monitor the WORM status of the metadata in the management range of the first MDS according to the WORM file list.

In this embodiment, the monitoring module 216 may be configured to execute step S430 shown in fig. 4, and reference may be made to the description of step S430 for a detailed description of the monitoring module 216.

To sum up, in the distributed system architecture of the multi-active metadata server, when the first MDS detects that the management of the first file needs to be switched to the management of other metadata servers, the WORM state monitoring and transferring method and apparatus provided by the present application select the second metadata server for the first file, and notify the second metadata server to take over the metadata of the first file, so as to monitor the WORM state of the first file. Therefore, under the multi-activity metadata server scene, when the metadata server for managing the file is switched, the monitoring of the WORM state can be transferred along with the switching, so that the WORM function can be realized on the multi-activity metadata server architecture.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The apparatus embodiments described above are merely illustrative, and for example, the flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

In addition, functional modules in the embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a machine-readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes. For example, MDS200 shown in figure 2 may comprise a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor to implement the WORM state monitoring transition method provided herein.

It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A WORM state monitoring and transferring method is applied to a first metadata server in a distributed storage system, wherein the first metadata server is provided with a WORM file list used for recording metadata of files needing WORM state monitoring; the method comprises the following steps:

when a first file subjected to WORM state monitoring by the first metadata server needs to be switched to be monitored by other metadata servers except the first metadata server, determining at least one second metadata server for monitoring the WORM state of the first file in the other metadata servers;

sending a first WORM adding message to the second metadata server, enabling the second metadata server to acquire metadata of the first file according to the WORM adding message, and performing WORM state monitoring on the first file according to WORM information carried by the metadata of the first file;

deleting a record of metadata of the first file from a WORM file list of the first metadata server;

wherein, after determining at least one second metadata server for the first file that monitors the WORM status of the first file among the other metadata servers, the method further comprises:

sending the metadata of the first file to the second metadata server;

adding a preset identifier to the metadata of the first file sent to the second metadata server in the WORM file list of the first metadata server;

the step of sending a first WORM addition message to the second metadata server comprises:

periodically locking the list of WORM files and traversing metadata recorded in the list of WORM files;

when detecting the metadata of the first file with the preset identification, sending a first WORM adding message to a second metadata server corresponding to the first file, wherein the first WORM adding message comprises the identification of the metadata of the first file, and the first WORM adding message is used for enabling the second metadata server to record the metadata of the first file to a WORM file list of the second metadata server according to the identification of the metadata of the first file when receiving the first WORM adding message.

2. The method as claimed in claim 1, wherein the first WORM addition message carries metadata of the first file;

and the metadata of the first file is used for enabling the second metadata server to acquire the metadata of the first file from the received first WORM addition message and record the metadata of the first file to a WORM file list of the second metadata server.

3. The method as recited in claim 1, wherein said deleting a record of metadata of the first file from a WORM file list of the first metadata server comprises:

receiving a first WORM add-back message fed back by the second metadata server according to the first WORM add-back message;

and when the first WORM addition feedback message is successful in adding the first WORM, deleting the record of the metadata of the first file from the WORM file list of the first metadata server.

4. The method of claim 1, further comprising:

the first metadata server receives a second WORM adding message sent by a third metadata server, wherein the second WORM adding message is sent by the third metadata server when a second file subjected to WORM state monitoring by the third metadata server needs to be switched to be monitored by the first metadata server;

according to the second WORM adding message, acquiring metadata of the second file and recording the metadata to a WORM file list of the first metadata server;

and monitoring the WORM state of the metadata in the management range of the first metadata server according to the WORM file list.

5. The method of claim 4, further comprising:

when detecting that a new file needing state monitoring is added into the cache, acquiring metadata of the WORM file newly added into the cache;

recording the metadata of the newly added cached WORM file to a WORM file list of the first metadata server.

6. The method of claim 1, wherein determining at least one second metadata server for the first file among the other metadata servers to manage the first file comprises:

respectively acquiring an operation load variable parameter of each metadata server in the other metadata servers, wherein the operation load variable parameter is used for representing the operation load state of the metadata server;

comparing the operational load variable parameters of the first metadata server and each metadata server;

determining the second metadata server from the other metadata servers according to the comparison result;

alternatively, the first and second electrodes may be,

receiving a selection operation instruction input by a user, wherein the selection operation instruction comprises an identifier of a metadata server selected by the user;

and determining the second metadata server according to the identifier of the metadata server.

7. The WORM state monitoring and transferring device is applied to a first metadata server in a distributed storage system, and the first metadata server is provided with a WORM file list used for recording metadata of files needing WORM state monitoring; the device comprises:

the system comprises a selection module, a first file monitoring module and a second file monitoring module, wherein the selection module is used for determining at least one second metadata server monitoring the WORM state of the first file for the first file in other metadata servers when the first file monitored by the WORM state of the first metadata server needs to be switched to be monitored by other metadata servers except the first metadata server; sending the metadata of the first file to the second metadata server; adding a preset identifier to the metadata of the first file sent to the second metadata server in the WORM file list of the first metadata server;

a notification module, configured to send a first WORM addition message to the second metadata server, so that the second metadata server obtains metadata of the first file according to the WORM addition message, and performs WORM state monitoring on the first file according to WORM information carried by the metadata of the first file; wherein the step of sending a first WORM addition message to the second metadata server comprises: periodically locking the list of WORM files and traversing metadata recorded in the list of WORM files; when detecting the metadata of the first file with the preset identification, sending a first WORM adding message to a second metadata server corresponding to the first file, wherein the first WORM adding message comprises the identification of the metadata of the first file, and the first WORM adding message is used for enabling the second metadata server to record the metadata of the first file to a WORM file list of the second metadata server according to the identification of the metadata of the first file when receiving the first WORM adding message;

a deletion module to delete a record of metadata of the first file from a WORM file list of the first metadata server.

8. The apparatus of claim 7, further comprising:

a receiving module, configured to receive a second WORM addition message sent by a third metadata server, where the second WORM addition message is sent by the third metadata server when a second file whose WORM status is monitored by the third metadata server needs to be switched to be monitored by the first metadata server;

the adding module is used for acquiring the metadata of the second file according to the second WORM adding message and recording the metadata to a WORM file list of the first metadata server;

and the monitoring module is used for monitoring the WORM state of the metadata in the management range of the first metadata server according to the WORM file list.

9. The apparatus according to claim 7, characterized in that the selection module is specifically configured to,

alternatively, the first and second electrodes may be,