A storage resource adaptive scheduling method and system

Abstract

The application relates to the technical field of storage resource management, and discloses a storage resource adaptive scheduling method and system, which comprises the following steps: acquiring request state data and medium state data, performing time window alignment processing on the request state data and the medium state data to obtain storage scheduling data, performing pressure wear correlation identification on the storage scheduling data to obtain pressure wear risk features, performing node health mapping according to the pressure wear risk features to obtain node health scores, generating a request distribution matrix according to the node health scores and the storage scheduling data, performing service bearing verification and target node selection according to the request distribution matrix to obtain a target storage node, and mapping a preset storage routing table according to the target storage node and the request distribution matrix to generate a storage scheduling instruction. The method can realize adaptive scheduling of storage resources under high-concurrency read-write services.

Description

Technical Field

[0001] This invention relates to the field of storage resource management technology, and in particular to a storage resource adaptive scheduling method and system. Background Technology

[0002] Currently, as the data read / write scale of business systems continues to increase, storage clusters need to distribute concurrent read / write requests across multiple storage nodes to ensure that different types of data can be written to the corresponding storage media. In industrial data storage scenarios, high-priority read / write requests typically have strong timeliness requirements, and the remaining capacity of storage nodes, queue status, and performance degradation caused by media wear directly affect the response results after request dispatch.

[0003] In a current technology, storage resource scheduling typically selects target storage nodes based on remaining capacity or a fixed load threshold. When a storage node has a large amount of available space, the scheduling process tends to allocate new read / write requests to that node. However, remaining capacity only reflects storage space occupancy and is insufficient to characterize the performance degradation caused by internal garbage collection (GC) and write amplification after prolonged read / write operations. It also fails to dynamically reflect the actual handling capacity of a storage node after high-concurrency requests arrive. For storage nodes that have experienced accumulated media wear or increased queue pressure, scheduling solely based on remaining capacity can easily lead to high-priority read / write requests being dispatched to storage nodes with insufficient capacity.

[0004] Existing technologies suffer from the problem of difficulty in accurately identifying the storage node's capacity under high-concurrency read / write operations. Summary of the Invention

[0005] This invention provides a storage resource adaptive scheduling method and system to solve the problem in the prior art that it is difficult to accurately identify the storage node's capacity under high-concurrency read and write services.

[0006] Firstly, in order to solve the above-mentioned technical problems, the present invention provides a storage resource adaptive scheduling method, comprising: Obtain request status data and media status data of high-concurrency read and write services in the storage cluster, and perform time window alignment processing on the request status data and the media status data to obtain storage scheduling data; The storage scheduling data is input into a pre-trained random forest risk assessment model to identify pressure wear associations, thereby obtaining pressure wear risk features. Based on the pressure wear risk features, node health is mapped to obtain node health scores. Based on the node health score and the storage scheduling data, resource acceptance is filtered to obtain candidate storage nodes. Based on the candidate storage nodes and the storage scheduling data, request acceptance mapping is performed to obtain a request allocation matrix. The service carrying verification is performed based on the request allocation matrix to obtain the node carrying result. The target node is selected based on the node carrying result to obtain the target storage node. Based on the target storage node and the requested allocation matrix mapping to a preset storage routing table, a storage scheduling instruction is generated.

[0007] In a second aspect, the present invention provides a storage resource adaptive scheduling system, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described above.

[0008] Compared with the prior art, the present invention has the following beneficial effects: (1) This invention obtains the request status data and media status data of high-concurrency read and write services in the storage cluster, and performs time window alignment processing on the request status data and the media status data to obtain storage scheduling data. This enables the storage scheduling process to simultaneously perceive the request pressure on the service side and the operating status on the media side, avoiding the one-sided problem of state judgment caused by simply selecting nodes based on the remaining capacity, and providing a unified data foundation for subsequent resource acceptance and screening.

[0009] (2) The present invention inputs storage scheduling data into a pre-trained random forest risk assessment model to identify pressure wear association, obtains pressure wear risk features, and performs node health mapping based on the pressure wear risk features to obtain node health scores, so that the read and write pressure and media wear status of storage nodes can be associated and characterized, thereby more accurately distinguishing between nodes that can handle the load and nodes with insufficient handling capacity, and reducing the situation where high-priority read and write requests are dispatched to sub-healthy storage nodes.

[0010] (3) The present invention obtains candidate storage nodes by screening resource acceptance based on node health scores and storage scheduling data, and performs business acceptance verification and target node selection by combining the request allocation matrix. Then, storage scheduling instructions are generated based on the target storage node mapping to the preset storage routing table, so that the request dispatch process of high-concurrency read and write services can match the actual acceptance status of storage nodes, thereby improving the availability and continuity of storage resource scheduling results. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of a storage resource adaptive scheduling method provided in the first embodiment of the present invention; Figure 2 This is a heatmap of the request allocation matrix for an adaptive scheduling method for storage resources provided in the first embodiment of the present invention. Detailed Implementation

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

[0013] Reference Figure 1 The first embodiment of the present invention provides a storage resource adaptive scheduling method, comprising the following steps: S1, obtain the request status data and media status data of high-concurrency read and write services in the storage cluster, and perform time window alignment processing on the request status data and the media status data to obtain storage scheduling data; S2, input the storage scheduling data into a pre-trained random forest risk assessment model to identify pressure wear associations, obtain pressure wear risk features, and perform node health mapping based on the pressure wear risk features to obtain node health scores; S3, perform resource acceptance screening based on the node health score and the storage scheduling data to obtain candidate storage nodes, and perform request acceptance mapping based on the candidate storage nodes and the storage scheduling data to obtain a request allocation matrix; S4. Perform service carrying verification based on the request allocation matrix to obtain node carrying results, and select target nodes based on the node carrying results to obtain target storage nodes; S5, Generate storage scheduling instructions based on the target storage node and the preset storage routing table mapped by the request allocation matrix.

[0014] In step S1, request status data and media status data of high-concurrency read / write services in the storage cluster are obtained. Time-window alignment processing is performed on the request status data and the media status data to obtain storage scheduling data, including: The request status data is windowed according to a preset sampling time window to obtain request window data; The medium state data is windowed according to the preset sampling time window to obtain medium window data; The request window data and the media window data are associated with the storage node identifier to obtain storage scheduling data.

[0015] In one implementation, the request status data is a set of request records recorded by the storage gateway during high-concurrency read / write operations. Each request record in the request status data includes a request identifier, a storage node identifier, a collection time, a request priority, a read / write type, a data block size, and a queuing time. The request identifier is generated by the storage gateway when it receives a read / write request; the storage node identifier is read by the storage gateway according to the logical volume mapping relationship corresponding to the current request; the collection time is recorded by the storage gateway's local clock; the request priority is read from the priority field carried when the service submits the request; the read / write type is either a read request flag or a write request flag; the data block size is read from the data length field in the request header; and the queuing time is obtained by subtracting the time when the request enters the sending queue from the time the request leaves the sending queue.

[0016] The media status data is a set of node media records recorded by the storage controller during the operation of the storage node. Each node media record in the media status data includes the storage node identifier, acquisition time, remaining capacity, erase / write count, number of bad blocks, spare block ratio, device health value, and node queue status. The remaining capacity is obtained by the storage controller reading the unallocated capacity in the logical address space; the erase / write count is obtained by the storage controller reading the media block erase / write counter; the number of bad blocks is obtained by the storage controller reading the bad block management table; the spare block ratio is obtained by dividing the number of used spare blocks by the total number of spare blocks; the device health value is obtained by the storage controller reading the media health register; and the node queue status is obtained by the storage controller reading the number of pending requests in the node's input / output queue.

[0017] It should be noted that the preset sampling window is set to 1 second. The preset sampling window is determined through offline playback, specifically by reading request status data and media status data for seven consecutive days, using 0.5 seconds, 1 second, and 2 seconds as candidate windows for aggregation, and calculating the coefficient of variation of the total request volume and the media status record missing rate within each candidate window. When the candidate window is 0.5 seconds, the coefficient of variation of the total request volume is 0.31, and the media status record missing rate is 0.2%; when the candidate window is 1 second, the coefficient of variation of the total request volume is 0.18, and the media status record missing rate is 0.4%; when the candidate window is 2 seconds, the coefficient of variation of the total request volume is 0.16, and the media status record missing rate is 1.5%. In this embodiment, the shortest candidate window with a coefficient of variation of less than 0.20 for the total request volume and a media status record missing rate of less than 0.5% is selected, and the preset sampling window is set to 1 second.

[0018] During window aggregation, this embodiment divides the request status data into corresponding preset sampling time windows according to the collection time, and aggregates the request records within the same preset sampling time window according to the storage node identifier. For request records of the same storage node within the same preset sampling time window, the total number of requests, read requests, write requests, total number of data blocks, and average queuing time are counted, and the highest request priority is read to form the request window data. The highest request priority is obtained by comparing the request priorities of all request records within the same preset sampling time window.

[0019] When performing window aggregation of media status data, this embodiment divides the media status data into corresponding preset sampling time windows according to the acquisition time, and aggregates the node media records within the same preset sampling time window according to the storage node identifier. If multiple node media records exist for the same storage node within the same preset sampling time window, the node media record whose acquisition time is closest to the end time of that preset sampling time window is read to form the media window data. If no node media records exist for the same storage node within a certain preset sampling time window, this embodiment does not generate media window data for that storage node within that preset sampling time window.

[0020] This embodiment associates the request window data and the media window data based on the storage node identifier. During the association process, the storage node identifier and time window start time are read from the request window data, and media window data with the same storage node identifier and time window start time are retrieved. When a corresponding media window data is found, the request window data and the media window data are merged into a single storage scheduling record; when no corresponding media window data is found, no corresponding storage scheduling record is generated. All storage scheduling records are arranged according to the time window start time and storage node identifier to obtain the storage scheduling data.

[0021] For example, with a preset sampling window of 1 second, a storage node generates 3200 read requests and 800 write requests within a preset sampling window. The total data block size is 640 megabytes, the average queuing time is 3 milliseconds, and the highest request priority is 9. Therefore, the request window data record for this preset sampling window contains 4000 requests, 3200 read requests, 800 write requests, 640 megabytes of data blocks, an average queuing time of 3 milliseconds, and a highest request priority of 9. Within the same preset sampling window, the storage node's media window data record shows a remaining capacity of 2.4 terabytes, 1800 erase / write cycles, 12 bad blocks, a spare block ratio of 0.18, a device health value of 86, and a node queue status of 420. After associating the storage node identifier with the window start time, a storage scheduling record for this storage node within the preset sampling window is generated.

[0022] In step S2, the storage scheduling data is input into a pre-trained random forest risk assessment model to identify pressure wear associations, thereby obtaining pressure wear risk features. Based on the pressure wear risk features, node health is mapped to obtain node health scores.

[0023] Specifically, the storage scheduling data is input into a pre-trained random forest risk assessment model for stress-wear association identification to obtain stress-wear risk features, including: The storage scheduling data is input into the pre-trained random forest risk assessment model for decision tree inference to obtain the node risk category; The Gini impurity decrease values ​​of the request pressure field set and media wear field set extracted from the storage scheduling data during the decision tree splitting process are statistically analyzed to obtain the field contribution sequence; Based on the field contribution sequence, the requested pressure field and the medium wear field are marked as risk fields to obtain pressure wear risk characteristics.

[0024] In one implementation, the request pressure field set is extracted from the storage scheduling data. The request pressure field set includes total requests, write requests, highest request priority, total data blocks, average queuing time, and node queue status. The media wear field set is also extracted from the storage scheduling data. The media wear field set includes erase / write cycles, number of bad blocks, spare block ratio, and device health value. During extraction, this embodiment reads each storage scheduling record in the storage scheduling data, writes the total requests, write requests, highest request priority, total data blocks, average queuing time, and node queue status into the request pressure field set in a fixed order, and writes the erase / write cycles, number of bad blocks, spare block ratio, and device health value into the media wear field set in a fixed order.

[0025] It should be noted that the pre-trained random forest risk assessment model is a classification model composed of multiple CART decision trees. The input to the random forest risk assessment model is a set of request pressure fields and a set of media wear fields, and the output is a node risk category. The node risk categories include low risk, risk of concern, and high risk. During training, each CART decision tree generates subsamples by sampling with replacement from the labeled training samples. Within each internal node, a subset of fields is randomly selected from the request pressure field set and the media wear field set as candidate fields. For each candidate field, the splitting points are traversed, and the splitting point with the largest decrease in Gini impurity value is selected for node splitting. During inference, the request pressure field set and the media wear field set are input into each CART decision tree, and each CART decision tree outputs a risk category. The risk category with the most outputs from all CART decision trees is counted to obtain the node risk category.

[0026] The pre-trained random forest risk assessment model is trained using historical storage scheduling data. The historical storage scheduling data uses the same field structure as the historical storage scheduling data. When constructing training samples, this embodiment reads each historical storage scheduling record from the historical storage scheduling data and reads the average response time, request failure rate, and device health value decline within the next sampling window for that historical storage scheduling record. If none of the following three conditions are met: average response time greater than 10 milliseconds, request failure rate greater than 0.1%, and device health value decline relative to 100 sampling windows prior not less than 1 minute, the corresponding training sample is marked as low-risk. If one of the three conditions is met, the corresponding training sample is marked as high-risk. If two or three of the three conditions are met, the corresponding training sample is marked as high-risk.

[0027] The aforementioned 10 milliseconds were determined using the 95th percentile of the average response time for high-priority read / write requests in historical storage scheduling data. The aforementioned 0.1% was determined using the 99th percentile of the request failure rate for low-risk samples in historical storage scheduling data. The aforementioned 1 point is the smallest recording granularity for device health values. The storage controller records device health values ​​as integer scores each time it reports them; therefore, 1 point is used as the determination value for the magnitude of the decline in device health values.

[0028] It is worth noting that the model parameters of the pre-trained random forest risk assessment model were determined through grid search and five-fold cross-validation. The number of candidate decision trees was set to 64, 96, and 128; the maximum candidate tree depth was set to 8, 12, and 16 layers; and the minimum number of candidate leaf nodes was set to 10, 20, and 30 samples. During grid search, this embodiment performed five-fold cross-validation on each set of candidate parameters and statistically analyzed the macro-average F1 value and the inference time per sample of the validation samples. The parameter combination with the highest macro-average F1 value and the inference time per sample not exceeding 5 milliseconds was selected as the model parameters. Validated with training samples, the macro-average F1 value corresponding to 96 decision trees, a maximum tree depth of 12 layers, and a minimum number of leaf nodes of 20 was 0.91, and the inference time per sample was 3.2 milliseconds. Therefore, the random forest risk assessment model was set to 96 CART decision trees, a maximum tree depth of 12 layers, and a minimum number of leaf nodes of 20.

[0029] When calculating the Gini impurity decrease value, this embodiment reads the split node records of each CART decision tree in the random forest risk assessment model. For each split node, the field name involved in the split and the corresponding Gini impurity decrease value are recorded. For each field in the requested pressure field set and the medium wear field set, the Gini impurity decrease values ​​of that field in all CART decision trees are summed to obtain the cumulative contribution value of the field; then, the cumulative contribution value of each field is divided by the sum of the cumulative contribution values ​​of all fields to obtain the field contribution value. All field names and their corresponding field contribution values ​​are arranged in descending order of field contribution value to obtain the field contribution sequence.

[0030] This embodiment marks risk fields based on the field contribution sequence. The 75th percentile of the field contribution value is used as the contribution threshold, which is set to 0.08 in this embodiment. The contribution threshold is determined through the field contribution sequence during the training phase. Specifically, all field contribution values ​​during the training phase are read, sorted in ascending order, and the 75th percentile is extracted, resulting in 0.08. When marking risk fields, fields with a contribution value of at least 0.08 are marked as risk fields, and the risk field name, risk field value, field contribution value, and node risk category are written into the same record to obtain the pressure wear risk characteristics.

[0031] For example, the request pressure field set of a certain storage node within the current preset sampling time window includes total request volume 4000, write request volume 800, highest request priority 9, total data block volume 640 megabytes, average queuing time 3 milliseconds, and node queue status 420. The media wear field set includes erase / write cycles 1800 times, number of bad blocks 12, spare block ratio 0.18, and device health value 86. After inputting the above fields into a pre-trained random forest risk assessment model, 68 out of 96 CART decision trees output "risk of concern," 20 output "low risk," and 8 output "high risk." Therefore, the node risk category is "risk of concern." After statistically analyzing the field contribution sequence, the field contribution value of node queue status is 0.21, the field contribution value of erase / write cycles is 0.17, the field contribution value of average queuing time is 0.12, the field contribution value of number of bad blocks is 0.09, and the contribution values ​​of the remaining fields are all below 0.08. Therefore, node queue status, erase / write cycles, average queuing time, and number of bad blocks are marked as risk fields, resulting in the pressure wear risk characteristics.

[0032] Specifically, node health is mapped based on the pressure wear risk characteristics to obtain a node health score, including: Based on the aforementioned pressure wear risk characteristics, a risk level mapping is performed to obtain the node risk level; Extract device health values ​​from the media window data in the storage scheduling data; Based on the node risk level, the device health value is deducted and mapped to obtain a node health score.

[0033] In one implementation, the pressure wear risk feature includes a risk field name, a risk field value, a field contribution value, and a node risk category. This embodiment maps risk levels based on the node risk categories in the pressure wear risk feature to obtain node risk levels. When the node risk category is low risk, the node risk level is mapped to level 0; when the node risk category is a risk of concern, the node risk level is mapped to level 1; and when the node risk category is high risk, the node risk level is mapped to level 2. The risk level mapping is formed by increasing the number of conditions that are met when the training samples are labeled: level 0 corresponds to all three conditions being false, level 1 corresponds to one condition being true, and level 2 corresponds to two or three conditions being true.

[0034] This embodiment extracts the device health value from the media window data in the storage scheduling data. The device health value is the device health value in the media window data, and its value ranges from 0 to 100. When the storage controller returns the remaining lifetime percentage, this embodiment directly records the remaining lifetime percentage as the device health value; when the storage controller returns the original health register value, this embodiment reads the maximum health register value given in the register manual, divides the original health register value by the maximum health register value, and then multiplies it by 100 to obtain the device health value. The maximum health register value is written to the register description table by the storage controller firmware during the device initialization phase, and this embodiment reads the maximum health register value from the register description table.

[0035] When performing health deduction mapping, this embodiment determines the health deduction value based on the node risk level. When the node risk level is 0, the health deduction value is 0 points; when the node risk level is 1, the health deduction value is 10 points; and when the node risk level is 2, the health deduction value is 25 points. The above health deduction values ​​are determined through historical training samples. Specifically, the historical training samples are grouped according to the node risk level, and the 90th percentile of the device health value decrease in the next sampling window for each group of samples is calculated. Then, the 90th percentile is multiplied by 10 and the result is taken as the nearest multiple of 5, yielding 0, 10, and 25 points respectively.

[0036] This embodiment maps the device health value to a health deduction based on the node risk level. Specifically, the health deduction value corresponding to the node risk level is read, and the device health value is subtracted from the health deduction value to obtain a candidate health score. When the candidate health score is less than 0, the node health score is recorded as 0; when the candidate health score is not less than 0, the candidate health score is recorded as the node health score.

[0037] For example, in the stress and wear risk characteristics of a certain storage node, the node risk category is "risk of concern," corresponding to a node risk level of 1. The device health value extracted from the storage scheduling data is 86. Based on the level 1 node risk level, a health deduction value of 10 points is read. Subtracting 10 from 86 yields a node health score of 76. In the stress and wear risk characteristics of another storage node, the node risk category is "high risk," corresponding to a node risk level of 2. The device health value extracted from the storage scheduling data is 72. Based on the level 2 node risk level, a health deduction value of 25 points is read. Subtracting 25 from 72 yields a node health score of 47.

[0038] In step S3, resource acceptance is filtered based on the node health score and the storage scheduling data to obtain candidate storage nodes. Request acceptance mapping is then performed based on the candidate storage nodes and the storage scheduling data to obtain a request allocation matrix.

[0039] Among them, resource acceptance is screened based on the node health score and the storage scheduling data to obtain candidate storage nodes, including: Healthy storage nodes are obtained by screening healthy nodes based on their health scores and preset health conditions. Based on the storage scheduling data, the capacity queue of the healthy storage nodes is verified to obtain the nodes that can be taken over. Candidate storage nodes are obtained by marking the nodes that can be accepted.

[0040] In one implementation, the node health score is the storage node health quantification result output in step S2, with a value range of 0 to 100. The preset health conditions include a node health score of not less than 60 points. The score of 60 is determined through offline playback of historical storage scheduling data. Specifically, historical storage scheduling data is divided into three candidate boundaries—50, 60, and 70 points—based on node health scores from low to high. The proportion of high-risk nodes incorrectly retained and the proportion of healthy nodes retained within the next sampling window under each candidate boundary are calculated. When the candidate boundary is 50 points, the proportion of high-risk nodes incorrectly retained is 11.6%, and the proportion of healthy nodes retained is 84.2%; when the candidate boundary is 60 points, the proportion of high-risk nodes incorrectly retained is 4.7%, and the proportion of healthy nodes retained is 72.5%; when the candidate boundary is 70 points, the proportion of high-risk nodes incorrectly retained is 2.1%, and the proportion of healthy nodes retained is 51.3%. In this embodiment, the candidate boundary is selected where the proportion of high-risk nodes that are incorrectly retained is less than 5% and the proportion of healthy nodes is the highest. The preset health condition is set as a node health score of not less than 60 points.

[0041] When screening healthy nodes, this embodiment reads the node health score obtained in step S2 one by one, writes the storage nodes with a health score of not less than 60 into the healthy node list, and records the healthy node list as healthy storage nodes. Each record in the healthy storage node list includes the storage node identifier, the node health score, and the start time of the time window.

[0042] It should be noted that the capacity queue verification reads the remaining capacity and node queue status corresponding to healthy storage nodes from the storage scheduling data. The remaining capacity is represented by a remaining capacity ratio, which is the ratio obtained by dividing the remaining capacity by the total capacity of the storage nodes. The node queue status is represented by the number of pending requests. The capacity queue verification includes a remaining capacity ratio of not less than 15% and a node queue status of not more than 800 requests. The 15% is determined through insufficient capacity events in historical storage scheduling data. Specifically, it involves extracting historical storage node records where write rejections or space reallocations occurred, and calculating the 90th percentile of the remaining capacity ratio of these historical storage node records within the sampling window prior to the event, thus obtaining 15%. The 800 requests were determined by the response inflection point in the offline playback. Specifically, the node queue status was divided into intervals of 100 requests each, and the median average response time for each interval was calculated. When the node queue status increased from the interval of 700 to 800 requests to the interval of 800 to 900 requests, the median average response time increased from 8 milliseconds to 13 milliseconds. Therefore, the node queue status of no more than 800 requests was used as the queue condition in the capacity queue verification.

[0043] This embodiment performs capacity queue verification on the healthy storage nodes based on the storage scheduling data. Specifically, the storage node identifier of the healthy storage node is read, and storage scheduling records with the same storage node identifier and the same start time of the same time window are retrieved from the storage scheduling data. The remaining capacity percentage and node queue status are read from the storage scheduling records. When the remaining capacity percentage is not less than 15% and the node queue status does not exceed 800 requests, the healthy storage node is written into the list of available nodes, thus obtaining the available nodes.

[0044] In this embodiment, candidate tags are generated for each available node during candidate tagging. The candidate tag includes a storage node identifier, a candidate status bit, a node health score, a remaining capacity percentage, a node queue status, and a time window start time. A candidate status bit of 1 indicates that the corresponding storage node has entered the candidate range for the current scheduling period. All available nodes with candidate tags constitute candidate storage nodes.

[0045] For example, within a certain scheduling period, node A has a node health score of 76, a remaining capacity ratio of 28%, and a node queue status of 420 requests; node B has a node health score of 58, a remaining capacity ratio of 40%, and a node queue status of 300 requests; node C has a node health score of 82, a remaining capacity ratio of 12%, and a node queue status of 250 requests. Node A meets the health conditions and capacity queue verification and is written into the candidate storage node; node B does not meet the health conditions and is not written into the candidate storage node; node C does not meet the condition that the remaining capacity ratio is not less than 15%, and is not written into the candidate storage node.

[0046] Specifically, a request allocation matrix is ​​obtained by performing request acceptance mapping based on the candidate storage nodes and the storage scheduling data, including: Based on the storage scheduling data, high-priority read / write requests are identified to obtain a set of high-priority read / write requests. A node request index is established based on the candidate storage nodes and the high-priority read / write request set to obtain the receiving index table; The weights of the receiving index table are filled according to the storage scheduling data to obtain the request allocation matrix.

[0047] In one implementation, the high-priority read / write request set is a set of request identifiers that meet the high-priority level condition within the current preset sampling time window. The request window data in the storage scheduling data retains the request identifier index, which is composed of request identifiers within the same preset sampling time window during window aggregation in step S1. Request priorities are marked with integers from level 1 to level 10, with larger values ​​indicating higher request levels. The high-priority level condition is set to a request priority of not less than level 8. Level 8 is determined through the distribution of high-priority requests in historical storage scheduling data. Specifically, all request priorities and their corresponding response times are read, and the 95th percentile of the average response time is calculated grouped by request priority. The 95th percentile for requests with priorities of 8, 9, and 10 is not greater than 10 milliseconds, and the 95th percentile for a request with priority of 7 is 18 milliseconds. Therefore, requests with a priority of not less than level 8 are identified as high-priority read / write requests.

[0048] When identifying high-priority read / write requests, this embodiment reads the request identifier index in the storage scheduling data one by one and looks up the request priority, read / write type, and data block size corresponding to each request identifier. When the request priority is not less than level 8, the request identifier, read / write type, data block size, request priority, and time window start time are written into the high-priority read / write request list to obtain the high-priority read / write request set.

[0049] This embodiment establishes a node request index based on the candidate storage nodes and the high-priority read / write request set. When establishing the node request index, the storage node identifiers in the candidate storage nodes are read one by one, and the request identifiers in the high-priority read / write request set are read one by one. Each storage node identifier and each request identifier are combined into an index record. Each index record includes a storage node identifier, a request identifier, a commitment status bit, and a commitment weight. The commitment status bit is initially set to 0, and the commitment weight is initially set to 0. All index records are arranged according to the storage node identifier and request priority to obtain the commitment index table.

[0050] In this embodiment, the acceptance index table is weighted according to the storage scheduling data. During weight filling, the storage node identifier in each index record is read, and the node health score, remaining capacity ratio, and node queue status of the corresponding storage node are extracted from the storage scheduling data. Candidate storage nodes are sorted by health score (highest to lowest), by remaining capacity ratio (highest to lowest), and by queue status (lowest to highest). The rankings in each of the three sortings are converted into ranking scores: the ranking score for the first-ranked node is equal to the number of candidate storage nodes, the ranking score for the second-ranked node is equal to the number of candidate storage nodes minus 1, and so on, with the lowest ranking having a ranking score of 1. The health ranking score, capacity ranking score, and queue ranking score are added together to obtain the acceptance weight. When the acceptance weight is greater than 0, the acceptance status bit is recorded as 1. After weight filling, the acceptance index table is expanded in a row-column format, with rows corresponding to candidate storage nodes, columns corresponding to high-priority read / write requests, and matrix elements representing acceptance weights, resulting in a request allocation matrix.

[0051] It is worth noting that the request allocation matrix retains an acceptance status bit and an acceptance weight. The acceptance status bit is read when determining the identifier of the request to be dispatched, and the acceptance weight is read during subsequent service carrying verification. Each matrix element in the request allocation matrix can be traced back to the corresponding record in the storage scheduling data through the storage node identifier and the request identifier.

[0052] For example, in the current scheduling period, there are two candidate storage nodes, node A and node D. The high-priority read / write request set includes request R1, request R2, and request R3. Node A has a health sorting score of 2, a capacity sorting score of 1, a queue sorting score of 2, and a weight of 5; node D has a health sorting score of 1, a capacity sorting score of 2, a queue sorting score of 1, and a weight of 4. This results in a two-row, three-column request allocation matrix, where the matrix elements for requests R1, R2, and R3 corresponding to node A are all 5, and the matrix elements for requests R1, R2, and R3 corresponding to node D are all 4.

[0053] like Figure 2As shown in the figure, this diagram presents a heatmap of the request allocation matrix for the adaptive scheduling method of storage resources. Rows represent candidate storage nodes (nodes A, B, and C), and columns represent high-priority read / write requests (requests 1 to 6). The values ​​within the matrix cells and the weight values ​​represented by the color bars on the right intuitively reflect the estimated weight distribution of each candidate node for different requests. By constructing this matrix, not only is the relationship between nodes and requests quantitatively displayed, but the differentiated weight filling also intuitively demonstrates the effectiveness of the system's strategy for differentiated resource mapping of high-concurrency business requests. This provides clear data support and visualization for the subsequent generation of storage routing tables and the issuance of scheduling instructions.

[0054] In step S4, service bearer verification is performed based on the request allocation matrix to obtain node bearer results, and target node selection is performed based on the node bearer results to obtain the target storage node.

[0055] The process of performing service bearer verification based on the request allocation matrix to obtain node bearer results includes: The number of requests to be accepted by the candidate storage nodes is determined based on the request allocation matrix. Extract the node queue status of the candidate storage nodes from the storage scheduling data; Response prediction is performed on the number of requests to be accepted and the status of the node queue to obtain a predicted response index; Based on the predicted response indicators and preset business conditions, the node bearing results are obtained by marking the bearings.

[0056] In one implementation, the number of requests to be accepted is the number of high-priority read / write requests mapped by the request allocation matrix to the candidate storage node in the current scheduling period and the corresponding total number of data blocks. To determine the number of requests to be accepted, this embodiment reads the request allocation matrix line by line; for each candidate storage node, the number of request identifiers with a status bit of 1 in the matrix elements is counted to obtain the number of requests to be accepted; the size of the data blocks in the high-priority read / write request set is checked back, and the data block sizes corresponding to the request identifiers with a status bit of 1 are accumulated to obtain the amount of data to be accepted; the number of requests to be accepted and the amount of data to be accepted are written into the same record to obtain the total number of requests to be accepted.

[0057] The node queue status is extracted from the storage scheduling data. During extraction, this embodiment reads the storage node identifier and time window start time corresponding to the candidate storage node, and retrieves storage scheduling records with the same storage node identifier and the same time window start time from the storage scheduling data. The node queue status is then read from these storage scheduling records. The node queue status represents the number of pending requests in the node's input / output queue at the end of the current preset sampling time window.

[0058] In response prediction, this embodiment employs an M / M / c queuing model. This model uses a single-queue, multi-server structure, where all enabled input / output queues of candidate storage nodes share a single waiting queue. The number of parallel service channels in the M / M / c queuing model is determined by the number of enabled input / output queues of the candidate storage node. The input request arrival rate is obtained by adding the total number of requests within the current preset sampling window to the number of pending requests, then dividing by the preset sampling window length. The service rate of a single parallel service channel is obtained by dividing the number of requests completed by the storage node within the last ten preset sampling windows by the number of enabled input / output queues and the total duration. The last ten preset sampling windows correspond to 10 seconds, and this duration is determined through offline playback. Specifically, service rates are statistically analyzed using 5 seconds, 10 seconds, and 20 seconds. The coefficient of variation for the service rate is 0.22 for 5 seconds, 0.11 for 10 seconds, and 0.10 for 20 seconds. This embodiment selects a 10-second window with a coefficient of variation lower than 0.12 and a shorter statistical duration.

[0059] In this embodiment, the input request arrival rate, the service rate of a single parallel service channel, the number of parallel service channels, and the node queue status are substituted into the M / M / c queuing model to obtain the predicted response time and predicted utilization rate, which are then recorded as the predicted response indicators. The M / M / c queuing model calculates the response time according to Poisson arrival, exponential service time, and the queuing process of multiple parallel service channels. The predicted response time is obtained by adding the queue waiting time and the service processing time, and the predicted utilization rate is obtained by dividing the input request arrival rate by the total service rate of all parallel service channels. If the predicted utilization rate is not less than 1, the predicted response time is marked as unacceptable.

[0060] It should be noted that the preset business conditions include a predicted response time of no more than 10 milliseconds and a predicted utilization rate of no more than 0.85. 10 milliseconds is the response boundary used in the training sample annotation in step S2, and it comes from the same source. 0.85 is determined by the utilization inflection point in offline playback. Specifically, the predicted utilization rate is divided into intervals of 0.05, and the 95th percentile of the response time for high-priority read / write requests within each interval is calculated. When the predicted utilization rate rises from the 0.80-0.85 interval to the 0.85-0.90 interval, the 95th percentile of the response time rises from 9.6 milliseconds to 14.8 milliseconds. Therefore, a predicted utilization rate of no more than 0.85 is used as the utilization boundary in the business conditions.

[0061] When performing load marking, this embodiment reads the predicted response metrics. If the predicted response time is no greater than 10 milliseconds and the predicted utilization rate is no greater than 0.85, the load status bit of the candidate storage node is recorded as 1; if either condition is not met, the load status bit of the candidate storage node is recorded as 0. The storage node identifier, the number of requests to be handled, the predicted response time, the predicted utilization rate, and the load status bit are written into the same record to obtain the node load result.

[0062] For example, node A has a total of 8637 requests within the current preset sampling window, 3 pending requests, 96 megabytes of data to be processed, a queue status of 420 requests, 8 active input / output queues, and 120,000 completed requests in the last 10 seconds. Based on the M / M / C queuing model, the predicted response time is 7.8 milliseconds, and the predicted utilization rate is 0.72. Since the predicted response time is no greater than 10 milliseconds and the predicted utilization rate is no greater than 0.85, node A's carrying status bit is recorded as 1. Node D has a predicted response time of 12.4 milliseconds and a predicted utilization rate of 0.79. Since the predicted response time is greater than 10 milliseconds, node D's carrying status bit is recorded as 0.

[0063] The process of selecting a target storage node based on the node carrying results includes: Based on the node carrying results, the candidate storage nodes are filtered according to business conditions to obtain dispatchable nodes; The dispatchable nodes are sorted according to their health scores to obtain the node sorting results. The target is marked based on the node sorting result to obtain the target storage node.

[0064] In one implementation, the dispatchable node is a candidate storage node whose bearer status bit is 1 in the node bearer results. During service condition filtering, this embodiment reads each node bearer result sequentially and writes the storage node identifier corresponding to the record with a bearer status bit of 1 into the dispatchable node list to obtain the dispatchable nodes. Candidate storage nodes with a bearer status bit of 0 are not written into the dispatchable node list.

[0065] During health sorting, this embodiment reads the node health score corresponding to each dispatchable node and sorts the dispatchable nodes from highest to lowest health score to obtain the node sorting result. When two dispatchable nodes have the same health score, the predicted response time in the node carrying result is read, and the dispatchable node with the shorter predicted response time is ranked first. When both the node health score and the predicted response time are the same, the remaining capacity ratio in the storage scheduling data is read, and the dispatchable node with the higher remaining capacity ratio is ranked first. The node sorting result includes the storage node identifier, node health score, predicted response time, remaining capacity ratio, and sorting rank.

[0066] When marking targets, this embodiment reads the first dispatchable node in the node sorting results, sets the target status bit of the dispatchable node to 1, and marks the corresponding storage node identifier as the target storage node. The target status bit of dispatchable nodes that are not first in the sorting results is set to 0. If the dispatchable node list is empty, this embodiment does not generate a record with a target status bit of 1, and retains the high-priority read / write requests of the current scheduling period in the original request queue to wait for reprocessing in the next preset sampling window; if the dispatchable node list is not empty, when the number of requests to be accepted corresponding to the target storage node reaches the upper limit of the node queue capacity, the next node is selected from the dispatchable node list in order of sorting to accept the requests, until the high-priority read / write request set is cleared or there are no dispatchable nodes.

[0067] For example, in the node carrying results, the carrying status bits of nodes A and E are 1, and the carrying status bit of node D is 0. Therefore, nodes A and E constitute dispatchable nodes. Node A has a node health score of 76, a predicted response time of 7.8 milliseconds, and a remaining capacity percentage of 28%. Node E has a node health score of 81, a predicted response time of 8.5 milliseconds, and a remaining capacity percentage of 22%. After sorting the nodes according to their health scores from highest to lowest, node E is ranked first, and node A is ranked second. In this embodiment, the target status bit of node E is recorded as 1, and node E is designated as the target storage node.

[0068] In step S5, a storage scheduling instruction is generated based on the target storage node and the preset storage routing table mapped by the request allocation matrix, including: The request identifier to be dispatched is determined based on the request allocation matrix; Based on the target storage node and the identifier of the request to be dispatched, the route entry is located in the preset storage routing table to obtain the target route entry; The target routing entry is used for instruction encoding processing to generate a storage scheduling instruction.

[0069] In one implementation, the request identifier to be dispatched is a request identifier in the request allocation matrix that corresponds to the target storage node and has an acceptance status bit of 1. When determining the request identifier to be dispatched, this embodiment reads the storage node identifier of the target storage node, locates the corresponding row in the request allocation matrix, reads the matrix element in the corresponding row whose acceptance status bit is 1, and writes the request identifier corresponding to the matrix element into the request list to be dispatched, thus obtaining the request identifier to be dispatched.

[0070] It should be noted that the logical volume identifier, logical address range, data block size, and request priority corresponding to the request to be dispatched are read from the original request record of the request status data. The original request record retains a lookup relationship through the request identifier index during window aggregation in step S1. The lookup relationship includes the request identifier and the storage location of the original request record. After reading the request to be dispatched identifier, this embodiment locates the original request record according to the lookup relationship and reads the corresponding logical volume identifier, logical address range, data block size, and request priority.

[0071] The preset storage routing table is a routing mapping table generated during storage cluster initialization and node configuration changes. When constructing the preset storage routing table, this embodiment reads the storage node identifier, logical volume identifier, namespace identifier, input / output queue number, routing port number, and address range from the cluster metadata; establishes a routing record for each set of storage node identifiers and logical volume identifiers; verifies the accessibility of the storage node corresponding to the routing record through a metadata read request; if the verification is successful, the routing record is written to the storage routing table; routing records that fail verification are not written to the storage routing table, and a verification failure log is recorded; when a storage node is added, removed, a logical volume is migrated, or a namespace remapping event occurs, the cluster metadata is reread and the storage routing table is updated. The keys in the storage routing table include the storage node identifier and the logical volume identifier, and the values ​​in the storage routing table include the namespace identifier, input / output queue number, routing port number, and address range.

[0072] When locating a route entry, this embodiment reads the storage node identifier of the target storage node and the logical volume identifier corresponding to the request to be dispatched; it then searches a preset storage routing table for a route record whose key matches both the storage node identifier and the logical volume identifier; when a route record is found, it is recorded as the target route entry. The target route entry includes the target storage node, namespace identifier, input / output queue number, routing port number, and address range.

[0073] This embodiment performs instruction encoding processing based on the target routing entry. The storage scheduling instruction adopts a Type-Length-Value encoding structure. During instruction encoding, the instruction type field, request identifier field, target storage node field, namespace field, input / output queue field, logical address field, data length field, request priority field, and verification field are written in a fixed order. The instruction type field records whether the scheduling is written or read; the request identifier field records the identifier of the request to be dispatched; the target storage node field records the storage node identifier of the target storage node; the namespace field records the namespace identifier in the target routing entry; the input / output queue field records the input / output queue number in the target routing entry; the logical address field records the logical address range in the original request record; the data length field records the data block size in the original request record; the request priority field records the request priority in the original request record; and the verification field is obtained by processing the byte stream of the aforementioned fields using the CRC-32 algorithm. After encoding, the storage scheduling instruction is obtained.

[0074] It's worth noting that in the Type-Length-Value encoding structure, Type represents the field type number, Length represents the field length, and Value represents the field content. The field type numbers are fixed in the storage controller firmware: Instruction type field number 1, Request identifier field number 2, Target storage node field number 3, Namespace field number 4, Input / Output queue field number 5, Logical address field number 6, Data length field number 7, Request priority field number 8, and Checksum field number 9. Field length is recorded in bytes, using big-endian byte order.

[0075] For example, if the target storage node is node E, and the acceptance status bit of requests R1 and R2 corresponding to node E in the request allocation matrix is ​​1, then the request identifiers to be dispatched include requests R1 and R2. Request R1 corresponds to logical volume identifier V3, with a logical address range of logical blocks 2048 to 4095, a data block size of 8 megabytes, and a request priority of 9. In the preset storage routing table, the target routing entries corresponding to node E and logical volume V3 include namespace identifier NS2, input / output queue number Q6, routing port number P4, and an address range of logical blocks 0 to 1048575. In this embodiment, request R1, node E, NS2, Q6, logical blocks 2048 to 4095, 8 megabytes, and request priority 9 are written into the field according to the Type-Length-Value encoding structure, and a check field is generated using the CRC-32 algorithm to obtain the storage scheduling instruction corresponding to request R1. Request R2 generates its corresponding storage scheduling instruction in the same way.

[0076] In summary, this invention obtains storage scheduling data by performing time-window alignment processing on request status data and media status data of high-concurrency read / write services in a storage cluster. This storage scheduling data is then input into a pre-trained random forest risk assessment model for stress and wear correlation identification. Based on the stress and wear risk characteristics, node health is mapped to obtain node health scores. Next, resource acceptance screening and request acceptance mapping are performed based on the node health scores and storage scheduling data to obtain a request allocation matrix. Subsequently, service carrying verification and target node selection are performed based on the request allocation matrix to obtain target storage nodes. Finally, a storage scheduling instruction is generated by mapping the target storage node and the request allocation matrix to a pre-set storage routing table. This achieves continuous processing between storage node acceptance status identification and storage request dispatch under high-concurrency read / write services.

[0077] A second embodiment of the present invention provides a storage resource adaptive scheduling system, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described above.

[0078] It should be noted that the storage resource adaptive scheduling system provided in this embodiment of the invention is used to execute all the process steps of the storage resource adaptive scheduling method in the above embodiment. The working principles and beneficial effects of the two are one-to-one, so they will not be described again.

[0079] It should be noted that the system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0080] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention for those skilled in the art.

Claims

1. A method for adaptive scheduling of storage resources, characterized in that, include: Obtain request status data and media status data of high-concurrency read and write services in the storage cluster, and perform time window alignment processing on the request status data and the media status data to obtain storage scheduling data; The storage scheduling data is input into a pre-trained random forest risk assessment model to identify pressure wear associations, thereby obtaining pressure wear risk features. Based on the pressure wear risk features, node health is mapped to obtain node health scores. Based on the node health score and the storage scheduling data, resource acceptance is filtered to obtain candidate storage nodes. Based on the candidate storage nodes and the storage scheduling data, request acceptance mapping is performed to obtain a request allocation matrix. The service carrying verification is performed based on the request allocation matrix to obtain the node carrying result. The target node is selected based on the node carrying result to obtain the target storage node. Based on the target storage node and the requested allocation matrix mapping to a preset storage routing table, a storage scheduling instruction is generated.

2. The storage resource adaptive scheduling method according to claim 1, characterized in that, The process of obtaining request status data and media status data of high-concurrency read / write services in the storage cluster, and performing time-window alignment processing on the request status data and the media status data to obtain storage scheduling data includes: The request status data is windowed according to a preset sampling time window to obtain request window data; The medium state data is windowed according to the preset sampling time window to obtain medium window data; The request window data and the media window data are associated with the storage node identifier to obtain storage scheduling data.

3. The storage resource adaptive scheduling method according to claim 1, characterized in that, The step of inputting the storage scheduling data into a pre-trained random forest risk assessment model for stress wear association identification to obtain stress wear risk features includes: The storage scheduling data is input into the pre-trained random forest risk assessment model for decision tree inference to obtain the node risk category; The Gini impurity decrease values ​​of the request pressure field set and media wear field set extracted from the storage scheduling data during the decision tree splitting process are statistically analyzed to obtain the field contribution sequence; Based on the field contribution sequence, the requested pressure field and the medium wear field are marked as risk fields to obtain pressure wear risk characteristics.

4. The storage resource adaptive scheduling method according to claim 1, characterized in that, The step of mapping node health based on the pressure wear risk characteristics to obtain a node health score includes: Based on the aforementioned pressure wear risk characteristics, a risk level mapping is performed to obtain the node risk level; Extract device health values ​​from the media window data in the storage scheduling data; Based on the node risk level, the device health value is deducted and mapped to obtain a node health score.

5. The storage resource adaptive scheduling method according to claim 1, characterized in that, The step of filtering candidate storage nodes based on the node health score and the storage scheduling data includes: Healthy storage nodes are obtained by screening healthy nodes based on their health scores and preset health conditions. Based on the storage scheduling data, the capacity queue of the healthy storage nodes is verified to obtain the nodes that can be taken over. Candidate storage nodes are obtained by marking the nodes that can be accepted.

6. The storage resource adaptive scheduling method according to claim 1, characterized in that, The step of performing request acceptance mapping based on the candidate storage nodes and the storage scheduling data to obtain the request allocation matrix includes: Based on the storage scheduling data, high-priority read / write requests are identified to obtain a set of high-priority read / write requests. A node request index is established based on the candidate storage nodes and the high-priority read / write request set to obtain the receiving index table; The weights of the receiving index table are filled according to the storage scheduling data to obtain the request allocation matrix.

7. The adaptive scheduling method for storage resources according to claim 1, characterized in that, The step of performing service bearer verification based on the request allocation matrix to obtain the node bearer result includes: The number of requests to be accepted by the candidate storage nodes is determined based on the request allocation matrix. Extract the node queue status of the candidate storage nodes from the storage scheduling data; Response prediction is performed on the number of requests to be accepted and the status of the node queue to obtain a predicted response index; Based on the predicted response indicators and preset business conditions, the node bearing results are obtained by marking the bearings.

8. The adaptive scheduling method for storage resources according to claim 1, characterized in that, The step of selecting a target node based on the node carrying result to obtain the target storage node includes: Based on the node carrying results, the candidate storage nodes are filtered according to business conditions to obtain dispatchable nodes; The dispatchable nodes are sorted according to their health scores to obtain the node sorting results. The target is marked based on the node sorting result to obtain the target storage node.

9. The adaptive scheduling method for storage resources according to claim 1, characterized in that, The step of generating storage scheduling instructions based on the target storage node and the requested allocation matrix mapping a preset storage routing table includes: The request identifier to be dispatched is determined based on the request allocation matrix; Based on the target storage node and the identifier of the request to be dispatched, the route entry is located in the preset storage routing table to obtain the target route entry; The target routing entry is used for instruction encoding processing to generate a storage scheduling instruction.

10. A storage resource adaptive scheduling system, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method according to any one of claims 1 to 9.

Images