Load balancing method and electronic device

Abstract

The application discloses a load balancing method and an electronic device, relates to the technical field of data storage, and is applied to a multi-controller architecture storage system. The multi-controller architecture storage system comprises a plurality of controller nodes, and each controller node corresponds to a controller domain for managing a deduplication metadata shard. By taking the deduplication metadata shard as a minimum scheduling unit, the traditional coarse-grained migration limit taking a volume or an entire table as a unit is broken, and the scheduling precision and flexibility are significantly improved. In the running process, the load is dynamically monitored, when any controller node is overloaded, the high-load shard of the controller node is automatically migrated to other lightly-loaded controller nodes, the performance bottleneck of the single controller node is avoided, and the overall throughput capacity of the multi-controller architecture storage system is ensured. Through static allocation, the load uniform distribution in the starting stage is realized, and in combination with the dynamic migration mechanism, the load change in the running time is responded, and the initialization efficiency and long-term stability of the multi-controller architecture storage system are considered.

Description

Technical Field

[0001] This application relates to the field of data storage technology, and in particular to a load balancing method and electronic device. Background Technology

[0002] In the enterprise storage field, multi-controller architecture storage systems have become the mainstream choice for massive data storage due to their high concurrency processing capabilities and redundancy fault tolerance. These systems achieve distributed data management through multiple controller nodes and corresponding controller domains, while the implementation of core functions such as online deduplication relies on the reasonable allocation of hash values ​​to ensure global deduplication effectiveness. However, the deduplication data is massive and access is highly concentrated. If traditional static partitioning or round-robin allocation strategies are used, some controller nodes may experience reduced deduplication efficiency and increased response latency due to excessive load, seriously affecting the performance stability and data reliability of multi-controller architecture storage systems. Summary of the Invention

[0003] This application provides a load balancing method and electronic device to at least solve the problems of uneven node load and reduced deduplication efficiency caused by the use of traditional static partitioning or round-robin allocation strategies in multi-controller architecture storage systems in the related art.

[0004] This application provides a load balancing method applied to a multi-controller architecture storage system. The multi-controller architecture storage system includes multiple controller nodes, each corresponding to a controller domain for managing deduplication metadata shards. The method includes:

[0005] Obtain deduplication metadata from a multi-controller architecture storage system. Deduplication metadata includes hash pointers, physical data list entries, and the mapping relationship between logical block addresses and physical block addresses.

[0006] The deduplication metadata is divided into multiple deduplication metadata fragments of equal size according to a preset granularity. Each deduplication metadata fragment corresponds to a unique fragment identifier and constitutes the smallest metadata unit that can be independently migrated and managed.

[0007] Multiple deduplication metadata shards are statically distributed to each controller domain, so that each controller domain initially manages a balanced portion of the deduplication metadata shards.

[0008] In the global shared memory of the multi-controller architecture storage system, a metadata shard node mapping table is established and maintained to record the current controller node to which each deduplicated metadata shard belongs.

[0009] Monitor the load on each controller node;

[0010] When the load of any controller node exceeds the preset threshold, the deduplication metadata shards under its management are selected to be migrated, and the shards to be migrated are migrated to the target controller node among the remaining controller nodes whose load does not exceed the preset threshold and whose metadata storage is the lowest.

[0011] After the migration is complete, update the metadata shard node mapping table and synchronize the updated mapping relationship to each controller node.

[0012] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the above-described load balancing method when executing the computer program.

[0013] The load balancing method and electronic equipment provided in this application, by using deduplicated metadata shards as the smallest scheduling unit, overcomes the limitations of traditional coarse-grained migration based on volumes or entire tables, significantly improving scheduling accuracy and flexibility. During operation, the load is dynamically monitored; when any controller node is overloaded, its high-load shards are automatically migrated to other lightly loaded controller nodes, avoiding performance bottlenecks of single controller nodes and ensuring the overall throughput of the multi-controller architecture storage system. Static allocation achieves uniform load distribution during startup, combined with a dynamic migration mechanism to handle runtime load changes, balancing initialization efficiency and long-term stability of the multi-controller architecture storage system. A metadata shard node mapping table in global shared memory is used to uniformly maintain shard ownership information; after migration, it is synchronously updated and broadcast, ensuring a consistent view across controller nodes and preventing input / output routing errors. By migrating shards to be migrated to target controller nodes with loads below the threshold and the lowest metadata storage volume, availability is ensured while optimizing storage resource distribution, fully leveraging the advantages of multi-controller parallel processing. Attached Figure Description

[0014] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 This is a schematic diagram of the system architecture of a load balancing method provided in an embodiment of this application.

[0016] Figure 2 This is a flowchart illustrating a load balancing method provided in an embodiment of this application.

[0017] Figure 3 This is a schematic diagram of a load balancing device provided in an embodiment of this application.

[0018] Figure 4 This is a schematic diagram of the structure of an electronic device provided in this application.

[0019] The above figures include the following reference numerals:

[0020] 310 - Acquisition module; 320 - Slicing module; 330 - Mapping module; 340 - Monitoring module; 350 - Migration module; 410 - Processor; 420 - Memory; 430 - Communication component. Detailed Implementation

[0021] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, various other embodiments obtained by those of ordinary skill in the art without creative effort are all within the protection scope of this application.

[0022] It should be noted that in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence. Those skilled in the art will understand that the words "first," "second," etc., do not limit the quantity or order of execution, and that "first," "second," etc., do not necessarily imply difference. It should be noted that in the embodiments of this application, the words "exemplary" or "for example," etc., are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as preferred or advantageous over other embodiments or designs. Specifically, the use of "exemplary" or "for example," etc., is intended to present the relevant concepts in a specific manner. In the embodiments of this application, "at least one" means one or more, and "more than one" means two or more.

[0023] It should be noted that the phrase "at...time" in the embodiments of this application can refer to the instant at which a certain situation occurs, or to a period of time after the occurrence of a certain situation; the embodiments of this application do not specifically limit this. Furthermore, the load balancing method provided in the embodiments of this application is merely an example; a load balancing method may include more or fewer elements.

[0024] In the enterprise storage field, with the explosive growth of massive amounts of data, multi-controller architecture storage systems have become the mainstream choice for massive data storage and management in industries such as finance, energy, and the internet due to their high-concurrency data processing capabilities and multi-node redundancy and fault tolerance. These storage systems typically contain multiple independent controller nodes, each corresponding to a dedicated controller domain, achieving distributed storage and collaborative management of data through a distributed architecture. Online deduplication, as a core data reduction technology, works by calculating data hash values ​​and determining the domain to which those hash values ​​belong, thereby identifying and deduplicating globally, reducing storage capacity usage, and controlling enterprise storage costs. Therefore, the proper allocation of hash value ownership directly determines the global deduplication effect and overall system efficiency of the online deduplication function.

[0025] However, in existing multi-controller architecture storage systems, hash value allocation often adopts a static mapping scheme (e.g., allocation based on the modulo operation of the number of controller domains using hash values). This scheme does not consider the real-time load differences of each controller node, specifically key load indicators such as processor utilization, metadata storage volume, and input / output (I / O) processing queue length. This leads to severe overload on some controller nodes during actual operation, as they bear a large number of tasks related to metadata management and deduplication logic execution for hash values. This results in decreased deduplication efficiency and data read / write response latency. Furthermore, under the static mapping scheme, the mapping relationship between hash values ​​and their domains lacks a flexible adjustment mechanism. When data is read and written across controller nodes, the mapping relationship synchronization relies on a fixed communication link and lacks a unified coordination strategy. This easily leads to untimely or inconsistent mapping relationship synchronization, causing data read errors, checksum block synchronization failures, and other data consistency issues. This severely restricts the performance stability, data reliability, and practical value of core functions such as online deduplication in multi-controller architecture storage systems.

[0026] Furthermore, for multi-controller architecture storage systems, existing technologies mostly adopt a direct expansion approach using a dual-controller scheme, simply distributing data hash values ​​evenly across each controller domain. Deduplication metadata is only synchronized within the controller domain, without designing a dedicated deduplication metadata load balancing mechanism tailored to the distributed characteristics of multi-controller architectures. Some solutions attempt to allocate deduplication metadata through static mapping, but fail to consider the actual load differences among controller nodes, lack fine-grained sharding management of deduplication metadata, and are devoid of a dynamic sharding migration mechanism based on load contribution. Simultaneously, existing solutions lack a coordinated mechanism adapted to load balancing in aspects such as deduplication metadata sharding, hash pointer migration, load contribution calculation, cross-node cache management, and verification synchronization, leading to numerous performance bottlenecks and reliability issues in actual operation.

[0027] Therefore, there is an urgent need for a load balancing technology solution that is compatible with multi-controller architecture storage systems to solve the technical defects caused by existing static hash value mapping, such as node load imbalance, low deduplication efficiency, high response latency and poor data consistency, so as to meet the core requirements of enterprise-level storage systems for high performance and high reliability.

[0028] Based on this, this application proposes a load balancing method and electronic device, which can be used in the field of data storage technology to solve the above-mentioned technical problems. Addressing the technical shortcomings of online deduplication load balancing in multi-controller architecture storage systems, such as the difficulty in implementing load balancing and the coarse management of deduplication metadata, this application considers the structural characteristics of multi-controller architecture storage systems, which contain multiple controller nodes, each corresponding to a dedicated controller domain. By fine-grained sharding and load-linked decision-making for deduplication metadata, and using deduplication metadata shards as the smallest migration unit, load-based dynamic migration is achieved in multi-controller architecture storage systems, solving the problem of uneven load on controller nodes caused by metadata hotspots in traditional solutions. Specifically, the system-wide deduplication metadata (including hash pointers, physical data list entries, and the mapping relationship between logical block addresses and physical block addresses) is divided into multiple equally sized deduplication metadata shards according to a preset granularity. Each deduplication metadata shard has a unique shard identifier and serves as the smallest metadata unit that can be independently migrated and managed, thereby achieving modular organization of metadata resources. During system initialization, multiple deduplication metadata shards are statically allocated to the controller domains corresponding to each controller node, ensuring a balanced number of shards initially managed by each controller and avoiding hotspots during startup. A metadata shard node mapping table is established and maintained in the global shared memory of the multi-controller architecture storage system. This table records in real time the controller node to which each deduplicated metadata shard currently belongs, providing a unified view for subsequent dynamic scheduling. The operating load of each controller node is continuously monitored. When the load of any node exceeds a preset threshold, a load balancing process is automatically triggered. Deduplicated metadata shards managed by overloaded nodes are selected for migration and moved to the target controller node with the lowest current metadata storage volume among the remaining controller nodes, balancing availability (adequate load) and load balancing (minimum storage). After the migration of the deduplicated metadata shards is completed, the metadata shard node mapping table is atomically updated, and the latest mapping relationship is synchronized to each controller node. This ensures that all controller nodes have a consistent understanding of shard ownership, guaranteeing correct routing of subsequent input / output requests. Through a dynamic load balancing mechanism using deduplicated metadata shards as the scheduling unit, controller hotspots are effectively eliminated while ensuring business continuity, improving the overall throughput and resource utilization of the multi-controller storage system. This effectively solves the problems of node load imbalance, reduced deduplication efficiency, and increased response latency caused by existing static hash value mapping. At the same time, it avoids the problem of poor data consistency caused by untimely synchronization of cross-node mapping relationships. Ultimately, it achieves the technical effects of load balancing of each controller node, improved system concurrency processing capability, and enhanced data storage reliability, ensuring the stable and efficient operation of core functions such as online deduplication.

[0029] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0030] Figure 1 This is a schematic diagram of the system architecture for a load balancing method provided in an embodiment of this application. It should be noted that... Figure 1 The examples shown are merely examples of system architectures that can be applied to the embodiments of this application, in order to help those skilled in the art understand the technical content of this application, but do not mean that the embodiments of this application cannot be used in other devices, systems, environments or scenarios.

[0031] like Figure 1 As shown, the system architecture of this method includes four nodes: a first controller node, a second controller node, a third controller node, and a fourth controller node. It also includes a global shared memory that communicates with each of these four nodes. The global shared memory stores a metadata shard node mapping table, records the current owner of each deduplicated metadata shard, and synchronizes the mapping relationship to each controller node to achieve global consistency.

[0032] Furthermore, each controller node independently maintains a controller domain to manage deduplication metadata shards.

[0033] It should be noted that, Figure 1 The multi-controller architecture storage system shown is a four-controller architecture storage system. In practice, this multi-controller architecture storage system can also adopt an extended architecture with three, five, or more controller nodes. Each controller node still corresponds to an independent controller domain and maintains communication connection with the global shared memory to adapt to storage scenarios of different scales and performance requirements, without affecting the normal implementation of the load balancing method of this application.

[0034] Figure 2 This is a flowchart illustrating a load balancing method provided in an embodiment of this application, as shown below. Figure 2 As shown, embodiments of this application provide a load balancing method applicable to multi-controller architecture storage systems. The multi-controller architecture storage system includes multiple controller nodes (e.g., four controller nodes, forming a four-controller architecture), each controller node operating independently and managing a corresponding controller domain. Each controller domain maintains deduplication metadata shards belonging to that domain, thereby supporting global data deduplication. Each controller node also collaboratively manages global deduplication metadata. The method is described in detail below:

[0035] S201. Obtain deduplication metadata from the multi-controller architecture storage system.

[0036] In this embodiment, deduplication metadata refers to duplicate metadata that needs to be deleted in a multi-controller architecture storage system. Deduplication metadata includes hash pointers, physical data list entries, and the mapping relationship between logical block addresses and physical block addresses. A load balancing method can be executed by controller nodes in a multi-controller architecture storage system. Specifically, it can be coordinated and executed by a single master node, or it can be completed collaboratively by various controller nodes through distributed consensus or event-driven methods.

[0037] Specifically, deduplication metadata mainly includes three types of information: hash pointer (HP), physical data list entry (PL), and the mapping relationship between logical block address (LBA) and physical block address (LBA-PBA Mapping).

[0038] A hash pointer is a unique identifier generated by hashing the original data block. It is used to determine whether data is duplicated and to identify the deduplicated data block. Specifically, the hash algorithm can be a Secure Hash Algorithm 256-bit (SHA-256) or a Message-Digest Algorithm 5 (MD5), etc., without specific restrictions.

[0039] The physical data list entries are used to record the physical storage location, reference count, and verification information corresponding to each hash pointer. Specifically, they record metadata such as the location, reference count, timestamp, and checksum of each unique data block on the physical storage device.

[0040] The mapping relationship between logical block addresses and physical block addresses is used to translate the logical addresses in the input / output requests initiated by the host into the actual storage locations, so as to support fast data location.

[0041] S202. Divide the deduplication metadata into multiple equally sized deduplication metadata fragments according to a preset granularity.

[0042] In this embodiment of the application, each deduplication metadata shard corresponds to a unique shard identifier and constitutes the smallest metadata unit that can be independently migrated and managed.

[0043] Specifically, the aforementioned deduplicated metadata can be divided into multiple equally sized deduplicated metadata shards according to a preset granularity (e.g., each deduplicated metadata shard contains a fixed number of hash pointer entries, or a fixed size such as 32 megabytes or 64 megabytes). Each deduplicated metadata shard is assigned a globally unique shard ID, such as a 64-bit integer. These deduplicated metadata shards are designed as the smallest metadata units that can be independently migrated and managed. That is, the metadata within a deduplicated metadata shard has access locality, and migration does not require dependence on other deduplicated metadata shards, thereby ensuring the atomicity and efficiency of the migration operation.

[0044] S203. Statically distribute multiple deduplication metadata shards to each controller domain, so that each controller domain initially manages a balanced portion of the deduplication metadata shards.

[0045] Specifically, during system initialization, multiple deduplication metadata shards can be statically allocated to each controller domain. For example, in a storage system with N controller nodes, if there are M shards in total, each node will initially be allocated approximately M / N shards. This ensures that each controller domain is in an initial load-balanced state upon startup, preventing any node from becoming a performance bottleneck prematurely due to the concentration of hot data. Here, N is an integer greater than 2, and M is an integer multiple of N.

[0046] S204. Establish and maintain a metadata shard node mapping table in the global shared memory of the multi-controller architecture storage system, and record the current owner controller node of each deduplicated metadata shard.

[0047] Specifically, to further support dynamic scheduling, a metadata shard node mapping table can be established and continuously maintained in Global SharedMemory. This metadata shard node mapping table uses shard identifiers as indexes to record the controller node to which each deduplicated metadata shard currently belongs. Since Global SharedMemory is visible to all controller nodes, any controller node can query the location of any deduplicated metadata shard in real time, providing a basis for subsequent input / output routing and migration decisions.

[0048] S205. Monitor the load of each controller node.

[0049] Specifically, the operating load of each controller node can be continuously monitored. Load metrics may include processor (Central Processing Unit, CPU) utilization, memory usage, metadata storage usage, and input / output (I / O) request queue length, etc.

[0050] S206. When the load of any controller node exceeds the preset threshold, select the fragments to be migrated from the deduplication metadata fragments managed by it, and migrate the fragments to be migrated to the target controller node among the remaining controller nodes whose load does not exceed the preset threshold and whose metadata storage volume is the lowest.

[0051] Specifically, when the load of any controller node exceeds a preset threshold (e.g., processor utilization is consistently higher than 80%, or metadata storage space usage exceeds 90%), it can be determined that the controller node is in an overloaded state and the load balancing process needs to be initiated.

[0052] At this point, one or more deduplicated metadata shards managed by the overloaded controller node can be selected for migration. The selection strategy can be based on the contribution of the deduplicated metadata shard to the current load (such as high access frequency, large storage usage, etc.), or it can adopt a round-robin or random method.

[0053] Crucially, to ensure migration effectiveness and system stability, the shards to be migrated are not randomly moved to any controller node, but are migrated to a target controller node among the remaining controller nodes that meets the following two conditions: First, the current load of the controller node does not exceed a preset threshold, and it has the ability to receive new shards to be migrated; second, among the candidate nodes whose current load does not exceed the preset threshold, its metadata storage volume is the lowest, so as to further optimize the distribution of global storage resources while ensuring availability.

[0054] S207. After the migration is complete, update the metadata shard node mapping table and synchronize the updated mapping relationship to each controller node.

[0055] Specifically, after the shard migration is complete, the metadata shard node mapping table in the global shared memory can be updated to change the ownership information of the shard to be migrated from the source controller node to the target controller node. Furthermore, to prevent inconsistencies caused by concurrent access, this update operation is preferably implemented through an atomic write operation.

[0056] Finally, the updated mapping can be synchronized to each controller node, for example, by broadcasting a message to notify each controller node to refresh its local cached mapping copy. From then on, all newly initiated input / output requests involving the shard to be migrated will be correctly routed to the target controller node, achieving seamless and imperceptible load rebalancing.

[0057] Through the above methods, the embodiments of this application effectively solve the controller hotspot problem caused by uneven metadata access in multi-controller deduplication storage systems, and significantly improve the overall throughput, resource utilization and service stability of the system.

[0058] This application provides a load balancing method that uses deduplicated metadata shards as the smallest scheduling unit, breaking through the limitations of traditional coarse-grained migration based on volumes or entire tables, significantly improving scheduling accuracy and flexibility. During operation, the load is dynamically monitored; when any controller node is overloaded, its high-load shards are automatically migrated to other lightly loaded controller nodes, avoiding performance bottlenecks of single controller nodes and ensuring the overall throughput of the multi-controller architecture storage system. Static allocation achieves uniform load distribution during startup, combined with a dynamic migration mechanism to handle runtime load changes, balancing initialization efficiency and long-term stability of the multi-controller architecture storage system. A metadata shard node mapping table in global shared memory is used to uniformly maintain shard ownership information; after migration, the information is synchronously updated and broadcast, ensuring a consistent view across controller nodes and preventing input / output routing errors. By migrating shards to be migrated to target controller nodes with loads below the threshold and the lowest metadata storage volume, availability is ensured while optimizing storage resource distribution, fully leveraging the advantages of multi-controller parallel processing.

[0059] In one possible implementation, the load includes processor utilization, metadata storage, and input / output processing queue length, and the preset thresholds include processor utilization threshold, metadata storage threshold, and input / output processing queue length threshold.

[0060] When the load on any controller node exceeds a preset threshold, shards to be migrated are selected from the deduplication metadata shards it manages. This includes determining that the controller node's load exceeds the preset threshold when the processor utilization rate, metadata storage amount, or input / output processing queue length exceeds the preset threshold. After determining that the load exceeds the preset threshold, the contribution of each deduplication metadata shard managed by the controller node to the load is calculated. The contribution is calculated based on the processor time percentage, metadata storage usage, and number of input / output request processing for each deduplication metadata shard. Based on the contribution, a preset number of deduplication metadata shards with the highest contribution are selected as shards to be migrated.

[0061] Specifically, to achieve more accurate load balancing decisions, the definition of load can be extended beyond a single metric, taking into account the multi-dimensional resource utilization of controller nodes. Specifically, load can include three key dimensions: processor utilization, metadata storage, and input / output processing queue length.

[0062] Among them, processor utilization reflects the busyness of the controller node's CPU resources, and is usually expressed as a percentage (e.g., 85%).

[0063] Metadata storage refers to the amount of storage space occupied by the deduplicated metadata shards currently managed by the controller node in local memory or cache, for example, in megabytes (MB).

[0064] The input / output processing queue length represents the number of input / output requests currently waiting to be processed on the controller node, directly reflecting the degree of congestion in the input / output path.

[0065] Accordingly, preset thresholds can be configured for each of the above load metrics, such as processor utilization threshold (e.g., 70%), metadata storage threshold (e.g., 256 megabytes), and input / output processing queue length threshold (e.g., 500 requests).

[0066] When any controller node continuously meets any of the following three conditions—processor utilization exceeding the processor utilization threshold, metadata storage exceeding the metadata storage threshold, or I / O processing queue length exceeding the I / O processing queue length threshold—it is determined that the controller node's load exceeds a preset threshold, and a load balancing process must be triggered. This ensures that the multi-controller architecture storage system can respond promptly to any resource bottleneck, avoiding the omission of potential overload issues due to monitoring only a single metric.

[0067] Upon determining that any controller node is overloaded, the multi-controller architecture storage system does not randomly or in round-robin select shards to migrate. Instead, it further quantifies the actual contribution of each deduplicated metadata shard to the current load of the controller node. Specifically, for each deduplicated metadata shard managed by the controller node, the following three metrics can be collected and calculated: the percentage of processor time consumed by the deduplicated metadata shard in the most recent statistical period (e.g., 5% of the total CPU time of the controller node); the size of the metadata storage space occupied locally by the deduplicated metadata shard; and the number of input / output request processing associated with the deduplicated metadata shard (e.g., the number of read / write requests processed per second).

[0068] Based on the above three indicators, the pressure weight of each deduplicated metadata shard on the overall load can be analyzed. Subsequently, the comprehensive load contribution of each deduplicated metadata shard is calculated according to these indicators. Finally, the deduplicated metadata shards are sorted from high to low according to their contribution, and a predetermined number of shards with the highest ranking (e.g., the top 2 or the top 5%) are selected as the shards to be migrated.

[0069] By using the above methods, deduplicated metadata shards with high load contribution can be migrated first, thereby achieving maximum load reduction with minimal migration cost and significantly improving the efficiency and benefit ratio of load balancing.

[0070] In one possible implementation, the contribution of each deduplicated metadata shard managed by the controller node to the load is calculated by: assigning preset weights to the processor time percentage, metadata storage usage, and number of input / output request processing; normalizing the processor time percentage, metadata storage usage, and number of input / output request processing corresponding to each deduplicated metadata shard to obtain normalized index values; and calculating the load contribution of each deduplicated metadata shard by weighted summation based on the normalized index values ​​and the corresponding preset weights.

[0071] Specifically, to accurately analyze the actual impact of each deduplicated metadata shard on the controller node load, a multi-dimensional weighted contribution calculation model can be introduced. This model can comprehensively consider the consumption of deduplicated metadata shards in three key resource dimensions: computation, storage, and input / output.

[0072] First, preset weights can be configured for the three core load metrics to reflect the differences in the importance of each resource under different business scenarios. For example: processor time percentage weight (denoted as w). cpu ), used to measure the sensitivity of deduplication metadata shards to CPU resource consumption; metadata storage occupancy weight (denoted as w) mem ), used to reflect the pressure of deduplication metadata shards on memory or cache space; input / output request processing quantity weight (denoted as w) io ), used to characterize the impact of deduplication metadata fragmentation on input / output bandwidth and queue depth.

[0073] These preset weights can be configured in advance according to the actual workload characteristics (e.g., database workloads focus more on input and output, so weights can be increased). io Computationally intensive workloads can improve w cpu It can also be automatically optimized based on historical performance data.

[0074] Secondly, because the dimensions and numerical ranges of the three original metrics differ significantly (for example, processor time percentage is a decimal between 0 and 1, while the number of input / output requests may be in the thousands), direct weighting would lead to one metric dominating the result. Therefore, the three metrics for each deduplication metadata shard can be normalized separately, mapping them to a unified numerical range (usually [0, 1]). Specific normalization methods can include min-max normalization, Z-score standardization, or sliding window-based dynamic normalization; no specific restrictions are imposed here.

[0075] By normalization, we obtain the normalized processor time percentage c corresponding to each deduplication metadata shard. cpu Normalized metadata storage footprint c memAnd the normalized number of input / output request processing numbers c io These are the three dimensionless index values.

[0076] Finally, a weighted summation method can be used to calculate the overall load contribution S of each deduplication metadata shard, as shown in the following formula:

[0077] S=w cpu ×c cpu +w mem ×c mem +w io ×c io

[0078] Wherein, the weights satisfy w cpu +w mem +w io =1, to ensure that the contributions are comparable.

[0079] This computational model allows for the objective and dynamic identification of high-contribution deduplicated metadata shards that are truly causing load pressure. For example, a deduplicated metadata shard may have few input / output requests, but its high CPU usage due to complex hash calculations can still accurately reflect its contribution. Subsequent load balancing processes can then prioritize migrating such deduplicated metadata shards, thereby achieving maximum performance gains with minimal migration overhead.

[0080] The above methods not only improve the intelligence level of load balancing, but also enhance the adaptability of multi-controller architecture storage systems to diverse business workloads, which is significantly better than coarse screening strategies that rely on a single indicator or simple counting.

[0081] In one possible implementation, migrating the fragment to be migrated to the target controller node among the remaining controller nodes whose load does not exceed a preset threshold and has the lowest metadata storage volume includes: performing load isolation on the fragment to be migrated, temporarily caching subsequent new input / output requests directed to the fragment to be migrated in a global shared input / output queue; synchronizing the metadata of the fragment to be migrated from the source controller node to which the fragment belongs to the target controller node; controlling the target controller node to rebuild the metadata index and input / output processing queue of the fragment to be migrated locally, and entering a ready state; in response to the target controller node entering the ready state, updating the metadata fragment node mapping table, and synchronizing the updated mapping relationship to each controller node; controlling the target controller node to retrieve the cached input / output requests from the global shared input / output queue and process them; controlling the source controller node to release the storage space and memory resources occupied by the fragment to be migrated, completing the migration process.

[0082] Specifically, to ensure uninterrupted service, no data loss, and consistent state during the migration of deduplicated metadata shards, a seamless hot migration process can be adopted to safely migrate the shards from the source controller node to the target controller node. This process includes the following sequential steps:

[0083] First, load isolation is performed on the shard to be migrated. Once the migration decision is made, all newly arriving I / O requests (such as requests to read specific logical block addresses) directed to the shard to be migrated can be immediately intercepted and temporarily cached in a global shared I / O queue. This global shared I / O queue can reside in the global shared memory of the multi-controller architecture storage system and is visible to all controller nodes, ensuring that requests are not lost or timed out during migration.

[0084] Subsequently, the metadata synchronization phase can be initiated, replicating all deduplicated metadata (including hash pointers, physical data list entries, and the mapping between logical block addresses and physical block addresses) contained in the shard to be migrated from the source controller node to the target controller node completely and consistently. This process can be performed through a high-speed interconnect channel to minimize transmission latency and can be supplemented with verification mechanisms (such as version number comparison) to ensure data integrity.

[0085] After the metadata synchronization is complete, the target controller node can be controlled to rebuild the runtime state of the shard to be migrated locally, including: rebuilding the hash index structure (such as a hash table) to support fast metadata query; initializing a dedicated input / output processing queue for subsequent request scheduling; and restoring statistical counters (such as access count, error rate, etc.) for load monitoring and performance analysis.

[0086] Once the reconstruction is complete, the target controller node can be set to the Ready state. In response, the metadata shard node mapping table in the global shared memory can be updated, switching the ownership field of the shard to be migrated from the source controller node to the target controller node. To prevent concurrent conflicts, this update operation can be performed using an atomic write operation. After the update, the mapping change event can be immediately broadcast to all controller nodes, triggering each controller node to refresh its local cached mapping copy, ensuring correct subsequent input / output routing.

[0087] Next, the target controller node can retrieve previously cached input / output requests from the globally shared input / output queue and process them according to the normal flow (such as querying the hash pointer, locating physical data, and returning results). Since the target controller node has now completely taken over the shard to be migrated, each request can be served correctly and efficiently, achieving seamless switching.

[0088] Finally, after confirming that each cached request has been successfully processed and there are no residual dependencies, the source controller node can be controlled to release the storage space and memory resources occupied by the shard to be migrated, including deleting local metadata copies and reclaiming index structures and queue memory. At this point, the entire migration process is completed safely, completely, and seamlessly.

[0089] Through the above methods, this embodiment achieves online, hot migration, and zero packet loss load balancing capabilities, which not only ensures business continuity but also effectively alleviates controller hotspot issues, significantly improving the reliability and service quality of the multi-controller architecture storage system.

[0090] In one possible implementation, updating the metadata shard node mapping table includes: locating the shard identifier corresponding to the shard to be migrated in the global shared memory; updating the home controller node field associated with the shard identifier from the source controller node to the target controller node, with the update performed via an atomic write operation; and broadcasting a mapping change event to each controller node after the update is completed, so as to trigger each controller node to update its locally cached metadata shard node mapping copy.

[0091] Specifically, to ensure the consistency of the system's global view during the deduplication metadata sharding migration process, the metadata sharding node mapping table can be securely and atomically updated during critical migration phases. This metadata sharding node mapping table is the routing hub of the entire multi-controller architecture storage system, and its accuracy directly affects whether input and output requests can be correctly forwarded to the currently assigned controller node.

[0092] Specifically, the update operation includes the following steps: First, locate the shard identifier corresponding to the shard to be migrated in the global shared memory. This shard identifier is assigned when the shard is created and has global uniqueness (e.g., a 64-bit unsigned integer). It can be used as a primary key or index field in the mapping table to quickly find the corresponding table entry.

[0093] Subsequently, the value of the "Own Controller Node" field in this entry can be updated from the source controller node to the target controller node. This update operation can be performed atomically, for example, using the Compare-and-Swap (CAS) instruction provided by the processor, or utilizing a memory transaction mechanism to ensure that no intermediate state (such as reading partially updated dirty data) occurs in concurrent access scenarios. Atomicity guarantees that at any given time, when other controller nodes read this mapping table, they will either see the complete state before the migration or the complete state after the migration, eliminating routing errors caused by partial updates.

[0094] After a successful atomic update, a mapping update event can be immediately broadcast to all other controller nodes. This mapping update event can be sent via multicast or multicast over a high-speed interconnect network, and includes the changed fragment identifier and the new home node information.

[0095] Upon receiving the mapping change event, each controller node can trigger an update process for its locally cached metadata shard node mapping copy. Typically, each controller node maintains a cached copy of the mapping table in its local memory to accelerate shard location lookups. Upon receiving the broadcast, each controller node refreshes the cached entry for the corresponding shard to the latest value, ensuring that subsequent input / output requests for that shard can be correctly routed to the target controller node, preventing requests from being incorrectly sent to the source controller node that no longer manages the shard due to outdated cache.

[0096] Using the above methods, the multi-controller architecture storage system achieves strong consistency synchronization of the mapping state in a high-concurrency, multi-node environment. This ensures the reliability of the migration process and maintains low latency and high availability of the input and output paths, providing a solid foundation for the entire load balancing solution.

[0097] In one possible implementation, after the migration process is completed, the method further includes: monitoring the running status of the shard to be migrated on the target controller node, including hash pointer query response latency, metadata processing throughput, and input / output request error rate; if the hash pointer query response latency exceeds a preset response threshold, or the metadata processing throughput is lower than a preset throughput threshold, or the input / output request error rate is higher than a preset error rate threshold, then the migration of the shard to be migrated is determined to be abnormal; the shard to be migrated is migrated back to the source controller node or other alternative controller nodes that meet the condition that the load does not exceed a preset threshold, and the metadata shard node mapping table is updated and the local cache copies of each controller node are synchronized.

[0098] Specifically, to ensure the actual effectiveness and service quality of the load balancing migration operation, the multi-controller architecture storage system does not immediately consider the migration successful after completing the shard migration process. Instead, it initiates a post-migration verification and self-healing mechanism. This mechanism continuously monitors the actual performance of the shards to be migrated on the target controller node to determine whether they are truly adapted to the new environment, thereby avoiding performance degradation or service downgrade caused by migrating to a worse node.

[0099] Specifically, the running status of the shards to be migrated on the target controller node can be monitored in multiple dimensions, mainly including three key indicators: hash pointer query response latency, metadata processing throughput, and input / output request error rate.

[0100] Hash pointer query response latency refers to the time elapsed from receiving a metadata query request (such as looking up the corresponding hash pointer based on the logical block address) to returning the result, reflecting the access efficiency of the metadata index.

[0101] Metadata processing throughput refers to the number of metadata-related operations successfully processed by the target controller node per unit of time, such as hash pointer lookups and physical data list entry updates per second, reflecting its processing capacity.

[0102] Input / output request error rate refers to the proportion of input / output requests for a particular shard that fail (such as timeout, validation error, path unreachable, etc.) within a certain period of time, and it characterizes service stability.

[0103] You can set corresponding preset thresholds for each of the above indicators, including: preset response threshold (e.g., 5 milliseconds), preset throughput threshold (e.g., 10,000 operations per second), and preset error rate threshold (e.g., 0.1%).

[0104] Within a pre-defined observation window (e.g., 30 seconds) after migration is completed, if any metric exceeds its threshold—namely, if the hash pointer query response latency exceeds a pre-defined response threshold, the metadata processing throughput is lower than a pre-defined throughput threshold, or the input / output request error rate is higher than a pre-defined error rate threshold—then the shard to be migrated can be considered to have experienced a migration anomaly. Such anomalies may be caused by various reasons, such as: the actual load on the target node being underestimated, the cache not being hot enough, hardware performance differences, or network path degradation.

[0105] Once a migration anomaly is determined, a rollback and rescheduling strategy can be immediately triggered: the shard to be migrated can be migrated back to the source controller node (i.e., the original home node before migration), or if the source controller node no longer meets the load conditions (e.g., it is still in an overloaded state), other alternative controller nodes that meet the load not exceeding the preset threshold can be selected as the new target controller node.

[0106] While performing the re-migration, the metadata shard node mapping table in the global shared memory can be updated synchronously, the ownership information of the shard to be migrated can be corrected to the new valid node, and the mapping change event can be broadcast to each controller node to ensure that each controller node refreshes its local cached mapping copy in a timely manner, preventing subsequent input and output requests from being incorrectly routed.

[0107] Through the aforementioned closed-loop verification and self-healing mechanism, this embodiment effectively avoids performance fluctuations or service interruptions caused by blind migration, significantly improves the stability, reliability, and user experience of the load balancing system, and achieves the intelligent governance goal of migration only taking effect when it is valid and rolling back when it is invalid.

[0108] In one possible implementation, the method further includes: maintaining a migration anomaly counter for each deduplicated metadata shard to record the number of migration anomalies that occur in the corresponding deduplicated metadata shard within a preset time window; when the number of migration anomalies for any deduplicated metadata shard reaches a preset upper limit threshold, marking the corresponding deduplicated metadata shard as a migration-restricted shard; prohibiting the migration-restricted shard from participating in subsequent load balancing migration operations, and fixing its affiliation to the controller node.

[0109] Specifically, to prevent system resource waste or continuous service instability caused by repeated migration failures, a migration anomaly accumulation management mechanism can be further introduced. This mechanism effectively avoids migration thashing by recording and restricting the migration history of deduplicated metadata shards, i.e., a deduplicated metadata shard that frequently migrates between multiple controller nodes but cannot operate stably.

[0110] Specifically, a separate migration failure counter can be maintained for each deduplicated metadata shard. Within a preset time window (e.g., the last 5 minutes, 10 minutes, or 1 hour), whenever the deduplicated metadata shard is judged to have a migration failure due to substandard performance after migration (e.g., excessive response latency, insufficient throughput, or excessive error rate) and a rollback operation is triggered, the corresponding counter value is automatically incremented by 1.

[0111] Additionally, a preset upper limit threshold (e.g., 3 times, 5 times) can be configured as the basis for determining whether to enable the restriction policy. When the number of migration anomalies of any deduplicated metadata shard reaches or exceeds the upper limit threshold, the deduplicated metadata shard can be marked as a migration-restricted shard. This mark can be stored in the metadata attribute field of the migration-restricted shard or recorded separately in the global management table.

[0112] Once a shard is marked as migration-restricted, its deduplicated metadata will be prohibited from participating in any subsequent load balancer-driven migration operations. Even if its current host controller node becomes overloaded again, the load balancer will proactively skip such migration-restricted shards when filtering shards for migration and will no longer include them in the candidate set.

[0113] In addition, a fixed ownership policy can be applied to the migration-restricted shard. Its current ownership is locked and will no longer be adjusted with load changes. This means that the migration-restricted shard will be managed by the current controller node for a long time until manual intervention (such as maintenance personnel resetting the counter) or automatic cleanup of expired restrictions after the multi-controller architecture storage system enters maintenance mode.

[0114] To prevent permanent locking due to the infinite accumulation of counters, multi-controller architecture storage systems can also incorporate a sliding time window mechanism. This mechanism only counts the number of exceptions within the current window, automatically invalidating historical records beyond the window. For example, if the time window is 10 minutes, exception records from 10 minutes ago will not be counted, allowing migration-restricted shards to have a chance to re-participate in the migration process after the cooling-off period.

[0115] Through the above methods, this embodiment ensures the overall load balancing capability of the multi-controller architecture storage system while implementing precise isolation and long-term fixation of stubborn abnormal shards. This not only prevents the additional overhead caused by invalid migration to the multi-controller architecture storage system, but also improves the stability and predictability of the service, and significantly enhances the stability of the multi-controller deduplication storage system in complex production environments.

[0116] In one possible implementation, the method further includes: during the process of synchronizing the metadata of the fragment to be migrated to the target controller node, verifying the consistency status of the data blocks associated with each physical data list entry in the fragment to be migrated in the multi-controller architecture storage system; if the consistency verification passes, generating a verification synchronization message carrying the fragment identifier of the fragment to be migrated, and broadcasting it to the other controller nodes; after the target controller node receives the verification confirmation response returned by each controller node, marking the fragment to be migrated as ready; if any controller node fails the verification, suspending the migration process, maintaining the ownership status of the fragment to be migrated on the source controller node, and triggering a data repair task.

[0117] Specifically, to ensure that the underlying data blocks upon which deduplication metadata shards depend during cross-controller migration are in a complete, consistent, and reliable state, a cross-node consistency verification mechanism can be introduced during the metadata synchronization phase. This mechanism aims to prevent issues such as storage media failures, non-persistent writes, or inconsistent replicas from causing metadata to become disconnected from the actual data after migration, thereby leading to read errors, data loss, or abnormal deduplication logic.

[0118] Specifically, during the process of synchronizing the metadata of the shard to be migrated from the source controller node to the target controller node, the consistency status of the data blocks associated with each physical data list entry in the shard to be migrated can be verified in the multi-controller architecture storage system. Each physical data list entry records the location of the physical data block corresponding to the hash pointer in the storage device, as well as the expected verification information.

[0119] The consistency check request is initiated to the storage subsystem (e.g., reading a data block with verification and verifying its integrity), or the replica consistency status of the distributed storage layer is queried (e.g., whether the erasure coding group is complete, or whether the independent disk redundant array reconstruction is complete) to determine whether the data block is currently in a valid and consistent state. If all associated data blocks pass verification, the shard to be migrated is considered to meet the migration prerequisites.

[0120] Once the consistency verification passes, the source controller node can generate a verification synchronization message carrying the fragment identifier of the fragment to be migrated. This verification synchronization message can be broadcast to all other controller nodes via the high-speed interconnect network, requesting each controller node to collaboratively confirm the consistency of the data blocks involved in the fragment to be migrated based on its own cache or local view.

[0121] After receiving the verification and synchronization message, each controller node can independently perform a consistency judgment based on its locally maintained metadata copy, cache status, or the interaction results with the storage layer, and return a verification confirmation response to the source controller node or coordinator.

[0122] After receiving verification confirmation responses from the other controller nodes, the target controller node can mark the shard to be migrated locally as ready, indicating that it is capable of providing services. This confirmation mechanism ensures that the migration will not be completed in the event of potential data problems in the multi-controller architecture storage system, thus improving migration reliability.

[0123] Conversely, if any controller node detects data anomalies during the verification process (such as verification failure, unreadable data, missing replicas, etc.), it returns a verification failure response. Once any verification failure response is detected, it is determined that there is a data consistency problem in this migration, and the entire migration process can be immediately stopped: the global mapping table is not updated; the input and output routes are not switched; the ownership status of the shard to be migrated on the source controller node remains unchanged, ensuring that the business continues to be safely processed by the original controller node.

[0124] Simultaneously, trigger a data repair task, such as initiating a background rebuild, restoring damaged blocks from a healthy copy, or notifying the storage layer to perform a self-healing operation.

[0125] Through the above method, this embodiment embeds a strong consistency guarantee link in the critical path of load balancing migration, realizing a security strategy of only migrating when the data is reliable and rolling back if the migration fails. This effectively avoids metadata corruption or service interruption caused by underlying storage anomalies, and significantly improves the data integrity and service continuity of the multi-controller architecture storage system in high-reliability scenarios.

[0126] In one possible implementation, the method further includes: constructing a cross-node cache shared pool accessible by all controller nodes; organizing the physical data loaded into the cross-node cache shared pool using a dual index based on logical block addresses and shard identifiers; when any non-owning controller node receives a read request for a target logical block address, calculating the corresponding hash value based on the target logical block address, and determining the target deduplication metadata shard to which the logical block address belongs and its corresponding shard identifier based on the hash value; performing a query operation in the cross-node cache shared pool based on the shard identifier and the target logical block address; if the query is successful, returning the physical data corresponding to the target logical block address from the cross-node cache shared pool; if the query is unsuccessful, initiating a remote read request to the controller node currently owning the target deduplication metadata shard, obtaining the corresponding physical data from the storage device it manages, and loading the physical data into the cross-node cache shared pool using a dual index.

[0127] Specifically, to improve the access efficiency of non-owned controller nodes to remote deduplicated metadata shards and reduce cross-node input / output latency, a cross-node cache sharing pool can be further constructed. This cross-node cache sharing pool can be deployed in the global shared memory area of ​​a multi-controller architecture storage system, and can be accessed concurrently and with low latency by various controller nodes through high-speed interconnect channels, thereby forming a unified, distributed, and transparent high-performance cache layer.

[0128] When physical data blocks (i.e. unique data content after deduplication) read from the backend storage device are loaded into this cross-node cache shared pool, they are not stored in a simple linear manner, but are organized using a dual index structure: the first dimension is the logical block address, which is used to quickly respond to host input and output requests; the second dimension is the shard identifier, which is used to associate the deduplication metadata shard to which the data block belongs.

[0129] This dual index can be implemented as a two-level hash table or a composite index structure, enabling multi-controller architecture storage systems to quickly locate data by logical block address and perform batch management by shard identifier (such as batch invalidation of cache during shard migration).

[0130] When any non-home controller node (i.e., the controller node that is not currently responsible for managing the deduplication metadata shard to which the logical block address belongs) receives a read request from a host for a target logical block address, it first calculates the corresponding hash value based on the logical block address. Based on this hash value, it queries the metadata shard node mapping table to determine the target deduplication metadata shard to which the logical block address belongs and its unique shard identifier. This step ensures accurate identification of data ownership even if the request is received by a non-home node.

[0131] Subsequently, the non-owning node can perform a join query operation in the cross-node cache shared pool based on the obtained shard identifier and the target logical block address. If the query is successful, meaning the physical data block already exists in the cross-node cache shared pool, the physical data corresponding to the target logical block address is directly read from the cross-node cache shared pool and returned, without needing to access remote nodes or backend storage, significantly reducing read latency.

[0132] If the query fails to find the target data shard, a remote read request can be initiated to the controller node that currently owns the target deduplication metadata shard. Upon receiving the remote read request, the owning node can read the corresponding physical data from its locally managed storage device (such as distributed object storage) and return the physical data to the requester via a high-speed interconnect network.

[0133] Upon receiving the physical data, the requester (i.e., the non-home node) can load the data into the cross-node cache shared pool according to the aforementioned dual index, so that subsequent requests for the same or the same segment targeting the target logical block address can be directly queried in the cross-node cache shared pool.

[0134] By employing the methods described above, this embodiment effectively solves the cache cold start problem caused by shard migration or load balancing in a multi-controller architecture. Even if the shard to be migrated is moved to a new controller node, other controller nodes can still efficiently access its hot data through the cross-node cache shared pool, avoiding the need to retrieve data from the origin node for each read. This not only significantly improves the read performance of non-home nodes but also reduces the input / output pressure and network bandwidth consumption of the home node, enhancing the scalability and responsiveness of the entire multi-controller architecture storage system.

[0135] In one possible implementation, to improve fault recovery efficiency and reduce communication overhead, a multi-controller architecture storage system can employ a metadata incremental synchronization mechanism based on change logs. Metadata change log units can be deployed on each controller node to record various metadata operations (including additions, modifications, and deletions). Each log entry contains a fragment number (1 byte), operation type (1 byte), metadata identifier (16 bytes), change content (32 bytes), and timestamp (8 bytes), for a total length of 65 bytes, stored in binary format to save space. The log can retain data from the most recent 7 days to meet typical fault recovery window requirements.

[0136] When any controller node fails and recovers, it can first establish a connection with a healthy node within the same controller domain to request the shard dimension change logs during the failure period. The healthy node can push the compressed shard log file to the failed node, which then decompresses it and replays the logs line by line according to the shard number, synchronizing only the changed metadata fragments. The synchronization time is no more than 30 seconds, quickly restoring the failed shards in the core mechanism. After the metadata synchronization is complete, the multi-controller architecture storage system can trigger the checksum block synchronization process to ensure the consistency of the checksum metadata. Subsequently, cache consistency checks are performed, marking invalid entries in the failed node's local cache. Finally, the failed node performs triple consistency checks on metadata, checksum blocks, and cached data with other controller nodes, synchronizing only inconsistent local fragments to achieve efficient global consistency.

[0137] In addition, in a multi-controller architecture storage system, log files older than 7 days can be automatically cleaned up daily. Before cleaning, it is verified that the relevant metadata has been successfully synchronized to each node to ensure that there is no possibility of data loss.

[0138] In one possible implementation, to ensure the quality of critical business services, a multi-controller architecture storage system can implement priority scheduling for verification and synchronization tasks. Each I / O operation is divided into three priorities according to business characteristics: first priority (Priority 0, P0), second priority (Priority 1, P1), and third priority (Priority 2, P2).

[0139] The first priority includes urgent I / O (such as database transactions) with latency requirements of less than 1 millisecond and shards to be migrated, accounting for about 10%.

[0140] The second priority includes general business read / write I / O, with a latency requirement of 1 to 5 milliseconds, accounting for approximately 70%.

[0141] The third priority (P2) includes background task I / O (such as verification synchronization and data backup), which has no strict latency requirements and accounts for about 20%.

[0142] After triggering synchronization, the sending end can mark priorities based on I / O type and insert them into the corresponding priority queue. The priority queue processes tasks in timestamp order to prevent low-priority tasks from starving. The receiving end can maintain three independent message processing threads, with thread priorities strictly corresponding to message priorities; higher-priority threads process lower-priority tasks only when they are idle.

[0143] To ensure data consistency, read operations on the corresponding data are only allowed after verification and synchronization are completed and confirmation is received from each node. Meanwhile, the communication bandwidth between multiple controller nodes is allocated proportionally: 30% for P0, 50% for P1, and 20% for P2. This ensures low latency for high-priority messages while preventing long-term blocking of low-priority tasks.

[0144] In one possible implementation, a refined coordination mechanism can also be used to avoid conflicts between background tasks (such as initialization, reconstruction, copying back, and verification synchronization) and cross-node read operations.

[0145] Specifically, during initialization, the upper-layer module ensures that writes precede reads, and the stripe has already been initialized when a non-home node reads it. When the stripe's ownership changes, only the new home node can trigger initialization; read operations by non-home nodes do not trigger initialization, preventing duplicate operations.

[0146] During the reconstruction process, read operations directly determine data readability based on disk status, without relying on reconstruction progress metadata. When reconstruction I / O conflicts with read I / O, the reconstruction task is paused and the stripe lock is released. It resumes after the read I / O operation is completed. The reconstruction task supports breakpoint resumption to avoid duplicate work through the breakpoint resumption mechanism.

[0147] During the copy-back process, non-owner nodes can force data to be read from the hot spare disk, regardless of the copy-back progress. The owner node selects the data source (hot spare disk or member disk) based on the copy-back completion flag and avoids deadlock through a lock timeout retry mechanism (the timeout threshold can be 50 milliseconds). When the core mechanism migrates shards, the lock of the shard to be migrated is automatically transferred to the target node.

[0148] During the verification and synchronization process, the verification and synchronization messages share the communication channel with read I / O, and bandwidth is allocated according to a preset ratio (60% for read I / O and 40% for verification and synchronization). The verification and synchronization task does not occupy the dedicated read I / O cache resources to ensure cache hit rate. When the core mechanism is migrated, it is temporarily adjusted to 30% for migration synchronization, 50% for read I / O, and 20% for regular verification and synchronization to ensure migration bandwidth.

[0149] In one possible implementation, a multi-controller architecture storage system can employ a differentiated cache read strategy.

[0150] When a non-home node receives a read request, it first queries the cross-node cache shared pool. If a match is found (latency ≤ 0.3 milliseconds), the data is returned directly. If a match is not found, the data is read from disk and loaded into the cross-node cache shared pool. This cross-node cache shared pool can employ an enhanced Least Recently Used (LRU) eviction policy. When cache space is insufficient, the least recently used data is evicted first. Simultaneously, any cache entry that has not been accessed for 30 consecutive minutes is forcibly marked as eligible for eviction, ensuring that long-term cold data does not occupy cache resources and is still associated according to shard number during loading.

[0151] When the home node receives a read request, it can only query the local cache. If the cache misses, it can directly read the disk without accessing the cross-node cache shared pool, thus avoiding redundant resource consumption.

[0152] To maintain cache consistency, when a data block or checksum is updated, the checksum synchronization across all controller nodes is first completed. Then, a write invalidation mechanism is used to mark the corresponding entry in the cross-node cache shared pool as invalid. Invalidated entries are prohibited from being accessed by subsequent read requests to ensure that each read operation is based on the latest disk data.

[0153] In one possible implementation, the multi-controller architecture storage system can provide a management interface to support load balancing strategy adjustments and operational status monitoring. It can display in real-time the processor utilization, metadata storage volume, I / O processing queue length, and cross-node cache shared pool hit rate for each node.

[0154] This application embodiment can divide an electronic device or main control device into functional modules according to the above method examples. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional module. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division; in actual implementation, there may be other division methods.

[0155] Figure 3 This is a schematic diagram of a load balancing device provided in an embodiment of this application. Figure 3 As shown in the figure, an embodiment of this application also provides a load balancing device. This device is applied to a multi-controller architecture storage system, which includes multiple controller nodes, each corresponding to a controller domain for managing deduplication metadata shards. The device includes: an acquisition module 310, a sharding module 320, a mapping module 330, a monitoring module 340, and a migration module 350.

[0156] The acquisition module 310 is used to acquire deduplication metadata in a multi-controller architecture storage system. The deduplication metadata includes hash pointers, physical data list entries, and the mapping relationship between logical block addresses and physical block addresses.

[0157] The sharding module 320 is used to divide deduplicated metadata into multiple deduplicated metadata shards of equal size according to a preset granularity. Each deduplicated metadata shard corresponds to a unique shard identifier and constitutes the smallest metadata unit that can be independently migrated and managed.

[0158] The sharding module 320 is also used to statically distribute multiple deduplicated metadata shards to each controller domain, so that each controller domain initially manages a balanced portion of the deduplicated metadata shards.

[0159] The mapping module 330 is used to establish and maintain a metadata shard node mapping table in the global shared memory of the multi-controller architecture storage system, and to record the current owner controller node of each deduplicated metadata shard.

[0160] Monitoring module 340 is used to monitor the load of each controller node.

[0161] The migration module 350 is used to select fragments to be migrated from the deduplication metadata fragments managed by any controller node when the load of any controller node exceeds a preset threshold, and migrate the fragments to be migrated to the target controller node among the remaining controller nodes whose load does not exceed the preset threshold and whose metadata storage volume is the lowest.

[0162] The mapping module 330 is also used to update the metadata shard node mapping table after the migration is completed, and to synchronize the updated mapping relationship to each controller node.

[0163] In one possible implementation, the load includes processor utilization, metadata storage, and input / output processing queue length, and the preset thresholds include processor utilization threshold, metadata storage threshold, and input / output processing queue length threshold.

[0164] The migration module 350 is also used to determine that the load of the controller node exceeds a preset threshold when the processor utilization rate of any controller node exceeds the processor utilization rate threshold, or the metadata storage exceeds the metadata storage threshold, or the input / output processing queue length exceeds the input / output processing queue length threshold.

[0165] The migration module 350 is also used to calculate the contribution of each deduplication metadata shard managed by the controller node to the load after determining that the load exceeds a preset threshold. The contribution is calculated based on the processor time ratio, metadata storage usage, and number of input / output request processing corresponding to each deduplication metadata shard.

[0166] The migration module 350 is also used to sort data from highest to lowest contribution and select a preset number of deduplicated metadata shards as shards to be migrated.

[0167] In one possible implementation, the migration module 350 is also used to assign preset weights to the processor time percentage, metadata storage usage, and the number of input / output request processing, respectively.

[0168] The migration module 350 is also used to normalize the processor time ratio, metadata storage usage and input / output request processing number corresponding to each deduplication metadata shard to obtain normalized index values.

[0169] The migration module 350 is also used to calculate the load contribution of each deduplication metadata shard by weighted summation based on the normalized index value and the corresponding preset weight.

[0170] In one possible implementation, the migration module 350 is also configured to perform load isolation on the fragment to be migrated, and temporarily cache subsequent new input / output requests to the fragment to be migrated to a globally shared input / output queue.

[0171] The migration module 350 is also used to synchronize the metadata of the fragment to be migrated from the source controller node to which the fragment belongs to the target controller node.

[0172] The migration module 350 is also used to control the target controller node to rebuild the metadata index and input / output processing queue of the shard to be migrated locally and enter the ready state.

[0173] The migration module 350 is also used to update the metadata shard node mapping table in response to the target controller node entering the ready state, and to synchronize the updated mapping relationship to each controller node.

[0174] The migration module 350 is also used to control the target controller node to retrieve cached input / output requests from the globally shared input / output queue and process them.

[0175] The migration module 350 is also used to control the source controller node to release the storage space and memory resources occupied by the fragments to be migrated, thus completing the migration process.

[0176] In one possible implementation, the migration module 350 is also configured to locate the fragment identifier corresponding to the fragment to be migrated in the global shared memory.

[0177] The migration module 350 is also used to update the home controller node field associated with the shard identifier from the source controller node to the target controller node, and the update is performed through an atomic write operation.

[0178] The migration module 350 is also used to broadcast mapping change events to each controller node after the update is completed, so as to trigger each controller node to update the local cached metadata shard node mapping copy.

[0179] In one possible implementation, the migration module 350 is also used to monitor the running status of the shard to be migrated on the target controller node, including hash pointer query response latency, metadata processing throughput, and input / output request error rate.

[0180] The migration module 350 is also used to determine that the migration of the fragment to be migrated is abnormal if the hash pointer query response delay exceeds a preset response threshold, or the metadata processing throughput is lower than a preset throughput threshold, or the input / output request error rate is higher than a preset error rate threshold.

[0181] The migration module 350 is also used to migrate the shards to be migrated back to the source controller node or other alternative controller nodes whose load does not exceed a preset threshold, and to update the metadata shard node mapping table and synchronize the local cache copies of each controller node.

[0182] In one possible implementation, the migration module 350 is also used to maintain a migration exception counter for each deduplicated metadata shard, which records the number of times a migration exception occurs in the corresponding deduplicated metadata shard within a preset time window.

[0183] The migration module 350 is also used to mark the corresponding deduplicated metadata shard as a migration-restricted shard when the number of migration anomalies for any deduplicated metadata shard reaches a preset upper limit threshold.

[0184] The migration module 350 is also used to prevent migration-restricted shards from participating in subsequent load balancing migration operations and to fix their affiliation to the controller node.

[0185] In one possible implementation, the migration module 350 is further configured to verify the consistency status of the data blocks associated with each physical data list entry in the shard to be migrated in the multi-controller architecture storage system during the process of synchronizing the metadata of the shard to be migrated to the target controller node.

[0186] The migration module 350 is also used to generate a verification synchronization message carrying the fragment identifier of the fragment to be migrated if the consistency verification passes, and broadcast it to the other controller nodes.

[0187] The migration module 350 is also used to mark the fragment to be migrated as ready after the target controller node receives the verification confirmation response returned by each controller node.

[0188] The migration module 350 is also used to abort the migration process if any controller node fails to verify, maintain the ownership status of the fragment to be migrated on the source controller node, and trigger a data repair task.

[0189] In one possible implementation, the device further includes a query module.

[0190] The query module is used to build a cross-node cache sharing pool that can be accessed by all controller nodes.

[0191] The query module is also used to organize physical data loaded into the cross-node cache shared pool by dual indexing based on logical block address and shard identifier.

[0192] The query module is also used to calculate the corresponding hash value based on the target logical block address when any non-home controller node receives a read request for the target logical block address, and to determine the target deduplication metadata shard to which the logical block address belongs and the corresponding shard identifier based on the hash value.

[0193] The query module is also used to perform query operations in the cross-node cache shared pool based on the shard identifier and the target logical block address.

[0194] The query module is also used to return the physical data corresponding to the target logical block address from the cross-node cache shared pool if the query is successful.

[0195] The query module is also used to initiate a remote read request to the controller node to which the target deduplication metadata shard currently belongs if the query fails, to obtain the corresponding physical data from the storage device it manages, and to load the physical data into the cross-node cache shared pool according to the dual index.

[0196] For a description of the features in the embodiment corresponding to the load balancing device, please refer to the relevant description of the embodiment corresponding to the load balancing method, which will not be repeated here.

[0197] Figure 4 This is a schematic diagram of the structure of an electronic device provided in this application. Figure 4 As shown, the electronic device provided in this embodiment includes at least one processor 410 and a memory 420. Optionally, the electronic device further includes a communication component 430. The processor 410, memory 420, and communication component 430 are connected via a bus.

[0198] In a specific implementation, at least one processor 410 executes computer execution instructions stored in memory 420, causing at least one processor 410 to execute the above-described load balancing method embodiment.

[0199] The specific implementation process of processor 410 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0200] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0201] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0202] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0203] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described load balancing method embodiments at runtime.

[0204] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0205] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described load balancing method embodiments.

[0206] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described load balancing method embodiments.

[0207] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0208] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for various specific applications, but such implementations should not be considered beyond the scope of this application.

[0209] The load balancing method and electronic device provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A load balancing method, characterized in that, The method is applied to a multi-controller architecture storage system, which includes multiple controller nodes, each corresponding to a controller domain for managing deduplication metadata shards. The method includes: Obtain deduplication metadata from the multi-controller architecture storage system. The deduplication metadata includes hash pointers, physical data list entries, and the mapping relationship between logical block addresses and physical block addresses. The deduplication metadata is divided into multiple deduplication metadata fragments of equal size according to a preset granularity. Each deduplication metadata fragment corresponds to a unique fragment identifier and constitutes the smallest metadata unit that can be independently migrated and managed. The multiple deduplication metadata shards are statically allocated to each controller domain, so that each controller domain initially manages a balanced portion of the deduplication metadata shards. A metadata shard node mapping table is established and maintained in the global shared memory of the multi-controller architecture storage system to record the current controller node to which each deduplicated metadata shard belongs; Monitor the load of each controller node, including processor utilization, metadata storage, and input / output processing queue length; When the load of any controller node exceeds a preset threshold, the controller selects the fragments to be migrated from the deduplication metadata fragments it manages, performs load isolation on the fragments to be migrated, and temporarily caches subsequent new input / output requests to the fragments to be migrated in the global shared input / output queue. The metadata of the fragment to be migrated is synchronized from the source controller node to which the fragment belongs to to the target controller node among the remaining controller nodes whose load does not exceed a preset threshold and whose metadata storage is the lowest. The target controller node is controlled to rebuild the metadata index and input / output processing queue of the fragment to be migrated locally, and enter the ready state; In response to the target controller node entering the ready state, the metadata shard node mapping table is updated, and the updated mapping relationship is synchronized to each controller node; The target controller node is controlled to retrieve cached input / output requests from the globally shared input / output queue and process them. The source controller node is controlled to release the storage space and memory resources occupied by the fragment to be migrated, thus completing the migration process.

2. The method according to claim 1, characterized in that, The preset thresholds include processor utilization threshold, metadata storage threshold, and input / output processing queue length threshold. When the load on any controller node exceeds a preset threshold, select shards to be migrated from the deduplication metadata shards it manages, including: When the processor utilization rate of any controller node exceeds the processor utilization rate threshold, or the metadata storage exceeds the metadata storage threshold, or the input / output processing queue length exceeds the input / output processing queue length threshold, the load of the controller node is determined to exceed the preset threshold. After determining that the load exceeds a preset threshold, the contribution of each deduplication metadata shard managed by the controller node to the load is calculated. The contribution is calculated based on the processor time ratio, metadata storage usage, and number of input / output request processing corresponding to each deduplication metadata shard. Based on the contribution level, sort from high to low, and select a preset number of deduplicated metadata shards with the highest ranking as the shards to be migrated.

3. The method according to claim 2, characterized in that, The calculation of the contribution of each deduplication metadata shard managed by the controller node to the load includes: Preset weights are assigned to the processor time percentage, the metadata storage usage, and the number of input / output request processing. The processor time percentage, metadata storage usage, and number of input / output request processing corresponding to each deduplication metadata shard are normalized to obtain normalized index values. Based on the normalized index value and the corresponding preset weight, the load contribution of each deduplicated metadata shard is calculated by weighted summation.

4. The method according to claim 1, characterized in that, The updating of the metadata shard node mapping table includes: Locate the fragment identifier corresponding to the fragment to be migrated in the global shared memory; The field of the home controller node associated with the fragment identifier is updated from the source controller node to the target controller node, and the update is performed through an atomic write operation; After the update is complete, a mapping change event is broadcast to each controller node to trigger each controller node to update the local cached metadata shard node mapping copy.

5. The method according to claim 1, characterized in that, After the migration process is completed, it also includes: Monitor the running status of the shard to be migrated on the target controller node. The running status includes hash pointer query response latency, metadata processing throughput, and input / output request error rate. If the hash pointer query response delay exceeds a preset response threshold, or the metadata processing throughput is lower than a preset throughput threshold, or the input / output request error rate is higher than a preset error rate threshold, then the fragment migration to be migrated is determined to be abnormal. The shard to be migrated is migrated back to the source controller node or other alternative controller nodes whose load does not exceed a preset threshold, and the metadata shard node mapping table is updated and the local cache copies of each controller node are synchronized.

6. The method according to claim 5, characterized in that, The method further includes: Maintain a migration exception counter for each deduplication metadata shard to record the number of migration exceptions that occur in the corresponding deduplication metadata shard within a preset time window; When the number of migration anomalies for any deduplicated metadata shard reaches a preset upper limit threshold, the corresponding deduplicated metadata shard will be marked as a migration-restricted shard. The migration-restricted shards are prohibited from participating in subsequent load balancing migration operations, and their assigned controller node is fixed.

7. The method according to claim 1, characterized in that, Also includes: During the process of synchronizing the metadata of the shard to be migrated to the target controller node, the consistency status of the data blocks associated with each physical data list entry in the shard to be migrated is verified in the multi-controller architecture storage system. If the consistency verification passes, a verification synchronization message carrying the fragment identifier of the fragment to be migrated is generated and broadcast to the other controller nodes; After the target controller node receives the verification confirmation response returned by each controller node, the fragment to be migrated is marked as ready. If any controller node fails verification, the migration process is aborted, the ownership status of the shard to be migrated on the source controller node is maintained, and a data repair task is triggered.

8. The method according to any one of claims 1 to 7, characterized in that, Also includes: Build a cross-node cache sharing pool that can be accessed by all controller nodes; The physical data loaded into the cross-node cache shared pool is organized using a dual index based on logical block address and fragment identifier; When any non-home controller node receives a read request for a target logical block address, it calculates the corresponding hash value based on the target logical block address, and determines the target deduplication metadata shard to which the logical block address belongs and the corresponding shard identifier based on the hash value. Based on the fragment identifier and the target logical block address, a query operation is performed in the cross-node cache shared pool; If the query hits, the physical data corresponding to the target logical block address is returned from the cross-node cache shared pool; If the query fails, a remote read request is initiated to the controller node to which the target deduplication metadata shard currently belongs, to obtain the corresponding physical data from the storage device it manages, and to load the physical data into the cross-node cache shared pool according to the dual index.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the load balancing method as described in any one of claims 1 to 8.

Images