Dynamic resource scheduling method and system based on OpenDaylight controller

Abstract

The invention relates to a dynamic resource scheduling method and system based on an OpenDaylight controller. The method comprises the following steps: step 1, monitoring a resource state in real time; step 2, load state evaluation; 3, generating a dynamic scheduling strategy; and step 4, executing and feeding back a scheduling instruction. The method has the beneficial effects that 1, the resource utilization rate is improved: node idleness is reduced by dynamically adjusting resource allocation, so that the resource utilization rate is improved by 20-30%; 2, load balancing is optimized, flow change is responded in real time, local overload is avoided, and the network congestion rate is reduced by more than 40%; and 3, dynamic adaptation is enhanced, topology change self-adaptation is supported, and diversified network requirements are met.

Description

Technical Field

[0001] This invention relates to the field of software-defined networking (SDN) technology, specifically to a dynamic resource scheduling method and system based on the OpenDaylight controller. Background Technology

[0002] Software-defined networking (SDN) enables flexible network management by separating the control plane from the data plane. OpenDaylight, as a mature open-source SDN controller framework, has a powerful modular framework, supports RESTful API and RETCONF northbound interfaces, and supports various southbound interface protocols such as NETCONF and SNMP. It can be used in various network scenarios such as data centers and telecommunications networks.

[0003] In traditional SDN controllers, resource scheduling strategies often employ static resource allocation methods such as fixed bandwidth or minimum bandwidth allocation, or pre-allocate the mapping relationship between the controller and the switch, which has the following drawbacks:

[0004] 1. Low resource utilization: Static allocation cannot adjust resources according to real-time load, resulting in some nodes being overloaded while others are idle;

[0005] 2. Poor load balancing: When network traffic surges or nodes fail, static strategies cannot quickly migrate resources, which can easily lead to network congestion.

[0006] 3. Weak dynamic adaptability: It lacks a real-time response mechanism for changes in network topology and fluctuations in business demand, making it difficult to meet differentiated service needs.

[0007] Therefore, there is an urgent need for a dynamic resource scheduling method for SDN controllers based on OpenDaylight to achieve real-time optimization of resource configuration and improve network performance. Summary of the Invention

[0008] To address the shortcomings of existing static resource scheduling methods in SDN controllers, such as low resource utilization and poor load balancing, the present invention aims to provide a dynamic resource scheduling method and system based on the OpenDaylight controller. This method achieves dynamic optimization of network resources through real-time monitoring, intelligent evaluation, and adaptive scheduling of network devices.

[0009] The technical solution of this invention to solve the above-mentioned technical problems is as follows: A dynamic resource scheduling method based on the OpenDaylight controller, comprising the following steps:

[0010] Step 1: Deploy a monitoring submodule on the southbound interface layer of the OpenDaylight controller. Use the OpenFlow protocol to periodically collect multiple resource parameters of network nodes. The monitoring period can be dynamically adjusted according to the network size. The data is stored in the distributed data storage module via MD-SAL.

[0011] Step 2: Based on the resource parameters collected in Step 1, construct a multi-dimensional load assessment model and calculate the node comprehensive load index using a formula. ,in accordance with The size of the nodes is used to classify them into overloaded nodes, lightly loaded nodes, and normal nodes.

[0012] Step 3: Based on Step 2, provide the node load index. As input load parameters, if an abnormal load is detected, the load balancing strategy is invoked and a scheduling command is output.

[0013] Step 4: Based on the scheduling instructions generated in Step 3, the instructions are sent to the southbound interface layer via the OpenDaylight northbound API. After conversion, the instructions are executed by the switch device. After execution, the scheduling effect is verified by using the data collected by the monitoring submodule in Step 1 according to the node division criteria in Step 2. If the criteria are met, the scheduling is completed; otherwise, Steps 2 to 4 are repeated until the conditions are met.

[0014] Based on the above technical solution, the present invention can be further improved as follows:

[0015] Furthermore, step 2 specifically includes:

[0016] Based on the resource parameters collected in step 1, a multi-dimensional load assessment model is constructed, and the node comprehensive load index is calculated using the following formula. :

[0017] ;

[0018] in, These are the normalized load values ​​for CPU utilization, memory utilization, bandwidth utilization, and forwarding latency, respectively, all ranging from [0,1]; weighting coefficients. satisfy It can be dynamically adjusted according to business needs, and can improve latency-sensitive businesses. Value, bandwidth-sensitive services can improve Value; when the node's overall load index When the node's overall load index is high, it is marked as an overloaded node; when the node's overall load index is high, it is marked as an overloaded node. When, mark as a lightly loaded node, if When this happens, it is marked as a normal node, where For custom preset values.

[0019] Furthermore, step 3 specifically includes:

[0020] Deploy a scheduling decision submodule at the application layer of OpenDaylight to generate adaptive scheduling policies, which will be applied when overloaded nodes exist. and multiple lightly loaded nodes At this time, it is necessary to calculate the overload node. To each lightly loaded node Normalized resource migration costs between Choose the one with the lowest cost Using a lightly loaded node as the target node reduces migration costs. The calculation formula is as follows:

[0021] ;

[0022] in, These represent the normalized migration delay, link loss rate, and number of flow table entries, respectively. Indicates overloaded nodes With lightly loaded nodes Migration delay between; Indicates overloaded nodes With lightly loaded nodes Link loss rate between; Indicates overloaded nodes With lightly loaded nodes The number of flow table entries that need to be migrated between them; , , The normalized values ​​are all in the range of [0,1]. , , These are the weighting coefficients, set to the default value. =0.4、 =0.3、 =0.3, which can be adjusted according to business needs.

[0023] Furthermore, the verification of the scheduling effect in step 4 specifically involves:

[0024] If the load of an overloaded node drops below 0.7 and the load of a lightly loaded node does not exceed 0.7, then the scheduling is complete; otherwise, the scheduling is incomplete.

[0025] A dynamic resource scheduling system based on the OpenDaylight controller, used to apply the aforementioned dynamic resource scheduling method based on the OpenDaylight controller, includes:

[0026] The OpenDaylight controller core module provides basic support capabilities;

[0027] The resource monitoring submodule communicates with the switch via the OpenFlow protocol and periodically collects network node resource data.

[0028] The load assessment submodule calculates the comprehensive load index of network nodes based on monitoring data stored in MD-SAL and a multi-dimensional weighted assessment model.

[0029] The scheduling decision submodule calculates the migration cost from overloaded nodes to lightly loaded nodes based on the comprehensive network node load index provided by the load assessment submodule, selects the node with the optimal migration cost, and generates scheduling instructions.

[0030] The execution feedback submodule sends the scheduling instructions generated by its scheduling decision submodule to network node devices and verifies the execution effect.

[0031] Based on the above technical solution, the present invention can be further improved as follows:

[0032] Furthermore, the core module of the OpenDaylight controller includes:

[0033] The MD-SAL functional module provides unified data storage, storing configuration data and operational status data. It provides a reliable data source for the controller, enabling centralized management of network status.

[0034] The southbound interface provides a standardized communication interface for the controller and network devices, enabling network information collection and control command issuance.

[0035] The northbound RESTCONF API module is a management interface provided by the controller for upper-layer applications.

[0036] Furthermore, the resource monitoring submodule is deployed on the southbound interface layer.

[0037] The beneficial effects of this invention are:

[0038] 1. Improve resource utilization: By dynamically adjusting resource allocation and reducing node idleness, resource utilization can be increased by 20%-30%;

[0039] 2. Optimized load balancing: Real-time response to traffic changes, avoiding local overload, reducing network congestion rate by more than 40%;

[0040] 3. Enhanced dynamic adaptation: Supports adaptive topology changes to meet diverse network needs. Attached Figure Description

[0041] Figure 1 This is a flowchart of the dynamic resource scheduling method for the SDN controller based on OpenDaylight;

[0042] Figure 2 This is an architecture diagram of a dynamic resource scheduling system based on OpenDaylight's SDN controller. Detailed Implementation

[0043] The principles and features of the present invention are described below with reference to the accompanying drawings. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0044] like Figure 1 As shown, a dynamic resource scheduling method based on the OpenDaylight controller includes the following steps:

[0045] Step 1: Real-time monitoring of resource status

[0046] A monitoring submodule is deployed at the southbound interface layer of the OpenDaylight controller. This submodule periodically collects multiple resource parameters from network nodes using the OpenFlow protocol. The monitoring period can be dynamically adjusted according to network size. The data is stored in a distributed data storage module via MD-SAL. Details are as follows:

[0047] a. The resource monitoring submodule sends data acquisition requests to the switch through the OpenFlow protocol's StatsRequest / StatsReply message exchange mechanism to collect data such as device status and flow table entries from the switch;

[0048] b. The JSON format for monitoring device status is shown below:

[0049] {

[0050] "node-id": "openflow:1",

[0051] "cpu-utilization": 0.75,

[0052] “mem-utilization”: 0.6,

[0053] “bw-utilization”: 0.9,

[0054] "delay": 95 / / Unit: ms

[0055] }

[0056] c. Data preprocessing: The collected network resource data is preprocessed, invalid data is cleaned up, and the preprocessed data is stored in the data storage module through MD-SAL.

[0057] Step 2, Load Status Assessment

[0058] Based on the resource parameters collected in step 1, a multi-dimensional load assessment model is constructed, and the comprehensive load index of the nodes is calculated using a formula. ,in accordance with The size of the load categorizes nodes into overloaded, lightly loaded, and normal nodes. Based on the resource parameters collected in step 1, a multi-dimensional load assessment model is constructed, and the overall node load index is calculated using the following formula. :

[0059] ;

[0060] in, These are the normalized load values ​​for CPU utilization, memory utilization, bandwidth utilization, and forwarding latency, respectively, all ranging from [0,1]; weighting coefficients. satisfy It can be dynamically adjusted according to business needs, and can improve latency-sensitive businesses. Value, bandwidth-sensitive services can improve Value; when the node's overall load index When the node's overall load index is high, it is marked as an overloaded node; when the node's overall load index is high, it is marked as an overloaded node. When, mark as a lightly loaded node, if When this happens, it is marked as a normal node, where For custom preset values.

[0061] Load status assessment uses a multi-dimensional weighted assessment model to quantify real-time resource status monitoring data and generate a load index that can influence scheduling decisions. The load status assessment process is as follows:

[0062] a. Normalization: Map each parameter to the [0,1] interval, corresponding to 30% CPU utilization. =0.3, memory utilization of 60% corresponds to =0.6, bandwidth utilization of 90% corresponds to =0.9, based on a maximum network latency of 100ms, calculate the value corresponding to a latency of 95ms. =95 / 100=0.95;

[0063] b. Weight Configuration: By default, the CPU parameter weight is set to... =0.2, set the memory parameter weight to =0.2, set the bandwidth parameter weight to =0.3, set the delay parameter weight to =0.3;

[0064] c. Load Index Calculation: Set the upper limit of the comprehensive load index. =0.8, lower limit value =0.3, calculate the switch Obviously If the value is 0, it means that the current switch is overloaded.

[0065] d. Status flags: based on the overall load index and upper limit threshold The switch is marked as overloaded and this information is synchronized to the scheduling decision submodule.

[0066] Step 3, Dynamic scheduling strategy generation

[0067] Based on step 2, the node load index is given. As input load parameters, if an abnormal load is detected, the load balancing strategy is invoked and a scheduling instruction is output, as follows:

[0068] Deploy a scheduling decision submodule at the application layer of OpenDaylight to generate adaptive scheduling policies, which will be applied when overloaded nodes exist. and multiple lightly loaded nodes At this time, it is necessary to calculate the overload node. To each lightly loaded node Normalized resource migration costs between Choose the one with the lowest cost Using a lightly loaded node as the target node reduces migration costs. The calculation formula is as follows:

[0069] ;

[0070] in, These represent the normalized migration delay, link loss rate, and number of flow table entries, respectively. Indicates overloaded nodes With lightly loaded nodes Migration delay between; Indicates overloaded nodes With lightly loaded nodes Link loss rate between; Indicates overloaded nodes With lightly loaded nodes The number of flow table entries that need to be migrated between them; , , The normalized values ​​are all in the range of [0,1]. , , These are the weighting coefficients, set to the default value. =0.4、 =0.3、 =0.3, which can be adjusted according to business needs.

[0071] Switch A shows a comprehensive load index =0.81, indicating overload, with a total of 200 non-priority flow tables; the combined load indices of switches B and C are respectively =0.25、 =0.28, indicating a light load state; when both are on an idle link, calculate the basic link data: the actual link latency between switches A and B is 25ms, and the link loss rate is... =30%, the actual link latency between switches A and C is 40ms, and the link loss rate is 30%. =60%; Set the delay weight, loss weight, and flow table quantity weight as follows: , , .

[0072] The collected raw data was normalized within the [0,1] interval to eliminate the influence of unit differences. Based on a maximum network latency of 100ms, the normalized migration latencies from switch A to B and from A to C were calculated as follows: =25 / 100=0.25、 =40 / 100=0.25; Based on a maximum network loss of 20%, calculate the normalized link losses from switches A to B and A to C as follows: Based on a maximum flow table capacity of 400 entries for overloaded nodes, the number of flow tables that switch A needs to migrate is: Therefore, the number of normalized migration flow tables from switch A to B and from A to C is 1. .

[0073] Based on the normalized parameters and weights, the migration cost from switch A to switch B is calculated as follows: Calculate the migration cost from switch A to C. Migration costs Compare The flow table scheduling instruction is generated because the flow table is lower and switch B is selected as the target migration node.

[0074] Step 4: Based on the scheduling instructions generated in Step 3, instructions are sent to the southbound interface layer via the OpenDaylight northbound API. After conversion, the instructions are executed by the switch device. After execution, the scheduling effect is verified using the data collected by the monitoring submodule in Step 1 according to the node division criteria in Step 2: If the load of overloaded nodes drops below 0.7 and the load of lightly loaded nodes does not exceed 0.7, the scheduling is complete; otherwise, the scheduling is incomplete. If the scheduling is incomplete, steps 2 to 4 are repeated until the conditions are met. Specifically:

[0075] a. Flow table migration is achieved through OpenFlow's FlowMod message, which specifies the matching rules for the migrated flow table entries and the new forwarding port;

[0076] b. Monitor again 5 seconds after execution. If the combined load index of both switch A and switch B has decreased to [value missing], [further action is needed]. If the value is below a certain threshold, the scheduling is considered successful.

[0077] Performance Comparison Table

[0078]

[0079] The table above leads to the following conclusions: Compared with traditional static scheduling, this invention can improve resource utilization, reduce network congestion, and shorten fault recovery time.

[0080] like Figure 2 As shown, a dynamic resource scheduling system based on the OpenDaylight controller includes:

[0081] The OpenDaylight controller core module provides fundamental support capabilities. It includes the MD-SAL module, the southbound interface, and the northbound RESTCONF API module. The MD-SAL module provides unified data storage, storing configuration and operational status data, offering a reliable data source for the controller and enabling centralized management of network status. The southbound interface provides a standardized communication interface between the controller and network devices, facilitating network information collection and the issuance of control commands. The northbound RESTCONF API module provides an open management interface for upper-layer applications.

[0082] The resource monitoring submodule is deployed at the southbound interface layer and communicates with the switch via the OpenFlow protocol to periodically collect network node resource data.

[0083] The load assessment submodule calculates the comprehensive load index of network nodes based on monitoring data stored in MD-SAL and a multi-dimensional weighted assessment model.

[0084] The scheduling decision submodule calculates the migration cost from overloaded nodes to lightly loaded nodes based on the comprehensive network node load index provided by the load assessment submodule, selects the node with the optimal migration cost, and generates scheduling instructions.

[0085] The execution feedback submodule sends the scheduling instructions generated by its scheduling decision submodule to network node devices and verifies the execution effect.

[0086] 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 method for dynamic resource scheduling based on OpenDaylight controller, characterized in that, Comprising the following steps: Step 1, deploying a monitoring submodule in the OpenDaylight controller southbound interface layer, periodically collecting multiple resource parameters of network nodes by OpenFlow protocol, the monitoring period can be dynamically adjusted according to the network scale, and the data is stored in the distributed data storage module through MD-SAL; Step 2, based on the resource parameters collected in step 1, a multi-dimensional load evaluation model is constructed, and the node comprehensive load index is calculated by formula , according to the size of , the node is divided into overload node, light load node and normal node; Step 3, give node load index based on step 2 As an input load parameter, if the load is judged to be abnormal, the load balancing strategy is called and the scheduling instruction is output. Step 4, based on the scheduling instructions generated in step 3, the instructions are issued to the southbound interface layer through the northbound API of OpenDaylight, and are executed by the switch device after conversion; After execution, the data collected by the monitoring submodule in step 1 is verified according to the node division standard in step 2 to verify the scheduling effect; If the condition is met, the scheduling is completed, otherwise steps 2 to 4 are repeated until the condition is met. 2.The OpenDaylight controller-based dynamic resource scheduling method of claim 1, wherein, Said step 2 is specifically: Based on the resource parameters collected in step 1, a multi-dimensional load evaluation model is constructed, and the node comprehensive load index is calculated through the following formula : ； in, These are the normalized load values ​​for CPU utilization, memory utilization, bandwidth utilization, and forwarding latency, respectively, all ranging from [0,1]; weighting coefficients. satisfy It can be dynamically adjusted according to business needs, and can improve latency-sensitive businesses. Value, bandwidth-sensitive services can improve Value; when the node's overall load index When the node's overall load index is high, it is marked as an overloaded node; when the node's overall load index is high, it is marked as an overloaded node. When, mark as a lightly loaded node, if When this happens, it is marked as a normal node, where For custom preset values. 3.The OpenDaylight controller-based dynamic resource scheduling method of claim 1, wherein, Said step 3 is specifically: Deploy a scheduling decision submodule at the application layer of OpenDaylight to generate adaptive scheduling policies, which will be applied when overloaded nodes exist. and multiple lightly loaded nodes At this time, it is necessary to calculate the overload node. To each lightly loaded node Normalized resource migration costs between Choose the one with the lowest cost Using a lightly loaded node as the target node reduces migration costs. The calculation formula is as follows: ； wherein, respectively represent normalized migration latency, link loss rate, and the number of flow entries; represent the migration latency between the overloaded nodes and the lightly loaded nodes ; represent the link loss rate between the overloaded nodes and the lightly loaded nodes ; represent the number of flow entries that need to be migrated between the overloaded nodes and the lightly loaded nodes ; , , The normalized value ranges are [0, 1] respectively; , , are weight coefficients, and the default settings are = 0.4, = 0.3, = 0.3, which can be adjusted according to the business. 4.The OpenDaylight controller-based dynamic resource scheduling method of claim 1, wherein, Said step 4 is specifically: If the load of the overloaded node is reduced to below 0.7 and the load of the lightly loaded node does not exceed 0.7, the scheduling is completed, otherwise the scheduling is not completed.

5. An OpenDaylight controller-based dynamic resource scheduling system for applying the OpenDaylight controller-based dynamic resource scheduling method according to any one of claims 1-4, characterized in that, Comprise: OpenDaylight controller core module, which provides basic support capability; Resource monitoring submodule, which communicates with the switch through OpenFlow protocol and periodically collects network node resource data; Load evaluation submodule, which calculates the comprehensive load index of network nodes based on the monitoring data stored in MD-SAL and the multi-dimensional weighted evaluation model; Scheduling decision submodule, which calculates the migration cost of overloaded nodes to lightly loaded nodes according to the comprehensive load index of network nodes provided by the load evaluation submodule, selects the optimal migration cost node, and generates scheduling instructions; The execution feedback submodule generates the scheduling instructions generated by the scheduling decision submodule, issues them to the network node device and verifies the execution effect. 6.The OpenDaylight controller-based dynamic resource scheduling system of claim 5, wherein, Said OpenDaylight controller core module comprises: MD-SAL function module, which is used to provide unified data storage, the data types stored are configuration data and running state data, and provides a reliable data source for the controller, so as to centrally manage the network state; Southbound interface, which provides a standardized communication interface for the controller and network device, realizes network information collection and control instruction issuing operation; Northbound RESTCONF API function module, which is a management interface provided by the controller for upper layer application. 7.The OpenDaylight controller-based dynamic resource scheduling system of claim 6, wherein, The resource monitoring submodule is deployed in the southbound interface layer.

Images