Cloud service resource intelligent distribution system based on SDN

Abstract

The invention discloses an SDN (Software Defined Network)-based cloud service resource intelligent distribution system, relates to the technical field of software defined network and cloud computing resource management, and is used for solving the problem of circular dependency and conflict during operation caused by strategy competition and dependency deficiency in a cloud service deployment process. The system establishes a strategy disturbance identification and resource pre-configuration mechanism by constructing a service component topology and strategy dependency relationship map, then collects a logic constraint relationship between a service component element and a strategy element, calculates a strategy criticality in combination with a historical collaborative effective time sequence, positions a core strategy unit and a potential conflict path, and finally performs strategy disturbance identification and resource pre-configuration on the basis of the strategy criticality. Then, based on the real-time resource state vector and the scheduling priority weight, a resource configuration instruction is generated within the minimum influence range, deployment oscillation caused by global rearrangement is avoided, a system is linked with a pre-configuration module and a coordination judgment module, a closed-loop strategy execution and rollback process is formed, and the system performance is improved. And the deployment success rate and the strategy execution certainty are obviously improved in a complex cloud service scene.

Description

Technical Field

[0001] This invention relates to the field of software-defined networking and cloud computing resource management technology, and more specifically, to an intelligent allocation system for cloud service resources based on SDN. Background Technology

[0002] In cloud platforms and software-defined networking (SDN) environments, the creation of new service instances and the global activation of associated policies are generally asynchronous in timing. Existing network policy management models are mostly based on serial or semi-parallel delivery mechanisms, simplifying the policy activation process into a one-way instruction push from the control plane to data plane network elements. They also employ static, stateless policy readiness determination methods and fail to quantify the dynamic constraint mechanism of policy dependencies on the global activation timing.

[0003] In existing technologies, due to the topological dependencies and functional mutual exclusions between policy scheduling and the uncoupled policy elements, the policy effectiveness state becomes unpredictable and the service readiness window is extended in highly dynamic environments. This causes newly created network services to be exposed to an unprotected or unavailable state before the policy is fully effective, exacerbating the risks of service interruption and security violations. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of the prior art, the present invention provides an intelligent allocation system for cloud service resources based on SDN to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A cloud service resource intelligent allocation system based on SDN includes: The service topology construction module is used to receive cloud service resource creation requests, parse and extract service component elements and associated strategy elements from the creation request, and generate service component topology. The resource verification module is used to initiate resource exploration to the underlying infrastructure, obtain the real-time resource status vectors of the target physical machine and the switching node, perform resource compliance verification on the service component topology, and generate resource compliance verification conclusions. The strategy graph construction module is used to generate atomic strategy units and their logical dependencies when the resource compliance verification result is passed. This is based on the analysis of the logical constraint relationship between service component elements and associated strategy elements, as well as the timing of the collaborative effect of atomic strategy units in the historical configuration success record database. The module also dynamically constructs a strategy dependency graph to determine the core strategy units. The strategy pre-configuration module is used to calculate the scheduling priority weight of each atomic strategy unit based on the strategy dependency graph and the real-time resource state vector, and issue configuration instructions to the atomic strategy units in parallel according to the scheduling priority weight, while performing pre-configuration mounting operations on the core strategy units. The readiness status monitoring module is used to collect and confirm the response status of the target network elements of all atomic policy units to the configuration instructions, and generate a policy readiness status vector. The coordination and adjudication module is used to determine whether all core policy units have reached the preset mounting ready state based on the policy ready state vector. If so, it issues an atomic switching command to the network boundary device; otherwise, it performs a policy rollback operation and generates a creation failure alarm.

[0006] Furthermore, it receives cloud service resource creation requests, parses and extracts service component elements and associated policy elements from the creation request, and generates a service component topology, including: Receive cloud service resource creation requests and convert the creation requests into structured data objects; The structured data object is parsed to identify and extract the service component elements that represent service function entities and the associated strategy elements that represent operation rules. Establish component dependency mapping based on the logical hierarchical relationship between service component elements, and bind strategies to associated strategy elements according to the functional constraint type of associated strategy elements; Based on component dependency mapping and strategy binding, a service component topology is generated with service component elements as nodes and logical subordinate relationships and functional constraint types as edges.

[0007] Furthermore, resource probing is initiated with the underlying infrastructure to obtain the real-time resource status vectors of the target physical machine and switching nodes. Resource compliance verification is then performed on the service component topology, and a resource compliance verification conclusion is generated, including: Initiate a resource exploration request to the underlying infrastructure to obtain the real-time resource status vectors of the target physical machine and the switching node; Map service component elements to real-time resource state vectors and calculate the matching degree between the resource requirements of each service component element and the real-time resources of the target physical machine. Edges constructed based on logical subordination and functional constraint types serve as data flow paths to be verified. These paths are mapped to real-time resource status vectors to perform resource compliance verification on the service component topology, verifying whether the data flow paths meet bandwidth requirements and latency constraints. The resource compliance verification conclusion is generated by combining the verification results of matching degree, bandwidth requirements and latency constraints.

[0008] Furthermore, when the resource compliance verification result is passed, based on the analysis of the logical constraint relationship between service component elements and associated policy elements, and the timing of the collaborative activation of atomic policy units in the historical configuration success record database, atomic policy units and their logical dependencies are generated, and a policy dependency graph is dynamically constructed to determine the core policy units, including: When the resource compliance verification result is passed, the logical constraint relationship between the service component element and the associated policy element is parsed, and the pre-dependency and mutual exclusion dependency rules between the associated policy elements are extracted. Based on the rules of pre-dependency and mutual exclusion, the associated strategy elements are functionally decomposed to generate different atomic strategy units. Query the historical configuration success record database to obtain the effective time point and duration of the atomic strategy unit in the atomic strategy unit collaborative effective sequence; Based on the rules of pre-dependency and mutual exclusion, as well as the effective time and duration of atomic policy units, the logical dependencies between atomic policy units are dynamically deduced and generated. Dynamically construct a policy dependency graph with atomic policy units as nodes and logical dependencies as edges; Based on the policy dependency graph, the topological attributes of each node are analyzed to obtain the dependency depth of each node, and the policy criticality of each atomic policy unit is calculated by combining the effective duration of the atomic policy unit. Atomic strategy units with a strategy criticality greater than a preset strategy criticality threshold are selected as core strategy units.

[0009] Furthermore, based on the policy dependency graph and real-time resource state vector, the scheduling priority weight of each atomic policy unit is calculated, and configuration instructions are issued to the atomic policy units in parallel according to the scheduling priority weight. Simultaneously, a pre-configured mounting operation is performed on the core policy unit, including: Based on the strategy dependency graph, the number of directly upstream dependent units and the number of directly downstream affected units of each atomic strategy unit are analyzed, and the dependency influence factor is calculated. The available computing resources of the target physical machine and the available bandwidth resources of the switching node are extracted from the real-time resource state vector, and the resource matching degree is calculated. Multiply the dependency impact factor by the resource matching degree to obtain the initial priority product; Based on the initial priority product, query the preset priority mapping table to generate the scheduling priority weight of each atomic strategy unit; Based on the scheduling priority weight from high to low, configuration instructions are issued to the corresponding atomic policy units in parallel, and a preset mounting operation is performed on the core policy unit at the same time.

[0010] Furthermore, the process of simultaneously performing a pre-configured mounting operation on the core strategy unit includes the following steps: Based on the policy dependency graph, locate all atomic policy units associated with the core policy unit scheduling, forming a core policy dependency chain; Resource reservation instructions and configuration preloading instructions are issued in parallel to all target network elements on the core strategy dependency chain; Monitor and confirm that each target network element successfully executes the resource reservation instruction and completes the reservation of resources required for the operation of the atomic strategy unit; Monitor and confirm that each target network element successfully executes the configuration preloading instruction, and completes the loading of atomic policy unit configuration data into memory; When all target network elements have completed the reservation of resources required for the operation of atomic policy units and the loading of atomic policy unit configuration data in memory, the pre-mounting operation is performed, and the core policy unit is marked as pre-mounting ready.

[0011] Furthermore, the response status of all target network elements in atomic policy units to configuration commands is collected and confirmed, and a policy ready state vector is generated, including: Collect and confirm the response status of the target network elements of all atomic policy units to the configuration instructions, initiate configuration status polling probes to the target network elements, and obtain the configuration instruction execution status code corresponding to each atomic policy unit; The configuration command execution status code is checked for consistency with the predefined policy readiness standard status code to determine the configuration readiness result of each atomic policy unit. All configuration ready results are vectorized and combined in a preset order to generate a policy ready state vector.

[0012] Furthermore, based on the policy readiness state vector, it is determined whether all core policy units have reached the preset mounting readiness state. If so, an atomic handover command is issued to the network boundary device; otherwise, a policy rollback operation is performed and a creation failure alarm is generated, including: Traverse the policy ready state vector and extract the configuration ready results of each core policy unit from the policy ready state vector based on the predefined set of core policy units. Based on the configuration readiness results, it is determined whether all core policy units have reached the preset mounting readiness state. The determination process is to compare each configuration readiness result with the predefined policy readiness standard status code. When all configuration readiness results meet the readiness standard, it is determined that all core policy units have reached the preset mounting readiness state. Once it is determined that all core policy units have reached the preset mounting ready state, an atomic switching command is generated and sent to the network boundary device. When it is determined that some core policy units have not reached the preset mounting ready state, a reverse rollback instruction sequence is generated based on the policy dependency relationship graph, and the reverse rollback instruction sequence is sent to all target network elements to execute the policy rollback operation, while generating a creation failure alarm.

[0013] Compared with the prior art, the present invention has the following beneficial effects: 1. First, based on the joint analysis of the logical dependency relationships of service component elements and the functional constraints of associated policy elements, a service component topology with both resource and policy views is generated. Then, combining historical collaborative activation time-series data, the logical dependencies between atomic policy units are dynamically deduced, constructing a policy dependency graph that deeply represents the inherent coupling relationships of policies. Based on this, compared to existing static configuration or single resource scheduling technologies, this invention can accurately identify potential conflicts and dependency depths between policy units through graph analysis before resource allocation instructions are issued, and determine the core policy units accordingly. A pre-mounting mechanism is used to pre-allocate and load the configuration of key resources. Ultimately, this avoids post-deployment circular dependencies and runtime conflicts caused by policy competition or missing dependencies from the source, significantly improving the probability of successful cloud service deployment and the determinism of policy execution.

[0014] 2. On the one hand, based on the vectorized acquisition and consistency verification of the response status of all atomic policy units and target network elements, a policy readiness state vector that can accurately reflect the overall system progress status in real time is constructed. On the other hand, according to the creation order defined by the policy dependency graph, a revocation instruction sequence that strictly matches the topology is generated in reverse. Therefore, compared to the coarse rollback mechanism in existing technologies that relies on timeout judgment or revocation line by line, this invention achieves precise coordination and adjudication based on the global state. Specifically, it can determine whether the system meets the atomic switching conditions within milliseconds, and trigger an automated global rollback that is strictly inverse of the creation order and maintains consistent dependencies when any core policy unit is not ready. This not only eliminates the semi-deployment state and resource silos caused by partial failures, but also greatly improves system reliability while ensuring the immediate reclamation and rapid reallocation of underlying resources, thus fully meeting the high-agility and high-availability operation and maintenance requirements of cloud services. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the structure of an intelligent cloud service resource allocation system based on SDN according to the present invention. Detailed Implementation

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

[0017] Example: Figure 1 A schematic diagram of the structure of an SDN-based intelligent cloud service resource allocation system according to the present invention is provided. The SDN-based intelligent cloud service resource allocation system includes: The service topology construction module is used to receive cloud service resource creation requests, parse and extract service component elements and associated strategy elements from the creation request, and generate service component topology. The resource verification module is used to initiate resource exploration to the underlying infrastructure, obtain the real-time resource status vectors of the target physical machine and the switching node, perform resource compliance verification on the service component topology, and generate resource compliance verification conclusions. The strategy graph construction module is used to generate atomic strategy units and their logical dependencies when the resource compliance verification result is passed. This is based on the analysis of the logical constraint relationship between service component elements and associated strategy elements, as well as the timing of the collaborative effect of atomic strategy units in the historical configuration success record database. The module also dynamically constructs a strategy dependency graph to determine the core strategy units. The strategy pre-configuration module is used to calculate the scheduling priority weight of each atomic strategy unit based on the strategy dependency graph and the real-time resource state vector, and issue configuration instructions to the atomic strategy units in parallel according to the scheduling priority weight, while performing pre-configuration mounting operations on the core strategy units. The readiness status monitoring module is used to collect and confirm the response status of the target network elements of all atomic policy units to the configuration instructions, and generate a policy readiness status vector. The coordination and adjudication module is used to determine whether all core policy units have reached the preset mounting ready state based on the policy ready state vector. If so, it issues an atomic switching command to the network boundary device; otherwise, it performs a policy rollback operation and generates a creation failure alarm.

[0018] The system receives cloud service resource creation requests, parses and extracts service component elements and associated strategy elements from the creation requests, and generates service component topologies. The specific implementation is as follows: The system receives cloud service resource creation requests through a predefined application programming interface. These creation requests are typically transmitted in JSON or XML format. Upon receipt, the system calls a data converter to transform the creation request into a structured data object. This structured data object is organized using key-value pairs or a tree structure. During the transformation process, the system verifies the syntactic and semantic integrity of the creation request, such as checking whether required fields exist and whether the data format conforms to the specifications, thereby generating a unified structured data object.

[0019] The system parses structured data objects, using a parsing engine to traverse each level of the structured data objects, identifying and extracting service component elements that represent service function entities and associated policy elements that represent operation rules. Among them, service component elements include, but are not limited to, virtual machine instances, container groups, or storage volumes. These service component elements identify the functional roles of service component elements through tags or attributes, while associated policy elements include, but are not limited to, security policies, load balancing policies, or resource configuration policies. These associated policy elements describe the constraints of associated policy elements through policy rules.

[0020] The system establishes component dependency mapping based on the logical hierarchical relationship between service component elements. This logical hierarchical relationship includes, but is not limited to, startup dependency, network dependency, or data dependency. At the same time, the system binds the associated policy elements to the policy elements according to the functional constraint type of the associated policy elements. The functional constraint type includes, but is not limited to, execution order constraint, resource allocation constraint, or access control constraint. The binding process associates the associated policy elements with the corresponding service component elements.

[0021] The system generates service component topology based on component dependency mapping and strategy binding, using service component elements as nodes and logical hierarchical relationships and functional constraint types as edges. Specifically, the service component topology is represented by a graph structure, where nodes represent various service component elements, and edges represent logical hierarchical relationships (e.g., dependency direction) and functional constraint types (e.g., strategy constraint path). The system traverses the component dependency mapping and strategy binding using a pre-defined topology construction algorithm, dynamically combining the relationships between nodes and edges, and ultimately outputting a complete service component topology.

[0022] Initiate a resource query to the underlying infrastructure to obtain the real-time resource status vectors of the target physical machine and switching nodes, perform resource compliance verification on the service component topology, and generate a resource compliance verification conclusion. The specific implementation is as follows: The system initiates a resource exploration request to the underlying infrastructure through a predefined resource management interface. This resource exploration request is transmitted to the target physical machine and the switching node based on a standard protocol. The resource exploration request contains a query command to obtain the real-time resource status vector of the target physical machine, which includes indicators such as CPU utilization, available memory, and storage space. The real-time resource status vector of the switching node includes indicators such as port bandwidth utilization, queue depth, and forwarding latency.

[0023] The system maps service component elements to real-time resource state vectors. Specifically, it iterates through the service component elements using a resource allocation algorithm to extract the resource requirements of each service component element. These resource requirements include computing resource requirements, storage resource requirements, and network resource requirements. Then, the system calculates the matching degree between the resource requirements of each service component element and the real-time resource state vector. The matching degree calculation process is as follows: First, the quantified value of the resource requirement is compared with the resource availability value of the real-time resource state vector. For example, the ratio of CPU requirement to CPU availability is calculated, and the ratios of all resource types are weighted and averaged. The weights are predefined according to the importance of the resources, and finally, a matching degree value between 0 and 1 is generated.

[0024] For example, in a real-world deployment scenario of a smart city traffic management system, the system needs to map a service component element named "Real-time Traffic Flow Analysis Service" to a real-time resource state vector on the cloud platform. The system extracts the resource requirements of this service component element using a resource allocation algorithm. These requirements include 6 CPU cores for processing high-definition video stream analysis, 16GB of memory for caching video frames and intermediate data, and 800Mbps bandwidth for receiving real-time video streams from roadside cameras. Next, the system matches these resource requirements with the real-time resource state vector. The matching degree calculation shows that the currently available resources in the real-time resource state vector include 8 CPU cores, 20GB of memory, and 1Gbps bandwidth. During the matching degree calculation process, the quantified value of resource demand is compared with the resource availability value of the real-time resource state vector, and the ratio of each resource type is calculated. The CPU ratio is 0.75, the memory ratio is 0.8, and the network bandwidth ratio is 0.8. Subsequently, the smart city traffic management system performs a weighted calculation according to the predefined resource importance weights, where the weights of CPU and memory are both 40%, and the weight of network bandwidth is 20%. By multiplying each ratio by its corresponding weight and summing them, the matching degree is obtained as 0.78.

[0025] The system constructs edges based on logical hierarchical relationships and functional constraint types, which serve as data flow paths to be verified, and maps these data flow paths to real-time resource status vectors; the system performs resource compliance verification on the service component topology, and the verification process includes: For each data flow path to be verified, the bandwidth requirement and latency constraint of the data flow path are extracted. Then, the available bandwidth and measured latency of the corresponding data flow path are obtained from the real-time resource status vector. The available bandwidth is compared with the bandwidth requirement and the measured latency is compared with the latency constraint. If the available bandwidth and measured latency of all data flow paths meet the bandwidth requirement and latency constraint, the verification passes. Otherwise, it is marked as failing, and the specific failing data flow path and the reason are recorded.

[0026] The system comprehensively verifies the matching degree, bandwidth requirements, and latency constraints to generate a resource compliance verification conclusion. The comprehensive process is as follows: First, it evaluates whether the matching degree of all service component elements is higher than the preset matching degree threshold. Then, it checks whether the bandwidth requirements and latency constraints of all data flow paths have passed the verification. If the matching degree is higher than the preset matching degree threshold and the bandwidth requirements and latency constraints of the data flow paths have passed the verification, the resource compliance verification conclusion is "passed". Otherwise, the resource compliance verification conclusion is "failed".

[0027] When the resource compliance verification result is passed, based on the analysis of the logical constraint relationship between service component elements and associated policy elements, and the timing of the collaborative activation of atomic policy units in the historical configuration success record database, atomic policy units and the logical dependencies between atomic policy units are generated, and a policy dependency graph is dynamically constructed to determine the core policy unit. The specific implementation is as follows: After the resource compliance check passes, the system begins to parse the pre-defined logical constraint relationships between service component elements and associated policy elements, specifically including two core rules: The first core rule is the prerequisite dependency rule, which means that the effectiveness of an associated strategy element must be conditional upon the prior effectiveness of one or more other specified associated strategy elements. The second core rule is the mutual exclusion dependency rule, which means that two or more related strategy elements are logically conflicting and are not allowed to take effect together in the same time period.

[0028] Based on pre-dependency and mutual exclusion rules, the system performs functional decomposition on associated policy elements. The goal of this decomposition is to break down a complex, composite associated policy element into multiple functionally singular, indivisible atomic policy units. Each atomic policy unit represents an independent, minimal policy action or configuration instruction. The functional decomposition process is as follows: The system parses the metadata and rule definitions of each associated strategy element, identifies and marks the pre-dependency rules and mutually exclusive dependency rules contained therein, and outputs a list of associated strategy elements marked with dependency types. Based on the dependency rule list, the system logically decomposes composite associated strategy elements. For pre-dependency rules, composite associated strategy elements with AND relationships are decomposed into independent atomic strategy units, and pre-dependency edges are established. For mutually exclusive dependencies, conflicting associated strategy elements are decomposed into multiple mutually exclusive, optional atomic strategy unit branches, and mutually exclusive dependency edges are established, thus outputting a preliminary set of atomic strategy units with single functions. The system performs a function minimization judgment on the initially decomposed atomic strategy units, recursively checks and decomposes until each atomic strategy unit meets the atomicity requirements of single function and indivisibility. Subsequently, a globally unique identifier is assigned to each finally generated atomic strategy unit, and its execution parameters, target network element, and other attributes are encapsulated into the data structure of the atomic strategy unit. Finally, a standard atomic strategy unit with a unique ID and complete attributes is output.

[0029] The system queries the historical configuration success record database, which records all past successful atomic policy unit deployment instances. From these recorded atomic policy unit deployment instances, the system extracts the atomic policy unit collaborative activation sequence related to the current atomic policy unit. The atomic policy unit collaborative activation sequence specifically includes two key time parameters: the atomic policy unit activation time point, which is the precise timestamp of when the atomic policy unit began to take effect in history, and the atomic policy unit activation duration, which is the total duration for which the atomic policy unit has remained in an effective state in history.

[0030] Based on pre-dependency and mutual exclusion rules, and combined with the effective time and duration of atomic policy units, the system dynamically deduces and generates logical dependencies between atomic policy units. These logical dependencies specifically include two types: pre-dependency edges and mutual exclusion edges. The deduction process is as follows: For pre-dependency rules: The system checks two atomic policy units that have pre-dependency rules. If, according to historical records, the effective time of the atomic policy unit of the latter atomic policy unit is later than that of the atomic policy unit of the former atomic policy unit, and the effective duration of the atomic policy units of the two overlaps, then a pre-dependency edge is established between the former atomic policy unit and the latter atomic policy unit. This pre-dependency edge is directional, pointing from the former atomic policy unit to the latter atomic policy unit.

[0031] For mutually exclusive dependency rules: The system checks atomic policy units that have mutually exclusive dependency rules. Regardless of the effective time and duration of the atomic policy unit, a mutually exclusive dependency edge is directly established between them. This mutually exclusive dependency edge is an undirected edge, indicating that the two cannot coexist.

[0032] After deducing the logical dependencies between atomic policy units, the system dynamically constructs a policy dependency graph with atomic policy units as nodes and logical dependencies as edges. The policy dependency graph is a network model that intuitively displays the complex constraints between atomic policy units. The construction process of the policy dependency graph is as follows: The system abstracts all atomic policy units generated through functional decomposition into nodes in a policy dependency graph. Each node carries its corresponding unique policy identifier and basic policy description information. Subsequently, the system maps prerequisite dependencies and mutual exclusion dependencies to edges connecting these nodes. Specifically, for prerequisite dependencies, the system represents a directed edge from the source node to the target node. The direction of this directed edge precisely defines the order in which atomic policy units take effect, i.e., the atomic policy unit at the starting point of the arrow must take effect before the atomic policy unit at the ending point of the arrow. For mutual exclusion dependencies, the system represents an undirected edge connecting two or more related nodes. This undirected edge indicates that there is a conflict constraint between connected atomic policy units that cannot take effect simultaneously. By integrating and laying out all nodes and these two types of edges, the system finally builds and maintains a complete and visual policy dependency graph in memory.

[0033] Based on a dynamically constructed policy dependency graph, the system performs in-depth topological attribute analysis on each atomic policy unit existing as a node in the graph. The core of this analysis lies in quantitatively evaluating the positional importance of each node in the graph network structure. Its first step is to calculate a key topological attribute, namely the dependency depth of the node. The system's calculation logic is as follows: Starting from all nodes in the graph with an in-degree of zero (i.e., nodes with no preceding dependency edges pointing to them), considered as the starting point of the entire dependency network, traverse along the directed path formed by the preceding dependency edges. For each node of the atomic policy unit to be analyzed, its dependency depth is precisely defined as: Starting from any starting node, the maximum number of preceding dependent edges contained in all possible paths when reaching that node through a series of consecutive preceding dependent edges. This means that the larger the dependency depth value of a node, the further back it is in the policy execution chain, and the more preconditions the node indirectly depends on for its effectiveness. After obtaining the topological attribute of dependency depth of all nodes, the system does not directly use dependency depth as the final evaluation indicator. Instead, it further combines the effective duration of the atomic policy unit corresponding to the node obtained from the historical configuration success record database to perform a comprehensive weighted calculation to determine the policy criticality of the atomic policy unit.

[0034] The weighted calculation method for strategy criticality follows the principles below: The dependency depth value of a node and the duration of the atomic strategy unit are both positively correlated with the final calculated strategy criticality value. Specifically, during the calculation process, the system assigns a weight coefficient to the dependency depth and the duration of the atomic strategy unit, and then linearly weights and sums these two normalized attribute values ​​according to their weight coefficients to obtain the final strategy criticality value.

[0035] The system compares the calculated policy criticality value of each atomic policy unit with a preset policy criticality threshold. This preset policy criticality threshold is set by the system administrator according to business fault tolerance requirements or dynamically adjusted by the system based on historical deployment success rates. The system filters out all atomic policy units whose policy criticality values ​​are greater than the preset policy criticality threshold and identifies them as core policy units.

[0036] Based on the policy dependency graph and real-time resource state vector, the scheduling priority weight of each atomic policy unit is calculated, and configuration instructions are issued to the atomic policy units in parallel according to the scheduling priority weight. At the same time, a pre-configured mounting operation is performed on the core policy unit. The specific implementation is as follows: The system parses the constructed policy dependency graph. For each node of an atomic policy unit in the policy dependency graph, it counts the number of directly upstream dependent units and the number of directly downstream influential units. The number of directly upstream dependent units refers to the number of all other atomic policy units that directly point to this atomic policy unit through a preceding dependency edge; the number of directly downstream influential units refers to the number of all other atomic policy units that directly point to this atomic policy unit through a preceding dependency edge. The system multiplies these two numbers and defines the product as the dependency influence factor of this atomic policy unit.

[0037] The system accesses the real-time resource state vector, which is a continuously updated data structure that encapsulates the real-time resource state of each physical entity in the network environment. From the real-time resource state vector, the system extracts the available computing resources of the target physical machine related to the current scheduling task, as well as the available bandwidth resources of the relevant switching nodes. The system then normalizes the available computing resources and available bandwidth resources to eliminate the influence of dimensions, and uses a weighted summation method for calculation: that is, assigning a weight coefficient to the available computing resources and another weight coefficient to the available bandwidth resources, multiplying the normalized available computing resource value and the available bandwidth resource value by their respective weight coefficients, and then adding them together to calculate the resource matching degree.

[0038] The system will multiply the dependency influencing factor and the resource matching degree to obtain an initial priority product. Through multiplication, the weakest link effect of either factor can be amplified. That is, even if an atomic strategy unit depends on a high influence factor, if the current resource matching degree is extremely low, its initial priority product will be significantly reduced, and vice versa.

[0039] The system has a built-in preset priority mapping table, which defines the correspondence between the numerical range of the initial priority product and the specific scheduling priority weight. The system compares the initial priority product of each atomic policy unit with this priority mapping table and generates a scheduling priority weight for each atomic policy unit through a table lookup operation.

[0040] Based on the generated scheduling priority weights, all atomic policy units to be executed are sorted and formed into a scheduling queue in descending order. The system then issues specific configuration instructions to the atomic policy units in the queue in a parallel and asynchronous manner, according to the scheduling queue order.

[0041] Simultaneously, a pre-configured mounting operation is performed on the core strategy unit. The specific process is as follows: Based on the constructed policy dependency graph, the system performs the location operation of the core policy dependency chain. Specifically, the system first identifies all nodes that have been marked as core policy units. Then, using the directed edges defined by the pre-dependency relationship as paths, it traces upstream and traverses downstream these core policy unit nodes to locate all atomic policy units that are directly or indirectly connected to them through the pre-dependency edges. This scheduling association is specifically reflected through the pre-dependency edges in the policy dependency graph. These atomic policy units that form scheduling associations with the core policy units through the pre-dependency edges are uniformly defined as their pre-dependency units. All atomic policy units included in this process, namely the core policy unit itself and all its pre-dependency units, together constitute a complete and logically closely related set, which is defined as the core policy dependency chain.

[0042] After identifying the core policy dependency chain, the system immediately initiates the pre-configured resource allocation and configuration process. In parallel, the system issues two types of instructions to the target network element that carries all atomic policy units on the core policy dependency chain: The first type of instruction is the resource reservation instruction, which is used to request and lock the underlying resources necessary for running the corresponding atomic policy unit from the target network element, such as a specific amount of computing power and memory space; the second type of instruction is the configuration preloading instruction, which is used to send the specific configuration parameters and data of the atomic policy unit to the target network element.

[0043] The system continuously monitors the execution feedback of each target network element to the resource reservation command. For each issued resource reservation command, the system waits for and receives a response message from the target network element. This message clearly indicates the success or failure of the resource reservation operation. Only when the system confirms that a target network element has returned a response indicating that the resource reservation was successful will it determine that the target network element has completed the reservation of the resources required for the operation of the atomic strategy unit. The system will then summarize the resource reservation status of all target network elements.

[0044] At the same time, the system monitors the execution of the configuration preloading command by each target network element in parallel. The system verifies whether the configuration data of the atomic policy unit has been accurately loaded into the specified memory area of ​​the target network element by checking the confirmation signal returned by the target network element or actively querying its memory status. Only when it is confirmed that the configuration data is ready in memory and can be called immediately, it is determined that the target network element has completed the loading of the atomic policy unit configuration data in memory. The system will summarize the configuration preloading status of all target network elements.

[0045] The system establishes a synchronization point to continuously check the status of all target network elements. The final pre-mount operation is triggered only when all target network elements have completed the reservation of resources required for the operation of atomic policy units and the loading of atomic policy unit configuration data in memory. Logically, this operation puts the entire core policy dependency chain into a state that can be activated immediately and updates the status of the core policy unit, which is the head of the core policy dependency chain, to the pre-mount ready state.

[0046] Collect and confirm the response status of all target network elements in atomic policy units to configuration commands, and generate a policy ready state vector. The specific implementation is as follows: After issuing configuration commands to atomic policy units, the system initiates a configuration readiness confirmation process. The system first collects and confirms the initial response status of all target network elements of the atomic policy units to the configuration commands. Subsequently, it initiates periodic configuration status polling probes to these target network elements. The configuration status polling probe process is implemented by sending specific query request messages to the target network elements. After receiving the query request message, the target network element will return a code that represents the configuration execution progress within the target network element. This code is obtained by parsing the response query request message and is defined as the configuration command execution status code.

[0047] The system has a set of policy ready standard status codes pre-stored. This set of policy ready standard status codes is a set of standard status values ​​that are predefined according to business requirements and represent that the atomic policy units have been successfully configured and can work normally. The system will compare and verify the configuration instruction execution status codes obtained from each target network element with this set of policy ready standard status codes one by one to determine the configuration ready result of each atomic policy unit.

[0048] The verification rule is as follows: determine whether the value of the configuration instruction execution status code obtained from the target network element completely matches any value in the predefined policy ready standard status code set. If they match, the configuration ready result of the atomic policy unit is determined to be ready; if they do not match, the configuration ready result of the atomic policy unit is determined to be not ready. This process is called consistency verification.

[0049] After determining the configuration readiness of all atomic policy units, the system arranges the configuration readiness results of all atomic policy units in a preset and fixed order, such as the topological order of the atomic policy units in the core policy dependency chain or the lexicographical order of their unique identifiers. The configuration readiness results include two states: ready and not ready. The system encapsulates the ordered set containing the ready states of all atomic policy units into a one-dimensional array structure, which is defined as the policy readiness state vector.

[0050] Based on the policy readiness state vector, determine whether all core policy units have reached the preset mounting readiness state. If so, issue an atomic handover command to the network boundary device; otherwise, perform a policy rollback operation and generate a creation failure alarm. The specific implementation is as follows: First, the system performs a traversal operation on the policy readiness state vector. During this traversal, the system uses a predefined set of core policy units. This set of core policy units is determined and stored in advance during the system initialization phase based on the critical requirements of the business policy and the core policy units in the policy dependency graph. Each atomic policy unit in the system is assigned a globally unique unit identifier when it is created. This unit identifier serves as the key basis for locating and identifying the corresponding atomic policy unit in the policy readiness state vector within the system. The system locates and extracts the configuration readiness results corresponding to each core policy unit by precisely matching the unit identifier corresponding to each position in the policy readiness state vector with the unit identifiers recorded in the core policy unit set.

[0051] Based on the configuration readiness results of each extracted core policy unit, the system determines whether all core policy units have reached the preset mounting readiness state. The specific determination process is as follows: The configuration readiness result of each core policy unit is compared one by one with the predefined policy readiness standard status code. The system determines that all core policy units have reached the preset mounting readiness state only when the configuration readiness result of all core policy units matches the policy readiness standard status code, that is, all are in the ready state.

[0052] Next, when the system determines that all core policy units have reached the preset mounting ready state, the system will generate an atomic switch command. This atomic switch command is a standardized command used to activate a new policy. Specifically, the atomic switch command instructs the network boundary device to switch traffic from the old policy to the ready new policy. This new policy is a complete configuration consisting of all ready atomic policy units. After generation, the system immediately sends this atomic switch command to the network boundary device.

[0053] Finally, when the system determines that at least one core policy unit has not reached the preset mounting ready state, that is, not all core policy units are ready, the system will generate a reverse rollback instruction sequence based on a pre-stored policy dependency graph. The generation process of the reverse rollback instruction sequence is as follows: a set of instructions for undoing operations, i.e., the reverse rollback instruction sequence, is generated in the reverse order of the creation order of the atomic policy units. The system issues this reverse rollback instruction sequence to all relevant target network elements to perform a comprehensive policy rollback operation. At the same time, the system will generate and report a creation failure alarm to notify the operation and maintenance personnel to intervene and handle the situation.

[0054] For example, in a financial cloud platform, when a user applies for a load balancer to handle high-frequency trading, the system intelligently parses the service topology and policy dependency graph to determine the three core atomic policy units that need to be mounted in sequence. The first policy mounted is a stateful firewall policy bound to a specific securities trading port. This stateful firewall policy is the first core atomic policy unit and has a scheduling priority weight of 0.4. The second policy mounted is an absolute bandwidth rate limiting policy to ensure business priority. This absolute bandwidth rate limiting policy is the core atomic policy unit and has a scheduling priority weight of 0.35. The last policy mounted is a millisecond-level health check policy to ensure service quality. This millisecond-level health check policy is the core atomic policy unit and has a scheduling priority weight of 0.25.

[0055] Based on the parsed policy dependency graph and the scheduling priority weights of each core atomic policy unit, the system sends configuration instructions to the underlying computing and network nodes in parallel. It successfully reserved a total of 8 CPU cores and 2GB of memory resources on the target physical machine for these three atomic policy units. However, during the readiness monitoring phase, it was detected that the probe program responsible for health checks could not start due to an unexpected occupation of port 8080 on the target server. This caused the millisecond-level health check policy to fail to reach the preset mounting readiness state. Consequently, the system determined that the load balancer creation had failed and immediately triggered an intelligent rollback process: based on the pre-stored policy dependency graph, a reverse rollback was generated. The system executes a rollback instruction sequence and sends the reverse rollback instruction sequence to all target network elements to perform policy rollback operations. This reverse rollback instruction sequence is the complete reverse of the creation order. It prioritizes issuing instructions to remove millisecond-level health check policies, then reclaims the queue resources occupied by absolute bandwidth rate limiting policies, and finally removes stateful firewall policies and their session entries. At the same time, it automatically releases the 8-core CPU and 2GB memory resources that were intelligently reserved for the load balancer in the initial stage, marks the memory resources as available and returns them to the global resource pool, and then generates a load balancer creation failure alarm indicating a health check port conflict to notify the operations and maintenance team.

[0056] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0057] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A cloud service resource intelligent allocation system based on SDN, characterized in that, include: The service topology construction module is used to receive cloud service resource creation requests, parse and extract service component elements and associated strategy elements from the creation request, and generate service component topology. The resource verification module is used to initiate resource exploration to the underlying infrastructure, obtain the real-time resource status vectors of the target physical machine and the switching node, perform resource compliance verification on the service component topology, and generate resource compliance verification conclusions. The strategy graph construction module is used to generate atomic strategy units and their logical dependencies when the resource compliance verification result is passed. This is based on the analysis of the logical constraint relationship between service component elements and associated strategy elements, as well as the timing of the collaborative effect of atomic strategy units in the historical configuration success record database. The module also dynamically constructs a strategy dependency graph to determine the core strategy units. The strategy pre-configuration module is used to calculate the scheduling priority weight of each atomic strategy unit based on the strategy dependency graph and the real-time resource state vector, and issue configuration instructions to the atomic strategy units in parallel according to the scheduling priority weight, while performing pre-configuration mounting operations on the core strategy units. The readiness status monitoring module is used to collect and confirm the response status of the target network elements of all atomic policy units to the configuration instructions, and generate a policy readiness status vector. The coordination and adjudication module is used to determine whether all core policy units have reached the preset mounting ready state based on the policy ready state vector. If so, it issues an atomic switching command to the network boundary device; otherwise, it performs a policy rollback operation and generates a creation failure alarm.

2. The SDN-based intelligent allocation system for cloud service resources according to claim 1, characterized in that, Receive cloud service resource creation requests, parse and extract service component elements and associated policy elements from the creation requests, and generate service component topology, including: Receive cloud service resource creation requests and convert the creation requests into structured data objects; The structured data object is parsed to identify and extract the service component elements that represent service function entities and the associated strategy elements that represent operation rules. Establish component dependency mapping based on the logical hierarchical relationship between service component elements, and bind strategies to associated strategy elements according to the functional constraint type of associated strategy elements; Based on component dependency mapping and strategy binding, a service component topology is generated with service component elements as nodes and logical subordinate relationships and functional constraint types as edges.

3. The SDN-based intelligent allocation system for cloud service resources according to claim 2, characterized in that, Initiate resource probing to the underlying infrastructure to obtain the real-time resource status vectors of the target physical machine and switching nodes, perform resource compliance verification on the service component topology, and generate resource compliance verification conclusions, including: Initiate a resource exploration request to the underlying infrastructure to obtain the real-time resource status vectors of the target physical machine and the switching node; Map service component elements to real-time resource state vectors and calculate the matching degree between the resource requirements of each service component element and the real-time resources of the target physical machine. Edges constructed based on logical subordination and functional constraint types serve as data flow paths to be verified. These paths are mapped to real-time resource status vectors to perform resource compliance verification on the service component topology, verifying whether the data flow paths meet bandwidth requirements and latency constraints. Based on the combined verification results of matching degree, bandwidth requirements, and latency constraints, a resource compliance verification conclusion is generated.

4. The SDN-based intelligent allocation system for cloud service resources according to claim 3, characterized in that, When the resource compliance verification result is passed, based on the analysis of the logical constraint relationship between service component elements and associated policy elements, and the timing of the collaborative activation of atomic policy units in the historical configuration success record database, atomic policy units and the logical dependencies between atomic policy units are generated, and a policy dependency graph is dynamically constructed to determine the core policy units, including: When the resource compliance verification result is passed, the logical constraint relationship between the service component element and the associated policy element is parsed, and the pre-dependency and mutual exclusion dependency rules between the associated policy elements are extracted. Based on the rules of pre-dependency and mutual exclusion, the associated strategy elements are functionally decomposed to generate different atomic strategy units. Query the historical configuration success record database to obtain the effective time point and duration of the atomic strategy unit in the atomic strategy unit collaborative effective sequence; Based on the rules of pre-dependency and mutual exclusion, as well as the effective time and duration of atomic policy units, the logical dependencies between atomic policy units are dynamically deduced and generated. Dynamically construct a policy dependency graph with atomic policy units as nodes and logical dependencies as edges; Based on the policy dependency graph, the topological attributes of each node are analyzed to obtain the dependency depth of each node, and the policy criticality of each atomic policy unit is calculated by combining the effective duration of the atomic policy unit. Atomic strategy units with a strategy criticality greater than a preset strategy criticality threshold are selected as core strategy units.

5. The SDN-based intelligent allocation system for cloud service resources according to claim 4, characterized in that, Based on the policy dependency graph and real-time resource state vector, the scheduling priority weight of each atomic policy unit is calculated, and configuration instructions are issued to the atomic policy units in parallel according to the scheduling priority weight. At the same time, a pre-configured mounting operation is performed on the core policy unit, including: Based on the strategy dependency graph, the number of directly upstream dependent units and the number of directly downstream affected units of each atomic strategy unit are analyzed, and the dependency influence factor is calculated. The available computing resources of the target physical machine and the available bandwidth resources of the switching node are extracted from the real-time resource state vector, and the resource matching degree is calculated. Multiply the dependency impact factor by the resource matching degree to obtain the initial priority product; Based on the initial priority product, query the preset priority mapping table to generate the scheduling priority weight of each atomic strategy unit; Based on the scheduling priority weight from high to low, configuration instructions are issued to the corresponding atomic policy units in parallel, and a preset mounting operation is performed on the core policy unit at the same time.

6. The SDN-based intelligent allocation system for cloud service resources according to claim 5, characterized in that, The process of simultaneously performing a pre-configured mounting operation on the core strategy unit includes the following steps: Based on the policy dependency graph, locate all atomic policy units associated with the core policy unit scheduling, forming a core policy dependency chain; Resource reservation instructions and configuration preloading instructions are issued in parallel to all target network elements on the core strategy dependency chain; Monitor and confirm that each target network element successfully executes the resource reservation instruction and completes the reservation of resources required for the operation of the atomic strategy unit; Monitor and confirm that each target network element successfully executes the configuration preloading instruction, and completes the loading of atomic policy unit configuration data into memory; When all target network elements have completed the reservation of resources required for the operation of atomic policy units and the loading of atomic policy unit configuration data in memory, the pre-mounting operation is performed, and the core policy unit is marked as pre-mounting ready.

7. The SDN-based intelligent allocation system for cloud service resources according to claim 6, characterized in that, Collect and confirm the response status of all target network elements in atomic policy units to configuration commands, and generate a policy ready state vector, including: Collect and confirm the response status of the target network elements of all atomic policy units to the configuration instructions, initiate configuration status polling probes to the target network elements, and obtain the configuration instruction execution status code corresponding to each atomic policy unit; The configuration command execution status code is checked for consistency with the predefined policy readiness standard status code to determine the configuration readiness result of each atomic policy unit. All configuration ready results are vectorized and combined in a preset order to generate a policy ready state vector.

8. The SDN-based intelligent allocation system for cloud service resources according to claim 7, characterized in that, Based on the policy readiness state vector, determine whether all core policy units have reached the preset mounting readiness state. If so, issue an atomic handover command to the network boundary device; otherwise, perform a policy rollback operation and generate a creation failure alarm, including: Traverse the policy ready state vector and extract the configuration ready results of each core policy unit from the policy ready state vector based on the predefined set of core policy units. Based on the configuration readiness results, it is determined whether all core policy units have reached the preset mounting readiness state. The determination process is to compare each configuration readiness result with the predefined policy readiness standard status code. When all configuration readiness results meet the readiness standard, it is determined that all core policy units have reached the preset mounting readiness state. Once it is determined that all core policy units have reached the preset mounting ready state, an atomic switching command is generated and sent to the network boundary device. When it is determined that some core policy units have not reached the preset mounting ready state, a reverse rollback instruction sequence is generated based on the policy dependency relationship graph, and the reverse rollback instruction sequence is sent to all target network elements to execute the policy rollback operation, while generating a creation failure alarm.

Images