Optimization method and system for realizing zero packet loss in live migration process of virtual machine of cloud platform

Abstract

The invention relates to the technical field of virtual machine live migration, in particular to an optimization method and system for achieving zero packet loss in the live migration process of a cloud platform virtual machine, and the method comprises the steps: adding an event publishing module in a Neutron service layer, pushing an event notification to a related OVS-Agent node through a message bus when the state of a port is changed, identifying event types based on port attribute pattern matching; the method has the advantages that by optimizing event processing and port binding logic, the service interruption time of the virtual machine in the live migration process is shortened, and the continuity and stability of services are improved; through plug-and-play network configuration and rapid flow table issuing, the packet loss rate in the live migration process is significantly reduced, and even zero packet loss can be realized, thereby improving the reliability of network transmission.

Description

Technical Field

[0001] The present invention relates to the technical field of virtual machine live migration, and specifically to an optimization method and system for achieving zero packet loss during the live migration of virtual machines in a cloud platform. Background Art

[0002] In a cloud platform based on OpenStack, the live migration of virtual machines is a key function for achieving high availability and flexibility. However, there are obvious packet loss problems in the existing technology during the live migration process, especially in VLAN and VXLAN network environments, where the packet loss durations can reach 6 seconds and 15 seconds respectively. This packet loss phenomenon is mainly caused by the delay of OpenStack network components (such as Neutron and OVS-Agent) when processing network port update events.

[0003] In the prior art, OVS-Agent uses a polling mechanism when processing port update events and adds a 2-second delay (sleep) in each poll to avoid overusing CPU resources. This mechanism will cause significant processing delays in high-concurrency event processing scenarios, thereby affecting the network connectivity of virtual machine live migration, resulting in packet loss and even service interruption. Summary of the Invention

[0004] The purpose of the present invention is to provide an optimization method and system for achieving zero packet loss during the live migration of virtual machines in a cloud platform to solve the problems raised in the above background art.

[0005] To achieve the above purpose, the present invention provides the following technical solutions: An optimization method for achieving zero packet loss during the live migration of virtual machines in a cloud platform, including:

[0006] Adding an event publishing module at the Neutron service layer. When the port status changes, an event notification is pushed to relevant OVS-Agent nodes through the message bus, and the event type is identified based on port attribute pattern matching;

[0007] Designing a high / low priority dual-queue architecture. The high-priority queue uses a lock-free data structure and is dedicated to events with high real-time requirements for live migration. The low-priority queue retains the original batch processing logic to process non-urgent operations;

[0008] The queue scheduler automatically assigns events to the corresponding queue according to the event type and dynamically adjusts the CPU resource quota based on the token bucket algorithm;

[0009] Limiting the resource quota of the OVS-Agent process through the Cgroups function of the Linux kernel. The real-time monitoring module collects the queue depth and processing delay. If the backlog in the high-priority queue exceeds the threshold, an alarm is triggered and a backup processing thread is started.

[0010] Preferably,.

[0011] Preferably, it also includes:

[0012] Modify the port binding logic in OVS-Agent so that it processes the port update event immediately when it receives it, regardless of whether the host in the binding information is the current node;

[0013] When a change in the host machine in the port binding information is detected, the corresponding flow table is immediately sent to OpenvSwitch;

[0014] Deploy a distributed event listener in Neutron-Server to capture port binding host change events in real time and synchronously notify the OVS-Agents of the source and target nodes;

[0015] After receiving the event, the target node OVS-Agent immediately calls the OVSDB interface to create a virtual port and generates a basic flow table based on the port attributes;

[0016] A globally unique version number is introduced for each port flow table. When a version conflict is detected, the coordination service confirms the final effective version through a two-phase commit protocol.

[0017] If the flow table fails to be delivered, OVS-Agent records the error status and triggers the rollback process, sending a migration failure signal to the Nova service to clean up the invalid flow table rules that have been delivered to the target node.

[0018] Preferably, it also includes:

[0019] A GARP injection module is integrated into the VM startup process. By calling a pre-configured script, GARP messages are actively broadcast within the VM's operating system to refresh the ARP table entries of the access layer switch. The script logic includes obtaining the VM's network card MAC address, constructing a GARP message containing the VM's IP and MAC address, and ensuring broadcast timeliness through a high-speed packet delivery mechanism.

[0020] For overlay networks, a proxy service is deployed on NeutronL2GW nodes to encapsulate virtual machine GARP packets and forward them to the physical network, ensuring that the TOR switches update the ARP cache in a timely manner.

[0021] OVS-Agent has a built-in sniffing module that continuously monitors the GARP packets of the virtual machine network port. If no valid packets are detected within the predetermined time window, the retransmission process is triggered through the Neutron API. If the retransmission fails, the Nova service is linked to perform a virtual machine health check.

[0022] Preferably, it also includes:

[0023] Design a multi-node simulation environment to simulate large-scale concurrent heat migration scenarios, collect metrics such as the flow table forwarding delay, CPU / memory occupancy rate, and message queue throughput of the OVS-Agent, compare the data before and after optimization, and verify that the high-priority event processing delay is reduced to less than 200 ms;

[0024] Utilize the OpenStack Cell V2 architecture to gradually roll out the new version of the OVS-Agent within a specific Cell unit, and compare the stability and performance through A / B testing;

[0025] Adjust the network stack parameters of the target node, including increasing net.core.netdev_max_backlog and optimizing net.ipv4.neigh.default.gc_thresh to reduce the risk of packet loss.

[0026] A system for an optimization method to achieve zero packet loss during the hot migration of virtual machines in a cloud platform, including:

[0027] An event classification and subscription module, which is set in the Neutron service layer and is used to push event notifications to relevant OVS-Agent nodes through the message bus when the port status changes, and identify the event type based on port attribute pattern matching;

[0028] A dynamic queue scheduling module, which is used to design a high / low priority dual-queue architecture. The high-priority queue uses a lock-free data structure and is dedicated to events with high real-time requirements for hot migration. The low-priority queue retains the original batch processing logic to handle non-urgent operations. The queue scheduler automatically assigns events to the corresponding queue based on the event type and dynamically adjusts the CPU resource quota based on the token bucket algorithm;

[0029] A resource isolation and monitoring module, which uses the Cgroups function of the Linux kernel to limit the resource quota of the OVS-Agent process. The real-time monitoring module continuously collects the queue depth and processing delay. If the high-priority queue backlog exceeds the threshold, an alarm is triggered and a backup processing thread is started.

[0030] Preferably, it further includes:

[0031] A port binding processing module, which is set in the OVS-Agent and is used to immediately check and process when receiving a port update event. When it detects that the host in the port binding information has changed, it immediately issues the corresponding flow table to OpenvSwitch;

[0032] The cross-node flow table synchronization module is deployed in Neutron-Server and is used to capture port binding host change events in real time and synchronously notify the OVS-Agent of the source and target nodes. After receiving the event, the OVS-Agent of the target node immediately calls the OVSDB interface to create a virtual port and generate a basic flow table based on the port attributes.

[0033] The flow table version control module is used to introduce a globally unique version number for each port flow table. When a version conflict is detected, the coordination service confirms the final effective version through a two-phase commit protocol.

[0034] The exception handling module is used to record the error status and trigger the rollback process when the flow table fails to be delivered. It sends a migration failure signal to the Nova service and cleans up the invalid flow table rules that have been delivered to the target node.

[0035] Preferably, it also includes:

[0036] The GARP injection module is integrated into the VM startup process. It actively broadcasts GARP messages within the VM operating system by calling a pre-configured script, refreshing the ARP table entries of the access layer switch. The script logic includes obtaining the MAC address of the VM network card, constructing a GARP message containing the VM's IP and MAC address, and ensuring the timeliness of the broadcast through a high-speed packet transmission mechanism.

[0037] The network topology adaptation module deploys a proxy service on the NeutronL2GW node for the overlay network, encapsulating the virtual machine GARP message and forwarding it to the physical network, ensuring that the TOR switch updates the ARP cache in a timely manner.

[0038] The closed-loop monitoring module is set in the OVS-Agent. The built-in sniffing module continuously monitors the GARP packets of the virtual machine network port. If no valid packets are detected within the predetermined time window, the retransmission process is triggered through the Neutron API. If the retransmission fails, the Nova service is linked to perform a virtual machine health check.

[0039] Also includes:

[0040] The stress testing module is used to design a multi-node simulation environment, simulate large-scale concurrent hot migration scenarios, collect OVS-Agent flow table delivery latency, CPU / memory usage, and message queue throughput metrics, and compare the data before and after optimization to verify that the processing latency of high-priority events has been reduced to below 200ms. The grayscale release module uses the OpenStack Cell V2 architecture to gradually release the new version of OVS-Agent within specific cells, and compares its stability and performance through A / B testing.

[0041] Kernel-level tuning module for adjusting network stack parameters of a target node, including increasing net.core.netdev_max_backlog, optimizing net.ipv4.neigh.default.gc_thresh, and reducing the risk of packet loss.

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

[0043] The optimization method and system for achieving zero packet loss during the live migration of virtual machines in a cloud platform proposed by the present invention reduce the service interruption time of virtual machines during live migration and improve the continuity and stability of services by optimizing event handling and port binding logic; significantly reduce the packet loss rate during live migration, and even achieve zero packet loss, thereby improving the reliability of network transmission, through plug-and-play network configuration and fast flow table distribution; reduce the operation and maintenance work caused by network problems by improving the stability and reliability of the network, thereby reducing the operation and maintenance costs. Description of the Drawings

[0044] Figure 1 It is a flowchart of the method of the present invention. Detailed Embodiments

[0045] In order to clearly and completely describe the objectives, technical solutions of the present invention and make the advantages more clear, the following further details the embodiments of the present invention with reference to the drawings. It should be understood that the specific embodiments described herein are some but not all embodiments of the present invention, and are only used to explain the embodiments of the present invention, not to limit the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present invention.

[0046] Embodiment 1, please refer to Figure 1 The present invention provides a technical solution: an optimization method for achieving zero packet loss during the live migration of virtual machines in a cloud platform, including the following steps:

[0047] I. Optimize the event handling mechanism

[0048] Scheme description:

[0049] Aiming at the latency defect of the original polling mechanism (Polling) of OpenStack OVS-Agent, this scheme constructs an event-driven model and a multi-level priority queue system to achieve millisecond-level real-time response:

[0050] Event classification and subscription:

[0051] Add an event publishing module at the Neutron service layer. When the port status (such as binding:host_id, device_owner) changes, push event notifications to relevant OVS-Agent nodes through the message bus (RabbitMQ).

[0052] Event type recognition is based on port attribute pattern matching. For example, the feature of a live migration event is that the host binding field changes and the device type is marked as a virtual machine network card.

[0053] Dynamic queue scheduling:

[0054] Design a dual-queue architecture with high / low priorities:

[0055] High-priority queue: Use a lock-free data structure to ensure the atomicity of event processing. It is dedicated to events with high real-time requirements such as live migration and failover.

[0056] Low-priority queue: Retain the original batch processing logic to handle non-urgent operations such as port security group updates and QoS policy adjustments.

[0057] The queue scheduler automatically assigns events to the corresponding queue according to the event type and dynamically adjusts the CPU resource quota based on the token bucket algorithm to ensure that high-priority tasks can temporarily break through resource limitations.

[0058] Resource isolation mechanism:

[0059] Use the Cgroups function of the Linux kernel to limit the resource quota of the OVS-Agent process to prevent excessive computing resources from being occupied during the handling of sudden events.

[0060] The real-time monitoring module continuously collects the queue depth and processing latency. If the high-priority queue backlog exceeds the threshold, trigger an alarm and start a backup processing thread.

[0061] Implementation process

[0062] Event triggering stage:

[0063] After Neutron-Server detects a change in port binding information, generate a message body with an event type label and push it to the OVS-Agent of the source node and the target node through RPC calls.

[0064] Event processing stage:

[0065] After the OVS-Agent receives the event, the classifier parses the event type and assigns it to the corresponding queue. High-priority events immediately trigger the pre-download operation of the flow table, and low-priority events enter the batch processing buffer.

[0066] During the flow table pre - distribution phase, before the virtual machine completes migration, the target node OVS - Agent writes the flow table rules to the local OpenvSwitch instance in advance and configures temporary flooding rules to avoid network interruption.

[0067] Resource recovery phase:

[0068] After migration is completed, the source node OVS - Agent receives the confirmation signal from the Nova service, deletes the remaining flow table copies, and releases the associated resources.

[0069] II. Improved port binding logic

[0070] Solution description:

[0071] Modify the port binding logic in the OVS - Agent so that it processes immediately when receiving a port update event, regardless of whether the host in the binding information is the current node.

[0072] Implementation steps:

[0073] Add logic in the OVS - Agent to immediately check and process all port update events.

[0074] When it is detected that the host in the port binding information has changed, immediately issue the corresponding flow table to OpenvSwitch.

[0075] Ensure that before the virtual machine starts, the required underlying flow tables have been fully issued, realizing plug - and - play of network cards.

[0076] Cross - node flow table synchronization mechanism:

[0077] Deploy a distributed event listener in Neutron - Server to capture port binding host change events in real - time and synchronously notify the OVS - Agents of the source node and the target node.

[0078] After receiving the event, the target node OVS - Agent immediately calls the OVSDB interface to create a virtual port (vport) and generates a basic flow table based on port attributes (VLAN ID, security group rules).

[0079] Flow table version control policy:

[0080] Introduce a globally unique version number (generated based on the timestamp and node ID) for each port flow table. When a version conflict is detected, the coordination service confirms the final effective version through a two - phase commit protocol.

[0081] Exception handling mechanism:

[0082] If the flow table is not successfully downloaded (e.g., OVSDB connection timeout), the OVS-Agent records the error status and triggers a rollback process:

[0083] Send a migration failure signal to the Nova service, triggering the virtual machine to roll back to the source node.

[0084] Clean up the invalid flow table rules downloaded on the target node to prevent residual configurations from affecting subsequent operations.

[0085] III. GARP Packet Processing

[0086] Solution Description:

[0087] After the virtual machine is started, a GARP (gratuitous ARP) packet is automatically sent to refresh the ARP cache of other devices under the same VLAN to ensure network connectivity.

[0088] Proactive GARP Announcement:

[0089] Integrate the GARP injection module into the virtual machine startup process, and actively broadcast GARP packets in the virtual machine operating system by calling a preset script to refresh the ARP entries of the access layer switch.

[0090] The script logic includes obtaining the MAC address of the virtual machine network card, constructing a GARP packet containing the virtual machine IP and MAC, and ensuring the broadcast timeliness through a high-speed packet sending mechanism.

[0091] Network Topology Adaptation:

[0092] For the Overlay network (such as VXLAN), deploy a proxy service on the Neutron L2GW node, encapsulate the virtual machine GARP packets and forward them to the physical network to ensure that the TOR switch updates the ARP cache in a timely manner.

[0093] Closed-loop Monitoring System:

[0094] The OVS-Agent is built with a sniffing module to continuously monitor the GARP packets of the virtual machine network interface. If no valid packets are detected within a predetermined time window, the retransmission process is triggered through the Neutron API.

[0095] When the retransmission fails, the Nova service is linked to perform a virtual machine health check to rule out network driver abnormalities or configuration errors.

[0096] IV. Performance Optimization Guarantee

[0097] Stress Test Verification:

[0098] Design a multi-node simulation environment to simulate large-scale concurrent hot migration scenarios (such as 1,000 virtual machines per minute) and collect OVS-Agent metrics such as flow table delivery delay, CPU / memory usage, and message queue throughput.

[0099] Comparing the data before and after optimization, it was verified that the processing delay of high-priority events was reduced to below 200ms (the original solution had an average of 2s).

[0100] Grayscale release strategy:

[0101] Leveraging the OpenStack Cell V2 architecture, the new version of OVS-Agent is limited to specific Cell units and gradually released online, with stability and performance compared through A / B testing.

[0102] Kernel-level tuning:

[0103] Adjust the network stack parameters of the target node, including increasing net.core.netdev_max_backlog (increasing the network card packet cache queue) and optimizing net.ipv4.neigh.default.gc_thresh (preventing premature recycling of ARP table entries) to reduce the risk of packet loss.

[0104] Example 2. Based on Example 1, a system for optimizing a method for achieving zero packet loss during hot migration of virtual machines on a cloud platform is proposed, including: an event classification and subscription module, which is arranged in the Neutron service layer and is used to push event notifications to relevant OVS-Agent nodes through the message bus when the port status changes, and identify the event type based on port attribute pattern matching; a dynamic queue scheduling module, which is used to design a high / low priority dual queue architecture, wherein the high priority queue adopts a lock-free data structure and is dedicated to events with high real-time requirements for hot migration, and the low priority queue retains the original batch processing logic to handle non-urgent operations, and the queue scheduler automatically allocates events to the corresponding queue according to the event type, and dynamically adjusts the CPU resource quota based on the token bucket algorithm; a resource isolation and monitoring module, which uses the Cgroups function of the Linux kernel to limit the resource quota of the OVS-Agent process, and the real-time monitoring module continuously collects queue depth and processing delay. If the backlog of the high priority queue exceeds the threshold, an alarm is triggered and a backup processing thread is started.

[0105] It also includes: a port binding processing module, which is set in the OVS-Agent and is used to immediately check and process the port update event when it is received. When a change in the host machine in the port binding information is detected, the corresponding flow table is immediately sent to OpenvSwitch; a cross-node flow table synchronization module, which is deployed in the Neutron-Server and is used to capture the port binding host change event in real time and synchronously notify the OVS-Agent of the source node and the target node. After receiving the event, the target node OVS-Agent immediately calls the OVSDB interface to create a virtual port and generates a basic flow table based on the port attributes; a flow table version control module is used to introduce a globally unique version number for each port flow table. When a version conflict is detected, the coordination service confirms the final effective version through a two-phase commit protocol; an exception handling module is used to record the error status and trigger the rollback process when the flow table fails to be sent, send a migration failure signal to the Nova service, and clean up the invalid flow table rules sent by the target node.

[0106] It also includes: a GARP injection module, which is integrated into the virtual machine startup process. By calling a preset script, it actively broadcasts GARP messages in the virtual machine operating system and refreshes the ARP table entries of the access layer switch. The script logic includes obtaining the MAC address of the virtual machine network card, constructing a GARP message containing the virtual machine IP and MAC, and ensuring the timeliness of the broadcast through a high-speed packet sending mechanism; a network topology adaptation module, for the Overlay network, deploys an agent service on the NeutronL2GW node, encapsulates the virtual machine GARP message and forwards it to the physical network to ensure that the TOR switch updates the ARP cache in time; a closed-loop monitoring module, which is set in the OVS-Agent. The built-in sniffing module continuously monitors the GARP message of the virtual machine network port. If no valid message is detected within the predetermined time window, the retransmission process is triggered through the NeutronAPI. When the retransmission fails, the Nova service is linked to perform a virtual machine health check.

[0107] It also includes: a stress testing module for designing a multi-node simulation environment, simulating large-scale concurrent hot migration scenarios, collecting OVS-Agent's flow table delivery delay, CPU / memory usage, and message queue throughput indicators, and comparing the data before and after optimization to verify that the high-priority event processing delay is reduced to below 200ms; a grayscale release module, which uses the OpenStackCellV2 architecture to limit the new version of OVS-Agent to specific Cell units and gradually launch it online, comparing stability and performance through A / B testing; a kernel-level tuning module for adjusting the network stack parameters of the target node, including increasing net.core.netdev_max_backlog and optimizing net.ipv4.neigh.default.gc_thresh to reduce the risk of packet loss.

[0108] Although embodiments of the present invention have been shown and described, those of ordinary skill in the art will understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the present invention. The scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. An optimization method for achieving zero packet loss during the live migration of virtual machines in a cloud platform, characterized in that: Including: Add an event publishing module at the Neutron service layer. When the port status changes, push event notifications to relevant OVS-Agent nodes through the message bus, and identify the event type based on port attribute pattern matching; Design a high / low priority dual-queue architecture. The high-priority queue uses a lock-free data structure and is dedicated to events with high requirements for live migration real-time performance. The low-priority queue retains the original batch processing logic to handle non-urgent operations; The queue scheduler automatically assigns to the corresponding queue according to the event type and dynamically adjusts the CPU resource quota based on the token bucket algorithm; Use the Cgroups function of the Linux kernel to limit the resource quota of the OVS-Agent process. The real-time monitoring module collects the queue depth and processing latency. If the backlog in the high-priority queue exceeds the threshold, trigger an alarm and start a backup processing thread.

2. The optimization method for achieving zero packet loss during the hot migration of virtual machines on a cloud platform according to claim 1, characterized in that: Also including: Modify the port binding logic in the OVS-Agent so that it processes immediately when receiving a port update event, regardless of whether the host in the binding information is the current node; When detecting a change in the host in the port binding information, immediately issue the corresponding flow table to OpenvSwitch; Deploy a distributed event listener in Neutron-Server to capture port binding host change events in real time and synchronously notify the OVS-Agent of the source node and the target node; After receiving the event, the target node OVS-Agent immediately calls the OVSDB interface to create a virtual port and generates a basic flow table based on the port attributes; Introduce a globally unique version number for each port flow table. When a version conflict is detected, the coordination service confirms the finally effective version through a two-phase commit protocol; If the flow table issuance fails, the OVS-Agent records the error status and triggers a rollback process, sends a migration failure signal to the Nova service, and clears the invalid flow table rules issued by the target node.

3. An optimization method for achieving zero packet loss during the hot migration of virtual machines in a cloud platform according to claim 2, characterized in that: Also including: Integrate a GARP injection module into the virtual machine startup process. Actively broadcast GARP packets in the virtual machine operating system by calling a preset script to refresh the ARP entries of the access layer switch. The script logic includes obtaining the virtual machine network card MAC address, constructing a GARP packet containing the virtual machine IP and MAC, and ensuring the broadcast timeliness through a high-speed packet sending mechanism; For the Overlay network, deploy a proxy service at the NeutronL2GW node, encapsulate the virtual machine GARP packets and forward them to the physical network to ensure that the TOR switch updates the ARP cache in time; The OVS-Agent has a built-in sniffing module that continuously listens for GARP packets on the virtual machine network interface. If no valid packets are detected within a predetermined time window, trigger a retransmission process through the Neutron API. When the retransmission fails, link with the Nova service to perform a virtual machine health check.

4. An optimization method for achieving zero packet loss during the hot migration of virtual machines in a cloud platform according to claim 3, characterized in that: Also including: Design a multi-node simulation environment to simulate a large-scale concurrent live migration scenario, collect metrics such as the flow table issuance latency, CPU / memory occupancy rate, and message queue throughput of the OVS-Agent, compare the data before and after optimization, and verify that the processing latency of high-priority events is reduced to less than 200ms; Using the OpenStackCellV2 architecture, the new version of the OVS-Agent is gradually launched within a specific Cell unit, and the stability and performance are compared through A / B testing; Adjust the network stack parameters of the target node, including increasing net.core.netdev_max_backlog, optimizing net.ipv4.neigh.default.gc_thresh, and reducing the risk of packet loss.

5. A system for an optimization method for achieving zero packet loss during the hot migration of virtual machines in a cloud platform, characterized in that: Including: Event classification and subscription module, which is set in the Neutron service layer and is used to push event notifications to relevant OVS-Agent nodes through the message bus when the port status changes, and identify the event type based on port attribute pattern matching; Dynamic queue scheduling module, which is used to design a high / low priority dual-queue architecture. The high-priority queue uses a lock-free data structure and is dedicated to events with high real-time requirements for live migration. The low-priority queue retains the original batch processing logic to handle non-emergency operations. The queue scheduler automatically allocates events to the corresponding queue based on the event type and dynamically adjusts the CPU resource quota based on the token bucket algorithm; Resource isolation and monitoring module, which uses the Cgroups function of the Linux kernel to limit the resource quota of the OVS-Agent process. The real-time monitoring module continuously collects the queue depth and processing latency. If the backlog of the high-priority queue exceeds the threshold, an alarm is triggered and a backup processing thread is started.

6. A system according to claim 5, wherein: Also including: Port binding processing module, which is set in the OVS-Agent and is used to immediately check and process when a port update event is received. When it is detected that the host in the port binding information has changed, the corresponding flow table is immediately sent down to the OpenvSwitch; Cross-node flow table synchronization module, which is deployed in the Neutron-Server and is used to capture port binding host change events in real time and synchronously notify the OVS-Agent of the source node and the target node. After receiving the event, the target node OVS-Agent immediately calls the OVSDB interface to create a virtual port and generates a basic flow table based on the port attributes; Flow table version control module, which is used to introduce a globally unique version number for each port flow table. When a version conflict is detected, the coordination service confirms the finally effective version through a two-phase commit protocol; Exception handling module, which is used to record the error status and trigger a rollback process when the flow table is sent down fails, send a migration failure signal to the Nova service, and clean up the invalid flow table rules sent down on the target node.

7. A system according to claim 6, characterized in that: Also including: GARP injection module, which is integrated into the virtual machine startup process and actively broadcasts GARP packets in the virtual machine operating system by calling a preset script to refresh the ARP table entries of the access layer switch. The script logic includes obtaining the MAC address of the virtual machine network card, constructing a GARP packet containing the virtual machine IP and MAC, and ensuring the broadcast timeliness through a high-speed packet sending mechanism; The network topology adaptation module deploys a proxy service on the NeutronL2GW node for the overlay network, encapsulating the virtual machine GARP message and forwarding it to the physical network, ensuring that the TOR switch updates the ARP cache in a timely manner. The closed-loop monitoring module is set in the OVS-Agent. The built-in sniffing module continuously monitors the GARP packets of the virtual machine network port. If no valid packets are detected within the predetermined time window, the retransmission process is triggered through the Neutron API. If the retransmission fails, the Nova service is linked to perform a virtual machine health check.

8. A system according to claim 7, characterized in that: Also includes: The stress testing module is used to design a multi-node simulation environment, simulate large-scale concurrent hot migration scenarios, collect OVS-Agent flow table delivery delay, CPU / memory usage, and message queue throughput indicators, and compare the data before and after optimization to verify that the processing delay of high-priority events is reduced to below 200ms. The grayscale release module uses the OpenStack Cell V2 architecture to gradually release the new version of OVS-Agent within specific Cell units, and compares stability and performance through A / B testing; The kernel-level tuning module is used to adjust the network stack parameters of the target node, including increasing net.core.netdev_max_backlog and optimizing net.ipv4.neigh.default.gc_thresh to reduce the risk of packet loss.

Images