A method and device for expanding a node of a storage system

Abstract

The application provides a node expansion method and device of a storage system. The multi-layer data structure of each original metadata node in the storage system is improved, so that each SST file deployed in each layer contains metadata of a same metadata shard file and a shard index field for the metadata shard file. Thus, after a new metadata node is added to the storage system, the shard index field contained in each SST file can be used to determine a to-be-split SST file in at least one layer below the highest layer of the original metadata node, and then, version information corresponding to a sub-data structure formed by the to-be-split SST file in the original metadata node can be directly migrated to version information of the new metadata node, without migrating a large amount of metadata, so that the metadata splitting efficiency is improved, network resources and hardware resources are saved, IO service interruption of the new metadata node is avoided, and the performance of the original metadata node is not affected.

Description

TECHNICAL FIELD

[0001] The present application mainly relates to the field of storage, more particularly to a node expansion method and device of a storage system. BACKGROUND

[0002] With the increasing data generated by Internet, Internet of Things and other applications, the capacity demand for distributed storage systems is increasing. When the remaining capacity of the storage system is insufficient, the storage nodes and metadata nodes of the storage system need to be expanded continuously to improve the performance of the storage system.

[0003] Among them, when the metadata node is expanded, a new metadata node is usually added in the storage system, part of the metadata of the original metadata node is split and read out, and is migrated and written into the new metadata node to realize the load balancing of each metadata node in the storage system. However, this metadata splitting and migration method consumes a large amount of time and hardware resources, and the new metadata node cannot respond to read services due to the lack of complete data. SUMMARY

[0004] To solve the above technical problems, on the one hand, the present application provides a node expansion method of a storage system, which comprises:

[0005] determining that the storage system responds to the metadata node expansion request to add a new metadata node; wherein each original metadata node in the storage system has a multi-layer data structure, each layer can deploy at least one SST file, and each SST file contains metadata of a same metadata shard file and a shard index field for the metadata shard file;

[0006] in response to a metadata splitting request, determining a to-be-split SST file in which a to-be-split metadata shard file is located according to the shard index field of each SST file possessed by the original metadata node;

[0007] migrating version information corresponding to a sub-data structure formed by the to-be-split SST file in the original metadata node to version information of the new metadata node; the sub-data structure contains SST files located at least one layer below the highest layer of the original metadata node.

[0008] Optionally, each SST file contains metadata of a same metadata shard file, which comprises:

[0009] in response to a file integration event for any metadata node in the storage system, determining a to-be-integrated SST file existing in the metadata node;

[0010] According to the shard file identifier corresponding to each metadata included in the to-be-integrated SST file, write the to-be-integrated metadata corresponding to the same shard file identifier in the to-be-integrated SST file into a newly created SST file, and write the shard file identifier into an identifier field of the newly created SST file.

[0011] The shard file identifier is used to identify different metadata shard files.

[0012] Optionally, the metadata is stored in a key-value pair manner, and the writing of the to-be-integrated metadata corresponding to the same shard file identifier in the to-be-integrated SST file into the newly created SST file according to the shard file identifier corresponding to each metadata included in the to-be-integrated SST file comprises:

[0013] sequentially writing the key values iteratively queried from the to-be-integrated SST file into a new SST file, the key values corresponding to a shard file identifier of a metadata shard file;

[0014] determining that the key value written into the new SST file this time is the last key value of the metadata shard file having the corresponding shard file identifier, and writing the shard file identifier into an identifier field of the new SST file;

[0015] creating a new SST file, and writing a next key value iteratively queried into the newly created SST file;

[0016] determining that the key value written into the new SST file this time is not the last key value of the metadata shard file having the corresponding shard file identifier, and continuing to write the next key value iteratively queried into the new SST file.

[0017] Optionally, the version information corresponding to the sub-data structure of the to-be-split SST file formed in the original metadata node is migrated into version information of the newly added metadata node, comprising:

[0018] extracting the version information of the to-be-split SST file existing in each layer below the highest layer in the original metadata node;

[0019] migrating the extracted version information to a corresponding layer of the newly added metadata node, and merging, by the newly added metadata node, the received version information with version information of the corresponding layer of the newly added metadata node;

[0020] updating, according to the migrated version information of the original metadata node, the version information of the multi-layer data structure currently possessed by the original metadata node.

[0021] Optionally, the extracting the version information of the to-be-split SST file existing in each layer below the highest layer of the original metadata node comprises:

[0022] determining that the highest layer of the original metadata node exists the to-be-split SST file, triggering the original metadata node to respond to a file integration event, and integrating the to-be-split SST file existing in the highest layer to the SST file created in the lower layer;

[0023] determining that the highest layer of the original metadata node does not exist the to-be-split SST file, and extracting the version information of the to-be-split SST file existing in each layer of the original metadata node.

[0024] In another aspect, the application further provides a node expansion method of a storage system, the method comprising:

[0025] receiving, by a new metadata node of a storage system, version information corresponding to a sub-data structure formed by a to-be-split SST file migrated from an original metadata node; wherein each original metadata node of the storage system has a multi-layer data structure, each layer of which can deploy at least one SST file, and each SST file contains metadata of a same metadata shard file and a shard index field for the metadata shard file; the to-be-split SST file refers to an SST file in which a to-be-split metadata shard file is located; and the sub-data structure contains SST files located in at least one layer below the highest layer of the original metadata node;

[0026] merging the received version information with version information of a corresponding layer of a multi-layer data structure of the new metadata node.

[0027] Optionally, the method further comprises:

[0028] obtaining a maximum sequence number of a split key value of a to-be-split metadata shard file in the original metadata node;

[0029] determining a global sequence number of the new metadata node by using the maximum sequence number of the split key value; the global sequence number of the new metadata node is greater than the maximum sequence number of the split key value;

[0030] in the process of merging the version information migrated from the original metadata node, prohibiting responding to a file integration event, and obtaining a data write request;

[0031] responding to the data write request according to the global sequence number;

[0032] determining that the merging operation on the version information is completed, and canceling the prohibition instruction for responding to the file integration event.

[0033] Optionally, the method further comprises:

[0034] obtaining a data reading request;

[0035] reading the requested data to be read in the newly added metadata node according to version information of a multi-layer data structure currently possessed;

[0036] determining that the data to be read is not successfully read, and forwarding the data reading request to the original metadata node corresponding to the data to be read, so that the original metadata node responds to the data reading request.

[0037] In another aspect, the application further provides a node expansion device of a storage system, which comprises:

[0038] a newly added metadata node determination module, configured to determine that a metadata node is newly added in a storage system in response to a metadata node expansion request; wherein each original metadata node in the storage system has a multi-layer data structure, and each layer can deploy at least one SST file, and each SST file contains metadata of a same metadata shard file and a shard index field for the metadata shard file;

[0039] a to-be-split SST file determination module, configured to determine, in response to a metadata splitting request, a to-be-split SST file in which a to-be-split metadata shard file is located according to the shard index field of each SST file possessed by the original metadata node;

[0040] a version information migration module, configured to migrate version information corresponding to a sub-data structure of the to-be-split SST file formed in the original metadata node to version information of the newly added metadata node; the sub-data structure contains SST files located at at least one layer below the highest layer of the original metadata node.

[0041] In another aspect, the application further provides a node expansion device of a storage system, which comprises:

[0042] a version information receiving module, configured to receive, by a newly added metadata node in a storage system, version information corresponding to a sub-data structure of a to-be-split SST file migrated by an original metadata node; wherein each original metadata node in the storage system has a multi-layer data structure, and each layer can deploy at least one SST file, and each SST file contains metadata of a same metadata shard file and a shard index field for the metadata shard file; the to-be-split SST file refers to an SST file in which a to-be-split metadata shard file is located;

[0043] a version information merging module, configured to merge the received version information with version information of a corresponding layer in a multi-layer data structure of the version information merging module.

[0044] In another aspect, the present application also provides a computer readable storage medium, on which a computer program can be stored, the computer program can be invoked and loaded by a processor to implement the node expansion method of the storage system.

[0045] It can be seen that the present application provides a node expansion method and device of a storage system, the multi-layer data structure of each original metadata node in the storage system is improved, so that each SST file deployed in each layer contains metadata of a same metadata shard file and a shard index field for the metadata shard file, so that after a metadata node is added to the storage system, the shard index field contained in each SST file can be used to determine the to-be-split SST file in at least one layer below the highest layer of the original metadata node in a metadata split request, and then the version information corresponding to the sub-data structure of the to-be-split SST file formed in the original metadata node is directly migrated to the version information of the added metadata node, without the need to migrate a large amount of metadata, the metadata split efficiency is improved, network resources and hardware resources are saved, and the IO service interruption of the added metadata node is avoided, and the performance of the original metadata node is not affected. BRIEF DESCRIPTION OF DRAWINGS

[0046] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or prior art description will be briefly introduced below. Obviously, the drawings in the following description are only embodiments of the present application, and for those skilled in the art, other drawings can be obtained without creative labor on the basis of the provided drawings.

[0047] Figure 1 A metadata migration process schematic diagram for a source levelDB in a levelDB expansion scenario;

[0048] Figure 2 An optional scenario schematic diagram suitable for the node expansion method of the storage system proposed in the present application;

[0049] Figure 3 A flowchart schematic diagram of an optional example of the node expansion method of the storage system proposed in the present application;

[0050] Figure 4 A flowchart schematic diagram of another optional example of the node expansion method of the storage system proposed in the present application;

[0051] Figure 5 A flowchart schematic diagram of another optional example of the node expansion method of the storage system proposed in the present application;

[0052] Figure 6A flowchart of another optional example of the node expansion method of the storage system proposed in the present application;

[0053] Figure 7 A flowchart of another optional example of the node expansion method of the storage system proposed in the present application;

[0054] Figure 8 A flowchart of another optional example of the node expansion method of the storage system proposed in the present application;

[0055] Figure 9 A flowchart of the levelDB expansion scenario suitable for the node expansion method of the storage system proposed in the present application;

[0056] Figure 10 A structural diagram of an optional example of the node expansion device of the storage system proposed in the present application

[0057] Figure 11 A structural diagram of another optional example of the node expansion device of the storage system proposed in the present application;

[0058] Figure 12 A structural diagram of another optional example of the node expansion device of the storage system proposed in the present application;

[0059] Figure 13 A structural diagram of an optional example of the storage system suitable for the node expansion method of the storage system proposed in the present application. DETAILED DESCRIPTION

[0060] The description in the background section is based on the example of taking the levelDB database as the metadata node of the distributed storage system, i.e., taking the levelDB as the metadata service and the shard as the smallest metadata shard unit, denoted as the metadata shard file, referring to the storage system node expansion scenario diagram shown in Figure 1 After determining the shard to be split (such as the gray area in Figure 1 ), an iterator of the shard is usually created from the source levelDB (such as Figure 1 shown as levelDB1), the metadata in the shard is iterated from the starting key of the metadata in the current shard to be split, the metadata in the shard is read (such as obtaining the key value to be split, Get(key, value)) and written (such as pushing the read key value, Put(key, value)) to the newly added levelDB (such as Figure 1The cross-node migration of such metadata is very time-consuming and consumes hardware resources, and also consumes a lot of network transmission resources. Moreover, before the metadata replication of all shards to be split is completed, the newly added levelDB cannot respond to IO (Input / Output) services (such as read / write services) due to the lack of complete data, resulting in a long interruption of IO services and affecting the efficiency of IO service processing. Figure 1

[0061] In addition, after the iteration of the above metadata is completed, the iterator usually needs to be destroyed, and the keys of the shards to be split in the source levelDB are deleted in sequence, that is, the old data in the original metadata node is deleted, which needs to generate a tombstone for each key. This not only consumes time, but also generates too many tombstones, which seriously affects the performance of the source levelDB.

[0062] To improve the above problems, the present application proposes a new metadata splitting method to support the node expansion method of a storage system, referring to Figure 2 The node expansion method of the storage system proposed in the present application only needs to split the version information of the sub-data structure of the metadata to be split in the original metadata node (such as the source levelDB) and migrate and merge it into the version information of the corresponding layer of the newly added metadata node (such as the newly added levelDB). This process does not need to migrate a large amount of metadata across nodes, saving network transmission resources and improving the efficiency of node expansion,

[0063] Moreover, since the migrated sub-data structure does not contain the highest layer, this process will not affect the read / write operations of the highest layer by IO services, that is, the read / write services and the metadata splitting process of the present application can be executed simultaneously and will not block user services. In addition, the above node expansion process will not generate garbage data, and no additional resources are needed to clean up garbage data. After the migration is completed, there will be no negative impact on the original metadata node.

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

[0065] Referring to Figure 3 ​Fig. 1 shows a flowchart of an optional example of the method for expanding the nodes of the storage system proposed in the present application, which can be described from the side of any original metadata node in the storage system, i.e. the method proposed in the present embodiment can be applied to the original metadata node, which can be a levelDB database or other type of device node, as the case can be. As shown in Fig. 1, the method for expanding the nodes of the storage system proposed in the present embodiment can include the following steps: Figure 3

[0066] Step S31, determining to add a metadata node in response to the request for expanding the metadata node of the storage system;

[0067] In the present embodiment, each SST file can contain the metadata of the same metadata shard file, i.e. each SST file in each metadata node in the storage system corresponds to the metadata of only one metadata shard file shard, which can be realized by a new compaction integration method, the implementation process of which can be referred to the description of the corresponding part of the method embodiment below, which will not be described in detail in the present embodiment.

[0068] In addition, in each SST file, the present application adds a field of shard, i.e. a shard index field for the metadata shard file shard, which is used to record which shard the SST file contains and which metadata index information, so as to query the required metadata shard file shard for subsequent processing, etc. The content of the shard index field contained in each improved SST file is not limited in the present application, as the case can be.

[0069] In some embodiments, the storage system can be a key-value storage system, and the multi-layer data structure of each metadata node contained therein can be an LSM Tree (Log Structured Merge Tree), i.e. a hierarchical, ordered, disk-oriented data structure, the highest layer L0 of which is located in the memory, and each layer below the highest layer is located in the disk. The types of memory and disk are not limited in the present application. In actual application, the modification increment of data or newly obtained business data is usually written into the memory first, and then batch-merged into the disk when the capacity reaches a certain level, such as using the way of merge sorting to merge and append the data in the memory to the tail of the disk to improve the write performance. The working principle of LSM Tree is not described in detail in the present application.

[0070] ​Step S32, in response to the metadata splitting request, determining the to-be-split SST file where the to-be-split metadata shard file is located according to the shard index field of each SST file possessed by the original metadata node;

[0071] After determining that the storage system adds a metadata node, in order to balance the load of the cluster, make the added metadata node process the business, and improve the performance of the storage system, it is necessary to split the metadata on the original metadata node and split part of the metadata to the new metadata node. To this end, the metadata splitting operation is performed on the original metadata node that needs to be split, so that the original metadata node can obtain the corresponding metadata splitting request.

[0072] Of course, the user can also use the management node in the storage system to send a corresponding metadata splitting request to one or more original metadata nodes to request splitting at least part of the metadata of the metadata node receiving the metadata splitting request to the added metadata node, and the like. The application does not limit the obtaining method of the metadata splitting request, which can be determined as appropriate.

[0073] In combination with the related description of the shard index field contained in the SST file above, the original metadata node in the storage system can respond to the obtained metadata splitting request, determine which SST file contains the to-be-split metadata shard file (i.e. the smallest unit of metadata shard) requested to be split out by querying the shard index field contained in each SST file possessed by the metadata node, and determine the SST file as the to-be-split SST file. The application does not limit the implementation method of determining the to-be-split shard / to-be-split SST file.

[0074] Step S33, migrating the version information corresponding to the sub-data structure of the to-be-split SST file formed in the original metadata node into the version information of the added metadata node; the sub-data structure contains the SST file located at least one layer below the highest layer of the original metadata node.

[0075] Since each metadata node in the storage system uses a multi-layer data structure to implement data management of the SST file, as shown in the following table, Figure 2 As shown in the table, the newly obtained data is first written into the highest layer L0 of the metadata node. For the multi-layer data structure, the lower the layer, the older the metadata stored in the SST file, i.e. the earlier the metadata node obtains the metadata. Different SST files at different levels can form a corresponding data structure, such as an LSM tree structure, record the version information Version of the data structure, and represent the SST files at each level contained in the metadata node.

[0076] Therefore, the original metadata node determines the to-be-split SST files according to the method described above, in order to reduce the amount of data transmission across nodes and improve the efficiency of metadata splitting. Since each SST file of the improved metadata node in the present case only contains one metadata shard file, each SST file can be used as a node. The original metadata node can split the version information of the sub-data structure (such as a sub-tree) formed by the determined to-be-split SST files from the metadata node and send it to the newly added metadata node, so that the newly added metadata node merges the version information of the multi-layer data structure possessed by itself with the received version information of the sub-data structure as the new version information (New Version) of the multi-layer data structure of the newly added metadata node, to support the newly added metadata node to normally process business.

[0077] Since the to-be-split SST files come from SST files in the multi-layer data structure possessed by the original metadata node, which are at least one layer below the highest layer, and do not include SST files in the highest layer L0, when the newly added metadata node merges the version information, it will not process the highest layer data, and will not cause conflicts with read-write business in the highest layer, ensuring that the newly added metadata node can normally process data write business during metadata splitting.

[0078] Moreover, between the original metadata node and the newly added metadata node, the present application only needs to migrate the version information of the sub-data structure formed by the to-be-split SST files. Compared with transmitting all to-be-split metadata contained in the to-be-split SST files, the data amount of the version information is very small, greatly shortening the time and hardware resources consumed by metadata splitting, and improving the efficiency of metadata splitting after node expansion.

[0079] Referring to Figure 4 Another optional example of the node expansion method of the storage system proposed in the present application is shown in the flowchart. The present embodiment can improve the data structure of any metadata node in the storage system and describe the improvement of the compaction process of the multi-layer data of the metadata node, as shown in Figure 4 The method can include:

[0080] Step S41, in response to a file compaction event of any metadata node in the storage system, determining the to-be-compacted SST files existing in the metadata node;

[0081] The multi-layer data structure of any metadata node in the storage system can be an LSM tree. After user data is written to the metadata node, the data is usually written in a Write-Ahead Logging (WAL) log mode, then written to a memory table (Memtable), and the Memtable is frozen after certain conditions are met, and a dump operation is performed to form an SST file. In this way, as the amount of data written to the metadata node increases, the number of dumps also increases, and the number of SST files also increases. However, too many SST files can increase the number of data query IOs, and the ranges of SST files in different layers can overlap, so these SST files need to be merged. This process can be referred to as compaction.

[0082] Therefore, the metadata node can scan the SST files in each layer, and when the preset integration condition (i.e., the condition for compaction of the SST files) is met, the metadata node can respond to the corresponding file integration event to determine that there are SST files to be integrated in the metadata node. In the embodiments of the present application, the integration condition, i.e., the condition for triggering the generation of the file integration event, can include but is not limited to: any SST file contains metadata belonging to different metadata shards, and such SST files are determined to be SST files to be integrated.

[0083] In step S42, according to the shard file identifiers corresponding to the metadata included in the SST files to be integrated, the metadata to be integrated corresponding to the same shard file identifier in the SST files to be integrated is written to a newly created SST file, and the shard file identifier is written to the identifier field of the corresponding newly created SST file.

[0084] In the embodiments of the present application, for the metadata shards included in the SST files, a corresponding shard file identifier can be configured, so that the metadata node can identify different metadata shards according to the shard file identifier. The shard file identifier can be a unique shard id, which can be stored in the identifier field of the SST file.

[0085] In order to combine the metadata belonging to the same metadata shard into one SST file, and to make the one SST file only contain metadata of the same metadata shard, the metadata node can identify the metadata to be integrated corresponding to the same shard file identifier from the multiple SST files to be integrated according to the shard file identifiers corresponding to the metadata included in the SST files to be integrated, write the metadata to be integrated corresponding to the same shard file identifier to a newly created SST file, so that the beginning and end of the SST file are aligned to the boundary of the shard corresponding to the shard file identifier, and write the shard file identifier to the identifier field of the newly created SST file, so as to identify the storage location of the shard in the future.

[0086] It should be noted that the improved compaction implementation process proposed in the present application includes but is not limited to the implementation method described above, and can be flexibly adjusted according to actual needs, which will not be described one by one in detail in the present application.

[0087] Step S43, obtaining a metadata splitting request for the newly added metadata node of the storage system;

[0088] In combination with the description of the technical solutions of the present application in the above embodiments, after the storage system responds to the metadata node expansion request and newly adds a metadata node, in order to balance the load, a data splitting request for at least one original metadata node can be generated. The data splitting request can be determined according to the load of each original metadata node in the storage system, and one or more metadata nodes with a high load ranking are selected as the to-be-split metadata node. A data splitting request for the newly added metadata node is sent to these metadata nodes, that is, the original metadata node is requested to split part of the metadata to the newly added metadata node, but it is not limited to the metadata splitting request obtaining method described in the present embodiment, which can be determined as appropriate.

[0089] Step S44, in response to the metadata splitting request, determining the to-be-split SST file in which the to-be-split metadata shard file is located according to the shard index field of each SST file possessed by the original metadata node;

[0090] In combination with the related description of the improved SST file integration processing method above, each SST file of each layer in each original metadata node in the storage system only contains the metadata of one metadata shard file, and the SST file is configured with a shard index field for the one metadata shard file. In this way, the metadata node parses the obtained metadata splitting request, and determines the to-be-split SST file in which the to-be-split metadata shard file is located according to the index information of the shard index field of each SST file, which is recorded as the to-be-split SST file.

[0091] Step S45, extracting version information of the to-be-split SST file existing in each layer below the highest layer in the original metadata node;

[0092] Step S46, migrating the extracted version information to the corresponding layer of the newly added metadata node, and merging the received version information with the version information of the corresponding layer of the newly added metadata node by the newly added metadata node;

[0093] In order to improve the metadata splitting efficiency, reduce the network resources consumed by data transmission, and ensure that the metadata splitting process does not interfere with the IO business of the newly added metadata node, the highest layer L0 of the original metadata node can be detected to determine whether there is a to-be-split SST file. The metadata in the to-be-split SST file can be merged into the SST file of the next layer according to the integration processing mode described above, so as to ensure that there is no to-be-split SST file in the highest layer L0.

[0094] Based on this, the step S45 can include: determining that the highest layer of the original metadata node has a to-be-split SST file, triggering the original metadata node to respond to the file integration event, integrating the to-be-split SST file in the highest layer to the SST file created in the lower layer. For the SST file integration process, please refer to the description of the corresponding part in the above. It is determined that the highest layer of the original metadata node does not have the to-be-split SST file, and the version information of the to-be-split SST file existing in each layer of the original metadata node is extracted.

[0095] Optionally, for the integration processing of the to-be-split SST file in the highest layer of the metadata node, a minor compaction integration mode can be used, that is, one or more small and adjacent dump SST files and 0 or more frozen memory tables are merged into a larger SST file. The specific implementation process of the minor compaction is not described in the present application, and the implementation mode is not limited to this compaction.

[0096] Therefore, in the metadata splitting processing, the to-be-split SST file in the second highest layer L1 of the original metadata node can be determined, the version information of the sub-data structure (such as LSM subtree) formed by the to-be-split SST files belonging to different layers is sent to the newly added metadata node, and the version information of each layer of the to-be-split SST file received by the newly added metadata node is merged into the version information of the SST file corresponding to the layer of the newly added metadata node itself, to form the new version information of the layer SST file.

[0097] The version information Version described above can represent which to-be-split SST files are contained in the corresponding layer of the multi-layer data structure and which metadata segment files are contained, and the content of the version information of the data structure and the extraction method thereof are not limited in the present application, and can be determined according to actual needs.

[0098] In the above process, the new metadata node can be prohibited from performing the compaction operation, that is, the new metadata node is prohibited from responding to the file integration event. The to-be-split SST files corresponding to the migration version information each only contain the same metadata shard file, so that the new metadata node obtains the to-be-split SST files without overlapping metadata through this way, and subsequent integration processing is not required.

[0099] In step S47, the version information of the multi-layer data structure currently possessed by the original metadata node is updated according to the migrated version information of the original metadata node.

[0100] For any original metadata node in the storage system, after the version information of the sub-data structure formed by all the to-be-split SST files determined by the original metadata node is migrated to the new metadata node according to the method described above, the version information of the original metadata node can be updated in time, that is, the sub-data structure is deleted from the original multi-layer data structure to obtain a new data structure and its version information. In this way, when reading metadata in the to-be-split SST file in the storage system, the corresponding data reading request can be sent to the new metadata node, and the requested to-be-read data can be queried by using the version information of the multi-layer data structure currently possessed by the new metadata node.

[0101] It can be seen that, in the node expansion process of the storage system, the original metadata node only needs to migrate the version information of the sub-data structure formed by the to-be-split SST file to the new metadata node, which greatly reduces the amount of data transmission, improves the node expansion efficiency, and saves network resources, compared with the processing method of migrating all the metadata in the to-be-split SST file to the new metadata node. Moreover, the original metadata node only needs to delete the migrated version information, and does not need to delete the metadata in the to-be-split SST file in sequence, so that the original metadata node is not negatively affected.

[0102] Reference Figure 5 The flowchart of another optional example of the node expansion method of the storage system proposed in the present application can be described, as shown in Figure 5 The method can include:

[0103] In step S51, in response to a file integration event of any metadata node in the storage system, a to-be-integrated SST file existing in the metadata node is determined.

[0104] For the implementation process of step S51, refer to the description of the corresponding part of the above embodiment, which will not be repeated here.

[0105] Step S52, the key values iteratively queried from the SST file to be integrated are written into the new SST file in sequence; the key values correspond to the shard file identifier of the metadata shard file to which the key values belong;

[0106] In the embodiment of the present application, the storage system can be a key-value storage system, and the metadata in each metadata node (such as levelDB) contained in the key-value storage system can be stored in the form of key-value pairs. Thus, referring to the flowchart of an optional implementation method of SST file integration of a metadata node in a storage system as shown in Figure 6 For any metadata node starting the compaction operation, the level participating in the compaction operation can be determined first, such as at least one level below the highest level in the multi-level data structure possessed by the metadata node, and then the SST file to be integrated participating in the compaction can be further determined from the plurality of SST files contained in the level, i.e., the SST file to be integrated. The determination process of the level participating in the compaction and the SST file to be integrated contained in the level can be determined according to the load condition of each original metadata node in the storage system, but is not limited thereto.

[0107] Then, as shown in Figure 6 The iterator for implementing the compaction operation can be created, i.e., the iterator of the metadata shard file shard is created, so that when the compaction operation is performed, the iteration can be started from the starting key corresponding to the shard id of the determined SST file to be integrated, and the iterated key is written into the newly created SST file in sequence. The creation method of the iterator and the working principle thereof are not described in detail in the present application.

[0108] Step S53, whether the key value written into the new SST file this time is the last key value of the metadata shard file having the corresponding shard file identifier is determined; if yes, step S54 is entered; if no, step S56 is performed;

[0109] Step S54, the shard file identifier is written into the identifier field of the new SST file;

[0110] Step S55, the new SST file is created, and the next key value iteratively queried is written into the newly created SST file;

[0111] Step S56, the next key value iteratively queried is continuously written into the new SST file.

[0112] Since the present application hopes that each SST file in the improved multi-level data structure only contains the metadata of one metadata shard file shard, as Figure 6As shown, in the key iteration process of the iterator on the metadata in the SST file to be integrated, it can be detected whether the iterated key reaches the boundary of the corresponding shard id. If the key of this iteration does not reach the boundary of the corresponding shard id, it means that the metadata key corresponding to the shard id has not been iterated completely, and the next key can be iterated and written into the new SST file in the above manner.

[0113] If it is detected that the metadata key of this iteration reaches the boundary of the corresponding shard id, it means that the metadata key belonging to a metadata shard file shard with the shard id has been iterated completely, and the complete metadata contained in the shard is written into the newly created SST file, and it is ensured that the newly created SST file only contains each metadata key corresponding to the shard id, and the shard id is written into the identification field of the new SST file, which is used for subsequent identification of the metadata shard file to be split. After that, if the determined SST file to be integrated has not been integrated completely, a new SST file can be created again, and the metadata key corresponding to the next shard id can be recorded in the new SST file according to the above method; when the determined SST file to be integrated is integrated completely, the compaction operation of the metadata node is ended.

[0114] In actual application, for each metadata node in the storage system, after a period of data writing processing, the compaction operation can be performed according to the method described above, so as to ensure that each SST file contained in each layer of the metadata node only contains the metadata of the same metadata shard file shard. It should be noted that for the new metadata node, when performing the merging processing of the version information of the child data structure from one or more original metadata nodes, the compaction operation can be temporarily prohibited, but the received SST file to be split corresponding to the version information only contains the metadata of one shard, and there is no SST file with overlapping metadata. After the metadata splitting of the new metadata node is completed, the compaction of the new metadata node is restored, and the new data obtained by the new metadata node can still be integrated according to the SST file integration processing method described above.

[0115] Referring to Figure 7 For another optional example of the node expansion method of the storage system proposed in the present application, the implementation process of the node expansion method of the storage system can be described from the side of the new metadata node of the storage system, as shown in Figure 7 The method can include:

[0116] Step S71, receiving version information corresponding to the sub-data structure formed by the to-be-split SST file of the original metadata node migration;

[0117] As to the obtaining process of the version information corresponding to the sub-data structure formed by the to-be-split SST file, reference can be made to the node expansion method of the storage system described above from the side of the original metadata node of the storage system, and the embodiment of the present application will not be described in detail here.

[0118] As can be known from the above analysis, since the metadata node of the storage system adopts the improved compaction to realize the integration processing of the metadata in the SST file thereof, so that each SST file only contains the metadata of one metadata shard file and is configured with the shard index field of the metadata shard file, such as shard id, and the to-be-split SST file refers to the SST file in which the to-be-split metadata shard file is located, therefore, each to-be-split SST file also only contains the metadata key of one shard, improving the query reliability of the sub-data structure (such as LSM sub-tree) formed by the to-be-split SST file.

[0119] Step S72, merging the received version information with the version information of the corresponding layer in the multi-layer data structure of the self.

[0120] Since the version information received by the newly-added metadata node can represent the information determined by the original metadata node, such as which layer of the multi-layer data structure the sub-data structure formed by the plurality of to-be-split SST files is located in, which shard file the to-be-split SST file contains, etc., and the data amount of the version information is very small relative to the data amount of the metadata contained by the to-be-split SST file, the network resources consumed by the transmission of the version information is greatly reduced, the metadata splitting speed is improved, and the node expansion efficiency is further improved.

[0121] In the case where the to-be-split SST file contains a plurality of SST files located in different layers, in order to ensure data consistency, the newly-added metadata node in the storage system can merge the version information corresponding to the to-be-split SST file of each layer with the version information of the layer possessed by the newly-added metadata node, thereby obtaining the new version information of the multi-layer data structure possessed by the newly-added metadata node, i.e., forming a new data structure, and the subsequent data reading service can be processed accordingly.

[0122] Since the version information received by the newly-added metadata node does not contain the highest layer data structure, it is said that the version information merging processing performed by the newly-added metadata node will not interfere with the processing of the data writing service, i.e., the IO service of the newly-added metadata node does not need to be interrupted.

[0123] Reference Figure 8As shown in the flowchart of another optional example of the node expansion method of the storage system proposed in the present application, the implementation process of the method can still be described from the side of the added metadata node of the storage system. It can be an optional detailed implementation manner of the node expansion method of the storage system described above, as shown in Figure 8 The method can include the following steps:

[0124] In step S81, the maximum sequence number of the split key value of the metadata shard file to be split in the original metadata node is obtained.

[0125] In step S82, the global sequence number of the added metadata node is determined by using the maximum sequence number of the split key value.

[0126] In actual applications, for a key-value storage system, each key can store multiple versions of values. In order to realize the orderliness of data reading, writing, and modification operations, each metadata node is usually configured with a sequence number field, such as a sequence number (global self-incrementing sequence number, a value of an unsigned 64-bit integer type), which is used to record a new sequence number generated by each modification operation of the metadata of the metadata node, such as the value obtained for each modification. The sequence number can be incremented by 1. Therefore, the larger the sequence number, the newer the corresponding key-value pair. The sequence number acquisition method of each key-value pair of each metadata node is not limited in the present application.

[0127] Based on the above analysis, in order to ensure data consistency and improve the reliability of business processing of the added metadata node, the global sequence number (such as the sequence number) of the added metadata node needs to be greater than the maximum sequence number of the split key value determined by the original metadata node. In this way, the added metadata node can read the latest metadata and data according to the global sequence number in response to a data reading request.

[0128] Therefore, after the storage system starts the metadata splitting operation of the original metadata node, referring to the levelDB expansion scenario as shown in Figure 9 The source levelDB can determine the maximum sequence number of the key in the shard to be split, that is, the maximum sequence number of the sequence number, as shown in Figure 9As shown, the number n of keys in each shard to be split can be counted and sent to the newly added metadata node levelDB to increase the sequence number of the new levelDB to be greater than the sequence number of the source levelDB, such as adding n to the sequence number of the new levelDB to obtain the global sequence number of the new levelDB.

[0129] For the levelDB expansion scenario of the key-value storage system as shown, Figure 9 For the levelDB expansion scenario of the key-value storage system as shown, for any source levelDB, after starting the metadata splitting operation, the source levelDB determines the to-be-split SST files of each layer in the LSM tree, and can detect whether there is a to-be-split SST file on the highest layer L0. If there is, the minor compaction file integration method can be used to perform hierarchical merging processing on the metadata in the to-be-split SST file on the highest layer L0 to determine that there is no to-be-split SST file on the highest layer L0. After splitting the version information Version of the sub-tree formed by the to-be-split SST files of L1 and the layers below L1 of the current source levelDB and migrating it to the newly added levelDB, no cross-node data migration is involved, the time consumption is very short, and no hardware resources are consumed.

[0130] After that, the newly added levelDB can merge the received version information into the corresponding layer of its own LSM tree to record these to-be-split SST files, and obtain the new version information Version of the LSM tree of the newly added levelDB. After that, the source levelDB can also clear the to-be-split SST files from its LSM tree and create a new version information Version.

[0131] Step S83, during the process of merging the version information migrated from the original metadata node, file integration events are prohibited to obtain data write requests;

[0132] Regarding the process of merging the version information migrated from the original metadata node by the newly added metadata node, reference can be made to the description of the corresponding part of the above embodiments, and the present embodiment will not be described in detail here.

[0133] In combination with the description of the corresponding part of the above embodiments, the present embodiment needs to merge each layer of to-be-split SST files of the original metadata node into the newly added metadata node at a time, and each to-be-split SST file only contains the metadata of one shard. The newly added metadata node can prohibit compaction, so as to ensure that there is no overlapping metadata in each layer of SST files. The present application does not limit the implementation manner of how the metadata node closes the compaction, which can be determined as appropriate.

[0134] Step S84, in response to the data write request, according to the global sequence number currently possessed by the newly added metadata node;

[0135] In the embodiments of the present application, for the multi-layer data structure of the metadata node, such as the LSM tree, the newly obtained data is usually written into the highest layer L0 of the LSM tree, and there is no conflict with the merging process of the version information from the original metadata node. Moreover, in order to ensure that the latest data can be read subsequently, when responding to the data write request, for the newly written key-value or new value of the existing key, the configured sequence number is greater than the maximum sequence number of the key in the to-be-split SST file, that is, in the newly added metadata node, the sequence number of the newly written sequence number will be greater than the sequence number from the original metadata node to be migrated, and the updating process of the sequence number of the newly added metadata node is not described in detail.

[0136] Based on this, in the case that the newly added metadata node obtains a data read request, the requested to-be-read data in the newly added metadata node can be read according to the version information of the currently possessed multi-layer data structure, it is determined that the to-be-read data is not successfully read, and the data read request is forwarded to the corresponding original metadata node, and the original metadata node responds to the data read request to meet the data read demand of the business. That is, as shown in Figure 9 For the data read request of the storage system, the data read request can be read in the newly added levelDB first, and if it is not read, the data read request is forwarded to the source levelDB for reading, so as to ensure that the read and write business are not blocked, and the data of the original metadata node and the newly added metadata node is consistent.

[0137] Step S85, determining to end the merging operation of the version information from the original metadata node, and canceling the prohibition instruction for responding to the file merging event.

[0138] After the merging of the split version information is completed according to the above description, the compaction of the newly added metadata node can be opened to realize the integration processing of the highest layer SST file in the metadata node, and the obtained data read request is no longer forwarded to other metadata nodes.

[0139] Referring to Figure 10 The structure diagram of an optional example of the node expansion device of the storage system proposed in the present application can be described from the side of the original metadata node of the storage system, as shown in Figure 10 The device can include:

[0140] The metadata node adding determining module 101 is configured to determine to add a metadata node in the storage system in response to a metadata node expansion request;

[0141] Each original metadata node in the storage system has a multi-layer data structure, and each layer can deploy at least one SST file. Each SST file contains metadata of a same metadata shard file and a shard index field of the metadata shard file.

[0142] The to-be-split SST file determining module 102 is configured to determine a to-be-split SST file in which a to-be-split metadata shard file is located according to the shard index field of each SST file possessed by the original metadata node in response to a metadata splitting request.

[0143] The version information migration module 103 is configured to migrate version information corresponding to a sub-data structure of the to-be-split SST file formed in the original metadata node into version information of the added metadata node. The sub-data structure includes an SST file located at at least one layer below the highest layer of the original metadata node.

[0144] Optionally, in order to ensure that each SST file contains metadata of a same metadata shard file, the above device can further include:

[0145] The to-be-integrated SST file determining module is configured to determine a to-be-integrated SST file existing in a metadata node in response to a file integration event of the metadata node.

[0146] The integration processing module is configured to write to-be-integrated metadata corresponding to a same shard file identifier in the to-be-integrated SST file into a newly created SST file according to the shard file identifier contained in each metadata, and write the shard file identifier into an identifier field of the newly created SST file. The shard file identifier is used to identify different metadata shard files.

[0147] In some embodiments, the above metadata is stored in a key-value pair manner. Based on this, the integration processing module can include:

[0148] The key-value iteration writing unit is configured to sequentially write key values iteratively queried from the to-be-integrated SST file into a new SST file. The key values correspond to a shard file identifier of a metadata shard file to which the key values belong.

[0149] The first determining unit is configured to determine that a key value written into the new SST file this time is a last key value of a metadata shard file having the corresponding shard file identifier, and write the shard file identifier into an identifier field of the new SST file.

[0150] The SST file creating unit is configured to create a new SST file and write the next key value obtained through the iterative query into the newly created SST file.

[0151] The second determining unit is configured to determine that the key value written into the new SST file is not the last key value of the metadata slice file corresponding to the slice file identifier, and continue to write the next key value obtained through the iterative query into the new SST file.

[0152] In some embodiments, the version information migration module 103 can include:

[0153] The version information extracting unit is configured to extract the version information of the to-be-split SST file existing in each layer below the highest layer in the original metadata node.

[0154] The version information migration unit is configured to migrate the extracted version information to the layer corresponding to the newly added metadata node, and merge the received version information with the version information of the layer corresponding to the newly added metadata node.

[0155] The version information updating unit is configured to update the version information of the multi-layer data structure currently possessed by the original metadata node according to the migrated version information.

[0156] Optionally, the version information extracting unit can include:

[0157] The file integrating unit is configured to determine that the to-be-split SST file exists in the highest layer of the original metadata node, trigger the original metadata node to respond to a file integration event, and integrate the to-be-split SST file existing in the highest layer into the SST file created in the lower layer.

[0158] The extracting unit is configured to determine that the to-be-split SST file does not exist in the highest layer of the original metadata node, and extract the version information of the to-be-split SST file existing in each layer of the original metadata node.

[0159] Reference Figure 11 The structure diagram of another optional example of the node expansion device of the storage system proposed in the present application can be described from the side of the newly added metadata node of the storage system, as shown in Figure 11 The device can include:

[0160] The version information receiving module 111 is configured to receive, by the newly added metadata node of the storage system, the version information corresponding to the sub-data structure formed by the to-be-split SST file migrated by the original metadata node.

[0161] Each of the original metadata nodes in the storage system has a multi-layer data structure, each layer of which can deploy at least one SST file, and each SST file contains metadata of a same metadata shard file and a shard index field for the metadata shard file; the to-be-split SST file refers to an SST file in which a to-be-split metadata shard file is located;

[0162] The version information merging module 112 is configured to merge the received version information with version information of a corresponding layer in the multi-layer data structure of the device.

[0163] In some embodiments, as shown in Figure 12 The device can further include:

[0164] The maximum sequence number obtaining module 113 is configured to obtain a maximum sequence number of a split key value of a to-be-split metadata shard file in the original metadata node.

[0165] The global sequence number determining module 114 is configured to determine a global sequence number of a newly added metadata node by using the maximum sequence number of the split key value; the global sequence number of the newly added metadata node is greater than the maximum sequence number of the split key value.

[0166] The file integration event prohibition response module 115 is configured to prohibit responding to a file integration event in the process of merging the version information migrated from the original metadata node.

[0167] The data write request obtaining module 116 is configured to obtain a data write request.

[0168] The data write request response module 117 is configured to respond to the data write request according to the global sequence number.

[0169] The file integration event recovery response module 118 is configured to determine to end the merging operation on the version information and cancel the prohibition instruction for responding to a file integration event.

[0170] It should be noted that the various modules, units, etc. in the above device embodiments can be stored in the memory as program modules, and the processor executes the above program modules stored in the memory to achieve the corresponding functions. For the functions of the various program modules and their combinations, and the technical effects achieved, reference can be made to the descriptions of the corresponding parts of the above method embodiments, and the present embodiment will not be described again.

[0171] The present application also provides a computer readable storage medium, which can store a computer program, the computer program can be called and loaded by a processor to implement the steps of the node expansion method of the storage system described in the above embodiments.

[0172] ReferenceFigure 13 , the storage system can include a plurality of metadata nodes, each of which can be a computer device with a multi-layer data structure, such as a database server such as levelDB, or a terminal device with certain data processing capabilities, such as a desktop computer, a robot, a smart terminal in various fields, etc. Figure 13 The node device of the storage system shown is only an example and should not limit the function and use range of the embodiments of the present application.

[0173] In the embodiments of the present application, each of the above metadata nodes can be used to implement the node expansion method of the storage system proposed in the present application, and the implementation process can refer to the description of the corresponding part of the above embodiments, which will not be described in detail in the embodiments of the present application.

[0174] Optionally, in order to implement the node expansion method of the storage system proposed in the present application, the metadata node can be configured with at least one memory, processor, etc. The memory can be used to store the program for implementing the node expansion method of the storage system proposed in the present application, and the processor can load and execute the program to implement the node expansion method of the storage system proposed in the present application.

[0175] In actual application, the above-mentioned memory can include at least one memory, disk, etc., such as at least one disk storage device or other volatile solid-state storage device, etc.; the processor can include a central processing unit (CPU), an application-specific integrated circuit (ASIC), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a ready-to-program gate array (FPGA) or other programmable logic device, etc. The present application does not limit the device composition structure of the metadata node, which can be determined as appropriate.

[0176] It should be understood that, Figure 13 The structure of the storage system shown does not constitute a limitation on the storage system in the embodiments of the present application. In actual application, the storage system can include more devices than Figure 13 shown, such as management nodes, monitoring nodes, etc., for implementing data management, monitoring, etc. of each metadata node in the storage system, which can be determined according to actual conditions, and will not be enumerated one by one in the present application.

[0177] Finally, it is to be understood that the singular forms "a", "an", and "the" include plural referents unless the context clearly dictates otherwise. Typically, terms "comprising" and "containing" are synonymous with "including" and "comprising", respectively, and are inclusive or open-ended and do not exclude additional, unrecited elements or method steps. Elements defined by the recitation of two or more means, for performing the same function, are not mutually exclusive, but are inclusive, unless expressly stated otherwise. It is to be understood that the terms "including", "comprising", "consisting" and "consisting essentially of" are not mutually exclusive, but are inclusive or open-ended and do not exclude additional, unrecited elements or method steps, unless the context clearly dictates otherwise.

[0178] In the description of the embodiments of the present application, unless otherwise defined, " / " means or, for example, A / B can represent A or B; "and / or" in the present document is only a description of the relationship between the associated objects, which means that there can be three relationships, for example, A and / or B, which means that there are three cases of A alone, A and B together, and B alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0179] The terms such as "first", "second" and the like used in the present application are only for the purpose of description, and are used to distinguish one operation, unit or module from another operation, unit or module, without necessarily requiring or implying any such actual relationship or order between the units, operations or modules. And it cannot be understood as indicating or implying the relative importance or implicitly indicating the number of the indicated technical features, so the features with "first", "second" can explicitly or implicitly include one or more features.

[0180] In addition, the embodiments in the specification are described in a progressive or parallel manner, and each embodiment focuses on the difference from other embodiments, and the same or similar parts between the embodiments can be referred to each other. For the device, storage system and metadata node disclosed by the embodiments, since it corresponds to the method disclosed by the embodiments, the description is relatively simple, and the related parts can be referred to the method part.

[0181] The above description of the disclosed embodiments enables a person skilled in the art to implement or use the present application. Various modifications to the embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for expanding the capacity of a storage system's nodes, the method comprising: The storage system responds to a metadata node expansion request by adding a new metadata node; wherein, each existing metadata node in the storage system has a multi-layer data structure, each layer can deploy at least one SST file, and each SST file contains metadata of the same metadata shard file and a shard index field for that metadata shard file. In response to the metadata splitting request, the SST file to be split is determined based on the sharding index field of each SST file in the original metadata node; The version information corresponding to the sub-data structure formed by the SST file to be split in the original metadata node is migrated to the version information of the newly added metadata node; the sub-data structure contains SST files located at least one layer below the highest layer of the original metadata node.

2. The method according to claim 1, wherein each SST file contains metadata of the same metadata fragment file, including: In response to a file consolidation event for any metadata node in the storage system, determine the SST files to be consolidated that exist on that metadata node; Based on the fragment file identifiers corresponding to the metadata contained in the SST file to be integrated, the metadata to be integrated corresponding to the same fragment file identifier in the SST file to be integrated is written into a newly created SST file, and the fragment file identifier is written into the identifier field of the corresponding newly created SST file. The fragment file identifier is used to identify different metadata fragment files.

3. The method according to claim 2, wherein the metadata is stored in key-value pairs, and the step of writing the metadata corresponding to the same fragment file identifier in the SST file to be integrated into a newly created SST file based on the fragment file identifier corresponding to each metadata contained in the SST file to be integrated includes: Write the key values ​​obtained from the iterative query of the SST file to be integrated into a new SST file in sequence; The key value corresponds to the fragment file identifier of the metadata fragment file to which it belongs; Determine that the key value written to the new SST file this time is the last key value of the metadata fragment file with the corresponding fragment file identifier, and write the fragment file identifier into the identifier field of the new SST file; Create a new SST file and write the next key value obtained from the iterative query into the newly created SST file; If the key value written to the new SST file is determined to be not the last key value of the metadata shard file with the corresponding shard file identifier, the next key value found in the iterative query will be written to the new SST file.

4. The method according to claim 1, wherein migrating the version information corresponding to the sub-data structure formed in the original metadata node of the SST file to be split to the version information of the newly added metadata node includes: Extract the version information of the SST file to be split from each layer below the highest level of the original metadata node; The extracted version information is migrated to the corresponding layer of the newly added metadata node, and the newly added metadata node merges the received version information with the version information of its own corresponding layer. Based on the version information migrated from the original metadata node, update the version information of the multi-layer data structure currently possessed by the original metadata node.

5. The method according to claim 4, wherein extracting the version information of the SST file to be split from each layer below the highest level of the original metadata node includes: If it is determined that there is an SST file to be split at the highest level of the original metadata node, the original metadata node is triggered to respond to the file integration event, and the SST file to be split at the highest level is integrated into the SST file created at the lower level. If the highest level of the original metadata node does not contain the SST file to be split, extract the version information of the SST file to be split that exists in each level of the original metadata node.

6. A method for expanding the capacity of a storage system node, the method comprising: A new metadata node in the storage system receives version information corresponding to the sub-data structure formed by the SST file to be split from the original metadata node. Each original metadata node in the storage system has a multi-layered data structure, with each layer capable of deploying at least one SST file. Each SST file contains metadata for the same metadata shard file and a shard index field for that metadata shard file. The SST file to be split refers to the SST file containing the metadata shard file to be split. The sub-data structure contains SST files located at least one layer below the highest layer of the original metadata node. The received version information is merged with the version information of the corresponding layer in its own multi-layer data structure.

7. The method according to claim 6, further comprising: Obtain the maximum sequence number of the split key value of the metadata shard file to be split in the original metadata node; The global sequence number of the newly added metadata node is determined using the maximum sequence number of the split key value. The global sequence number of the newly added metadata node is greater than the maximum sequence number of the split key value; During the process of merging the version information migrated from the original metadata node, it is prohibited to respond to file integration events and obtain data write requests; Respond to the data write request based on the global sequence number; Confirm the end of the merge operation for the version information and cancel the prohibition command for the response file merge event.

8. The method according to claim 6, further comprising: Obtain a data read request; Based on the version information of the existing multi-layer data structure, read the data to be read requested in the newly added metadata node; If it is determined that the data to be read was not successfully read, the data read request is forwarded to the corresponding original metadata node, which then responds to the data read request.

9. A node expansion device for a storage system, the device comprising: The newly added metadata node determination module is used to determine the addition of metadata nodes in response to the metadata node expansion request of the storage system; wherein, each existing metadata node in the storage system has a multi-layer data structure, each layer can deploy at least one SST file, and each SST file contains the metadata of the same metadata shard file and the shard index field for the metadata shard file. The module for determining the SST file to be split is used to respond to the metadata splitting request and determine the SST file to be split, which contains the metadata shard file to be split, based on the shard index field of each SST file in the original metadata node. The version information migration module is used to migrate the version information corresponding to the sub-data structure formed by the SST file to be split in the original metadata node to the version information of the newly added metadata node; the sub-data structure includes SST files located at least one layer below the highest layer of the original metadata node.

10. A node expansion device for a storage system, the device comprising: The version information receiving module is used to receive version information corresponding to the sub-data structure formed by the SST file to be split from the original metadata node when a new metadata node is added in the storage system. Each original metadata node in the storage system has a multi-layer data structure, and each layer can deploy at least one SST file. Each SST file contains metadata of the same metadata shard file and a shard index field for that metadata shard file. The SST file to be split refers to the SST file containing the metadata shard file to be split. The version information merging module is used to merge the received version information with the version information of the corresponding layer in its own multi-layer data structure.

Images