Storage pool space management method and electronic equipment

Abstract

The invention discloses a storage pool space management method and electronic equipment, and relates to the technical field of distributed storage systems.The method comprises the steps that multiple nodes share the same storage pool, storage pools do not need to be independently built for different nodes or services, hardware resource investment is reduced, and meanwhile the design of sharing the storage pools reduces dependence on redundant nodes; working nodes obtain and use respective logic spaces through the logic space bitmaps, isolation of service data on the logic level is achieved, and meanwhile, resources can be flexibly allocated among different scenes due to unification of a storage pool. A working node can autonomously determine a to-be-processed target logic space address according to a logic space bitmap and send a request to a management node to realize space management, and the management node can dynamically allocate logic space based on a global bitmap, support resource allocation according to needs, avoid the problem of resource idleness or uneven load caused by independence of a storage pool, and improve the resource utilization rate. And the flexibility and the overall utilization rate of resource scheduling are improved.

Description

Technical Field

[0001] This application relates to the field of distributed storage system technology, and in particular to a method and electronic device for managing storage pool space. Background Technology

[0002] With the rapid development of cloud computing and big data technologies, data volume is growing exponentially, placing higher demands on the capacity, reliability, and performance of distributed storage systems. Ceph distributed storage system, as one of the mainstream solutions, uses object storage devices (OSDs) to store and manage data, and its core mechanism is widely used in the industry.

[0003] However, in existing Ceph distributed storage systems, each OSD requires independent configuration of hardware resources and software environment. At the same time, a large number of redundant OSD nodes are configured to meet reliability requirements, resulting in high deployment and maintenance costs for OSDs. Furthermore, in the actual deployment and operation of Ceph distributed storage systems, different business scenarios or nodes often require independent configuration of dedicated storage pools. This design increases the complexity of storage pool management, makes it difficult to reuse existing storage resources across scenarios, reduces the flexibility of system resource scheduling and overall utilization, and fails to meet the efficient storage needs of diverse businesses. Summary of the Invention

[0004] This application provides a storage pool space management method and electronic device to at least solve the problems of insufficient storage pool reusability and inability to meet the needs of multiple nodes sharing in the related technologies.

[0005] This application provides a storage pool space management method applied to a cluster file system. The cluster file system includes multiple nodes and a storage pool, with multiple nodes sharing the storage pool. The storage pool is used to store node data and metadata of multiple nodes. The method includes: obtaining a logical space bitmap of the storage pool through a worker node, the logical space bitmap indicating the logical space addresses corresponding to multiple nodes; determining the target logical space address to be processed by the worker node based on the logical space bitmap; generating a space management request by the worker node based on the target logical space address; and sending the space management request to a management node through the worker node to request the management node to manage the logical space corresponding to the target logical space address.

[0006] This application also provides a storage pool space management device, comprising: The acquisition module is used to obtain the logical space bitmap of the storage pool through the worker node. The logical space bitmap is used to indicate the logical space addresses corresponding to multiple nodes. The determination module is used to determine the target logical space address to be processed by the working node based on the logical space bitmap. The request generation module is used to generate space management requests based on the target logical space address through worker nodes; The sending module is used to send space management requests from worker nodes to management nodes, requesting the management nodes to manage the logical space corresponding to the target logical space address.

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

[0008] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the above-described storage pool space management method.

[0009] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described storage pool space management method.

[0010] In this application, multiple nodes share the same storage pool, eliminating the need to build separate storage pools and supporting OSD environments for different nodes or services. This reduces hardware resource investment and the workload of independent configuration and maintenance. The shared storage pool design also reduces reliance on redundant nodes, lowering overall costs in both hardware deployment and software maintenance. A logical space bitmap is introduced to abstractly manage the space within the storage pool. Worker nodes obtain and use their respective logical spaces through the logical space bitmap, achieving logical isolation of business data and avoiding the creation, configuration, and maintenance of multiple storage pools. Furthermore, the unified storage pool allows for flexible resource allocation across different scenarios, breaking down existing resource reuse barriers. Worker nodes can autonomously determine the target logical space address to be processed based on the logical space bitmap and send requests to the management node for space management. The management node can dynamically allocate logical spaces based on the global bitmap, supporting on-demand resource allocation. This effectively avoids the resource idleness or uneven load issues caused by independent storage pools in the original Ceph, improving the flexibility of resource scheduling and overall utilization, ultimately meeting the efficient storage needs of diverse services. Attached Figure Description

[0011] 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.

[0012] Figure 1A schematic diagram of the specific hardware architecture on which the execution of a storage pool space management method provided in this application embodiment depends; Figure 2 A flowchart illustrating a method for managing storage pool space provided in an embodiment of this application; Figure 3A A schematic diagram of a physical storage pool provided in an embodiment of this application; Figure 3B A logical space bitmap provided for embodiments of this application; Figure 4 Another logical space bitmap provided for embodiments of this application; Figure 5A A schematic diagram illustrating the interaction between a working node and a management node, provided as an embodiment of this application; Figure 5B Another interactive diagram of a working node and a management node provided for an embodiment of this application; Figure 5C This is another interactive diagram of a working node and a management node provided in an embodiment of this application; Figure 6 A schematic diagram of a storage pool space management device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] 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, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0014] 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.

[0015] To more clearly illustrate the embodiments of this application, the technical terms used in the embodiments will be briefly introduced below: Object Storage Daemon (OSD): In distributed storage systems like Ceph, the OSD is the daemon responsible for actually storing the data. Each OSD manages a storage device, such as a hard disk or solid-state drive (SSD), performing data read and write operations. It is also responsible for data replication, recovery, and rebalancing to ensure data reliability and cluster load balancing. Furthermore, the OSD monitors its own health and exchanges heartbeat information with other OSDs to maintain cluster stability.

[0016] Metadata Server (MDS): In a distributed file system, the MDS is the server responsible for managing the file system's metadata. It stores the hierarchical structure of files and directories, permission information, file attributes, quota information, etc. The MDS also handles namespace management operations such as file and directory creation, deletion, and renaming, ensuring file system consistency, handling concurrent access and updates, and assisting in the recovery of file system metadata in the event of system failure.

[0017] The Ceph distributed storage system achieves dynamic data distribution through the Controlled Replication Under Scalable Hashing (CRUSH) algorithm, ensuring balanced data storage across cluster nodes. It employs multi-replica redundancy or erasure coding strategies to mitigate node failure risks and guarantee data reliability. Simultaneously, it leverages the BlueStore storage engine to directly manage raw devices, reducing the overhead of traditional file systems and effectively improving storage performance. Furthermore, the Ceph system adopts a separate architecture for the data pool and metadata pool, storing file data and metadata describing data attributes and locations separately, further optimizing data access efficiency.

[0018] However, existing Ceph distributed storage systems still face numerous technical challenges in actual deployment and operation: First, the deployment and maintenance costs of OSDs remain high. Each OSD requires independent configuration of hardware resources and software environment, and the risk of single point of failure is high. A single OSD failure may cause the corresponding data replica to become invalid, requiring immediate data reconstruction and recovery processes, increasing operational complexity. Simultaneously, to meet reliability requirements, the system needs to configure a large number of redundant OSD nodes, resulting in low hardware resource utilization and significant resource waste. Second, cluster scalability is poor, and node changes easily cause performance fluctuations. When adding or removing OSD nodes, the CRUSH algorithm triggers large-scale data migration within the cluster to rebalance data distribution. This process consumes significant network bandwidth and storage I / O resources, leading to concentrated I / O pressure. This not only causes a significant decline in cluster performance but, in extreme cases, may also cause service interruptions due to resource exhaustion, affecting business continuity. Finally, storage pool reusability is insufficient, limiting adaptability. In existing systems, different business scenarios or nodes often require independent configuration of dedicated storage pools, making it impossible for all nodes to share a unified storage pool. This design not only increases the management complexity of the storage pool, but also makes it difficult to reuse existing storage resources across scenarios, reduces the system's resource scheduling flexibility and overall utilization, and fails to meet the efficient storage needs of diverse businesses.

[0019] To address all or part of the aforementioned technical problems, this application provides a storage pool space management method. Addressing the high deployment and maintenance costs in Ceph due to the need for independent hardware and software configuration for each OSD and the presence of numerous redundant nodes, this method allows multiple nodes to share the same storage pool. This eliminates the need to build separate storage pools and supporting OSD environments for different nodes or services, reducing hardware resource investment and the workload of independent configuration and maintenance. Furthermore, the shared storage pool design reduces dependence on redundant nodes, lowering overall costs from both hardware deployment and software maintenance perspectives. For the management complexity and difficulty in resource reuse across scenarios caused by the need for independent configuration of dedicated storage pools for different business scenarios, the method introduces a logical space bitmap to abstractly manage the space within the storage pool. The logical space bitmap clearly indicates the logical space address corresponding to each node. Nodes in different business scenarios do not need dedicated storage pools; they only need to obtain and use their respective logical spaces through the bitmap. This achieves logical isolation of business data and avoids the creation, configuration, and maintenance of multiple storage pools. Simultaneously, the unification of the storage pool allows for flexible resource allocation across different scenarios, breaking down the original barriers to resource reuse. In addition, to address the shortcomings of insufficient resource scheduling flexibility and low overall utilization, the working nodes can autonomously determine the target logical space address to be processed based on the logical space bitmap and send a request to the management node to achieve space management. The management node can dynamically allocate logical space based on the global bitmap, supporting on-demand resource allocation. This effectively avoids the resource idleness or uneven load problems caused by independent storage pools in the original Ceph, improves the flexibility of resource scheduling and overall utilization, and ultimately meets the efficient storage needs of diverse businesses.

[0020] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0021] The specific application environment architecture or specific hardware architecture on which the execution of the storage pool space management method depends is described here.

[0022] like Figure 1 As shown, Figure 1 This is a schematic diagram of the specific hardware architecture on which the execution of a storage pool space management method provided in this application embodiment depends.

[0023] All nodes in a cluster file system share a logically unified storage pool.

[0024] The management node (NODE 0) contains the metadata management component MDS0, which includes a global space allocator (HugeBlock Alloc) and a metadata allocator (Meta-0 Alloc). The global space allocator manages the allocation of all available space; the metadata allocator manages the allocation of metadata space. The node data allocator (Data-0 Alloc) manages and allocates node data space.

[0025] Each worker node (such as NODE 1) contains a metadata management component, MDS1. MDS1 includes a metadata allocator (Meta-1 Alloc) used to allocate and manage the metadata space of worker node NODE 1. A node data allocator (Data-1Alloc) is used to allocate and manage the node data of worker node NODE 1.

[0026] Figure 2 A flowchart illustrating a storage pool space management method provided in this application embodiment is shown below. Figure 2 As shown, the method includes the following steps S201~S204: S201. Obtain the logical space bitmap of the storage pool through the worker node.

[0027] The logical space bitmap is used to indicate the logical space corresponding to multiple nodes. The storage pool is a shared storage pool among multiple nodes in the cluster file system.

[0028] This application divides the shared storage pool into multiple block spaces according to a preset spatial granularity, and saves the block spaces using a bitmap to obtain a logical space bitmap. For example... Figure 3A and 3B As shown, the physical storage pool is divided into numerous discrete block spaces, each with a 1GB unit. When constructing the logical storage pool, these 1GB blocks from the physical space are evenly distributed within it. The logical storage pool is divided into different intervals, such as 0-8PB, 8-16PB, etc., with each interval corresponding to one node.

[0029] like Figure 3B The logical space bitmap shown indicates that there is one management node and three worker nodes in the cluster file system. MDS0 is the metadata management component of the management node, and MDS1-3 are the metadata management components of the three worker nodes. The logical space bitmap shows that the cluster file system shares a logical storage pool of 32PB. In this logical storage pool, the 0-8PB range is allocated to the management node, the 8-16PB range is allocated to the worker node corresponding to MDS1, the 16-24PB range is allocated to the worker node corresponding to MDS2, and the 24-32PB range is allocated to the worker node corresponding to MDS3.

[0030] This application designs a system where two block allocators are bound to each worker node: a metadata allocator and a node data allocator. The metadata allocator manages the metadata space; the node data allocator manages the node data space.

[0031] Correspondingly, a global space allocator is bound to the management node. This global space allocator is used for the metadata space and node data space of the same management worker node. The global space allocator divides the shared storage pool into multiple discrete block spaces of preset sizes according to a preset space granularity, and saves these block spaces as a bitmap, resulting in the logical space bitmap of the storage pool. Each worker node's metadata allocator or node data allocator can request space from the global space allocator on the management node.

[0032] The bit structure used to describe the storage of related information in the logical space bitmap is defined as shown in Table 1: Table 1

[0033] In Table 1, Bit 7 indicates the status, with "1" representing occupied and "0" representing idle, used to identify the usage status of the corresponding storage unit; Bits 6-5 define the block length, with different combinations of two bits corresponding to different length specifications: "00" corresponds to 1024M, "01" to 256M, "10" to 512M, and "11" to 768M, thus determining the size of the storage block; Bit 4 is used to distinguish the storage type, with "1" representing metadata and "0" representing node data, specifying the type of stored content. Bits 3-0 indicate the instance ID to which the storage unit belongs; for metadata, it is rank_id; for node data, it is member_id, used to determine the specific instance to which the storage unit belongs.

[0034] S202. Based on the logical space bitmap, determine the target logical space address to be processed by the working node.

[0035] The target logical space address to be processed by the worker node refers to the logical space address requested by the worker node, or the logical space address that the worker node needs to reclaim.

[0036] In some embodiments, the worker node first determines its own block space offset address, and then determines the block space bitmap belonging to the worker node based on the block space offset address and the logical space bitmap. If the remaining node data space of the worker node is less than a first preset threshold, the first logical space address to be processed by the worker node is determined based on the block space bitmap.

[0037] The remaining node data space refers to the remaining space in the shared storage pool of worker nodes used to store node data; it represents the available space already allocated to worker nodes for storing node data. The first preset threshold is a pre-set minimum value for the available node data space; a value less than the first preset threshold indicates insufficient space on the worker node for storing node data. The first logical space address indicates the range of storage units allocated by the management node to the worker node for storing node data. After obtaining the first logical space address, the management node first determines all logical space addresses allocated to that worker node for storing node data, and then further determines the requested first logical space address from all logical space addresses. The management node then allocates the logical space corresponding to the first logical space address to the worker node, thereby ensuring that the worker node can completely store its node data.

[0038] like Figure 4 As shown, assuming that the 8-16PB range in the logical space bitmap of the logical storage pool is the range of the working node corresponding to MDS1, the working node corresponding to MDS1 determines the metadata space bitmap from the 8-16PB range based on the block space offset address of the metadata, as shown in the red-marked part of the figure.

[0039] Each worker node determines its own block space bitmap from the entire logical space bitmap based on its block space offset address. This avoids address overlap or blurred boundaries between different nodes, making the space allocation of each worker node clearer. A first preset threshold is set, and the remaining space of node data is monitored to detect the space shortage status of worker nodes in real time. If the remaining space of node data is less than the first preset threshold, it indicates that the space used by the worker node to store node data is critically low. Then, based on the block space bitmap of the worker node, the first logical space address to be processed is determined, that is, the address range of storage units that need to be requested from the management node to store node data is determined. This allows the management node to allocate the corresponding storage units to the worker node based on the first logical space address to store the node data, realizing dynamic allocation of resources on demand.

[0040] Combination Figure 1 When the node data allocator space of a worker node is insufficient, it requests available space from the global space allocator bound to the management node to store the node data.

[0041] If the remaining space for metadata on a worker node is less than a preset threshold, it indicates that the worker node is running out of space for storing metadata. The logical space address to be processed is then determined based on the worker node's block space bitmap. In other words, the address range of storage units to be requested from the management node for storing metadata is determined, so that the management node can allocate the corresponding storage units to the worker node based on the address range. This way, the worker node can have enough space to store metadata.

[0042] Combination Figure 1 When the metadata allocator space of a worker node is insufficient, it requests metadata space from the global space allocator bound to the management node for storing metadata.

[0043] By monitoring the relationship between the remaining metadata space and a preset threshold, the system can accurately detect when metadata storage space is running low, avoiding problems such as file system directory structure disorder and file attribute loss caused by insufficient metadata storage space. This provides an early warning mechanism for metadata storage, ensuring that space replenishment requests are initiated in a timely manner at critical nodes.

[0044] The logical space address to be processed is determined based on the block space bitmap of the working node, and this address range is dedicated to storing metadata. This enables on-demand location and dedicated use of funds, avoiding confusion between metadata and node data in space allocation. It ensures that the management node can accurately allocate storage units that match the metadata storage needs, satisfying the requirements of metadata for continuous storage location and efficient access, without occupying the storage space of node data. This achieves a reasonable division of metadata and node data storage resources.

[0045] S203. Generate a space management request based on the target logical space address through the working node.

[0046] Among them, space management requests are used to request the operation of the logical space of other nodes, or to request the reclamation of the free logical space of worker nodes.

[0047] In some embodiments, if the remaining metadata space of the working node is greater than a second preset threshold, the second logical space address to be processed by the working node is determined according to the block space bitmap of the working node.

[0048] The remaining metadata space for worker nodes refers to the remaining space in the shared storage pool used to store the metadata of worker nodes. The second preset threshold is a pre-set threshold for reclaiming metadata space; a value greater than the second preset threshold indicates that there is excess space on the worker node used to store metadata, which can be reclaimed. The second logical space address is used to request the management node to reclaim the range of storage units storing metadata from the worker node.

[0049] After determining its own block space bitmap from the entire logical space bitmap based on its block space offset address, the worker node checks if the remaining metadata space is greater than a second preset threshold. If so, it indicates that the worker node has surplus space for storing metadata. Then, based on the worker node's block space bitmap, it determines the second logical space address to be processed, i.e., it determines the address range of storage units that need to be requested from the management node for reclamation from the worker node. This allows the management node to reclaim the corresponding storage units from the worker node based on the second logical space address. This avoids the metadata storage risk caused by blind reclamation and ensures that only truly idle metadata storage units are reclaimed. At the same time, the clearly defined address range allows the management node to quickly locate and execute the reclamation operation, improving reclamation efficiency.

[0050] By reclaiming excess space and incorporating it back into the global resource pool of the storage pool, it can be used by other worker nodes that require metadata or node data storage. This breaks down resource occupancy barriers and improves the overall space utilization of the storage pool. The reclamation and redistribution of excess metadata space helps avoid the imbalance where some worker nodes occupy too many resources for a long time while other nodes are short of resources. Management nodes can flexibly allocate the reclaimed space to nodes in need, balancing the resource occupancy of each node and reducing system load tilt caused by uneven resource allocation. This improves the operating efficiency and stability of the entire cluster file system and ensures efficient storage for diverse businesses in scenarios with dynamic resource changes.

[0051] If the remaining metadata space of a worker node is greater than a second preset threshold, after determining the second logical space address to be reclaimed from the worker node, it is determined whether the second logical space address includes a reserved logical space address. A reserved logical space address is a logical space address of at least one pre-reserved block space, always used for metadata storage and not included in the reclamation mechanism. If the second logical space address does not include a reserved logical space address, it means that all logical spaces corresponding to the second logical space address support reclamation. In this case, a request containing the second logical space address is sent directly to the management node, so that the management node responds to the request and reclaims the storage unit corresponding to the second logical space address from the worker node.

[0052] The reserved logical space address is a pre-reserved superblock space for storing metadata. The superblock space refers to a specific storage area in the file system dedicated to storing the superblock and its backup data; it is a crucial part of ensuring proper file system mounting and data consistency. The superblock is the core metadata structure of the file system, used to record key information about the entire file system, such as file system size, total number of inodes, number of free blocks, and block size. This application allows for the pre-reservation of two superblock spaces.

[0053] The second logical space address does not include the reserved logical space address, meaning that directly reclaiming logical space from worker nodes will not affect their normal operation. Therefore, sending a request containing the second logical space address to the management node eliminates the need to generate an additional request, reducing unnecessary latency. Simultaneously, the clear address range division allows the management node to quickly locate and reclaim releasable storage units, improving resource reallocation response speed. This approach ensures that critical metadata space is unaffected by reclamation while maximizing the release of truly idle storage space, enabling these resources to be reused by other nodes in a timely manner.

[0054] If it is determined that the second logical space address contains a reserved logical space address, the reserved logical space address is first removed from the second logical space address to obtain the third logical space address. Then, a request containing the third logical space address is sent to the management node so that the management node responds to the request and reclaims the storage unit corresponding to the third logical space address from the worker node.

[0055] The second logical space address contains reserved logical space addresses, indicating that directly reclaiming the storage unit corresponding to the second logical space address would affect the normal operation of the worker nodes. To avoid adverse effects on the worker nodes, the reserved logical space addresses need to be removed from the second logical space address to generate a new third logical space address. The storage unit corresponding to the third logical space address is reclaimable. A space reclamation request is then generated based on the third logical space address and sent to the management node, enabling the management node to reclaim idle and safe storage units from the worker nodes based on the third logical space address.

[0056] By detecting that the second logical space address to be reclaimed contains a reserved logical space address, these critical addresses are first removed to obtain the third logical space address before the reclamation operation is performed. This effectively prevents the risk of mistakenly reclaiming critical metadata storage space, ensuring that the reserved logical space always remains available and providing a security guarantee for the continuous storage of metadata. By accurately removing unreclaimable reserved space, other idle metadata storage units can be reclaimed to the maximum extent, and these resources can be reintegrated into the shared storage pool for use by other nodes. This avoids the problem of large areas of space that cannot be reclaimed due to the existence of reserved logical space, improving the overall utilization rate of storage resources. This allows the system to flexibly respond to constantly changing storage needs while maintaining necessary safety margins, achieving an optimal balance between security and flexibility.

[0057] The above embodiments introduce a mechanism for determining reserved logical space addresses in the metadata space reclamation process, improving the security of the reclamation operation and the stability of the system. By determining whether the second logical space address to be reclaimed contains a reserved logical space address before reclamation, metadata loss or file system anomalies caused by mistaken reclamation of critical metadata space can be effectively prevented. The reserved logical space, as a secure area for metadata, remains always available, ensuring the continuity and reliability of metadata storage, and will not affect the core functions of the system even during frequent space reclamation and allocation.

[0058] S204. Send a space management request to the management node through the working node to request the management node to manage the logical space corresponding to the target logical space address.

[0059] like Figure 5A As shown, the worker node first obtains the logical space bitmap of the storage pool, then determines the target logical space address to be processed based on the logical space bitmap, and then generates a space management request based on the target logical space address and sends it to the management node. After receiving the space management request, the management node manages the logical space corresponding to the target logical space address.

[0060] Combination Figure 1 The management node is equipped with a metadata management component, MDS0, which manages the available space for all nodes in the cluster. Worker nodes request metadata (mds) space or node data (client) space from the management node.

[0061] As in the aforementioned embodiments, the space management request includes, but is not limited to: a request containing a first logical space address for requesting the allocation of a storage unit corresponding to the first logical space address; a request containing a second logical space address for requesting the reclamation of a storage unit corresponding to the second logical space address; and a request containing a third logical space address for requesting the reclamation of a storage unit corresponding to the third logical space address.

[0062] If a worker node sends a request containing a first logical space address to the management node, the management node responds by requesting the logical space corresponding to the first logical space address. Based on the aforementioned embodiments, the first logical space address is the range of storage units requested by the worker node from the management node for storing node data. The management node determines the corresponding logical space based on the first logical space address and allocates this space to the worker node, enabling the worker node to utilize this space to store node data.

[0063] like Figure 5BAs shown, the worker node first obtains the logical space bitmap of the storage pool, then determines the first logical space address it needs to request based on the logical space bitmap, and then generates a space management request based on the first logical space address and sends it to the management node. After receiving the space management request, the management node requests the logical space corresponding to the first logical space address, first updates the logical space bitmap of the storage pool based on the first logical space address, and then allocates the logical space corresponding to the first logical space address to the worker node.

[0064] To ensure the atomicity of bitmap updates, the logical space bitmap in this application is stored in a manner consisting of a bitmap file header, the bitmap itself, and a bitmap copy. This separation of the bitmap copy and file header allows worker nodes to efficiently calculate and modify the bitmap locally, only switching on the file header when necessary, thus reducing the overhead of cross-node coordination and synchronization.

[0065] Optionally, the worker node updates the logical space bitmap and / or the bitmap copy of the block space bitmap according to the first logical space address; and updates the logical space bitmap and / or the bitmap file header of the block space bitmap according to the first logical space address to complete the update of the logical space bitmap. The bitmap file header stores pointers to the block space locations, providing an index for fast location and access to the block space, reducing addressing overhead and improving system response speed. Centralized management of block space location pointers reduces latency for random access, making space allocation and reclamation operations more efficient.

[0066] When updating the logical space bitmap, the bitmap copy is updated first. Only after successful disk persistence is the bitmap file header updated. This improves the reliability and consistency of logical space bitmap management. Specifically, the existence of the bitmap copy provides redundancy protection for the bitmap file. Even if a node crashes or storage media fails during the update process, the bitmap state can be recovered from the copy, reducing the risk of damage to node data and metadata. Once the new bitmap content is persisted, it is converted to a valid version by updating the file header, thus avoiding bitmap version inconsistencies that might occur due to mid-process failures and ensuring the correctness of logical space allocation and reclamation.

[0067] If a worker node sends a request containing the address of the first logical space to the management node, the management node responds to the request by first determining at least one block space according to the first logical space address and a preset space granularity, and then allocating the at least one block space to the worker node.

[0068] At least one block space contains the storage unit corresponding to the first logical space address. The preset space granularity is a pre-set space size, such as 1G.

[0069] This can be understood as the management node allocating space for storing node data to worker nodes according to a preset space granularity as the smallest allocation unit. This simplifies the complexity of space management and enables the management node to efficiently and consistently handle various space requests. This fixed-granularity allocation method reduces fragmentation, improves storage utilization, and facilitates load balancing and resource scheduling within the system.

[0070] In the above embodiments, the fixed spatial granularity makes the resource allocation process more transparent and easier to monitor and manage. It also reduces the metadata update overhead caused by frequent small-granularity allocation. The management node can process space requests in batches, reducing communication and computing burdens and improving the overall performance of the system.

[0071] If a worker node sends a request containing a second logical space address to the management node, the management node responds to the request and reclaims the logical space corresponding to the second logical space address. Based on the aforementioned embodiments, the second logical space address is the range of storage units used for storing metadata that the worker node requests the management node to reclaim. The management node determines the logical space corresponding to the second logical space address based on the second logical space address, reclaims this space from the worker node to release idle space, and reintegrates the idle space into the shared storage pool for use by other nodes.

[0072] like Figure 5C As shown, the worker node first obtains the logical space bitmap of the storage pool, then determines the address of the second logical space that needs to be reclaimed based on the logical space bitmap, and then generates a space management request based on the second logical space address and sends it to the management node. After receiving the space management request, the management node first locates the logical space corresponding to the second logical space address, then updates the logical space bitmap of the storage pool based on the second logical space address, and finally reclaims the logical space corresponding to the second logical space address from the worker node.

[0073] Optionally, the worker node determines a fourth logical space address based on the second logical space address and a preset space granularity, wherein the range of the fourth logical space address is less than or equal to the range of the second logical space address. Then, the worker node sends a request containing the fourth logical space address to the management node, so that the management node responds to the request and reclaims the block space corresponding to the fourth logical space address.

[0074] This can be understood as the management node reclaiming free space from the worker nodes according to a preset space granularity as the smallest reclamation unit. Aligning the reclamation units to the preset space granularity avoids frequent reclamation operations on fragmented address spaces, reduces the number of metadata updates and communication overhead for the management node, and improves the overall system performance. By extending the reclamation scope to the granularity boundary, the integrity of the reclaimed block space is ensured, facilitating the efficient reuse of these blocks in subsequent allocations, reducing storage fragmentation, and increasing space utilization.

[0075] Combination Figure 1 When the remaining space inside the metadata allocator of the worker node exceeds the second preset threshold, the free block space of the preset size is returned to the global space allocator of the management node.

[0076] If a worker node sends a request containing the address of a third logical space to the management node, the management node responds to the request and reclaims the logical space corresponding to the third logical space. Based on the aforementioned embodiments, the third logical space address does not include the reserved logical space address, supporting normal reclamation. The management node determines the corresponding logical space based on the third logical space address and then reclaims this space from the worker nodes, preventing the risk of mistakenly reclaiming critical metadata storage space corresponding to the logical space address.

[0077] Similarly, worker nodes determine the logical space addresses to be reclaimed based on the third logical space address and a preset space granularity. The units of the logical space addresses to be reclaimed are less than or equal to the third logical space address and do not include reserved logical space addresses. Then, the worker nodes send a request to the management node containing the logical space addresses to be reclaimed, so that the management node responds to the request and reclaims free and safe block space from the worker nodes.

[0078] In summary, the storage pool space management method provided in this application is based on a multi-node shared unified storage pool. During allocation, block space is divided at a fixed granularity to avoid fragmentation. During reclamation, the address to be reclaimed is extended to the granular boundary to ensure the integrity of the reclaimed blocks. This reduces resource idleness caused by traditional independent storage pools and, by dynamically reclaiming excess metadata space, brings idle resources back into the global schedule, improving the overall utilization rate and cross-scenario reuse capability of the storage pool. In data management, a first preset threshold is used to monitor whether node data space is insufficient, and a second preset threshold is used to identify whether metadata space is excessive, achieving dynamic adaptation of node data and metadata storage. Simultaneously, logical space addresses are reserved to prevent accidental reclamation and ensure metadata security. The logical space bitmap adopts a storage mode of file header, bitmap, and replicas. During updates, the order of first writing the replica to disk and then updating the file header is followed to avoid data loss and version inconsistencies, providing reliable metadata support for space management. Before block space allocation, the target address is determined through the bitmap to ensure that the addresses of each node do not overlap, further guaranteeing the stability of data storage. A unified storage pool replaces the traditional multiple dedicated storage pools, reducing the complexity of independent configuration and maintenance. Worker nodes autonomously determine space requirements and initiate requests based on bitmaps and thresholds, while management nodes uniformly handle allocation and reclamation at the granular level, reducing cross-node coordination costs. At the same time, the preset space granularity can be adjusted according to business needs to adapt to different scale storage scenarios, enabling the system to flexibly respond to the high-efficiency storage needs of diverse businesses and improving the problems of high deployment and maintenance costs and rigid resource scheduling in traditional Ceph systems.

[0079] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0080] like Figure 6 As shown, embodiments of this application also provide a storage pool space management device, the device comprising: The acquisition module 601 is used to acquire the logical space bitmap of the storage pool through the working node. The logical space bitmap is used to indicate the logical space addresses corresponding to multiple nodes. The determination module 602 is used to determine the target logical space address to be processed by the working node based on the logical space bitmap. The request generation module 603 is used to generate a space management request based on the target logical space address through the working node; The sending module 604 is used to send a space management request to the management node through the working node, in order to request the management node to manage the logical space corresponding to the target logical space address.

[0081] As an optional implementation provided in this application, the determining module 602 is specifically used for: determining the block space offset address belonging to the working node through the working node; determining the block space bitmap of the working node according to the block space offset address and the logical space bitmap; and determining the first logical space address to be processed by the working node according to the block space bitmap when the remaining space of the node data of the working node is less than a first preset threshold; wherein, the first logical space address is used to indicate the range of storage units allocated by the management node to the working node to store the node data.

[0082] As an optional implementation provided in this application, the determining module 602, after determining the block space bitmap of the working node based on the block space offset address and the logical space bitmap, is further configured to: determine the second logical space address to be processed by the working node based on the block space bitmap when the remaining metadata space of the working node is greater than a second preset threshold; wherein the second logical space address is used to indicate the range of storage units that the management node reclaims from the working node to store metadata.

[0083] As an optional implementation provided in this application, the determining module 602, after determining the second logical space address to be processed by the working node according to the block space bitmap when the remaining metadata space of the working node is greater than the second preset threshold, is further configured to: determine whether the second logical space address contains a reserved logical space address, wherein the reserved logical space address is the logical space address of at least one pre-reserved block space; if the second logical space address does not contain a reserved logical space address, send a request containing the second logical space address to the management node so that the management node responds to the request to reclaim the storage unit corresponding to the second logical space address from the working node.

[0084] As an optional implementation provided in this application embodiment, the determining module 602, after determining whether the second logical space address of the logical space contains the target logical space address, is further configured to: if the second logical space address contains the reserved logical space address, remove the reserved logical space address from the second logical space address to obtain the third logical space address; send a request containing the third logical space address to the management node so that the management node responds to the request to reclaim the storage unit corresponding to the third logical space address from the working node.

[0085] As an optional implementation provided in this application embodiment, the sending module 604 is specifically used for: sending a request containing a first logical space address to the management node through the working node; and requesting the logical space corresponding to the first logical space address through the management node in response to the request containing the first logical space address.

[0086] As an optional implementation provided in this application, the device further includes an update module, configured to: update the bitmap copy of the logical space bitmap and / or block space bitmap according to the first logical space address through the working node; and update the bitmap file header of the logical space bitmap and / or block space bitmap according to the first logical space address through the working node, so as to complete the update of the logical space bitmap.

[0087] As an optional implementation provided in this application, the sending module 604 is specifically used to: send a request containing a first logical space address to the management node through the working node; and, in response to the request containing the first logical space address, determine at least one block space according to the first logical space address and a preset space granularity, and allocate at least one block space to the working node.

[0088] As an optional implementation provided in this application, the sending module 604 is specifically used to: determine a fourth logical space address by the working node based on the second logical space address and a preset space granularity, wherein the range of the fourth logical space address is less than or equal to the range of the second logical space address; and send a request containing the fourth logical space address to the management node by the working node, so that the management node responds to the request to reclaim the block space corresponding to the fourth logical space address.

[0089] For a description of the features in the embodiment corresponding to the storage pool space management device, please refer to the relevant description in the embodiment corresponding to the storage pool space management method, which will not be repeated here.

[0090] like Figure 7 As shown, embodiments of this application also provide an electronic device, including a memory 701 and a processor 702. The memory 701 stores a computer program, and the processor 702 is configured to run the computer program to perform the steps in any of the above-described embodiments of the storage pool space management method.

[0091] 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 embodiments of the storage pool space management method.

[0092] 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.

[0093] 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 storage pool space management method embodiments.

[0094] 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 storage pool space management method embodiments.

[0095] 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 each specific application, but such implementation should not be considered beyond the scope of this application.

[0096] The foregoing has provided a detailed description of a storage pool space management method and electronic device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for managing storage pool space, characterized in that, The method is applied to a clustered file system, which includes multiple nodes and a storage pool, wherein the multiple nodes share the storage pool, and the storage pool is used to store node data and metadata of the multiple nodes; the method includes: The logical space bitmap of the storage pool is obtained through the worker node, and the logical space bitmap is used to indicate the logical space address corresponding to the plurality of nodes; The target logical space address to be processed by the working node is determined by the working node based on the logical space bitmap. The working node generates a space management request based on the target logical space address; The working node sends the space management request to the management node, requesting the management node to manage the logical space corresponding to the target logical space address.

2. The method according to claim 1, characterized in that, The step of determining the target logical space address to be processed by the working node based on the logical space bitmap includes: The block space offset address belonging to the working node is determined by the working node; The block space bitmap of the working node is determined based on the block space offset address and the logical space bitmap. If the remaining space of node data of the working node is less than a first preset threshold, the first logical space address to be processed of the working node is determined according to the block space bitmap. The first logical space address is used to indicate the range of storage units that the management node allocates to the working node to store node data.

3. The method according to claim 2, characterized in that, After determining the block space bitmap of the working node based on the block space offset address and the logical space bitmap, the method further includes: If the remaining metadata space of the working node is greater than the second preset threshold, the second logical space address to be processed by the working node is determined according to the block space bitmap. The second logical space address is used to indicate the range of storage units that the management node reclaims from the worker node to store metadata.

4. The method according to claim 3, characterized in that, When the remaining metadata space of the working node is greater than a second preset threshold, after determining the second logical space address to be processed by the working node based on the block space bitmap, the method further includes: Determine whether the second logical space address contains a reserved logical space address, wherein the reserved logical space address is the logical space address of at least one block space that has been reserved in advance; If the second logical space address does not contain the reserved logical space address, a request containing the second logical space address is sent to the management node, so that the management node responds to the request and reclaims the storage unit corresponding to the second logical space address from the worker node.

5. The method according to claim 4, characterized in that, After determining whether the second logical space address contains a reserved logical space address, the method further includes: If the second logical space address contains the reserved logical space address, then the reserved logical space address is removed from the second logical space address to obtain the third logical space address; A request containing the third logical space address is sent to the management node, so that the management node responds to the request to reclaim the storage unit corresponding to the third logical space address from the worker node.

6. The method according to claim 2, characterized in that, The step of sending the space management request from the working node to the management node, requesting the management node to manage the logical space corresponding to the target logical space address, includes: The working node sends a request containing the first logical space address to the management node; The management node responds to a request containing the first logical space address and requests the logical space corresponding to the first logical space address.

7. The method according to claim 2, characterized in that, When the remaining node data space of the working node is less than a first preset threshold, after determining the first logical space address to be processed by the working node according to the block space bitmap, and before sending the space management request to the management node through the working node to request the management node to manage the logical space corresponding to the target logical space address, the method further includes: The working node updates the bitmap of the logical space and / or the bitmap copy of the block space bitmap according to the first logical space address; The working node updates the bitmap file header of the logical space bitmap and / or the block space bitmap according to the first logical space address to complete the update of the logical space bitmap.

8. The method according to claim 2, characterized in that, The step of sending the space management request from the working node to the management node, requesting the management node to manage the logical space corresponding to the target logical space address, includes: The working node sends a request containing the first logical space address to the management node; In response to a request containing the first logical space address, the management node determines at least one block space according to the first logical space address and a preset space granularity, and allocates the at least one block space to the working node.

9. The method according to claim 3, characterized in that, The step of sending the space management request from the working node to the management node, requesting the management node to manage the logical space corresponding to the target logical space address, includes: The working node determines the fourth logical space address based on the second logical space address and the preset space granularity, wherein the range of the fourth logical space address is less than or equal to the range of the second logical space address; The working node sends a request containing the fourth logical space address to the management node, so that the management node responds to the request to reclaim the block space corresponding to the fourth logical space address.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the storage pool space management method as described in any one of claims 1 to 9 when executing the computer program.

Images