CN108418705B - Virtual network management method and system of virtual machine and container mixed nested architecture - Google Patents
Virtual network management method and system of virtual machine and container mixed nested architecture Download PDFInfo
- Publication number
- CN108418705B CN108418705B CN201810083753.1A CN201810083753A CN108418705B CN 108418705 B CN108418705 B CN 108418705B CN 201810083753 A CN201810083753 A CN 201810083753A CN 108418705 B CN108418705 B CN 108418705B
- Authority
- CN
- China
- Prior art keywords
- virtual
- virtual machine
- container
- network
- switch
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000007726 management method Methods 0.000 title claims abstract description 33
- 238000012423 maintenance Methods 0.000 claims abstract description 6
- 230000006854 communication Effects 0.000 claims description 41
- 238000004891 communication Methods 0.000 claims description 35
- 238000000034 method Methods 0.000 claims description 15
- 238000013508 migration Methods 0.000 claims description 12
- 230000005012 migration Effects 0.000 claims description 12
- 238000002955 isolation Methods 0.000 claims description 10
- 238000005538 encapsulation Methods 0.000 claims description 6
- 230000007175 bidirectional communication Effects 0.000 claims description 4
- 238000012217 deletion Methods 0.000 claims description 4
- 230000037430 deletion Effects 0.000 claims description 4
- 238000012544 monitoring process Methods 0.000 claims description 2
- 238000004806 packaging method and process Methods 0.000 claims 1
- 238000002360 preparation method Methods 0.000 claims 1
- 238000005516 engineering process Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 241000322338 Loeseliastrum Species 0.000 description 1
- 230000008602 contraction Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000004927 fusion Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/04—Network management architectures or arrangements
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention provides a virtual network management method and a virtual network management system of a virtual machine and container mixed nested architecture, which relate to the field of cloud computing and the field of computer networks. In addition, the invention integrates the advantages of a centralized controller and a distributed controller, adopts a two-stage controller structure, sinks partial functions of a control plane into a local controller on a hypervisor server, and the centralized controller is responsible for global data maintenance and a third party operation platform interface and is responsible for flow table maintenance on a local virtual machine switch, thereby effectively reducing the pressure of the global centralized controller and improving the performance of virtual network management.
Description
Technical Field
The invention relates to the field of cloud computing and the field of computer networks, in particular to a virtual network management method of a virtual machine and container mixed nested architecture.
Background
The virtualization based on the virtual machine and the virtualization based on the container are two typical server virtualization technologies in the current cloud computing field, the former has the advantages of better resource isolation, high safety and decoupling of a client operating system and a host operating system, the latter has the advantages of light weight of a virtualization platform, convenience in service deployment and efficient elastic resource expansion, the two virtualization technologies respectively have different application scenes and can coexist in a foreseeable period of time.
For a virtual machine, the most popular virtual network solution at present is a neutron scheme of openstack, a control plane is implemented by a neutron server service on a control node, and virtual network management of a data plane is implemented by an agent on each computing node, for example, ovs bridge (br-int, br-eth, br-tun, etc.) flow table management is implemented by using ovsag, and defects of the method include: 1) centralized virtual network management results in lower performance and is not suitable for rapid elastic expansion and contraction of a container network; 2) virtualization scenarios that do not support virtual machine nesting with containers.
For a container, the currently popular virtual network solutions include Calico, Flannel, Weave, Libnetwork, and the like, but these solutions are only for the container, do not provide network support of a virtual machine, and even do not support a virtualization scene in which the virtual machine and the container are nested.
Because the virtual machine technology and the container technology are two independently developed technical routes, and the implementation modes of the virtual networks are also independently evolved, the mixed deployment of virtualization and containers, particularly the nested deployment scenario, is difficult to satisfy, and therefore a new network management method is required to provide the unified network management capability of the virtual machines and the containers.
Disclosure of Invention
Aiming at the current mixed deployment of a virtual machine and a container, in particular to a nested deployment scene, the invention provides a virtual network management method of a mixed nested architecture of the virtual machine and the container. And unified fusion management of the virtual machine network and the container network is realized.
The invention integrates the advantages of a centralized controller and a distributed controller, adopts a two-stage controller structure, sinks partial functions of a control plane into a local controller on a hypervisor server, and the centralized controller is responsible for global data maintenance and interface with a third party operation platform and is responsible for flow table maintenance on a local virtual machine switch, thereby effectively reducing the pressure of the global centralized controller and improving the performance of virtual network management.
The specific operation steps are as follows:
1) introducing a local network controller (LC) in the server;
2) the virtual machine and the container on the server are both connected to an internal virtual switch (virtual switch-L0);
3) for a nested scenario in which a container runs on a virtual machine, a container network card is connected to a virtual switch (virtual switch-L1) in the virtual machine;
4) the LC acquires necessary global information, such as basic information of virtual machines and containers of each tenant and physical distribution thereof, from a Unified Network Controller (UNC);
5) when a virtual machine or a container is created, the LC issues a flow table to virtual switch-L0 according to the basic information of the local virtual machine or the container, the access channel of the local virtual machine or the container is opened, and tenants are isolated by the vlan;
6) when a virtual machine or a container is deleted, the LC deletes the flow table related to the virtual machine on the virtual switch-L0;
7) when the virtual machine or the container is migrated, the LC deletes the flow table related to the virtual machine on virtual switch-L0 on the host before migration, and the LC of the target host re-issues the related flow table after migration is completed;
8) for a nested scene that a container runs in a virtual machine, when the container is created, deleted and migrated in the virtual machine, an LC of a host machine issues or deletes a corresponding flow table to virtual switch-L0, and a virtual switch-L1 in the virtual machine is in a common two-layer switching mode;
9) when the virtual machines or containers are communicated across nodes, virtual switch-L0 encapsulates the tenant networks into corresponding formats according to the types of the tenant networks and sends the tenant networks out, and if the vlan-type networks are encapsulated into vlan messages, and the vxlan-type networks are encapsulated into vxlan messages;
10) if the tenant network is of a vlan type, vlan configuration of a physical network is needed firstly;
11) and if the tenant network is of a vxlan type, the vxlan full-connection tunnel between the servers is established by the UNC.
Because the UNC itself is not responsible for the virtualization management work of the virtual machine and the container, the UNC needs to interact with a third-party cloud management platform, take over the virtual network management service, and monitor events such as creation, deletion, migration and the like of the virtual machine and the container.
When a virtual machine is created, the UNC notifies the LC on the hypervisor server where the virtual machine is located of the relevant information of the virtual machine, and the basic information and the distribution situation of other relevant virtual machines and containers of the current tenant network, and the LC issues a flow table to the local virtual switch-L0, and opens up the communication channel from the virtual machine to other virtual machines or containers in the tenant network. In addition, the information and the distribution condition of the virtual machine need to be notified to LCs on hypervisor servers where other virtual machines or containers are located in the network of the tenant, the LCs issue flow tables to their local virtual switch-L0, and the communication channel of the virtual machines to the newly-built virtual machine is opened, so that the bidirectional communication channel between the newly-built virtual machine and other virtual machines or containers in the network of the tenant is established.
When a virtual machine is deleted, the UNC notifies the LCs on the hypervisor server where all virtual machines or containers in the tenant network are located of the information related to the virtual machine, and the LCs delete the flow table related to the virtual machine on the local virtual switch-L0.
However, when the virtual machine is migrated, the UNC notifies the relevant location information before the virtual machine is migrated to LCs on hypervisor servers where all virtual machines or containers in the tenant network are located, the LCs delete the flow table on the local virtual switch-L0 related to the virtual machine, and simultaneously notify the location information after the virtual machine is migrated to LCs on the target hypervisor server after the migration and LCs on hypervisor servers where other virtual machines and containers in the tenant network are located, and the LCs add the flow table related to the virtual machine to the respective local virtual switch-L0.
The creating, deleting, and migrating processes of the container are substantially similar to those of the virtual machine, and are not described herein again, and a nested virtualization scenario in which the container runs in the virtual machine is described below.
When a nested container is created, a virtual machine needs to be newly created, the creation process is as described above, after the virtual machine is created, a container (created by a container management platform, such as kubernets) is created inside the virtual machine, the UNC monitors a container creation event, notifies information related to the container and information of other containers and virtual machines of a current tenant network to an LC on a hypervisor server where the virtual machine is located, and the LC issues a flow table to a local virtual switch-L0 of the local virtual switch, and gets through the container to communication channels of other virtual machines or containers in the tenant network. In addition, the information and distribution condition of the container need to be notified to LCs on hypervisor servers where other virtual machines or containers are located in the tenant network, the LCs issue flow tables to their local virtual switch-L0, and open the communication channels from the virtual machines to the newly-built virtual machine, so that the bidirectional communication channels between the newly-built virtual machine and other virtual machines or containers in the tenant network are established.
The container deletion and migration in the nested virtualization scenario in which the container runs in the virtual machine are substantially consistent with the flow in the non-nested environment, and details are not repeated here.
The communication process between virtual machines or containers in a tenant is also divided into a plurality of scenes, and the scenes specifically include the following steps:
1) communication between containers within a virtual machine. Because the containers in the virtual machines belong to the same tenant, the two conditions can be divided into two conditions, one is that two communication parties are positioned in the same subnet, the two communication parties can directly communicate through virtual switch-L1, the other is that the two communication parties are positioned in different subnets (the two communication parties cannot directly communicate between the different subnets and need to pass through a gateway), the message needs to be sent to the gateway through virtual switch-L0, the gateway changes the mac address of the message destination into the mac address of the network card of the target container, and then the message is sent back to the virtual switch-L0, and then the message is sent to the virtual switch-L1 through the virtual switch-L0 and finally sent to the target container.
2) Communication between a container within a virtual machine and a virtual machine or container on a hypervisor server. Similar to 1), the method is divided into two cases of the same subnet and different subnets, if a source and a destination belong to the same subnet, the communication can be directly established by forwarding through related flow tables on virtual switch-L0, if the source and the destination belong to different subnets, a message is firstly sent to a gateway through virtual switch-L0, the gateway changes the destination mac into the mac of a target virtual machine or container and then sends the mac back to the virtual switch-L0, and then the virtual switch-L0 forwards the mac to a specific virtual machine or container according to the flow tables.
3) And communicating between the virtual machines, between the virtual machines and the containers and between the containers on the hypervisor server. The communication process is similar to 2), and is not described in detail.
4) Communication is performed across nodes. The essential process of cross-node communication is the same as that of non-cross-node communication, the biggest difference is that when the communication is not performed, communication is directly established between a source and a destination through a local virtual machine network, extra encapsulation (such as vlan and vxlan encapsulation) is not needed, when the node communication is performed, no matter whether the source and the destination are located in the same subnet, the communication process can be established through extra encapsulation, and other processes are basically consistent.
The invention also provides a virtual network management system of the virtual machine and container mixed nested architecture, which mainly comprises a centralized controller and a distributed controller.
The centralized controller is responsible for maintaining global information, interacting with a third-party cloud management platform to acquire related information and distribution conditions of the virtual machines, the containers and the like, and monitoring related events of the virtual machines and the containers, such as creation, deletion, migration and the like.
The distributed controller (or local controller) is responsible for obtaining relevant information from the centralized controller and maintaining forwarding flow tables related to the local virtual machines or containers.
The virtualization server is internally connected by two levels of virtual machine switches to form internal virtual network connection, the L0-level virtual switch-L0 is in a flow table forwarding mode and operates on a hypervisor, and the L1-level virtual switch-L1 is in a normal forwarding mode and operates inside a virtual machine.
The tenant isolation of the virtual machine and the container is realized by the virtual switch-L0 of the L0 level virtual switch through vlan isolation on each virtual port, and each container on the virtual switch-L1 of the L1 level switch belongs to the container of the same tenant, so the isolation is not performed.
When the virtual machine or the container is created, the UNC informs LCs on all hypervisor servers in the tenant network of the virtual machine or the container basic information and the distribution position information, and each LC maintains a communication flow table of the newly created virtual machine or the container on the local virtual switch-L0 and other virtual machines and containers in the tenant network.
When the virtual machine or the container is deleted, the UNC notifies the LCs on all hypervisor servers in the tenant network of the information related to the virtual machine or the container, and the LCs delete the flow table related to the virtual machine or the container on the local virtual switch-L0.
When a virtual machine or a container is migrated, the UNC notifies the LCs on all hypervisor servers in the tenant network of the relevant information before the virtual machine or the container is migrated, each LC deletes the flow table on the local virtual switch-L0 relevant to the virtual machine or the container, in addition, the UNC notifies the LCs on all hypervisor servers in the tenant network of the relevant information after the virtual machine or the container is migrated, and each LC maintains the communication flow table between the virtual machine or the container and other virtual machines and containers in the tenant network on the local virtual switch-L0.
The invention has the advantages that
1) The virtual machine and the container are treated in the same way, so that unified network management of the virtual machine and the container can be realized;
2) supporting virtual network management of nested virtualization scenes in which containers run in a virtual machine;
3) the control plane part is arranged on the hypervisor server in a lower layer, and the virtual network management performance can be improved.
Drawings
FIG. 1 is a diagram of a typical scenario for hybrid deployment of virtual machines and containers;
FIG. 2 is a diagram of virtual network connections within a server;
fig. 3 is a unified network management architecture diagram.
Detailed Description
The invention is explained in more detail below:
the mixed deployment of the virtual machine and the container is divided into the following scenes: 1) the virtual machine runs on the physical server; 2) the container runs on a physical server; 3) the container is nested and run in the virtual machine; 4) the virtual machine is nested and run in the container; 5) the virtual machine is nested and run in the virtual machine; 6) the containers run nested in the containers. From the current requirements of cloud computing services and application values, 1 and 2 belong to the most typical application scenarios, and scenario 3 can meet some special application requirements, for example, a container with higher requirements on resource isolation and security can be considered to be deployed in an independent virtual machine, while scenarios 4, 5, and 6 have fewer current actual applications and low application values, and are not considered temporarily, and the unified network management method provided by the invention mainly aims at scenarios 1, 2, and 3, as shown in fig. 1.
The unified network management method provided by the invention comprises the following steps:
12) introducing a local network controller (LC) in the server;
13) the virtual machine and the container on the server are both connected to an internal virtual switch (virtual switch-L0);
14) for a nested scenario in which a container runs on a virtual machine, a container network card is connected to a virtual switch (virtual switch-L1) in the virtual machine;
15) the LC acquires necessary global information, such as basic information of virtual machines and containers of each tenant and physical distribution thereof, from a Unified Network Controller (UNC);
16) when a virtual machine or a container is created, the LC issues a flow table to virtual switch-L0 according to the basic information of the local virtual machine or the container, the access channel of the local virtual machine or the container is opened, and tenants are isolated by the vlan;
17) when a virtual machine or a container is deleted, the LC deletes the flow table related to the virtual machine on the virtual switch-L0;
18) when the virtual machine or the container is migrated, the LC deletes the flow table related to the virtual machine on virtual switch-L0 on the host before migration, and the LC of the target host re-issues the related flow table after migration is completed;
19) for a nested scene that a container runs in a virtual machine, when the container is created, deleted and migrated in the virtual machine, an LC of a host machine issues or deletes a corresponding flow table to virtual switch-L0, and a virtual switch-L1 in the virtual machine is in a common two-layer switching mode;
20) when the virtual machines or containers are communicated across nodes, virtual switch-L0 encapsulates the tenant networks into corresponding formats according to the types of the tenant networks and sends the tenant networks out, and if the vlan-type networks are encapsulated into vlan messages, and the vxlan-type networks are encapsulated into vxlan messages;
21) if the tenant network is of a vlan type, vlan configuration of a physical network is needed firstly;
22) and if the tenant network is of a vxlan type, the vxlan full-connection tunnel between the servers is established by the UNC.
Fig. 2 is a connection relationship of a virtual network inside a server, where a container and a virtual machine on a hypervisor server are both connected to a local virtual switch-L0 through a tap port or a virtual port (e.g. veth), and the virtual switch-L0 operates in a flow table forwarding mode, and flow table rules thereof are issued by a local controller LC. The containers in the virtual machines are connected to a virtual switch-L1 inside the virtual machines through tap port virtual ports (such as veth), the virtual switch-L1 works in a common L2 forwarding mode (because the containers in one virtual machine belong to one tenant, and thus vlan isolation is not needed between the containers in the virtual machine), since the tap of the virtual machine is hooked to virtual switch-L0, thus virtual switch-L0 is in communication with virtual switch-L1, since there may be virtual machines or containers of multiple tenants on the hypervisor server, therefore, the vlan isolation of the virtual machine or container of the tenant needs to be started on the virtual port of the virtual switch-L0, a unique local vlan number is allocated to different tenants, when a virtual machine or a container communicates across physical nodes, the local vlan number in the message needs to be replaced with the vlan number of the actual physical network (vlan encapsulation) or vni of the vxlan (vxlan encapsulation).
Fig. 3 is an overall architecture of a unified virtual network management system, and unlike a conventional virtual network solution (e.g. neutron), the present invention employs a control plane combining centralized and distributed control, in which a global central controller UNC is maintained, the UNC is responsible for maintaining global information of a data center network and basic information of virtual machines and containers (calling related interfaces to obtain from a third-party platform, such as openstack or kubernets, etc.), and furthermore, a lightweight local controller LC is started on each hypervisor server, the LC is responsible for maintaining flow table rules related to local virtual machines and containers on a virtual switch-L0, and the hidden LC needs to obtain sufficient global information from the UNC, such as container and virtual machine basic information and distribution conditions of tenants.
The unified virtual machine network management method provided by the invention treats the virtual machine and the container in the same way and the same way, provides the virtual network management capability of the container and the virtual machine integration, can support the nested virtualization scene of the container running in the virtual machine, and enriches the virtualization application scene.
Claims (8)
1. The virtual network management method of the virtual machine and container mixed nesting architecture integrates the advantages of a centralized controller and a distributed controller, adopts a two-stage controller structure, sinks partial functions of a control plane into a local controller on a hypervisor server, and the centralized controller is responsible for global data maintenance and interface with a third party operation and management platform and is responsible for flow table maintenance on a local virtual machine switch; it is characterized in that the preparation method is characterized in that,
the method mainly comprises the following steps:
1) introducing a local network controller (LC for short) into the server;
2) the virtual machine and the container on the server are both connected to an internal virtual switch (virtual switch-L0);
3) for a nested scenario in which a container runs on a virtual machine, a container network card is connected to a virtual switch (virtual switch-L1) in the virtual machine;
4) the LC acquires global information from the unified network controller;
5) when a virtual machine or a container is created, the LC issues a flow table to virtual switch-L0 according to the basic information of the local virtual machine or the container, the access channel of the local virtual machine or the container is opened, and tenants are isolated by the vlan;
6) when a virtual machine or a container is deleted, the LC deletes the flow table related to the virtual machine on the virtual switch-L0;
7) when the virtual machine or the container is migrated, the LC deletes the flow table related to the virtual machine on virtual switch-L0 on the host before migration, and the LC of the target host re-issues the related flow table after migration is completed;
8) for a nested scene that a container runs in a virtual machine, when the container is created, deleted and migrated in the virtual machine, an LC of a host machine issues or deletes a corresponding flow table to virtual switch-L0, and a virtual switch-L1 in the virtual machine is in a common two-layer switching mode;
9) when the virtual machine or the container is communicated across nodes, the virtual switch-L0 encapsulates the tenant network into a format corresponding to the tenant network according to the type of the tenant network and sends the tenant network out;
10) if the tenant network is of a vlan type, vlan configuration of a physical network is needed firstly;
11) and if the tenant network is of a vxlan type, the vxlan full-connection tunnel between the servers is established by the unified network controller.
2. The method of claim 1,
when a virtual machine is created, a network controller (UNC) informs an LC on a hypervisor server where the virtual machine is located of relevant information of the virtual machine, basic information and distribution conditions of other relevant virtual machines and containers of a current tenant network, and the LC issues a flow table to a local virtual switch-L0 of the LC to open a communication channel of the virtual machine to other virtual machines or containers in the tenant network.
3. The method of claim 2,
the information and the distribution condition of the virtual machine are required to be notified to LCs on hypervisor servers where other virtual machines or containers are located in the network of the tenant, the LCs issue flow tables to the virtual switch-L0 of the local virtual switch, and the communication channel of the virtual machines to the newly-built virtual machine is opened, so that the bidirectional communication channel between the newly-built virtual machine and the other virtual machines or containers in the network of the tenant is established.
4. The method of claim 3,
when a virtual machine is deleted, a network controller (UNC) informs LCs on a hypervisor server where all virtual machines or containers in a tenant network are located of information related to the virtual machine, and the LCs delete a flow table related to the virtual machine on a local virtual switch-L0;
however, when the virtual machine is migrated, the UNC notifies the relevant location information before the virtual machine is migrated to LCs on hypervisor servers where all virtual machines or containers in the tenant network are located, the LCs delete the flow table on the local virtual switch-L0 related to the virtual machine, and simultaneously notify the location information after the virtual machine is migrated to LCs on the target hypervisor server after the migration and LCs on hypervisor servers where other virtual machines and containers in the tenant network are located, and the LCs add the flow table related to the virtual machine to the respective local virtual switch-L0.
5. The method of claim 2,
when a nested container is created, firstly, a virtual machine needs to be newly created, after the virtual machine is created, a container is created inside the virtual machine, the UNC monitors a container creating event, informs the LC on the hypervisor server where the virtual machine is located of information related to the container and information of other containers and virtual machines of the current tenant network, and sends a flow table to a local virtual switch-L0 of the LC, so as to open a communication channel from the container to other virtual machines or containers in the tenant network.
6. The method of claim 5,
the information and the distribution condition of the container also need to be notified to LCs on hypervisor servers where other virtual machines or containers are located in the tenant network, the LCs issue flow tables to the local virtual switch-L0, and get through the virtual machines to the communication channel of the newly-built virtual machine, so that the bidirectional communication channel between the newly-built virtual machine and other virtual machines or containers in the tenant network is established.
7. The method of claim 5,
the communication process between virtual machines or containers in the tenant specifically comprises the following steps:
1) communication between containers within a virtual machine
Because the containers in the virtual machines belong to the same tenant, the two conditions can be divided into two conditions, one is that two communication parties are positioned in the same subnet, the two communication parties can directly communicate through virtual switch-L1, and the other is that the two communication parties are positioned in different subnets, the message needs to be sent to the gateway through virtual switch-L0, the gateway changes the mac address of the message destination into the mac address of the network card of the target container, and then the message is sent back to the virtual switch-L0, and is sent to the virtual switch-L1 through the virtual switch-L0, and finally the message is delivered to the target container;
2) communication between a container within a virtual machine and a virtual machine or container on a hypervisor server
If the source and the destination belong to different subnets, the message is firstly sent to a gateway by a virtual switch-L0, the gateway changes the destination mac into the mac of a target virtual machine or container and then sends the mac back to the virtual switch-L0, and then the virtual switch-L0 forwards the mac to a specific virtual machine or container according to the flow table;
3) communication between virtual machines and hypervisor server, between virtual machines and containers, and between containers and containers
The communication process is the same as 2);
4) cross-node communication
When the cross-node communication is not carried out, the communication is directly established between the source and the destination through a local virtual machine network without additional packaging; when nodes communicate, no matter whether a source and a destination are located in the same subnet, the communication process can be established through extra encapsulation, and other processes are consistent.
8. The virtual network management system of the virtual machine and container mixed nested architecture is characterized in that,
the method mainly comprises the following steps: a centralized controller and a distributed controller;
the centralized controller is responsible for maintaining global information, interacting with a third-party cloud management platform to acquire information and distribution conditions of the virtual machines and the containers, and monitoring related events of the virtual machines and the containers, including creation, deletion and migration;
the distributed controller is responsible for acquiring relevant information from the centralized controller and maintaining a forwarding flow table relevant to the local virtual machine or the container;
the virtualization server is internally connected by two levels of virtual machine switches to form internal virtual network connection, the L0-level virtual switch-L0 is in a flow table forwarding mode and operates on a hypervisor, and the L1-level virtual switch-L1 is in a common forwarding mode and operates inside a virtual machine;
the tenant isolation of the virtual machine and the container is realized by the virtual switch-L0 of the L0 level virtual switch on each virtual port by using vlan isolation, and each container on the virtual switch-L1 of the L1 level switch belongs to the container of the same tenant, so the isolation is not carried out;
when a virtual machine or a container is created, the network controller UNC informs LCs on all hypervisor servers in the tenant network of the virtual machine or the container basic information and the distribution position information, and each LC maintains a communication flow table of the newly-built virtual machine or the container on a local virtual switch-L0 and other virtual machines and containers in the tenant network;
when the virtual machine or the container is deleted, the UNC informs the LCs on all hypervisor servers in the tenant network of the information related to the virtual machine or the container, and each LC deletes a flow table related to the virtual machine or the container on a local virtual switch-L0;
when a virtual machine or a container is migrated, the UNC notifies the LCs on all hypervisor servers in the tenant network of the relevant information before the virtual machine or the container is migrated, each LC deletes the flow table on the local virtual switch-L0 relevant to the virtual machine or the container, in addition, the UNC notifies the LCs on all hypervisor servers in the tenant network of the relevant information after the virtual machine or the container is migrated, and each LC maintains the communication flow table between the virtual machine or the container and other virtual machines and containers in the tenant network on the local virtual switch-L0.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810083753.1A CN108418705B (en) | 2018-01-29 | 2018-01-29 | Virtual network management method and system of virtual machine and container mixed nested architecture |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810083753.1A CN108418705B (en) | 2018-01-29 | 2018-01-29 | Virtual network management method and system of virtual machine and container mixed nested architecture |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108418705A CN108418705A (en) | 2018-08-17 |
| CN108418705B true CN108418705B (en) | 2021-01-08 |
Family
ID=63126581
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810083753.1A Active CN108418705B (en) | 2018-01-29 | 2018-01-29 | Virtual network management method and system of virtual machine and container mixed nested architecture |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108418705B (en) |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109450768B (en) * | 2018-11-01 | 2021-06-01 | 中国联合网络通信集团有限公司 | Method for interconnecting containers and system for interconnecting containers |
| CN110730133B (en) * | 2019-10-21 | 2021-11-12 | 北京百度网讯科技有限公司 | Route notification method and system |
| CN110838954B (en) * | 2019-11-07 | 2021-03-30 | 中国人民解放军国防科技大学 | Lightweight large-scale autonomous network protocol function test method |
| CN113114552A (en) * | 2020-01-13 | 2021-07-13 | 上海云轴信息科技有限公司 | Method and equipment for providing network for virtual machine and container in cloud platform |
| CN111522624B (en) * | 2020-04-17 | 2023-10-20 | 成都安恒信息技术有限公司 | Message forwarding performance elastic expansion system and expansion method based on virtualization technology |
| CN112035216B (en) * | 2020-09-01 | 2023-02-21 | 浪潮云信息技术股份公司 | Communication method for Kubernetes cluster network and OpenStack network |
| CN112398688B (en) * | 2020-11-13 | 2022-06-03 | 广东省华南技术转移中心有限公司 | Container network configuration method, container network system, and storage medium |
| CN113472563B (en) * | 2021-05-13 | 2023-12-26 | 新华三大数据技术有限公司 | Network configuration issuing method and device |
| CN113472848A (en) * | 2021-05-31 | 2021-10-01 | 济南浪潮数据技术有限公司 | Network fusion method and device of virtual machine and container and related equipment |
| CN113612688B (en) * | 2021-07-14 | 2023-03-24 | 曙光信息产业(北京)有限公司 | Distributed software defined network control system and construction method thereof |
| CN114363021B (en) * | 2021-12-22 | 2023-11-03 | 绿盟科技集团股份有限公司 | Network target range system, virtual network implementation method and device of network target range system |
| CN115426259A (en) * | 2022-08-29 | 2022-12-02 | 浪潮电子信息产业股份有限公司 | Network access control method, device, equipment and storage medium |
| CN116820686B (en) * | 2023-08-29 | 2024-01-09 | 苏州浪潮智能科技有限公司 | Physical machine deployment method, virtual machine and container unified monitoring method and device |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104518935A (en) * | 2013-09-27 | 2015-04-15 | 华为技术有限公司 | Method for realizing virtual network communication, device, and system |
| CN105763512A (en) * | 2014-12-17 | 2016-07-13 | 杭州华三通信技术有限公司 | SDN virtual network communication method and device |
| WO2016174597A1 (en) * | 2015-04-27 | 2016-11-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Service based intelligent packet-in mechanism for openflow switches |
| CN106712988A (en) * | 2015-08-25 | 2017-05-24 | 新华三技术有限公司 | Virtual network management method and device |
| CN106936777A (en) * | 2015-12-29 | 2017-07-07 | 中移(苏州)软件技术有限公司 | Cloud computing distributed network implementation method based on OpenFlow, system |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9378066B2 (en) * | 2008-02-25 | 2016-06-28 | Sap Se | Dynamic resizing of applications running on virtual machines |
| US10432450B2 (en) * | 2016-06-30 | 2019-10-01 | Microsoft Technology Licensing, Llc. | Data plane API in a distributed computing network |
-
2018
- 2018-01-29 CN CN201810083753.1A patent/CN108418705B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104518935A (en) * | 2013-09-27 | 2015-04-15 | 华为技术有限公司 | Method for realizing virtual network communication, device, and system |
| CN105763512A (en) * | 2014-12-17 | 2016-07-13 | 杭州华三通信技术有限公司 | SDN virtual network communication method and device |
| WO2016174597A1 (en) * | 2015-04-27 | 2016-11-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Service based intelligent packet-in mechanism for openflow switches |
| CN106712988A (en) * | 2015-08-25 | 2017-05-24 | 新华三技术有限公司 | Virtual network management method and device |
| CN106936777A (en) * | 2015-12-29 | 2017-07-07 | 中移(苏州)软件技术有限公司 | Cloud computing distributed network implementation method based on OpenFlow, system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108418705A (en) | 2018-08-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108418705B (en) | Virtual network management method and system of virtual machine and container mixed nested architecture | |
| CN102457439B (en) | Virtual switching system and method of cloud computing system | |
| CN105376303B (en) | Docker implementation system and communication method thereof | |
| CN109743415B (en) | Public cloud network elastic IP implementation method and system | |
| EP3386157B1 (en) | Packet transmission method, device and system | |
| US9331872B2 (en) | Implementing PVLANs in a large-scale distributed virtual switch | |
| RU2595540C9 (en) | Chassis controllers for converting universal flows | |
| CN105471744B (en) | A kind of virtual machine migration method and device | |
| CN105099779B (en) | Multi-tenant cloud platform framework | |
| CN107977255B (en) | Apparatus and method for separating tenant-specific data | |
| EP3300298B1 (en) | Method and apparatus for switching vnf | |
| CN102843286B (en) | Implementation method, and system of virtual routers | |
| CN105429938B (en) | Resource allocation method and device | |
| CN105227454B (en) | Virtual flow-line system and method | |
| CN112398687B (en) | Configuration method of cloud computing network, cloud computing network system and storage medium | |
| US9344360B2 (en) | Technique for managing an allocation of a VLAN | |
| CN106953848B (en) | Software defined network implementation method based on ForCES | |
| CN112600903B (en) | Elastic virtual network card migration method | |
| CN108574613B (en) | Two-layer intercommunication method and device for SDN data center | |
| CN104699522B (en) | A kind of dynamic migration of virtual machine method | |
| CN110635999A (en) | Cloud computing platform network control method based on router virtualization technology | |
| CN110572288A (en) | Data exchange method based on trusted container | |
| WO2022017099A1 (en) | Communication method, cp device, and nat device | |
| CN112583655B (en) | Data transmission method and device, electronic equipment and readable storage medium | |
| CN111786843B (en) | Traffic acquisition method and device, network equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB03 | Change of inventor or designer information | ||
| CB03 | Change of inventor or designer information |
Inventor after: Qi Guangpeng Inventor after: Hu Zhangfeng Inventor before: Hu Zhangfeng |
|
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20201221 Address after: 250100 No. 1036 Tidal Road, Jinan High-tech Zone, Shandong Province, S01 Building, Tidal Science Park Applicant after: Inspur cloud Information Technology Co., Ltd Address before: Floor S06, Inspur Science Park, No. 1036, Inspur Road, hi tech Zone, Jinan City, Shandong Province Applicant before: SHANDONG HUIMAO ELECTRONIC PORT Co.,Ltd. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |