A metadata extension method, device and equipment under a distributed file system and a storage medium

Abstract

The present disclosure relates to the field of distributed storage, and particularly relates to a metadata extension method and device under a distributed file system, equipment and a storage medium. The method comprises: receiving an expansion cluster request sent by a client; determining a target process to be migrated according to the expansion cluster request, the target process being used for managing metadata, and an identifier of a file or a directory where the metadata is located having a hash mapping relationship with the target process; copying metadata of the target process from a first metadata server to a second metadata server, and adjusting the hash mapping relationship, the second metadata server being different from the first metadata server. Through the hash of the directory or the file, the present embodiment dynamically schedules and balances the load of the metadata server cluster, and significantly reduces the impact on the business by minimizing the data migration cost. Compared with the traditional method, the present embodiment provides better load balancing capability, lower data migration cost and higher scalability.

Description

Technical Field

[0001] This disclosure relates to the field of distributed storage, and in particular to a method, apparatus, device, and storage medium for extending metadata under a distributed file system. Background Technology

[0002] Traditional file systems are limited by the performance bottleneck of a single machine and cannot meet the rapidly growing data processing needs of a business. Distributed file systems can integrate the storage resources of multiple servers, allowing businesses to access data without knowing its actual physical location. Furthermore, distributed file systems inherently support the expansion of any number of nodes, thus meeting the demands of rapidly growing data processing needs.

[0003] Efficient metadata management is a key challenge for distributed file systems. Current metadata extension methods mainly include static subtree partitioning, dynamic subtree partitioning, and hash-based metadata partitioning. However, these methods can severely impact user services under various conditions, including directory hotspots and capacity expansion. Currently, no reasonable and effective metadata extension method has been provided in the relevant technologies. Summary of the Invention

[0004] In view of this, this disclosure proposes a method, apparatus, device and storage medium for metadata extension in a distributed file system.

[0005] According to one aspect of this disclosure, a method for extending metadata in a distributed file system is provided, the distributed file system including multiple metadata servers (MDS), the method comprising:

[0006] Received a request from the client to expand the cluster;

[0007] Based on the cluster expansion request, the target process to be migrated is determined. The target process is used to manage metadata, and the identifier of the file or directory where the metadata is located has a hash mapping relationship with the target process.

[0008] The metadata of the target process is copied from a first metadata server to a second metadata server, and the hash mapping relationship is adjusted. The second metadata server is different from the first metadata server.

[0009] In one possible implementation, copying the metadata of the target process from a first metadata server to a second metadata server and adjusting the hash mapping relationship includes:

[0010] The metadata of the target process is copied from the first metadata server to the second metadata server in an incremental manner, and client requests continue to be processed during the data migration process;

[0011] When the preset conditions are met, the target process is stopped, the remaining data of the target process is copied to the second metadata server, and the hash mapping relationship is adjusted.

[0012] After the migration is complete, clean up the redundant data on the first metadata server.

[0013] In another possible implementation, the method further includes:

[0014] Receive a directory creation request sent by the client, the directory creation request including the directory identifier of the target directory to be created;

[0015] Based on the directory identifier of the target directory, the corresponding hash value is determined by a preset hash function;

[0016] Based on the hash value, the target directory is assigned to the target metadata server so that the target metadata server can create the target directory.

[0017] In another possible implementation, determining the corresponding hash value based on the directory identifier of the target directory using a preset hash function includes:

[0018] The corresponding hash value is determined by using the preset hash function based on the directory identifier of the parent directory of the target directory and the directory identifier of the target directory.

[0019] The directory identifier of the parent directory is used to uniquely identify the parent directory among multiple directories, and the directory identifier of the target directory is used to uniquely identify the target directory among multiple directories.

[0020] In another possible implementation, the method further includes:

[0021] Bind the directory identifier or file identifier of the target directory to the process of the target metadata server, and separate the directory entries of the target directory from the inodes;

[0022] The file identifier is used to uniquely identify the target file in the target directory among multiple files.

[0023] In another possible implementation, the method further includes:

[0024] When any one of the plurality of metadata servers fails, the directory identifier or file identifier bound to the failed metadata server is reassigned to the processes of the other metadata servers.

[0025] In another possible implementation, the distributed file system further includes a metadata manager, and the method further includes:

[0026] The metadata manager monitors the key metrics of each of the multiple metadata servers to obtain monitoring data. The key metrics include at least one of load, response time, and storage utilization.

[0027] The metadata manager dynamically adjusts the process distribution of the multiple metadata servers based on the monitoring data, with each metadata server hosting one or more processes.

[0028] According to another aspect of this disclosure, a metadata extension device for a distributed file system is provided, the distributed file system including multiple metadata servers, the device comprising:

[0029] The receiving module is used to receive cluster expansion requests sent by clients;

[0030] The determination module is used to determine the target process to be migrated based on the cluster expansion request. The target process is used to manage metadata, and the identifier of the file or directory where the metadata is located has a hash mapping relationship with the target process.

[0031] An extension module is used to copy the metadata of the target process from a first metadata server to a second metadata server and adjust the hash mapping relationship, wherein the second metadata server is different from the first metadata server.

[0032] In one possible implementation, the extension module is further configured to: copy the metadata of the target process from the first metadata server to the second metadata server in an incremental manner, and continue to process client requests during the data migration process;

[0033] When the preset conditions are met, the target process is stopped, the remaining data of the target process is copied to the second metadata server, and the hash mapping relationship is adjusted.

[0034] After the migration is complete, clean up the redundant data on the first metadata server.

[0035] In another possible implementation, the apparatus further includes: a distribution module, configured to:

[0036] Receive a directory creation request sent by the client, the directory creation request including the directory identifier of the target directory to be created;

[0037] Based on the directory identifier of the target directory, the corresponding hash value is determined by a preset hash function;

[0038] Based on the hash value, the target directory is assigned to the target metadata server so that the target metadata server can create the target directory.

[0039] In another possible implementation, the allocation module is further configured to:

[0040] The corresponding hash value is determined by using the preset hash function based on the directory identifier of the parent directory of the target directory and the directory identifier of the target directory.

[0041] The directory identifier of the parent directory is used to uniquely identify the parent directory among multiple directories, and the directory identifier of the target directory is used to uniquely identify the target directory among multiple directories.

[0042] In another possible implementation, the device further includes: a binding module, used for:

[0043] Bind the directory identifier or file identifier of the target directory to the process of the target metadata server, and separate the directory entries of the target directory from the inodes;

[0044] The file identifier is used to uniquely identify the target file in the target directory among multiple files.

[0045] In another possible implementation, the apparatus further includes: a reallocation module for:

[0046] When any one of the plurality of metadata servers fails, the directory identifier or file identifier bound to the failed metadata server is reassigned to the processes of the other metadata servers.

[0047] In another possible implementation, the distributed file system further includes a metadata manager, and the apparatus further includes an adjustment module for:

[0048] The metadata manager monitors the key metrics of each of the multiple metadata servers to obtain monitoring data. The key metrics include at least one of load, response time, and storage utilization.

[0049] The metadata manager dynamically adjusts the process distribution of the multiple metadata servers based on the monitoring data, with each metadata server hosting one or more processes.

[0050] According to another aspect of this disclosure, a computing device is provided, the computing device comprising:

[0051] processor;

[0052] Memory used to store processor-executable instructions;

[0053] The processor is configured to implement the above method when executing instructions stored in the memory.

[0054] According to another aspect of this disclosure, a non-volatile computer-readable storage medium is provided that stores computer program instructions thereon, which, when executed by a processor, implement the above-described method.

[0055] According to another aspect of this disclosure, a computer program product is provided, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of a computing device, the processor in the computing device performs the above-described method.

[0056] This disclosure provides a method for extending metadata in a distributed file system. It involves receiving a cluster expansion request from a client; determining a target process to be migrated based on the request, wherein the target process manages metadata, and the identifier of the file or directory containing the metadata has a hash mapping relationship with the target process; copying the metadata of the target process from a first metadata server to a second metadata server, and adjusting the hash mapping relationship, wherein the second metadata server is different from the first metadata server. On one hand, by employing a directory- or file-based hash algorithm, directory-level load balancing can be achieved without sacrificing directory operation performance. On the other hand, binding the identifier of a file or directory to a specific metadata server process allows for precise control over the scaling of the metadata server cluster. This mechanism allows for the rapid and cost-free migration of metadata server processes to any node, further improving the stability and efficiency of the entire distributed file system.

[0057] Other features and aspects of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0058] The accompanying drawings, which are included in and form part of this specification, illustrate exemplary embodiments, features, and aspects of this disclosure together with the specification and serve to explain the principles of this disclosure.

[0059] Figure 1A flowchart illustrating a metadata extension method under a distributed file system provided in an exemplary embodiment of this disclosure is shown.

[0060] Figure 2 This illustration shows a schematic diagram of a metadata extension method under a distributed file system provided in an exemplary embodiment of this disclosure.

[0061] Figure 3 A schematic diagram of the directory tree structure of the file system is shown.

[0062] Figure 4 A schematic diagram of a two-level directory structure for a distributed file system is shown.

[0063] Figure 5 A flowchart illustrating a metadata extension method under a distributed file system provided by another exemplary embodiment of this disclosure is shown.

[0064] Figure 6 A flowchart illustrating a metadata extension method under a distributed file system provided by another exemplary embodiment of this disclosure is shown.

[0065] Figure 7 A flowchart illustrating a metadata extension method under a distributed file system provided by another exemplary embodiment of this disclosure is shown.

[0066] Figure 8 A schematic diagram of the structure of a metadata extension device under a distributed file system provided in an exemplary embodiment of the present disclosure is shown.

[0067] Figure 9 This is a block diagram illustrating an apparatus for performing a metadata extension method under a distributed file system, according to an exemplary embodiment. Detailed Implementation

[0068] Various exemplary embodiments, features, and aspects of this disclosure will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0069] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0070] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0071] Current metadata extension methods mainly include static subtree partitioning, dynamic subtree partitioning, and hash-based metadata partitioning. However, each method has its own limitations: static subtree partitioning struggles to handle hotspot issues and has poor scalability; dynamic subtree partitioning can impact business access during migration; and hash-based metadata partitioning disrupts the file system hierarchy, leading to decreased directory operation performance. Furthermore, these solutions often require extensive data migration during cluster scaling, severely impacting system performance and availability.

[0072] The three solutions described above all severely impact user services under different conditions. This disclosure provides a metadata extension method under a distributed file system. Based on a directory or file hash algorithm, it achieves directory-level load balancing without reducing directory operation performance, thereby reducing metadata hotspots. Furthermore, by binding the unique identifier of a file or directory to a unique metadata server process, directory entries are directly isolated from inodes, minimizing migration costs. Moreover, by introducing a metadata manager as an intermediate node to control the scaling up and down of the metadata server cluster, the impact on user services is minimized while ensuring high cluster scalability. The metadata server can be quickly and cost-free migrated to any node, achieving load balancing and reducing hotspots.

[0073] The following describes the metadata extension method under the distributed file system provided in this disclosure using several exemplary embodiments.

[0074] Please refer to Figure 1 This document illustrates a flowchart of a metadata extension method for a distributed file system provided in an exemplary embodiment of the present disclosure. The distributed file system includes multiple metadata servers. This embodiment uses the method in one metadata server of the distributed file system as an example for illustration. The method includes the following steps.

[0075] Step 101: Receive a directory creation request sent by the client. The directory creation request includes the directory identifier of the target directory to be created.

[0076] A distributed file system includes multiple metadata servers. A metadata server is a server responsible for storing and managing the metadata (such as permissions, location, size, etc.) of a file or directory. A metadata server is also called a metadata server node.

[0077] The client sends a directory creation request, which instructs the creation of a target directory in the distributed file system. The directory creation request may include a directory identifier for the target directory to be created. This directory identifier is used to uniquely identify the name or path of a directory; it could be the directory name, path, or other unique identifier. When the client sends a directory creation request, this request can be sent to the metadata server responsible for the parent directory of the target directory. For simplicity, this metadata server is referred to as the first metadata server, which is the metadata server containing the parent directory of the target directory to be created.

[0078] Step 102: Determine the corresponding hash value using a preset hash function based on the directory identifier of the target directory.

[0079] The primary metadata server uses a pre-defined hash function to process the directory identifier of the target directory, generating a hash value. This hash value is used to determine which metadata server (the target metadata server) will be responsible for storing and managing the metadata of this target directory. When selecting the target metadata server, the primary metadata server can consider the hotspot status (i.e., access frequency) of the parent directory and the load of all metadata servers to achieve load balancing.

[0080] A hash function is a pre-defined hash algorithm used to convert input (such as a directory identifier) ​​into a fixed-size number (hash value), typically used for fast lookup and data distribution.

[0081] In some embodiments, a corresponding hash value is determined by a preset hash function based on the directory identifier of the parent directory of the target directory and the directory identifier of the target directory; wherein, the directory identifier of the parent directory is used to uniquely identify the parent directory in multiple directories, and the directory identifier of the target directory is used to uniquely identify the target directory in multiple directories.

[0082] Optionally, the first metadata server determines the target metadata server based on the hotspot status of the parent directory and the metadata server cluster. It then performs a hash calculation based on the directory identifiers of the parent directory, the target directory, and the target metadata server to determine the hash mapping relationship among these three elements. The first metadata server can establish a mapping relationship between the target directory's directory identifier and the target metadata server, recording the correspondence between these three elements.

[0083] In some embodiments, each metadata server hosts one or more processes. The mapping relationship indicates the hash mapping relationship between the parent directory identifier of the target directory, the directory identifier of the target directory, and a process of the target metadata server. That is, during the hash mapping relationship determination process, the hash mapping relationship between the input parameters and the output parameters is determined based on the input parameters (the parent directory identifier of a directory and the directory identifier of that directory) and the output parameters (the hash value corresponding to the process of the metadata server). After the hash mapping relationship is determined, the corresponding hash value can be determined using a preset hash function based on the input parameters (the parent directory identifier of a directory and the directory identifier of that directory). This hash value is used to uniquely identify a process of a metadata server, and the corresponding metadata server process can be identified through this hash value. This metadata server process is used to manage the metadata in that directory.

[0084] Step 103: Based on the hash value, the target directory is assigned to the target metadata server so that the target metadata server can create the target directory.

[0085] The first metadata server assigns the target directory to the target metadata server based on the hash value. If the target metadata server is the first metadata server, it creates the target directory and inode, and replies to the client upon completion. When the target metadata server is not the first metadata server, it sends a directory entry creation message to the target metadata server. Upon receiving the message, the target metadata server creates the target directory and inode, and sends a success message to the first metadata server upon completion. After receiving the creation completion message from the second metadata server, the first metadata server considers the directory creation request complete and replies to the client. The client receives this response message, indicating that the entire directory creation process is complete.

[0086] In an illustrative example, such as Figure 2 As shown, the first metadata server receives a client request that requests the creation of a directory in the distributed file system. The first metadata server uses the aforementioned hash algorithm based on the directory or file to perform metadata service and assigns the directory to the target metadata server. The figure only schematically shows three metadata servers: metadata server 1, metadata server 2, and metadata server 3. Each metadata server manages a set of inodes or directories. For example, metadata server 1 manages inode / directory 1, metadata server 2 manages inode / directory 2, and metadata server 3 manages inode / directory 3.

[0087] This disclosure introduces a directory- or file-based hash algorithm, which aims to significantly reduce the performance bottleneck of directory operations and effectively reduce metadata hotspots by evenly distributing directories across metadata server nodes. However, simple directory entry hashing cannot completely solve the problem of data migration volume during cluster changes. To further optimize this issue, the following improvement scheme is proposed.

[0088] First, the metadata server is designed as a stateless service; it does not store any persistent data itself, existing only as a cache structure. All data modification operations rely on a separate storage engine to complete.

[0089] By deeply analyzing the three core elements of a file system—directories, directory entries, and inodes—an innovative decoupling method is proposed. Since directories and inodes constitute the basic structure of data storage, the metadata server to which they belong is explicitly specified when files and directories are created. This design allows for load balancing directly at the metadata server level, via a monitoring program, when the cluster environment changes. This means that a specified metadata server service can be started on any node, achieving metadata server-level load balancing while avoiding data migration issues.

[0090] By applying these key technologies, the directory tree structure of the file system can be optimized.

[0091] In an illustrative example, such as Figure 3 The diagram illustrates the directory tree structure of a file system. In this structure, several directories (d) and files (f) are shown, arranged hierarchically. This directory tree contains multiple directories (d1, d2, d3, d4, d5) and files (f1, f3, f4, f5, f6, f7, f8, ..., fN). The relationships between files and folders are as follows: Directory d1 contains file f1 and directory d4. Directory d2 contains files f3, f4...fN, where N is a positive integer. Directory d4 contains files f5, f6, and directory d5. Directory d5 contains files f7 and f8. This directory tree structure is a simplified representation of a file system used to show the hierarchical relationship between files and directories. Each directory can contain subdirectories and files, with files located at the bottom level of the directory structure.

[0092] In an illustrative example, such as Figure 4As shown, this diagram illustrates a two-level directory structure for a distributed file system, in which directories (d) and files (f) are evenly distributed across multiple metadata servers. This design not only improves system stability and scalability but also significantly reduces unnecessary data migration caused by cluster changes, thereby enhancing overall system performance and efficiency.

[0093] The following section will provide a further introduction to these key technologies.

[0094] This disclosure provides a directory- or file-based hash algorithm for efficient metadata management in a distributed file system. Unlike traditional methods, this algorithm uses directory structures, rather than files or inodes, as the basic unit of hashing. In some embodiments, the algorithm takes the directory identifier of the target directory (e.g., the pathname of the target directory) as input, generates a hash value using a specific hash function, and then allocates the target directory to the corresponding metadata server based on the hash value.

[0095] The algorithm offers several advantages: First, it preserves the file system's hierarchical structure, enabling directory operations (such as listing directory contents) to be performed efficiently on a single metadata server. Second, by hashing directories rather than individual files, the algorithm distributes the load more evenly, achieving directory-level load balancing. This balancing strategy significantly reduces the probability of metadata hotspots because even if a directory contains a large number of files, their metadata is centralized on the same metadata server, avoiding frequent access across multiple servers.

[0096] Furthermore, the algorithm considers dynamic changes in directory depth and file system performance. By employing an adaptive hash function, the algorithm can dynamically adjust the hash function based on the depth of the target directory and the load of the distributed file system, further optimizing load balancing. This approach not only improves the overall system performance but also enhances its scalability, enabling it to better adapt to the needs of large-scale file systems.

[0097] In some embodiments, the directory identifier or file identifier of the target directory can be bound to the target metadata server, and the directory entry of the target directory can be separated from the inode; wherein, the file identifier is used to uniquely identify the target file in the target directory among multiple files. This design greatly simplifies the management and migration process of metadata.

[0098] In a distributed file system, a directory is a collection of files and subdirectories. Similar to a folder, it's used to organize and manage files. A directory entry is an entry within a directory, containing metadata about the file or directory. This primarily includes the file or directory's name and parent directory information, such as filename, inode number, and permissions. An inode is a database record in the distributed file system that stores file attributes and data structures. An inode contains file attributes and data block location information, such as file permissions, owner, size, timestamp, and data block location.

[0099] Each file or directory is assigned a globally unique identifier, and a one-to-one mapping is established between this identifier and the metadata server that manages the metadata of that file or directory. This mapping is persistently stored and remains consistent throughout the file system. Furthermore, embodiments of this disclosure separate the traditionally tightly coupled directory entry and inode information.

[0100] This design offers several advantages: First, since the binding relationship between file / directory identifiers and the metadata server is fixed, only a small amount of metadata information needs to be migrated during load balancing or system expansion, significantly reducing data migration costs. Second, the separation of directory entries and inodes allows the distributed file system to handle renaming, moving, and other operations more flexibly, as these operations mainly involve changes to directory entries without requiring modifications to inode information.

[0101] Furthermore, this design improves the system's fault tolerance and recovery capabilities. In some embodiments, when any one of the multiple metadata servers fails, the directory or file identifiers bound to the failed metadata server are reassigned to other metadata servers without requiring large-scale data migration. This not only reduces system downtime but also ensures data consistency and integrity.

[0102] In some embodiments, this disclosure may also introduce a metadata manager as an intermediate node, responsible for comprehensive monitoring and management of the metadata server cluster. This metadata manager node acts as the "brain" of the entire distributed file system, coordinating and optimizing the operational status of the metadata server cluster, playing a crucial role, especially during cluster expansion or contraction.

[0103] The main functions of the metadata manager node include:

[0104] 1. Real-time Monitoring: This involves monitoring key metrics of multiple metadata servers to obtain monitoring data. Key metrics include at least one of the following: load, response time, and storage utilization. Metadata server load typically refers to the server's workload when processing requests, which can be measured by various metrics, including but not limited to CPU utilization, memory usage, disk I / O, network traffic, and the number of requests being processed. Metadata server response time refers to the time it takes for the metadata server to respond to a user's request or instruction. Metadata server storage utilization typically refers to the ratio of used storage space to total storage space, and is an important indicator of metadata server efficiency. This data is usually transmitted and processed digitally to enable timely monitoring and control of the metadata server cluster.

[0105] 2. Load Balancing: Based on monitoring data, the process distribution of multiple metadata servers is dynamically adjusted. Each metadata server hosts one or more processes. For example, some metadata from a high-load metadata server is migrated to a low-load metadata server to achieve load balancing. After determining the migration strategy, the system will execute the migration operation. This typically involves updating internal data structures, such as metadata mapping tables, and the actual data movement. In some cases, the system may provide automated load balancing functionality, while in others, manual intervention by the system administrator may be required depending on the specific circumstances.

[0106] 3. Cluster scaling management: When it is necessary to add or reduce metadata server nodes, the metadata manager is responsible for formulating and executing detailed migration plans to ensure a smooth process.

[0107] 4. Fault detection and recovery: Promptly detect faults in metadata server nodes and initiate an automatic recovery process to redistribute affected metadata to healthy metadata server nodes.

[0108] With the introduction of the metadata manager, the migration process of the metadata server becomes faster and almost seamless. When it is necessary to migrate the target process from the first metadata server to the second metadata server, the metadata manager incrementally copies the target process's metadata from the first metadata server to the second metadata server.

[0109] Please refer to Figure 5 This document illustrates a flowchart of a metadata extension method under a distributed file system provided in an exemplary embodiment of the present disclosure. The distributed file system includes a metadata manager and multiple metadata servers. This embodiment uses the method in the metadata manager as an example for illustration. The method includes the following steps.

[0110] Step 501: Receive a request from the client to expand the cluster.

[0111] Expanding a cluster refers to adding computing resources such as servers, storage, and networks to improve its processing power, storage capacity, and reliability. A cluster expansion request can be used to instruct the addition of new nodes, i.e., adding a metadata server. A metadata server is responsible for storing and managing metadata. It typically contains key information such as data storage location, access permissions, and data structure, and is a core component for data management and retrieval.

[0112] Step 502: Based on the cluster expansion request, determine the target process to be migrated. The target process is used to manage metadata, and the identifier of the file or directory where the metadata is located has a hash mapping relationship with the target process.

[0113] A client is the software that allows users to interact with a distributed file system; it can be an application, a web browser, or a mobile application. In the context of cluster management, a client typically refers to the system or user interface that issues management requests (such as scaling up, migration, etc.).

[0114] Metadata is data that describes data; it provides information about the data's organization, storage, format, and attributes. In a distributed file system, metadata might include filename, size, creation date, etc.

[0115] A hash mapping exists between the identifier of the file containing the metadata and the target process, or between the identifier of the directory containing the metadata and the target process. The file identifier uniquely identifies the file, and the directory identifier uniquely identifies the directory. A hash mapping is a technique that maps data (such as filenames or keys) to specific locations (such as storage locations or memory addresses). A hash function transforms input parameters into a fixed-size output parameter, which determines the location of the data in the storage medium. In distributed file systems, hash mapping is used for data distribution and load balancing.

[0116] Step 503: Copy the target process's metadata from the first metadata server to the second metadata server and adjust the hash mapping relationship. The second metadata server is different from the first metadata server.

[0117] In this context, the target process can be one or more processes. The second metadata server differs from the first metadata server. The first metadata server is the source metadata server where the target process resided before migration, while the second metadata server is the target metadata server after migration. The first metadata server can be a high-load metadata server (e.g., its load metric exceeds a preset first load threshold), while the second metadata server can be a low-load metadata server (e.g., its load metric is less than a preset second load threshold). The load level of the first metadata server is higher than that of the second metadata server.

[0118] In some embodiments, the metadata of the target process is copied incrementally from a first metadata server to a second metadata server. Incremental replication is a data replication technique that only copies the data that has changed on the source server, rather than copying the entire dataset. This method can reduce the amount of data transferred and improve migration efficiency.

[0119] Optionally, client requests can continue to be processed during the data migration process; when preset conditions are met, the target process can be stopped, the remaining data of the target process can be copied to the second metadata server, and the hash mapping relationship can be adjusted; after the migration is completed, redundant data on the first metadata server can be cleaned up.

[0120] Preset conditions are the conditions that the system must meet before performing a specific operation (such as stopping the target process). These conditions can be based on factors such as time, data migration progress, and system load.

[0121] Once all metadata has been migrated to the second metadata server, the existing hash mappings need to be updated to reflect the new location of the data. This involves recalculating hash values ​​and associating these values ​​with the new location on the second metadata server. Specifically, while copying the remaining data of the target process to the second metadata server, the hash mappings corresponding to the metadata are adjusted, establishing a hash mapping between the identifier of the file or directory containing the metadata and the process on the migrated second metadata server.

[0122] Redundant data refers to data that is no longer needed or is duplicated in a system. Redundant data includes information related to the target process. Cleaning up redundant data is a crucial step in optimizing storage space and improving system performance during data migration and system maintenance.

[0123] In other words, when it is necessary to migrate the metadata of a target process from one metadata server to another, the metadata manager can perform the following steps:

[0124] 1. Develop a migration plan: Determine the scope of metadata that needs to be migrated and select the target metadata server.

[0125] 2. Preprocessing: Pre-create the necessary data structures and indexes on the target metadata server node.

[0126] 3. Incremental Synchronization: Using an incremental approach, the metadata of the target process is copied from the source metadata server to the target metadata server in time-sharing and batch-wise steps, while continuing to process client requests. During this process, the metadata manager will continuously respond to client requests to ensure service continuity.

[0127] 4. Switching: When the preset conditions are met, stop running the target process, complete the copying of the remaining metadata, that is, copy the remaining data of the target process to the second metadata server and adjust the hash mapping relationship.

[0128] 5. Cleanup: After the migration is complete, clean up the first metadata server, removing redundant data that is no longer needed, especially information related to the target process, in order to optimize server performance.

[0129] The advantage of this approach is that the entire migration process is almost transparent to the client, and the system can complete the reallocation of the metadata server without interrupting service. Furthermore, due to the use of incremental synchronization and rapid switching strategies, the migration process is significantly shortened, thereby minimizing the impact on system performance.

[0130] By introducing a metadata manager and implementing this efficient metadata server migration mechanism, the method provided in this disclosure improves the flexibility and scalability of distributed file systems. System administrators can quickly adjust the size and composition of the metadata server cluster according to actual needs without worrying about complex data migration issues. This not only simplifies system management but also provides strong support for dynamic load balancing, effectively reducing performance hotspots in distributed file systems.

[0131] In summary, the embodiments of this disclosure achieve efficient load balancing and reduce hotspot issues for metadata servers in several ways. Firstly, by employing a directory- or file-based hash algorithm, directory-level load balancing can be achieved without sacrificing directory operation performance. This method helps distribute the load of directory operations, effectively reducing metadata hotspots. Secondly, binding unique identifiers of files or directories to specific metadata servers and isolating directory entries from inodes minimizes the cost of migration, making metadata migration more efficient and cost-effective. Thirdly, introducing a metadata manager as an intermediate node allows for precise control over the scaling of the metadata server cluster. This mechanism enables rapid and cost-free migration of metadata servers to any node, further achieving load balancing and reducing hotspot issues.

[0132] In this embodiment of the disclosure, by hashing the directory, different directories can be evenly distributed across multiple metadata servers, reducing metadata hotspots. In an illustrative example, the method includes, but is not limited to, the following steps: Figure 6 As shown:

[0133] 1. Before sending a directory creation request, the client performs pre-checks. Pre-checks refer to a series of verification and preparation tasks performed before executing a specific operation to ensure the smooth operation and data integrity.

[0134] 2. The client parses and calculates the metadata server 1 where the parent directory is located.

[0135] 3. The client sends a directory creation request to the metadata server 1 where the parent directory is located.

[0136] 4. After receiving the directory creation request, metadata server 1 determines the target metadata server as metadata server 2 based on the hotspot status of the parent directory and the hotspot status of the metadata server cluster. It then performs a hash calculation based on the unique identifier of the parent directory, the unique identifier of the target directory to be created, and metadata server 2 to determine the mapping relationship between these three entities.

[0137] 5. Metadata server 1 sends a create directory entry message to metadata server 2.

[0138] 6. After receiving the message to create a directory entry, metadata server 2 creates a target directory and an index node.

[0139] 7. After metadata server 2 is created, a success message is sent to metadata server 1 node.

[0140] 8. After receiving the creation completion message from metadata server 2, metadata server 1 considers the directory creation request to be completed and then replies with a response message to the client.

[0141] 9. The client receives a response message, confirming that the entire directory creation is complete.

[0142] In this embodiment of the disclosure, by introducing a metadata manager as a monitoring node, the metadata server is divided into multiple metadata management services, i.e., multiple processes. This allows for arbitrary scaling and scheduling of metadata server nodes, resulting in seamless data migration. In an illustrative example, the method includes, but is not limited to, the following steps: Figure 7 As shown:

[0143] 1. Perform pre-checks.

[0144] 2. The client sends a request to expand the cluster to the metadata manager.

[0145] 3. After receiving the cluster expansion request, the metadata manager performs calculations on the metadata server cluster. The calculations determine that the processes that need to be migrated are process A and process C in metadata server 1. There is a hash mapping relationship between process A and process C and the identifier of the file or directory where the metadata to be migrated is located.

[0146] 4. The metadata manager uses an incremental method to copy the metadata of process A and process C from metadata server 1 to metadata server 2, and continues to process client requests during the data migration process.

[0147] 5. When the preset conditions are met, the metadata manager stops running processes A and C, copies the remaining data of processes A and C to metadata server 2, and adjusts the hash mapping relationship; after the migration is completed, it cleans up the redundant data of metadata server 1.

[0148] 6. The metadata manager issues process creation operations to metadata server 1 and metadata server 2, that is, it issues operations to create process E and process F to metadata server 1, and operations to create process G and process H to metadata server 2.

[0149] 7. The metadata manager replies with a response message to the client, and the client considers the expansion request to be complete.

[0150] In summary, this disclosure provides a method for extending metadata in a distributed system. This method employs a directory- or file-based hash algorithm to evenly distribute directories across multiple metadata service nodes. Simultaneously, it binds unique file / directory identifiers to specific metadata servers and separates directory entries from index nodes. This achieves directory-level load balancing without compromising directory operation performance, thereby reducing metadata hotspots. Furthermore, this disclosure introduces a metadata manager as a monitoring node for dynamic scheduling and load balancing of the metadata server cluster. The metadata servers are designed as stateless services, using object storage services as backend storage. By minimizing data migration costs, metadata servers can be quickly and cost-free moved to any node, achieving load balancing, reducing hotspots, and significantly minimizing the impact on business operations. Compared to traditional methods, this disclosure provides better load balancing capabilities, lower data migration costs, and higher scalability.

[0151] The following are device embodiments of the present disclosure. For parts not described in detail in the device embodiments, please refer to the technical details disclosed in the above method embodiments.

[0152] Please refer to Figure 8This illustration shows a schematic diagram of a metadata extension device under a distributed file system provided in an exemplary embodiment of the present disclosure. The device can implement all or part of a distributed file system through software, hardware, or a combination of both. The device includes: a receiving module 82, a determining module 83, and an extension module 84.

[0153] The receiving module 82 is used to receive the cluster expansion request sent by the client;

[0154] The determination module 83 is used to determine the target process to be migrated based on the cluster expansion request. The target process is used to manage metadata, and the identifier of the file or directory where the metadata is located has a hash mapping relationship with the target process.

[0155] Extension module 84 is used to copy the target process's metadata from the first metadata server to the second metadata server and adjust the hash mapping relationship. The second metadata server is different from the first metadata server.

[0156] In one possible implementation, extension module 84 is also used to: copy the target process's metadata from the first metadata server to the second metadata server in an incremental manner, and continue to process client requests during the data migration process;

[0157] When the preset conditions are met, the target process is stopped, the remaining data of the target process is copied to the second metadata server, and the hash mapping relationship is adjusted.

[0158] After the migration is complete, clean up redundant data on the first metadata server.

[0159] In another possible implementation, the apparatus further includes: a distribution module, for:

[0160] Received a directory creation request from the client, which includes the directory identifier of the target directory to be created;

[0161] Based on the directory identifier of the target directory, the corresponding hash value is determined by a preset hash function;

[0162] Based on the hash value, the target directory is assigned to the target metadata server so that the target metadata server can create the target directory.

[0163] In another possible implementation, the allocation module is also used for:

[0164] Based on the directory identifier of the parent directory of the target directory and the directory identifier of the target directory, the corresponding hash value is determined by a preset hash function;

[0165] The parent directory identifier is used to uniquely identify the parent directory among multiple directories, and the target directory identifier is used to uniquely identify the target directory among multiple directories.

[0166] In another possible implementation, the device further includes: a binding module for:

[0167] Bind the directory identifier or file identifier of the target directory to the process of the target metadata server, and separate the directory entries of the target directory from the inodes;

[0168] Among them, the file identifier is used to uniquely identify the target file in the target directory among multiple files.

[0169] In another possible implementation, the apparatus further includes: a reallocation module for:

[0170] When any one of the multiple metadata servers fails, the directory identifier or file identifier bound to the failed metadata server is reassigned to the processes of the other metadata servers.

[0171] In another possible implementation, the distributed file system also includes a metadata manager, and the apparatus further includes an adjustment module for:

[0172] The metadata manager monitors the key metrics of multiple metadata servers and obtains monitoring data. The key metrics include at least one of the following: load, response time, and storage utilization.

[0173] The metadata manager dynamically adjusts the process distribution of multiple metadata servers based on monitoring data, with each metadata server hosting one or more processes.

[0174] It should be noted that the above embodiments only illustrate the division of the above functional modules when implementing the device. In actual applications, the above functions can be assigned to different functional modules according to actual needs, that is, the content structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0175] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0176] This disclosure also provides a metadata extension device under a distributed file system, the device comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to implement the above-described method when executing the instructions stored in the memory.

[0177] This disclosure also provides a non-volatile computer-readable storage medium storing computer program instructions that, when executed by a processor, implement the above-described method.

[0178] This disclosure also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of a computing device, the processor in the computing device performs the above-described method.

[0179] Figure 9 This is a block diagram illustrating an apparatus 1900 for implementing a metadata extension method under a distributed file system, according to an exemplary embodiment. For example, apparatus 1900 may be provided as a server. (Refer to...) Figure 9 The apparatus 1900 includes a processing component 1922, which further includes one or more processors, and memory resources represented by memory 1932 for storing instructions, such as application programs, that can be executed by the processing component 1922. The application programs stored in memory 1932 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 1922 is configured to execute instructions to perform the methods described above.

[0180] Device 1900 may also include a power supply component 1926 configured to perform power management of device 1900, a wired or wireless network interface 1950 configured to connect device 1900 to a network, and an input / output interface 1958 (I / O interface). Device 1900 can operate on an operating system, such as Windows Server, stored in memory 1932. TM macOS X TM Unix TM Linux TM FreeBSD TM Or similar.

[0181] In an exemplary embodiment, a non-volatile computer-readable storage medium is also provided, such as a memory 1932 including computer program instructions that can be executed by a processing component 1922 of the device 1900 to perform the above-described method.

[0182] This disclosure can be a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for causing a processor to implement various aspects of this disclosure.

[0183] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example—but not limited to—electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0184] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0185] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0186] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0187] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0188] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0189] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0190] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for extending metadata in a distributed file system, characterized in that, The distributed file system includes multiple metadata servers, and the method includes: Received a request from the client to expand the cluster; Based on the cluster expansion request, the target process to be migrated is determined. The target process is used to manage metadata, and the identifier of the file or directory where the metadata is located has a hash mapping relationship with the target process. The metadata of the target process is copied from the first metadata server to the second metadata server, and the hash mapping relationship is adjusted. The second metadata server is different from the first metadata server. The step of copying the metadata of the target process from the first metadata server to the second metadata server and adjusting the hash mapping relationship includes: The metadata of the target process is copied from the first metadata server to the second metadata server in an incremental manner, and client requests continue to be processed during the data migration process; When the preset conditions are met, the target process is stopped, the remaining data of the target process is copied to the second metadata server, and the hash mapping relationship is adjusted. After the migration is complete, clean up redundant data on the first metadata server; The method further includes: Receive a directory creation request sent by the client, the directory creation request including the directory identifier of the target directory to be created; Based on the directory identifier of the target directory, the corresponding hash value is determined by a preset hash function; Based on the hash value, the target directory is assigned to the target metadata server, so that the target metadata server can create the target directory; The directory identifier or file identifier of the target directory is bound to the process of the target metadata server, and the directory entries of the target directory are separated from the index nodes. The directory entries include the metadata of the file or directory, and the index nodes contain the file attributes and data block location information. The file identifier is used to uniquely identify the target file in the target directory among multiple files.

2. The method according to claim 1, characterized in that, The step of determining the corresponding hash value based on the directory identifier of the target directory using a preset hash function includes: The corresponding hash value is determined by using the preset hash function based on the directory identifier of the parent directory of the target directory and the directory identifier of the target directory. The directory identifier of the parent directory is used to uniquely identify the parent directory among multiple directories, and the directory identifier of the target directory is used to uniquely identify the target directory among multiple directories.

3. The method according to claim 1, characterized in that, The method further includes: When any one of the plurality of metadata servers fails, the directory identifier or file identifier bound to the failed metadata server is reassigned to the processes of the other metadata servers.

4. The method according to any one of claims 1 to 3, characterized in that, The distributed file system also includes a metadata manager, and the method further includes: The metadata manager monitors the key metrics of each of the multiple metadata servers to obtain monitoring data. The key metrics include at least one of load, response time, and storage utilization. The metadata manager dynamically adjusts the process distribution of the multiple metadata servers based on the monitoring data, with each metadata server hosting one or more processes.

5. A metadata extension device under a distributed file system, characterized in that, The distributed file system includes multiple metadata servers, and the device includes: The receiving module is used to receive cluster expansion requests sent by clients; The determination module is used to determine the target process to be migrated based on the cluster expansion request. The target process is used to manage metadata, and the identifier of the file or directory where the metadata is located has a hash mapping relationship with the target process. An extension module is used to copy the metadata of the target process from a first metadata server to a second metadata server and adjust the hash mapping relationship, wherein the second metadata server is different from the first metadata server; The expansion module is also used for: The metadata of the target process is copied from the first metadata server to the second metadata server in an incremental manner, and client requests continue to be processed during the data migration process; When the preset conditions are met, the target process is stopped, the remaining data of the target process is copied to the second metadata server, and the hash mapping relationship is adjusted. After the migration is complete, clean up redundant data on the first metadata server; The device further includes: a distribution module, used for: Receive a directory creation request sent by the client, the directory creation request including the directory identifier of the target directory to be created; Based on the directory identifier of the target directory, the corresponding hash value is determined by a preset hash function; Based on the hash value, the target directory is assigned to the target metadata server, so that the target metadata server can create the target directory; The device further includes: a binding module, used for: The directory identifier or file identifier of the target directory is bound to the process of the target metadata server, and the directory entries of the target directory are separated from the index nodes. The directory entries include the metadata of the file or directory, and the index nodes contain the file attributes and data block location information. The file identifier is used to uniquely identify the target file in the target directory among multiple files.

6. A computing device, characterized in that, The computing device includes: processor; Memory used to store processor-executable instructions; The processor is configured to implement the method of any one of claims 1 to 4 when executing instructions stored in the memory.

7. A non-volatile computer-readable storage medium storing computer program instructions thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 4.

Images