Load balancing method, device, electronic device, storage medium and program product
By combining the load prediction model and subtree migration strategy, the problem of metadata load imbalance in distributed storage systems is solved, and efficient load balancing and system performance improvement of metadata server clusters are achieved.
Patent Information
- Application Number
- CN202510768694.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-10
- Publication Date
- 2025-10-03
- Estimated Expiration
- 2045-06-10
AI Technical Summary
In the prior art, metadata load balancing methods in distributed storage systems cannot dynamically adapt to the expansion of metadata server clusters and cannot accurately predict load changes, resulting in load imbalance and affecting system performance and scalability.
By combining the target data and load prediction model of each server node in the metadata server cluster, the load balancing degree of each server node in the future time step is determined. The metadata server cluster is load balanced using the subtree migration strategy, which includes weighted comprehensive calculation of multiple load indicators and time series analysis to optimize the subtree migration decision.
The load balancing effect of the metadata server cluster is improved, system resource consumption is reduced, system performance and stability are improved, system adaptability and scalability are enhanced, and unnecessary migration operations are reduced.
Smart Images

Figure CN120276873B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of task scheduling technology, and in particular to a load balancing method, device, electronic device, storage medium, and program product. Background Art
[0002] In distributed storage systems, metadata management plays a key role in system performance. With the explosive growth of data volumes and the increasing complexity of application scenarios, such as cloud computing, big data analytics, and artificial intelligence, the demand for storage systems continues to increase, and metadata load balancing issues are becoming increasingly prominent.
[0003] In practical applications, such as file storage in enterprise data centers and large-scale data management in scientific research institutions, unbalanced metadata loads can lead to overloads on some metadata servers, while other server resources remain idle, severely impacting the overall performance, responsiveness, and scalability of the system. Related metadata load balancing methods are unable to dynamically adapt to the expansion of metadata server clusters and accurately predict dynamic load changes within them. Consequently, they suffer from poor load balancing across metadata server clusters, and there is an urgent need to improve the load balancing performance of metadata server clusters.
[0004] In the related art, the problem of how to improve the balancing effect of metadata load balancing in a distributed storage system has not yet been effectively solved. Summary of the Invention
[0005] The present application provides a load balancing method, apparatus, electronic device, storage medium and program product to at least solve the problem in the related art of how to improve the balancing effect of metadata load balancing in a distributed storage system.
[0006] The present application provides a load balancing method, comprising: determining a first load balancing degree of each server node in a metadata server cluster at least one time step after a current time point based on target data and a load prediction model corresponding to each server node in the metadata server cluster, wherein the target data comprises one of the following: a first load index at the current time point, a second load balancing degree related to the first load index; determining a subtree migration strategy for the metadata server cluster through the first load balancing degree and the second load balancing degree, and balancing the load of the metadata server cluster through the subtree migration strategy.
[0007] The present application also provides a load balancing device, including: a first determination module, used to determine the first load balancing degree of each server node in the metadata server cluster at least one time step after the current time point based on the target data and load prediction model corresponding to each server node in the metadata server cluster, wherein the target data includes one of the following: the first load index at the current time point, and a second load balancing degree related to the first load index; a second determination module, used to determine the subtree migration strategy for the metadata server cluster through the first load balancing degree and the second load balancing degree, and balance the load of the metadata server cluster through the subtree migration strategy.
[0008] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned load balancing methods when executing the computer program.
[0009] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned load balancing methods are implemented.
[0010] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned load balancing methods when executed by a processor.
[0011] Through this application, by combining the target data corresponding to each server node in the metadata server cluster and the load prediction model, the first load balancing degree of each server node at least one time step after the current time point is accurately determined, wherein the target data includes one of the following: the first load index at the current time point, the second load balancing degree related to the first load index; thereby, the predicted first load balancing degree and the second load balancing degree related to the first load index of each server node can be combined to jointly determine the subtree migration strategy for the metadata server cluster, and the load of the metadata server cluster can be balanced by the subtree migration strategy. Therefore, the technical problem of how to improve the balancing effect of metadata load balancing in a distributed storage system in the related technology can be solved, and the technical effect of improving the load balancing effect of the metadata server cluster can be achieved. BRIEF DESCRIPTION OF THE DRAWINGS
[0012] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.
[0013] Figure 1 This is a hardware structure block diagram of a computer terminal of a load balancing method according to an embodiment of the present application;
[0014] Figure 2 is a flow chart of a load balancing method according to an embodiment of the present application;
[0015] Figure 3 is an overall architecture diagram of a distributed storage system according to an embodiment of the present application;
[0016] Figure 4 is an architectural diagram of an intelligent load balancing controller according to an embodiment of the present application;
[0017] Figure 5 It is a structural block diagram of a load balancing device according to an embodiment of the present application. DETAILED DESCRIPTION
[0018] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.
[0019] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.
[0020] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.
[0021] In conjunction with the specific application environment architecture or specific hardware architecture on which the execution of the load balancing method depends, the specific application environment architecture or specific hardware architecture is described herein.
[0022] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking running on a computer terminal as an example, Figure 1 This is a hardware structure diagram of a computer terminal of a load balancing method according to an embodiment of the present application. Figure 1 As shown, the computer terminal may include one or more ( Figure 1Only one is shown) a processor 102 (the processor 102 may include but is not limited to a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data. The computer terminal may also include a transmission device 106 and an input / output device 108 for communication functions. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above-mentioned computer terminal. For example, the computer terminal may also include Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.
[0023] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the load balancing method in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implementing the above-mentioned method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.
[0024] Transmission device 106 is used to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by a computer terminal's communications provider. In one embodiment, transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.
[0025] Figure 2 This is a flow chart of a load balancing method according to an embodiment of the present application, which is applied to a metadata server cluster of a distributed storage system. Figure 2 As shown, the process includes the following steps:
[0026] Step S202: determining a first load balancing degree of each server node in the metadata server cluster at least one time step after a current time point based on target data corresponding to each server node and a load prediction model, wherein the target data includes one of the following: a first load index at the current time point, and a second load balancing degree related to the first load index;
[0027] Step S204: determining a subtree migration strategy for the metadata server cluster based on the first load balancing degree and the second load balancing degree, and balancing the load of the metadata server cluster based on the subtree migration strategy.
[0028] Through the above steps, the first load balancing degree of each server node in the metadata server cluster at least one time step after the current time point is determined based on the target data and load prediction model corresponding to each server node in the metadata server cluster, wherein the target data includes one of the following: the first load index at the current time point, the second load balancing degree related to the first load index; the subtree migration strategy for the metadata server cluster is determined by the first load balancing degree and the second load balancing degree, and the load of the metadata server cluster is balanced by the subtree migration strategy. Therefore, the technical problem of how to improve the balancing effect of metadata load balancing in a distributed storage system in the related technology can be solved, and the technical effect of improving the load balancing effect of the metadata server cluster can be achieved.
[0029] The embodiments of the present application provide a load balancing method, and the method is described in detail in conjunction with the execution process of the load balancing method.
[0030] In an exemplary embodiment, before determining the first load balancing degree of each server node in the metadata server cluster at least one time step after the current time point based on the target data and load prediction model corresponding to each server node in the metadata server cluster, the method also includes: obtaining the first load indicator of each server node in a preset manner, wherein the first indicator type in the first load indicator includes at least one of the following: central processing unit utilization rate, memory occupancy rate, network bandwidth utilization rate, metadata read and write request queue length, metadata cache hit rate; determining the second load balancing degree through the first load indicator and the load balancing function.
[0031] That is, before inputting target data into the load prediction model to predict the first load balance degree, it is necessary to obtain a first load indicator and the first load balance degree. The first load indicator is a real-time load indicator for each server node. Preset methods for obtaining the first load indicator include Linux commands and distributed storage system monitoring services. The second load balance degree is an explicit indicator for determining the real-time load status of each server node. The more first indicator types included in the first load indicator used to calculate the second load balance degree, the more comprehensive and accurate the analysis of the first load indicator will be.
[0032] Furthermore, the second load balancing degree is determined by the first load indicator and the load balancing function, including: determining the position measurement of the second load indicator in the third load indicator, wherein the second load indicator is the load indicator of each indicator type in the first load indicator, and the third load indicator includes: the second load indicators corresponding to multiple server nodes in the metadata server cluster; inputting the first load indicator and the position measurement into the load balancing function to obtain the second load balancing degree.
[0033] Optionally, the above position metric may be an average or median. Optionally, the load balancing function may be:
[0034] ;(1)
[0035] In the above formula (1), is the second load balancing degree, is the weight of each indicator in the first indicator type in the first load indicator, and ; is the CPU usage, is the memory usage, For network bandwidth utilization, The length of the metadata read and write request queue, is the metadata cache hit rate; in formula (1) Indicates the first server nodes.
[0036] 、 、 、 、 They are the average values of the corresponding indicators of all server nodes in the metadata server cluster. By comparing with the average values of the corresponding indicators of the metadata server cluster, we can intuitively obtain the relative load of each server node in the cluster (that is, the abbreviation of the metadata server cluster).
[0037] Weight It is used to reflect the importance of different indicators on the system load balancing. It can be adjusted according to the actual system requirements. For example, in the scenario where the metadata read and write speed is extremely high, the weight of the metadata read and write request queue length can be appropriately increased. .
[0038] By combining the load indicators of multiple first indicator types of each server node and calculating the real-time load balancing degree of each server node (i.e., the above-mentioned second load balancing degree), real-time dynamic load evaluation of each server node is achieved, thereby achieving the technical effect of comprehensively considering the load situation of the metadata server cluster.
[0039] In an exemplary embodiment, before determining the first load balancing degree of each server node in the metadata server cluster at least one time step after the current time point based on the target data and load prediction model corresponding to each server node in the metadata server cluster, the method also includes: obtaining the first historical load data of the metadata server cluster, wherein the first historical load data includes: a fourth load indicator and a third load balancing degree corresponding to the fourth load indicator, wherein the second indicator type in the fourth load indicator includes: central processing unit utilization rate, memory occupancy rate, network bandwidth utilization rate, metadata read and write request queue length, metadata cache hit rate; training a preset model through the first historical load data to obtain the load prediction model.
[0040] Optionally, obtaining the first historical load data of the metadata server cluster includes: obtaining the second historical load data of each server node; and normalizing the second historical load data to obtain the first historical load data.
[0041] Furthermore, the load prediction model is obtained by training a preset model with the first historical load data, including: estimating the model order of the preset model with a parameter estimation method, and selecting the optimal model from the preset models having different order combinations of the model orders with a model selection criterion; estimating the model coefficients of the optimal model with the parameter estimation method; and obtaining the load prediction model by training the optimal model with the model coefficients with the first historical load data.
[0042] The preset model can be the autoregressive moving average model (ARMA(p,q)). Parameter estimation methods include least squares and maximum likelihood estimation, and model selection criteria include the Akaike Information Criterion (AIC) and the Bayesian Information Criterion (BIC).
[0043] The load prediction model trained based on the historical load data of the metadata server cluster can be used to accurately predict the load change trend of the metadata server cluster. Then, combined with the real-time load balancing of each server node in the metadata server cluster, the load situation of the entire metadata server cluster is determined, and the metadata distribution is adjusted in time to ensure load balancing of each server node.
[0044] In an exemplary embodiment, a first load balancing degree of each server node in a metadata server cluster at least one time step after a current time point is determined based on target data and a load prediction model corresponding to the server node in the metadata server cluster, including: inputting the target data into the load prediction model to obtain a fourth load balancing degree output by the load prediction model; determining whether the difference between the second load balancing degree and the fourth load balancing degree is less than a target value; and if the difference is less than the target value, performing weighted fusion on the second load balancing degree and the fourth load balancing degree to obtain the first load balancing degree.
[0045] That is to say, after inputting the target data into the load prediction model and obtaining the fourth load balancing degree output by the model, it is necessary to further determine whether the prediction result of the load prediction model is accurate, that is, to determine whether the deviation from the real-time second load balancing degree of each server node is less than the target value; if it is less than the target value, the first load balancing degree is obtained by weighted fusion of the second load balancing degree and the fourth load balancing degree.
[0046] Furthermore, after determining whether the difference between the second load balancing degree and the fourth load balancing degree is less than the target value, the method also includes: updating the first historical load data of the metadata server cluster and updating the load prediction model through the updated first historical load data when a first preset condition is met; and updating the load balancing function through the updated first historical load data, wherein the load balancing function is used to determine the second load balancing degree through the first load indicator; wherein the first preset condition includes one of the following: the difference between the second load balancing degree and the fourth load balancing degree is greater than or equal to the target value, the cluster scale of the metadata server cluster changes, and the workload type of the metadata server cluster changes.
[0047] The method for updating the first historical load data of the metadata server cluster includes: obtaining recent historical load data of the metadata server cluster for multiple time steps before the current time point, and adding the recent historical load data to the first historical load data, or updating the first historical load data. Updating the load prediction model using the updated first historical load data includes: retraining or continuing to train the load prediction model using the updated first historical load data; and updating the load balancing function using the updated first historical load data includes: adjusting the weights corresponding to various indicators in the load balancing function using the updated first historical load data.
[0048] Through the update mechanism of historical load data, the load prediction model and load balancing function can change with the dynamic changes of the metadata server cluster, so that the real-time load balancing degree and the predicted load balancing degree (i.e., the above-mentioned first load balancing degree) calculated by this application are close to the actual situation of the cluster, thereby making the determination of the cluster load situation more accurate.
[0049] In an exemplary embodiment, a subtree migration strategy for the metadata server cluster is determined by the first load balancing degree and the second load balancing degree, including: determining a migration subtree in the subtree by the topological structure and access popularity of the subtree in the metadata server cluster, wherein the subtree is managed by at least one server node in the metadata server cluster; and determining a migration target of the migration subtree in the metadata server cluster by the first load balancing degree and the second load balancing degree; and determining the subtree migration strategy by the migration subtree and the migration target.
[0050] Furthermore, the migration subtree in the subtree is determined through the topological structure and access popularity of the subtree in the metadata server cluster, including: determining the topological index of the subtree to be evaluated in the subtree through the topological structure, wherein the topological index includes: the subtree depth of the subtree to be evaluated, and the number of files and directories included in the subtree to be evaluated; determining the topological importance factor of the subtree to be evaluated through the subtree depth and the number of files and directories; and determining the migration subtree in the subtree to be evaluated through the topological importance factor and the access popularity.
[0051] The calculation formula of the topological importance factor is:
[0052] ;(2)
[0053] In the above formula (2), is the topological importance factor, is the subtree depth, is the number of files and directories; and is a weight coefficient used to adjust the weight coefficient of the influence of the subtree depth (Depth) and the number of files and directories contained in the subtree (Count) on the topology importance factor. For example, in a system with a clear directory structure and a large impact of depth on the load, it is appropriate to increase The value of , highlighting the depth factor contribution.
[0054] Access popularity can be determined through client access logs, that is, the number of times a subtree was accessed within time t before the current time point (reflecting the access status of the subtree) can be determined through client access logs. The specific formula is:
[0055] ;(3)
[0056] in, For visit popularity, Is the starting time for counting visit popularity, It is the end time of the visit popularity statistics. , Indicates the statistical time period. By adjusting the statistical time period, you can obtain the access popularity of subtrees at different time granularities.
[0057] The migration subtree in the subtree to be evaluated is determined by the topological importance factor and the access popularity, that is, the subtree with a high combined score of access popularity and topological importance factor is selected as the migration subtree. The combined score of access popularity and topological importance factor can be calculated by weighted fusion of access popularity and topological importance factor.
[0058] Furthermore, the migration target of the migration subtree in the metadata server cluster is determined by the first load balancing degree and the second load balancing degree, including: obtaining the evaluation index of each server node, wherein the evaluation index includes: the first load balancing degree and the second load balancing degree; calculating the evaluation score of each server node by using the evaluation index and the evaluation function; and taking the server node with the highest evaluation score in the metadata server cluster as the migration target.
[0059] The evaluation indicators specifically include: first load balancing degree, second load balancing degree, storage capacity and network bandwidth. The evaluation function is:
[0060] ;(4)
[0061] in, represents the evaluation score, Indicates the second load balancing degree, Indicates the first load balancing degree, Indicates storage capacity, represents the network bandwidth, and in formula (4) Indicates the first server nodes; is the weight, and .
[0062] In a scenario that is sensitive to storage capacity, the weight of storage capacity can be increased. , making the system more inclined to select nodes with large storage capacity as migration targets. Select server nodes with high evaluation scores as migration targets. 、 、 、 They are the average values of the evaluation indicators of all server nodes in the metadata server cluster, which are used to standardize and compare the indicators of each node.
[0063] Furthermore, the subtree migration strategy is determined by the migration subtree and the migration target, including: determining the migration timing of the migration subtree through the at least one time step; and determining the migration mechanism allowed to be adopted during the migration process of the migration subtree, wherein the migration mechanism includes at least one of the following: asynchronous migration, data prefetching, version control and transaction mechanism; the subtree migration strategy is determined by the migration object, migration timing and the migration mechanism, wherein the migration object includes: the migration subtree and the migration target.
[0064] That is, the migration object, migration timing, and migration mechanism during the migration process together constitute the subtree migration strategy. Wherein, determining the migration timing of the migration subtree by the at least one time step means that the subtree migration strategy is completed within at least one time step.
[0065] In an embodiment of the present application, the migration subtree is determined by the access popularity and topological importance factor of the subtree, and the migration target is determined by the real-time load balancing degree and the predicted load balancing degree, so that the migration object in the subtree migration strategy can be accurately measured, thereby reducing unnecessary migration operations and reducing system resource consumption.
[0066] In an exemplary embodiment, the load of the metadata server cluster is balanced through the subtree migration strategy, including: when the migration mechanism in the subtree migration strategy includes asynchronous migration and data prefetching, the prefetched data amount of the migration subtree is determined by the historical access frequency and subtree size of the migration subtree; and the migration subtree is migrated to the migration target by at least one thread corresponding to the prefetched data amount and the asynchronous migration to balance the load of the metadata server cluster.
[0067] The method of determining the pre-fetched data amount of the migration subtree according to the historical access frequency and subtree size of the migration subtree includes determining the pre-fetched data amount by multiplying the historical access frequency, the subtree size and the pre-fetch coefficient.
[0068] In an exemplary embodiment, the load of the metadata server cluster is balanced through the subtree migration strategy, including: when the migration mechanism in the subtree migration strategy includes version control and transaction mechanism, a version number that uniquely identifies the migration subtree is assigned to the migration subtree, and metadata operations related to the migration subtree are recorded; the metadata operation is re-executed on the migration target through the transaction mechanism and the version number to balance the load of the metadata server cluster, wherein, when the transaction mechanism is successfully executed, the version number is updated, and when the transaction mechanism fails to execute, a rollback operation is performed based on the version number and the metadata operation.
[0069] In an exemplary embodiment, the method also includes: in the event that the cluster scale of the metadata server cluster changes, determining the load migration ratio of the first server node through the second load balancing degree, wherein the first server node includes one of the following: a second server node and a third server node, wherein the second server node is a faulty server node in the metadata server cluster, and the third server node is an original server node in the metadata server cluster under a second preset condition, and the second preset condition includes: there are new server nodes in the metadata server cluster; and migrating the load in the first server node according to the load migration ratio.
[0070] Furthermore, migrating the load in the first server node according to the load migration ratio includes: determining the load to be migrated in the load in the first server node according to the migration ratio; migrating the load to be migrated to the fourth server node, wherein the fourth server node includes one of the following: other server nodes in the metadata server cluster except the faulty server node, and the newly added server node.
[0071] That is to say, through the load balancing method of the embodiment of the present application, the load in the metadata server cluster can be dynamically adjusted when the cluster scale changes. For example, if there is a new server node, the subtree with a high comprehensive score of access popularity and topological importance factors will be migrated to the new server node through the load balancing method; when there is a faulty server node, the subtree managed in the faulty server node will be migrated to a non-faulty server node with a high evaluation score.
[0072] In order to better understand the process of the above-mentioned load balancing method, the implementation process of the above-mentioned load balancing method is described below in combination with an optional embodiment, but it is not used to limit the technical solution of the embodiment of the present application.
[0073] The load balancing method of the embodiment of the present application is applied to a metadata server cluster in a distributed storage system. A distributed storage system refers to a system that stores data on multiple independent nodes and manages it in a distributed manner, aiming to provide a high-performance, high-reliability and scalable storage solution. The design concept of the distributed storage system is based on scalability and fault tolerance. It adopts a decentralized distributed architecture, slices the data and stores it in the form of objects on multiple nodes, and ensures the capacity and load balancing of each node. It uses a technology for data access and management through the network, and provides a unified storage interface. Among them, high reliability means that the distributed storage system adopts data redundancy and automatic fault recovery mechanism to ensure the reliability and persistence of data. High scalability means that the distributed storage system can dynamically expand horizontally to support hundreds or even thousands of nodes.
[0074] Distributed storage systems typically adopt an architecture that separates metadata from data. While this architecture facilitates independent scaling of metadata and data performance, it also presents metadata management challenges. Metadata operations account for a significant portion of file system workloads in distributed storage systems. Research shows that in some scenarios, metadata operations account for over 70% and even as high as 94%. Furthermore, the presence of large numbers of small files and the use of fast storage devices make metadata processing a performance bottleneck. Therefore, metadata load balancing is necessary for distributed storage systems.
[0075] The metadata load balancing methods that can be used in distributed storage systems include hash mapping and subtree partitioning.
[0076] In a distributed file system that uses hash mapping, a hash operation is performed on the file path name, inode number, or other unique identifier. Taking the file path name hash as an example, the full path of the file is used as input, and a hash value is calculated using a specific hash function (such as Message-Digest Algorithm 5 (MD5) or Secure Hash Algorithm 1 (SHA-1)). This hash value is mapped to a specific range, which corresponds to different metadata servers (MDS, equivalent to the server nodes in the above embodiment). When a client requests access to the metadata of a file, the system calculates a hash value based on the file's identifier, then uses the hash value to find the corresponding MDS and obtain the metadata from it.
[0077] The subtree partitioning method assigns metadata subtrees to different MDSs based on subtree usage patterns and current cluster load. Taking dynamic subtree partitioning as an example, the load balancing process involves multiple steps. First, the MDS collects metadata load statistics, including metrics such as the number of accesses and file counts for each subtree. Next, based on these statistics, it determines whether the MDS cluster is experiencing load imbalance. If so, it proceeds to the next step. The cluster is then divided into the export metadata server (export MDS) and the import metadata server (import MDS) to determine the load required for migration. Next, when selecting subtrees for migration, the MDS scans the directory tree for subtrees with high access popularity (e.g., high access counts and large file counts) as migration candidates. Finally, the selected subtrees are migrated from the export MDS to the import MDS. In practice, the MDS continuously monitors the number of files and popularity of each directory. If the number of files or popularity is too high, the corresponding subtree is pre-split into smaller subtrees to facilitate subsequent migration.
[0078] However, the disadvantages of the above hash mapping method are: in terms of data locality, due to the randomness of the hash operation, the file metadata that was originally logically related may be stored in different MDSs. In a data analysis task, it is necessary to frequently access the metadata of multiple files in the same directory. These file metadata are distributed across multiple MDSs after hash mapping. Each access requires obtaining data across MDSs, which increases network overhead and latency. In terms of dynamic adaptability, when the scale of the MDS cluster expands and new MDSs are added, the existing hash mapping relationship will not be automatically adjusted. This will make the new MDS unable to effectively share the load, and some of the original MDSs are overloaded, affecting system performance and scalability. When an access hotspot appears and a large number of requests are concentrated on the MDS corresponding to a specific hash partition, the MDS is prone to overload, while other MDSs are in a low-load state, exacerbating the system load imbalance.
[0079] The aforementioned subtree partitioning approach has drawbacks: Regarding load prediction, the related art's popularity count-based prediction method suffers from serious flaws. It estimates future load based solely on historical access counts and fails to consider dynamic workload trends. In artificial intelligence (AI) training workloads, file access patterns fluctuate rapidly, leading to significant discrepancies between popularity count predictions and actual access. This makes it difficult to accurately assess load changes, impacting the timeliness and accuracy of load balancing decisions. Regarding subtree selection, the "one-size-fits-all" approach fails to consider the unique access patterns of different workloads. For scanning workloads, such as AI training, files are rarely re-accessed. A popularity-based migration strategy cannot effectively predict future access patterns, resulting in inappropriate migration subtrees, wasted resources, inability to achieve load balancing, and reduced system performance. In other words, dynamic subtree partitioning methods suffer from load imbalance and resource waste, and accurate models and reasonable heuristic algorithms for metadata migration and load balancing are difficult to derive.
[0080] In summary, both hash mapping and subtree partitioning methods have poor metadata load balancing effects in distributed storage systems.
[0081] In view of the shortcomings of the above-mentioned hash mapping and subtree partitioning methods, the embodiments of the present application provide corresponding solutions through the above-mentioned load balancing method. Specifically:
[0082] 1) This application solves the problem of load imbalance in scenarios with massive small files: The hash mapping method in a distributed storage system destroys data locality due to the random allocation of metadata storage locations. When the cluster expands or hot spots appear, the load imbalance is serious. Although the subtree partitioning method attempts to dynamically allocate based on the load, the prediction is inaccurate and the selection strategy is single, and it still cannot effectively balance the load. This application will accurately identify the load imbalance status of the metadata service cluster through an innovative load monitoring and prediction mechanism. By using an improved algorithm and combining a dynamic load evaluation method with multiple system indicators, the load situation of the metadata service is comprehensively considered, the load change trend is predicted in advance, and the metadata distribution is adjusted in a timely manner to ensure the load balance of each metadata service and improve the overall performance and stability of the system;
[0083] 2) This application optimizes subtree migration decisions: The subtree partitioning method adopts a "one-size-fits-all" approach to subtree selection, without considering the differences between different workloads, resulting in unreasonable migration decisions. This application uses a workload-aware subtree migration strategy to deeply analyze the access patterns, read and write characteristics, data locality and other characteristics of different workloads. For workloads with mainly sequential access, subtrees with a low probability of continuous access are migrated first; for workloads with frequent random access, migration objects are selected based on the access probability distribution of files within the subtree. In this way, the accuracy of subtree migration is improved, unnecessary migration operations are reduced, system resource consumption is reduced, and load balancing effects are improved.
[0084] 3) This application improves the adaptability and scalability of distributed storage systems: The hash mapping method cannot dynamically adjust metadata distribution when the cluster expands or hotspots appear, which limits the scalability and adaptability of the system. The optimization algorithm and system proposed in this application will have strong dynamic adaptability. When the cluster size changes, it can automatically reallocate metadata storage locations, allowing new MDSs to quickly integrate into the system and reasonably share the load. In the face of access hotspots, metadata in the hotspot area can be promptly migrated to the MDS with lower load, ensuring that the system can operate efficiently in various complex situations, meet growing business needs, and improve the scalability and adaptability of the system.
[0085] 4) This application also enhances load prediction accuracy: Existing load prediction methods based on popularity counts in subtree partitioning cannot accurately grasp load trends, seriously affecting load balancing effectiveness. This application introduces an advanced load prediction model, combined with time series analysis algorithms and other technologies, to perform a multi-dimensional analysis of metadata load. By comprehensively considering historical load data, current system status, workload characteristics, and other factors, it accurately predicts future load changes, providing a reliable basis for load balancing decisions, enabling the system to proactively respond to load changes and achieve more efficient metadata management.
[0086] Combine Figure 3 , Figure 3 This is a diagram of the overall architecture of a distributed storage system according to an embodiment of the present application. The load balancing method of the present application can be implemented based on an intelligent load balancing controller (BC) in a metadata server cluster in the distributed storage system. Specifically:
[0087] First, to address the shortcomings of hash mapping and subtree partitioning methods, an intelligent load balancing controller (BC) is implemented to achieve multi-dimensional load monitoring and precise assessment. The BC collects multiple load metrics from each MDS cluster node in real time, including central processing unit (CPU) usage, memory utilization, network bandwidth utilization, metadata read and write request queue length, and metadata cache hit rate. It then uses a weighted comprehensive calculation method to accurately calculate the load balancing degree, comprehensively and accurately assessing the load status of each MDS node. The weighted comprehensive calculation method is then used to calculate the load balancing degree and, combined with time series analysis, to construct a load prediction model. This time series analysis method fully considers historical load data, the current system status, and workload characteristics, effectively capturing long-term dependencies in load changes and predicting load trends in advance. This provides strong support for resource allocation and load balancing decisions, effectively capturing load variation patterns and enabling preemptive resource allocation planning. In terms of subtree migration, the migration subtree is selected based on the topology and access mode, and the migration target is determined by comprehensively considering the load trend and resource status of the target node. At the same time, asynchronous migration and data prefetching technologies are used to optimize the migration process, and version control and transaction mechanisms are introduced to ensure data consistency. Finally, this application also has dynamic adjustment capabilities to cope with changes in cluster size and workload. This application can reduce metadata load pressure by 47% and improve metadata access efficiency. It has significant advantages in performance, stability, security, cost and compatibility, and provides an efficient solution for metadata management of distributed storage systems.
[0088] Specifically, if Figure 3 As shown, in the embodiment of the present application, the distributed storage system architecture includes the following key components:
[0089] 1) Provide file system services to the outside world, through which distributed storage clients can perform distributed file storage input / output (IO) operations.
[0090] 2) A unified, self-controlled, and scalable distributed storage consistency management system: This component is the core component of the distributed storage cluster and provides distributed object-based storage services. In this component, data is stored as objects, each with a unique identifier and associated data. This component is responsible for distributing objects across the nodes of the storage cluster and provides data replication, recovery, and load balancing to ensure data reliability and high-performance access.
[0091] Storage pools: A distributed storage cluster consists of multiple storage nodes, each of which can contain multiple hard drives or storage devices. Storage pools include file metadata pools and data pools, dividing storage resources into different pools to meet different storage needs.
[0092] In the storage pool, client data is stored in slices, fixed to 4MB objects by default. Objects are grouped, and the group id is the modulo of Hash (object x) and the number of groups. Finally, it is stored in the underlying device object storage daemon (OSD).
[0093] 3) Controllable, scalable, distributed data balancing placement algorithm: This component evenly distributes data objects across the nodes of the storage cluster to avoid data hotspots and improve system performance.
[0094] 4) Metadata and Monitoring Service Cluster: The metadata cluster manages file system metadata, including file and directory attributes and locations. The monitoring service cluster monitors cluster status and configuration. Its technical principles include maintaining cluster status, configuration, and health information to ensure cluster consistency and availability.
[0095] based on Figure 3 The architecture shown in the figure, this application uses the above-mentioned load balancing method to load balance the metadata service clusters 1..n in the existing distributed storage system architecture. Specifically, this application builds a metadata load balancing optimization system on top of the distributed storage environment. The metadata load balancing optimization system mainly includes a metadata server cluster (MDS cluster), data storage nodes (i.e., object storage daemons OSD) and clients. The MDS cluster is responsible for managing metadata, the OSD stores actual data, and the client is used to interact with the system and initiate data read and write requests. Unlike traditional systems, this metadata load balancing optimization system also introduces an intelligent load balancing controller (BC) as the core component for achieving load balancing optimization.
[0096] like Figure 4 As shown, Figure 4 This is an architectural diagram of an intelligent load balancing controller according to an embodiment of the present application. The intelligent load balancing controller (BC) mainly includes: a data acquisition module, a load evaluation module, a metadata load prediction module, a subtree migration decision and execution module, and an interactive relationship with the MDS cluster.
[0097] The metadata load monitoring and evaluation module (including the data collection module and the load evaluation module) of the intelligent load balancing controller (BC) is used to implement the following solutions:
[0098] Part 1: Multi-dimensional Load Metrics Collection: BC collects multiple load metrics from each node in the MDS cluster in real time. In addition to standard metrics like CPU usage, memory utilization, and network bandwidth utilization, it also focuses on metrics specific to metadata operations, such as metadata read and write request queue length and metadata cache hit rate. Comprehensive analysis of these metrics enables a more comprehensive and accurate assessment of the load status of each MDS node. For an MDS node that frequently performs metadata writes, its metadata read and write request queue length and CPU utilization will increase significantly, and changes in these metrics are promptly captured by BC.
[0099] Specifically, BC collects multiple key load indicators (equivalent to the first load indicator in the above embodiment) in real time, including: CPU usage , used to reflect the CPU usage of the MDS node. High CPU usage may cause metadata processing delays; memory usage , used to reflect the degree of memory usage of the MDS node. Insufficient memory may affect the effect of metadata caching; network bandwidth utilization , used to indicate the usage ratio of the MDS node network bandwidth. Network congestion will affect the transmission of metadata. The length of the metadata read and write request queue A long queue length means that there are a large number of requests waiting to be processed, which may lead to performance degradation; the metadata cache hit rate A high hit rate means that more metadata can be obtained from the cache, reducing disk I / O operations. Indicates the MDS metadata service node (equivalent to each server node in the above embodiment). These indicators reflect the The load status of each MDS metadata service node is the basic data for subsequent calculations and decisions.
[0100] Part 2, load balance calculation: The embodiment of the present application designs a new load balance calculation method, which constructs a load balance function to perform weighted calculation on each load indicator. According to the importance of different indicators to system performance, a corresponding weight is assigned to each indicator. CPU usage has a greater impact on metadata processing speed and can be assigned a higher weight; while memory occupancy has a relatively small impact on system performance within a certain range and is assigned a lower weight. The load balance calculated in this way can more accurately reflect the overall load balance status of the MDS cluster. Specifically, a weighted comprehensive calculation method is used to calculate the load balance. The formula for is shown in the above formula (1).
[0101] The metadata load prediction module in the intelligent load balancing controller (BC) is used to implement the following solutions:
[0102] Part 1: Use time series analysis methods to process the patterns in the historical load data of the MDS metadata load, predict future load trends, and provide strong support for achieving load balancing. It can effectively process time series data and capture the long-term dependencies of load changes. Use historical load data (including the above-mentioned multi-dimensional load indicators, which are equivalent to the first historical load data in the above-mentioned embodiment) as model input, and after training, learn the patterns and patterns of load changes. According to actual needs, predict the load conditions at different time points or time periods in the future. The prediction results can be used to plan resource allocation in advance. When it is predicted that the load of a certain MDS node will be too high, some metadata can be promptly migrated to other nodes with lower loads to achieve load balancing. The system configuration can also be adjusted according to the prediction results, such as increasing or decreasing resource supply, to improve the performance and stability of the system and discover potential load imbalance problems in advance.
[0103] Specifically, this embodiment of the application constructs a load prediction model to process the time series characteristics of MDS metadata load. This model considers multiple parameters related to MDS metadata load (equivalent to the second indicator type in the fourth load indicator in the above embodiment), such as CPU usage, memory utilization, network bandwidth utilization, metadata read and write request queue length, and metadata cache hit rate. It predicts future load conditions by learning from historical data.
[0104] Optionally, the load prediction model training steps include:
[0105] Step 1: Data collection and preprocessing. Collect metadata load-related parameters from each MDS node, including 、 、 、 、 This information can be obtained through Linux commands and distributed storage system monitoring services. To unify the dimensions and make different data comparable, data preprocessing is performed on the collected data. The collected monitoring data (equivalent to the second historical load data in the above embodiment, where the second historical load data may include the first load indicator collected in real time, or may not include it) is normalized as follows:
[0106] Data normalization: Normalize the values of all parameters to the [0, 1] interval to ensure that the model can converge better. The formula is as follows:
[0107] ;(5)
[0108] in, is the original data, and These are the minimum and maximum values of the parameter in the dataset of this indicator type in the metadata server cluster. For example, in the CPU usage dataset, if , , the currently collected CPU usage , substituting into the formula we can get After normalization, the output values are mapped to the interval [0, 1]. 0 represents the minimum value of the metric in the dataset, 1 represents the maximum value, and intermediate values proportionally reflect the relative position of the data between the minimum and maximum values. This helps the model treat different metric data more fairly, preventing certain metrics from dominating model training due to differences in data dimensions.
[0109] Step 2: Load balancing adjustment of time series. Indicators related to MDS load are selected as time series data. This application selects the normalized load balancing degree (LBD) as the observation value of the time series. The LBD data over a period of time (e.g., the past week, recorded every 15 minutes) is calculated and normalized using the weighted comprehensive calculation method to obtain the series. ,in is the number of data points.
[0110] The autoregressive moving average model (ARMA(p,q)) is used to construct the metadata load prediction model of this application. The model expression of the autoregressive moving average model is: , where the model expression represents the load value at time t (which can be an LBD or a single load index value, equivalent to the fourth load balancing degree in the above embodiment), p and q are the autoregressive order and the moving average order respectively, and is the corresponding coefficient, Is a white noise sequence. Using historical load data (including historical LBD and various load index data), the model parameters p, q, and . Use the Akaike Information Criterion (AIC) and Bayesian Information Criterion (BIC) to determine the optimal p and q values and improve the model fitting effect.
[0111] The currently calculated LBD or load index value (equivalent to the target data in the above embodiment) is input into the trained ARMA (p, q) model to predict the load value for one or more future time steps. To obtain more accurate predictions, the prediction results from the time series analysis are fused with the current LBD calculation results (equivalent to the fourth load balance degree in the above embodiment). For example, a weighted fusion approach is used, assigning weights to the time series prediction results and the LBD calculation results, respectively, and combining the two to produce a final load prediction. If the time series prediction indicates a future load increase and the current LBD indicates that some MDSs are underloaded, a comprehensive assessment can be made that the load imbalance problem may worsen in the future. MDS load data and system operating status are continuously monitored. If the actual load deviates significantly from the predicted result, or if the system environment changes (such as cluster expansion or workload type changes), a model update mechanism is triggered. Data is recollected and preprocessed, and the ARMA (p, q) model parameters are re-estimated. Alternatively, the weights in the LBD calculation are adjusted based on the new data characteristics. This optimizes the load prediction model to adapt to system dynamics and ensures prediction accuracy.
[0112] This embodiment of the application starts from p=0,q=0, and gradually tries different combinations of p and q to calculate the corresponding AIC and BIC values. When p=1,q=1, the calculated AIC value is , the BIC value is After calculation and comparison, it is found that when p=2,q=1, the AIC value is the smallest, so the model order is determined to be p=2,q=1. The least squares method is used to estimate the parameters of the ARMA(2,1) model, and the parameters are obtained. and . Perform residual analysis on the constructed ARMA(2,1) model, plotting the residual series and autocorrelation function. Observe that the residual series approximates white noise, indicating that the model fits the historical load data well. Model training: Input this week's LBD data into the ARMA(2,1) model for training, allowing the model to learn the load fluctuation patterns. After training, the model can be used to predict future MDS load balancing, providing a basis for load balancing decisions.
[0113] Part II: Adaptive Model Update Mechanism: To address the dynamic nature of load changes, an adaptive model update mechanism is designed. When system load undergoes significant changes, such as cluster expansion or changes in workload type, the model update process is triggered promptly. By recollecting data and adjusting the model structure or parameters, the load prediction model can adapt to the new system environment. When a new MDS node joins the cluster, the system automatically collects the new node's load data, incorporates it into the model training scope, and adjusts the model to adapt to the new cluster structure.
[0114] The subtree migration decision module in the intelligent load balancing controller (BC) is used to implement the following solutions:
[0115] Part 1. Subtree selection based on topology and access pattern: When selecting a subtree for migration, fully consider the topology of the file system and the access pattern of the client. By analyzing the directory structure of the file system, identify subtrees with higher levels and larger scales, which have a greater impact on the system load. Combined with the client's access log, count the access frequency and access time interval of different subtrees. For those hot subtrees with high access frequency and short access time interval, give priority to migration. At the same time, avoid selecting subtrees that have strong dependencies with other subtrees for migration to reduce the impact on system data consistency and access performance. If a subtree contains multiple files that are being read and written frequently, and these files have data associations with files in other subtrees, when migrating the subtree, it is necessary to carefully evaluate the impact on the entire system.
[0116] Specifically, in the embodiment of subtree selection based on topology structure and access pattern, a topological importance factor (TI) of a subtree is defined to measure the importance of the subtree in the file system topology structure. The calculation of TI is combined with the depth of the subtree (Depth), which represents the depth of the subtree in the file system directory structure. The greater the depth, the lower the hierarchy of the subtree in the entire system, and the greater its potential impact on the system load. The more files and directories (Count) a subtree contains, the higher the load of the subtree may be, and the greater its impact on the overall system load. The calculation formula of the topological importance factor (TI) is shown in the above formula (2).
[0117] At the same time, based on the client access log, the formula for calculating the access heat (AH) of the subtree is shown in the above formula (3). The subtree with a high comprehensive score of TI and AH is selected as the migration candidate.
[0118] Part II, Migration Target Selection Strategy: After determining the migration subtree, select a suitable migration target MDS node. In addition to considering the current load status of the target node, also evaluate its future load trend. Using the results of the above load prediction module, select those MDS nodes with lower future load and sufficient processing power as migration targets. Consider the storage capacity, network bandwidth and other resource conditions of the target node to ensure that it can accommodate the migrated subtree. When an MDS node currently has a low load, but it is predicted that its load will increase in the future due to other tasks and its storage capacity is limited, the node is not selected as a migration target. Define the migration target evaluation function (TEF) to comprehensively consider the current load of the target MDS node. , Future load forecast value , respectively represent the current load and future load forecast value of the jth MDS node, which are used to evaluate the current and future load processing capabilities of the node. Storage capacity and network bandwidth Factors such as represent the storage capacity and network bandwidth of the jth MDS node, respectively, reflecting the resource status of the node. The formula is shown in the above formula (4).
[0119] The subtree migration execution module in the intelligent load balancing controller (BC) is used to execute the following scheme:
[0120] Part 1: Migration Process Optimization: During subtree migration, asynchronous migration and data prefetching technologies are used. Asynchronous migration allows subtree migration operations to be performed without blocking normal system operation, improving the system's concurrent processing capabilities. Before the migration begins, some data is prefetched into the cache of the target MDS node based on the size and access pattern of the subtree, reducing the initial access latency after the migration is complete. For a subtree containing a large number of small files, the metadata and partial data of these small files are prefetched to the target node before migration. After the migration is complete, clients can access these files more quickly.
[0121] Specifically, the embodiment adopts asynchronous migration and data prefetching technology. In asynchronous migration, a multi-threading mechanism is used to assign subtree migration tasks to different threads for execution, thereby reducing the impact on the normal operation of the system. In terms of data prefetching, according to the access pattern and size of the subtree, part of the data is prefetched into the cache of the target MDS node. The calculation of the amount of prefetched data (PrefetchSize) is based on the historical access frequency (AccessFreq) of the subtree, which reflects the frequency of access to the subtree. The higher the access frequency, the greater the value of the prefetched data may be. The subtree size (SubtreeSize) is often measured in terms of data volume or the number of files. The larger the subtree, the more likely the amount of prefetched data will increase accordingly. The formula is:
[0122] ;(6)
[0123] in, It is the prefetch coefficient, which can be adjusted according to the actual system situation, network bandwidth, cache size, etc., to control the amount of prefetched data.
[0124] Part II, data consistency assurance: To ensure data consistency during the migration process, version control and transaction mechanisms are introduced. Before migrating a subtree, a unique version number is assigned to the subtree, and all related metadata operations are recorded. During the migration process, these operations are re-executed on the target MDS node in the form of transactions to ensure data integrity and consistency. If an error occurs during the migration process, the system can roll back based on the version number and transaction records to restore to the state before the migration. Introducing version control and transaction mechanisms. Before migrating, a version number (Version) is assigned to the subtree, and all related metadata operations (Operations) are recorded. During the migration process, the operations are executed on the target node in the form of transactions. After the transaction is successfully executed, the version number is updated; if an error occurs, the system is rolled back based on the version number and operation records.
[0125] Optionally, the intelligent load balancing controller (BC) further includes a system dynamic adjustment module configured to perform the following steps:
[0126] The first part deals with cluster size changes: When the MDS cluster size changes, whether due to a new node or a node failure, the system automatically triggers a dynamic adjustment process. When a new node is added, the BC migrates some heavily loaded subtrees to the new node based on the current cluster load, rebalancing the load. In the event of a node failure, the subtrees on the failed node are promptly migrated to other functioning nodes, the cluster's load balance is recalculated, and the parameters of the load monitoring and prediction models are adjusted.
[0127] Specifically, when the MDS cluster scale changes, such as adding new nodes, calculate the load migration ratio of each existing MDS node , the formula is:
[0128] ;(7)
[0129] in, : represents the current load of the i-th existing MDS node (equivalent to the original server in the above embodiment), which is used to calculate the load ratio of the node that needs to be migrated. is the average of the current loads of all existing MDS nodes. It serves as a comparison benchmark to determine the difference between each node's load and the average load. n in formula (7) represents the number of existing MDS nodes and is used to calculate the total load difference. Based on the migration ratio, some subtrees with higher loads are migrated to the new node.
[0130] Second, adapting to workload changes: As workloads change, such as shifting from primarily file reads to a high volume of file writes, the system adaptively adjusts its load balancing strategy. By re-evaluating the weights of various load metrics, it adjusts subtree migration decisions and migration target selection strategies to accommodate the new workload pattern. If the workload shifts from primarily read to primarily write, the system increases its focus on metrics such as metadata write request queue length and disk I / O performance, adjusting the subtree migration priority and target node selection criteria accordingly.
[0131] Through the above load balancing method, the technical effects of the embodiment of the present application are as follows:
[0132] 1) This application focuses on metadata load balancing in distributed storage systems. Through a series of innovative technologies, it brings significant benefits in terms of performance, stability, security, cost and compatibility, effectively solves many problems of existing technologies, and improves the overall efficiency of distributed storage systems.
[0133] 2) Performance improvement: In scenarios with massive small files and metadata-intensive IO requests, this application effectively reduces the average search latency for metadata extension attributes and permission attributes. Operations such as directory quotas and directory inheritance permission retrieval can reduce metadata load pressure by 47%. Through precise load monitoring and prediction mechanisms, load change trends can be predicted in advance, and metadata distribution can be adjusted in a timely manner, thereby improving efficient metadata access capabilities. When faced with frequent read and write requests for a large number of small files, the system can quickly locate and process metadata, reducing waiting time, improving the efficiency of metadata-intensive storage operations in large-scale massive data processing environments, and enhancing the system's response speed and throughput when processing complex data operations.
[0134] 3) Enhanced Stability: This application decouples metadata organization and management methods from the distributed storage module. This design makes metadata management transparent to business clients. Business clients do not need to be concerned with the specific storage and management details of metadata, reducing the coupling between business and storage systems. When the distributed storage module undergoes upgrades, maintenance, or experiences local failures, it does not impact the normal use of business clients. This ensures system stability, ensures continuous and stable business operations, and reduces the risk of business interruption due to internal system changes.
[0135] 4) Improved Security: Encapsulation of components and method modules hides internal system implementation details, preventing unauthorized external access and malicious attacks from disrupting core system functionality. External access to the system's metadata management logic and key algorithms is inaccessible, reducing the risk of data leakage and tampering. Encapsulation also facilitates more granular permission control within the system, ensuring that only authorized modules or users can access specific functions and data, further enhancing system security and protecting the safety and privacy of user data.
[0136] 5) Cost Reduction: The proposed metadata multipath processing logic and the storage format for metadata and structured attribute information optimize metadata storage and management. This optimization improves the competitiveness of distributed file storage, reduces storage resource waste, and lowers storage device acquisition and maintenance costs. Through more efficient load balancing strategies, excessive server wear and energy waste caused by load imbalances are reduced, server resource utilization is improved, and overall system operating costs are reduced, making distributed storage systems more economically viable and sustainable.
[0137] 6) Good Compatibility: The metadata multipath management method of this embodiment is highly portable and versatile, capable of running on diverse hardware devices. It functions effectively across both traditional and new storage devices, and on x86-based servers and other hardware platforms. This provides greater flexibility in hardware selection, allowing enterprises to select appropriate hardware based on their needs and budget without worrying about compatibility issues with the metadata management method. This reduces the cost and risk of hardware upgrades and replacements, and improves the system's adaptability and scalability.
[0138] In summary, this application improves the metadata load balancing performance of distributed storage systems through innovative load monitoring, prediction and migration strategies. This technical solution based on real-time data processing, intelligent decision-making and dynamic adjustment is expected to be applied to the task scheduling field in edge computing scenarios. By monitoring the resource load status of edge nodes, predicting task requirements, and intelligently scheduling tasks to balance node loads, the overall efficiency and response speed of the edge computing system can be improved.
[0139] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.
[0140] This embodiment also provides a load balancing device for implementing the above-mentioned embodiments and preferred implementations. Details already described will not be repeated. As used below, the term "module" may refer to a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.
[0141] Figure 5 is a structural block diagram of a load balancing device according to an embodiment of the present application, such as Figure 5 As shown, the device includes:
[0142] A first determining module 52 is configured to determine a first load balancing degree of each server node in the metadata server cluster at least one time step after a current time point based on target data corresponding to each server node and a load prediction model, wherein the target data includes one of the following: a first load index at the current time point, and a second load balancing degree related to the first load index;
[0143] The second determining module 54 is configured to determine a subtree migration strategy for the metadata server cluster according to the first load balancing degree and the second load balancing degree, and balance the load of the metadata server cluster according to the subtree migration strategy.
[0144] Through the above-mentioned device, the first load balancing degree of each server node in the metadata server cluster is determined according to the target data and load prediction model corresponding to each server node in the metadata server cluster at least one time step after the current time point, wherein the target data includes one of the following: the first load index at the current time point, the second load balancing degree related to the first load index; the subtree migration strategy for the metadata server cluster is determined by the first load balancing degree and the second load balancing degree, and the load of the metadata server cluster is balanced by the subtree migration strategy. Therefore, the technical problem of how to improve the balancing effect of metadata load balancing in a distributed storage system in the related art can be solved, and the technical effect of improving the load balancing effect of the metadata server cluster can be achieved.
[0145] In an exemplary embodiment, the device also includes: a third determination module, used to obtain the first load indicator of each server node in a preset manner, wherein the first indicator type in the first load indicator includes at least one of the following: central processing unit utilization rate, memory occupancy rate, network bandwidth utilization rate, metadata read and write request queue length, metadata cache hit rate; and determine the second load balancing degree through the first load indicator and the load balancing degree function.
[0146] In an exemplary embodiment, the third determination module is also used to determine the position measurement of the second load indicator in the third load indicator, wherein the second load indicator is the load indicator of each indicator type in the first load indicator, and the third load indicator includes: the second load indicators corresponding to multiple server nodes in the metadata server cluster; the first load indicator and the position measurement are input into the load balancing function to obtain the second load balancing degree.
[0147] In an exemplary embodiment, the device also includes: a training module for obtaining first historical load data of the metadata server cluster, wherein the first historical load data includes: a fourth load indicator and a third load balancing degree corresponding to the fourth load indicator, wherein the second indicator type in the fourth load indicator includes: central processing unit utilization rate, memory occupancy rate, network bandwidth utilization rate, metadata read and write request queue length, metadata cache hit rate; the preset model is trained through the first historical load data to obtain the load prediction model.
[0148] In an exemplary embodiment, the training module is also used to estimate the model order of the preset model through a parameter estimation method, and select the optimal model from the preset models that have different order combinations of the model orders through a model selection criterion; estimate the model coefficients of the optimal model through the parameter estimation method; and train the optimal model with the model coefficients through the first historical load data to obtain the load prediction model.
[0149] In an exemplary embodiment, the training module is further configured to obtain second historical load data of each server node; and perform normalization processing on the second historical load data to obtain the first historical load data.
[0150] In an exemplary embodiment, the first determination module is further used to input the target data into the load prediction model to obtain a fourth load balancing degree output by the load prediction model; determine whether the difference between the second load balancing degree and the fourth load balancing degree is less than a target value; and when the difference is less than the target value, perform weighted fusion on the second load balancing degree and the fourth load balancing degree to obtain the first load balancing degree.
[0151] In an exemplary embodiment, the device also includes: an update module, used to update the first historical load data of the metadata server cluster when a first preset condition is met, and update the load prediction model through the updated first historical load data; and update the load balancing function through the updated first historical load data, wherein the load balancing function is used to determine the second load balancing degree through the first load indicator; wherein the first preset condition includes one of the following: the difference between the second load balancing degree and the fourth load balancing degree is greater than or equal to the target value, the cluster scale of the metadata server cluster changes, and the workload type of the metadata server cluster changes.
[0152] In an exemplary embodiment, the second determination module is also used to determine the migration subtree in the subtree through the topological structure and access popularity of the subtree in the metadata server cluster, wherein the subtree is managed by at least one server node in the metadata server cluster; and determine the migration target of the migration subtree in the metadata server cluster through the first load balancing degree and the second load balancing degree; and determine the subtree migration strategy through the migration subtree and the migration target.
[0153] In an exemplary embodiment, the second determination module is also used to determine the topological index of the subtree to be evaluated in the subtree through the topological structure, wherein the topological index includes: the subtree depth of the subtree to be evaluated, and the number of files and directories included in the subtree to be evaluated; determining the topological importance factor of the subtree to be evaluated through the subtree depth and the number of files and directories; and determining the migration subtree in the subtree to be evaluated through the topological importance factor and the access heat.
[0154] In an exemplary embodiment, the second determination module is also used to obtain evaluation indicators of each server node, wherein the evaluation indicators include: the first load balancing degree, the second load balancing degree; calculate the evaluation score of each server node through the evaluation indicators and the evaluation function; and take the server node with the highest evaluation score in the metadata server cluster as the migration target.
[0155] In an exemplary embodiment, the second determination module is further used to determine the migration timing of the migration subtree through the at least one time step; and determine the migration mechanism allowed to be adopted in the migration process of the migration subtree, wherein the migration mechanism includes at least one of the following: asynchronous migration, data prefetching, version control and transaction mechanism; determine the subtree migration strategy through the migration object, migration timing and the migration mechanism, wherein the migration object includes: the migration subtree and the migration target.
[0156] In an exemplary embodiment, the second determination module is also used to determine the amount of pre-fetched data of the migration subtree according to the historical access frequency and subtree size of the migration subtree when the migration mechanism in the subtree migration strategy includes asynchronous migration and data pre-fetching; and migrate the migration subtree to the migration target according to the pre-fetched data amount and at least one thread corresponding to the asynchronous migration to balance the load of the metadata server cluster.
[0157] In an exemplary embodiment, the second determination module is also used to assign a version number that uniquely identifies the migration subtree to the migration subtree and record metadata operations related to the migration subtree when the migration mechanism in the subtree migration strategy includes version control and transaction mechanism; re-execute the metadata operation on the migration target through the transaction mechanism and the version number to balance the load of the metadata server cluster, wherein, if the transaction mechanism is executed successfully, the version number is updated, and if the transaction mechanism fails to execute, a rollback operation is performed based on the version number and the metadata operation.
[0158] In an exemplary embodiment, the second determination module is also used to determine the load migration ratio of the first server node through the second load balancing degree when the cluster scale of the metadata server cluster changes, wherein the first server node includes one of the following: a second server node and a third server node, wherein the second server node is a faulty server node in the metadata server cluster, and the third server node is an original server node in the metadata server cluster under a second preset condition, and the second preset condition includes: there are new server nodes in the metadata server cluster; and the load in the first server node is migrated according to the load migration ratio.
[0159] In an exemplary embodiment, the second determination module is also used to determine the load to be migrated in the load in the first server node according to the migration ratio; and migrate the load to be migrated to the fourth server node, wherein the fourth server node includes one of the following: other server nodes in the metadata server cluster except the faulty server node, and the newly added server node.
[0160] For the description of the features in the embodiment corresponding to the load balancing device, reference can be made to the relevant description of the embodiment corresponding to the load balancing method, which will not be repeated here.
[0161] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above load balancing method embodiments.
[0162] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned load balancing method embodiments when running.
[0163] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.
[0164] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above load balancing method embodiments are implemented.
[0165] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned load balancing method embodiments are implemented.
[0166] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0167] The above is a detailed introduction to the load balancing provided by this application. Specific examples are used herein to illustrate the principles and implementation methods of this application. The description of the above embodiments is only intended to help understand the method and core ideas of this application. It should be noted that, for those skilled in the art, without departing from the principles of this application, several improvements and modifications can be made to this application, and these improvements and modifications also fall within the scope of protection of the claims of this application.
Claims
1. A load balancing method, characterized in that: include: Determining a first load balancing degree of each server node at least one time step after a current time point based on target data corresponding to each server node in the metadata server cluster and a load prediction model, wherein the target data includes one of the following: a first load index at the current time point, and a second load balancing degree related to the first load index; A subtree migration strategy for the metadata server cluster is determined by the first load balancing degree and the second load balancing degree, and the load of the metadata server cluster is balanced by the subtree migration strategy, wherein: Determining a subtree migration strategy for the metadata server cluster based on the first load balancing degree and the second load balancing degree includes: Determining a migration subtree in the subtree according to the topological structure and access popularity of the subtree in the metadata server cluster includes: Determining a topological index of a subtree to be evaluated in the subtree by using the topological structure, wherein the topological index includes: a subtree depth of the subtree to be evaluated, and a number of files and directories included in the subtree to be evaluated; pass Determine the topological importance factor of the subtree to be evaluated; wherein, is the topological importance factor, is the subtree depth, is the number of files and directories; and is the weight coefficient; Determining a migration subtree in the subtree to be evaluated by a weighted fusion score of the topological importance factor and the access popularity, wherein the subtree is managed by at least one server node in the metadata server cluster; and Determining a migration target of the migration subtree in the metadata server cluster according to the first load balancing degree and the second load balancing degree includes: pass Calculate the evaluation score of each server node; wherein, represents the evaluation score, Indicates the second load balancing degree, Indicates the first load balancing degree, Indicates storage capacity, Indicates the network bandwidth, Indicates the first server nodes; is the weight, and ,in, 、 、 、 are the average values of the evaluation indicators of all server nodes in the metadata server cluster; Taking the server node with the highest evaluation score in the metadata server cluster as the migration target; The subtree migration strategy is determined according to the migration subtree and the migration target.
2. The load balancing method according to claim 1, wherein: Before determining a first load balancing degree of each server node at least one time step after a current time point based on target data corresponding to each server node in the metadata server cluster and a load prediction model, the method further includes: Obtaining the first load indicator of each server node in a preset manner, wherein the first indicator type in the first load indicator includes at least one of the following: central processing unit usage rate, memory occupancy rate, network bandwidth utilization rate, metadata read and write request queue length, and metadata cache hit rate; The second load balancing degree is determined by using the first load indicator and a load balancing function.
3. The load balancing method according to claim 2, wherein: Determining the second load balancing degree by using the first load indicator and a load balancing function includes: Determining a position metric of a second load indicator in a third load indicator, wherein the second load indicator is a load indicator of each indicator type in the first load indicator, and the third load indicator includes: second load indicators corresponding to a plurality of server nodes in the metadata server cluster; The first load index and the location metric are input into the load balancing function to obtain the second load balancing degree.
4. The load balancing method according to claim 1, wherein: Before determining a first load balancing degree of each server node at least one time step after a current time point based on target data corresponding to each server node in the metadata server cluster and a load prediction model, the method further includes: Obtaining first historical load data of the metadata server cluster, wherein the first historical load data includes: a fourth load indicator and a third load balancing degree corresponding to the fourth load indicator, wherein the second indicator type in the fourth load indicator includes: central processing unit usage rate, memory occupancy rate, network bandwidth utilization rate, metadata read and write request queue length, and metadata cache hit rate; The load prediction model is obtained by training a preset model using the first historical load data.
5. The load balancing method according to claim 4, wherein: The load prediction model is obtained by training a preset model using the first historical load data, including: estimating the model order of the preset model by a parameter estimation method, and selecting the optimal model from the preset models having different order combinations among the model orders by a model selection criterion; estimating the model coefficients of the optimal model by the parameter estimation method; The load prediction model is obtained by training an optimal model having the model coefficients using the first historical load data.
6. The load balancing method according to claim 4, wherein: Acquiring first historical load data of the metadata server cluster includes: Acquire second historical load data of each server node; Normalizing the second historical load data to obtain the first historical load data.
7. The load balancing method according to claim 1, wherein: Determining a first load balancing degree of each server node at least one time step after a current time point based on target data corresponding to each server node in the metadata server cluster and a load prediction model includes: Inputting the target data into the load prediction model to obtain a fourth load balancing degree output by the load prediction model; determining whether a difference between the second load balancing degree and the fourth load balancing degree is less than a target value; When the difference is smaller than the target value, weighted fusion is performed on the second load balancing degree and the fourth load balancing degree to obtain the first load balancing degree.
8. The load balancing method according to claim 7, wherein: After determining whether a difference between the second load balancing degree and the fourth load balancing degree is less than a target value, the method further includes: When a first preset condition is met, updating the first historical load data of the metadata server cluster, and updating the load prediction model according to the updated first historical load data; and Updating a load balancing function using the updated first historical load data, wherein the load balancing function is used to determine the second load balancing degree using the first load indicator; Among them, the first preset condition includes one of the following: the difference between the second load balancing degree and the fourth load balancing degree is greater than or equal to the target value, the cluster scale of the metadata server cluster changes, and the workload type of the metadata server cluster changes.
9. The load balancing method according to claim 1, wherein: Determining the subtree migration strategy according to the migration subtree and the migration target includes: Determining a migration timing of the migration subtree according to the at least one time step; and Determining a migration mechanism allowed to be adopted during the migration process of the migration subtree, wherein the migration mechanism includes at least one of the following: asynchronous migration, data prefetching, version control, and transaction mechanism; The subtree migration strategy is determined by the migration object, migration timing and the migration mechanism, wherein the migration object includes: the migration subtree and the migration target.
10. The load balancing method according to claim 1, wherein: Balancing the load of the metadata server cluster by using the subtree migration strategy includes: In the case where the migration mechanism in the subtree migration strategy includes asynchronous migration and data prefetching, determining the prefetched data amount of the migration subtree according to the historical access frequency and subtree size of the migration subtree; The migration subtree is migrated to the migration target through the pre-fetched data amount and at least one thread corresponding to the asynchronous migration, so as to balance the load of the metadata server cluster.
11. The load balancing method according to claim 1, wherein: Balancing the load of the metadata server cluster by using the subtree migration strategy includes: In a case where the migration mechanism in the subtree migration strategy includes version control and transaction mechanism, assigning a version number that uniquely identifies the migration subtree to the migration subtree, and recording metadata operations related to the migration subtree; The metadata operation is re-executed on the migration target through the transaction mechanism and the version number to balance the load of the metadata server cluster. If the transaction mechanism is successfully executed, the version number is updated. If the transaction mechanism fails to execute, a rollback operation is performed based on the version number and the metadata operation.
12. The load balancing method according to claim 1, wherein: The method further comprises: In the case where the cluster size of the metadata server cluster changes, determining a load migration ratio of a first server node by using the second load balancing degree, wherein the first server node includes one of the following: a second server node and a third server node, wherein the second server node is a failed server node in the metadata server cluster, and the third server node is an original server node in the metadata server cluster under a second preset condition, wherein the second preset condition includes: a newly added server node in the metadata server cluster; The load in the first server node is migrated according to the load migration ratio.
13. The load balancing method according to claim 12, wherein: Migrating the load in the first server node according to the load migration ratio includes: determining a load to be migrated in the load in the first server node according to the migration ratio; Migrate the load to be migrated to a fourth server node, wherein the fourth server node includes one of the following: other server nodes in the metadata server cluster except the failed server node, and the newly added server node.
14. A load balancing device, characterized in that: include: a first determining module, configured to determine a first load balancing degree of each server node in the metadata server cluster at least one time step after a current time point based on target data corresponding to each server node and a load prediction model, wherein the target data includes one of the following: a first load index at the current time point, and a second load balancing degree related to the first load index; The second determining module is configured to determine a subtree migration strategy for the metadata server cluster based on the first load balancing degree and the second load balancing degree, and balance the load of the metadata server cluster based on the subtree migration strategy, wherein: The second determining module is further configured to determine a migration subtree in the subtree according to the topological structure and access popularity of the subtree in the metadata server cluster, wherein the subtree is managed by at least one server node in the metadata server cluster; and determine a migration target of the migration subtree in the metadata server cluster according to the first load balancing degree and the second load balancing degree; The second determining module is further configured to determine the topological index of the subtree to be evaluated in the subtree through the topological structure, wherein the topological index includes: the subtree depth of the subtree to be evaluated, the number of files and directories included in the subtree to be evaluated; Determine the topological importance factor of the subtree to be evaluated; wherein, is the topological importance factor, is the subtree depth, is the number of files and directories; and is a weight coefficient; determining a migration subtree in the subtree to be evaluated by a weighted fusion score of the topological importance factor and the access heat; and pass Calculate the evaluation score of each server node; wherein, represents the evaluation score, Indicates the second load balancing degree, Indicates the first load balancing degree, Indicates storage capacity, Indicates the network bandwidth, Indicates the first server nodes; is the weight, and ,in, 、 、 、 are respectively the average values of evaluation indicators of all server nodes in the metadata server cluster; the server node with the highest evaluation score in the metadata server cluster is used as the migration target; and the subtree migration strategy is determined by the migration subtree and the migration target.
15. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the load balancing method according to any one of claims 1 to 13 when executing the computer program.
16. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the load balancing method according to any one of claims 1 to 13.
17. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the load balancing method according to any one of claims 1 to 13 are implemented.
Citation Information
Patent Citations
Method and device for establishing models corresponding to malicious account numbers and method and device for identifying malicious account numbers
CN107305611A
Target migration method and device
CN114448897A
Metadata load balancing method, device and equipment and readable storage medium
CN115952005A