Virtual resource fragmentation state integration early warning method

Abstract

The present application relates to the technical field of alarm early warning, and more particularly to a virtual resource fragmentation state integration early warning method. The method obtains the occupation state, locking state, release prediction time and compatibility label of resource fragments in a virtual resource pool, and generates a resource fragment state sequence. Idle fragments, occupied fragments, to-be-released fragments and restricted fragments are constructed as topological nodes, and adjacent relationships, same type merging relationships, time coinciding relationships, policy compatibility relationships and restricted blocking relationships are constructed as topological edges to form an integrable domain topology graph. Connected domain identification and edge weight correction are performed on the integrable domain topology graph to obtain an integrable domain set. Request forms in historical resource application records and current queued requests are extracted, and the request forms are matched with the integrable domain set. The method can identify virtual resource states in which the total remaining amount is sufficient but the integrable capacity is insufficient, so that the early warning result corresponds to specific risk sources such as insufficient capacity, boundary blocking, time mismatch or compatibility failure.

Description

Technical Field

[0001] This invention relates to the field of alarm and early warning technology, and in particular to a method for early warning of fragmented virtual resource status integration. Background Technology

[0002] Existing virtual resource management systems typically divide the virtual resource pool into several logical resource units and maintain a resource allocation table during resource application, occupation, release, renewal, locking, and reclamation processes. Conventional early warning schemes generally read status variables from the resource allocation table, such as remaining capacity, occupied capacity, number of free segments, maximum consecutive free segments, and average segment size, and compare these status variables with preset alarm thresholds. When the remaining capacity is below the threshold, the number of fragments is above the threshold, or the maximum consecutive free segments are below the requested size, the system generates a resource shortage alarm or fragmentation alarm of the corresponding level. This type of scheme is simple to implement, reflects the overall occupancy of virtual resources, and can also indicate operational risks when the resource pool is nearing depletion. Some systems also scan the resource allocation table at fixed intervals, merge adjacent free segments within the table, and use the largest free interval after merging as the basis for subsequent alarms. Since the scan results are usually expressed as table entry length and resource quantity, the contextual constraints of the segments are compressed into simple status fields. However, the judgment objects are mainly static statistics at a single moment. Whether there is a policy compatibility relationship between resource fragments, whether the release time is within the same available window, whether the locked state covers the subsequent occupancy period, and whether the restricted fragment will block the continuous interval are usually not uniformly modeled, so the alarm basis remains at the level of resource quantity statistics.

[0003] In virtual resource scheduling scenarios that more closely resemble real-world operations, some systems add release time prediction and request queuing analysis. The system estimates resource release times based on historical occupancy durations and, combined with the current resource size in the queue, determines whether resource shortages are likely within a few future time slices. Some solutions also sort idle segments, merging adjacent idle segments, or perform a reorganization operation after resource release, then determine whether to trigger an alarm based on the largest available segment after reorganization. These solutions add a time dimension compared to simple capacity threshold judgment, but still rely on the continuity of segment form or capacity availability as the core criteria. For virtual resources with differences in compatibility tags, isolation policies, locking restrictions, pending release states, and time windows, two segments, even if logically adjacent, may not be merged due to policy incompatibility; multiple segments, even if physically scattered, may form composable resources under the same release window and compatibility constraints. If the system judges only based on segment length or release order, it will consider formally adjacent segments as available or exclude scattered but composable segments. When queuing requests include continuity requirements, resource type combination requirements, and continuous occupancy time requirements, these misjudgments will further propagate to the alarm level. Conventional solutions struggle to distinguish these states, and alarm results are prone to deviating from actual integration capabilities.

[0004] Therefore, the main technical problem with existing technologies is that virtual resource fragmentation early warning still relies primarily on static statistical indicators such as capacity, number of fragments, or maximum consecutive fragments as the main basis for judgment. It lacks a structured expression of the integrable relationships between resource fragments and a mechanism for jointly verifying these relationships with subsequent request patterns. When resources are frequently requested, released, locked, and policy constraints change, the system may be unable to provide integrable resources that meet the conditions even when the remaining total amount is sufficient, or there may still be usable combined resources even when the number of fragments is high. Because existing alarm logic cannot identify states such as adjacent but not mergeable, scattered but combinable, or short-term available but unstable states, fragmentation alarms are prone to premature alarms, delayed alarms, or alarm jitter, making it difficult for warning signals to correspond to the actual risk of integration failure. The root cause of this technical problem is not an unreasonable single threshold setting, but rather the lack of a joint representation of fragment relationships, time conditions, compatibility conditions, and request constraints in alarm judgment. This prevents the abnormal state of the virtual resource pool from being converted into an alarm level with a clear risk source. Furthermore, as subsequent requests continue to change, the same resource pool state may correspond to different risk levels depending on the request pattern, and static statistical indicators are insufficient to achieve this correspondence. Summary of the Invention

[0005] The purpose of this invention is to provide a method for early warning of virtual resource fragmentation status integration, which can effectively solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] A method for integrating and warning about the fragmentation status of virtual resources includes: obtaining the occupancy status, locking status, estimated release time and compatibility tags of resource fragments in the virtual resource pool, and generating a resource fragment status sequence;

[0008] Based on the resource fragment state sequence, idle fragments, occupied fragments, fragments to be released, and restricted fragments are constructed as topological nodes, and adjacent relationships, similar merging relationships, time coincidence relationships, policy compatibility relationships, and restricted blocking relationships are constructed as topological edges to form an integrable domain topological graph.

[0009] The integrable domain topology graph is subjected to connected component identification and edge weight correction to obtain the integrable domain set;

[0010] Extract the request patterns from historical resource application records and current queued requests, match the request patterns with the set of integrable domains, generate fragmentation integration risk values, and trigger tiered early warning signals.

[0011] Preferably, generating the resource fragment state sequence includes: encoding the virtual resource fragments at the same granularity according to resource type, logical address range, fragment boundary, occupancy identifier, remaining lock duration, estimated release time, and compatibility tag;

[0012] Set status categories for consecutive occupied segments, consecutive idle segments, occupied segments awaiting release, and policy-restricted segments;

[0013] The segment codes within the same logical address range are versioned according to the state change time, and the boundary mapping relationship before and after the segment merging is preserved.

[0014] Write a pending confirmation status flag for any missing segments at the expected release time, and incorporate the pending confirmation status flag into the subsequent topology edge construction.

[0015] Preferably, forming the integrable domain topology graph includes: establishing adjacent topology edges with segments having the same resource type and whose boundaries can be connected; establishing strategy-compatible topology edges with segments with the same compatibility label or satisfying the compatibility mapping relationship; establishing time-overlapping topology edges with segments whose expected release time is in the same available time window; and establishing restricted blocking topology edges when the merging is blocked in a locked state, under an isolation policy, or with mutually exclusive labels.

[0016] Write the edge identifier, direction identifier, relationship type, and blocking source marker for each topological edge according to the fragment boundary order and release time order, and write the blocking object of the restricted blocking topological edge into the node index.

[0017] Preferably, obtaining the set of integrable domains includes: removing topological edges in the integrable domain topology graph that do not satisfy the constraints of compatibility label, release time window, and locked state;

[0018] Perform connected component partitioning on the remaining topological edges;

[0019] Within the connected domain, spurious continuous segments are split according to the positions of the restricted blocking topological edges, and the segments are logically dispersed by merging according to the time-overlapping topological edges.

[0020] For each integrable domain, record the capacity boundary, available time window, merging resistance, and stable duration, and write inter-domain association tags for candidate integrable domains to which the same topology node belongs. The inter-domain association tags include the shared node number and the candidate domain number.

[0021] Preferably, the versioned arrangement includes: recording the state changes caused by application, release, locking, re-occupancy and timeout reclamation within the same logical address range as a fragment version chain;

[0022] In the fragment version chain, write boundary inheritance markers and release inheritance markers for adjacent versions;

[0023] When a segment is divided into multiple sub-segments, the compatibility label, locking state, and expected release time of the parent segment are mapped to the sub-segment encoding respectively, and a backtracking index is generated for the sub-segments;

[0024] When multiple sub-segments re-form continuous boundaries, the boundary mapping relationship before merging is restored according to the backtracking index, and the restoration result is written to the merge record at the end of the version chain.

[0025] Preferably, the generation of the relationship type and blocking source marker includes: cross-validating the adjacent topological edges, the policy-compatible topological edges, and the time-overlapping topological edges between two topological nodes;

[0026] When an adjacency relationship is established but a compatible label conflict occurs, the topological edge is rewritten as a boundary blocking edge;

[0027] When the compatibility relationship is valid but the expected release times do not coincide, the topological edge is rewritten as a time mismatch edge;

[0028] When the locked state covers the available time window of any node, the topological edge is rewritten as a locked blocking edge;

[0029] Write the topological edges before and after the rewrite into the relation change chain respectively, and retain the original edge identifiers in the relation change chain.

[0030] Preferably, the recording of the merging resistance includes: generating a blocking sequence within each integrable domain according to the distribution positions of boundary blocking edges, time mismatch edges, and locking blocking edges;

[0031] The blocking sequence is bound to the capacity boundary and available time window of the integrable domain;

[0032] When different connected domains share the same compatible label and the expected release time overlaps, cross-domain candidate merge records are established and included in the candidate level of the integrable domain set;

[0033] In the candidate level, a candidate merging order is generated according to the number of cross-domain nodes and the type of blocking edge, and the correspondence between the candidate merging order and the blocking sequence is preserved.

[0034] Preferably, matching the request pattern with the set of integrable domains includes: extracting the request size, resource continuity requirements, resource type combination requirements, continuous occupancy time, and release tolerance window from historical resource request records and current queued requests;

[0035] Filter the integrable domains that meet the capacity boundary conditions according to the requested size;

[0036] Verify the topological edge types within the integrable domain according to the resource continuity requirements and resource type combination requirements;

[0037] The available time window is verified according to the duration of continuous occupation and the release tolerance window.

[0038] Write the unvalidated integrateable domains into the request failure mapping table.

[0039] Preferably, generating the fragmentation integration risk value includes: when the request form does not match any integrable domain, generating a capacity-type risk component according to the difference between the request size and the maximum capacity boundary;

[0040] When only an integrable domain with a boundary blocking edge is matched, a boundary blocking risk component is generated according to the position of the boundary blocking edge in the blocking sequence;

[0041] When only an integrable domain with an incomplete available time window is matched, a time mismatch risk component is generated according to the overlap relationship between the release tolerance window and the available time window;

[0042] According to the request failure mapping table, each risk component is combined into a fragmented integrated risk value.

[0043] Preferably, triggering the graded early warning signal includes: writing the capacity-type risk component, the boundary-blocking risk component, and the time mismatch risk component into the early warning state machine;

[0044] When the same request pattern maintains the same risk source in consecutive state versions, the corresponding level of warning signal is output according to the upgrade path of the warning state machine;

[0045] When the source of risk described in the subsequent state version disappears and the corresponding request form is rematched, the alert level is switched to a lower alert level according to the recovery path of the alert state machine.

[0046] Write the warning level, risk source, and identifier of the integrable domain that failed to match into the warning record.

[0047] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0048] 1. By integrating resource fragment status sequences, integrable domain topology graphs, request pattern matching, and hierarchical early warning signals into the same processing chain, virtual resource fragmentation early warning is transformed from static capacity judgment to status judgment based on integrable capability. Resource fragment status sequences describe fragments at the same granularity according to resource type, logical address range, occupancy identifier, remaining lock duration, expected release time, and compatibility label, providing a unified analytical basis for idle fragments, occupied fragments, fragments awaiting release, and restricted fragments. The integrable domain topology graph writes adjacent relationships, similar merging relationships, time coincidence relationships, policy compatibility relationships, and restricted blocking relationships into the topology edges, allowing merging and blocking conditions between fragments to be expressed in the same graph structure. Connectivity identification and edge weight correction can eliminate formally continuous connections restricted by compatibility labels, release time windows, or lock states, while retaining physically dispersed candidate integrable relationships with time coincidence and policy compatibility. Request pattern matching verifies request size, resource continuity requirements, resource type combination requirements, continuous occupancy time, and release tolerance window against the integrable domain set, shifting the alarm basis from whether resources are remaining to whether resources can meet specific request conditions. Fragmentation consolidation risk values ​​are generated based on capacity boundaries, blocking sequences, available time windows, and request failure mapping tables. This allows resource fragment status, consolidation constraints, and request conditions to be compressed into a single early warning judgment object. The resulting capacity-based risk components, boundary-blocking risk components, and time-mismatch risk components correspond to different sources of consolidation failure. The tiered early warning signals directly reflect the process of the virtual resource pool changing from a consolidable state to a consolidation-restricted state. Because the risk components originate from the matching results of consolidable domains and request patterns, states where the remaining total quantity is sufficient but the combination conditions are not met can be identified. States with a high number of fragments but still sufficient to meet requests will not be simply categorized as high-level alarms.

[0049] 2. A continuous data association is formed between the fragment version chain, relationship change chain, blocking sequence, candidate merge order, and request failure mapping table, enabling the tracking of changes in the fragmented state of virtual resources. The fragment version chain retains the boundary inheritance relationships caused by application, release, locking, re-occupancy, and timeout reclamation, allowing the restoration of the before-and-after state correspondence through backtracking indexes even after resource fragments are split or re-merged. The relationship change chain records the process of adjacent topological edges, policy-compatible topological edges, and time-coincident topological edges being rewritten as boundary blocking edges, time-mismatched edges, or locked blocking edges under conflict conditions, giving the topology changes a clear source. After the blocking sequence is bound to the capacity boundary and available time window of the integrable domain, the blocking positions within the integrable domain can be sorted and recorded. The candidate merge order associates the number of cross-domain nodes with the blocking edge type, avoiding treating all candidate domains as equally available resources. The request failure mapping table stores integrable domains that fail the checks of capacity boundary, topological edge type, continuous occupancy time, or release tolerance window, ensuring that subsequent risk component synthesis has a traceable data source. The alert state machine switches alert levels based on the persistence of risk sources in consecutive state versions. Once the risk source disappears and re-matching is completed, the alert level is lowered. This reduces alarm jumps caused by short-cycle release requests and retains the alert level, risk source, and integrable domain identifiers for failed matches. This data chain ensures that alarm records not only contain level values ​​but also the correspondence between fragment versions, topology relationships, and request matching results. When the same blocking source repeatedly appears in a resource pool across consecutive state versions, the alert state machine maintains the corresponding level. When the topology connection is restored and re-matching is successful, the alarm level changes according to the recovery path, reducing the interference of instantaneous fluctuations on alarm output. The corresponding records also provide a consistent data standard for subsequent resource management and anomaly review. Attached Figure Description

[0050] Figure 1 This is a flowchart illustrating the overall processing flow of the virtual resource fragmentation status integration and early warning method of the present invention.

[0051] Figure 2 This is a flowchart illustrating the generation process of the resource fragment state sequence and the integrable domain topology graph of the present invention.

[0052] Figure 3 This is a flowchart of the request pattern matching and hierarchical early warning triggering process of the present invention. Detailed Implementation

[0053] 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, not all, of the embodiments of the present invention. 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.

[0054] Please refer to Figure 1 This embodiment provides a method for early warning of virtual resource fragmentation status integration, which runs in the resource status processing flow of a virtual resource management platform. Each virtual resource fragment in the virtual resource pool is described by resource type, logical address range, fragment boundary, occupied status, locked status, estimated release time, and compatibility tag. After resource application, resource release, resource renewal, resource locking, resource unlocking, and resource reclamation events occur, the resource status processing flow obtains updated resource allocation records and converts idle fragments, occupied fragments, fragments to be released, and restricted fragments into a resource fragment status sequence. Each record in the resource fragment status sequence includes fragment number, resource type number, starting logical address, ending logical address, status category, remaining lock duration, estimated release time, compatibility tag set, and policy restriction flag. The resource status processing flow constructs an integrable domain topology based on the resource fragment status sequence. The diagram shows an integrable domain topology graph with resource fragments as topology nodes and adjacency relationships, similar merging relationships, time overlap relationships, policy compatibility relationships, and restricted blocking relationships between fragments as topology edges. Connectivity identification and edge weight correction are then performed on the integrable domain topology graph. Fragments that meet the merging conditions are included in the integrable domain set. Request size, resource continuity requirements, resource type combination requirements, continuous occupancy time, and release tolerance window are extracted from historical resource request records and current queued requests. These request patterns are matched with the integrable domain set to generate a fragmentation integration risk value, and a tiered warning signal is output by the warning state machine. This embodiment establishes a closed processing chain between resource status, fragment relationships, request conditions, and alarm levels, ensuring that virtual resource fragmentation alarms are judged based on whether resources meet the conditions for integrable allocation, avoiding alarm conclusions based solely on remaining capacity or the number of fragments.

[0055] In this embodiment, the resource fragment state sequence is formed in an event-driven manner. When the resource management platform receives a resource request event, it splits the occupied continuous interval into occupied fragments and remaining free fragments. When it receives a resource release event, it writes the release interval into the fragment to be released. After the release verification is completed, it updates the fragment to be released as a free fragment. When it receives a lock event, it writes the lock status and remaining lock duration to the corresponding fragment. When it receives a policy change event, it updates the compatibility tag and policy restricted flag. The resource state processing flow does not directly delete the fragment record before it was split, but generates a new fragment record and retains the mapping relationship between the boundaries of the fragments before and after. When there are multiple sources of change in the fragment state within the same processing cycle, the process is carried out according to the event. The occurrence times of events are sorted. If multiple events have the same occurrence time, they are written into the state sequence according to a fixed priority of occupancy change, locking change, release change, and tag change to avoid conflicting state descriptions of the same fragment within the same period. After the resource fragment state sequence is completed, it is grouped according to resource type and logical address range. The fragment records in each group are arranged in ascending order of starting logical address, and adjacent fragments are initially marked as to whether they belong to the same state category, have the same compatible tag, or have similar expected release times. The processing result of this embodiment enables the subsequent topology to directly read state records with uniform granularity, reducing data conflicts caused by fragmentation judgments from different event sources.

[0056] In this embodiment, the construction of the integrable domain topology map is not simply based on logical address adjacency, but also incorporates time availability and policy compatibility. The resource status processing flow identifies the relationship between any two candidate segments within the same resource type. When the endpoints of the logical address intervals of the two segments are consecutive or there is only a segment to be released in the middle, an adjacency relationship is written. When the resource types of the two segments are the same and their status categories can be converted to idle status in subsequent cycles, a similarity merging relationship is written. When the expected release times of the two segments are within the same available time window, a time overlap relationship is written. When the compatibility tag sets of the two segments satisfy a preset compatibility mapping table, a policy compatibility relationship is written. When any segment... When a locked state, isolation flag, mutual exclusion label, or policy-restricted flag exists and the merging path is blocked, a restricted blocking relationship is written. The edge attributes of the topology edge include relationship type, direction identifier, boundary order, release time order, blocking source, and candidate merging flag. The resource status processing flow retains the situation where multiple relationship types exist in parallel when constructing topology edges. For example, two segments can have both adjacent relationships and policy-compatible relationships at the same time, or they can have both adjacent relationships and restricted blocking relationships at the same time. This allows subsequent edge weight correction to be judged based on the complete set of relationships. The processing method of this embodiment can distinguish between formally continuous segments and integrable segments, so that the division of integrable domains is not limited by a single address continuity.

[0057] The basic edge weight of any candidate topological edge in the integrable domain topology graph is calculated according to the following formula:

[0058] ;

[0059] in, Indicates the first The segment and the first The basic edge weights between segments This indicates an adjacency flag; the value is 1 if the addresses are adjacent, and 0 if they are not adjacent. This indicates a compatibility flag. The compatibility flag is set to 1 if the compatibility mapping table is satisfied, and 0 if it is not. The time coincidence flag indicates that the estimated release time falls within the same available time window; it is set to 1 if the estimated release time is within the same available time window, and 0 otherwise. This represents a blocking flag; it is set to 1 if there is a locked, isolated, or mutually exclusive blocking state, and to 0 if no such state exists. , , , These represent the calculation coefficients corresponding to address adjacency, policy compatibility, time coincidence, and blocking conditions, respectively. Used to prune candidate connections that have blocking relationships, for example when , , , When the two fragment addresses are adjacent, compatible, time-overlapping, and there is no blocking, When two fragment addresses are adjacent, compatible but subject to locking and blocking, and their times do not overlap, The calculation results are used for subsequent connected component filtering and edge weight correction.

[0060] In this embodiment, connected component identification and edge weight correction take basic edge weights as input and combine edge attributes to divide the integrable domain. The resource state processing flow uses topological edges with basic edge weights greater than a preset connectable benchmark as candidate connecting edges and topological edges with restricted blocking relationships and whose blocking markers are true as strong blocking edges. When performing connected component identification, candidate connecting edges are used to connect adjacent nodes or compatible nodes, and strong blocking edges are used to cut off false merge paths within the same logically continuous interval. If a connected component has temporally coincident relationships but no address adjacency relationships, the resource state processing flow registers the corresponding segment as a logically composable segment. If a connected component has address adjacency relationships but also has... In the case of compatibility conflicts or lockouts, the resource status processing flow splits the corresponding segments into different integrable domains. After the connected domains are identified, the capacity boundary, available time window, merging resistance, stability duration, and candidate domain number are recorded for each integrable domain. The capacity boundary is obtained by accumulating the capacity of available segments within the domain. The available time window is obtained by the intersection of the expected release times of segments within the domain. The merging resistance is determined by the number, location, and type of blocking edges. The stability duration is limited by the earliest release change time and the earliest lock expiration time of segments within the domain. This embodiment can obtain available continuous integrable domains and composable distributed integrable domains from the same topology graph, so that subsequent request matching has clear resource candidate objects.

[0061] In this embodiment, the request form is extracted from historical resource request records and current queued requests. Historical resource request records provide a reference for request size distribution, duration of occupancy distribution, resource type combination methods, and continuity requirements. Current queued requests provide resource conditions that need to be met immediately. The resource status processing flow generates a request form record for each request. The request form record includes the request number, request size, required resource type, whether a continuous interval is required, whether scattered combinations are allowed, duration of occupancy, release tolerance window, and compatibility label requirements. The resource status processing flow matches the request form record with the set of integrable domains item by item. When the capacity boundary of an integrable domain is lower than the specified threshold, the request form is processed accordingly. When the requested size is insufficient, the recording capacity is insufficient; when the blocking sequence within the integrable domain conflicts with the continuity requirement, the recording continuity is insufficient; when the available time window of the integrable domain cannot cover the continuous occupancy time and release tolerance window, the recording time is insufficient; when the set of compatible tags of the integrable domain cannot meet the request's compatible tag requirements, the recording compatibility is insufficient. All failed matching records are written to the request failure mapping table, and all successful matching records are written to the candidate satisfaction table. The correspondence between the integrable domain number and the request number is retained in the candidate satisfaction table. This embodiment makes the alarm triggering basis directly come from the matching result between the request conditions and the integrable domain, avoiding the mistaken assumption that the total amount of resources is sufficient as an allocable state.

[0062] In this embodiment, the fragmentation integration risk value is generated jointly by the request failure mapping table and the candidate satisfaction table. If the request form does not match any integrable domain, a capacity-type risk component is generated based on the difference between the request size and the maximum capacity boundary. If the request form only matches an integrable domain containing a boundary blocking edge, a boundary blocking-type risk component is generated based on the position and continuity requirements of the boundary blocking edge in the blocking sequence. If the request form only matches an integrable domain with an incomplete available time window, a time mismatch-type risk component is generated based on the overlap between the release tolerance window and the available time window. If the failure source corresponding to the request form contains multiple... The risk type is synthesized according to the source of the risk component and the importance of the request. The resource status processing flow inputs the fragmented integrated risk value into the early warning state machine. The early warning state machine outputs a graded early warning signal of observation, prompt, alert or blocking level based on whether the risk source is consistent in the continuous status version, whether the request form is still not matched, and whether the integrable domain identifier is continuously invalid. The early warning record includes the early warning level, risk source, integrable domain identifier of the failed match, request number, status version number and occurrence time. This embodiment enables the early warning output to have status source and matching source, and the alarm level changes together with the topology relationship and request form.

[0063] The risk value of fragmented integration is calculated using the following formula:

[0064] ;

[0065] in, Indicates the risk value of fragmented integration. Indicates the capacity-based risk component. This indicates the risk component that blocks the boundary. This indicates the risk component related to time mismatch. Indicates that the component failed to match. , , , These represent the composition coefficients of each component. Their values ​​are determined by the early warning strategy table of the resource management platform and remain unchanged within the same calculation cycle. For example, when the size of a request is 80 and the maximum capacity boundary is 70, it can be set as follows: The continuity requirement can be set when the second boundary blocking edge cuts off the connection. When the release tolerance window and the available time window do not overlap, it can be allowed When the compatibility tag is satisfied, it can be made ,when , , , hour, This value is used as the input for switching the level of the early warning state machine.

[0066] Preferably, refer to Figure 2 The generation process of resource fragment state sequences uses the same granularity encoding, with resource type and logical address range as the primary key, fragment boundaries as the positioning basis, and state category and additional state fields as dynamic content. When reading virtual resource allocation records, the resource state processing flow converts the resource type into an internal type number, the logical address range into a closed or half-open boundary, the occupancy identifier into an idle, occupied, pending release, or restricted state category, the remaining lock duration into a countdown field relative to the current processing cycle, the estimated release time into a time window index, and the compatibility tag into a tag bitmap or tag set. If a... If a fragment is simultaneously marked as both pending release and restricted, the status category is set to pending release, and the restricted policy flag is retained as an additional field. If the expected release time is missing, a pending confirmation status flag is written, and participation in the construction of time-overlapping relationships is restricted. If the compatibility tag is missing, only fragments with the same inherited tag are allowed to establish candidate compatibility relationships. The resource status processing flow sets status categories for consecutive occupied fragments, consecutive free fragments, pending release occupied fragments, and restricted policy fragments within the same logical address range, and arranges them in a versioned manner according to the status change time. This embodiment uses unified fields and unified granularity to ensure stable input for subsequent topology edge construction.

[0067] In this embodiment, the versioned arrangement of fragments is used to preserve the correspondence between state changes. The resource state processing flow establishes a fragment version chain for state changes caused by application, release, locking, re-occupancy, and timeout reclamation within the same logical address range. Each version record in the fragment version chain includes a version number, fragment number, parent fragment number, child fragment number, boundary inheritance flag, release inheritance flag, compatibility tag inheritance flag, and state change source. When a fragment is divided into multiple sub-fragments, the resource state processing flow maps the compatibility tag, locking state, and expected release time of the parent fragment to the encoding of each sub-fragment and generates a backtracking index based on the segmentation boundary. When multiple sub-fragments re-form a continuous boundary, the resource state processing flow restores the boundary mapping relationship before merging according to the backtracking index and writes the merging result to the merging record at the end of the fragment version chain. If a sub-fragment has undergone a locking change or compatibility tag change before merging, the merging record retains the change source flag of the sub-fragment to prevent the merged fragment from losing blocking information. This embodiment can maintain continuous tracking of boundaries, time, and compatibility conditions when resource fragments are frequently split and merged.

[0068] In a preferred embodiment, the resource status processing flow uses the status fields shown in Table 1 to encode resource fragments. The fields in Table 1 are not limited to a fixed storage structure and can be implemented in the form of database tables, key-value records, or memory objects. The relationships between the fields just need to be consistent. The fragment number is used to establish topology nodes, the boundary field is used to determine the adjacency relationship, the status category is used to distinguish between free fragments, occupied fragments, fragments to be released, and restricted fragments, the estimated release time is used to construct time-overlapping relationships, the compatibility tag is used to construct policy-compatible relationships, the locking field and the restricted field are used to construct restricted blocking relationships, and the version field is used to maintain the status change link. In this embodiment, the field-based encoding enables resource statuses from different sources to enter the same topology processing flow.

[0069] Table 1. Comparison of Resource Status Processing Field Attributes and Topology Processing

[0070]

[0071] The status fields in Table 1 are written according to the event time within the same processing cycle. After reading the fields, the resource status processing flow does not directly generate alarms based on the status category. Instead, it converts the fields into topology nodes and topology edges. The remaining lock duration and the expected release time jointly determine the time availability. The compatibility label and the resource type number jointly determine the policy compatibility. The start logical address and the end logical address jointly determine the address adjacency. The version number is used to track whether field changes are repeated within consecutive processing cycles. If the same segment maintains the same blocking source in two consecutive versions, the subsequent warning state machine will treat the blocking source as a continuous risk source. This embodiment can support the identification of integrable domains and the backtracking of risk sources at the data structure level.

[0072] Furthermore, the topology edge construction process uses cross-validation to generate relation types and blocking source tags. The resource status processing flow first reads the address boundaries between any two candidate topology nodes. If the terminating logical address of the first segment is continuous with the starting logical address of the second segment, an adjacent topology edge is generated. Then, the compatible label set is read. If the two label sets satisfy any mapping relationship in the compatible mapping table, a policy-compatible topology edge is generated. Next, the expected release time and release tolerance window are read. If the available time of two segments overlaps, a time-overlapping topology edge is generated. If the locked state covers the available time window of any segment, or the isolation policy prohibits the merging of two segments, or... If there is a conflict between mutually exclusive labels, a restricted blocking topology edge is generated. The resource status processing flow does not overwrite existing relationships in the generation order, but retains multiple relationship types in the same topology edge attribute and writes a relationship change chain in the edge attribute. The relationship change chain records the original edge identifier, the original relationship type, the rewritten relationship type, and the blocking source mark. If an adjacent relationship is established but the compatibility label conflicts, it is rewritten as a boundary blocking edge. If a compatible relationship is established but the expected release time does not coincide, it is rewritten as a time mismatch edge. If the locked state covers the available time window of any node, it is rewritten as a locked blocking edge. This embodiment can avoid fragments being directly identified as integrateable due to the satisfaction of a single condition.

[0073] In this embodiment, the relationship change chain is used to support the generation of subsequent blocking sequences. The resource state processing flow retains the original edge identifier each time the edge relationship is rewritten, so that the state changes of the same topological edge can be tracked. If the original adjacent topological edge is rewritten as a boundary blocking edge due to compatibility conflict, the conflict label number and the numbers of the two affected topological nodes are written into the relationship change chain. If the original time coincident topological edge is rewritten as a time mismatch edge due to the re-estimation of the release expected time, the original time window index and the new time window index are written into the relationship change chain. If the original policy compatible topological edge is rewritten as a locked blocking edge due to the extension of the locked state, the locking source event number and the remaining lock duration are written into the relationship change chain. When the resource state processing flow reconstructs the topological edge in the next state version, it reads the relationship change chain and compares the new relationship corresponding to the same edge identifier with the relationship of the previous version. If the blocking source is the same, it is marked as continuous blocking. If the blocking source changes, it is marked as transition blocking. This embodiment can provide the early warning state machine with the risk source retention status in continuous state versions.

[0074] The capacity boundary of the integrable domain is obtained according to the following formula:

[0075] ;

[0076] in, Indicates the first The capacity boundary of an integrable domain. Indicates the first A set of fragments in an integrable domain Indicates the first The segment length is obtained by subtracting the starting logical address from the ending logical address. Indicates the first The availability flag for each segment is set to 1 when it is free and unrestricted, 1 when it is pending release and the expected release time is within the available time window, and 0 when it is occupied and not released or blocked by a lock. For example, if a mergeable domain contains 3 segments with segment lengths of 30, 20, and 15, where the first two segments are available and the third segment is unavailable due to a lock, then... This capacity boundary is used to match the size of the request.

[0077] Furthermore, the process of generating the integrable domain set handles spurious continuous fragments and logically scattered fragments separately. The resource state processing flow performs connected component partitioning after removing topological edges that do not meet the constraints of compatible labels, release time windows, and locked states. If there are restricted blocking topological edges within a connected component, the connected component is split into multiple integrable domains according to the position of the restricted blocking topological edges. During splitting, the node numbers on both sides of the restricted blocking topological edges are retained and written into the blocking sequence. If there are time-coincident topological edges within a connected component and the fragments connected by these topological edges are not in adjacent address ranges, they are processed as logically scattered fragments. The resource state processing flow... The process registers two fragments as the same candidate integrable domain but marks them as non-contiguous combinations. Non-contiguous combinations can only match request patterns that allow for dispersed combinations. If there are adjacent topological edges and time-overlapping topological edges within a connected domain, a continuous integrable domain is generated first, and then a candidate combination domain is generated to avoid the same fragment being repeatedly calculated in multiple candidate domains. The resource status processing flow is to write the candidate integrable domains to which the same topological node belongs into the inter-domain association marker. The inter-domain association marker includes the shared node number, the candidate domain number, and the candidate domain priority. This embodiment can maintain the consistency of the integrable domain set when there is an overlap in candidate resources.

[0078] In this embodiment, merging resistance is recorded according to the blocking sequence, capacity boundary, and available time window. The resource status processing flow reads the distribution positions of boundary blocking edges, time mismatch edges, and locking blocking edges along the logical address direction within each integrable domain and arranges them into a blocking sequence. Each item in the blocking sequence includes the blocking edge number, blocking edge type, preceding node number, following node number, blocking source, and associated request continuity requirements. If two different connected domains share the same compatibility label and their expected release times overlap, the resource status processing flow establishes a cross-domain candidate merging record. The cross-domain candidate merging record includes the number of cross-domain nodes, shared compatibility label, overlapping time window, candidate merging order, and candidate level number. In the candidate level, the resource status processing flow generates a candidate merging order in the order of fewer cross-domain nodes, fewer blocking edge types, and longer available time window coverage. However, the candidate merging order is not directly used as an alarm result. Instead, it is input into the risk calculation along with the request pattern matching result. This embodiment enables the blocking positions and candidate paths in the resource integration process to be recorded, reducing the situation where candidate resources are regarded as equally available resources.

[0079] In a preferred embodiment, the blocking sequence and candidate merging order are recorded according to Table 2. Each row in Table 2 corresponds to an integrable domain or a candidate cross-domain merging record. Before request matching, the resource status processing flow reads the capacity boundary, available time window, blocking sequence and candidate merging order in Table 2. If the request requires a continuous interval, the candidate with boundary blocking edge is marked as not satisfying continuity. If the request allows scattered combination, the candidate with time coincidence relationship continues to participate in matching. If the request continues to occupy time for more than the available time window, the candidate is marked as not satisfying time. This embodiment enables request matching to directly reference the internal constraints of the integrable domain through structured records.

[0080] Table 2 Comparison of Resource Integrability Domain Constraint Parameters and Merging Rules

[0081]

[0082] The records shown in Table 2 are regenerated or partially updated after each state version update. If the resource fragment state sequence only changes locally, the resource state processing flow locates the affected nodes according to the version number and only recalculates the integrable domains containing the affected nodes. The domain numbers and blocking sequences of unaffected domains remain unchanged. If a blocking edge persists in consecutive state versions, the blocking source in the blocking sequence is marked as a persistent source. If a candidate merging order fails due to a change in release time, the candidate merging order is moved to the failure record and stops participating in request matching. The matching restriction fields in Table 2 are jointly determined by the topology relationship and request constraints. They cannot be used as separate alarm conditions and must be entered into the request failure mapping table to participate in risk component generation. This embodiment enables the integrable domain information to remain continuous between state versions, avoiding the loss of the risk source of the previous version after each scan.

[0083] Further, refer to Figure 3 The request form matching process adopts a layered verification method. The resource status processing flow generates a request form record for each currently queued request and extracts historical request forms of the same type as the current request from historical resource application records as a verification supplement. If the current request lacks a release tolerance window, the median value of the release tolerance window of the same type of historical request is used as the field to be confirmed. The field to be confirmed is marked separately in the alarm record. During matching, the request size is first used to filter the integrable domains that meet the capacity boundary conditions. Then, the resource continuity requirement is used to verify whether there are boundary blocking edges inside the integrable domain. Next, the resource type combination requirement is used to verify the fragment resource types and compatibility tags within the domain. Finally, the continuous occupancy time and release tolerance window are used to verify the available time window. If all verifications pass, the request number, domain number, and matching conditions are written into the candidate satisfaction table. If any verification fails, the failure reason, failure domain number, and corresponding field are written into the request failure mapping table. When multiple failure reasons exist at the same time, they are written in a fixed record order of capacity non-compliance, continuity non-compliance, time non-compliance, and compatibility non-compliance. This embodiment ensures that each matching failure has a specific field source.

[0084] In this embodiment, the request failure mapping table not only stores failure conclusions but also the correspondence between failure conclusions and the structure of integrable domains. Records of capacity non-compliance include request size, maximum capacity boundary, and difference; records of continuity non-compliance include boundary blocking edge number, blocking location, and associated segment number; records of time non-compliance include available time window, continuous occupancy time, and release tolerance window; and records of compatibility non-compliance include request compatibility label, intra-domain compatibility label, and conflict label number. When the resource status processing flow generates risk components based on the request failure mapping table, it merges failure records of the same request in multiple integrable domains. If all integrable domains have capacity non-compliance, a capacity-type risk component is generated. If there is a domain with sufficient capacity but insufficient continuity, a boundary blocking-type risk component is generated. If there is a domain with sufficient capacity and sufficient continuity but insufficient time window, a time mismatch-type risk component is generated. If there is a domain with sufficient capacity, sufficient continuity, and sufficient time but insufficient compatibility label, a compatibility matching failure component is generated. This embodiment can limit the alarm source to the technical conditions that the actual blocking request in the matching chain meets.

[0085] The degree of overlap of time windows is calculated according to the following formula:

[0086] ;

[0087] in, Indicates the first The request and the first The length of available time overlap between integrable domains Indicates the first The start time at which each request is allowed to begin occupying space. Indicates the first Each request is allowed to terminate the matching at the end of the release tolerance window. Indicates the first The start time of the available time window for each integrable domain. Indicates the first The end time of the available time window for each integrable domain. This means taking the smaller of the two values. This indicates taking the larger of two values. For example, if a request's allowed time window is 10 to 25, and a consolidable domain's available time window is 18 to 30, then... If the available time window for another integrable domain is 30 to 40, then The overlap length is used to determine whether the continuous occupancy time can be covered.

[0088] Furthermore, the triggering process of the early warning state machine adopts dual conditions of state version and risk source. The resource state processing flow writes capacity-type risk components, boundary blocking-type risk components, time mismatch-type risk components, and compatibility matching failure components into the early warning state machine. The early warning state machine uses the request number and resource type number as state keys and the risk source in consecutive state versions as the transition condition. When the same request form maintains the same risk source in consecutive state versions, the early warning state machine outputs a higher-level early warning signal along the upgrade path. When the risk source disappears in subsequent state versions and the corresponding request form completes re-matching, the early warning state machine switches to a lower early warning level along the recovery path. When the risk source changes from capacity insufficiency to boundary blocking or time mismatch, the early warning state machine does not directly clear the previous risk source, but writes the risk source transfer record into the early warning record. The early warning record includes the early warning level, risk source, identifier of the integrable domain that failed to match, request number, state version number, and relationship change chain number. This embodiment can maintain the continuity of alarm status when resource status fluctuates in a short period of time, so that alarm changes correspond to changes in risk sources.

[0089] In a preferred embodiment, the early warning state machine includes five states: normal, observation, alert, warning, and blocking. The normal state indicates that the current request form has at least one fully matching integrable domain. The observation state indicates that the request form is not fully matched but there are candidate merging sequences that can satisfy the dispersed combination request. The alert state indicates that the request form only has candidate domains that meet the capacity requirements but have boundary blocking or time mismatch. The warning state indicates that the same risk source persists in consecutive state versions and the candidate satisfaction table is empty. The blocking state indicates that the request form does not have an integrable domain that meets the capacity boundary requirements in the current processing cycle and the same failure source has been recorded as a persistent source. The state switching of the early warning state machine does not depend on a single risk value exceeding a fixed line, but rather reads the risk component source, consecutive version flag, and rematch result. If the risk source disappears but the request has not yet completed rematching, the state machine maintains its original state and writes a pending recovery flag. If the request completes rematching and there are available domains in the candidate satisfaction table, the state machine lowers its state along the recovery path. This embodiment can reduce alarm jumps when request release events occur frequently.

[0090] In this embodiment, the working principle of the resource status processing flow can be summarized as transforming the fragmented state from a problem of fragment quantity into a problem of fragment relationships and request fulfillment. The resource fragment status sequence provides node attributes, the integrable domain topology graph provides merging and blocking conditions between fragments, connected component identification and edge weight correction provide a set of integrable domains that can be used for matching, the request form provides the actual constraints of resource allocation, the risk component provides the input to the alarm state machine, and the early warning record provides the tracking path of the risk source. If any link only uses capacity or quantity information, it is impossible to distinguish between adjacent but unmergeable fragments and scattered but combinable fragments. If any link only uses request information without topological relationships, it is impossible to determine whether the request failure is caused by capacity, boundary, time, or compatibility conditions. This embodiment ensures that each alarm level is jointly defined by resource fragments, topological relationships, request conditions, and status versions, and can form a complete processing chain around the risk of virtual resource fragmentation integration failure.

[0091] Furthermore, in implementing this embodiment, the resource management platform can adopt a combination of batch processing and incremental processing. Batch processing is used to rebuild the topology of all integrable domains within a fixed period, while incremental processing is used to update affected nodes and topology edges after a single application, release, lock, or label change event occurs. Incremental processing locates the affected logical address range through the fragment version chain, locates the edge attributes that need to be recalculated through the relationship change chain, locates the affected integrable domains through the inter-domain association marker, and locates the request form that needs to be rematched through the request failure mapping table. Unaffected fragment records, topology edge records, integrable domain records, and warning status records remain unchanged. If a new boundary blocking edge or time mismatch edge appears in the relationship change chain after the incremental update, the resource status processing flow only recalculates the merging resistance and capacity boundary for the integrable domain containing the edge and puts the relevant request back into the matching queue. This embodiment can reduce redundant graph construction while maintaining data consistency, and synchronize the warning results with the current resource status.

[0092] In a preferred embodiment, the compatibility mapping table is generated by the resource policy configuration of the resource management platform. The compatibility mapping table records the composable relationships between different resource types, isolation policies, usage policies, and tag sets. When constructing policy-compatible topology edges, the resource status processing flow reads the compatibility mapping table. If two segments have the same compatibility tag, a policy-compatible topology edge is directly established. If two segments have different compatibility tags but have a mapping relationship in the compatibility mapping table, a policy-compatible topology edge with a mapping number is established. If two segments have mutually exclusive compatibility tags, a restricted blocking topology edge is established and the mutually exclusive tag number is written. When the compatibility mapping table is updated, the resource status processing flow does not rewrite the entire segment status sequence, but recalculates the policy-compatible topology edges and restricted blocking topology edges corresponding to the affected tags and writes the relationship change into the relationship change chain. Subsequent requests read the new topology edge attributes to complete the re-verification. This embodiment enables policy condition changes to be reflected in the integrable domain set.

[0093] In this embodiment, the processing of the estimated release time adopts an available time window instead of a single moment. The resource status processing flow generates an available time window for the fragment based on the release event, the re-occupancy event, and the locking event. The available time window includes a start time, an end time, and a confirmation flag. When the fragment is in a state to be released and the release verification has not yet been completed, the start time is the estimated release time, the end time is the estimated time when it may be occupied or locked next, and the confirmation flag is true. When the fragment is in an idle state and there is no locking constraint, the start time is the current processing cycle, and the end time is an unrestricted state. When the fragment is in a locked state, the start time is the lock end time, and the end time is determined according to the estimated release time or the resource strategy. When constructing time-overlapping topology edges, the resource status processing flow only allows time windows with a false confirmation flag to directly participate in strong connections. Time windows with a true confirmation flag can only participate in candidate connections and have the confirmation source written in the request failure mapping table. This embodiment can avoid unconfirmed release states being directly treated as available resources.

[0094] Furthermore, when extracting request forms from historical resource application records, similar requests are aggregated. The resource status processing flow divides historical requests into multiple request templates according to resource type combinations, continuity requirements, and continuous occupancy time ranges. When a current queued request arrives, it first matches the corresponding request template, and then writes the specific scale and release tolerance window of the current request into the request form record. If the current request is inconsistent with any historical request template, the current request is used as a new template and only the current field is used for matching. Historical request templates do not replace the current request fields, but only supplement the missing release tolerance window or resource type combination constraints of the current request. After the request is matched, the resource status processing flow records the actual matching result of the current request and uses it as the data source for subsequent request template updates. This embodiment makes the request form updatable and avoids the explicit condition of historical data overwriting the current request.

[0095] In this embodiment, the capacity-type risk component is calculated from the difference between the request size and the capacity boundary of the integrable domain; the boundary blocking-type risk component is calculated from the position of the blocking edge in the blocking sequence; the time mismatch-type risk component is calculated from the overlap length between the request time window and the available time window of the integrable domain; and the compatibility matching failure component is calculated from the number of conflicts between the request compatibility label and the compatibility label within the domain. The resource status processing flow normalizes the above components and then inputs them into the risk value formula. The normalization process is only performed within the same resource type and the same processing cycle to prevent the difference in capacity units of different resource types from affecting the calculation of the same risk value. If a request allows for dispersed combinations, the boundary blocking-type risk component is generated only when the blocking edge affects the resource type combination requirement. If a request requires a continuous interval, any boundary blocking edge within the target interval of the request generates a boundary blocking-type risk component. This embodiment keeps the risk components consistent with the request constraints.

[0096] In a preferred embodiment, the candidate merging order is used to assist in matching scattered combination requests. The resource status processing flow generates a candidate merging order at the candidate level according to the number of cross-domain nodes, the type of blocking edge, and the available time window. The candidate merging order does not change the actual allocation status of the resource fragments, but only serves as a combination candidate when matching requests. If the request allows scattered combination and all nodes in the candidate merging order meet the compatibility label and time overlap conditions, the candidate integrable domain corresponding to the candidate merging order is entered into the candidate satisfaction table. If there is a pending confirmation time window or a locked blocking edge in the candidate merging order, the candidate integrable domain is entered into the request failure mapping table and the corresponding failure source is recorded. The resource status processing flow rereads the candidate merging order in subsequent status versions. If the pending confirmation time window becomes confirmed available, the candidate integrable domain participates in the matching again. If the locked blocking edge continues to exist, the candidate merging order is retained but marked as a blocking candidate. This embodiment enables scattered composable resources to be included in the early warning judgment, while not mistaking candidate combinations that do not meet the conditions as available resources.

[0097] In this embodiment, the generation of the warning record includes a status version number, resource type number, request number, integrable domain number, risk source, risk component, warning level, and recovery flag. At the end of each processing cycle, the resource status processing flow compares the current warning record with the warning record of the previous status version. If the request number and risk source are the same and the integrable domain number is the same, a persistence flag is written. If the request number is the same but the risk source is different, a transfer flag is written. If the request number disappears or the request is successfully matched, a recovery candidate flag is written. The recovery candidate flag is converted to a recovery flag only when the candidate satisfaction table is not empty in the next status version. The warning state machine performs level switching based on the persistence flag, transfer flag, and recovery flag. The warning record retains the identifier of the integrable domain that failed to match, so that subsequent review can read the corresponding fragment version chain, relationship change chain, and request failure mapping table. This embodiment can keep the alarm record consistent with the underlying resource relationship.

[0098] Furthermore, when the resource pool has sufficient remaining capacity but the request cannot be matched during a continuous processing cycle, the resource status processing flow will not directly output a resource shortage alarm. Instead, it will read the request failure mapping table to determine the source of the failure. If the maximum capacity boundary meets the request size but the boundary blocking edge cuts off the continuous interval required by the request, a boundary blocking type warning will be output. If both the capacity boundary and continuity are met but the available time window cannot cover the continuous occupancy time, a time mismatch type warning will be output. If the capacity, continuity, and time are all met but the compatibility label conflicts, a compatibility matching type warning will be output. If the capacity boundaries of all integrable domains are lower than the request size, a capacity type warning will be output. This embodiment can distinguish different alarm types under the same resource pool status, so that the warning result corresponds to the specific source of integration failure.

[0099] In a preferred embodiment, when the number of resource pool fragments is high but there are still integrable domains that satisfy the request pattern, the resource status processing flow does not directly upgrade the warning level due to the high number of fragments. Instead, it writes the number of fragments as a status reference field into the warning record. If the request pattern can match an integrable domain with a stable duration, the warning state machine remains in normal or observation state. If the matched integrable domain depends on a fragment to be confirmed for release, the warning state machine enters the observation state and writes the source to be confirmed. If all candidate domains in the candidate satisfaction table depend on the same fragment to be released, the warning state machine retains a single-point dependency mark and waits for the next state version to be updated based on the release confirmation result. This embodiment avoids using the number of fragments to replace the integrability judgment, making the alarm level depend on whether the request pattern can be satisfied by the resource relationship.

[0100] Furthermore, when matching multiple requests simultaneously, the resource status processing flow adopts a request queue snapshot method. At the beginning of the processing cycle, the current queued request set is fixed, and a request form record is generated for each request. During the matching process, the same integrable domain can be used as a candidate domain record for multiple requests at the same time. However, the correspondence between the request number and the candidate domain number is retained when synthesizing risk components. If multiple requests depend on the same integrable domain, the resource status processing flow writes a shared candidate flag for that integrable domain. The early warning state machine does not use the shared candidate flag as an alarm condition alone, but updates the candidate satisfaction table after reading the actual resource application results in subsequent processing cycles. If the shared candidate domain is occupied by one of the requests, causing other requests to fail, the relationship change chain and the request failure mapping table record the new capacity boundary and failure source. This embodiment can handle candidate resource conflicts when queued requests exist in parallel.

[0101] In this embodiment, all variables in the formulas maintain a unique meaning within the same description text, and the basic edge weights... It only indicates the degree of topological connectivity between segments, and the capacity boundary. This only indicates the capacity of the integrable domain that can be used for matching, and the time window overlap length. This only indicates the time coverage relationship between the request and the integrable domain; fragmented integration risk value. This only represents the risk input of the early warning state machine. When implementing the resource status processing flow, the calculation results corresponding to the above variables can be written into the same state version record. The basic edge weight is used for graph construction, the capacity boundary is used for capacity screening, the time window overlap length is used for time verification, and the fragmented integrated risk value is used for early warning state machine switching. The calculation results do not replace each other. This embodiment keeps the logical relationship between integrable domain identification, request matching, and hierarchical alarm clear by fixing the meaning of variables and calculation links.

[0102] In this embodiment, the virtual resource fragmentation status integration and early warning method can be applied to virtual resource pools that include computing quotas, storage quotas, network quotas, address ranges, or session quotas. However, the implementation objects are still logical resource fragments and their status records. It does not require the addition of collection structures unrelated to resource management. The resource status processing flow can construct the resource fragment status sequence by reading the existing resource allocation table, resource locking table, release record table, and request queue list. If the resource pool contains only a single type of resource, the resource type combination requirement degenerates into a single resource type requirement. The policy compatibility topology edge can still be constructed based on the compatibility label. If the resource pool contains multiple types of resources, the resource type combination requirement participates in request form matching. The resource status processing flow does not change the core processing link. This embodiment has processing consistency that adapts to different virtual resource types and can output early warning records around the integration risk of resource fragments.

[0103] In this embodiment, the early warning output obtained at the end of the implementation includes a graded early warning signal and an early warning record. The graded early warning signal is used to indicate the current integration risk level of the virtual resource pool, and the early warning record is used to save the source of risk and the failed matching objects. The resource status processing flow obtains a unified status input through the resource fragment status sequence, expresses the mergeable conditions and blocking conditions between fragments through the integrable domain topology graph, obtains the integrable domain set through connected component identification and edge weight correction, determines whether the resource combination can meet subsequent requests through request pattern matching, and generates an alarm level through risk components and state machine. The advantage of this embodiment is that it can incorporate the remaining total amount, fragment fragments, time window, compatibility label, locked status and request conditions into the same judgment chain, so that the alarm result corresponds to the virtual resource integration failure risk, rather than corresponding to a single capacity or quantity indicator.

Claims

1. A method for early warning of virtual resource fragmentation status integration, characterized in that, include: Obtain the occupancy status, locking status, estimated release time, and compatibility tag of resource fragments in the virtual resource pool, and generate a resource fragment status sequence; Based on the resource fragment state sequence, idle fragments, occupied fragments, fragments to be released, and restricted fragments are constructed as topology nodes, and adjacent relationships, time coincidence relationships, policy compatibility relationships, and restricted blocking relationships are constructed as topology edges to form an integrable domain topology graph. This includes: establishing adjacent topology edges with fragments of the same resource type and whose boundaries can be connected; establishing policy compatible topology edges with fragments with the same compatibility label or satisfying compatibility mapping relationships; establishing time coincidence topology edges with fragments whose release expected time is in the same available time window; and establishing restricted blocking topology edges when the fragments are locked, under isolation policies, or when mutually exclusive labels block merging. Write the edge identifier, direction identifier, relationship type, and blocking source marker for each topological edge according to the fragment boundary order and release time order, and write the blocking object of the restricted blocking topological edge into the node index; Connectivity identification and edge weight correction are performed on the integrable domain topology graph to obtain an integrable domain set, including: removing topological edges in the integrable domain topology graph that do not meet the constraints of compatibility label, release time window and locked state. Perform connected component partitioning on the remaining topological edges; Within the connected domain, spurious continuous segments are split according to the positions of the restricted blocking topological edges, and the segments are logically dispersed by merging according to the time-overlapping topological edges. For each integrable domain, record the capacity boundary, available time window, merging resistance, and stable duration, and write inter-domain association markers for candidate integrable domains belonging to the same topology node. The inter-domain association markers include shared node numbers and candidate domain numbers. Extracting the request patterns from historical resource application records and current queued requests, and matching the request patterns with the set of integrable domains, includes: extracting request size, resource continuity requirements, resource type combination requirements, continuous occupancy time and release tolerance window from historical resource application records and current queued requests; Filter the integrable domains that meet the capacity boundary conditions according to the requested size; Verify the topological edge types within the integrable domain according to the resource continuity requirements and resource type combination requirements; The available time window is verified according to the duration of continuous occupation and the release tolerance window. Write the unvalidated integrateable domains into the request failure mapping table; Generating fragmented integration risk values ​​and triggering tiered early warning signals includes: when the request form does not match any integrable domain, generating a capacity-type risk component based on the difference between the request size and the maximum capacity boundary; When only an integrable domain with a boundary blocking edge is matched, a boundary blocking risk component is generated according to the position of the boundary blocking edge in the blocking sequence; When only an integrable domain with an incomplete available time window is matched, a time mismatch risk component is generated according to the overlap relationship between the release tolerance window and the available time window; According to the request failure mapping table, each risk component is combined into a fragmented integrated risk value.

2. The virtual resource fragmentation status integration and early warning method according to claim 1, characterized in that, Generating the resource fragment state sequence includes: encoding the virtual resource fragments at the same granularity according to resource type, logical address range, fragment boundary, occupancy identifier, remaining lock duration, estimated release time, and compatibility tag; Set status categories for consecutive occupied segments, consecutive idle segments, occupied segments awaiting release, and policy-restricted segments; The segment codes within the same logical address range are versioned according to the state change time, and the boundary mapping relationship before and after the segment merging is preserved. Write a pending confirmation status flag for any missing segments at the expected release time, and incorporate the pending confirmation status flag into the subsequent topology edge construction.

3. The virtual resource fragmentation status integration and early warning method according to claim 2, characterized in that, The versioned arrangement includes: recording the state changes caused by application, release, locking, re-occupancy and timeout reclamation within the same logical address range as a fragment version chain; In the fragment version chain, write boundary inheritance markers and release inheritance markers for adjacent versions; When a segment is divided into multiple sub-segments, the compatibility label, locking state, and expected release time of the parent segment are mapped to the sub-segment encoding respectively, and a backtracking index is generated for the sub-segments; When multiple sub-segments re-form continuous boundaries, the boundary mapping relationship before merging is restored according to the backtracking index, and the restoration result is written to the merge record at the end of the version chain.

4. The virtual resource fragmentation status integration and early warning method according to claim 3, characterized in that, The generation of the relationship type and blocking source marker includes: cross-validating the adjacent topological edges, the policy-compatible topological edges, and the time-coincident topological edges between two topological nodes; When an adjacency relationship is established but a compatible label conflict occurs, the topological edge is rewritten as a boundary blocking edge; When the compatibility relationship is valid but the expected release times do not coincide, the topological edge is rewritten as a time mismatch edge; When the locked state covers the available time window of any node, the topological edge is rewritten as a locked blocking edge; Write the topological edges before and after the rewrite into the relation change chain respectively, and retain the original edge identifiers in the relation change chain.

5. The virtual resource fragmentation status integration and early warning method according to claim 4, characterized in that, The recording of the merging resistance includes: generating a blocking sequence within each integrable domain according to the distribution positions of boundary blocking edges, time mismatch edges, and locking blocking edges; The blocking sequence is bound to the capacity boundary and available time window of the integrable domain; When different connected domains share the same compatible label and the expected release time overlaps, cross-domain candidate merge records are established and included in the candidate level of the integrable domain set; In the candidate level, a candidate merging order is generated according to the number of cross-domain nodes and the type of blocking edge, and the correspondence between the candidate merging order and the blocking sequence is preserved.

6. The virtual resource fragmentation status integration and early warning method according to claim 5, characterized in that, Triggering the graded early warning signal includes: writing the capacity-type risk component, the boundary-blocking risk component, and the time mismatch risk component into the early warning state machine; When the same request pattern maintains the same risk source in consecutive state versions, the corresponding level of warning signal is output according to the upgrade path of the warning state machine; When the source of risk described in the subsequent state version disappears and the corresponding request form is rematched, the alert level is switched to a lower alert level according to the recovery path of the alert state machine. Write the warning level, risk source, and identifier of the integrable domain that failed to match into the warning record.

Images