A hot migration optimization method and device based on OpenStack

Abstract

The invention discloses a hot migration optimization method and device based on OpenStack, which relates to the technical field of cloud computing; the method and device comprise: step 1: verifying the authority to execute hot migration of a virtual machine, assembling a hot migration request if the verification is passed, step 2: constructing a scheduling request of the virtual machine according to the hot migration request, step 3: screening out computing nodes that meet the requirements as target nodes according to the scheduling request, step 4: constructing the hot migration request again, and sending the reconstructed hot migration request to the Compute service of the original computing node where the virtual machine is currently located, and step 5: judging whether the virtual machine uses a security group driver that supports an iptables firewall through the Compute service of the original computing node, and performing hot migration according to the judgment situation; the invention avoids network interruption of the virtual machine during the hot migration process, reduces the impact on the business during the hot migration process, and improves the user experience.

Description

Technical Field

[0001] The invention discloses a hot migration optimization method and device based on OpenStack, and relates to the technical field of cloud computing. Background Art

[0002] Among the cloud services currently provided by cloud service providers, OpenStack is the most typical representative. As a large-scale cloud operating system, OpenStack controls the three major resources of computing, network, and storage, provides a web-based visual interface for administrators to control, and adopts an identity authentication mechanism to grant user permissions and resources. It has its own standard infrastructure and service functions, but also has other components to provide other services to ensure the high availability of user applications.

[0003] Live Migration is the operation of migrating a virtual machine from one physical server to another. However, the live migration solution currently implemented in OpenStack has realized the function of migrating virtual machines to computing nodes. However, there are still problems such as virtual network interruption during live migration, that is, there is jitter in the network of the virtual machine during the migration process. With the widespread adoption of domestic servers, due to the performance limitations of CPU and memory, the network jitter may be more obvious in the open source solution, which will affect the normal use of users. Summary of the invention

[0004] In view of the problems in the prior art, the present invention provides a hot migration optimization method and device based on OpenStack, which avoids network interruption of virtual machines during hot migration by configuring a hot migration network, reduces the impact on services during hot migration, and improves user experience.

[0005] The specific scheme proposed by the present invention is:

[0006] The present invention provides a hot migration optimization method based on OpenStack, comprising:

[0007] Step 1: Call the OpenStack API interface to verify the permission to perform virtual machine live migration. If the verification is successful, assemble a live migration request and send the request to the Conductor component of Nova. The request includes at least the virtual machine's universal unique identifier UUID.

[0008] Step 2: The Conductor component obtains the specification information of the virtual machine from the database according to the hot migration request. Based on the specification information, a scheduling request for the virtual machine is constructed and sent to the Scheduler component. The scheduling request includes at least the number of CPUs, CPU type, memory capacity, and affinity attributes of the virtual machine.

[0009] Step 3: The Scheduler component selects the computing nodes that meet the requirements as the target nodes according to the scheduling request, and sends the target node information to the Conductor component.

[0010] Step 4: The Conductor component reconstructs the hot migration request based on the target node information, and sends the reconstructed hot migration request to the Compute service of the original computing node where the virtual machine is currently located.

[0011] Step 5: Use the Compute service of the original computing node to determine whether the virtual machine uses a security group driver that supports the iptables firewall, and perform hot migration based on the determination:

[0012] If the virtual machine currently uses a security group driver that supports the iptables firewall, the Compute service of the target node is notified to create and configure the switch device required by the virtual machine locally on the target node for hot migration;

[0013] If the virtual machine is not currently using a security group driver that supports the iptables firewall, the original computing node will suspend the hot migration of the virtual machine and reserve time for the target node to configure the switch device.

[0014] The target node creates the switch device required for the virtual machine, and the Neutron service of the target node configures the switch device according to the type of the virtual machine network. After the configuration is completed, an asynchronous event notification is sent to the Compute service of the original computing node. The Compute service of the original computing node starts the hot migration operation of the suspended virtual machine according to the notification.

[0015] Furthermore, in step 1 of the OpenStack-based hot migration optimization method, the OpenStack API interface is called to verify the permission to perform hot migration, including: checking whether the user has the permission to perform virtual machine hot migration, if the user does not have the permission to perform virtual machine hot migration, the user is considered to be an unauthorized user, the request of the unauthorized user is immediately stopped, and an exception of unauthorized request is returned when the API responds, if the user has the permission to perform virtual machine hot migration, the verification is passed.

[0016] Further, in step 5 of the OpenStack-based hot migration optimization method, configuring the switch device according to the type of the virtual machine network through the Neutron service of the target node includes:

[0017] Configure the virtual LAN VLAN of the relevant ports of the switch device. The network information of the virtual machine network port is obtained through the Neutron service. According to the universal unique identifier UUID of the network information, the deployment status of the local virtual LAN VLAN on the target node is queried. If the virtual LAN VLAN has not been deployed on the target node, a virtual LAN VLAN is allocated to the virtual machine and the virtual LAN VLAN is recorded in the local cache of the Neutron service.

[0018] Furthermore, the OpenStack-based hot migration optimization method also includes step 6: monitoring the running status of the virtual machine through the Compute service of the original computing node, and when the hot migration of the virtual machine is completed normally, calling the interface of the Neutron service through the Compute service of the original computing node to update the metadata information of the virtual machine in the database, and cleaning up the remaining log files and network port information of the virtual machine on the original computing node.

[0019] The present invention also provides a hot migration optimization device based on OpenStack, including a verification module, an assembly module, a scheduling module, an analysis and judgment module and a hot migration management module.

[0020] The verification module calls the OpenStack API interface to verify the permission to perform virtual machine hot migration. If the verification is passed, the assembly module assembles a hot migration request and sends the request to the Conductor component of Nova. The request includes at least the virtual machine's universal unique identifier UUID.

[0021] The assembly module obtains the specification information of the virtual machine from the database according to the hot migration request through the Conductor component, constructs the scheduling request of the virtual machine based on the specification information and sends it to the Scheduler component. The scheduling request includes at least the number of CPUs, CPU type, memory capacity and affinity attributes of the virtual machine.

[0022] The scheduling module uses the Scheduler component to filter out the computing nodes that meet the requirements as the target nodes according to the scheduling request, and sends the information of the target nodes to the Conductor component.

[0023] The assembly module reconstructs the hot migration request through the Conductor component according to the information of the target node, and sends the reconstructed hot migration request to the Compute service of the original computing node where the virtual machine is currently located.

[0024] The analysis and judgment module determines whether the virtual machine uses the security group driver that supports the iptables firewall through the Compute service of the original computing node. The hot migration management module performs hot migration based on the judgment:

[0025] If the virtual machine currently uses a security group driver that supports the iptables firewall, the hot migration management module notifies the Compute service of the target node to create and configure the switch device required by the virtual machine locally on the target node to perform hot migration;

[0026] If the virtual machine is not currently using a security group driver that supports the iptables firewall, the original computing node will suspend the hot migration of the virtual machine through the hot migration management module and reserve time for the target node to configure the switch device.

[0027] The target node creates the switch device required for the virtual machine through the hot migration management module. The hot migration management module configures the switch device according to the type of the virtual machine network through the Neutron service of the target node, and after the configuration is completed, sends an asynchronous event notification to the Compute service of the original computing node through the Neutron service, so that the Compute service of the original computing node starts the hot migration operation of the suspended virtual machine according to the notification.

[0028] Furthermore, the verification module of the OpenStack-based hot migration optimization device calls the OpenStack API interface to verify the permission to perform hot migration, including: checking whether the user has the permission to perform virtual machine hot migration. If the user does not have the permission to perform virtual machine hot migration, the user is considered to be an unauthorized user, and the request of the unauthorized user is immediately stopped, and an exception of unauthorized request is returned when the API responds. If the user has the permission to perform virtual machine hot migration, the verification is passed.

[0029] Furthermore, the hot migration management module of the hot migration optimization device based on OpenStack configures the switch device according to the type of the virtual machine network through the Neutron service of the target node, including:

[0030] Configure the virtual LAN VLAN of the relevant ports of the switch device. The network information of the virtual machine network port is obtained through the Neutron service. According to the universal unique identifier UUID of the network information, the deployment status of the local virtual LAN VLAN on the target node is queried. If the virtual LAN VLAN has not been deployed on the target node, a virtual LAN VLAN is allocated to the virtual machine and the virtual LAN VLAN is recorded in the local cache of the Neutron service.

[0031] Furthermore, the OpenStack-based hot migration optimization device also includes step 6: monitoring the running status of the virtual machine through the Compute service of the original computing node, and when the hot migration of the virtual machine is completed normally, calling the interface of the Neutron service through the Compute service of the original computing node to update the metadata information of the virtual machine in the database, and cleaning up the remaining log files and network port information of the virtual machine on the original computing node.

[0032] The benefits of the present invention are:

[0033] The method of the present invention aims at the problems of hot migration interruption and the like that are easy to occur in the hot migration process of the current native OpenStack. Based on the hot migration process of the original OpenStack, a new hot migration execution step is added, so as to avoid the interruption of the virtual network during the hot migration process, avoid the impact of unexpected virtual network fluctuations on the running business of the customer, improve the hot migration capability of the cloud platform, and improve the customer's user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 It is a schematic flow chart of the method of the present invention. DETAILED DESCRIPTION

[0035] The present invention is further described below in conjunction with the accompanying drawings and specific embodiments so that those skilled in the art can better understand the present invention and implement it, but the embodiments are not intended to limit the present invention.

[0036] Embodiment 1: The present invention provides a hot migration optimization method based on OpenStack, comprising:

[0037] Step 1: Call the OpenStack API interface to verify the permission to perform virtual machine live migration. If the verification is successful, assemble a live migration request and send the request to the Conductor component of Nova. The request includes at least the virtual machine's universal unique identifier UUID.

[0038] The calling of the OpenStack API interface to verify the permission to perform live migration may further include: checking whether the user has the permission to perform live migration of virtual machines. If the user does not have the permission to perform live migration of virtual machines, the user is considered to be an unauthorized user, the request of the unauthorized user is immediately stopped, and an exception indicating that the request is not authorized is returned when the API responds. If the user has the permission to perform live migration of virtual machines, the verification is passed.

[0039] Step 2: The Conductor component obtains the specification information of the virtual machine from the database according to the hot migration request. Based on the specification information, a scheduling request for the virtual machine is constructed and sent to the Scheduler component. The scheduling request includes at least the number of CPUs, CPU type, memory capacity and affinity attributes of the virtual machine.

[0040] Step 3: The Scheduler component selects the computing nodes that meet the requirements as the target nodes according to the scheduling request, and sends the target node information to the Conductor component.

[0041] In order to select computing nodes that meet the requirements, in addition to considering the remaining memory capacity and allocated CPU capacity of the computing nodes, the weighter can also be set through the Scheduler component to set weights for different service functions of the computing nodes. The default weight values ​​of all service functions can be 1. After combining the weights, the computing nodes that best meet the requirements can be selected as the target nodes.

[0042] Step 4: The Conductor component reconstructs the hot migration request according to the information of the target node, and sends the reconstructed hot migration request to the Compute service of the original computing node where the virtual machine is currently located.

[0043] Step 5: Use the Compute service of the original computing node to determine whether the virtual machine uses a security group driver that supports the iptables firewall, and perform hot migration based on the determination:

[0044] If the virtual machine currently uses a security group driver that supports the iptables firewall, the Compute service of the target node is notified to create and configure the switch device required by the virtual machine locally on the target node. After the switch device is created, the target node can be used to notify the original compute node to continue other processes of hot migration and perform hot migration.

[0045] If the virtual machine is not currently using a security group driver that supports the iptables firewall, the original computing node suspends the hot migration of the virtual machine and configures the switch device to reserve time for the target node. That is, when the target node creates the corresponding switch device during the hot migration process, the original computing node keeps the virtual machine in the paused state and does not run hot migration, and configures the switch device data reservation time for the Neutron service of the target node.

[0046] The target node creates the switch device required for the virtual machine, and the Neutron service of the target node configures the switch device according to the type of the virtual machine network. After the configuration is completed, an asynchronous event notification is sent to the Compute service of the original computing node. The Compute service of the original computing node starts the hot migration operation of the suspended virtual machine according to the notification.

[0047] Configuring the switch device according to the type of the virtual machine network through the Neutron service of the target node may further include:

[0048] Configure the virtual LAN VLAN of the relevant ports of the switch device. The network information of the virtual machine network port is obtained through the Neutron service. According to the universal unique identifier UUID of the network information, the deployment status of the local virtual LAN VLAN on the target node is queried. If the virtual LAN VLAN has not been deployed on the target node, a virtual LAN VLAN is allocated to the virtual machine and the virtual LAN VLAN is recorded in the local cache of the Neutron service to improve the speed of accessing content in the future.

[0049] In addition, the Neutron service of the target node can also obtain the security group information of the network from the port data, and according to the security group information, configure the configuration options translated into the switch device, and configure the configuration options into the switch device of the target node.

[0050] Example 2: Based on Example 1, the method of the present invention may further include step 6: monitoring the running status of the virtual machine through the Compute service of the original computing node, and when the hot migration of the virtual machine is completed normally, calling the interface of the Neutron service through the Compute service of the original computing node to update the metadata information of the virtual machine in the database, and cleaning up the remaining log files and network port information of the virtual machine on the original computing node.

[0051] Embodiment 3: The present invention also provides a hot migration optimization device based on OpenStack, including a verification module, an assembly module, a scheduling module, an analysis and judgment module and a hot migration management module.

[0052] The verification module calls the OpenStack API interface to verify the permission to perform virtual machine hot migration. If the verification is successful, the assembly module assembles a hot migration request and sends the request to the Conductor component of Nova. The request includes at least the virtual machine's universal unique identifier UUID.

[0053] The assembly module obtains the specification information of the virtual machine from the database according to the hot migration request through the Conductor component, constructs the scheduling request of the virtual machine based on the specification information and sends it to the Scheduler component. The scheduling request includes at least the number of CPUs, CPU type, memory capacity and affinity attributes of the virtual machine.

[0054] The scheduling module uses the Scheduler component to filter out the computing nodes that meet the requirements as the target nodes according to the scheduling request, and sends the information of the target nodes to the Conductor component.

[0055] The assembly module reconstructs the hot migration request through the Conductor component according to the information of the target node, and sends the reconstructed hot migration request to the Compute service of the original computing node where the virtual machine is currently located.

[0056] The analysis and judgment module determines whether the virtual machine uses the security group driver that supports the iptables firewall through the Compute service of the original computing node. The hot migration management module performs hot migration based on the judgment:

[0057] If the virtual machine currently uses a security group driver that supports the iptables firewall, the hot migration management module notifies the Compute service of the target node to create and configure the switch device required by the virtual machine locally on the target node to perform hot migration;

[0058] If the virtual machine is not currently using a security group driver that supports the iptables firewall, the original computing node will suspend the hot migration of the virtual machine through the hot migration management module and reserve time for the target node to configure the switch device.

[0059] The target node creates the switch device required for the virtual machine through the hot migration management module. The hot migration management module configures the switch device according to the type of the virtual machine network through the Neutron service of the target node, and after the configuration is completed, sends an asynchronous event notification to the Compute service of the original computing node through the Neutron service, so that the Compute service of the original computing node starts the hot migration operation of the suspended virtual machine according to the notification.

[0060] As the information interaction and execution process between the modules of the above-mentioned device are based on the same concept as the embodiment of the method of the present invention, the specific contents can be found in the description of the embodiment of the method of the present invention and will not be repeated here.

[0061] Similarly, the device of the present invention addresses the problems of hot migration interruption that are prone to occur during the hot migration process of the current native OpenStack. Based on the original OpenStack hot migration process, new hot migration execution steps are added, thereby avoiding virtual network interruption during the hot migration process and preventing unexpected virtual network fluctuations from affecting the customer's running business, improving the cloud platform's hot migration capabilities, and enhancing the customer's user experience.

[0062] It should be noted that not all steps and modules in the above-mentioned processes and device structures are necessary, and some steps or modules can be ignored according to actual needs. The execution order of each step is not fixed and can be adjusted as needed. The system structure described in the above-mentioned embodiments can be a physical structure or a logical structure, that is, some modules may be implemented by the same physical entity, or some modules may be implemented by multiple physical entities, or some components in multiple independent devices may be implemented together.

[0063] The above embodiments are only preferred embodiments for fully illustrating the present invention, and the protection scope of the present invention is not limited thereto. Any equivalent substitution or change made by a person skilled in the art based on the present invention is within the protection scope of the present invention.

Claims

1. A hot migration optimization method based on OpenStack, characterized by: include: Step 1: Call the OpenStack API interface to verify the permission to perform virtual machine live migration. If the verification is successful, assemble a live migration request and send the request to the Conductor component of Nova. The request includes at least the virtual machine's universal unique identifier UUID. Step 2: The Conductor component obtains the specification information of the virtual machine from the database according to the hot migration request. Based on the specification information, a scheduling request for the virtual machine is constructed and sent to the Scheduler component. The scheduling request includes at least the number of CPUs, CPU type, memory capacity, and affinity attributes of the virtual machine. Step 3: The Scheduler component selects the computing nodes that meet the requirements as the target nodes according to the scheduling request, and sends the target node information to the Conductor component. Step 4: The Conductor component reconstructs the hot migration request based on the target node information, and sends the reconstructed hot migration request to the Compute service of the original computing node where the virtual machine is currently located. Step 5: Use the Compute service of the original computing node to determine whether the virtual machine uses a security group driver that supports the iptables firewall, and perform hot migration based on the determination: If the virtual machine currently uses a security group driver that supports the iptables firewall, the Compute service of the target node is notified to create and configure the switch device required by the virtual machine locally on the target node for hot migration; If the virtual machine is not currently using a security group driver that supports the iptables firewall, the original computing node will suspend the hot migration of the virtual machine and reserve time for the target node to configure the switch device. The switch device required for the virtual machine is created through the target node, and the switch device is configured according to the type of the virtual machine network through the Neutron service of the target node, including: configuring the virtual LAN VLAN of the relevant port of the switch device, wherein the network information of the virtual machine network port is obtained through the Neutron service, and the deployment status of the local virtual LAN VLAN on the target node is queried according to the universal unique identifier UUID of the network information. If the virtual LAN VLAN has not been deployed on the target node, a virtual LAN VLAN is allocated to the virtual machine, and the virtual LAN VLAN is recorded in the local cache of the Neutron service. After the configuration is completed, an asynchronous event notification is sent to the Compute service of the original computing node, and the Compute service of the original computing node starts the hot migration operation of the suspended virtual machine according to the notification. Step 6: Monitor the running status of the virtual machine through the Compute service of the original computing node. When the hot migration of the virtual machine is completed normally, call the interface of the Neutron service through the Compute service of the original computing node to update the metadata information of the virtual machine in the database, and clean up the remaining log files and network port information of the virtual machine on the original computing node.

2. According to the OpenStack-based hot migration optimization method of claim 1, it is characterized by: In step 1, the OpenStack API interface is called to verify the permission to perform live migration, including: checking whether the user has the permission to perform virtual machine live migration. If the user does not have the permission to perform virtual machine live migration, the user is considered to be an unauthorized user, and the request of the unauthorized user is immediately stopped. When the API responds, an exception indicating that the request is not authorized is returned. If the user has the permission to perform virtual machine live migration, the verification is successful.

3. A hot migration optimization device based on OpenStack, characterized in that It includes verification module, assembly module, scheduling module, analysis and judgment module and hot migration management module. The verification module calls the OpenStack API interface to verify the permission to perform virtual machine hot migration. If the verification is successful, the assembly module assembles a hot migration request and sends the request to the Conductor component of Nova. The request includes at least the virtual machine's universal unique identifier UUID. The assembly module obtains the specification information of the virtual machine from the database according to the hot migration request through the Conductor component, constructs the scheduling request of the virtual machine based on the specification information and sends it to the Scheduler component. The scheduling request includes at least the number of CPUs, CPU type, memory capacity and affinity attributes of the virtual machine. The scheduling module uses the Scheduler component to filter out the computing nodes that meet the requirements as the target nodes according to the scheduling request, and sends the information of the target nodes to the Conductor component. The assembly module reconstructs the hot migration request through the Conductor component according to the information of the target node, and sends the reconstructed hot migration request to the Compute service of the original computing node where the virtual machine is currently located. The analysis and judgment module determines whether the virtual machine uses the security group driver that supports the iptables firewall through the Compute service of the original computing node. The hot migration management module performs hot migration based on the judgment: If the virtual machine currently uses a security group driver that supports the iptables firewall, the hot migration management module notifies the Compute service of the target node to create and configure the switch device required by the virtual machine locally on the target node to perform hot migration; If the virtual machine is not currently using a security group driver that supports the iptables firewall, the original computing node will suspend the hot migration of the virtual machine through the hot migration management module and reserve time for the target node to configure the switch device. The target node creates the switch device required by the virtual machine through the hot migration management module. The hot migration management module configures the switch device according to the type of the virtual machine network through the Neutron service of the target node, including: configuring the virtual LAN VLAN of the relevant port of the switch device, wherein the network information of the virtual machine network port is obtained through the Neutron service, and the deployment status of the local virtual LAN VLAN on the target node is queried according to the universal unique identifier UUID of the network information. If the virtual LAN VLAN has not been deployed on the target node, a virtual LAN VLAN is allocated to the virtual machine, and the virtual LAN VLAN is recorded in the local cache of the Neutron service. After the configuration is completed, the Neutron service sends an asynchronous event notification to the Compute service of the original computing node, so that the Compute service of the original computing node starts the hot migration operation of the suspended virtual machine according to the notification. The running status of the virtual machine is monitored through the Compute service of the original computing node. When the hot migration of the virtual machine is completed normally, the Compute service of the original computing node calls the interface of the Neutron service to update the metadata information of the virtual machine in the database, and clean up the remaining log files and network port information of the virtual machine on the original computing node.

4. The OpenStack-based hot migration optimization device according to claim 3 is characterized in that The verification module calls the OpenStack API interface to verify the permission to perform live migration, including: checking whether the user has the permission to perform virtual machine live migration. If the user does not have the permission to perform virtual machine live migration, the user is considered an unauthorized user, and the unauthorized user's request is immediately stopped. The API response returns an exception indicating that the request is not authorized. If the user has the permission to perform virtual machine live migration, the verification is successful.

Images