Distributed file systems, computer systems, and media

Abstract

The present disclosure provides a distributed file system, including: a client, a metadata node, a data node and a volume management node; the client corresponds to one or more containers; the metadata node is used to store a first correspondence relationship, the first correspondence relationship is a correspondence relationship between a file system attribute and a storage location of data, the data is actual data in a file; the data node is used to store data; the volume management node is used to create one or more volumes in response to receiving a volume creation request from the client, each volume is an instance of a file system that can be mounted by at least one container, each file system attribute includes an index node and corresponding index node identification information, the index node identification information includes a file name and any one or more of the following: file size, creation time, modification time, number of links, user, user group and file permissions. The present disclosure also provides a computer system and a computer-readable storage medium.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and more specifically, to a distributed file system, a computer system, and a medium. Background Art

[0002] In the field of computer technology, virtualization is a resource management technology that can abstract, transform and present various physical resources of a computer, such as servers, networks, memory and storage, breaking the inseparable barriers between physical structures and allowing users to use these resources in a better way than the original configuration.

[0003] Containers are a virtualization technology that is more efficient and lightweight than traditional virtual machines. Currently, the most popular container engine is Docker, an open source application container engine that allows developers to package their applications and dependent packages into a portable container and then publish them to any popular Linux machine, which can also achieve virtualization. Containers are stateless and can be created, started, stopped, and destroyed at any time.

[0004] In the process of implementing the concept of the present disclosure, the inventors found that there are at least the following problems in the prior art: the container itself can be migrated on any physical machine in the cluster according to conditions, while the persistence and migration of container data is a relatively thorny and critical issue in container technology. Summary of the invention

[0005] In view of this, the present disclosure provides a distributed file system, a computer system, and a medium that can implement persistence and migration of container data.

[0006] One aspect of the present disclosure provides a distributed file system, including: a client, a metadata node, a data node, and a volume manager node (volmgr for short), wherein the client corresponds to one or more containers, the metadata node is used to store a first correspondence, the first correspondence is a correspondence between a file system attribute and a storage location of data, the data is actual data in a file, the data node is used to store data, and the volume manager node is used to create one or more volumes in response to receiving a volume creation request from the client, each volume is an instance of a file system that can be mounted by at least one container, wherein each file system attribute includes an index node and corresponding index node identification information, the index node identification information includes a file name and any one or more of the following: file size, creation time, modification time, number of links, user, user group, and file permission. The present disclosure provides a new distributed file system architecture, which includes a volume management node in addition to a client, a metadata node and a data node. The volume management node can respond to a request for creating a volume from a client and create multiple volumes according to the scale of the volume management node to form a volume pool. That is to say, the volume pool can provide multiple logical volumes. The container corresponding to the client only needs to be mounted through a user space file system (Filesystem in Userspace, Fuse) to be used. By mounting the volume, the data of the container is persisted, and no matter where the container is migrated to, the volume can be remounted, thereby realizing the portability of data.

[0007] According to an embodiment of the present disclosure, the metadata node is also used to respond to receiving a remote procedure call protocol message sent by the client, write the index node identification information and the data block identification information of the data corresponding to the remote procedure call protocol message into the first corresponding relationship, and return the storage location of the data corresponding to the index node identification and the file opening success message, wherein the remote procedure call protocol message includes the index node identification and the data block identification of the data, so that when the client needs to write data, first make a corresponding record in the metadata node, such as which data blocks of which file have been written at what time, and after the record is completed, the metadata node will also return to the client a message of successful file opening and the storage address of the data corresponding to the data that the client wants to write. In this way, the client can know which storage address to send the data it wants to write to for storage, and can ensure that the first corresponding relationship stored in the metadata node is the latest corresponding relationship. Correspondingly, the data node is also used to store the written data in a designated location in response to receiving the written data sent by the client, wherein the data block information of the written data includes the storage location of the data corresponding to the volume mounted by the container corresponding to the client, and the designated location is the storage location of the data corresponding to the written data, and the storage location of the data corresponding to the written data includes an IP address, an interface, and a storage space identifier. In this way, the function of the client remotely writing data in the data can be realized.

[0008] According to an embodiment of the present disclosure, the data block identification information of the data includes a data block group, and the data block group includes the IP addresses, interfaces and storage space identifications of several data nodes. In this way, the writing of several copies of data can be realized, ensuring the high reliability of the file data.

[0009] According to an embodiment of the present disclosure, after the index node identifier and the data block identifier of the data contained in the remote procedure call protocol message are written into the first corresponding relationship, the metadata node uses a consistency replication protocol (raft protocol) to keep the data of the first corresponding relationship stored in the remaining metadata nodes consistent.

[0010] According to an embodiment of the present disclosure, the metadata node is also used to respond to receiving a storage location request sent by the client and return the storage location of the data corresponding to the storage location request, wherein the storage location request includes a file name, so that when the client needs to read data, it can obtain the storage location of the required data from the metadata node. Correspondingly, the data node is also used to respond to receiving a data read request sent by the client and return a data block of the data corresponding to the data read request, wherein the data read request includes the storage location and offset of the data. In this way, the function of the client remotely reading data is implemented. In addition, multiple mount points can read the same or different files at the same time, realizing the shareability of the volume.

[0011] According to an embodiment of the present disclosure, a file is composed of a plurality of data blocks, and the size of each data block is a set size.

[0012] According to an embodiment of the present disclosure, each volume corresponds to a metadata storage space group (each metadata storage space of the metadata storage space group satisfies the consistency replication protocol) and multiple data storage space groups, wherein the metadata storage space group is located in the metadata node, each metadata node can carry multiple metadata storage spaces, the multiple data storage space groups are located in the data node, each data node can carry multiple data storage spaces, and since there are multiple possible permutations and combinations, a large number of volumes of different sizes can be created to form a volume pool, each volume has its own file system attributes, supports the standard Portable Operating System Interface of UNIX (POSIX) protocol, and can be mounted by Fuse. Therefore, each container can mount one or more volumes.

[0013] According to an embodiment of the present disclosure, the data of the file is distributed in the storage space of the data node according to the consistent hash value, or the data of the file is randomly distributed in the storage space of the data node.

[0014] According to an embodiment of the present disclosure, the storage space of the container can reach PB level.

[0015] According to an embodiment of the present disclosure, the client has at least one application, a virtual file system, a user space file system and an interface library of the user space file system, wherein the virtual file system is used to create a container for the at least one application, and the user space file system interacts with the metadata node and / or the data node on the data information in the container based on the interface library of the user space file system.

[0016] Another aspect of the present disclosure provides a computer system, including one or more processors, and a storage device, wherein the storage device is used to store executable instructions, and when the executable instructions are executed by the processor, the following operations are implemented: in response to receiving a volume creation request from the client, one or more volumes are created, each volume is an instance of a file system that can be mounted by at least one container, wherein each file system attribute includes an index node and corresponding index node identification information, and the index node identification information includes a file name and any one or more of the following: file size, creation time, modification time, number of links, user, user group, and file permissions.

[0017] Another aspect of the present disclosure provides a computer-readable storage medium storing computer-executable instructions, which are used to implement the above method when executed.

[0018] Another aspect of the present disclosure provides a computer program, which includes computer executable instructions, and the instructions are used to implement the method described above when executed.

[0019] According to the embodiments of the present disclosure, containers can truly achieve elastic scaling and free migration, such as an application creating a container and then mounting the required volumes.

[0020] According to the embodiments of the present disclosure, since the data block identification information of the data includes a data block group, and the data block group includes the IP addresses, interfaces and storage space identifiers of several data nodes, the reliability of the container data is greatly improved, for example, when three or other numbers of copies can be stored respectively.

[0021] According to the embodiments of the present disclosure, the container data scale can break through the limitation of a single physical hard disk and reach the PB level. For example, a container can correspond to several volumes, and the data corresponding to each volume can be stored on different physical machines respectively.

[0022] According to the embodiments of the present disclosure, the read and write response delay of the business file in the container is decoupled from the physical disk and stably maintained within an excellent range. For example, the data of the business in the container may not be stored on the local physical machine, so the file read and write response delay can be decoupled from the physical disk.

[0023] According to an embodiment of the present disclosure, multiple containers can share the same storage space, and this feature can be used to enrich business types. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The above and other objects, features and advantages of the present disclosure will become more apparent through the following description of the embodiments of the present disclosure with reference to the accompanying drawings, in which:

[0025] Figure 1The application scenarios of the distributed file system, computer system and medium according to the embodiments of the present disclosure are schematically shown;

[0026] Figure 2 The schematic diagram schematically shows the relationship between the container and the physical machine in the prior art;

[0027] Figure 3 The diagram schematically shows the relationship between the container and the physical machine according to an embodiment of the present disclosure;

[0028] Figure 4 The following schematically shows an architecture diagram of a distributed file system according to an embodiment of the present disclosure; and

[0029] Figure 5 A block diagram of a computer system suitable for a distributed file system according to an embodiment of the present disclosure is schematically shown. DETAILED DESCRIPTION

[0030] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the present disclosure. In the following detailed description, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present disclosure. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of known structures and technologies are omitted to avoid unnecessary confusion of the concepts of the present disclosure.

[0031] The terms used herein are only for describing specific embodiments and are not intended to limit the present disclosure. The terms "comprise", "include", etc. used herein indicate the existence of the features, steps, operations and / or components, but do not exclude the existence or addition of one or more other features, steps, operations or components.

[0032] All terms (including technical and scientific terms) used herein have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification, and should not be interpreted in an idealized or overly rigid manner.

[0033] In the case of using expressions such as "at least one of A, B, and C, etc.", it should generally be interpreted in accordance with the meaning of the expression generally understood by those skilled in the art (for example, "a system having at least one of A, B, and C" should include but is not limited to a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, C, etc.). In the case of using expressions such as "at least one of A, B, or C, etc.", it should generally be interpreted in accordance with the meaning of the expression generally understood by those skilled in the art (for example, "a system having at least one of A, B, or C" should include but is not limited to a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, C, etc.).

[0034] Embodiments of the present disclosure provide a distributed file system, a computer system, and a medium. The distributed file system includes a client, a metadata node, a data node, and a volume management node. The volume management node can respond to a request from a client to create a volume, and create multiple volumes according to the scale of the volume management node to form a volume pool. That is, the volume pool can provide multiple logical volumes. The container corresponding to the client only needs to be mounted through a user space file system for use. By mounting the volume, the data of the container is persisted, and no matter where the container is migrated to, the volume can be remounted, thereby realizing data portability.

[0035] Figure 1 The following schematically illustrates the application scenarios of the distributed file system, computer system and medium according to the embodiments of the present disclosure. Figure 1 The system architecture 100 shown is only an example of a system architecture to which the embodiments of the present disclosure can be applied, so as to help those skilled in the art understand the technical content of the present disclosure, but it does not mean that the embodiments of the present disclosure cannot be used in other devices, systems, environments or scenarios.

[0036] like Figure 1 As shown, the system architecture 100 according to this embodiment may include terminal devices 101, 102, 103, a network 104, a metadata server cluster 105, a data server cluster 106, and a volume management server cluster 107. The network 104 is used to provide a medium for communication links between the terminal devices 101, 102, 103 and the metadata server cluster 105, the data server cluster 106, and the volume management server cluster 107. The network 104 may include various connection types, such as wired, wireless communication links, or optical fiber cables, etc.

[0037] The user can use the terminal devices 101, 102, 103 to interact with the metadata server cluster 105, the data server cluster 106, and the volume management server cluster 107 through the network 104 to receive or send messages, etc. Various communication client applications with files can be installed on the terminal devices 101, 102, 103, such as virtualization tools, shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only for example).

[0038] The terminal devices 101, 102, 103 may be various electronic devices having a display screen, supporting web browsing and supporting a portable operating system interface, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, and the like.

[0039] The metadata server cluster 105, the data server cluster 106 and the volume management server cluster 107 may be servers that provide various services, such as a background management server (only an example) that provides support for websites browsed by users using the terminal devices 101, 102, 103. The background management server may analyze and process the received data such as user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal device.

[0040] It should be understood that Figure 1 The number of terminal devices, networks and server clusters in the embodiment is only for illustration. Any number of terminal devices, networks and server clusters may be provided according to implementation requirements.

[0041] Figure 2 The figure schematically shows the relationship between the container and the physical machine in the prior art.

[0042] like Figure 2 As shown, the existing technical solution is to use the physical hard disk on the physical machine where the container is located, and with the help of the local volume management mechanism (Logical Volume Manager, referred to as LVM) technology, divide the hard disk of the local physical machine into partitions and map them to the container for use.

[0043] That is to say, the data in the container in the prior art is actually bound to the physical machine to which it belongs, and the container data cannot be migrated. Since the hard disk of the physical machine is easily damaged, the high reliability of the data in the container cannot be guaranteed.

[0044] In addition, due to the limited hard disk capacity of a single physical machine, it is impossible to provide ultra-large volumes. In addition, the hard disk performance of a single physical machine is limited. When it is heavily used, the read and write response delays are large, affecting the use of upper-layer applications.

[0045] Since the volume divided by LVM technology (LVM Volume for short) cannot provide sharing function, multiple containers across physical machines cannot share the volume.

[0046] In summary, the existing technical solutions are only suitable for small-scale container clusters.

[0047] Figure 3 The diagram schematically shows the relationship between a container and a physical machine according to an embodiment of the present disclosure.

[0048] like Figure 3 As shown, in the distributed file system provided by the present disclosure, the container is separated from the local physical machine, rather than dividing the hard disk of the local physical machine into partitions and mapping them to the container as in the prior art. The data in the container of the present disclosure can be stored on data nodes, such as a data server cluster, etc., and the remote reading and writing function of data is realized by mounting volumes on the client (Cluster). Figure 3 As shown, the core technical point of the distributed file system provided by the present disclosure is to provide a highly available, portable, and sharable volume pool (volumes pool), which can provide thousands of logical volumes (volumes), and the container can be used by simply mounting it through fuse. By mounting the volume, the data of the container is persisted (the data of the container is stored in the data server, and the metadata server information can be obtained through the information in the volume. The metadata server information corresponds to the storage location of the data of the file stored in the metadata server, such as which data block of which disk of which data server the data exists in. The client (Cluster) can find the data at any time through this information and can operate it. Moreover, no matter where the container is migrated to any physical machine, the volume can be remounted, realizing the portability of the data.

[0049] Figure 4 The schematic diagram shows an architecture diagram of a distributed file system according to an embodiment of the present disclosure.

[0050] like Figure 4 As shown, the distributed file system may include: a client, a metadata node, a data node, and a volume management node.

[0051] The client corresponds to one or more containers, which is only for illustration, and multiple clients may exist at the same time. The client has at least one application (APP), a virtual file system (VFS), a user space file system (FUSE), and an interface library (Libfuse) of the user space file system. The virtual file system is used to create a container for the at least one application, and the user space file system interacts with the metadata node and / or the data node on the data information in the container based on the interface library of the user space file system.

[0052] The metadata node is used to store a first correspondence relationship, where the first correspondence relationship is a correspondence relationship between a file system attribute and a storage location of data, and the data is actual data in the file. Figure 4 There are 3 metadata nodes in total, and these 3 metadata nodes together form a metadata node cluster. It should be noted that the above 3 metadata nodes are only illustrative examples, and there may be more or fewer metadata nodes. Figure 4 In the example, one volume corresponds to three metadata nodes, and the three metadata nodes satisfy the consistency replication protocol (Raft), which can ensure the high reliability of the data in the metadata nodes. The first correspondence can be stored in the form of "key-value memory storage space" (Key-Value map, referred to as KV map), where Key is used to store file system attributes, specifically corresponding to a set of parent inodes (parent inode, referred to as parent node) and file names (filename), and Value corresponds to index node attributes, such as the storage location of data.

[0053] The data node is used to store data. Figure 4 A storage space group, also called a replica group (BlockGroup), corresponds to 3 data nodes. This is only an example. It can also correspond to more or fewer data nodes. Each data node can correspond to a hard disk (DISK). Each data node can have multiple configurable storage spaces (Blocks). Each Block has a unique identifier (Block ID). The specific storage location can be determined based on the first Block ID and offset.

[0054] The volume management node is used to create one or more volumes in response to receiving a volume creation request from the client, each volume being an instance of a file system that can be mounted by at least one container, wherein each file system attribute includes an index node and corresponding index node identification information, and the index node identification information includes a file name and any one or more of the following: file size, creation time, modification time, number of links, user, user group and file permissions, wherein the number of links refers to how many hard links a file has (i.e., one or more file names of a file, used to link the file name and the node number used by the file system), a user can be a user name, etc. (such as root, admin, etc.), and a user group refers to a group of users with certain identical attributes. Figure 4 Only one volume manager node (Volume manager) is exemplified, and there may be multiple volume manager nodes. Each volume has a metadata node table (MataData Table) and multiple replica groups (BlockGroup) corresponding to the metadata node table.

[0055] In the process of creating a volume, the client and the volume management node need to interact with each other to generate at least one volume, in which a metadata node table and a replica group (BlockGroup) are stored, wherein the metadata node table and at least one replica group (BlockGroup) are associated with each other.

[0056] Since each volume corresponds to a RaftGroup (RaftGroup can be composed of several meta ranges, such as three meta ranges), each volume has multiple BlockGroups. Each metanode can carry n meta ranges, and each datanode can carry n blocks. Therefore, there are many possible combinations, so many volumes can be created in the entire cluster.

[0057] Specifically, each volume has its own namespace, including a metadata node table and multiple blockgroups. Depending on the size of the cluster, you can create many volumes of different sizes. Each volume is an instance of a file system, has its own file system properties, supports the standard POSIX protocol, and can be mounted by FUSE.

[0058] After the volume is mounted through the client, it has the function of a file system and can be used as a local directory.

[0059] The metadata information of the file, including file name, file size, modification date, file permissions and other metadata information, is stored in the kv map.

[0060] The data of the file is distributed in the storage space of the data node according to the consistent hash value, or the data of the file is randomly distributed in the storage space of the data node.

[0061] Through the above architecture, each volume can be directly mounted and used by one or more containers. The number of volumes can be created in the tens of thousands according to the cluster scale, with excellent performance.

[0062] Figure 4 The curve in the figure represents the data flow of the distributed file system.

[0063] In one embodiment, the data flow is described by taking writing data in a container as an example.

[0064] First, the user mounts a volume through the client, such as the / mnt directory, and the client takes over the user's operations such as opening files, reading and writing files through fuse. The client determines the metadata node where the file name corresponding to the data to be written is located based on the information in the mounted volume, and then sends a remote procedure call protocol message to the metadata node.

[0065] The metadata node is used to write the index node identification information and the data block identification information of the data corresponding to the remote procedure call protocol message into the first corresponding relationship in response to receiving the remote procedure call protocol message sent by the client, and return the storage location of the data corresponding to the index node identification and a file opening success message, wherein the remote procedure call protocol message includes the index node identification and the data block identification of the data.

[0066] Specifically, when a user opens a file, the client will initiate a grpc message to the metanode, apply for the index node identifier (InodeID), apply for the first data block identifier (ChunkID), and write the index node information (InodeInfo) and data block information (ChunkInfo) into the metanode's kv map. The metanode will return a message to the client that the file has been successfully opened, and the client will generate a file handle and return it to fuse. This process completes the process of opening the file. Among them, the metanodes will use the raft protocol to ensure the data consistency of the kv map storage, and multiple metanodes also ensure the availability of metadata reports.

[0067] The data node is used to store the write data in a designated location in response to receiving the write data sent by the client, wherein the data block information of the write data includes the storage location of the data corresponding to the volume mounted by the container corresponding to the client, and the designated location is the storage location of the data corresponding to the write data, and the storage location of the data corresponding to the write data includes an IP address, an interface, and a storage space identifier.

[0068] Specifically, the user starts writing data to the file. Each data block information (chunkinfo) contains a requested replica group (blockgroup), which contains the addresses (ip), interfaces (port) and storage space identifiers (blockID) of three datanodes. Through these information, the client writes the actual file data to the three datanodes respectively. Among them, the writing of three replicas of data ensures the high reliability of the file data. In this way, the data writing process in the container is completed.

[0069] The data block identification information of the data includes a data block group, and the data block group includes IP addresses, interfaces and storage space identifiers of several data nodes. After the index node identifier and the data block identifier contained in the remote procedure call protocol message are written into the first corresponding relationship, the metadata node makes the first corresponding relationship stored in other metadata nodes consistent through a consistency replication protocol.

[0070] In another embodiment, the data flow is described by taking reading data from a container as an example.

[0071] The client sends a storage location request to the metadata node.

[0072] The metadata node is used to return the storage location of the data corresponding to the storage location request in response to receiving the storage location request sent by the client, wherein the storage location request includes a file name.

[0073] The data node is used to return a data block of data corresponding to the data read request in response to receiving the data read request sent by the client, wherein the data read request includes a storage location and an offset of the data.

[0074] Specifically, users can mount the volume multiple times in parallel on other physical machines or containers. When users read files from the mounted directory, they will first go to the metanode to obtain the file metadata information, including file size, file data block information (chunkinfos) and other information. After obtaining this information, the client can locate which datanodes the file data is distributed on, and locate which chunk of which blockgroup to start reading based on the input parameters when the user reads the file, such as the offset. Among them, multiple mount points can read the same or different files at the same time, realizing the shareability of the volume. The chunkinfo will contain the ID of the blockgroup to which the chunk belongs, and the blockgroup can be located by the ID.

[0075] The file is composed of multiple data blocks, and the size of each data block is a set size. For example, the file is composed of multiple chunks, and each chunk is 64MB.

[0076] Each volume corresponds to a metadata storage space group and multiple data storage space groups, wherein the metadata storage space group is located in the metadata node, and the multiple data storage space groups are located in the data node.

[0077] In the distributed file system provided by the present disclosure, the storage space of the container can reach the PB level.

[0078] Figure 5 A block diagram of a computer system suitable for a distributed file system according to an embodiment of the present disclosure is schematically shown. Figure 5 The computer system shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0079] like Figure 5 As shown, the computer system 500 according to the embodiment of the present disclosure includes a processor 501, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 502 or the program loaded from the storage part 508 to the random access memory (RAM) 503. The processor 501 may include, for example, a general-purpose microprocessor (such as a CPU), an instruction set processor and / or a related chipset and / or a special-purpose microprocessor (for example, an application-specific integrated circuit (ASIC)), etc. The processor 501 may also include an onboard memory for caching purposes. The processor 501 may include a single processing unit or multiple processing units for performing different actions of the method flow according to the embodiment of the present disclosure.

[0080] In RAM 503, various programs and data required for the operation of system 500 are stored. Processor 501, ROM 502 and RAM 503 are connected to each other through bus 504. Processor 501 performs the following operations by executing the program in ROM 502 and / or RAM 503: in response to receiving a volume creation request from the client, one or more volumes are created, each volume is an instance of a file system that can be mounted by at least one container, wherein each file system attribute includes an index node and corresponding index node identification information, and the index node identification information includes a file name and any one or more of the following: file size, creation time, modification time, number of links, user, user group and file permissions. It should be noted that the program can also be stored in one or more memories other than ROM 502 and RAM 503. Processor 501 can also perform various operations according to the embodiments of the present disclosure by executing the program stored in the one or more memories.

[0081] According to an embodiment of the present disclosure, the system 500 may further include an input / output (I / O) interface 505, which is also connected to the bus 504. The system 500 may further include one or more of the following components connected to the I / O interface 505: an input section 506 including a keyboard, a mouse, etc.; an output section 507 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, a modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the I / O interface 505 as needed. A removable medium 511, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 510 as needed, so that a computer program read therefrom is installed into the storage section 508 as needed.

[0082] According to an embodiment of the present disclosure, the method flow according to an embodiment of the present disclosure can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a computer-readable storage medium, and the computer program contains a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 509, and / or installed from the removable medium 511. When the computer program is executed by the processor 501, the above-mentioned functions defined in the system of the embodiment of the present disclosure are executed. According to an embodiment of the present disclosure, the system, equipment, device, module, unit, etc. described above can be implemented by a computer program module.

[0083] The present disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiment; or it may exist independently without being assembled into the device / apparatus / system. The above computer-readable storage medium carries one or more programs, and when the above one or more programs are executed, the following operations are implemented: in response to receiving a volume creation request from the client, one or more volumes are created, each volume is an instance of a file system that can be mounted by at least one container, wherein each file system attribute includes an index node and corresponding index node identification information, and the index node identification information includes a file name and any one or more of the following: file size, creation time, modification time, number of links, user, user group, and file permissions.

[0084] According to an embodiment of the present disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, for example, may include but is not limited to: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, an apparatus or a device. For example, according to an embodiment of the present disclosure, a computer-readable storage medium may include the ROM 502 and / or RAM 503 described above and / or one or more memories other than ROM 502 and RAM 503.

[0085] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0086] It will be appreciated by those skilled in the art that the features described in the various embodiments and / or claims of the present disclosure may be combined and / or combined in a variety of ways, even if such combinations and / or combinations are not explicitly described in the present disclosure. In particular, the features described in the various embodiments and / or claims of the present disclosure may be combined and / or combined in a variety of ways without departing from the spirit and teachings of the present disclosure. All of these combinations and / or combinations fall within the scope of the present disclosure.

[0087] The embodiments of the present disclosure are described above. However, these embodiments are only for illustrative purposes and are not intended to limit the scope of the present disclosure. Although the embodiments are described above separately, this does not mean that the measures in the various embodiments cannot be used in combination to advantage. The scope of the present disclosure is defined by the attached claims and their equivalents. Without departing from the scope of the present disclosure, those skilled in the art may make a variety of substitutions and modifications, which should all fall within the scope of the present disclosure.

Claims

1. A distributed file system, comprising: Clients, metadata nodes, data nodes, and volume management nodes; The client corresponds to one or more containers; The metadata node is used to store a first correspondence relationship, where the first correspondence relationship is a correspondence relationship between a file system attribute and a storage location of data, and the data is actual data in the file; The data node is used to store data; as well as The volume management node is used to create one or more volumes in response to receiving a volume creation request from the client, each volume being an instance of a file system that can be mounted by at least one container, wherein each file system attribute includes an index node and corresponding index node identification information, and the index node identification information includes a file name, and any one or more of the following: file size, creation time, modification time, number of links, user, user group, and file permission; Wherein, the client has at least one application, a virtual file system, a user space file system and an interface library of the user space file system; The virtual file system is used to create a container for the at least one application; The user space file system interacts with the metadata node and / or the data node on the data information in the container based on the interface library of the user space file system; Wherein, in the process of writing data into the container, the client determines the metadata node where the file name corresponding to the write data is located according to the information in the mounted volume, and sends a remote procedure call protocol message to the metadata node and sends the write data to the data node; in response to receiving the remote procedure call protocol message, the metadata node writes the index node identification information and the data block identification information of the data corresponding to the remote procedure call protocol message into the first corresponding relationship, and returns the storage location of the data corresponding to the index node identification information and a file opening success message; in response to receiving the write data, the data node stores the write data in a specified location; after writing the index node identification information and the data block identification of the data into the first corresponding relationship, the metadata node uses a consistency replication protocol to make the first corresponding relationship stored in other metadata nodes consistent; In the process of reading data from the container, the client sends a storage location request to the metadata node and a data read request to the data node; the metadata node returns the storage location of the data corresponding to the storage location request in response to receiving the storage location request; the data node returns the data block corresponding to the data read request in response to receiving the data read request.

2. The system according to claim 1, wherein: The remote procedure call protocol message includes an index node identifier and a data block identifier of the data; the data block information of the written data includes the storage location of the data corresponding to the volume mounted by the corresponding container of the client, the designated location is the storage location of the data corresponding to the written data, and the storage location of the data corresponding to the written data includes an IP address, an interface and a storage space identifier.

3. The system according to claim 2, wherein: The data block identification information of the data includes a data block group, and the data block group includes IP addresses, interfaces and storage space identifications of several data nodes.

4. The system according to claim 1, wherein: The storage location request includes a file name; the data read request includes a storage location and an offset of the data.

5. The system according to claim 4, wherein: A file consists of multiple data blocks, and the size of each data block is a set size.

6. The system according to claim 1, wherein: Each volume corresponds to a metadata storage space group and multiple data storage space groups, wherein the metadata storage space group is located in the metadata node, and the multiple data storage space groups are located in the data node.

7. The system of claim 1, wherein: The data of the file is distributed in the storage space of the data node according to the consistent hash value; or The data of the file is randomly distributed in the storage space of the data node.

8. The system according to claim 1, wherein: The storage space of the container can reach PB level.

9. A computer system comprising: one or more processors; A storage device, used to store executable instructions, wherein the executable instructions are applied to a distributed file system, wherein the distributed file system includes a client, a metadata node, and a data node; When the executable instruction is executed by the processor, the following operations are implemented: In response to receiving a volume creation request from the client, one or more volumes are created, each volume being an instance of a file system that can be mounted by at least one container, wherein each file system attribute includes an index node and corresponding index node identification information, and the index node identification information includes a file name, and any one or more of the following: file size, creation time, modification time, number of links, user, user group, and file permission; Wherein, the client has at least one application, a virtual file system, a user space file system and an interface library of the user space file system; The virtual file system is used to create a container for the at least one application; The user space file system interacts with the metadata node and / or the data node on the data information in the container based on the interface library of the user space file system; Wherein, in the process of writing data into the container, the client determines the metadata node where the file name corresponding to the write data is located according to the information in the mounted volume, and sends a remote procedure call protocol message to the metadata node and sends the write data to the data node; in response to receiving the remote procedure call protocol message, the metadata node writes the index node identification information corresponding to the remote procedure call protocol message and the data block identification information of the data into a first corresponding relationship, and returns the storage location of the data corresponding to the index node identification information and a file opening success message; in response to receiving the write data, the data node stores the write data in a specified location; after writing the index node identification information and the data block identification of the data into the first corresponding relationship, the metadata node uses a consistency replication protocol to make the first corresponding relationship stored in other metadata nodes consistent; In the process of reading data from the container, the client sends a storage location request to the metadata node and a data read request to the data node; the metadata node returns the storage location of the data corresponding to the storage location request in response to receiving the storage location request; the data node returns the data block corresponding to the data read request in response to receiving the data read request.

10. A computer-readable storage medium having executable instructions stored thereon, wherein the executable instructions are applied to a distributed file system, wherein the distributed file system includes a client, a metadata node, and a data node; When this instruction is executed by the processor, the following operations are implemented: In response to receiving a volume creation request from the client, one or more volumes are created, each volume being an instance of a file system that can be mounted by at least one container, wherein: Each file system attribute includes an index node and corresponding index node identification information, wherein the index node identification information includes the file name and any one or more of the following: file size, creation time, modification time, number of links, user, user group, and file permissions; Wherein, the client has at least one application, a virtual file system, a user space file system and an interface library of the user space file system; The virtual file system is used to create a container for the at least one application; The user space file system interacts with the metadata node and / or the data node on the data information in the container based on the interface library of the user space file system; Wherein, in the process of writing data into the container, the client determines the metadata node where the file name corresponding to the write data is located according to the information in the mounted volume, and sends a remote procedure call protocol message to the metadata node and sends the write data to the data node; in response to receiving the remote procedure call protocol message, the metadata node writes the index node identification information corresponding to the remote procedure call protocol message and the data block identification information of the data into a first corresponding relationship, and returns the storage location of the data corresponding to the index node identification information and a file opening success message; in response to receiving the write data, the data node stores the write data in a specified location; after writing the index node identification information and the data block identification of the data into the first corresponding relationship, the metadata node uses a consistency replication protocol to make the first corresponding relationship stored in other metadata nodes consistent; In the process of reading data from the container, the client sends a storage location request to the metadata node and a data read request to the data node; the metadata node returns the storage location of the data corresponding to the storage location request in response to receiving the storage location request; the data node returns the data block corresponding to the data read request in response to receiving the data read request.

Images