KR101078287B1 - Method Recovering Data Server at the Applying Multiple Reproduce Dispersion File System and Metadata Storage and Save Method Thereof - Google Patents

Abstract

The present invention discloses a recovery method of a data server in a distributed file system supporting multiple replications, and a metadata storage and storage method suitable thereto. The present invention provides a data storage device comprising: a metadata area for storing metadata related to attributes of a file including location information; And a block area for storing contents of block indexes classified for each data server storing the block in which the file is stored, and when a failure occurs in the data server, supporting the restoration of the corresponding data server loss using the block index. Has its features.

The present invention distinguishes and stores file attributes and metadata of a block index, and uses the same to reconstruct lost data by reconstructing index information for a block in which a file exists and selecting another data server in which the same block is stored. There is an effect that can be easily recovered.

Distributed File System, Failure, Recovery, Metadata Server, Data Server

Description

{Method Recovering Data Server at the Applying Multiple Reproduce Dispersion File System and Metadata Storage and Save Method Thereof}

The present invention relates to a method for recovering a data server and a method for storing and storing metadata appropriately in a distributed file system supporting multiple replication, and in particular, distinguishes and stores metadata of file attributes and block indexes, and uses the data server Recovery method of a data server in a distributed file system that supports multiple replication to easily recover lost data by reconstructing index information for a block in which a file exists and selecting another data server in which the same block is stored. A suitable metadata storage and storage method is provided.

The present invention is derived from the research conducted as part of the IT new growth engine core technology development project of the Ministry of Information and Communication and the Ministry of Information and Communication Research and Development. Development].

Most of the data stored in the conventional storage environment has been business-related data generated by companies or institutions, but the recent rapid development of the Internet technology is also rapidly increasing the storage of multimedia data such as blogs, photos, videos. In particular, large portal companies that provide Internet services at home and abroad are newly generating, storing, and managing data of several terabytes (TB) to several tens of terabytes (TB) each month. However, the existing storage structure environment has many problems in storage scalability and ease of management, so it is not sufficient to replace the ever-changing service environment.

Recent technological advances in storage systems or file systems are due to improvements in scalability and performance of storage systems. Specifically, in terms of the file system structure, some systems have separated the data input / output path of the file and the metadata management path of the file to increase the scalability and performance of the distributed storage system. By applying this structure, the client system can directly access the storage devices, and by distributing the metadata, the bottleneck caused by frequent file metadata access can be eliminated to increase the storage scalability.

Enterprise-class storage solutions built on this structure include IBM's StorageTank, Panasas 'ActiveScale Storage Cluster, Cluster Filesystems' Luster, and Google's Google Filesystem. Google's Google Filesystem has the advantage of being more available by replicating block data for one file to multiple data servers.

In this network-based distributed file system environment, client file systems, metadata servers, and data servers communicate over the network to provide input and output of data. To access a specific file, the client obtains the location information of the block in which the actual data of the file is stored from the metadata server, and then accesses the data server where the block is located and reads the data of the block.

1 is a block diagram illustrating a multiple replication based distributed file system according to the prior art.
As shown in FIG. 1, the multiple replication-based distributed file system includes a client 100 which is a user terminal operating as a separate system, a metadata server 200 that stores metadata such as file attributes and block positions, and the like. It consists of one or more data servers 300A, 300B, and 300C that store data in files, which are networked and share information.

The client 100 may be a personal terminal (PC), a personal digital assistant (PDA), and a mobile phone that are operated by individual systems.

The metadata server 200 stores the metadata of the data stored in the data servers 300A, 300B, and 300C, including the file's attributes such as the file size, creation time, owner, and the block position of the file. To provide.

The data servers 300A, 300B, and 300C store actual data blocks related to attributes of the file of the metadata server 200 and provide them at the request of the client 100.

The same block may be replicated and stored in one or more physically separated data servers 300A, 300B, and 300C to increase the availability of the file system.

Here, the data servers 300A, 300B, and 300C divide one file into several blocks or store them as one continuous file.

Meanwhile, the metadata server 200 may be disposed as a separate device from the data servers 300A, 300B, and 300C, and may be configured with the same device as the data server 300A, 300B, or 300C or the client 100. .
Hereinafter, the operation of the metadata server 200 and the data servers 300A, 300B, and 300C will be described.

For example, the client 100 who wants to read a file called "example.txt" is provided with metadata information such as the properties of the "example.txt" file and the location of a block from the metadata server 200. The data server 300A, 300B, or 300C in which the block is located is identified from the request, and the data server requests data of the block. Then, the data server provides the client 100 with the data of the corresponding block stored in its metadata repository 201.

In this case, since the block (block 1) requested by the client 100 may exist in one or more data servers 300A and 300C, as shown in FIG. 1, the client 100 may be the nearest data server (for example, a network). , I / O performance based on locality can be improved by importing the requested block from 300A).

Such a multiple replication environment may acquire the same block from another data server (e.g. 300C) that operates normally when one data server (e.g. 300A) in which the block to be searched is stored has failed and is inaccessible. The file system is highly available.

In addition, unlike RAID1, which supports server-level replication, block-by-file replication is performed on a file-by-block basis, which allows flexible designation of the number of blocks to be replicated according to the system operating environment or application access pattern. There is this.

In this case, a block is a logical unit containing data, and one file may exist in one block or one file may exist in one or more blocks.

However, even in a distributed file system that supports multiple replication of such blocks, loss of replicated blocks may occur when an exception occurs such as a data server failure.

For example, even if two of the three replication blocks for a file fail, a service can be provided if one replication block remains. However, if two failed replication blocks are not recovered continuously, the last one block may be lost by another failure, so only the metadata of the file exists and the block where the actual data is stored does not exist. The recovery itself would be impossible.

In order to prepare for such a case, a distributed file system that supports multiple replication generally recovers failed blocks using the following methods within the minimum availability.

The first method is a method of loading all block information into the memory of the metadata server 200 and recovering the block after collecting the block information in which the failure occurred from the memory when a failure situation occurs. However, this method has a drawback that if the block information to be managed increases, not only system performance is degraded because excessive memory is consumed, but also the amount of block information beyond the physical memory capacity of the metadata server 200 cannot be stored. . Therefore, even though there is sufficient free space on the disk of the data servers, it may be impossible to create a new file due to the memory shortage of the metadata server 200.

The second method is to store all block information in a separate database, recover the block after collecting the block information from the database when a failure occurs.
In detail, a dedicated database for storing block information is constructed in the metadata server 200, and the database is edited and managed whenever a change in a block occurs. However, this method has a problem that it is difficult to design an efficient table structure for processing millions of data as well as the system operation flexibility because the file system is database-dependent.

The third method is to recover blocks after collecting all block information by searching all metadata whenever a failure occurs without managing separate block information. However, this method also requires a procedure to collect blocks belonging to the failed data server, even if one data server fails, so the recovery efficiency is low. There is.

The present invention distinguishes and stores file attributes and metadata of a block index, and uses the same to reconstruct lost data by reconstructing index information for a block in which a file exists and selecting another data server in which the same block is stored. It is an object of the present invention to provide a method for recovering a data server and a method for storing and storing metadata appropriately in a distributed file system supporting multiple replications that can be easily recovered.

In order to achieve the above object, in the distributed file system supporting multiple replications according to the present invention, the storage of the metadata server is a storage of the metadata server that manages metadata about files stored in block units in at least one data server. A metadata field comprising: a metadata area for storing metadata related to attributes of a file including location information; And a block area for storing a block index for each data server storing a block including the file, and if a failure occurs in the data server, supporting a restoration of a corresponding data server loss using the block index. It has its features.
Here, the attribute of the file relates to information including the name of the file, the size of the file, the file access authority and the location where the file is stored, and the block area is reconfigured every time the system of the metadata server is started. A basic file for storing block index information of a state; The initial state has a size of 0 and an additional file for additionally storing a new block information entry each time a new block is added; In the initial state, the size is 0, and the content of the block index is managed by dividing the block information entry to be deleted each time a block is deleted into a deletion file.
In this case, the addition file and the deletion file may only add a new block information entry, and do not allow the deletion of contents, and the block information entry includes a block identifier and a file path to which the block belongs.
According to another aspect of the present invention, a method for storing metadata for data stored in one or more data servers by a metadata server, the method comprising: (a) dividing a metadata storage area into a metadata area and a block area; (b) receiving metadata from a data server and storing attribute related information of a file in the metadata area; (c) generating a basic file for storing information of blocks of an initial state in the block area; (d) if the information of the block to be added or deleted from the initial state is present, adding the information of the block to be added or deleted from the initial state to the additional file or the deletion file. Metadata storage method is provided in a distributed file system that supports.
Here, step (d) includes (d-1) inserting a new block information entry at the end of the additional file when a new block is added; (d-2) if a block to be deleted exists, inserting a block information entry to be deleted at the end of the deletion file, and after step (d), if a new data server is added, step (b) It is preferable to further include the step of performing the step (d) repeatedly.

delete

delete

delete

delete

According to still another aspect of the present invention, there is provided a method for a metadata server to recover a failed data server, the method comprising: (f) detecting a failed data server; (g) reconstructing the crash region to reconstruct block information before failure occurs; (h) searching for and selecting other data servers storing the same blocks as the block to be recovered and requesting each of the same blocks; (i) receiving each same block from the other data servers; (j) a method for recovering a data server in a distributed file system supporting multiple replications, characterized in that it comprises recovering the one data server with each received same block and notifying a completion of the recovery. .
Here, the detection of the failure in step (f) is performed by detection of a phenomenon including disconnection of a network, abnormal termination of the data server processor, power failure, and after step (j), (k) Determining success or failure; (l) if the recovery is successful, deleting the crash region; and (m) if the recovery fails, returning to step (g).
Meanwhile, in the step (k), whether the recovery is successful or not is determined based on a result of comparing the reconstructed crash region with the result of the processing collected from the one data server, and the step (g) includes the step (g-1). Allocating a crash region; (g-2) copying a basic file in which the block index information of the initial state of the one data server is stored in the crash region; (g-3) adding contents of an additional file in which block index information added from an initial state of the one data server is stored in the crash region; (g-4) adding the contents of the deletion file in which the block index information deleted from the initial state of the one data server is stored in the crash region.
In addition, step (h) may include (h-1) retrieving the number of identical blocks available for recovery and the location of each identical block from the metadata; (h-2) selecting each other data server to perform re-replication among data servers in which each searched same block is stored; (h-3) constructing a list of {same block, another data server in which the same block is stored, one data server} from the search result; (h-4) sorting the list by each other data server in which the same block is stored; (h-5) transmitting a command for requesting the same block to the other data servers.
In this case, in the step (h-2), the other data server is preferably selected in consideration of a system situation including a network topology structure and a system load.

delete

delete

delete

delete

In a distributed file system supporting multiple replications according to the present invention, a method for recovering a data server and a method for storing and storing metadata according to the present invention distinguish and store file attributes and metadata of a block index, and use the same to store a file in case of a data server failure. The lost data can be easily recovered by reconstructing index information of the existing block and selecting another data server in which the same block is stored.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following embodiments are provided to those skilled in the art to fully understand the present invention, can be modified in various forms, the scope of the present invention is limited to the embodiments described below no.

2 and 3 are block diagrams illustrating a form of metadata storage in a distributed file system supporting multiple replications according to an embodiment of the present invention.
As shown in FIG. 2, the metadata server 200 divides and manages the metadata repository 201 into a metadata area 210 managing a metadata of a file and a block area 220 managing a block index. .

The metadata area 210 is an area for managing a file namespace tree of a file and represents a hierarchical structure of each directory and file (block 220).
In addition, the metadata area 210 stores and manages metadata, which is information about attributes of a file such as names, sizes, permissions, and location information of blocks.

Block area 220 is an area that manages the information of all data server (data server # 1 to data server #N) blocks, each for fast recovery information collection of the failure of a specific data server (for example, data server # 1) Entries are stored in a tree for each data server (block 221).

As such, the metadata server 200 may store the entries for each data server to obtain desired block information without searching the entire block index when a failure occurs in a specific data server.

The block index 222 exists for every data server entry and is used to track information in blocks stored in a separate data server.
As shown in FIG. 3, the block index 222 may include three types of basic files 223, additional files 224, and deleted files 225 to track changes such as adding and deleting blocks in real time. It is desirable to be managed separately (block 222).

The basic file 223 is reconfigured at system startup of the metadata server 200 or when one data server (eg, data server # 1) in which the failure occurs is recovered from the failure, and is not changed otherwise.

In this case, as shown in FIG. 3, the basic file 223 stores block information in any order and manages block information entries in the form of [block identifier, file path to which the block belongs].

The additional file 224 is reset to zero size when the base file 223 is reconstructed, and then adds information about the addition of a new block.

Specifically, as shown in FIG. 3, each time a new block is added, a new block information entry is inserted at the end of the additional file 224, and the block information entry is in the form of [block identifier, file path to which the block belongs]. It consists of.

The delete file 225 is reset to zero when the base file 223 is reconstructed, and then adds information about the deleted file when the block to be deleted occurs.

Specifically, as shown in FIG. 3, each time a new block is deleted, a new block information entry is inserted at the end of the deletion file 225, and the block information entry is in the form of [block identifier, file path to which the block belongs]. It consists of.

In this case, the additional file 224 and the deletion file 225 have attributes that allow the addition of new data but do not allow the change or deletion of existing entries.

4 is a flowchart illustrating a method of configuring the block index 222 by the metadata server 200 according to an embodiment of the present invention.
In FIG. 4, as shown, blocks # 1, block # 2, and "a.txt", "b.txt", and "c.txt" files exist in the network where the metadata server 200 is started. Assume that only data server # 1 with block # 3 exists.

In this case, the storage space of the metadata server 200 is divided into a metadata area 210 for managing metadata of a file and a block area 220 for managing a block index.
In detail, the metadata server 200 receives metadata from the data server # 1 existing in the network after starting the operation, and stores the attribute related information of the file in the metadata area. Like the blocks 420 and 430, the basic file 223, the additional file 224, and the deletion file 225 are stored.
Block 410 indicates a basic file 223 indicating that files "a.txt", "b.txt", and "c.txt" are stored in blocks # 1, # 2, and # 3 of the data server # 1, respectively. Shown.

When block 420 is added a new file called "d.txt" containing block # 4 (S420), the additional file 224, the information (block # 4, d.txt) added to the end of the new block at the end Shown.

When the block “430” including the block # 2 is deleted (S430), the block 430 may include a deletion file 225 having information (blocks # 2 and b.txt) added to the end of the block. Shown.

At this time, the basic file 223 is not changed except when the data server (eg, data server # 1) in which the metadata server 200 system is restarted or malfunctions is restored.

That is, even if the information on the block to be deleted is included in the additional file 223 or the deletion file 224, the basic file 222 is not changed.

In this case, as described above, the contents of the additional file 224 and the deletion file 225 may be changed by restarting the metadata server 200 or by a failure of one data server (eg, data server # 1). It is only merged into the base file 222 when recreating a block from.

5 is a flowchart illustrating a process of reconstructing block information of a failed data server using the block index 222 according to an embodiment of the present invention.

If a failure occurs in the data server # 1 that has undergone the processes of blocks 410 to 430, the metadata server 200 immediately before the failure occurs in the block area 220 as in the block 510. The block index 222 of 1 is checked.

Subsequently, the metadata server 200 copies the contents of the basic file 223 to the crash area of the metadata server 200 as in block 520 (S510).

At this time, "a.txt", "b.txt", and "c.txt" of blocks # 1, block # 2, and block # 3 are the same as the contents of the basic file 223 in the crash area.

Here, the crash area exists in one storage area of the metadata server 200 and may be a memory and another storage medium.

The metadata server 200 adds an index entry of the additional file 224 to the crash region as in block 530 (S520).

At this time, the information of "d.txt" of block # 4 is added to the crash area, and "a.txt", "b.txt", "c of block # 1, block # 2, block # 3, and #block 4 are added. .txt "and" d.txt "information.

Next, the metadata server 200 removes the index entry of the deletion file 225 in the crash area as in block 540 (S530).

At this time, the information of block # 2 is deleted in the crash area, and information of "a.txt", "b.txt", and "d.txt" of blocks # 1, block # 2, and #block 4 exists, respectively.

Thereafter, the data server # 1 recovers the block information in which the failure occurred by using the information of the completed crash region (S540), and restores the data in which the loss occurred by using the recovered block information.

FIG. 6 is a flowchart illustrating a method of replicating blocks by a data server (data server # 1) having a failure in a distributed file system supporting multiple replications according to an exemplary embodiment of the present invention. FIG. 6 shows data lost by copying the same block from another data server (data server # 3, data server # 7, data server #N) where data server # 1 is different using the block information of the crash region configured through the process of FIG. It shows the process of restoring.

delete

First, the metadata server 200 reconstructs block information of the crash area to secure the location of the data server (data server # 3, data server # 7, data server #N) in which the block to be found exists (S610). .

Here, step S610 is a process of selecting a normal block to be used for recovery and a data server to be re-created.

In this case, a normal block to be used for recovery may be secured from metadata of the file. That is, since the metadata stores not only the namespace information of the file but also the number of the same blocks and the storage location information of the blocks, the metadata of the file can be accessed to obtain normal block information.

Here, it is preferable to select a data server (data server # 3, data server # 7, data server #N) to which a block is to be replicated in consideration of network topology or system load.

The crash region reconstructed as in block 630 has a form of {the original block, the data server in which the original block is stored, and the data server to be replicated}.

Subsequently, a re-cloning command is transmitted to the data server (data server # 3, data server # 7, data server #N) to be reproduced in which a normal block to be used for recovery exists (S620).

Subsequently, each data server (data server # 3, data server # 7, data server #N) that has received the re-cloning command is sent to the corresponding data server (data server # 1) to be replicated (block # 1, block # 3). In operation S630, the process of transmitting the block # 4 is performed.

That is, the data servers (data server # 3, data server # 7, and data server #N) that have received the re-copy command are data servers that will re-replicate each block from the disk of the block information transmitted by the metadata server 200. Send to (Data Server # 1).

At this time, each data server (data server # 3, data server # 7, data server #N) may perform block replication step by step or all at once in consideration of system conditions such as the load of the data server.

7 is a flowchart illustrating a recovery method of a data server in a distributed file system supporting multiple replications according to an embodiment of the present invention. A description with reference to FIG. 7 is as follows.

When one data server in which a failure occurs while using the distributed file system is detected (S705), the metadata server 200 allocates a crash area for configuring block index information to the storage area (S710).

Here, the crash region may exist in a memory or a separate storage space of the metadata server 200, and may be removed when the recovery is completed.

That is, the metadata server 200 may indicate that one data server is in a failure state by allocating a crash region.

Here, a failure of one data server may be caused by disconnection of a network, abnormal termination of a data server process, power failure, or the like.

The metadata server 200 copies the block index contents of the basic file 223 to the crash area (S715).

Next, the metadata server 200 checks whether the size of the additional file 224 is greater than or equal to zero (S720), and if it is greater than or equal to zero, adds the block index content of the additional file 224 to the crash area (S725). .

In this case, when the size of the additional file 224 is 0, the metadata server 200 determines that there is no content of the block index in the additional file 224, and omits step S725 and performs step S730.

Next, the metadata server 200 checks whether the size of the deleted file 225 is greater than or equal to zero (S730), and if it is greater than or equal to zero, adds the contents of the block index of the deleted file 225 to the crash area (S735). .

At this time, if the size of the deletion file 225 is 0, the metadata server 200 determines that there is no content of the block index in the deletion file 225, and skips step S735 and performs step S740.

Through the above-described process, the crash area stores the latest block information of one data server in which a failure occurs.

Then, the metadata server 200 searches for a data server in which a normal block to be used for recovery exists, and selects a data server to re-replicate the block (S740).
At this time, the metadata server 200 forms a list of {original block, data server in which original blocks are stored, and data server to be replicated} for each block to be reproduced with reference to the metadata, and among them, a data server to be used for recovery. To select.
At this time, the original block is selected from among the duplicate blocks normally left in each data server.
For example, if one block of all three duplicated blocks is lost, one of the remaining two blocks is selected as the block to be used for recovery.

delete

delete

In this case, it is efficient that the data server to which the block is to be replicated is selected in consideration of network locality (ie, proximity of physical location).

Subsequently, the data server in which the failure occurs arranges the crash area entries of the metadata server 200 for each data server (S745).
That is, the command to be transmitted is preferably composed of one network command, which is preferably transmitted collectively for each data server.
As described above, a data server having a failure is configured by transmitting an entry for each data server and collectively transmitting data for each data server, so that only one data server needs to be transmitted regardless of the number of blocks.

delete

For example, if there are 10 data servers to handle recovery, the metadata server 200 only needs to transmit 10 network commands, no matter how many blocks to recover.

Subsequently, the one data server in which the failure occurs transmits a block replication command to each aligned data server (S750).

In this case, when a plurality of original blocks to be replicated exist, one data server may sequentially transmit a command to each data server to perform re-replication, or transmit original blocks in parallel. Therefore, the command transmission method may be selected in such a way that the recovery efficiency may be increased in consideration of the system load at the time of performing the recovery operation.

Thereafter, one data server receives a normal block to be used for recovery from the data server receiving the replica command (S755).

The to-be-restored data server performs a recovery operation using the received normal block (S760).

Subsequently, when the recovery task data server is completed, the metadata server 200 notifies the metadata server 200 that block recovery is completed (S765).

Then, the metadata server 200 determines whether block recovery of one data server is completed (S770).

In this case, whether the block recovery is completed may be determined by comparing the processing result collected from each data server with the block information of the crash area.
When the replication is completed (S775), the metadata server 200 removes the crash area and completes the recovery of one data server (S780).

delete

On the other hand, the recovered one data server is preferably not used in terms of stability of the distributed file system.

The configuration of the present invention has been described above through the preferred embodiments and the accompanying drawings. However, these are only examples and are not used to limit the scope of the present invention. Those skilled in the art will understand from this that various modifications and equivalent other embodiments are possible. The true scope of protection of the present invention should be defined by the technical spirit of the appended claims.

1 is a block diagram illustrating a multiple replication based distributed file system according to the prior art.

2 and 3 are block diagrams illustrating a form of metadata storage in a distributed file system supporting multiple replications according to the present invention.

4 is a flowchart illustrating a method for configuring a block index in a metadata server according to the present invention.

5 is a flowchart illustrating a process of reconstructing block information of a data server having a failure using a block index according to the present invention.

6 is a flowchart illustrating a method for replicating blocks by a failed data server in a distributed file system supporting multiple replications according to the present invention.

7 is a flowchart illustrating a method of recovering a data server in a distributed file system supporting multiple replications according to the present invention.

<Description of main parts of drawing>

200: metadata server 201: metadata store

210: metadata area 220, 221: block area

222: Block Index 223: Basic File

224: Additional Files 225: Delete Files

Claims (15)

For storage of metadata servers in distributed file systems that support multiple replication, The metadata server manages metadata about a file stored in at least one data server in block units, The storage of the metadata server, A metadata area for storing metadata related to attributes of a file including location information; A block area for storing a block index classified for each data server storing a block including the file, If a failure occurs in the data server, support for restoration of the corresponding data server loss using the block index, The block area is, A basic file that is reconfigured each time the system of the metadata server is started and stores block index information of an initial state; The initial state has a size of 0 and an additional file for additionally storing a new block information entry each time a new block is added; In the initial state, the file has a size of 0 and further includes a block file for storing block information entries that are deleted each time a block is deleted. Storage of a metadata server in a distributed file system supporting multiple replication, characterized by managing the contents of the block index by dividing into. The method of claim 1, wherein the attribute of the file is: File name, file size, file access permissions, and where the file is stored Storage of the metadata server in a distributed file system that supports multiple replication, characterized in that related to the information including. delete The method of claim 1, wherein the additional file and the deletion file, Storage of a metadata server in a distributed file system that supports multiple replication, characterized in that only content can be added but not content can be deleted. The method of claim 1, wherein each of the new block information entry and the deleted block information entry are: Block identifier, file path to which the block belongs Storage of the metadata server in a distributed file system that supports multiple replication, characterized in that it comprises a. A method for storing metadata in a distributed file system that supports multiple replications, The metadata server stores metadata about data stored on one or more data servers. (a) dividing the metadata storage area into a metadata area and a block area; (b) receiving the metadata from a data server and storing attribute related information of a file in the metadata area; (c) generating a basic file for storing information of blocks of an initial state in the block area; (d) adding information of a block added or deleted from the initial state to an additional file or a deleted file if information of a block added or deleted from the initial state exists Metadata storage method in a distributed file system supporting multiple replication, comprising a. The method of claim 6, wherein step (d) (d-1) when a new block is added, inserting a new block information entry at the end of the additional file; (d-2) inserting a block information entry to be deleted at the end of the deletion file if a block to be deleted exists; Metadata storage method in a distributed file system supporting multiple replication, comprising a. The method of claim 6, wherein after step (d), When a new data server is added, the method further includes repeating steps (b) to (d). In a distributed file system supporting multiple replication, a metadata server recovers a data server. The metadata server stores metadata for data stored in one or more of the data servers, The metadata server divides the metadata storage area into a metadata area and a block area, receives the metadata from the data server, stores attribute related information of a file in the metadata area, and initializes the data in the block area. Create a basic file that stores information of blocks of a state, and if information of a block added or deleted from the initial state exists, add information of a block added or deleted from the initial state to an additional file or a delete file, (f) detecting a data server on which the failure occurred; (g) reconstructing the crash region to reconstruct block information before failure occurs; (h) searching for and selecting other data servers storing the same blocks as the block to be restored and requesting the same block; (i) receiving the same block from the other data servers; (j) recovering the one data server with the same block received, and notifying a completion of recovery; Method for recovering a data server metadata server in a distributed file system that supports multiple replication, comprising a. The method of claim 9, wherein the detecting of the failure in the step (f), A method for recovering a data server by a metadata server in a distributed file system supporting multiple replication, characterized by disconnection of the network, abnormal termination of the data server processor, and detection of a power failure. The method of claim 9, wherein after step (j), (k) determining whether the recovery is successful; (l) if the recovery is successful, deleting the crash region; (m) if the recovery fails, returning to step (g) and repeating steps (g) to (j) until the recovery is successful. Method for recovering a data server metadata server in a distributed file system that supports multiple replication, comprising a. The method of claim 11, wherein in the step (k) whether the recovery is successful, And a metadata server recovering the data server in the distributed file system supporting multiple replications, wherein the metadata server is determined based on a result of the processing of the processing data collected from the data server and the reconstructed crash region. The method of claim 9, wherein step (g) is (g-1) allocating the crash region; (g-2) copying the basic file in which the block index information for the initial state of the one data server is stored in the crash area; (g-3) adding contents of the additional file in which the block index information added from the initial state of the one data server is stored in the crash area; (g-4) adding contents of the deleted file in which the block index information deleted from the initial state of the one data server is stored in the crash region; Method for recovering a data server metadata server in a distributed file system that supports multiple replication, comprising a. The method of claim 9, wherein (h) is, (h-1) retrieving the number of the same blocks and at least one data server in which the same blocks are located from the metadata; (h-2) selecting each other data server to perform re-replication among the searched one or more data servers; (h-3) constructing a list of {same block, another data server in which the same block is stored, one data server} from the search result; (h-4) sorting the list by each other data server in which the same block is stored; (h-5) transmitting a command for requesting the same block to the other data servers Method for recovering a data server metadata server in a distributed file system that supports multiple replication, comprising a. The method of claim 14, wherein in the step (h-2) the other data server, Network topology and system load Method for recovering the data server metadata server in a distributed file system supporting multiple replication, characterized in that the system is selected in consideration of the situation.

Images