CN109120494B - Method for accessing physical machine in cloud computing system - Google Patents

Abstract

The present invention provides a method for connecting physical machines in a cloud computing system, including creating a virtual network with several nodes configured in a virtual cluster, and connecting all nodes to a first switch, and connecting at least one physical machine in the physical cluster to Access to the second switch that communicates with the first switch; all physical machines in the physical cluster do not distinguish between functional nodes, and the cloud platform dynamically assigns the configuration parameters of the physical machines to be accessed and the VLAN ID assigned by the virtual network Configure the port corresponding to the physical network card of the physical machine to be accessed on the second switch, and define at least one node in the virtual cluster as a computing node. Through this method, the security and smoothness of the physical machine access to the cloud computing system are improved, traffic aggregation at the physical cluster end is avoided, public network IP resources are saved, and the data access efficiency between the virtual machine and the physical machine is improved. Security and compatibility with physical machines.

Description

Method for accessing physical machine in cloud computing system

technical field

The invention relates to the technical field of cloud computing, in particular to a method for accessing a physical machine in a cloud computing system.

Background technique

In a cloud computing environment, programs, applications, databases, etc. run on physical servers (ie, physical machines, PMs). A user (guest) logs in to a virtual machine (VM), and accesses the physical server on which the above program, application or database is deployed through the network. The virtual network function is provided between multiple virtual machines through software-defined network (SND) technology to realize VLAN, VXLAN, GRE or GENEVE between multiple virtual machines or between containers (Docker) or between virtual machines and containers. type of network communication.

As the number of virtual machines continues to increase, higher requirements are placed on the scale of a physical cluster composed of multiple physical machines. In order to cope with the user's access requirements for virtual machines and the improvement of computing power, it is necessary to deploy more physical machines or physical servers in the physical cluster. In this scenario, a programmable physical switch must be deployed on the front end of the physical cluster. As shown in FIG. 1 , due to the different communication instructions adopted by various physical machine manufacturers, there is a defect of poor compatibility of physical machines when deploying physical machines (usually adding physical machines) in a physical cluster. At the same time, in this prior art, as a part of computing nodes, storage nodes, or network nodes in the resource pool, the physical cluster can only rely on the administrator to convert the network protocol between the physical machine and the virtual network, resulting in The flexibility of physical machine deployment is not good.

More importantly, when the physical machine communicates with the virtual machine, an external network IP needs to be assigned to each physical machine. When the number of physical machines is very large, it is obvious that a large number of external network IPs need to be allocated, resulting in a waste of external network IP resources. In addition, there is a bottleneck of the upper limit of VLAN IDs, and the maximum number is only 4096. Therefore, when more physical machines are connected, it is impossible to allocate VLAN IDs for each physical machine.

At the same time, the applicant also found that in the cloud platform shown in FIG. 1 , one or more physical machines in the physical cluster 10 are usually defined as network node A, computing node B, storage node C or other functional nodes. However, this deployment method of classifying the functional roles of physical machines in the physical cluster 10 will result in the need to automatically convert network IP addresses between physical machines and virtual machines under the unified management of the cloud platform. This makes it difficult to deploy physical machines to a certain extent, and leads to the poor compatibility of physical machines provided by different hardware manufacturers during the deployment process.

Further, based on the cloud platform shown in FIG. 1 , if multiple physical machines are divided into network node A, computing node B, storage node C or other functional nodes, there will be serious traffic aggregation phenomenon in network node A. Once the network node A is powered off, down, or has a system abnormality, it will cause a fatal impact on the user's access to the virtual machines 401 - 40i in the virtual cluster 400 in the cloud platform. Therefore, the cloud platform architecture shown in Figure 1 cannot be effectively deployed in a public cloud environment, and there is a defect that physical machines are vulnerable to attacks, resulting in low security.

In view of this, it is necessary to improve the method for connecting a physical machine in a cloud computing system in the prior art to solve the above problems.

Contents of the invention

The purpose of the present invention is to disclose a method for accessing a physical machine in a cloud computing system, so as to improve the security and smoothness of the physical machine accessing the cloud computing system, prevent traffic aggregation at the physical cluster end, and save public network IP resources, improve the data access efficiency and security between virtual machines and physical machines, and improve the compatibility of physical machines provided by different manufacturers for access.

To achieve the above object, the present invention provides a method for accessing a physical machine in a cloud computing system, including:

Several nodes configured in the virtual cluster create a virtual network, and all nodes are connected to a first switch, and at least one physical machine in the physical cluster is connected to a second switch that communicates with the first switch;

Wherein, all the physical machines in the physical cluster do not distinguish between functional nodes, and the cloud platform dynamically configures the configuration parameters of the physical machines to be accessed and the VLAN ID allocated by the virtual network to the physical nodes to be accessed. The port corresponding to the physical network card to which the machine belongs is on the second switch, and at least one node in the virtual cluster is defined as a computing node.

As a further improvement of the present invention, the configuration parameters include: the MAC address information of the physical machine to be accessed, the port information corresponding to the physical network card of the physical machine to be accessed to access the second switch, and the physical network card to be accessed. machine permissions.

As a further improvement of the present invention, one or more of a firewall, a Layer 2 switch or a Layer 3 switch is arranged between the first switch and the second switch.

As a further improvement of the present invention, the virtual network is a hybrid virtual network composed of one of VXLAN virtual network, GRE virtual network, VLAN virtual network, and GENEVE virtual network, or any two virtual networks.

As a further improvement of the present invention, the virtual cluster is isolated from the first switch based on VXLAN virtual network, GRE virtual network, VLAN virtual network or GENEVE virtual network, and the physical cluster is isolated from the second switch based on VLAN .

As a further improvement of the present invention, the working mode of the port connecting the physical network card to the second switch is Access mode, so as to automatically add or remove the Vlan Tag.

As a further improvement of the present invention, at least one node in the virtual cluster is defined as a computing node, and the working mode between the computing node and the port connected to the first switch is trunk mode.

As a further improvement of the present invention, the physical machine is selected from a bare metal server with a physical network card, a server for deploying applications, a desktop computer or a mobile communication device.

As a further improvement of the present invention, the functional nodes of all physical machines in the physical cluster include: physical storage nodes with storage functions, physical computing nodes with computing functions, and physical network nodes with data forwarding functions.

As a further improvement of the present invention, the cloud platform dynamically configures the VLAN ID assigned by the virtual network to the physical network card to which the physical machine to be accessed belongs. After the port corresponding to the second switch, it also includes: all nodes in the virtual cluster In the step of configuring the VNI mapping relationship between the VLAN ID and the virtual network, the node is configured as a virtual machine or a container.

As a further improvement of the present invention, the two nodes in the virtual cluster are both defined as computing nodes, and the two computing nodes respectively pass through the first switches configured with each other to convert different types of virtual networks, and to The data packets forwarded by the physical network cards of the physical machines corresponding to the two computing nodes respond.

As a further improvement of the present invention, nodes in the virtual cluster process data packets returned from computing nodes to physical machines based on openvswitch flow table rules;

The nodes are configured with br-int, br-tun, and br-phy, and process tunnel network data packets through br-tun, process physical machine network data packets through br-phy, and process virtual machines and traffic classification through br-int. The above virtual machine is connected to br-int, br-int is connected to br-phy through a virtual network cable, br-int is connected to br-tun through a virtual network cable, and br-phy and br-tun are not directly connected.

Compared with prior art, the beneficial effect of the present invention is:

Through a method for accessing physical machines in a cloud computing system disclosed by the present invention, the security and smoothness of physical machines accessing the cloud computing system are significantly improved; at the same time, since all physical machines in the physical cluster do not distinguish Functional nodes, so it can effectively avoid traffic aggregation phenomenon at the physical cluster end; finally, the present invention also saves public network IP resources, improves data access efficiency, security and physical machine access efficiency between virtual machines and physical machines compatibility.

Description of drawings

Fig. 1 is a topological structure diagram of a cloud computing system in the prior art;

Fig. 2 is the topological structure diagram of the cloud computing system formed in the first embodiment based on the method for accessing the physical machine in the cloud computing system shown in the present invention, wherein, the physical machine in Fig. 2 is selected from bare metal server;

Fig. 3 is the schematic diagram when Node_1 in the virtual cluster communicates with the physical machine in the physical cluster;

FIG. 4 is a schematic diagram of the virtual machine VM1 in the node Node_1 in the virtual cluster converting different types of virtual networks;

5 is a schematic diagram of the process of network communication based on ARP when a physical machine accesses a virtual machine in a virtual cluster;

Figure 6 is a schematic diagram of when Node_1 in the virtual cluster is abnormal and Node_2 is used to replace Node_1 as a computing node and communicate with a physical machine in the physical cluster, where the physical machine in Figure 6 is selected from bare metal server;

Fig. 7 shows the maximum bandwidth between the virtual machine and the physical machine in the cloud computing system in the prior art shown in Fig. 1 and in the cloud computing system established by the present invention in the same network cross-node and cross-network cross-node scenarios Schematic diagram of the comparison of the transmission rate;

FIG. 8 is a topological structure diagram of a cloud computing system formed in a first modified embodiment based on the method for accessing a physical machine in a cloud computing system shown in the present invention;

Fig. 9 is a topological structure diagram of a cloud computing system formed in a second modified embodiment based on the method for accessing a physical machine in a cloud computing system shown in the present invention, wherein the physical machine in Fig. 9 is selected from bare metal server.

Detailed ways

The present invention will be described in detail below in conjunction with the implementations shown in the drawings, but it should be noted that these implementations are not limitations of the present invention, and those of ordinary skill in the art based on the functions, methods, or structural changes made by these implementations Equivalent transformations or substitutions all fall within the protection scope of the present invention.

The technical terms used in the specific manner of this specification should be interpreted differently in different scenarios, for example, the term "host" is a host that runs programs or applications in the virtual cluster 400 or responds to requests initiated by users. At the same time, in this application, the term "connection" can refer to a computer topology connection, an electrical connection, or a one-way data transmission and/or two-way data transmission based on a message or a data link. .

Embodiment one:

As shown in FIG. 1, the physical nodes in the physical cluster 10 are divided into network nodes and ordinary nodes. The physical nodes are all connected to the second switch 300 (ie, the bare metal switch), and the first switch (not shown, refer to FIG. 2 The first switch 200) is connected to one or more virtual machines in the virtual cluster 400. In FIG. 1, only one virtual machine is shown for simplified representation.

In the prior art, it is necessary to classify bare machines (that is, physical machines). In FIG. 1 , multiple bare metal machines (that is, physical machines) are divided into network node A, computing node B, and storage node C for simplified representation. The traffic of computing node B and storage node C needs to converge to network node A to communicate with resources of different network types. The network type here indicates the network type supported by the cloud platform. The bare metal network type is VLAN. If the virtual network where the VM in the cloud When the network devices communicate, the traffic must be converged to the network node A, and then the network node A is encapsulated by VXLAN and then reaches the host machine of the virtual cluster 400 (equivalent to the virtual machine shown in FIG. 1 ).

This kind of cloud platform formed by the existing technology will not only increase the complexity of the architecture, but also need to converge the traffic of ordinary nodes (namely computing node B and storage node C) to network node A, and also need to integrate bare metal network node A and virtual machine The establishment of VXLAN tunnels on the host machine greatly increases the management cost, and there are many unstable factors. In particular, when network node A fails and goes down, the traffic of ordinary nodes (ie computing node B and storage node C) cannot converge to network node A, resulting in the inability of the bare metal to communicate with the virtual machines in the virtual cluster 400 .

Therefore, this architecture requires that at least one bare metal machine (that is, a physical machine) must be used as the network node A, resulting in consumption of additional physical resources. Therefore, the specific implementation part of the description of the present application focuses on the targeted improvement of the technical problems existing in the prior art disclosed in FIG. 1 .

As shown in FIG. 2, the virtual cluster 400 in this application may be a distributed architecture of the virtual cluster 400 (that is, Content Management System, CMS). The virtual cluster 400 includes n nodes such as Node_1 , Node_2 . . . Node_n. These n nodes can be configured as virtual machines or as containers (Docker). The n nodes are all connected to the first switch 200 . From the perspective of system architecture, the role of the first switch 200 is that one or more physical machines in the virtual cluster 400 and the physical cluster 10 (that is, the physical machine 10a, the physical machine 10b...the physical machine 10i) pass through the second switch 300 communicate with each other. That is, the ports configured by the physical machine 10a, the physical machine 10b...the physical machine 10i and the second switch 300 are connected to the virtual cluster 400 of the cloud computing system. Specifically, the operating systems installed on n nodes such as Node_1, Node_2...Node_n are Linux operating systems.

Specifically, in this embodiment, any type of device 100 with one-way data broadcast or two-way data transmission can be configured or set between the first switch 200 and the second switch 300, and the device 100 can be a firewall 50 (refer to 3 and 6), one or more of a Layer 2 switch (not shown) or a Layer 3 switch (not shown). Meanwhile, when a firewall 50 and a Layer 2 switch or a Layer 3 switch are configured or set between the first switch 200 and the second switch 300 , a direct connection method can be used to connect the first switch 200 and the second switch 300 .

Specifically, as shown in FIG. 3, a method for accessing a physical machine in a cloud computing system disclosed in this embodiment includes:

Several nodes configured in the virtual cluster 400 create a virtual network, and all nodes are connected to the first switch 200, and at least one physical machine in the physical cluster 10 (ie, the physical machine 10a, the physical machine 10b...the physical machine 10i) Both access the second switch 300 that communicates with the first switch 200 . All physical machines in the physical cluster 10 (that is, physical machine 10a, physical machine 10b...physical machine 10i) do not distinguish between functional nodes, but are assigned by the cloud platform to the configuration parameters of the physical machines to be accessed and the virtual network The VLAN ID is dynamically configured to the port corresponding to the physical network card of the physical machine to be accessed on the second switch 300, so as to define at least one node in the virtual cluster 400 as a computing node. There may be one computing node, or two or more computing nodes; wherein, the operation of dynamically configuring the VLAN ID to the port corresponding to the second switch 300 is performed by the SDN controller.

After the virtual network distributes the VLAN ID, the VLAN ID is stored in the database; wherein, the database is configured in the cloud platform, for example, the database can be deployed to a virtual machine or container formed by node node1_1～node Node_n in Figure 2, Open network communication through virtual network. At the same time, since the virtual machine or container itself supports HA or fault migration, the probability of database failure is reduced; or the database is deployed on a physical machine, and the network communication is opened up through the physical network to which the physical machine belongs to better improve the performance and performance of the database. stability.

Further, in this embodiment, it can also include creating a virtual network in the cloud platform and assigning a VLAN ID to the virtual network, storing the VLAN ID in a database; wherein, the database includes: Oracle database, DB2 database, Postgre SQL Database, Microsoft SQL Server database, Microsoft Access database or MySQL database, and preferably MySQL database. Therefore, when creating a virtual network card in the virtual network, the port of the second switch 300 connected to the physical machine can be configured according to the VLAN ID corresponding to the created virtual network. In this embodiment, through this access method, the physical machine can obtain the virtual IP address of the created virtual network, thereby effectively reducing the waste of public network IP resources.

At the same time, in this embodiment, the configuration parameters include: the MAC address information of the physical machine to be accessed, the port information corresponding to the physical network card of the physical machine to be accessed to access the second switch 300, and the The permissions of the physical machine.

The virtual cluster 400 can configure the parameters provided during the creation of the physical machine 10a, physical machine 10b....physical machine 10i, such as the MAC address and IP address, into the internal DHCP service, so that the physical machine is automatically deployed or connected to the physical cluster 10. Get an IP. The IP refers to the IP address of a certain physical machine in the physical cluster 10 (that is, the IP address formed by the bare metal server 10a in FIG. 9 , 10.10.100.100).

The DHCP service is implemented in the cloud platform using DHCP-AGENT, and the DHCP-AGENT is used to manage the dhcp ports corresponding to all virtual networks in the cloud platform to provide DHCP services. DHCP-AGENT runs on one or two fixed nodes (non-virtual machine hosts) in the cloud platform, uses namespace to realize network resource isolation, uses veth device to connect namespace to br-int virtual switch, and at the same time, in namespace Start the dnsmasq process to provide DHCP services, so that the DHCP request initiated by the physical machine can enter the namespace where the DHCP process is located through the br-int virtual switch, and the assigned IP address can be obtained correctly.

In this embodiment, when deploying or accessing a physical machine in the cloud computing system, a virtual network card in the virtual network corresponding to the physical machine will be created, and at the same time, the SDN controller will configure the VLAN of the physical machine generated by the virtual cluster 400 to the second switch 300 port to establish a physical path between the physical machine to be deployed or accessed and a node in the virtual cluster 400 .

As shown in FIG. 7, in the cloud computing system formed by the method disclosed in the present invention, in the same network cross-node and cross-network cross-node scenarios, the virtual machine (that is, each Node in FIG. 2) and the physical machine The transmission rates of the maximum bandwidth are 8.87Gbit/s and 8.28Gbit/s respectively, compared to the transmission rates of the maximum bandwidth between the virtual machine and the physical machine in the prior art are 8.45Gbit/s and 7.51Gbit/s respectively In other words, in the cloud computing system established by the present invention, in the same network (the same type of virtual network) cross-node scenario, and in the cross-network (different type of virtual network) cross-node scenario, the virtual machine and physical The communication capability between machines is better than the communication capability between nodes inside the virtual cluster 400.

The functional nodes of all physical machines in the physical cluster 10 include: physical storage nodes with storage functions, physical computing nodes with computing functions, and physical network nodes with data forwarding functions. Therefore, in this embodiment, the conversion of the virtual network type is completed in one or more nodes in the virtual cluster 400, so the first switch 200 and/or the second switch 300 are not required to perform conversion processing, thereby greatly improving The switching pressure of the first switch 200 and/or the second switch 300 is relieved. The node (Node) can be configured as a virtual machine (VM) or a container (Docker). In this embodiment, we take a node (Node) configured as a virtual machine (VM) as an example for demonstration.

Meanwhile, in this embodiment, the physical machine is selected from a bare metal server with a physical network card, a server for deploying applications, a desktop computer (such as a PC) or a mobile communication device (such as a mobile phone, a tablet computer). In this embodiment, we take a physical machine as a bare metal server (Bare Metal) as an example for demonstration.

A bare metal server is a collection of CPU, RAM, VirtIO-NIC, VirtIO-Blk, and external devices. It supports cloud disks, VPC networks, hot-swappable storage/network devices, and multiple elastic physical network cards. X86, ARM, Power and other CPUs have good compatibility. Therefore, when the physical cluster 10 in the cloud computing system needs to be expanded, the bare metal server becomes a more preferred solution.

In this embodiment, the virtual network is one of VXLAN virtual network, GRE virtual network, VLAN virtual network, and GENEVE virtual network, or a hybrid virtual network composed of any two virtual networks. The virtual cluster 400 and the first switch 200 are isolated based on a VXLAN virtual network, GRE virtual network, VLAN virtual network or GENEVE virtual network. In this embodiment, the virtual cluster 400 and the first switch 200 are based on a VXLAN virtual network to connect. The isolation between the physical cluster 10 and the second switch 300 is based on VLAN. The working mode of the port connecting the physical network card to the second switch 300 is Access mode, so as to automatically add or remove the Vlan Tag. Meanwhile, a node in the virtual cluster 400 is defined as a computing node.

Referring to FIG. 2 or FIG. 8, n nodes such as Node_1, Node_2...Node_n can be individually defined as a computing node. At the same time, specifically as shown in FIG. 6, in this embodiment, we use Node_1 as the only computing node, and the working mode between the computing node and the port connected to the first switch 200 is trunk mode.

At the same time, in this embodiment, after the cloud platform dynamically configures the VLAN ID assigned by the virtual network to the port of the switch corresponding to the physical network card of the physical machine to be accessed, it also includes: configuring in all nodes of the virtual cluster 400 Steps for VNI mapping relationship between VLAN ID and virtual network. Specifically, in this embodiment, the physical machines in the physical cluster 10 are configured as bare metal servers, that is, bare metal servers 10a, bare metal servers 10b....bare metal servers 10i.

Specifically, in this embodiment, the specific implementation of dynamically configuring the VLAN ID assigned by the virtual network to the port of the switch corresponding to the physical network card to which the physical machine to be accessed belongs can be performed by the global control of the first switch 200 and the second switch 200. The SDN controller of the switch 300 is implemented. The SDN controller can run on any node (or container) in the virtual cluster 400 or any physical machine in the physical cluster 10 interconnected with the virtual cluster 400.

Inside the nodes of the cloud computing system, when implementing virtual network type conversion, it can be filtered according to the source MAC address of the physical machine to be connected, such as the bare metal server, and only the bare metal server 10a whose MAC address has been entered on the cloud platform , BMS 10b... BMS 10i corresponding data packets are allowed to pass, otherwise they will be discarded. Example rules:

The code for the first rule is as follows:

br-phy in_port=2, dl_vlan=2,

dl_dst=60:da:83:3d:45:05,actions=mod_vlan_vid:1270,NORMAL

The code for the second rule is as follows:

br-int in_port=11, dl_vlan=1270,

dl_src=60:da:83:3d:45:05,actions=mod_vlan_vid:2,NORMAL

Compared with the technical route of implementing virtual network type conversion through a physical switch in the prior art, it is implemented by using openvswitch flow table rules in this embodiment.

Among them, the above-mentioned first rule means: for the data packets going out from the physical machine of the cloud platform, the destination MAC address is the physical network card of the physical machine and the VLAN will be set to 1270.

The above-mentioned second rule means: for the VLAN is 1270 and the source MAC address is the physical machine to be connected, an internal VLAN tag will be set to ensure that the network devices in the virtual network 400 in the same cloud platform can perform bidirectional or single to the communication.

At the same time, the method disclosed in this embodiment can satisfy the virtual network type conversion of any cloud platform, and the physical machine or the physical machine to be connected always uses the same VLAN type. There is no overhead cost of virtual network type conversion, which reduces the load and traffic pressure of the second switch 300, and at the same time does not increase the load of the physical cluster 10, especially on a physical machine or computing device in the physical cluster 10. Traffic aggregation.

Since various types of virtual networks inside the cloud platform are implemented based on VLANs, different tunneling technologies (Tunnel) are used to transmit data between multiple physical nodes, and when the data packets reach the physical machine, they are converted into In this application, the data packet sent by the physical machine is directly connected to the physical cluster 10 of the cloud platform, which is equivalent to VLAN and the same type of data packet communication of the VLAN, so that the physical machine connected to the cloud computing system It has the technical advantages of higher flexibility and higher performance in the scenario.

Meanwhile, as shown in FIG. 6 , in this embodiment, the nodes in the virtual cluster 400 process the data packets returned from the computing nodes to the physical machines based on the rules of the openvswitch flow table. Nodes are configured with br-int, br-tun and br-phy, and process tunnel network data packets through br-tun, process physical machine network data packets through br-phy, and process virtual machines and traffic classification through br-int. The computer is connected to br-int, and br-int and br-phy are connected through a virtual network cable, that is, connected through Patch-port1 and Patch-port2 in Figure 6, and br-int and br-tun are connected through a virtual network cable. br-tun and br-phy are not connected.

Specifically, the applicant uses a virtual machine VM1 (which is located in Node-1) in the cloud platform to access the physical machine 101 as an example to introduce the network communication path. Here, it is assumed to use PING to access, and the specific code is as follows:

arp, in_port=2, dl_vlan=1, arp_tpa=169.255.128.11

actions=mod_vlan_vid:1814,NORMAL.

First, the virtual machine VM1 sends an ARP broadcast packet to obtain the MAC address corresponding to the IP (10.10.100.100) of the physical machine 101, and the data packet first reaches br-int through the virtual network card of the virtual machine VM, and br-int is matched according to the rules of the internal flow table If the destination IP address is found to belong to the physical machine 101, the data packet will be sent to br-phy; the internal VLAN of the data packet corresponding to the virtual machine VM1 will be converted into the VLAN corresponding to the physical machine 101 in br-phy. At this time, since the physical path has been established when the virtual network card is created, the data packet can successfully reach the physical network card to which the physical machine 101 belongs. The physical network card to which the physical machine 101 belongs returns an ARP REPLY data packet. The virtual machine VM1 starts to send ICMP data packets, process and send ARP data packet types. So far, the virtual machine VM1 has successfully accessed the physical machine 101 .

As shown in FIG. 5 , in the implementation manner, the network communication path is introduced here by taking the physical machine 10a accessing the virtual machine VM1 in the virtual cluster 400 of the cloud platform as an example. Specifically, in this implementation manner, communication is performed in the ARP manner. For details, please refer to steps S1 to S8 below.

S1. The physical machine 10a sends an ARP broadcast packet to obtain the MAC address of the virtual machine VM1.

S2. The data packet reaches the second switch 300 . Because of the access 10 mode used by the physical network card to which the physical machine 10a belongs. A tag of Vlan 10 is added to the data packet entering the second switch 300 from the physical network card to which the physical machine 10a belongs.

S3. The data packet arrives at the firewall 50, and the firewall 50 is used to filter the data packet, so as to filter illegal or abnormal data packets through firewall rules.

S4. The data packet arrives at the first switch 200 connected to the virtual cluster 400 . Since the computing node (Node_1) in the virtual cluster 400 and the first switch 200 use the trunk mode, and allow Vlan 10 to pass through.

S5. The data packet can normally reach the physical network card (NIC (Baremetal)) of the computing node (ie, Node_1 in FIG. 2 or FIG. 6 ).

S6. Arrive at the br-phy virtual switch.

The br-phy virtual switch in Node_1 as a computing node converts the external Vlan to the internal vlan

in_port=11, dl_vlan=10, actions=mod_vlan_vid:2, NORMAL.

Wherein, in_port represents the entrance, port 11 in in_port=11 represents the physical network card, dl_vlan=10 represents Vlan10; action represents the action that needs to be done for the qualified data packet. mod_vlan_vid means modifying Vlan, that is, changing Vlan10 to local Vlan2; NORMAL means doing broadcast action to send this data packet to all reachable ports. Furthermore, in this embodiment, the broadcast range is limited to ports with the same Vlan tag. That is to say, the data packets of external Vlan=10 are converted into internal Vlan=2.

Then, the data packet is broadcast and sent to the virtual ports of all virtual networks of the same type on all current computing nodes (Node_1).

in_port=2, dl_vlan=2, actions=mod_vlan_vid:10, NORMAL

The above flow table rules are used to process the data packets going out from the computing node (Node_1). Suppose it is an ARP return packet sent by VM1 to the physical machine 10a. It means that the Vlan of internal vlan=2 is changed to external Vlan=10, and the data packet is broadcasted at the same time. In this embodiment, since the physical network card is on the br-phy virtual switch, it is in trunk mode. Therefore, the physical network card NIC (Baremetal) can receive the broadcast data packet and send it to the second switch 300 .

S7. Convert vlan to vxlan. As shown in FIG. 4, in this embodiment, br-tun is a virtual switch for processing tunnel network packets, and br-phy is responsible for sending and receiving one or more nodes in the virtual cluster 400 and one of the physical clusters 10 Or a virtual switch for data packets forwarded between multiple physical machines, br-int is used to process virtual machines (when only one virtual machine is created in a node, it can also be understood as the node, that is, node Node_1～node Node_n ) and virtual switches for traffic classification.

VM1 is connected to the br-int virtual switch. br-tun converts overlay type data packets (such as vxlan) into local vlan; br-phy converts data packets of physical machine 10avlan into local vlan; br-int is the communication between local vlan, and br-tun and br -phy is connected to br-int, that is to say, the incoming data packets from br-tun or br-phy can reach br-int, and all of them are converted into local vlan. Here, there are two paths to access VM1, from br-tun and br-phy respectively, and it is found that the data packets have been converted to local vlan after arriving at br-int, that is to say, no matter what type of virtual network is before Type of virtual network, for VM1, it only needs the same localvlan to communicate; the processing of virtual network type is processed on the respective virtual switch to realize the communication between different network types.

S8. The data packet reaches VM1, thereby completing the entire process of accessing the physical machine 101 by the virtual machine VM1.

Embodiment two:

As shown in FIG. 9 , compared with Embodiment 1, a method for accessing a physical machine in a cloud computing system shown in this embodiment is mainly different in that, in this embodiment, the virtual cluster 400 Both nodes are defined as compute nodes. The two computing nodes respectively pass through the first switches configured with each other (that is, the first switch 200 and the first switch 210 in FIG. The data packet forwarded by the physical network card of the physical machine responds, that is, responds to the data packets forwarded by the physical network card of the physical machine 10 a and the physical network card of the physical machine 10 b in the physical cluster 10 respectively.

Specifically, as shown in FIG. 9 , the nodes Node_1 and Node_2 in the virtual cluster 400 are both defined as computing nodes. The NIC (VXLAN) of the node Node-1 is connected to the first switch 200, and at the same time, a connection is established between the first switch 200 and the NIC (VXLAN) configured on the node Node-2. The first switch 200 establishes a connection with the NIC (Baremetal) of the node Node_1 and the NIC (Baremetal) of the node Node_2.

Nodes Node_1 and Node_2 are physical nodes inside the cloud platform, respectively, and represent host machines on which virtual machines run. In each computing node, br-tun represents the virtual switch that handles tunnel communication; br-phy represents the virtual machine switch that handles physical machine communication; br-int represents the virtual switch that handles virtual machine communication, and at the same time classifies and sends data packets to Different virtual switches are handled. br-int is connected to br-tun and br-phy respectively; patch-port1 and patch-port2 represent the two ends of the virtual network cable, which are used to connect br-int and br-phy (that is, two virtual switches). br-int and br-tun are connected through a virtual network cable, and br-phy and br-tun are not directly connected to prevent network storms in the virtual cluster 400, avoid paralysis of the cloud platform, and further affect the physical cluster 10 pairs of users The response speed and user experience of various access requests initiated.

NIC (VXLAN) and NIC (Baremetal) represent physical network cards that handle vxlan communication and physical machine communication. After the br-int virtual switch classifies the data packets, the data packets enter different virtual switches (for example: br-phy), each Each virtual switch is connected to a physical NIC. When the data packet reaches the br-phy, it will go out from the NIC (Baremetal) to the second switch 300 . Here, the port where the NIC (Baremetal) is connected to the second switch 300 uses a trunk mode to allow multiple vlans to pass through, thereby supporting multiple vlans and vxlans to communicate. Trunk 10-20 in Figure 9 indicates that vlan data packets in the range of vlan 10-vlan20 are allowed to pass through this network card.

As mentioned above, br-int is used to classify and process data packets. VMs are connected to br-int. Each VM corresponds to an internal Tag on the br-int virtual switch for secondary layer network isolation. For example, Tag2 in Figure 9 indicates that the internal Vlan of the VM1 network card is "2", and Tag3 in Figure 9 indicates that the internal Vlan of the VM2 network card is "3". Only ports with the same Tag can communicate, thereby realizing the network isolation function. It should be declared that in this application, the technical term "communication" involved may be one-way communication, that is, a master-slave relationship or a control relationship; at the same time, it may also be a two-way communication.

Physical machines can be distributed in different cabinets, computer rooms, or areas, and connected through one or more layer-2 devices. All physical machines are managed by the bare-metal platform, regardless of the type of physical machine. The data packets of the physical machine are directly sent to the second switch 300 through its configured physical network card without converging to a special device for processing; the physical network card to which the physical machine belongs corresponds to the port of the second switch 300 using access mode for automatic addition and removal vlan tag.

A method for accessing a physical machine in a cloud computing system shown in this embodiment has the same technical features or technical solutions as those contained in Embodiment 1. Please refer to Embodiment 1, and details will not be repeated here.

Embodiment three:

A third specific implementation manner of a method for accessing a physical machine in a cloud computing system according to the present invention is shown in conjunction with FIG. 6 . FIG. 6 is a schematic diagram of when Node_1 in the virtual cluster 400 is abnormal and Node_2 replaces Node_1 to communicate with a physical machine in the physical cluster 10 .

Compared with Embodiment 1 and/or Embodiment 2, the main difference between this embodiment is that in this embodiment, it is assumed that the computing node node_1 is down, as can be seen from Figure 6, only the computing node node_1 is actually affected In the communication between VM1 and the corresponding physical machine, the physical machine can still communicate with other computing nodes, such as the virtual machine (such as VM2) in Node_2.

As shown in FIG. 1, although in the prior art, the second switch 300 connected to the physical machine can be stacked or bonded to solve the single point problem, theoretically speaking, the probability of failure of the second switch 300 is still very high. This problem cannot be solved fundamentally. When the communication flow pressure between the virtual cluster 400 of the cloud platform and the physical machine is very high, the second switch 300 is likely to become a bottleneck, unable to process the data packets on both sides, increasing the probability of failure, causing problems such as delay, packet loss, and communication interruption.

The present invention transfers the conversion task of the virtual network type to one or more virtual machine hosts located in the virtual cluster 400 for processing, that is, one or more nodes in the virtual cluster 400 perform the conversion of the virtual network type, thereby greatly The pressure on the second switch 300 is alleviated, and the probability of failure of the second switch 300 is reduced. The second switch 300 only needs to be used as a common Layer 2 switch. More importantly, the technical solution disclosed in the embodiment can fundamentally The problem of traffic aggregation generated by the physical machines in the physical cluster 10 as computing nodes is avoided, and network congestion and response delays will not be caused due to failure or paralysis of a physical machine used as computing.

A method for accessing a physical machine in a cloud computing system shown in this embodiment has the same technical features or technical solutions as those contained in Embodiment 1 and/or Embodiment 2, please refer to Embodiment 1 and/or As shown in Embodiment 2, details are not repeated here.

Embodiment four:

A third specific implementation manner of a method for accessing a physical machine in a cloud computing system according to the present invention is shown in conjunction with FIG. 8 .

Compared with any one of Embodiments 1 to 3, this embodiment is mainly different in that, in this embodiment, the virtual cluster 400 and the physical cluster 10 are directly connected through the first switch 200 and the second switch 300 , and there is no firewall 50 (shown in FIG. 3 and FIG. 6 ) or a layer-2 switch (not shown) or a layer-3 switch (not shown) as shown in the first embodiment.

For the technical features that are the same in this embodiment as in any one of Embodiments 1 to 3, please refer to the above, and details will not be repeated here.

In the several embodiments provided in this application, it should be understood that the disclosed system, device and method can be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of the modules or units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be Incorporation may either be integrated into another system, or some features may be omitted, or not implemented. In another point, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, each unit may exist separately physically, or two or more units may be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

If the integrated unit is realized in the form of a software function unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the essence of the technical solution of the present invention or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium , including several instructions to make a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor (processor) execute all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), magnetic disk or optical disk and other media that can store program codes. .

The series of detailed descriptions listed above are only specific descriptions for feasible implementations of the present invention, and they are not intended to limit the protection scope of the present invention. Any equivalent implementation or implementation that does not depart from the technical spirit of the present invention All changes should be included within the protection scope of the present invention.

It will be apparent to those skilled in the art that the invention is not limited to the details of the above-described exemplary embodiments, but that the invention can be embodied in other specific forms without departing from the spirit or essential characteristics of the invention. Accordingly, the embodiments should be regarded in all points of view as exemplary and not restrictive, the scope of the invention being defined by the appended claims rather than the foregoing description, and it is therefore intended that the scope of the invention be defined by the appended claims rather than by the foregoing description. All changes within the meaning and range of equivalents of the elements are embraced in the present invention. Any reference sign in a claim should not be construed as limiting the claim concerned.

In addition, it should be understood that although this specification is described according to implementation modes, not each implementation mode only includes an independent technical solution, and this description in the specification is only for clarity, and those skilled in the art should take the specification as a whole , the technical solutions in the various embodiments can also be properly combined to form other implementations that can be understood by those skilled in the art.

Claims (12)

1. accessing the method for physical machine in cloud computing system characterized by comprising

Several nodes creation virtual network configured in Virtual Cluster, and all nodes are accessed into the first interchanger, by object At least one physical machine in reason cluster accesses the second switch being in communication with each other with the first interchanger；

Wherein, all physical machines in the physical cluster do not distinguish functional node, and by cloud platform by physics to be accessed The VLAN ID that the configuration parameter and virtual network of machine are distributed dynamically is configured to object belonging to the physical machine to be accessed Port of the network interface card corresponding to second switch is managed, and is calculate node by least one node definition in Virtual Cluster.

2. the method according to claim 1, wherein the configuration parameter includes: the MAC of physical machine to be accessed Physical network card belonging to address information, physical machine to be accessed accesses port information and to be accessed corresponding to second switch The permission of physical machine.

3. the method according to claim 1, wherein being configured between first interchanger and second switch anti- One or more in wall with flues, Layer 2 switch or three-tier switch.

4. the method according to claim 1, wherein the virtual network includes VXLAN virtual network, GRE void Mixed type composed by one of quasi- network, VLAN virtual network, GENEVE virtual network or any two kinds of virtual networks Virtual network.

5. according to the method described in claim 4, it is characterized in that, being based between the Virtual Cluster and the first interchanger VXLAN virtual network, GRE virtual network, VLAN virtual network or GENEVE virtual network are isolated, the physical cluster It is isolated between second switch based on VLAN.

6. according to the method described in claim 4, it is characterized in that, port that the physical network card is connect with second switch Operating mode is Access mode, to add or remove Vlan Tag automatically.

7. method according to any one of claim 1 to 6, which is characterized in that save at least one of Virtual Cluster Point is defined as calculate node, and the operating mode between the calculate node and the port of the first interchanger connection is trunk mode.

8. the method according to claim 1, wherein the physical machine is selected from the bare metal service of tool physical network card Device, the server of application deployment, desktop computer or mobile communication device.

9. the method according to claim 1, wherein the functional section of all physical machines in the physical cluster Point includes: the physical store node for having store function, the physical computing nodes for having computing function and tool data forwarding function Physical network nodes.

10. according to the method described in claim 9, it is characterized in that, the VLAN ID dynamic that cloud platform is distributed virtual network Ground is configured to after port of the physical network card corresponding to second switch belonging to the physical machine to be accessed further include: The step of VNI mapping relations between VLAN ID and virtual network are configured in all nodes of Virtual Cluster, the node is configured For virtual machine or container.

11. the method according to the description of claim 7 is characterized in that two nodes in the Virtual Cluster are defined as Calculate node, between two calculate nodes respectively by the first interchanger for being configured each other to different types of virtual network into Row conversion, and the data packet forwarded to the physical network card of physical machine corresponding to two calculate nodes makes a response.

12. according to claim 1 or method described in 11, which is characterized in that the node in the Virtual Cluster is based on The data packet that openvswitch flow table rule process is returned from calculate node to physical machine；

Node in the Virtual Cluster configures br-int, br-tun and br-phy, and handles tunneled network number by br-tun According to packet, physical machine network packet is handled by br-phy, the data packet and traffic classification of virtual machine, institute are handled by br-int It states virtual machine to connect with br-int, be connected between br-int and br-phy by virtual cable, led between br-int and br-tun Virtual cable connection is crossed, br-phy and br-tun are not directly connected.