System and method for an openstack virtual machine to connect to an external network through a node snat

Abstract

A system for connecting OpenStack virtual machines to the external network via SNAT on their host node includes a virtual router for creating distributed SNAT, a module for limiting north-south traffic flow of virtual machines, and a network interface card (NIC) link status detection module. The method for connecting to the external network includes the following steps: Step S1, creating a router for distributed SNAT; Step S2, creating a module for limiting north-south traffic flow of virtual machines; Step S3, NIC link status detection.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, specifically relating to a system and method for an OpenStack virtual machine to connect to the external network via SNAT on its host node. Background Technology

[0002] Networking has always been one of the core functionalities of OpenStack, and OpenStack provides many technical solutions to meet users' diverse network needs. Most existing data center networking solutions use Vxlan+DVR. Compared with traditional router solutions, this solution does reduce the load on network nodes to a certain extent and improve scalability. However, in scenarios where external network resources are scarce, north-south traffic of virtual machines without bound floating IPs still needs to be concentrated on a single network node for processing through SNAT. This will cause the following problems: high load on a single network node, a single point becoming the bottleneck of the entire network, waste of network resources on other nodes, high probability of network failure, slow SNAT failure migration, the tunnel network between compute nodes and network nodes bearing a large amount of traffic, and a complex network architecture that is difficult to maintain. Summary of the Invention

[0003] To overcome the shortcomings of the prior art, the purpose of this invention is to provide a system and method for OpenStack virtual machines to connect to the external network via SNAT on their host node.

[0004] To achieve the above objectives, the technical solution adopted by the present invention is: a system for OpenStack virtual machines to connect to the external network through SNAT on their respective nodes, including a virtual router for creating distributed SNAT, a module for limiting the north-south traffic flow of virtual machines, and a network interface card link status detection module;

[0005] The router described above is used to create a distributed SNAT type virtual router and deploy SNAT functionality on each computing node.

[0006] The module for limiting the north-south traffic flow of virtual machines is used to restrict the north-south traffic of virtual machines to flow only into the local SNAT and not into network nodes.

[0007] The network interface card link status detection module is used to detect the link status of the physical port bound to the external network on the computing node in real time. When the link status is broken, the traffic of the virtual machine on this node connected to the external network is redirected to other normal nodes through routing, so as to ensure that the north-south traffic of the virtual machine is quickly restored and the network reliability is enhanced.

[0008] A method for an OpenStack virtual machine to connect to the external network via SNAT on its host node includes the following steps:

[0009] Step S1: Create a distributed SNAT router

[0010] This is used to create distributed SNAT-type virtual routers and deploy SNAT functionality on each compute node. A key reason why north-south traffic from virtual machines without bound floating IPs in DVR mode needs to be centralized to network nodes for processing is that these nodes lack SNAT functionality and cannot handle it. Therefore, SNAT functionality is distributed and deployed on each compute node.

[0011] Step S2: Create a module to restrict north-south traffic flow in virtual machines.

[0012] This step is used to restrict the north-south traffic of virtual machines to flow only into the local SNAT and not into network nodes. In DVR mode, virtual machines without a bound floating IP will concentrate north-south traffic to network nodes. Therefore, to solve the problem of existing technology, it is necessary to restrict the virtual machine traffic to flow only into the local SNAT. The concentration of north-south traffic of virtual machines to network nodes is achieved by forwarding it to the other end br-tun endpoint through the tunnel network via the OVS flow table. Therefore, the restriction of the north-south traffic direction of virtual machines must be modified in the br-tun flow table of OVS.

[0013] Step S2 specifically includes the following steps:

[0014] Step S2-1: The neutron-server receives the request to access the virtual router for the internal network and creates the internal network snat_port;

[0015] In step S2-2, when neutron-openvswitch-agent binds snat_port to OVS, it modifies the OVS flow table rules of br-tun and adds a rule to table 22 to discard the ARP response packets of snat_port.

[0016] Step S2-3: Add a rule to table 1 of br-tun's OVS flow table that drops the destination MAC address corresponding to snat_port;

[0017] Step S3, Network Interface Card (NIC) Link Status Detection

[0018] The system monitors the physical port link status of the external network on the compute node in real time. When the link is broken, it redirects the traffic of the virtual machine on this node to other normal nodes through routing, ensuring that the north-south traffic of the virtual machine is quickly restored and enhancing network reliability.

[0019] Step S1 specifically includes the following steps:

[0020] Step S1-1: Modify the routers table in the neutron-server database and add an ex_network field to represent the UUID of the external network corresponding to the virtual router;

[0021] In steps S1-2, when neutron-server creates a virtual machine router, it no longer creates an external gateway, but instead records the UUID and other attributes of the external network in the routers table;

[0022] In steps S1-3, after the neutron-l3-agent of each compute node discovers the newly created virtual route, it obtains the information of the virtual router and sends a request to the neutron-server to create an external gateway for this node. The request must contain at least the UUID of the neutron-l3-agent of this node and the UUID of the external network of the virtual router.

[0023] In steps S1-4, the neutron-server receives a request from the neutron-l3-agent of each compute node to create an external gateway. It uses the UUID of the neutron-l3-agent of the node in the request as the device_id attribute of the port to distinguish the node to which each gw_port belongs. It then sends a request to the core plugin ML2 to create the port and returns the port information to the neutron-l3-agent of each compute node.

[0024] In steps S1-5, after each compute node's neutron-l3-agent receives the return message indicating the creation of its own external gateway, it creates a local SNAT network namespace for each compute node, adds its own external gateway as an external gateway to the local SNAT network namespace, and writes it as the source address of SNAT into the iptables rules of the local SNAT network namespace.

[0025] Step S3 specifically includes the following steps:

[0026] Step S3-1: Query whether the distributed SNAT route on this computing node is connected to the internal network. If yes, proceed to step S3-2; otherwise, continue to step S3-1.

[0027] Step S3-2: Query the physical port name bound to the external network on this compute node;

[0028] Step S3-3: Use system commands (such as ethtool) to query the link status of the above physical ports;

[0029] Step S3-4: If the link status of the above physical port is disconnected, delete the rule in table 22 of the br-tun OVS flow table that discards the ARP response packet of snat_port, and delete the rule in table 1 of the br-tun OVS flow table that discards the destination MAC address corresponding to snat_port, so that the north-south traffic of the virtual machine of this node can reach the network node, and continue to step S3-2.

[0030] Step S3-5: If the link status of the above physical port is normal, check whether there are rules in the br-tun OVS flow table that discard ARP response packets of snat_port and rules that discard packets whose destination MAC address is the MAC address corresponding to snat_port. If they do not exist, add the rules; if they exist, continue to step S3-2.

[0031] The beneficial effects of this invention are:

[0032] Compared with existing technologies, the key inventive points of this invention are: 1) By deploying an SNAT network namespace on each computing node through the virtual router that creates distributed SNAT, virtual machines without bound floating IPs can connect to the external network through the SNAT of their respective nodes, solving the problems of high load, network bottleneck, resource waste, and high failure probability caused by centralized SNAT; 2) By limiting the north-south traffic flow of virtual machines and modifying the OVS flow table rules, traffic from virtual machines to the external network on the tunnel network is discarded, solving the problem of the tunnel network between computing nodes and network nodes bearing a large amount of traffic; 3) The network card link status detection checks the physical port link status bound to the external network of this node in real time. When the network card link is unexpectedly disconnected, the OVS flow table rules are quickly modified so that the traffic from virtual machines to the external network of this node can be automatically redirected to other normal nodes without the need for a complete SNAT migration, solving the problem of slow SNAT failure migration and improving the overall network reliability of the system. Attached Figure Description

[0033] Figure 1 This is a system principle block diagram of the present invention.

[0034] Figure 2 A flowchart illustrating the router process for creating a distributed SNAT in this invention.

[0035] Figure 3(a) is a flowchart of the north-south traffic flow direction of the virtual machine in this invention.

[0036] Figure 3(b) is a flowchart of the network card link status detection process of the present invention.

[0037] Figure 4 This is a diagram showing the network topology and north-south traffic flow of the virtual machine in this invention. Detailed Implementation

[0038] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments.

[0039] A system for OpenStack virtual machines to connect to the external network via SNAT on their host node includes a virtual router for creating distributed SNAT, a module for limiting north-south traffic flow of virtual machines, and a network interface card link status detection module.

[0040] The router described above is used to create a distributed SNAT type virtual router and deploy SNAT functionality on each computing node.

[0041] The module for limiting the north-south traffic flow of virtual machines is used to restrict the north-south traffic of virtual machines to flow only into the local SNAT and not into network nodes.

[0042] The network interface card link status detection module is used to detect the link status of the physical port bound to the external network on the computing node in real time. When the link status is broken, the traffic of the virtual machine on this node connected to the external network is redirected to other normal nodes through routing, so as to ensure that the north-south traffic of the virtual machine is quickly restored and the network reliability is enhanced.

[0043] A method for an OpenStack virtual machine to connect to the external network via SNAT on its host node includes the following steps:

[0044] Step S1: Create a distributed SNAT router

[0045] This is used to create distributed SNAT-type virtual routers and deploy SNAT functionality on each compute node. A key reason why north-south traffic from virtual machines without bound floating IPs in DVR mode needs to be centralized to network nodes for processing is that these nodes lack SNAT functionality and cannot handle it. Therefore, SNAT functionality is distributed and deployed on each compute node.

[0046] Step S1 specifically includes the following steps:

[0047] Step S1-1: Modify the routers table in the neutron-server database and add an ex_network field to represent the UUID of the external network corresponding to the virtual router;

[0048] In steps S1-2, when neutron-server creates a virtual machine router, it no longer creates an external gateway, but instead records the UUID and other attributes of the external network in the routers table;

[0049] In steps S1-3, after the neutron-l3-agent of each compute node discovers the newly created virtual route, it obtains the information of the virtual router and sends a request to the neutron-server to create an external gateway for this node. The request must contain at least the UUID of the neutron-l3-agent of this node and the UUID of the external network of the virtual router.

[0050] In steps S1-4, the neutron-server receives a request from the neutron-l3-agent of each compute node to create an external gateway. It uses the UUID of the neutron-l3-agent of the node in the request as the device_id attribute of the port to distinguish the node to which each gw_port belongs. It then sends a request to the core plugin ML2 to create the port and returns the port information to the neutron-l3-agent of each compute node.

[0051] In steps S1-5, after each compute node's neutron-l3-agent receives the return message indicating the creation of its own external gateway, it creates a local SNAT network namespace for each compute node, adds its own external gateway as an external gateway to the local SNAT network namespace, and writes it as the source address of SNAT into the iptables rules of the local SNAT network namespace.

[0052] Step S2: Create a module to restrict north-south traffic flow in virtual machines.

[0053] This step is used to restrict the north-south traffic of virtual machines to flow only into the local SNAT and not into network nodes. In DVR mode, virtual machines without a bound floating IP will concentrate north-south traffic to network nodes. Therefore, to solve the problem of existing technology, it is necessary to restrict the virtual machine traffic to flow only into the local SNAT. The concentration of north-south traffic of virtual machines to network nodes is achieved by forwarding it to the other end br-tun endpoint through the tunnel network via the OVS flow table. Therefore, the restriction of the north-south traffic direction of virtual machines must be modified in the br-tun flow table of OVS.

[0054] Step S2 specifically includes the following steps:

[0055] Step S2-1: The neutron-server receives the request to access the virtual router for the internal network and creates the internal network snat_port;

[0056] In step S2-2, when neutron-openvswitch-agent binds snat_port to OVS, it modifies the OVS flow table rules of br-tun and adds a rule to table 22 to discard the ARP response packets of snat_port.

[0057] Step S2-3: Add a rule to table 1 of br-tun's OVS flow table that drops the destination MAC address corresponding to snat_port;

[0058] Step S3, Network Interface Card (NIC) Link Status Detection

[0059] Real-time monitoring of the physical port link status bound to the external network on the compute node; when the link status is broken, the traffic of the virtual machine on this node to the external network is redirected to other normal nodes through routing, ensuring that the north-south traffic of the virtual machine is quickly restored and enhancing network reliability;

[0060] Step S3 specifically includes the following steps:

[0061] Step S3-1: Query whether the distributed SNAT route on this computing node is connected to the internal network. If yes, proceed to step S3-2; otherwise, continue to step S3-1.

[0062] Step S3-2: Query the physical port name bound to the external network on this compute node;

[0063] Step S3-3: Use system commands (such as ethtool) to query the link status of the above physical ports;

[0064] Step S3-4: If the link status of the above physical port is disconnected, delete the rule in table 22 of the br-tun OVS flow table that discards the ARP response packet of snat_port, and delete the rule in table 1 of the br-tun OVS flow table that discards the destination MAC address corresponding to snat_port, so that the north-south traffic of the virtual machine of this node can reach the network node, and continue to step S3-2.

[0065] Step S3-5: If the link status of the above physical port is normal, check if there are rules in the br-tun OVS flow table that discard ARP response packets of snat_port and rules that discard packets whose destination MAC address is the MAC address corresponding to snat_port. If not, add the rules.

[0066] If it exists, proceed to step S3-2.

[0067] The technical solution described in this invention provides a method for an OpenStack virtual machine to connect to the external network via SNAT on its host node, with appended details. Figure 4 The diagram illustrates the network topology and north-south traffic flow of virtual machines under the technical solution described in this patent. It should be understood that the diagram is for ease of description only and is not intended to limit this disclosure or its application or use. Techniques, methods, and devices known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and devices should be considered part of the specification. Furthermore, in all examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations.

[0068] like Figure 4 As shown in the figure, multiple (computing + networking) nodes are deployed to complete the technical solution described in this patent. The traffic of virtual machine 1 on (computing + networking) node 1 connecting to the external network, as shown by the dotted line, first passes through QBR bridge 1 to reach the OVS integrated bridge of this node, then enters the router namespace, and then through the internal gateway to enter the SNAT namespace. After the SNAT namespace translates the source address, it is sent out from the external gateway-1 of this node, and then through the BR-EX bridge to the physical network card 1 of this node, completing external communication. Similarly, the traffic of virtual machine 2 on (computing + networking) node 2 connecting to the external network, as shown by the dotted line, first passes through QBR bridge 2 to reach the OVS integrated bridge of this node, then enters the router namespace, and then through the internal gateway to enter the SNAT namespace. After the SNAT namespace translates the source address, it is sent out from the external gateway-2 of this node, and then through the BR-EX bridge to the physical network card 2 of this node, completing external communication. Thus, virtual machine 1 and virtual machine 2 can connect to the external network through the SNAT of their respective nodes.

[0069] Specialized terminology:

[0070] Vxlan (Virtual eXtensible Local Area Network) is a tunneling network technology that can establish Layer 2 Ethernet network tunnels on top of Layer 3 networks, thereby enabling Layer 2 interconnection across geographical regions.

[0071] DVR: Distributed Router, a virtual routing mode officially introduced by OpenStack starting with the Juno release. It primarily distributes virtual routes across compute nodes, allowing north-south traffic from virtual machines bound to floating IPs, as well as east-west traffic from different networks, to be processed on the compute node where the originating virtual machine resides.

[0072] SNAT (Source Address Translation) is used to translate the internal IP address that initiates the access to the external network into a specified IP address when an internal network address accesses the external network. This allows multiple hosts on the internal network to access the external network through a single valid external IP address.

[0073] OVS: Open VSwitch is a high-quality, multi-layer virtual switch (a layer of network layering) designed to enable large-scale network automation that can be scaled programmatically while still supporting standard management interfaces and protocols.

Claims

1. A method for an OpenStack virtual machine to connect to the external network via SNAT on its host node, characterized in that, Includes the following steps: Step S1: Create a distributed SNAT router Used to create distributed SNAT type virtual routers and deploy SNAT functionality on each compute node; a major reason why north-south traffic of virtual machines without bound floating IPs in DVR mode needs to be centralized to network nodes for processing is that the local node does not have SNAT functionality and cannot process it. Deploy the SNAT functionality in a distributed manner on each compute node; Step S1 specifically includes the following steps: Step S1-1: Modify the routers table in the neutron-server database and add an ex_network field to represent the UUID of the external network corresponding to the virtual router; In steps S1-2, when neutron-server creates a virtual machine router, it no longer creates an external gateway, but instead records the UUID and other attributes of the external network in the routers table; In steps S1-3, after the neutron-l3-agent of each compute node discovers the newly created virtual route, it obtains the information of the virtual router and sends a request to the neutron-server to create an external gateway for this node. The request must contain at least the UUID of the neutron-l3-agent of this node and the UUID of the external network of the virtual router. In steps S1-4, the neutron-server receives a request from the neutron-l3-agent of each compute node to create an external gateway. It uses the UUID of the neutron-l3-agent of the node in the request as the device_id attribute of the port to distinguish the node to which each gw_port belongs. It then sends a request to the core plugin ML2 to create the port and returns the port information to the neutron-l3-agent of each compute node. Steps S1-5: After receiving the return message to create the external gateway of the local node, the neutron-l3-agent of each compute node creates a local SNAT network namespace for each compute node, adds its own external gateway as an external gateway to the local SNAT network namespace, and writes it as the source address of SNAT into the iptables rules of the local SNAT network namespace. Step S2: Create a module to restrict north-south traffic flow in virtual machines. This step is used to restrict the north-south traffic of virtual machines to flow only into the local SNAT and not into network nodes. In DVR mode, virtual machines without a bound floating IP will concentrate north-south traffic to network nodes. Therefore, to solve the problem of existing technology, it is necessary to restrict the virtual machine traffic to flow only into the local SNAT. The concentration of north-south traffic of virtual machines to network nodes is achieved by forwarding it to the other end br-tun endpoint through the tunnel network via the OVS flow table. Therefore, the restriction of the north-south traffic direction of virtual machines must be modified in the br-tun flow table of OVS. Step S2 specifically includes the following steps: In step S2-1, the neutron-server receives the request to access the virtual router on the internal network and creates the internal network snat_port; In step S2-2, when neutron-openvswitch-agent binds snat_port to OVS, it modifies the OVS flow table rules of br-tun and adds a rule to table 22 to discard the ARP response packets of snat_port. Step S2-3: Add a rule to table 1 of br-tun's OVS flow table that drops the destination MAC address corresponding to snat_port; Step S3, Network Interface Card (NIC) Link Status Detection Real-time monitoring of the physical port link status bound to the external network on the compute node; when the link status is broken, the traffic of the virtual machine on this node to the external network is redirected to other normal nodes through routing, ensuring that the north-south traffic of the virtual machine is quickly restored and enhancing network reliability; Step S3 specifically includes the following steps: Step S3-1: Query whether the distributed SNAT route on this computing node is connected to the internal network. If yes, proceed to step S3-2; otherwise, continue to step S3-1. Step S3-2: Query the physical port name bound to the external network on this compute node; Step S3-3: Use system commands to query the link status of the aforementioned physical ports; Step S3-4: If the link status of the above physical port is disconnected, delete the rule in table 22 of the br-tun OVS flow table that discards the ARP response packet of snat_port, and delete the rule in table 1 of the br-tun OVS flow table that discards the destination MAC address corresponding to snat_port, so that the north-south traffic of the virtual machine on this node can reach the network node, and continue to step S3-2; Step S3-5: If the link status of the above physical port is normal, check whether there are rules in the br-tun OVS flow table that discard ARP response packets of snat_port and rules that discard packets whose destination MAC address is the MAC address corresponding to snat_port. If they do not exist, add the rules; if they exist, continue to step S3-2.

2. The system for a method of connecting an OpenStack virtual machine to the external network via SNAT on its host node, as described in claim 1, is characterized in that... include: The module for creating distributed SNAT virtual routers is used to create distributed SNAT virtual routers on each compute node and deploy SNAT functionality. The module for limiting the north-south traffic flow of virtual machines is used to configure the flow table rules of virtual switches to restrict the north-south traffic of virtual machines to flow only into the local SNAT of the compute node where the virtual machine is located, and not to the network node. The network interface card link status detection module is used to detect the link status of the physical ports of the external network of the computing node in real time, and dynamically manage the flow table rules of the virtual switch based on the link status, so as to redirect the north-south traffic of the virtual machine of this node to other normal nodes when the link is broken.

Images