KR101010219B1 - Asymmetric Distributed File System, And Incremental Consistency Error Check And Recovery Method For The Same - Google Patents

Abstract

The present invention provides a progressive coherence error detection and recovery method that can maintain the structural consistency of the file system in a network-based asymmetric distributed file system, the progressive coherence error detection and recovery method in the asymmetric distributed file system of the present invention, Maintaining the chunk size and chunk version information in the data server and the data server; Synchronizing and changing the chunk information of the metadata server and the chunk information of the data server to perform file recording for a gradual consistency check; Performing a file read in parallel with a gradual consistency check through mutual comparison of the recorded chunk information; And gradually healing cross-reference coherence errors between the metadata server and the data server according to the checking.

Asymmetric Distributed File, Incremental, Consistency Error, Detect, Repair

Description

Asymmetric Distributed File System, And Incremental Consistency Error Check And Recovery Method For The Same}

The present invention relates to an asymmetric distributed file system and its progressive coherence error detection and recovery method, and more particularly to a progressive coherent error detection and recovery method capable of maintaining structural consistency of a file system in a network-based asymmetric distributed file system. It is about.

The present invention is derived from the research conducted as part of the IT growth engine technology development project of the Ministry of Knowledge Economy and the Ministry of Information and Communication Research and Development. [Task management number: 2007-S-016-02, Title: Development of a low-cost large-scale global Internet service solution ].

Every file system has its own storage structure and must provide File System Check and Recovery (FSCR) procedures in case of failure. CHKDSK utilities of the FAT file system, fsck utility of ext2 and ext3 file systems, and scandisk utility of NT file systems are widely used for this purpose. In addition, an asymmetric distributed file system (ADFS) must also provide recovery procedures for this purpose.

The asymmetric distributed file system is a structure in which a metadata server and a data server exist separately. That is, the asymmetric distributed file system is a metadata server (MDS) that handles all metadata processing, a data server (DS) that handles all data processing, and accesses to provide a file service. Clients are connected to each other via a network. In this structure, the actual data of every file is distributed and stored in multiple data servers, and the location information is stored in the metadata server as part of the metadata of the file. Such mutual storage structures should not fail in any case, but in reality, due to the nature of an asymmetric distributed file system consisting of multiple servers, it is not possible to completely prevent structural defects from occurring in a part of recent changes immediately after a failure. . Therefore, this kind of structural flaw should be searchable and corrected by the appropriate FSCR procedure.

Consistency check method of distributed file system is divided into full check procedure and log based check and recovery procedure.

The full inspection procedure uses a method of reading all metadata and all data in turn to verify cross-references, which is the last resort to detect and repair any kind of consistency error, but it is a time-consuming task. There are various attempts to make this process as efficient as possible, but there is no way to completely overcome the basic feature of full inspection of all files. Therefore, there are some limitations in the field requiring rapid system restart after failure.

The log check and recovery procedure puts each log file on the client, metadata server, and data server side for recently changed files, and performs a check and recovery procedure based on these logs only in case of a failure. do. Thus, there is no need to search the entire storage space. However, this method is not applicable if a file that is not already recorded in the log or the log itself is lost, and as a last resort, a full inspection cannot be avoided.

The present invention is to solve the above problems, the object of the present invention is to quickly restart the system without a full check in the worst case, such as log loss, and to perform a consistency check when accessing the file gradually service without consistency problems Asymmetric distributed file system and its incremental consistency error detection and recovery method are provided.

Another object of the present invention is to provide an asymmetric distributed file system and its progressive coherence error detection and recovery method, which enables the service to be resumed without a consistency problem, so that the full inspection can be postponed to a low load of the system. .

Another object of the present invention is to prevent users from accessing files whose consistency has been impaired even if the system is restarted without a full inspection procedure after failure, even if the log is lost, and the file access is continued and their consistency errors over time. It is to provide an asymmetric distributed file system that can be gradually healed naturally and its progressive consistency error detection and recovery method.

It is still another object of the present invention to provide an asymmetric distributed file system and its progressive coherence error detection and recovery method which can improve performance by requiring no additional burden during normal operation in order to prepare for a failure.

Progressive consistency error detection and recovery method in the asymmetric distributed file system of the present invention for achieving the above object, maintaining the chunk size and chunk version information in the metadata server and the data server; Synchronizing and changing the chunk information of the metadata server and the chunk information of the data server to perform file recording for a gradual consistency check; Performing a file read in parallel with a gradual consistency check through mutual comparison of the recorded chunk information; And gradually healing cross-reference coherence errors between the metadata server and the data server according to the checking.

The asymmetric distributed file system of the present invention stores and manages metadata of a file, transmits metadata of the file to the client according to a metadata request from a client, and recovers a gradual consistency error of the asymmetric distributed file system. Data server; And a data server for checking a gradual consistency error of the asymmetric distributed file system and reporting an error check result to the metadata server according to a chunk read request from the client, and transmitting the read result of the file to the client. Characterized in that.

Embodiments of the present invention allow the system to be quickly restarted without a full check in a worst case situation such as log loss, and by performing a consistency check on file access to resume service without a consistency problem. Allow the load to postpone to a low time.

According to embodiments of the present invention, even if a log is restarted, even if the system is restarted without a full inspection procedure after failure, the user may not be able to access a file whose consistency has been impaired, and the file access may be continued and their coherence error may be over time. Allow for natural healing gradually.

Embodiments of the present invention, the existing log-based procedure requires an additional burden, such as synchronization with a separate protocol to keep track of whether both sides of the persistent storage device has a separate log on both the metadata server and the data server On the other hand, in order to prepare for failure, no additional burden is required during normal operation, so better performance of an asymmetric distributed file system can be expected.

Hereinafter, with reference to the accompanying drawings will be described in detail a preferred embodiment of the present invention.

Basically, various embodiments to which the present invention is applied are possible, but the present invention will be described based on the exemplary embodiments. For the sake of clarity, the parts which are not directly related to the present invention or unnecessary parts are omitted, even though they exist in general file systems and distributed file systems. In addition, even if all the modules and functions of the distributed file system targeted by the present invention are implemented on any hardware, an operating system, a computer language, and a network device, they basically have the same meaning. Although there is a significant improvement in the performance of the distributed file system of the target structure, since there is no fundamental change in each module and function, these are all one kind of various embodiments of the same invention.

1 is a hardware diagram of an asymmetric distributed file system according to an embodiment of the present invention.

Referring to FIG. 1, an asymmetric distributed file system (ADFS) 10 of the present invention includes a plurality of clients 11-1 to 11-4 connected to a network 14. And a metadata server (MDS) 12 and a plurality of data servers 13-1 to 13-4.

The metadata server 12 stores and manages various metadata used in the asymmetric distributed file system 10. The metadata server 12 has its own metadata repository with a metadata processing module for storing and managing metadata. Here, the storage may be file systems ext2, ext3, xfs, or a database (DBMS).

The data servers 13-1 to 13-4 are a plurality of physical storage devices connected to the network 14, which store and manage the actual data of the file and perform input / output functions of the actual data of the file. .

The network 14 allows communication between hardware as well as a local area network (LAN), a wide area network (WAN), a storage area network (SAN), a wireless network, and the like. As one of any networks, it is used here for communication between clients 11-1 to 11-4, metadata server 12 and data servers 13-1 to 13-4.

2 is a software block diagram of an asymmetric distributed file system according to an embodiment of the present invention.

Referring to FIG. 2, the file system client module 11-1b stores a file stored in the asymmetric distributed file system by an application 11-1a accessing the asymmetric distributed file system 10 performed by the client 11-1. Provides a file system access interface such as POSIX for accessing

The file system client module 11-2b may execute the POSIX to allow an application 11-2a accessing the asymmetric distributed file system 10 executed in the client 11-2 to access a file stored in the asymmetric distributed file system. It provides a file system access interface such as

The file system client module 11-3b may execute the POSIX to allow an application 11-3a accessing the asymmetric distributed file system 10 executed on the client 11-3 to access a file stored in the asymmetric distributed file system. It provides a file system access interface such as

The file system client module 11-4b is configured to execute the POSIX for the application 11-4a accessing the asymmetric distributed file system 10 executed in the client 11-4 to access files stored in the asymmetric distributed file system. It provides a file system access interface such as

The metadata server 12 stores and manages only metadata of all files stored in the asymmetric distributed file system 10, and includes a metadata management module 12a and a failure recovery module 12b. The metadata storage management module 12a stores and manages all metadata used in the distributed file system. The metadata storage management module 12a utilizes an ext3 file system or database (DBMS) as a storage 12c and stores metadata on disk. Failure recovery module 12b recovers file system consistency errors. This recovery function can be started manually by an administrator, the system monitoring software detects a fault, or automatically triggered at predetermined intervals.

The data server 13-1 stores and manages data of all files stored in the asymmetric distributed file system 10, and includes a chunk storage management module 13-1a and a storage 13-1b. The chunk storage management module 13-1a stores and manages data transmitted from at least one of the clients 11-1 to 11-4 through the storage 13-1b.

The data server 13-2 stores and manages data of all files stored in the asymmetric distributed file system 10, and includes a chunk storage management module 13-2a and a storage 13-2b. The chunk storage management module 13-2a stores and manages data transmitted from at least one of the clients 11-1 to 11-4 through the storage 13-2b.

The data server 13-3 stores and manages data of all files stored in the asymmetric distributed file system 10, and has a chunk storage management module 13-3a and a repository 13-3b. The chunk storage management module 13-3a stores and manages data transmitted from at least one of the clients 11-1 to 11-4 through the storage 13-3b.

The data server 13-4 stores and manages data of all files stored in the asymmetric distributed file system 10, and has a chunk storage management module 13-4a and a repository 13-4b. The chunk storage management module 13-4a stores and manages data transmitted from at least one of the clients 11-1 through 11-4 through the storage 13-4b.

3 is a diagram illustrating a file storage structure of an asymmetric distributed file system according to an embodiment of the present invention.

Referring to FIG. 3, data of all files stored in the asymmetric distributed file system 10, that is, metadata 31, is stored in the metadata server 12. Here, metadata 31 actually stores the data of this file along with size, owner, group owner, access mode, and times (atime, ctime, mtime) and the like. Data server (DS) identifier (DS #), chunk identifier (CID #), and chunk size and chunk version for verifying the integrity of the data.

In addition, the data of the file to be stored is divided into several chunks 32 and stored in the data servers 13-1 to 13-4. In this case, the chunk 32 includes the chunk size and the chunk version information together with the file data. When the file is accessed, the metadata server 12 obtains the metadata to determine the location of the chunk, and the data server in which the chunk is stored among the data servers 13-1 to 13-4 reads the chunk data. In this state, if the information such as the location, size and version of the chunks recorded in the metadata is different from the actual location, size and version information of the chunk to be read, a consistency error has occurred.

4 is a diagram illustrating types of consistency errors between metadata and chunks in an asymmetric distributed file system according to an embodiment of the present invention.

There are three types of coherence errors that can occur in an asymmetric distributed file system 10 environment: an orphan object residual error, an absent object reference error, and an anomaly object reference error.

Referring to FIG. 4, an orphan chunk error 41 is a case where a chunk exists but no metadata refers to it. The orphan chunk error 41 is reflected in the chunk generated during the file generation process in the data server storage among the data servers 13-1 to 13-4, but the metadata deletion result is not reflected in the storage. This occurs when a failure occurs in the data server 12. In addition, this problem occurs when the metadata deletion result is reflected in the storage during the file deletion process, but the data server fails before the deleted chunk information is reflected in the storage. In both of these cases, the orphan chunks will not be able to take advantage of that area of the reservoir forever, so they should not occur or be effectively removed.

A non-existent chunk reference error 42 is when a non-existent chunk reference is referenced in the metadata. In the absence chunk reference error 42, the metadata of the file generated during the file generation process is reflected in the storage, but the generated chunk is applied to the data servers 13-1 to 13-4 before being reflected in the storage. Occurs when a data server fails. In addition, this error occurs when the chunk information deleted in the file deletion process is reflected in the storage, but the metadata server 12 fails before the metadata is reflected in the storage.

An incorrect chunk reference error 43 is a case where the data, size and version of the chunk referenced by the metadata of a specific file are different. In this case, the data in the chunk cannot be trusted, so it is no longer necessary to deny access to the file.

As the ultimate means for detecting and recovering the errors, the total inspection time is very long because all metadata and chunk information are collated with each other, and normal service is impossible before this inspection is completed. Become.

As the next best way to detect and recover the errors, the log-based detection and recovery method has the advantage of being performed much faster than the full inspection because only recently changed files are examined in most situations. In the worst case, such as log loss, you may have to rely on a full inspection.

Consistency error recovery method according to an embodiment of the present invention is a method for detecting the missing chunk reference error 42 and the abnormal chunk reference error 43 of the two error types without depending on the total inspection and log, In addition to processing file I / O requests at the client node, the location, version, and size of the chunks recorded in the metadata are compared with the information of the chunks read by the corresponding data server among the data servers 13-1 to 13-4. By detecting coherence errors in real time with each other, the failure recovery procedure of the metadata server 12 is automatically notified of this fact. In this case, if the log information is lost, even if the full check is not performed immediately, consistency check is performed on the currently accessed files to prevent the wrong data from being delivered to the user. You can maneuver.

5 is a diagram illustrating a file writing procedure that enables a gradual consistency checking and repairing method in an asymmetric distributed file system according to an embodiment of the present invention.

Referring to FIG. 5, when a chunk recording request is requested from the client 51 (S510), the data server 52, along with data of the corresponding chunk, chunk size and chunk version, which are additional information for consistency checking, are included. Update the (chunk version) (S520). The chunk size is a changed size of the chunk after updating, and when the data is added, the chunk size is increased by the size of the added data, and the chunk size is not changed when the data is overwritten with the existing data. The chunk version is incremented by 1 for every change. Information such as the changed chunk size and chunk version is reported to the metadata server 53 (S530), and the metadata server 53 changes the metadata of the file corresponding to the corresponding chunk to the reported value (S540). By this file writing procedure, the chunk size and chunk version of the metadata are synchronized with the chunk size and chunk version of the data server 52.

Here, the client 51 is any one of the clients 11-1 to 11-4 of FIG. 1, and the data server 52 is any one of the data servers 13-1 to 13-4 of FIG. 1. And the metadata server 53 is the metadata server 12 of FIG.

6 is a diagram illustrating a file access procedure when there is no consistency error in a gradual consistency checking and repairing method of an asymmetric distributed file system according to an embodiment of the present invention. That is, FIG. 6 illustrates a read request processing procedure in a normal state in which a chunk size and a chunk version between a metadata server and a data server match according to an embodiment of the present invention.

Referring to FIG. 6, the client 61 first requests a file metadata by accessing the metadata server 63 (S610), and transmits metadata 65 corresponding to a file to be accessed from the metadata server 63. After obtaining (S620), the read request of the corresponding chunk is transmitted to the data server 62 according to the information recorded in the metadata (S630). At this time, the client 61 transmits the chunk size and the chunk version recorded in the metadata as the read request, so that the data server 62 requests the requested chunk information and the stored chunk information ( 64) can be compared. The data server 62 compares the requested chunk information with the stored chunk information, and if the comparison result is matched (S640), the read request is finally allowed (S650).

Here, the client 61 is any one of the clients 11-1 to 11-4 of FIG. 1, and the data server 62 is any one of the data servers 13-1 to 13-4 of FIG. 1. And the metadata server 63 is the metadata server 12 of FIG.

FIG. 7 is a diagram illustrating a read request processing procedure when an abnormal chunk error exists in a gradual consistency check and repair method of an asymmetric distributed file system according to an embodiment of the present invention.

Referring to FIG. 7, the client 71 first accesses the metadata server 73 to request file metadata (S710), and transmits metadata 75 corresponding to a file to be accessed from the metadata server 73. After obtaining (S720), the read request of the corresponding chunk is transmitted to the data server 72 according to the information recorded in the metadata (S730). At this time, the client 71 transmits the chunk size and the chunk version recorded in the metadata as the read request, so that the data server 72 requests the chunk information and the stored chunk information ( 74).

The data server 72 compares the requested chunk information with the stored chunk information, and if there is a mismatch (S740), reports the stored chunk information to the metadata server 73 and reports the chunk consistency error (S750). Finally, the chunk read failure is reported to the client 71 (S750). At this time, the metadata server 73 which received the chunk error is changed to the reported new value of the metadata corresponding to the reported chunk (S770), and if necessary, activates an additional recovery procedure.

Here, the client 71 is any one of the clients 11-1 to 11-4 of FIG. 1, and the data server 72 is any of the data servers 13-1 to 13-4 of FIG. 1. One, and metadata server 73 is metadata server 12 of FIG.

FIG. 8 is a diagram illustrating a read request processing procedure when an absent chunk error exists in a gradual consistency check and repair method of an asymmetric distributed file system according to an embodiment of the present invention.

Referring to FIG. 8, the client 81 first accesses the metadata server 83 to request file metadata (S810), and transmits metadata 85 corresponding to a file to be accessed from the metadata server 83. After obtaining (S820), the read request of the corresponding chunk is transmitted to the data server 82 according to the information recorded in the metadata (S830). At this time, the client 81 transmits the chunk size and the chunk version recorded in the metadata as the read request, so that the data server 82 requests the requested chunk information and the stored chunk information ( 64) can be compared.

In this case, since the stored chunk information does not exist (S840), the data server 82 reports to the metadata server 83 that the requested chunk information cannot be compared with the stored chunk information (S850). Finally, the chunk read failure is reported to the client 81 (S860). The metadata server 83 that reported the chunking error starts an additional recovery procedure if necessary.

At this time, the metadata server 83 that received the chunk error is changed to the reported new value of the metadata corresponding to the reported chunk (S870), and the corresponding chunk does not exist in the metadata corresponding to the reported chunk. If necessary, activate additional recovery procedures.

Here, the client 81 is any one of the clients 11-1 to 11-4 of FIG. 1, and the data server 82 is any one of the data servers 13-1 to 13-4 of FIG. 1. And the metadata server 83 is the metadata server 12 of FIG.

As described above, the embodiments of the present invention allow the system to be quickly restarted without a full check in a worst case situation such as log loss, and by performing a consistency check on file access to resume service without a consistency problem. Allow full inspections to be postponed when the load on the system is low. In addition, embodiments of the present invention prevent users from accessing files whose consistency has been impaired even if the system is restarted without a full inspection procedure after a failure even if a log is lost. It can be gradually healed naturally.

Whereas existing log-based procedures require additional burdens such as keeping separate logs on both sides of the metadata server and data server and mutually synchronizing them in separate protocols to track whether the two sides reflect persistent storage, Embodiments do not require additional burden in the normal operation process in order to prepare for failures can expect better performance of the asymmetric distributed file system.

Although the technical spirit of the present invention has been described in detail according to the above-described preferred embodiment, it should be noted that the above-described embodiment is for the purpose of description and not of limitation. In addition, those skilled in the art will understand that various embodiments are possible within the scope of the technical idea of the present invention.

1 is a block diagram of an asymmetric distributed file system according to an embodiment of the present invention.

2 is a software diagram of an asymmetric distributed file system in accordance with an embodiment of the present invention.

3 illustrates a file storage structure of an asymmetric distributed file system according to an embodiment of the present invention.

4 illustrates types of consistency errors between metadata and chunks in an asymmetric distributed file system in accordance with an embodiment of the present invention.

5 is a diagram illustrating a file writing procedure that enables a gradual consistency checking and recovery method in an asymmetric distributed file system in accordance with one embodiment of the present invention.

FIG. 6 is a diagram illustrating a file access procedure when there is no consistency error in a gradual consistency checking and repairing method of an asymmetric distributed file system according to an embodiment of the present invention. FIG.

FIG. 7 is a diagram illustrating a read request processing procedure when an abnormal chunk error exists in a gradual consistency check and recovery method of an asymmetric distributed file system according to an embodiment of the present invention. FIG.

8 is a diagram illustrating a read request processing procedure when an absent chunk error is present in a method for gradual consistency checking and repair of an asymmetric distributed file system according to an embodiment of the present invention.

Claims (10)

Maintaining the chunk size and chunk version information in the metadata server and the data server; Synchronizing and changing the chunk information of the metadata server and the chunk information of the data server to perform file recording for a gradual consistency check; Performing a file read in parallel with a gradual consistency check through mutual comparison of the recorded chunk information; And Gradually healing cross-reference consistency errors between the metadata server and the data server according to the checking Progressive consistency error detection and recovery method in an asymmetric distributed file system comprising a. The method of claim 1, wherein performing the file recording comprises: The data server receiving a chunk write request from a client; The data server recording data of the requested chunk, changing the size of the chunk, and increasing the version of the chunk; Reporting the changed chunk size and version information to the metadata server; And Updating, by the metadata server, the chunk size and version information of metadata corresponding to the reported chunk. Progressive consistency error detection and recovery method in an asymmetric distributed file system comprising a. The method of claim 2, wherein in the incrementing of the chunk version, And the data server increments the version of the chunk by 1 for every change. The method of claim 1, wherein the performing of the file read comprises: Receiving a request to read a file containing information about the chunk identifier, the chunk size, and the chunk version from the client; Checking the reference consistency error by comparing the size and version of the stored chunk corresponding to the requested chunk identifier with the requested chunk size and version information; If there is no consistency error as a result of the checking, delivering data of the requested chunk to the client; And If a consistency error is detected as a result of the check, reporting read failures to the client. The method of claim 4, wherein The metadata server reports the chunk error and changes the metadata corresponding to the reported chunk to the reported new value Progressive consistency error detection and recovery method in an asymmetric distributed file system, characterized in that it further comprises. The method of claim 4, wherein the checking of the reference consistency error comprises: Checking whether a chunk corresponding to the chunk identifier delivered from the client exists in the data server; If the chunk does not exist in the data server as a result of the check, it is determined that an absent chunk reference error occurs in the metadata server, and the chunk information stored in the metadata server is reported to the metadata server. Deleting the; If the chunk exists in the data server but the chunk size or chunk version is different from the delivered chunk information, it is determined as an abnormal chunk reference error, and the abnormal chunk reference error is stored in the metadata server along with the stored chunk size and chunk version information. Reporting and updating metadata of the corresponding chunk stored in the metadata server to the actual value delivered; And Determining that there is no consistency error if the chunk exists in the data server and both the chunk size and chunk version are the same as the chunk information passed. Progressive consistency error detection and recovery method in an asymmetric distributed file system comprising a. In an asymmetric distributed file system, A metadata server for storing and managing metadata of a file, transmitting metadata of the file to the client according to a metadata request from a client, and recovering a gradual consistency error of the asymmetric distributed file system; And In response to a chunk read request from the client, a data server for checking a gradual consistency error of the asymmetric distributed file system and reporting an error check result to the metadata server and transmitting the read result of the file to the client Asymmetric distributed file system comprising a. The method of claim 7, wherein The client, An application program accessing the asymmetric distributed file system; And A file system client module that provides a file system access interface for the application to access files stored in the asymmetric distributed file system Asymmetric distributed file system comprising a. The method of claim 7, wherein the metadata server, A metadata management module configured to store and manage metadata of all files stored in the asymmetric distributed file system; A repository for storing the metadata; And A failure recovery module for recovering the gradual consistency error; Wherein said metadata includes size, owner, group owner, access rights, times, data server identifier, chunk identifier, chunk size, and chunk version. The method of claim 7, wherein the data server, A chunk storage management module that stores and manages data of all files stored in the asymmetric distributed file system; And Storage for storing the data of the file Asymmetric injection file system comprising a.

Images