WO2017032251A1 - 虚拟网络管理 - Google Patents

虚拟网络管理 Download PDF

Info

Publication number
WO2017032251A1
WO2017032251A1 PCT/CN2016/095687 CN2016095687W WO2017032251A1 WO 2017032251 A1 WO2017032251 A1 WO 2017032251A1 CN 2016095687 W CN2016095687 W CN 2016095687W WO 2017032251 A1 WO2017032251 A1 WO 2017032251A1
Authority
WO
WIPO (PCT)
Prior art keywords
vswitch
information
virtual
sdn controller
virtual network
Prior art date
Application number
PCT/CN2016/095687
Other languages
English (en)
French (fr)
Inventor
崔凯
牟彦
Original Assignee
杭州华三通信技术有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 杭州华三通信技术有限公司 filed Critical 杭州华三通信技术有限公司
Priority to JP2018510364A priority Critical patent/JP6574304B2/ja
Priority to EP16838510.2A priority patent/EP3327994B1/en
Priority to US15/744,704 priority patent/US10572291B2/en
Publication of WO2017032251A1 publication Critical patent/WO2017032251A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • 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/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • 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/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • 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/12—Discovery or management of network topologies
    • 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/12—Discovery or management of network topologies
    • H04L41/122—Discovery or management of network topologies of virtualised topologies, e.g. software-defined networks [SDN] or network function virtualisation [NFV]
    • 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/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/58—Association of routers
    • H04L45/586—Association of routers of virtual routers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/70—Virtual switches
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances

Definitions

  • multiple heterogeneous hypervisors can be utilized to coordinate access to different physical devices and VMs (virtual machines).
  • a virtual switch (vSwitch) configured in the hypervisor provides communication between VMs and between the VM and the external network.
  • These hypervisors and vSwitches can be managed by different hypervisor managers. Since different vVSs managed by the Hypervisor Manager go online in different ways, different Hypervisor Managers are controlled by different SDN (Soft Defined Network) controllers or SDN controller clusters. Different SDN controllers cannot perceive each other's overlay network. Therefore, VMs running on heterogeneous hypervisors may not be able to communicate directly through the Overlay network.
  • SDN Software Defined Network
  • 1 is a schematic diagram of networking of virtual network management
  • FIG. 2 is a flowchart of a virtual network management method according to an example of the present disclosure
  • FIG. 3 is a schematic structural diagram of a virtual network according to an example of the present disclosure.
  • FIG. 4 is a schematic diagram of an interaction process between a virtual switch and an SDN controller according to an example of the present disclosure
  • FIG. 5 is a schematic diagram showing the hardware structure of a virtual network management apparatus according to an example of the present disclosure
  • FIG. 6 is a block diagram of functional modules of a virtual network management logic in accordance with an example of the present disclosure.
  • FIG. 1 is a schematic diagram of a common virtual network management network.
  • a plurality of different architectures of Hypervisors can be utilized to manage and control the VMs to provide various services such as computing services to users.
  • Heterogeneous hypervisors can be managed by different hypervisor managers, such as Hypervisor Manager 1001, which manages Hypervisor 110, and Hypervisor Manager 1002, which manages Hypervisor 120.
  • the forwarding engine related to providing network services is generally installed in the Hypervisor 110 and 120.
  • the forwarding engine may be referred to as a vSwitch (virtual switch).
  • vSwitches come online in different ways in different hypervisors, different SDN controllers may be required to manage heterogeneous hypervisors in data center management.
  • the VMs in each Hypervisor can usually interact through the corresponding vSwitch of the Hypervisor.
  • Each vSwitch can connect to multiple VMs.
  • VM1 under vSwitch1 sends a message to VM2 under vSwitch2
  • Hypervisor 110 and Hypervisor 120 where VM1 and VM2 are located are managed by different SDN controllers 101 and 102, different SDN controllers cannot perceive each other's Overlay. Network, so VM1 and VM2 cannot communicate directly through the Overlay network.
  • One of the solutions may be to use the traditional network for packet forwarding, and the forwarding path is: VM1 ⁇ vSwitch1 ⁇ VTEP Router 10 ⁇ VTEP Router 20 ⁇ vSwitch2 ⁇ VM2, as indicated by the dotted arrow in FIG.
  • VTEP Routers 10 and 20 can be used as gateways.
  • the forwarding path also needs to be configured separately in the SDN controller 101 and the SDN controller 102. Due to the complexity of the forwarding mode, the forwarding efficiency of packets is low. In addition, for data center management, different SDN controllers need to be managed by using different APPs, such as APP 1011 management SDN controller 101 and APP 1012 management SDN controller 102, resulting in data center management. It is more difficult.
  • the virtual network management method and apparatus of the present disclosure can manage different virtual domain topologies of multiple domains by creating different computing domains for the manager managing the heterogeneous hypervisors and managing the domains by using the topology management information. So that the SDN controller can control the heterogeneous hypervisor manager in a unified manner, so that the VMs in the heterogeneous hypervisors can interoperate through the Overlay network. In this way, the forwarding process can be simplified, the forwarding efficiency is improved, and the management difficulty is reduced.
  • heterogeneous hypervisors refer to hypervisors from different vendors that use different methods to virtualize servers.
  • the typical KVM Hypervisors and vCenter Hypervisors are different in virtualization technology, and the user UI and operation steps are different.
  • a hypervisor manager can manage a specific type of hypervisor, and the heterogeneous hypervisor manager provided by different vendors is different in virtualization.
  • the computing domain here can manage the entities of different types of Hypervisor Managers, which support the same way to deploy the topology information parameters to the virtual switches of different types of Hypervisor Managers, thus achieving unified management of heterogeneous hypervisors.
  • FIG. 2 is a flowchart of a virtual network management method in an example of the present invention.
  • the method is applicable to an SDN controller in a virtual network, and the method may include steps 201 to 203.
  • the SDN controller creates a first Domain and a second Domain for the first Hypervisor Manager and the second Hypervisor Manager, respectively.
  • the first hypervisor manager and the second hypervisor manager are heterogeneous, and the first hypervisor manager manages a first virtual machine (VM) and a first virtual switch (vSwitch), the second The Hypervisor Manager manages the second VM and the second vSwitch.
  • the SDN controller when setting up a virtual network, can control different hypervisor managers through different domains, that is, the SDN controller creates the first for the first hypervisor manager and the second hypervisor manager respectively. Domain and second domain.
  • the SDN controller creates topology management information based on the topology of the virtual network, where the topology management information includes first virtual network topology information, second virtual network topology information, first configuration information, and second configuration information.
  • the SDN controller can also create topology management information based on a pre-configured virtual network topology.
  • the topology management information may include a virtual network topology of the first domain and the second domain that participate in packet forwarding.
  • the virtual network topology of the first domain may be referred to as the first virtual network topology information, including the virtual IP address corresponding to the first VM, the uplink port, and the like; the virtuality of the second domain
  • the network topology may be referred to as second virtual network topology information, including a virtual IP address corresponding to the second VM, an uplink port, and the like.
  • the topology management information may also include different vSwitch configuration information that is set in advance for the heterogeneous hypervisor.
  • the configuration information set for the vSwitch managed by the first Hypervisor Manager may be referred to as first configuration information, and may include the name of the first vSwitch, forwarding mode, virtual MAC address, and content such as VXLAN; and management for the second Hypervisor Manager.
  • the configuration information of the vSwitch configuration may be referred to as the second configuration information, and may generally include the name of the second vSwitch, the forwarding mode, the virtual MAC address, and the content of the VXLAN.
  • the creation of the topology management information may also be implemented by a VDS (Virtual Distributed Switch).
  • the first configuration information and the second configuration information in the topology management information are respectively sent to the The first vSwitch and the second vSwitch enable the first vSwitch and the second vSwitch to implement the first VM and the second VM according to the first configuration information and the second configuration information, respectively. Message forwarding.
  • the SDN controller may separately associate the topology management information with the first domain and the second domain, and then deliver the first configuration information and the second configuration information in the topology management information to the first
  • the first vSwitch can guide the packet forwarding on the first VM according to the first configuration information
  • the second vSwitch can guide the packet forwarding on the second VM according to the second configuration information.
  • the topology management information may be sent to the first hypervisor manager and the second hypervisor. Manager.
  • the first hypervisor manager can then send the first configuration information in the received topology management information to the first vSwitch managed by the first hypervisor manager, and the second hypervisor manager can receive the first in the topology management information received.
  • the second configuration information is sent to the second vSwitch managed by itself.
  • the first vSwitch and the second vSwitch are respectively according to the first
  • the configuration information and the second configuration information implement message forwarding between the first VM and the second VM.
  • the SDN controller may control the first vSwitch and the second vSwitch according to the topology management information, so that the first VM and the second VM located in the heterogeneous hypervisors may pass the first vSwitch Communicating with the second vSwitch.
  • the present disclosure can create a different domain for the heterogeneous hypervisor manager, and record the virtual network topology of multiple domains through the topology management information, so that the SDN controller can uniformly control the heterogeneous hypervisor manager, thereby enabling VMs running in heterogeneous hypervisors can communicate with each other through the Overlay network, which simplifies the forwarding process, improves forwarding efficiency, and reduces management difficulty.
  • the SDN controller can know the information of the newly-launched virtual network device based on the feedback information of the vSwitch.
  • the SDN controller can receive the openflow connection request sent by the third vSwitch and the vSwitch online message, for example, increase the openflow message of the switch.
  • the SDN controller can then create a record of the third vSwitch in the first domain corresponding to the first hypervisor manager according to the vSwitch online message.
  • the SDN controller may receive a VM online message sent by the vSwitch corresponding to the third VM, for example, an openflow message of portstatus.
  • the SDN controller may add the record of the third VM to the topology management information according to the VM online message, and the record may include information such as a virtual IP address, an online port, and the like of the third VM. Therefore, the SDN controller can manage the heterogeneous hypervisor manager by using different domains, and manage the virtual network device through the virtual network topology, so that the SDN controller can manage the heterogeneous hypervisor more efficiently.
  • the message when the first VM sends a message to the second VM, the message is first sent to the first vSwitch, and then the first vSwitch can send the message to the SDN controller.
  • the SDN controller After receiving the packet, the SDN controller can parse the source address and the destination address of the packet, and determine that the source virtual device of the packet is the first VM and the target virtual device is the second VM.
  • the SDN controller may determine, according to the virtual network topology information, whether the first VM and the second VM allow interworking. Since the SDN controller of the present disclosure can uniformly manage the heterogeneous first hypervisor manager and the second hypervisor manager, when the first VM managed by the first hypervisor manager and the second VM managed by the second hypervisor manager are configured to When the same Overlay network is used, the first VM and the second VM may be allowed to communicate.
  • the topology management information may generally include information of multiple virtual routers (vRouters), each vRouter may correspond to multiple subnets, and each subnet may include multiple VMs.
  • the SDN controllers need to determine whether the source virtual device and the target virtual device can communicate with each other. Specifically, when processing the packet, the SDN controller needs to search for topology management information to determine whether the first VM and the second VM correspond to the same vRouter. If the first VM and the second VM correspond to the same vRouter, it may be determined that the first VM and the second VM are allowed to communicate; otherwise, they cannot communicate.
  • the SDN controller determines that the first VM and the second VM allow interworking, the virtual IP address corresponding to the second VM and the second VM may be further obtained from the locally managed virtual network topology information.
  • An uplink port on the vSwitch, and the tunnel encapsulation information of the second vSwitch corresponding to the second VM is obtained in the second domain.
  • the SDN controller may create a first flow table according to the foregoing information, where the first flow table may include a virtual IP address, an uplink port, and the tunnel encapsulation information of the second VM.
  • the SDN controller can send the first flow table to the first vSwitch, and the first vSwitch can encapsulate the packet according to the first flow table and forward the packet to the second vSwitch through the Overlay network.
  • the second vSwitch can decapsulate the packet and forward it to the SDN controller.
  • the SDN controller may further search for the online port corresponding to the second VM when the second VM is online on the second vSwitch, and create a second flow table according to the online port and the virtual IP address of the second VM.
  • Send to the second vSwitch, the second vSwitch can be based on the second flow
  • the table forwards the message to the second VM.
  • the present disclosure can simplify the forwarding step across the vSwitch by unified management of the heterogeneous hypervisor, thereby improving forwarding efficiency.
  • the configured virtual network includes a KVM (Kernel-based Virtual Machine) hypervisor manager 31, a vCenter (virtual center) hypervisor manager 32, and a CAS (Cloud Automation System).
  • Hypervisor Manager 33 The KVM Hypervisor Manager 31 manages the vSwitch 1 and its corresponding KVM Hypervisor 310, vSwitch 2, and its corresponding KVM Hypervisor 320, respectively.
  • the vCenter Hypervisor Manager 32 manages vSwitch 3 and its corresponding ESXi Hypervisor 330, vSwitch 4, and its corresponding ESXi Hypervisor 340, respectively.
  • the CAS Hypervisor Manager 33 manages the vSwitch 5 and its corresponding CAS Hypervisor 350, vSwitch 6, and its corresponding CAS Hypervisor 360, respectively.
  • n VMs can be included in each Hypervisor.
  • the data center management platform 300 can manage the SDN controller 3000 through an APP, and the SDN controller 3000 uniformly performs domain management and virtual network topology management on the virtual network device.
  • the so-called Domain Management that is, the SDN controller can create different Domains for different types of Hypervisor Managers, for example, KVM Hypervisor Manager 31 corresponds to KVM type Domain1, vCenter Hypervisor Manager 32 corresponds to vCenter type Domain2, CAS Hypervisor Manager 33 Corresponds to Domain3 of the CAS type.
  • Each domain can manage the virtual network devices managed by the corresponding Hypervisor Manager, and record the tunnel encapsulation information of each vSwitch, such as the tunnel type and virtual IP address.
  • the SDN controller also creates topology management information, which may include n vRouter-network-subnet-VM management architectures.
  • the subnet can represent a subnet, and each subnet can include multiple VMs, and multiple subnets can form a subnet collection network, and the vRouter can virtually connect multiple subnets, corresponding to the same vRouter.
  • VMs can allow interworking.
  • the virtual IP address and online port of each VM can be recorded in the topology management information.
  • the SDN controller can associate the topology management information with all the domains participating in the virtual exchange, and deliver the relevant configuration parameters in the topology management information to the Hypervisor Manager corresponding to each domain.
  • FIG. 4 When the VM 11 running on the KVM Hypervisor 31 is to send a message to the VM 31 running on the vCenter Hypervisor 32, the interaction of the vSwitch 1, the vSwitch 3, and the SDN controller 3000 according to the virtual network management method provided by the present disclosure is shown in FIG. The process can be as shown in Figure 4.
  • the VM 11 sends an ARP (Address Resolution Protocol) request packet to the vSwitch 1 on the KVM Hypervisor 31.
  • the ARP request packet may include the virtual IP address of the VM 11 and the virtual IP address of the VM 31.
  • the vSwitch 1 After receiving the ARP request packet, the vSwitch 1 can send the ARP request packet to the SDN controller 3000 through the openflow protocol.
  • the SDN controller 3000 can determine the vRouter corresponding to the VM 11 and the VM 31 according to the virtual IP addresses of the VM 11 and the VM 31, and determine whether the VM 11 and the VM 31 are allowed to communicate. If VM 31 and VM 11 correspond to the same vRouter, then VM 11 and VM 31 are considered to be interoperable.
  • the MAC address of the gateway corresponding to VM 31 or VM 31 can be used as a response to the received ARP request message. In this example, the MAC address of the VM 31 can be used as the response to the received ARP request packet, and the ARP reply packet carrying the MAC address is sent to the vSwitch 1.
  • the vSwitch 1 After receiving the ARP reply packet, the vSwitch 1 forwards the ARP reply packet to the VM 11.
  • the VM 11 obtains the MAC address of the VM 31 in the ARP reply packet, and creates an IP packet, where the source IP address of the IP packet is the virtual IP address of the VM 11 and the destination IP address is the virtual IP address of the VM 31.
  • the MAC address is the MAC address of the VM 11, and the destination MAC address is the MAC address of the VM 31. Then, the VM 11 can send the created IP packet to the vSwitch 1.
  • vSwitch 1 After receiving the IP packet, vSwitch 1 can send the IP packet to the SDN through the openflow protocol. Controller 3000.
  • the SDN controller 3000 can determine the vRouter corresponding to the VM 11 and the VM 31 according to the virtual IP addresses of the VM 11 and the VM 31, and determine whether the VM 11 and the VM 31 are allowed to communicate. If the VM 31 and the VM 11 correspond to the same vRouter, the VM 11 and the VM 31 are considered to be interoperable, so that the first flow table can be delivered to the vSwitch 1.
  • the first flow table may include: the source IP address is the virtual IP address of the VM 11, the destination IP address is the virtual IP address of the VM 31, the source MAC address is the MAC address of the VM 11, and the destination MAC address is the MAC address of the VM 31. , as well as tunnel encapsulation information. In the tunnel encapsulation information, the encapsulation type is VXLAN, and may include the virtual IP address of vSwitch 1 and the virtual IP address of vSwitch 3.
  • vSwitch 1 After receiving the first flow table, vSwitch 1 encapsulates the IP packet in VXLAN according to the first flow table and sends it to vSwitch 3.
  • the vSwitch 3 When receiving the VXLAN packet sent by the vSwitch 1, the vSwitch 3 performs the VXLAN decapsulation of the VXLAN packet to obtain the IP packet, and then sends the IP packet to the SDN controller 3000.
  • the SDN controller 3000 searches the online port of the vSwitch 3 corresponding to the destination VM 31 according to the destination IP address in the IP packet, and sends a second flow table to the vSwitch 3.
  • the second flow table may include: the source IP address is the virtual IP address of the VM 11, the destination IP address is the virtual IP address of the VM 31, the source MAC address is the MAC address of the VM 11, and the destination MAC address is the MAC address of the VM 31. And the online port corresponding to VM 31.
  • the vSwitch 3 After receiving the second flow table sent by the SDN controller 3000, the vSwitch 3 can forward the IP packet to the VM 31 according to the second flow table, so that the VM 11 and the VM 31 exchange visits.
  • the present disclosure can uniformly manage the heterogeneous hypervisors, so that the VMs in the heterogeneous hypervisors can communicate with each other through the Overlay network, thereby simplifying the forwarding process, improving the forwarding efficiency, and reducing the management difficulty.
  • the present disclosure further provides a virtual network management apparatus, which may be implemented by software, or may be implemented by hardware or a combination of hardware and software.
  • a virtual network management apparatus which may be implemented by software, or may be implemented by hardware or a combination of hardware and software.
  • the virtual network management device of the present disclosure can be used as a logical device, and can be processed by reading a corresponding machine readable program instruction in a storage medium by a CPU on the SDN controller.
  • FIG. 5 is a schematic block diagram of a hardware structure of a virtual network management apparatus in an example of the present disclosure.
  • the virtual network management device can be an SDN controller in a virtual network.
  • the virtual network management device may include a processor 501 such as a central processing unit (CPU), an internal bus 502, a network interface 503, and a non-transitory storage medium 504.
  • the processor 501, the network interface 503, and the non-transitory storage medium 504 can communicate with each other through the internal bus 502.
  • the non-transitory storage medium 504 can store machine executable instructions corresponding to the virtual network management logic 600.
  • the functions of the various modules of the virtual control management device can be implemented by the processor 501 reading and executing the machine executable instructions corresponding to the virtual network management logic 600 stored in the non-transitory storage medium 504.
  • Figure 6 illustrates a block diagram of various functional modules of a virtual network management logic.
  • the virtual network management logic 600 may include a first creation unit 601, a second creation unit 602, an information delivery unit 603, a forwarding control unit 604, a first uplink unit 605, and a second. Online unit 606.
  • the first creating unit 601 can create a first domain and a second domain respectively for the first hypervisor manager and the second hypervisor manager in the virtual network.
  • the first hypervisor manager and the second hypervisor manager are heterogeneous, the first hypervisor manager manages a first VM and a first vSwitch, and the second hypervisor manager manages a second VM and a second vSwitch .
  • the second creating unit 602 may create topology management information based on a topology of the virtual network, where the topology management information includes first virtual network topology information for the first computing domain, and second virtual domain for the second computing domain Network topology information, first configuration information for the first vSwitch, and second configuration information for the second vSwitch;
  • the information delivery unit 603 can associate the topology management information with the first domain and the second domain respectively, and can set the first configuration information and the second configuration information in the topology management information. Distributing to the first vSwitch and the second vSwitch respectively, so that the first vSwitch and the second vSwitch respectively implement the first VM and the second according to the first configuration information and the second configuration information Packet forwarding between VMs.
  • the device 600 further includes: a first uplink unit 605, configured to receive a vSwitch online message sent by the third vSwitch when the third vSwitch is online on the first hypervisor manager; The message creates a record of the third vSwitch in the first domain corresponding to the first hypervisor manager.
  • the device 600 further includes: a second uplink unit 606, configured to receive a VM online message sent by the vSwitch corresponding to the third VM when the third VM is online on the first Hypervisor Manager; The VM online message adds the record of the third VM to the topology management information.
  • a second uplink unit 606 configured to receive a VM online message sent by the vSwitch corresponding to the third VM when the third VM is online on the first Hypervisor Manager; The VM online message adds the record of the third VM to the topology management information.
  • the device 600 further includes a forwarding control unit 604, where the forwarding control unit 604 can include:
  • the first receiving sub-unit 6041 is configured to receive a packet that the source virtual device that is sent by the first vSwitch is the first VM, and the target virtual device is the second VM.
  • the intercommunication judging subunit 6042 is configured to determine, according to the first virtual network topology information and the second virtual network topology information, whether the first VM and the second VM allow interworking;
  • a first creating sub-unit 6043 configured to create a first flow table and send the first flow table to the first vSwitch when the first VM and the second VM are allowed to communicate, so that the first vSwitch sends the packet To the second vSwitch;
  • the second receiving subunit 6044 is configured to receive the packet sent by the second vSwitch.
  • a second creating sub-unit 6045 configured to create a second flow table according to the packet received by the second receiving sub-unit 6044, and send the second flow table to the second vSwitch to enable the second The vSwitch sends the message to the second VM according to the second flow table.
  • the interworking judging subunit 6042 can search for the first virtual network topology.
  • the information and the second virtual network topology information determine whether the first VM and the second VM correspond to the same vRouter. If the first VM and the second VM correspond to the same virtual router, the first VM and the second VM are allowed to communicate.
  • the first creating sub-unit 6043 may obtain, from the second virtual network topology information, a virtual IP address corresponding to the second VM and an online port of the second VM on the second vSwitch. Obtaining tunnel encapsulation information of the second vSwitch corresponding to the second VM from the second configuration information; creating a first flow table, where the first flow table includes a virtual IP address, an uplink port, and the tunnel of the second VM Package information.
  • the second creating subunit 6045 may create a second flow table, where the second flow table includes an online port of the second VM.
  • the present disclosure can create a different domain for the heterogeneous hypervisor manager and manage the virtual network topology of multiple domains through the topology management information, so that the SDN controller can uniformly manage the heterogeneous hypervisor manager.
  • VMs in heterogeneous hypervisors can communicate with each other through the Overlay network, which simplifies the forwarding process, improves forwarding efficiency, and reduces management difficulty.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

在示例中，提供一种虚拟网络管理方法。根据该方法，可针对异构的第一Hypervisor管理器和第二Hypervisor管理器分别创建第一计算域和第二计算域，所述第一管理器管理第一虚拟机(VM)和第一虚拟交换机(vSwitch)，所述第二管理器管理第二VM和第二vSwitch；基于所述虚拟网络的拓扑创建拓扑管理信息，所述拓扑管理信息包括针对所述第一计算域的第一虚拟网络拓扑信息、针对所述第二计算域的第二虚拟网络拓扑信息、针对所述第一vSwitch的第一配置信息和针对所述第二vSwitch的第二配置信息；在将所述拓扑管理信息与所述第一计算域和第二计算域分别进行关联后，将所述拓扑管理信息中的第一配置信息和第二配置信息分别下发到所述第一vSwitch和所述第二vSwitch，使得所述第一vSwitch和所述第二vSwitch分别根据所述第一配置信息和所述第二配置信息实现所述第一VM与所述第二VM之间的报文转发。

Description

虚拟网络管理 背景技术
在数据中心的网络虚拟化技术中，可以利用多个异构的超级管理器(Hypervisor)来协调访问不同的物理设备以及VM(Virtual Machine，虚拟机)。配置在Hypervisor中的虚拟交换机(Virtual Switch，vSwitch)提供了VM之间以及VM与外部网络之间的通讯能力。而这些Hypervisors以及vSwitches可由不同的Hypervisor管理器进行管理。由于不同的Hypervisor管理器管理的vSwitch会通过不同的方式上线，不同的Hypervisor管理器会由不同的SDN(Soft Defined Network，软件定义网络)控制器或SDN控制器集群来控制。而不同的SDN控制器不能相互感知对方的叠加(Overlay)网络，因此异构Hypervisors上运行的VMs之间可能无法通过Overlay网络直接通信。
附图说明
图1是虚拟网络管理的组网示意图；
图2是本公开一示例的一种虚拟网络管理方法的流程图；
图3是本公开一示例的虚拟网络的架构示意图；
图4是本公开一示例的虚拟交换机与SDN控制器的交互流程的示意图；
图5是本公开一示例的虚拟网络管理装置的硬件结构示意图；
图6是本公开一示例的一种虚拟网络管理逻辑的功能模块的框图。
具体实施方式
请参考图1，是常用的虚拟网络管理的组网示意图。如图1所示，在数据 中心管理中可以利用多个不同架构的Hypervisors来管理和控制VM，以向用户提供诸如计算服务的各种服务。而异构的Hypervisors可由不同的Hypervisor管理器管理，例如Hypervisor管理器1001管理Hypervisor 110，Hypervisor管理器1002管理Hypervisor 120。而提供网络服务相关的转发引擎一般会安装在Hypervisor110、120之中，该转发引擎可称为vSwitch(virtual Switch)。由于vSwitch在不同的Hypervisor中会通过不同的方式上线，所以在数据中心管理中可能需要不同的SDN控制器对异构的Hypervisor进行管理。每个Hypervisor中的VM通常可以通过该Hypervisor对应的vSwitch进行交互，每个vSwitch可以连接多个VM。
然而，当vSwitch1下的VM1向vSwitch2下的VM2发送报文时，由于VM1和VM2所在的Hypervisor 110和Hypervisor 120由不同的SDN控制器101和102进行管理，不同SDN控制器不能相互感知对方的Overlay网络，因此VM1与VM2无法通过Overlay网络直接通信。解决方法之一可以是利用传统网络进行报文转发，其转发路径为：VM1→vSwitch1→VTEP Router 10→VTEP Router 20→vSwitch2→VM2，如图1中的虚线箭头所示。这里的VTEP Router 10和20可用作网关。该转发路径还需要在SDN控制器101与SDN控制器102中分别进行配置。由于上述转发方式较为复杂，可导致报文的转发效率较低。另外，对于数据中心管理来讲，不同的SDN控制器需使用不同的APP(Application，应用)来被管理，例如APP 1011管理SDN控制器101、APP 1012管理SDN控制器102，导致数据中心的管理难度较大。
为了解决上述问题，本公开的虚拟网络管理方法及装置可以通过为对异构的Hypervisor进行管理的管理器创建不同的计算域(Domain)，并通过拓扑管理信息来管理多个Domain的虚拟网络拓扑，以使SDN控制器可以统一控制异构的Hypervisor管理器，从而使得异构Hypervisors中的VMs可以通过Overlay网络实现互通。这样，可以简化转发过程，提高转发效率，降低管理难度。
在本文中，异构的Hypervisor指的是不同厂商提供的Hypervisor，其使用不同的方式实现服务器的虚拟化。比如典型的KVM Hypervisors以及vCenter Hypervisors实现虚拟化的技术不同，提供的用户UI以及操作步骤也不同。而一种Hypervisor管理器可以管理一种特定类型的Hypervisor，不同厂商提供的异构的Hypervisor管理器的虚拟化方式不同。这里的计算域可以管理不同类型的Hypervisor管理器的实体，该实体支持把拓扑信息参数通过相同的方式部署到不同类型的Hypervisor管理器的虚拟交换机上，从而实现对异构Hypervisor的统一管理。
请参考图2，是本发明一示例中的一种虚拟网络管理方法的处理流程图，所述方法可应用于虚拟网络中的SDN控制器，所述方法可包括步骤201到203。
在步骤201、所述SDN控制器针对第一Hypervisor管理器和第二Hypervisor管理器分别创建第一Domain和第二Domain。其中，所述第一Hypervisor管理器和所述第二Hypervisor管理器可相互异构，所述第一Hypervisor管理器管理第一虚拟机(VM)和第一虚拟交换机(vSwitch)，所述第二Hypervisor管理器管理第二VM和第二vSwitch。
在本公开可选的示例中，搭建虚拟网络时，SDN控制器可以通过不同的Domain来控制不同的Hypervisor管理器，即SDN控制器为第一Hypervisor管理器和第二Hypervisor管理器分别创建第一Domain和第二Domain。
在步骤202、所述SDN控制器基于虚拟网络的拓扑创建拓扑管理信息，所述拓扑管理信息包括第一虚拟网络拓扑信息、第二虚拟网络拓扑信息、第一配置信息和第二配置信息。
在本示例中，SDN控制器还可以根据预先配置的虚拟网络拓扑创建拓扑管理信息。该拓扑管理信息中可包括参与报文转发的第一Domain和第二Domain的虚拟网络拓扑。例如，第一Domain的虚拟网络拓扑可称为第一虚拟网络拓扑信息，包括第一VM对应的虚拟IP地址以及上线端口等；第二Domain的虚拟 网络拓扑可称为第二虚拟网络拓扑信息，包括第二VM对应的虚拟IP地址以及上线端口等。另外，该拓扑管理信息中还可包括预先为异构Hypervisor设置的不同的vSwitch配置信息。例如，为第一Hypervisor管理器管理的vSwitch设置的配置信息可称为第一配置信息，可包括第一vSwitch的名称、转发模式、虚拟MAC地址以及VXLAN等内容；以及为第二Hypervisor管理器管理的vSwitch设置的配置信息可称为第二配置信息，通常可包括第二vSwitch的名称、转发模式、虚拟MAC地址以及VXLAN等内容。本公开可选的示例中，创建该拓扑管理信息也可以通过VDS(Virtual Distributed Switch，虚拟分布式交换机)实现。
在步骤203、在所述拓扑管理信息与所述第一Domain和第二Domain分别进行关联后，将所述拓扑管理信息中的所述第一配置信息和第二配置信息分别下发到所述第一vSwitch和第二vSwitch，使得所述第一vSwitch和所述第二vSwitch分别根据所述第一配置信息和所述第二配置信息实现所述第一VM与所述第二VM之间的报文转发。
在本示例中，SDN控制器可以将所述拓扑管理信息与所述第一Domain和第二Domain分别进行关联，然后将拓扑管理信息中的第一配置信息和第二配置信息分别下发到第一Domain中的第一Hypervisor管理器管理的第一vSwitch以及第二Domain中的第二Hypervisor管理器管理的第二vSwitch。该第一vSwitch可以根据该第一配置信息指导第一VM上的报文转发，该第二vSwitch可以根据该第二配置信息指导第二VM上的报文转发。
在另一示例中，SDN控制器在将所述拓扑管理信息与所述第一Domain和第二Domain分别进行关联后，可以将所述拓扑管理信息下发到第一Hypervisor管理器和第二Hypervisor管理器。然后第一Hypervisor管理器可以将收到的所述拓扑管理信息中的第一配置信息下发到自身管理的第一vSwitch，第二Hypervisor管理器可以将收到的所述拓扑管理信息中的第二配置信息下发到自身管理的第二vSwitch。所述第一vSwitch和第二vSwitch分别根据所述第一 配置信息和所述第二配置信息实现所述第一VM与所述第二VM之间的报文转发。
因此，SDN控制器可以根据所述拓扑管理信息控制所述第一vSwitch和所述第二vSwitch，以使位于异构Hypervisors的所述第一VM和所述第二VM可以通过所述第一vSwitch和所述第二vSwitch相互通信。
由此可见，本公开可以通过为异构的Hypervisor管理器创建不同的Domain，并通过拓扑管理信息记录多个Domain的虚拟网络拓扑，使SDN控制器可以统一控制异构的Hypervisor管理器，从而使异构Hypervisors中运行的VMs可以通过Overlay网络实现互通，进而可以简化转发过程，提高转发效率，降低管理难度。
虚拟网络搭建完成后，如果有新的vSwitch或者VM上线时，SDN控制器可以根据vSwitch的反馈信息及时获知新上线的虚拟网络设备的信息。
具体的说，当第三vSwitch在第一Hypervisor管理器上上线时，SDN控制器可以接收第三vSwitch发送的openflow连接请求以及vSwitch上线消息，例如增加交换机的openflow消息。之后SDN控制器可以根据所述vSwitch上线消息在第一Hypervisor管理器对应的第一Domain中创建所述第三vSwitch的记录。当第三VM在第一Hypervisor管理器上上线时，SDN控制器可以接收所述第三VM对应的vSwitch发送的VM上线消息，例如portstatus的openflow消息。SDN控制器可以根据该VM上线消息在拓扑管理信息中添加所述第三VM的记录，记录中可包括该第三VM的虚拟IP地址、上线端口等信息。因此SDN控制器可以利用不同的Domain来管理异构的Hypervisor管理器，并通过虚拟网络拓扑实现对虚拟网络设备的管理，从而可以使SDN控制器对异构的Hypervisor的管理更加高效。
在本发明可选的示例中，当第一VM向第二VM发送报文时，该报文首先会上送到第一vSwitch，然后第一vSwitch可以将该报文上送到SDN控制器。 SDN控制器收到该报文后，可以解析报文的源地址和目标地址，确定该报文的源端虚拟设备为第一VM，目标端虚拟设备为第二VM。
SDN控制器可以根据所述虚拟网络拓扑信息判断所述第一VM和第二VM是否允许互通。由于本公开的SDN控制器可以统一管理异构的第一Hypervisor管理器和第二Hypervisor管理器，当第一Hypervisor管理器管理的第一VM和第二Hypervisor管理器管理的第二VM被配置到同一Overlay网络时，可以允许第一VM和第二VM互通。
在本公开优选的示例中，拓扑管理信息中通常可以包括多个虚拟路由器(vRouter)的信息，每个vRouter可以对应多个子网(subnet)，每个subnet可包括多个VM。由于不同的vRouter之间不能互通，SDN控制器在处理报文时，需要判断报文的源端虚拟设备和目标端虚拟设备是否能够互通。具体来讲，SDN控制器在处理报文时，需要查找拓扑管理信息以确定所述第一VM和第二VM是否对应于同一vRouter。若所述第一VM和第二VM对应于同一vRouter，则可以确定所述第一VM和第二VM允许互通；反之，则不能互通。
当SDN控制器确定所述第一VM和第二VM允许互通时，可以进一步从本地管理的虚拟网络拓扑信息中获取所述第二VM对应的虚拟IP地址及所述第二VM在所述第二vSwitch上的上线端口，并且在第二Domain中获取第二VM对应的第二vSwitch的隧道封装信息。之后，SDN控制器可以根据上述信息创建第一流表，所述第一流表可包括所述第二VM的虚拟IP地址、上线端口以及所述隧道封装信息。SDN控制器可将该第一流表下发到第一vSwitch上，第一vSwitch可以根据该第一流表将报文封装后通过Overlay网络转发到第二vSwitch。当第二vSwitch收到封装后的报文后，可以对其解封装，并转发到SDN控制器。SDN控制器可以进一步在自身管理的虚拟网络拓扑信息中查找第二VM在第二vSwitch上上线时对应的上线端口，并根据该上线端口以及第二VM的虚拟IP地址创建第二流表并下发到第二vSwitch，第二vSwitch可以根据该第二流 表将该报文转发到第二VM。
相对于依靠外网的转发路径，本公开可通过对异构的Hypervisor的统一管理来简化跨vSwitch的转发步骤，从而可提高转发效率。
为使本公开的目的、技术方案及优点更加清楚明白，以下基于图3的虚拟网络架构图，对本公开所述方案作进一步地详细说明。
假设配置的虚拟网络中包括KVM(Kernel-based Virtual Machine，基于内核的虚拟机)Hypervisor管理器31、vCenter(virtual Center，虚拟中心)Hypervisor管理器32、CAS(Cloud Automation System，云计算管理平台)Hypervisor管理器33。其中，KVM Hypervisor管理器31中分别管理vSwitch 1及其对应的KVM Hypervisor 310、vSwitch 2及其对应的KVM Hypervisor 320。vCenter Hypervisor管理器32中分别管理vSwitch 3及其对应的ESXi Hypervisor 330、vSwitch 4及其对应的ESXi Hypervisor 340。CAS Hypervisor管理器33中分别管理vSwitch 5及其对应的CAS Hypervisor 350、vSwitch 6及其对应的CAS Hypervisor 360。并且每个Hypervisor中可包括n个VM。
在本示例中，数据中心管理平台300可以通过一个APP对SDN控制器3000进行管理，并由该SDN控制器3000统一对上述虚拟网络设备进行Domain管理和虚拟网络拓扑管理。所谓的Domain管理，即SDN控制器可以为不同类型的Hypervisor管理器创建不同的Domain，例如KVM Hypervisor管理器31对应KVM类型的Domain1、vCenter Hypervisor管理器32对应vCenter类型的Domain2、CAS Hypervisor管理器33对应CAS类型的Domain3。每个Domain可以管理对应的Hypervisor管理器所管理的虚拟网络设备，并记录每个vSwitch的隧道封装信息，如隧道类型、虚拟IP地址等。SDN控制器还会创建拓扑管理信息，所述拓扑管理信息可包括n个vRouter—network—subnet—VM的管理架构。其中，subnet可代表子网，每个子网中可包括多个VM，多个子网可组成子网集合network，而vRouter可以虚拟连接多个子网，对应于同一个vRouter的 VM可以允许互通。拓扑管理信息中可以记录每个VM的虚拟IP地址及上线端口。之后，SDN控制器可以把拓扑管理信息和所有参与虚拟交换的Domain进行关联，并将拓扑管理信息中的相关配置参数下发到每个Domain对应的Hypervisor管理器上。
当图3中，KVM Hypervisor 31上运行的VM 11要向vCenter Hypervisor 32上运行的VM 31发送报文时，根据本公开提供的虚拟网络管理方法，vSwitch 1、vSwitch 3、SDN控制器3000的交互流程可如图4所示。
其中，VM 11向KVM Hypervisor 31上的vSwitch 1发送ARP(Address Resolution Protocol，地址解析协议)请求报文，该ARP请求报文可包括VM 11的虚拟IP地址和VM 31的虚拟IP地址。
vSwitch 1收到该ARP请求报文后，可通过openflow协议将该ARP请求报文上送到SDN控制器3000。
SDN控制器3000收到该ARP请求报文后，可根据VM 11和VM 31的虚拟IP地址确定VM 11和VM 31分别对应的vRouter，并判断VM 11和VM 31是否被允许互通。如果VM 31和VM 11对应于同一vRouter，则认为VM 11和VM 31可以互通。可使用VM 31或VM 31对应的网关的MAC地址作为对所接收到的ARP请求报文的应答。在本示例中可使用VM 31的MAC地址作为对所接收到的ARP请求报文的应答，并把携带该MAC地址的ARP应答报文下发到vSwitch 1。
vSwitch 1收到该ARP应答报文后，把该ARP应答报文转发给VM 11。
VM 11获取ARP应答报文中的VM 31的MAC地址，并创建IP报文，其中该IP报文的源IP地址为VM 11的虚拟IP地址，目的IP地址为VM 31的虚拟IP地址，源MAC地址为VM 11的MAC地址，目的MAC地址为VM 31的MAC地址。然后，VM 11可将所创建的该IP报文发送到vSwitch 1。
vSwitch 1收到该IP报文后，可通过openflow协议将该IP报文上送到SDN 控制器3000。
SDN控制器3000收到该IP报文后，可根据VM 11和VM 31的虚拟IP地址确定VM 11和VM 31分别对应的vRouter，并判断VM 11和VM 31是否被允许互通。如果VM 31和VM 11对应于同一vRouter，则认为VM 11和VM 31可以互通，因此可以向vSwitch 1下发第一流表。在该第一流表中可包括：源IP地址为VM 11的虚拟IP地址，目的IP地址为VM 31的虚拟IP地址，源MAC地址为VM 11的MAC地址，目的MAC地址为VM 31的MAC地址，以及隧道封装信息。在该隧道封装信息中，封装类型为VXLAN，并且可包括vSwitch1的虚拟IP地址和vSwitch3的虚拟IP地址。
vSwitch 1收到该第一流表后，可根据第一流表将该IP报文进行VXLAN封装并送往vSwitch 3。
vSwitch 3收到vSwitch 1发送的VXLAN报文时，对该VXLAN报文进行VXLAN解封装以获取其中的IP报文，之后将该IP报文上送SDN控制器3000。
SDN控制器3000根据IP报文中的目的IP地址查找目的VM31对应的vSwitch 3的上线端口，向vSwitch 3下发第二流表。该第二流表中可包括：源IP地址为VM 11的虚拟IP地址，目的IP地址为VM 31的虚拟IP地址，源MAC地址为VM 11的MAC地址，目的MAC地址为VM 31的MAC地址，以及VM 31对应的上线端口。
vSwitch 3接收到SDN控制器3000下发的第二流表后，可根据该第二流表将该IP报文转发到VM 31，从而实现VM 11与VM 31互访。
由此可见，本公开可以通过统一管理异构Hypervisors，使异构Hypervisors中的VMs可以通过Overlay网络实现互通，从而可以简化转发过程，提高转发效率，降低管理难度。
基于基本相同的构思，本公开还提供一种虚拟网络管理装置，所述装置可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现 为例，本公开的虚拟网络管理装置可作为一个逻辑意义上的装置，可以是通过SDN控制器上的CPU将存储介质中对应的机器可读程序指令读取后运行而成。
请参考图5，是本公开一示例中的一种虚拟网络管理装置的硬件结构示意框图。所述虚拟网络管理装置可为虚拟网络中的SDN控制器。如图5所示，该虚拟网络管理装置可以包括：诸如中央处理单元(CPU)的处理器501、内部总线502、网络接口503以及非暂时性存储介质504。其中，处理器501、网络接口503以及非暂时性存储介质504可以通过内部总线502相互通信。非暂时性存储介质504可存储有与虚拟网络管理逻辑600对应的机器可执行指令。通过处理器501读取并执行非暂时性存储介质504中存储的虚拟网络管理逻辑600所对应的机器可执行指令，可以实现虚拟控制管理装置的各个模块的功能。
图6例示了一种虚拟网络管理逻辑的各个功能模块的框图。如图6所示，从功能上划分，该虚拟网络管理逻辑600可包括第一创建单元601、第二创建单元602、信息下发单元603、转发控制单元604、第一上线单元605以及第二上线单元606。
其中，第一创建单元601可针对虚拟网络中的第一Hypervisor管理器和第二Hypervisor管理器分别创建第一Domain和第二Domain。所述第一Hypervisor管理器和所述第二Hypervisor管理器相互异构，所述第一Hypervisor管理器管理第一VM和第一vSwitch，所述第二Hypervisor管理器管理第二VM和第二vSwitch。
第二创建单元602可基于所述虚拟网络的拓扑创建拓扑管理信息，所述拓扑管理信息包括针对所述第一计算域的第一虚拟网络拓扑信息、针对所述第二计算域的第二虚拟网络拓扑信息、针对所述第一vSwitch的第一配置信息和针对所述第二vSwitch的第二配置信息；
信息下发单元603，可将所述拓扑管理信息与所述第一Domain和第二Domain分别进行关联，并可将拓扑管理信息中的第一配置信息和第二配置信息 分别下发到第一vSwitch和第二vSwitch，使得所述第一vSwitch和所述第二vSwitch分别根据所述第一配置信息和所述第二配置信息实现所述第一VM与所述第二VM之间的报文转发。
可选的，所述装置600还包括：第一上线单元605，用于当第三vSwitch在第一Hypervisor管理器上上线时，接收所述第三vSwitch发送的vSwitch上线消息；根据所述vSwitch上线消息在所述第一Hypervisor管理器对应的第一Domain中创建所述第三vSwitch的记录。
可选的，所述装置600还包括：第二上线单元606，用于当第三VM在第一Hypervisor管理器上上线时，接收所述第三VM对应的vSwitch发送的VM上线消息；根据所述VM上线消息在拓扑管理信息中添加所述第三VM的记录
可选的，所述装置600还包括转发控制单元604，所述转发控制单元604可包括：
第一接收子单元6041，用于接收所述第一vSwitch上送的源端虚拟设备为第一VM、目标端虚拟设备为第二VM的报文；
互通判断子单元6042，用于根据所述第一虚拟网络拓扑信息和所述第二虚拟网络拓扑信息判断所述第一VM和第二VM是否允许互通；
第一创建子单元6043，用于在所述第一VM和第二VM许互通时，创建第一流表并下发到所述第一vSwitch，以使所述第一vSwitch将所述报文发送到所述第二vSwitch；
第二接收子单元6044，用于接收第二vSwitch上送的所述报文；
第二创建子单元6045，用于根据第二接收子单元6044接收的所述报文创建第二流表，并将所述第二流表并下发到第二vSwitch，以使所述第二vSwitch根据所述第二流表将所述报文发送到第二VM。
可选的，所述互通判断子单元6042，可通过查找所述第一虚拟网络拓扑 信息和所述第二虚拟网络拓扑信息，来确定所述第一VM和第二VM是否对应于同一vRouter。若所述第一VM和所述第二VM对应于同一虚拟路由器，则所述第一VM和第二VM允许互通。
可选的，所述第一创建子单元6043可从所述第二虚拟网络拓扑信息中获取所述第二VM对应的虚拟IP地址及所述第二VM在所述第二vSwitch上的上线端口；从所述第二配置信息中获取第二VM对应的第二vSwitch的隧道封装信息；创建第一流表，所述第一流表包括所述第二VM的虚拟IP地址、上线端口以及所述隧道封装信息。
可选的，所述第二创建子单元6045可创建第二流表，所述第二流表包括所述第二VM的上线端口。
由此可见，本公开可以通过为异构的Hypervisor管理器创建不同的Domain，并通过拓扑管理信息管理多个Domain的虚拟网络拓扑，以使SDN控制器可以统一管理异构的Hypervisor管理器，使异构Hypervisor中的VM可以通过Overlay网络实现互通，从而可以简化转发过程，提高转发效率，降低管理难度。
以上所述仅为本公开的较佳示例而已，并不用以限制本公开，凡在本公开的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本公开保护的范围之内。

Claims (15)

  1. 一种虚拟网络管理方法，包括：
    SDN(Software Defined Network)控制器针对虚拟网络中的第一Hypervisor管理器和第二Hypervisor管理器分别创建第一计算域和第二计算域，其中，所述第一Hypervisor管理器和所述第二Hypervisor管理器异构，所述第一Hypervisor管理器管理第一虚拟机(VM)和第一虚拟交换机(vSwitch)，所述第二Hypervisor管理器管理第二VM和第二vSwitch；
    所述SDN控制器基于所述虚拟网络的拓扑创建拓扑管理信息，所述拓扑管理信息包括针对所述第一计算域的第一虚拟网络拓扑信息、针对所述第二计算域的第二虚拟网络拓扑信息、针对所述第一vSwitch的第一配置信息和针对所述第二vSwitch的第二配置信息；
    所述SDN控制器将所述拓扑管理信息与所述第一计算域和所述第二计算域分别进行关联；
    所述SDN控制器将所述拓扑管理信息中的所述第一配置信息和第二配置信息分别下发到所述第一vSwitch和第二vSwitch，使得所述第一vSwitch和所述第二vSwitch分别根据所述第一配置信息和所述第二配置信息实现所述第一VM与所述第二VM之间的报文转发。
  2. 根据权利要求1所述的方法，其中，将所述拓扑管理信息中的所述第一配置信息和第二配置信息分别下发到所述第一vSwitch和第二vSwitch包括：
    所述SDN控制器将所述拓扑管理信息下发到所述第一Hypervisor管理器，使得所述第一Hypervisor管理器将所述拓扑管理信息中的所述第一配置信息下发到所述第一vSwitch；以及
    所述SDN控制器将所述拓扑管理信息下发到所述第二Hypervisor管理器， 使得所述第二Hypervisor管理器将所述拓扑管理信息中的所述第二配置信息下发到所述第二vSwitch。
  3. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    当第三vSwitch在第一Hypervisor管理器上上线时，所述SDN控制器接收所述第三vSwitch发送的vSwitch上线消息；
    所述SDN控制器根据所述vSwitch上线消息在所述第一Hypervisor管理器对应的所述第一计算域中创建所述第三vSwitch的记录。
  4. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    当第三VM在第一Hypervisor管理器上上线时，所述SDN控制器接收所述第三VM对应的vSwitch发送的VM上线消息；
    所述SDN控制器根据所述VM上线消息在所述拓扑管理信息中添加所述第三VM的记录。
  5. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    在接收到所述第一vSwitch上送的源端虚拟设备为所述第一VM、目标端虚拟设备为所述第二VM的报文的情况下，所述SDN控制器根据所述第一虚拟网络拓扑信息和所述第二虚拟网络拓扑信息判断所述第一VM和所述第二VM是否允许互通；
    在判断所述第一VM和所述第二VM允许互通的情况下，所述SDN控制器创建第一流表；
    所述SDN控制器将所述第一流表下发到所述第一vSwitch，以使所述第一vSwitch根据所述第一流表将所述报文发送到所述第二vSwitch；
    所述SDN控制器在从所述第二vSwitch接收到的报文时创建第二流表；
    所述SDN控制器将所述第二流表下发到所述第二vSwitch，以使所述第二vSwitch根据所述第二流表将所述报文发送到所述第二VM。
  6. 根据权利要求5所述的方法，其特征在于，所述判断所述第一VM和所述第二VM是否允许互通，包括：
    所述SDN控制器通过查找所述第一虚拟网络拓扑信息和所述第二虚拟网络拓扑信息，来确定所述第一VM和所述第二VM是否对应于同一虚拟路由器；
    在所述第一VM和所述第二VM对应于同一虚拟路由器的情况下，所述SDN控制器判断所述第一VM和第二VM允许互通。
  7. 根据权利要求5所述的方法，其特征在于，所述创建第一流表，包括：
    所述SDN控制器从所述第二虚拟网络拓扑信息中获取所述第二VM的虚拟IP地址及所述第二VM在第二vSwitch上的上线端口；
    所述SDN控制器从所述第二配置信息中获取所述第二VM对应的第二vSwitch的隧道封装信息；
    所述SDN控制器创建第一流表，所述第一流表包括所述第二VM的虚拟IP地址、上线端口以及所述隧道封装信息。
  8. 根据权利要求7所述的方法，其特征在于，所述创建第二流表，包括：
    所述SDN控制器创建第二流表，所述第二流表包括所述第二VM的虚拟IP地址以及上线端口。
  9. 一种虚拟网络管理装置，其包括处理器、存储有用作虚拟网络管理逻辑所对应的机器可执行指令的非暂时性存储介质，通过执行所述机器可执行指令，所述处理器被使得：
    针对虚拟网络中的第一Hypervisor管理器和第二Hypervisor管理器分别创建第一计算域和第二计算域，其中，所述第一Hypervisor管理器和所述第二Hypervisor管理器异构，所述第一管理器管理第一虚拟机(VM)和第一虚拟交换机(vSwitch)，所述第二管理器管理第二VM和第二vSwitch；
    基于所述虚拟网络的拓扑创建拓扑管理信息，所述拓扑管理信息包括针对 所述第一计算域的第一虚拟网络拓扑信息、针对所述第二计算域的第二虚拟网络拓扑信息、针对所述第一vSwitch的第一配置信息和针对所述第二vSwitch的第二配置信息；
    将所述拓扑管理信息与所述第一计算域和所述第二计算域分别进行关联；
    将所述拓扑管理信息中的所述第一配置信息和第二配置信息下发到所述第一vSwitch和所述第二vSwitch，使得所述第一vSwitch和所述第二vSwitch分别根据所述第一配置信息和所述第二配置信息实现所述第一VM与所述第二VM之间的报文转发。
  10. 根据权利要求9所述的装置，其中，所述机器可执行指令还使得所述处理器：
    当第三vSwitch在第一Hypervisor管理器上上线时，接收所述第三vSwitch发送的vSwitch上线消息；
    根据所述vSwitch上线消息在所述第一Hypervisor管理器对应的所述第一计算域中创建所述第三vSwitch的记录。
  11. 根据权利要求9所述的装置，其中，所述机器可执行指令还使得所述处理器：
    当第三VM在第一Hypervisor管理器上上线时，接收所述第三VM对应的vSwitch发送的VM上线消息；
    根据所述VM上线消息在所述拓扑管理信息中添加所述第三VM的记录
  12. 根据权利要求9所述的装置，其中，所述机器可执行指令还使得所述处理器：
    在接收到所述第一vSwitch上送的源端虚拟设备为所述第一VM、目标端虚拟设备为所述第二VM的报文的情况下，根据所述第一虚拟网络拓扑信息和所述第二虚拟网络拓扑信息判断所述第一VM和第二VM是否允许互通；
    在判断所述第一VM和第二VM许互通的情况下，创建第一流表；
    将所述第一流表下发到所述第一vSwitch，以使所述第一vSwitch根据所述第一流表将所述报文发送到所述第二vSwitch；
    在从所述第二vSwitch接收到所述报文时创建第二流表；
    将所述第二流表下发到第二vSwitch，以使所述第二vSwitch根据所述第二流表将所述报文发送到第二VM。
  13. 根据权利要求12所述的装置，其中，所述机器可执行指令还使得所述处理器：
    通过查找所述第一虚拟网络拓扑信息和所述第二虚拟网络拓扑信息，来确定所述第一VM和所述第二VM是否对应于同一虚拟路由器；
    在所述第一VM和所述第二VM对应于同一虚拟路由器的情况下，判断所述第一VM和第二VM允许互通。
  14. 根据权利要求12所述的装置，其中，所述机器可执行指令还使得所述处理器：
    从所述第二虚拟网络拓扑信息中获取所述第二VM对应的虚拟IP地址及所述第二VM在第二vSwitch上的上线端口；
    从所述第二配置信息中获取第二VM对应的第二vSwitch的隧道封装信息；
    创建第一流表，所述第一流表包括所述第二VM的虚拟IP地址、上线端口以及所述隧道封装信息。
  15. 根据权利要求14所述的装置，其中，所述机器可执行指令还使得所述处理器：
    创建第二流表，所述第二流表包括所述第二VM的虚拟IP地址以及上线端口。
PCT/CN2016/095687 2015-08-25 2016-08-17 虚拟网络管理 WO2017032251A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2018510364A JP6574304B2 (ja) 2015-08-25 2016-08-17 仮想ネットワーク管理
EP16838510.2A EP3327994B1 (en) 2015-08-25 2016-08-17 Virtual network management
US15/744,704 US10572291B2 (en) 2015-08-25 2016-08-17 Virtual network management

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510527718.0A CN106712988B (zh) 2015-08-25 2015-08-25 一种虚拟网络管理方法及装置
CN201510527718.0 2015-08-25

Publications (1)

Publication Number Publication Date
WO2017032251A1 true WO2017032251A1 (zh) 2017-03-02

Family

ID=58099599

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/095687 WO2017032251A1 (zh) 2015-08-25 2016-08-17 虚拟网络管理

Country Status (5)

Country Link
US (1) US10572291B2 (zh)
EP (1) EP3327994B1 (zh)
JP (1) JP6574304B2 (zh)
CN (1) CN106712988B (zh)
WO (1) WO2017032251A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10862762B2 (en) * 2017-02-13 2020-12-08 Oracle International Corporation Implementing a single-addressable virtual topology element in a virtual topology
US11082300B2 (en) 2016-08-03 2021-08-03 Oracle International Corporation Transforming data based on a virtual topology
US11240152B2 (en) 2016-09-02 2022-02-01 Oracle International Corporation Exposing a subset of hosts on an overlay network to components external to the overlay network without exposing another subset of hosts on the overlay network

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9990222B2 (en) 2016-03-18 2018-06-05 Airwatch Llc Enforcing compliance rules against hypervisor and virtual machine using host management component
DE102016219854A1 (de) * 2016-10-12 2018-04-12 Siemens Aktiengesellschaft Computersystem und Verfahren zum dynamischen Anpassen eines software-definierten Netzwerks
KR102008918B1 (ko) * 2017-10-13 2019-08-08 엔에이치엔 주식회사 클라우드 네트워크 구성
CN108418705B (zh) * 2018-01-29 2021-01-08 浪潮云信息技术股份公司 虚拟机与容器混合嵌套架构的虚拟网络管理方法及系统
CN111865629B (zh) * 2019-04-26 2023-08-29 伊姆西Ip控股有限责任公司 用于配置服务实例的方法、设备和计算机程序产品
CN110351135B (zh) * 2019-06-28 2022-03-25 新华三技术有限公司合肥分公司 多dc中的网络设备配置方法及装置
US11153261B2 (en) 2020-01-22 2021-10-19 Cisco Technology, Inc. Routing traffic for virtualized/containerized network functions
US11740919B2 (en) * 2020-05-18 2023-08-29 Dell Products L.P. System and method for hardware offloading of nested virtual switches
CN112910776B (zh) * 2021-01-18 2022-10-18 北京火山引擎科技有限公司 一种数据转发方法、装置、设备及介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103516802A (zh) * 2013-09-30 2014-01-15 中国科学院计算技术研究所 一种实现跨异构虚拟交换机无缝迁移的方法和装置
CN104115453A (zh) * 2013-12-31 2014-10-22 华为技术有限公司 一种实现虚拟机通信的方法和装置
CN104303467A (zh) * 2012-05-23 2015-01-21 博科通讯系统有限公司 集成的异构的软件定义的网络
US20150212844A1 (en) * 2014-01-27 2015-07-30 Red Hat Israel, Ltd. Fair Unidirectional Multi-Queue Virtual Machine Migration

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA3081255C (en) 2009-04-01 2023-08-22 Nicira, Inc. Method and apparatus for implementing and managing virtual switches
US8675644B2 (en) * 2009-10-16 2014-03-18 Oracle America, Inc. Enhanced virtual switch
US8743888B2 (en) * 2010-07-06 2014-06-03 Nicira, Inc. Network control apparatus and method
CN102710432B (zh) * 2012-04-27 2015-04-15 北京云杉世纪网络科技有限公司 云计算数据中心中的虚拟网络管理系统及方法
US8942237B2 (en) * 2012-06-20 2015-01-27 International Business Machines Corporation Hypervisor independent network virtualization
US9036639B2 (en) 2012-11-29 2015-05-19 Futurewei Technologies, Inc. System and method for VXLAN inter-domain communications
CN103051529B (zh) * 2012-12-20 2016-03-30 华为技术有限公司 一种报文的处理方法和装置
US9477506B2 (en) * 2013-02-12 2016-10-25 Futurewei Technologies, Inc. Dynamic virtual machines migration over information centric networks
JP2014182576A (ja) 2013-03-19 2014-09-29 Hitachi Ltd 構成管理装置と構成管理方法及び構成管理プログラム
CN104253770B (zh) * 2013-06-27 2017-07-14 新华三技术有限公司 实现分布式虚拟交换机系统的方法及设备
CN104518935B (zh) * 2013-09-27 2018-05-25 华为技术有限公司 实现虚拟网络通信的方法、装置和系统
US9912582B2 (en) * 2013-11-18 2018-03-06 Telefonaktiebolaget Lm Ericsson (Publ) Multi-tenant isolation in a cloud environment using software defined networking
US9612854B2 (en) * 2013-12-18 2017-04-04 Telefonaktiebolaget Lm Ericsson (Publ) System and method for virtualizing a remote device
US9794128B2 (en) * 2013-12-30 2017-10-17 International Business Machines Corporation Overlay network movement operations
US10097372B2 (en) * 2014-01-09 2018-10-09 Ciena Corporation Method for resource optimized network virtualization overlay transport in virtualized data center environments
US10079694B2 (en) * 2014-08-29 2018-09-18 Nokia Of America Corporation Scalable virtual networks in SDN-based ethernet networks using VLANs

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104303467A (zh) * 2012-05-23 2015-01-21 博科通讯系统有限公司 集成的异构的软件定义的网络
CN103516802A (zh) * 2013-09-30 2014-01-15 中国科学院计算技术研究所 一种实现跨异构虚拟交换机无缝迁移的方法和装置
CN104115453A (zh) * 2013-12-31 2014-10-22 华为技术有限公司 一种实现虚拟机通信的方法和装置
US20150212844A1 (en) * 2014-01-27 2015-07-30 Red Hat Israel, Ltd. Fair Unidirectional Multi-Queue Virtual Machine Migration

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3327994A4 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11082300B2 (en) 2016-08-03 2021-08-03 Oracle International Corporation Transforming data based on a virtual topology
US11240152B2 (en) 2016-09-02 2022-02-01 Oracle International Corporation Exposing a subset of hosts on an overlay network to components external to the overlay network without exposing another subset of hosts on the overlay network
US10862762B2 (en) * 2017-02-13 2020-12-08 Oracle International Corporation Implementing a single-addressable virtual topology element in a virtual topology

Also Published As

Publication number Publication date
EP3327994B1 (en) 2021-12-15
JP6574304B2 (ja) 2019-09-11
EP3327994A4 (en) 2018-05-30
US20180210750A1 (en) 2018-07-26
JP2018525937A (ja) 2018-09-06
US10572291B2 (en) 2020-02-25
CN106712988A (zh) 2017-05-24
CN106712988B (zh) 2019-11-12
EP3327994A1 (en) 2018-05-30

Similar Documents

Publication Publication Date Title
WO2017032251A1 (zh) 虚拟网络管理
JP6605713B2 (ja) クラウドコンピューティングシステムにおけるパケット処理方法、ホスト及びシステム
CN107070691B (zh) Docker容器的跨主机通信方法和系统
US9825900B2 (en) Overlay tunnel information exchange protocol
US20150358232A1 (en) Packet Forwarding Method and VXLAN Gateway
EP3376712B1 (en) Method and apparatus for implementing communication between virtual machines
US10541913B2 (en) Table entry in software defined network
US10554484B2 (en) Control plane integration with hardware switches
US9294349B2 (en) Host traffic driven network orchestration within data center fabric
WO2018040530A1 (zh) 一种确定虚拟机迁移的方法和装置
WO2017114342A1 (zh) 虚拟机报文控制
WO2018112709A1 (zh) 一种数据包处理方法、主机和系统
US20240154928A1 (en) Communication method, gateway, and management method and apparatus in hybrid cloud environment
WO2016045637A1 (en) Forwarding data packets in software defined network
WO2017198163A1 (zh) 接入控制
US9992153B2 (en) Managing link aggregation traffic in edge nodes
TWI477110B (zh) 資料通信方法和資料通信系統
WO2015113410A1 (zh) 数据包的处理方法与装置
CN106331206B (zh) 域名管理方法及装置
WO2014079005A1 (zh) Mac地址强制转发装置及方法
US20170019369A1 (en) Managing link aggregation traffic in edge nodes
US11570097B1 (en) Overlay broadcast network for management traffic
CN108111461B (zh) 实现虚拟机访问管理网络的方法、装置、网关及系统
CN116888940A (zh) 利用虚拟联网的容器化路由器
US20240348584A1 (en) Arp-based annotations for virtual machines

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16838510

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15744704

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2018510364

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2016838510

Country of ref document: EP