KR20110070677A - Apparatus and method of processing failure data recovery in the asymmetric clustering file system - Google Patents

Abstract

PURPOSE: Apparatus and method for processing failure data recovery in an asymmetric clustering file system are provided to efficiently and rapidly error data by distributing the error data to a data server and recovering the error data by the data server. CONSTITUTION: A chunk list in which a data server of a second data server group is recovered is received(S40). The data server is not included in a first data server group including a failed data server. The data server requests chunk data required for recovering an error chunk to the rest data severs of the first data server group(S50). The data server recovers the error chunk on a basis of the chunk data(S52). The data server transmits the recovery complete message to a metadata server(S56).

Description

Apparatus and method of processing failure data recovery in the asymmetric clustering file system}

The present invention relates to an apparatus and method for error recovery in an asymmetric clustering file system, and more particularly, to an apparatus and method for distributed processing of error recovery due to a data server failure in an asymmetric clustering file system.

The present invention is derived from a study conducted as part of the IT growth engine technology development project of the Ministry of Knowledge Economy [Task Management No .: 2007-S-016-03, Title: Development of a low-cost large-scale global Internet service solution].

In general, an asymmetric clustering file system includes a metadata server that manages file metadata, a plurality of data servers that manage data in the file, and a plurality of clients that store or retrieve the file.

The metadata server, the plurality of data servers, and the plurality of clients communicate with each other over a local network.

Multiple data servers can be provided in a single, massive storage space through virtualization technology. Free storage management is possible by adding / deleting volumes in the data server or data server.

In such a system of managing a plurality of data servers, a failure rate proportional to the number of servers is considered. As a result, in systems that manage multiple data servers, as in Level 5 of Redundant Array of Inexpensive Disks (RAID), data is distributed, parity is provided for recovery, or mirroring technology is used to place copies of data. . Mirroring technology provides low storage efficiency due to redundant data storage. Accordingly, a data distributed storage structure using parity is preferred when fault tolerance is required.

The data distributed storage structure using parity may recover data stored in an error device using parity when a single error occurs among storage devices that store data. The recovery process is recovered by performing an error correction scheme (eg, exclusive-OR) of the parity with other data constituting the parity. To do this, a single data recovery process must involve read processing for multiple data and parities.

In the related art, a metadata server that detects a storage device error is mostly performed to recover data stored in the device.

The present invention has been proposed in view of the above-described conventional situation, and an error recovery processing apparatus in an asymmetric clustering file system that improves efficiency in asymmetric clustering file system in the event of a data server failure in a metadata server, and The purpose is to provide a method.

The present invention is characterized in that in the structure of distributing and storing data and parity to a plurality of data servers in an asymmetric clustering file system, data recovery due to a single data server failure is distributed and processed to a plurality of data servers.

In order to achieve the above object, an error recovery processing method in an asymmetric clustering file system according to a preferred embodiment of the present invention is a data server group different from the data server group including a failed data server among a plurality of data server groups. Receiving, by the data server, a list of chunks in need of recovery; Requesting, by a data server of another data server group, chunk data necessary for recovering an error chunk from data servers other than the failed data server among the data server groups; And recovering, by the data server of another data server group, the error chunk based on the chunk data.

Each of the plurality of data server groups includes the same number of data servers as the sum of the number of file data divided in chunks and the number of error recovery parities for the file data.

The chunk list includes a chunk identifier for recovery by one or more disk identifiers, a chunk identifier for storing recovery data, and a chunk information list for recovery.

The chunk identifier that needs to be recovered is identification information of the selected chunk among the chunks stored in the failed data server.

The chunk identifier in which the repair data is to be stored is identification information of the chunk in which the error chunk is recovered and newly stored.

The list of chunk information needed for recovery is a list of chunk information for data and parity needed to recover the error chunk.

The chunk information includes data server IP address, disk identifier, and chunk identifier information in which the chunk is stored.

Preferably, after the recovering step, the data server of another data server group further includes transmitting a recovery complete message to the metadata server.

Preferably, the data server of the other data server group, further comprising the step of storing the recovery data according to the recovery of the error chunk in the chunk list.

Preferably, the method further includes performing processing corresponding to the write request as the data server of the other data server group receives the write request from the client.

The write request processing step may include: checking whether a corresponding chunk exists in the chunk list by a write request; And if it is determined that the chunk does not exist, writing and storing data in the chunk.

And after the storing step, notify the metadata server of the completion of the recovery.

The write request processing step may include: canceling the recovery and deleting the chunk information from the chunk list if the chunk exists but the recovery of the chunk is in progress; And storing the data by the write request in the corresponding chunk.

The write request processing step may include: deleting the chunk information from the chunk list when the chunk exists, but the recovery of the chunk has not started; And storing the data by the write request in the corresponding chunk.

An error recovery processing apparatus in an asymmetric clustering file system according to a preferred embodiment of the present invention includes a receiving unit for receiving a list of chunks to be recovered from a metadata server; A recovery unit for recovering the error chunk based on the chunk data necessary to recover the error chunk; And a controller for requesting chunk data to the remaining data servers except for the failed data server in the data server group and transmitting the received chunk data to the recovery unit.

The chunk list includes a chunk identifier for recovery by one or more disk identifiers, a chunk identifier for storing recovery data, and a chunk information list for recovery.

The chunk identifier that needs to be recovered is identification information of the selected chunk among the chunks stored in the failed data server.

The chunk identifier in which the repair data is to be stored is identification information of the chunk in which the error chunk is recovered and newly stored.

The list of chunk information needed for recovery is a list of chunk information for data and parity needed to recover the error chunk.

The control unit transmits a restoration complete message to the metadata server when the restoration is completed.

According to the present invention having such a configuration, since a plurality of data servers distribute and recover error data, a single metadata server can provide efficient and fast recovery compared to a method of handling error data.

1 is a diagram showing the structure of an asymmetric clustering file system to which the present invention is applied.
FIG. 2 is a diagram illustrating a method of distributedly storing data and parity in an asymmetric clustering file system to which the present invention is applied.
FIG. 3 is a diagram for describing a recovery information structure configured in a metadata server for data recovery distribution processing in an asymmetric clustering file system to which the present invention is applied.
4 is a block diagram illustrating an internal configuration of a data server in an asymmetric clustering file system to which the present invention is applied.
FIG. 5 is a diagram illustrating a recovery management thread processing flow performed in a metadata server in an asymmetric clustering file system to which the present invention is applied.
FIG. 6 is a diagram illustrating a processing flow when a metadata server receives a repair complete message in an asymmetric clustering file system to which the present invention is applied.
7 is a diagram illustrating a processing flow for recovering an error chunk in a data server in an asymmetric clustering file system to which the present invention is applied.
8 is a diagram illustrating a processing flow when a data server receives a write request from a client in an asymmetric clustering file system to which the present invention is applied.
9 is a diagram illustrating a read processing flow in a client in an asymmetric clustering file system to which the present invention is applied.

Hereinafter, an error recovery processing apparatus and method in an asymmetric clustering file system according to an embodiment of the present invention will be described with reference to the accompanying drawings. Prior to the detailed description of the present invention, terms and words used in the present specification and claims should not be construed as limited to ordinary or dictionary terms. Therefore, the embodiments described in the specification and the drawings shown in the drawings are only one of the most preferred embodiments of the present invention and do not represent all of the technical idea of the present invention, various modifications that can be replaced at the time of the present application It should be understood that there may be equivalents and variations.

1 is a diagram showing the structure of an asymmetric clustering file system to which the present invention is applied.

The metadata server 10 manages metadata of the file.

The plurality of data servers 20a to 20n 20 manage data of files. Each data server is equipped with one or more disk storage devices 22a. The storage space size of each data server is determined by the number of disks mounted.

Clients 30a-30n; 30 access the file.

The metadata server 10, the plurality of data servers 20a to 20n; 20, and the clients 30a to 30n; 30 are connected to and communicate with each other through a network 40 such as Ethernet.

According to the present invention, a file stored from the clients 30a to 30n is divided into chunks in a predetermined unit and stored in advance in different data servers 20a to 20n, and an error due to a failure of one data server occurs. In this case, the parity for recovering the data is applied to a structure previously stored in different data servers 20a to 20n. This can be more easily understood from the description of FIG. 2 to be described later.

FIG. 2 is a diagram illustrating a method of distributedly storing data and parity in an asymmetric clustering file system to which the present invention is applied.

Client 30a divides file A 50 into units (eg, chunks). Here, the division size is a value that is set in advance or defined by a user configuring the file system, such as a value obtained by dividing the size of the file A 50 by the number of data servers to be stored.

The client 30a generates the parity 54 for each of the predetermined number of data 51, 52, and 53 generated in this manner. The definition of the number of data chunks constituting parity 54 may be determined by the user. The data servers 20a, 20b, 20c, and 20n to store the data 51, 52, and 54 and the parity 54 are selected by considering the storage space utilization of each data server in the metadata server 10. The metadata server 10 notifies the client 30a of the selected content.

In FIG. 2, data 51 is stored in data server 20c, data 52 is stored in data server 20a, data 53 is stored in data server 20n, and parity 54 is stored. It is assumed that it is stored in the data server 20b. In FIG. 2, it is assumed that four data servers 20a, 20b, 20c, and 20n form one data server group among n (n ≧ 5) data servers. Under this assumption, if any data server (eg, 20a) in the data server group (group) fails, the data server of another data server group that exists separately from the data servers 20a, 20b, 20c, and 20n (i.e., Is a data server selected by the metadata server 10, which is a normal data server).

3 is a diagram illustrating a recovery information structure configured in a metadata server for data recovery distribution processing in an asymmetric clustering file system to which the present invention is applied.

The metadata server 10 detects a failure of the data server in each data server group. When the metadata server 10 detects a failure of the data server, the metadata server 10 checks the asymmetric clustering file system to configure a recovery information structure. The metadata server 10 transmits the configured recovery information structure to a data server of a data server group different from the data server group including the failed data server.

The recovery information structure includes data server information 60 including a list of data server IP addresses and disk identifier information for each data server. In addition, the disc identifier information list includes disc identifier information 70 including a chunk identifier for recovery, a chunk identifier for storing recovery data, and a chunk information list for recovery for each disc identifier. The list of chunk information required for recovery includes chunk information 80 including the data server IP address where the chunk is stored, the disk identifier and the chunk identifier.

Here, the chunk identifier to be recovered is identification information of the selected chunk among the chunks stored in the failed data server. The chunk identifier in which the repair data is to be stored is identification information of the chunk in which the error chunk is recovered and newly stored. The list of chunk information required for recovery is a list of data and parity chunk information needed for recovering the error chunk. One parity chunk and data chunks included in calculating parity are referred to as one stripe 90.

4 is a block diagram illustrating an internal configuration of a data server in an asymmetric clustering file system to which the present invention is applied.

The data server includes a receiver 100, a buffer 110, a recoverer 120, a controller 130, and a storage 140. Here, the data server may be understood to mean each of the data servers 20a to 20n illustrated in FIG. 1. However, the failed data server cannot receive the list of chunks that need to be provided from the metadata server 10.

The receiver 100 receives a list of chunks to be repaired provided from the metadata server 10. Here, the received chunk list is a list of disc identifier information 70. The disc identifier information 70 is replaced with the description of FIG. 3 described above.

The buffer 110 stores the recovery data for recovering the error chunk. That is, the buffer 110 temporarily stores the recovery data generated as the error chunk is recovered. In FIG. 4, only one buffer 110 is illustrated, but a plurality of buffers 110 may be implemented.

The recovery unit 120 recovers the error chunk based on the chunk data necessary to recover the error chunk. Here, the chunk data necessary for recovering the error chunks is owned by the remaining data servers except the failed data server in the data server group.

The controller 130 requests chunk data (that is, chunk data necessary to recover an error chunk) from the remaining data servers except the failed data server in the data server group. The controller 130 transmits the chunk data received through the receiver 100 to the recovery unit 120. The controller 130 transmits a restoration completion message to the metadata server 10 when the restoration is completed by the restoration unit 120.

The storage 140 stores file data in chunk units. Here, the storage 140 may be understood to correspond to the disk storage 22a of FIG. 1.

FIG. 5 is a diagram illustrating a recovery management thread processing flow performed in a metadata server in an asymmetric clustering file system to which the present invention is applied. That is, FIG. 5 is a flowchart of processing of a data recovery management thread that is performed when the metadata server 10 detects a data server failure.

The metadata server 10 first initializes a recovery information structure (preferably, data server information 60 and disk identifier information 70 in the form of a list) (S10).

The metadata server 10 checks the asymmetric clustering file system (S12).

The metadata server 10 creates a list of chunks stored in the failed data server through inspection (S14). Here, the failed data server assumes that four data servers 20a, 20b, 20c, and 20n are one data server group, and assumes that the data server 20a has failed in the corresponding data server group.

The metadata server 10 sets the states of chunks (that is, error chunks) stored in the failed data server 20a to a recovery state (S16).

The metadata server 10 stores the first to last chunks of the chunk list thus created in the initialized recovery information structure (S18). That is, when the chunk identifier to be recovered from the chunk list is selected, the metadata server 10 allocates a new chunk to store the recovered chunk data (S20). Then, the metadata server 10 checks the chunk information 80 of the remaining data and parity belonging to the stripe 90 to which the selected chunk belongs and stores it in the recovery information structure (S22). Here, the stored location is stored in the information structure corresponding to the data server and disk on which the newly allocated chunk is generated.

When the last chunk is completed, the metadata server 10 transmits the contents stored in the disk identifier information 70 list from the beginning of the data server information 60 list to the corresponding data server to perform the recovery operation (S26). That is, the metadata server 10 transmits the list of chunks to be repaired to the corresponding data server to perform the recovery activity. Here, the data server to perform the recovery activity is a data server of another data server group which exists separately from the data server group including the failed data server 20a.

Here, if the transmission process (S26) to the corresponding data server to perform the recovery activity is completed up to the contents of the last data server (that is, all data servers 20b, 20c, 20n) (YES in S24), the thread is terminated. do.

FIG. 6 is a diagram illustrating a processing flow when a metadata server receives a repair complete message in an asymmetric clustering file system to which the present invention is applied. First, it is assumed that the metadata server 10 has a recovery information structure worked as shown in FIG. 5.

The metadata server 10 receives a recovery completion message from a data server (that is, a data server that has performed a recovery activity) (S30).

The metadata server 10 finds the data server information 60 and the disk identifier information 70 by using the data server IP address and the disk identifier in the recovery information structure. Thereafter, the metadata server 10 searches for the corresponding chunk information by comparing the received chunk identifier with the chunk identifier where the recovery data is to be stored (S32).

The metadata server 10 deletes corresponding chunk information having information on the error chunk in which the recovery is completed in the recovery information structure (S34).

Then, the metadata server 10 modifies the error chunk information in the file metadata into newly recovered chunk information (S36).

7 is a diagram illustrating a processing flow of a data server recovering an error chunk in an asymmetric clustering file system to which the present invention is applied.

First, the data server to perform a recovery activity receives a list of chunks to be recovered from the metadata server 10 (S40). The chunk list received here is a list of disc identifier information 70. Here, the data server to perform the recovery activity is a data server of another data server group which exists separately from the data server group including the failed data server.

The data server to perform the recovery activity starts from the first disk of the received chunk list and ends when processing is completed until the last disk (YES in S42).

The data server to perform the recovery operation performs from the beginning to the last chunk of the chunk list in which the contents of the error chunks are loaded for each disk (S44). In other words, the data server to perform the recovery activity first allocates a buffer to temporarily store the chunks being recovered (S46). When a buffer is allocated, the data server to perform recovery activities performs recovery activities as described in the following steps. The data server to perform the recovery activity checks whether the chunks necessary for recovering the error chunks are the last data server among the stored data servers (S48).

As a result of the check, if not last, the data server to perform the recovery activity requests the corresponding chunk data to the remaining data servers (for example, 20b, 20c, and 20n) that are not broken (S50).

Thereafter, upon receiving the requested chunk data, the data server for recovery activity performs an error data recovery process (for example, exclusive-OR) by using the contents of the temporary buffer and the received data (S52). Since the error data recovery process is performed, the data server to perform the above recovery activity will be the data data server performing the recovery activity below.

When this error data recovery process is completed using the last chunk of the last data server (that is, all data servers (20b, 20c, 20n) that have not failed), the data server that performed the recovery activity will recover the recovery data stored in the temporary buffer. The newly allocated chunk file is stored (S54).

The data server performing the recovery activity notifies the metadata server 10 that the recovery of the corresponding error chunk is completed when the saving is completed (S56). That is, the data server performing the recovery activity sends a recovery completion message to the metadata server 10.

Then, the data server performing the recovery activity deletes the recovered chunk information from the list of chunks to be recovered (S58).

8 is a diagram illustrating a processing flow when a data server receives a write request from a client in an asymmetric clustering file system to which the present invention is applied.

First, the data server, which is the subject of the recovery activity, receives a write request from the client (any one of 30a to 30n) (S60). Here, the data server, which is the subject of the recovery activity, is a data server of another data server group which exists separately from the data server group including the failed data server.

Subsequently, the data server which is the subject of the recovery activity checks whether the corresponding chunk exists in the recovery chunk list being processed (S62).

As a result of the check, if it is not present (NO in S62), the data server, which is the subject of the recovery activity, interprets that the recovery for the chunk is completed and processes the write to the chunk file (S64).

On the contrary, if there exists (YES in S62) and the recovery for the corresponding chunk is currently in progress (YES in S66), the data server, which is the subject of the recovery activity, stops the recovery when the current I / O command is completed (S68). ). Then, the data server that is the subject of the recovery activity deletes the corresponding chunk information from the recovery chunk list (S70). Of course, if it exists in the recovery chunk list but recovery has not yet started, the corresponding chunk information is deleted from the recovery chunk list. Subsequently, the data server, which is the subject of the recovery activity, stores the data requested to be written in the corresponding chunk (S72).

As such, when the recovery is completed or the recovery is canceled and the storage of the write data is completed, the data server, which is the subject of the recovery activity, informs the metadata server 10 that the recovery of the chunk is completed (S74). That is, the data server, which is the subject of the recovery activity, sends a recovery completion message to the metadata server 10.

9 is a diagram illustrating a read processing flow in a client in an asymmetric clustering file system to which the present invention is applied. 9 is a diagram illustrating a process of receiving and executing a client when a read request is made by an application layer, which is an upper layer of the client.

First, the client (any one of 30a to 30n) receives a read request (S80).

Upon receiving the read request, the client requests metadata about the file to the metadata server 10 (S82).

Thereafter, the client receives metadata information from the metadata server 10 (S84).

Subsequently, the client checks whether the state value of the chunk to be read currently is based on the received metadata information (S86).

If it is confirmed that the recovery state (YES in S86), the client first allocates a temporary buffer for storing the recovery data (S88). Here, the temporary buffer allocation may be equal to the number of data servers in which chunks required for recovery are stored. For example, suppose four data servers are a group of data servers, and if one data server fails, the remaining three data servers become data servers storing chunks required for recovery.

If the temporary buffer allocation to the last data server is not completed (No in S90), the client requests the chunk data to the last data server in which the chunk necessary for recovery is stored (S92). When the client receives the requested chunk data, the client performs an error data recovery process using the contents of the temporary buffer and the received chunk data (S94).

When the error data recovery process is completed up to the last data server, the client returns the data (S96).

As a result of the checking in step S86, if it is not in the recovery state, the client requests data to the data server in which the chunk is stored (S98) and then performs the operation of step S96.

On the other hand, the present invention is not limited only to the above-described embodiments and can be carried out by modifications and variations within the scope not departing from the gist of the present invention, the technical idea that such modifications and variations are also within the scope of the claims Must see

10: metadata server 20a to 20n: data server
30a ~ 30n: Client 40: Network
100: receiver 110: buffer
120: recovery unit 130 control unit
140: storage unit

Claims (20)

Receiving, by a data server of a data server group different from the data server group including the failed data server among the plurality of data server groups, a list of chunks to be restored;
Requesting, by a data server of the other data server group, chunk data necessary for recovering an error chunk from the data server group except for the failed data server; And
Restoring the error chunk based on the chunk data by a data server of the other data server group. The method according to claim 1,
Each of the plurality of data server groups includes the same number of data servers as the sum of the number of file data divided in chunks and the number of error recovery parity for the file data. Error recovery processing in an asymmetric clustering file system, characterized in that the. The method according to claim 1,
And the chunk list includes a chunk identifier for recovery by one or more disk identifiers, a chunk identifier for storing recovery data, and a chunk information list for recovery. The method according to claim 3,
And the chunk identifier to be recovered is identification information of the selected chunk among the chunks stored in the failed data server. The method according to claim 3,
And a chunk identifier in which the repair data is to be stored is identification information of a chunk in which the error chunk is recovered and newly stored. The method according to claim 3,
And the chunk information list necessary for the recovery is a list of the chunk information for the data and parity necessary for recovering the error chunk. The method of claim 6,
The chunk information includes a data server IP address, a disk identifier, and a chunk identifier information on which the chunk is stored. The method according to claim 1,
After the recovering step, the data server of the other data server group further comprises transmitting a recovery complete message to a metadata server. The method according to claim 1,
And storing, by the data server of the other data server group, the recovery data according to the recovery of the error chunk in the chunk list. The method according to claim 1,
And processing corresponding to the write request as the data server of the other data server group receives the write request from the client. The method according to claim 10,
The write request processing step,
Checking whether the corresponding chunk exists in the chunk list by the write request; And
And writing the data into the chunk and storing the chunk if the chunk does not exist as a result of the checking. The method of claim 11,
And notifying the metadata server of the completion of the recovery after the storing step. The method of claim 11,
The write request processing step,
Canceling the recovery and deleting the chunk information from the chunk list if the chunk exists, but the recovery of the chunk is in progress; And
And storing the data in response to the write request in the corresponding chunk. The method of claim 11,
The write request processing step,
Deleting the chunk information from the chunk list when the chunk exists but recovery of the chunk is not started; And
And storing the data in response to the write request in the corresponding chunk. A receiver for receiving a list of chunks to be recovered from the metadata server;
A recovery unit for recovering the error chunk based on the chunk data necessary to recover the error chunk; And
Error in the asymmetric clustering file system comprising a; control unit for requesting the chunk data to the remaining data servers except the failed data server in the data server group, and transmits the received chunk data to the recovery unit Recovery processing unit. The method according to claim 15,
And the chunk list includes a chunk identifier for recovery by one or more disk identifiers, a chunk identifier for storing recovery data, and a chunk information list for recovery. The method according to claim 16,
And the chunk identifier to be repaired is identification information of the selected chunk among the chunks stored in the failed data server. The method according to claim 16,
An apparatus for error recovery in an asymmetric clustering file system, wherein the chunk identifier for storing the repair data is identification information of the chunk in which the error chunk is restored and newly stored. The method according to claim 16,
And the chunk information list necessary for the recovery is a list of the chunk information for the data and parity necessary for recovering the error chunk. The method according to claim 15,
And the control unit transmits a restoration completion message to the metadata server when the restoration is completed in the restoration unit.

Images