WO2014186957A1 - 多租户网络系统 - Google Patents

多租户网络系统 Download PDF

Info

Publication number
WO2014186957A1
WO2014186957A1 PCT/CN2013/076067 CN2013076067W WO2014186957A1 WO 2014186957 A1 WO2014186957 A1 WO 2014186957A1 CN 2013076067 W CN2013076067 W CN 2013076067W WO 2014186957 A1 WO2014186957 A1 WO 2014186957A1
Authority
WO
WIPO (PCT)
Prior art keywords
virtual machine
pod
layer
switch
tenant
Prior art date
Application number
PCT/CN2013/076067
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 PCT/CN2013/076067 priority Critical patent/WO2014186957A1/zh
Publication of WO2014186957A1 publication Critical patent/WO2014186957A1/zh

Links

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

Definitions

  • the present invention relates to multi-tenant technology, and in particular, to a multi-tenant network that needs to support exactly two (multiple) logical POD, g ⁇ Multi-tenant POD issues. Background technique
  • a tenant is a customer who uses a system or computer computing resource, but in multi-tenant technology, a tenant contains all the data that can be identified as a specified user in the system, as well as the user's own customized application.
  • the program environment, etc. are all within the scope of the tenant.
  • Tenants use application systems or computing resources developed or built by vendors.
  • the application system designed by the vendor will accommodate more than one tenant in the same environment (the respective instance of the application instance), in order to allow multiple tenants to use multiple instances of the same application in the computing environment,
  • the application and computing environment must be specially designed.
  • the ability of the network to support multiple logical PODs is one of the keys to multi-tenancy technology.
  • POD point of delivery
  • Cisco The concept of POD (point of delivery) was first proposed by Cisco. It is a rapidly deployable building module and a fast-delivery module that includes services, security, networking, management, virtualization software, and data center interconnection technologies. There are many types of POD construction. First, there is a definition. POD is a replicable physical environment, including computing resources, network resources, application resources, and so on. The most important thing is that virtualization applications within the same POD can be freely migrated without the barrier of a three-tier routing. The design of POD users may be different for different users. It is possible that all aggregation switches under one data center core switch are a POD; it may be smaller.
  • POD can be divided into logical and physical.
  • the so-called logical POD refers to the combination of computing, network, and storage logical resources required by the user's business project.
  • the resources are "subscribed” according to the specifications specified by the user, and the resources therein have the characteristics of shared space or shared time (so-called time sharing).
  • the so-called physical POD is a resource supply physical unit formed by defining and dividing a collection of devices in a data center network; the unit can work independently without relying on other devices, and finally form a POD resource service unit. That is to say, the basic unit of resource supply is not a physical server, a virtual server or a virtual switch, but a (meaningful) "collection" between them.
  • Logical POD is like a banquet reserved for a wedding banquet, including table size, number of seats, and dishes, etc.
  • physical POD is the actual birthday of the wedding banquet.
  • the POD proposed by Cisco refers only to physical POD.
  • the distinction between logical and physical POD, and in particular the mapping of logical PODs to physical PODs, is unique to the present invention.
  • a tenant refers to each department in an enterprise or government that occupies IT resources. This occupation is different from the permanent possession of resources in the past, but refers to sharing resources in a private cloud at a specific time period or place.
  • a development department of a bank deploys a clearing system in a private cloud data center for development according to the specification of logical POD A
  • the testing department deploys the clearing system in a private cloud data center for testing according to the specification of logical POD B, logical POD A
  • the specifications are exactly the same as those of POD B.
  • the development and testing departments of this bank are tenants whose logical PODs share the same physical POD in the private cloud data center and run their own clearing system instances.
  • the multi-tenant computing environment requires the network to provide appropriate network services based on the needs of the multi-tenant application.
  • multi-tenant network technologies face different needs in order to adapt to the characteristics of computing resources pooling.
  • Multi-tenant networks must meet the isolation requirements between virtual servers. Each tenant must sign a network service policy with the cloud service provider, that is, each tenant has its own independent network policy deployment plan.
  • Multi-tenant networks must ensure that each tenant has a different quality of service.
  • each tenant has a different application, so the cloud service provider must ensure the quality of service for each tenant.
  • each user's QoS policy and its traffic policy are very important.
  • Multi-tenant networks must be able to interconnect tenants across the WAN or MAN.
  • the deployment of tenant's virtual servers is not necessarily concentrated in one data center, and some need to span the metropolitan area network or even the wide area network. In this case, the multi-tenant network must be able to interconnect tenants across the Internet.
  • the multi-tenant network described in the present invention also faces special needs, for example, a bank's development department and testing department, respectively, in a private cloud data center according to its own logical POD specification. Share the same physical POD and run their own clearing system.
  • the multi-tenant network faces the problem that two (multiple) tenants share the same set of IP addresses.
  • the clearing system is customized by the third party for the bank, it is not convenient to change the IP address in the program; or in order to make the tested clearing system more faithful to the development or production environment, the multi-tenant network needs to support the same Two (multiple) logical POD, g ⁇ Multi-tenant POD issues.
  • Figure 1 depicts a common single tenant POD, the Single-tenant POD.
  • a single tenant POD can only run an instance of an application, it cannot support multi-tenancy.
  • Figure 1 is an example of a multi-tenant POD problem encountered by a single tenant POD in the face of a multi-tenant network.
  • the virtual machine VM 1002 and VM 1006 belong to the same POD and are occupied by the development department.
  • the virtual machine VM 1003 and VM 1004 belong to the same POD and are used by the testing department in the plan.
  • the virtual machine VM 1002 and the virtual machine VM 1003 use the same IP address, which is 1.0.0.0.2; the virtual machine VM 1004 and the virtual machine VM 1006 use the same IP address, both of which are 1.0.0.1.2. It can be seen that the two PODs share the same set of IP addresses, namely: 1.0.0.0.2 and 1.0.0.1.2.
  • the object of the present invention is to solve the above problems, and to provide a multi-tenant network system, so that a multi-tenant network supports exactly the same multiple logical POD (Point Of Delivery), that is, a Mult i-tenant POD problem.
  • POD Point Of Delivery
  • the technical solution of the present invention is:
  • the present invention discloses a multi-tenant network system, including multiple data A central tenant, each of the plurality of data center tenants includes a logical POD, and the system has a physical POD.
  • the logical PODs of the plurality of data center tenants share the same physical POD in the private cloud data center, and run the respective systems.
  • the multi-tenancy mode of the instance wherein the physical POD is a resource supply physical unit formed by defining and dividing a device set in the data center network, and can work independently without relying on other devices, and finally forms a POD resource service unit, and the logical POD is according to the user.
  • the plurality of data center tenants operate the multi-tenancy mode in the system by way of virtual routing.
  • the manner of virtual routing is applicable to an environment without external storage.
  • the system includes a first virtual machine, a second virtual machine, a third virtual machine, and a fourth virtual machine, wherein the first virtual machine and the fourth virtual machine belong to the first
  • the plurality of data center tenants operate the multi-tenancy mode in the system by establishing a pipeline.
  • the manner in which the pipeline is established is applicable to both an environment without external storage and an environment with external storage.
  • the system includes a first virtual machine, a second virtual machine, a third virtual machine, and a fourth virtual machine, wherein the first virtual machine and the fourth virtual machine belong to the first POD.
  • the second virtual machine and the third virtual machine belong to the second POD, and are occupied by the second department.
  • the first virtual machine and the second virtual machine both use the first IP address, and are in the first host.
  • the third virtual machine and the fourth virtual machine both use the second IP address, and are on the second host, the first three-layer switch.
  • the fourth layer 3 switch establishes a first pipeline for communication between the first virtual machine and the fourth virtual machine, and the second layer 3 switch and the third layer 3 switch are between the second virtual machine and the third virtual machine.
  • the communication establishes a second pipeline, which uses the IP addresses of the first Layer 3 switch and the Layer 2 switch on the pipeline to be different, and the IP addresses of the Layer 3 and Layer 3 switches are different, in the first Layer 3 switch,
  • the second layer 3 switch, the third layer 3 switch, and the fourth layer 3 switch communicate with each other through the router, and the first POD and the second POD belonging to the first department and the second department share the same set of IP addresses: IP address and second IP address.
  • the application system instances running in the first POD and the second POD are separate, and the virtual machine is used to implement the three-layer routing function for forwarding data between VLANs. Packets, packets in the first POD and the second POD do not meet and conflict at any point.
  • the present invention has the following beneficial effects:
  • the solution of the present invention is to implement a multi-tenant network system by using a virtual route or a tunnel (the former), the former is relatively simple, and is applicable to the case of no external storage, and the latter is complicated. , but it can be applied to the case of external storage.
  • Figure 1 shows an example where a single tenant POD can only run one application.
  • Figure 2 illustrates multiple instances of the present invention that enable a multi-tenant POD to run an application through virtual routing.
  • FIG. 3 shows a specific implementation diagram of implementing a multi-tenant POD by virtual routing.
  • Figure 4 illustrates multiple instances of the present invention for enabling a multi-tenant POD to run an application by establishing a pipeline.
  • FIG. 5 shows an implementation process of implementing a multi-tenant POD through virtual routing.
  • the multi-tenant computing model is the most typical service-oriented application model in the cloud computing technology architecture. It requires a server computing environment. The design and deployment of storage resources and their network resources must meet the isolation between virtual servers, ensure the different quality of service for each tenant, and enable the interconnection of tenants across the WAN or metropolitan area network. Below we focus on the solution that the network needs to meet the special needs mentioned above in the multi-tenant environment, namely the Multi-tenant POD problem.
  • FIG. 2 illustrates multiple instances of the present invention for enabling a multi-tenant POD to run an application by virtual routing.
  • the virtual machines VM 2001, 2002, 2003, 2004, 2005, and 2006 in FIG. 2 are the VMs 1001, 1002, 1003, 1004, 1005, and 1006 in FIG.
  • the virtual machine VM 2002 and the virtual machine VM 2003 use the same IP address, both of which are 1.0.0.0.2; the virtual machine VM 2004 and the virtual machine VM 2006 use the same IP address, both of which are 1.0.0.1.2.
  • a virtual route may be employed, that is, a simple method of replacing the original one physical route 1021 with two virtual routes 2021a and 2021b to solve the conflict of IP addresses.
  • the virtual machines VM 2002 and VM 2006 when deployed, they can communicate through the router 2021a, and their corresponding gateway addresses are: 1.0.0.0.1 and 1.0.0.1.1.
  • the virtual machine VM 2003 and VM 2004 are deployed, they can communicate through the router 1021b, and the corresponding gateway address is also: 1.0.0.0.1 and 1.0.0.1.1.
  • FIG. 3 is a specific implementation diagram of the scheme described in FIG. 2.
  • the virtual machines VMs 3002, 3003, 3004, and 3006 in FIG. 3 are VM 2002, 2003, 2004, and 2006 in FIG.
  • the virtual machine VM 3002 and VM 3006 belong to the same POD and are occupied by the development department; the virtual machine VM 3003 and VM 3004 belong to another POD and are used by the testing department.
  • Virtual machine VM 3002 and virtual machine VM 3003 The IP addresses used are the same, both are 1.0.0.0.2, they are on the same host (Host) 3051; the virtual machine VM 3004 and the virtual machine VM 3006 use the same IP address, both are 1.0.0.1.2 They are on the same host (Host) 3052.
  • the two PODs in Figure 3 share the same set of IP addresses: 1.0.0.0.2 and 1.0.0.1.2.
  • the virtual switch 301 1 in Fig. 3 replaces the role of the virtual switches 201 1 and 2012 in Fig. 2; the virtual switch 3013 replaces the role of the virtual switches 2013 and 2014 in Fig. 2.
  • the Layer 3 routers (vRouter) 3021a and 3021b in Figure 3 implement the functionality of virtual routes 2021a and 2021b in Figure 2.
  • the 3021a and 3021b are actually implemented by two virtual machines (VMs), so they require Hypervisor support.
  • the Layer 2 switch 3015 in Figure 3 represents the Layer 2 switch 2015 that can be omitted in Figure 2, which can be either physical or virtual.
  • the role of the Layer 2 switch 3015 is to increase the flexibility of the scheme described in FIG. 2, for example: In the case where the VMs VM 3002 and VM 3006 belong to one VLAN, the packets sent from the VM 3002 to the VM 3006 do not have to pass through the Layer 3 layer. Router 3021a, but instead is forwarded directly by Layer 2 switch 3015; the same is true for packets sent from VM 3006 to VM 3002. This greatly speeds up the transfer of packets between the VM 3002 and the VM 3006.
  • FIG. 5 illustrates an implementation process of implementing a multi-tenant POD through a virtual routing method.
  • the steps to implement the virtual route method are as follows:
  • Step 1) First, design an application APP.
  • This application requires two servers (A and B); the IP of the specified A is "100.0.0.100", the gateway is "100.0.0.1”; the IP of the specified B is "200.0.0.100”. " , Gateway is " 200.0.0.1 " ;
  • Step 2) Deploy the application APP-time, to the virtual machine VM 5002 and VM 5006, which is the APP instance INSTANCE 1.
  • Step 4 Redeploy the application APP - times, to the virtual machine VM 5003 and VM 5004, which is the APP instance INSTANCE2o
  • Step 5) Start APP INSTANCE2, where VM 5003 of INSTANCE2 selects VLAN 300 for communication, VM 5004 selects VLAN 400 for communication, they need to trigger the "Exchange Service” program on the Layer 2 switch to assign VLANs 300 and 400, trigger in the virtual routing server. "Multiple Guest Services” creates a virtual route for this instance.
  • vGateway2 includes two ports, which belong to VLANs 300 and 400 respectively, and specifies that the IP of VLAN300 is "100.0.0.1” and the IP of VLAN400 is "200.0.0.1", so the deployment of INSTANCE2 is completed.
  • the application instance (instance) running in two PODs is physically separate.
  • VM virtual machine
  • Multi-tenant networks must meet the isolation requirements between virtual servers 2) Multi-tenant networks must ensure the basic requirements of different quality of service for each tenant.
  • the virtual machine VM 4002 and the virtual machine VM 4003 use the same IP address, both of which are 1.0.0.0.2; the virtual machine VM 4004 and the virtual machine VM 4006 use the same IP address, both of which are 1.0.0.1.2.
  • a virtual gateway vGateway may be used instead of the virtual switch vSwitch, that is, the method of replacing the original virtual switches 1011, 1012, 1013, and 1014 with the three-layer switches 4011, 4012, 4013, and 4014 is used to solve the problem.
  • the conflict of IP addresses is resolved.
  • the virtual machine VM 4002 can communicate with the outside through the virtual gateway 4011.
  • the gateway address of the corresponding VLAN is: 1.0.0.0.1, and the external gateway address is: 100.0.0.10;
  • the virtual machine VM 4003 can The virtual gateway 4012 communicates with the outside, and the gateway address of the corresponding VLAN is: 1.0.0.0.1, and the external gateway address is: 100.0.1.10;
  • the virtual machine VM 4004 can communicate with the outside through the virtual gateway 4013.
  • the gateway address of the corresponding VLAN is: 1.0.0.1.1, and the external gateway address is: 100.0.2.10;
  • the virtual machine VM 4006 can communicate with the outside through the virtual gateway 4014, and the gateway address of the corresponding VLAN is: 1.0.0.1. 1.
  • the external gateway address is: 100.0.3.10.
  • the three-layer switch 4011, 4012 in FIG. 4 converts the same gateway address 1.0.0.0.1 of the two VLANs where the virtual machine VM 4002 and the VM 4003 are located into different external gateway addresses 100.0.0.10 and 100.0.1.10;
  • the three-layer switch 4013, 4014 converts the same gateway address 1.0.0.1.1 of the two VMs where the virtual machine VM 4004 and the VM 4006 are located into different external gateway addresses 100.0.2.10 and
  • the essence of the above solution is that the three-layer switches 4011 and 4014 establish a tunnel for communication between the virtual machine VM 4002 and the VM 4006.
  • the three-layer switches 4012 and 4013 are virtual machines.
  • the communication between VM 4003 and VM 4004 establishes another conduit.
  • the two PODs share the same set of IP addresses, namely: 1.0.0.0.2 and 1.0.0.1.2.
  • Figure 4 is a method for establishing a tunnel to implement a multi-tenant POD.
  • the steps to establish a pipeline and communicate are as follows: The specific process is more complicated:
  • the virtual machine VM 4003 wants to access the virtual machine VM 4004, first the virtual machine VM 4003 will perform its own IP address and subnet mask to obtain the network address (for example: the IP of the virtual machine VM 4003) After the address 10.0.0.2 is operated with the self-mask 255.255.255.0, the obtained network number is 10.0.0.0). Then it is judged whether the destination IP address (that is, the IP address of the virtual machine VM 4004) is the same as its own network address. Subnet. Because the virtual machine VM 4003 and VM 4004 are not in the same subnet, three layers of forwarding are required.
  • Step 1) The virtual machine VM 4003 sends an ARP broadcast to obtain the gateway MAC address.
  • the virtual machine VM 4003 wants to access the virtual machine VM 4004 to first have the MAC address of the virtual machine VM 4004. Since the virtual machine VM 4003 and the VM 4004 are not in the same subnet, the virtual machine VM 4003 first sends an ARP broadcast message to the default gateway. To get the MAC address of the gateway.
  • Step 2) The Layer 3 switch 4012 forms a MAC entry of the VM VM 4003 and responds to the ARP request of the VM VM 4003 with the gateway MAC address.
  • the Layer 3 switch 4012 After receiving the ARP broadcast packet, the Layer 3 switch 4012 first learns the source MAC address of the Ethernet header of the ARP packet, and the switch chip automatically records the MAC address of the VM 4003.
  • the Layer 3 switch 4012 also saves the information such as the IP and MAC of the virtual machine VM 4003 to the interface of the switch 4012 through the software to the ARP table of the switch 4012 (the three-layer entry, the MAC table is not IP).
  • the destination IP address (10.0.0.1) in the ARP broadcast packet sent by the VM VM is the IP address of the VLAN (VLAN 100) to which the interface (E1/0/0) that receives the ARP broadcast packet is received.
  • the switch will reply to the ARP request of virtual machine VM 4003 using the MAC address of VLAN 100.
  • Step 3) The virtual machine VM 4003 is sent to the gateway by the gateway MAC.
  • the VM 4003 After receiving the ARP reply packet from the gateway, the VM 4003 sends the data frame to the gateway.
  • the gateway MAC is used as the destination MAC to encapsulate the data frame.
  • Step 4): The Layer 3 switch 4012 searches the hardware forwarding table/routing table for Layer 3 forwarding. After receiving the data packet sent by the VM VM 4003, the Layer 3 switch 4012 still learns the source MAC address of the Ethernet packet of the data packet. Address, and then look up the MAC table of the switch according to the destination MAC address of the Ethernet header, and find that the destination MAC address is the MAC address of the local VLAN. In this case, the switch will send the message to the Layer 3 engine of the switch chip. The three-tier engine will first look up the hardware forwarding table.
  • the IP address of the packet is processed accordingly: 1.
  • the destination IP address is the local IP address, and the corresponding module is processed.
  • the destination IP address is the IP address of the other device. If the local IP address is forwarded only, the source MAC address of the outgoing MAC address is replaced by the hardware forwarding entry, and the destination MAC address of the packet is replaced by the next hop MAC address. , continue to forward. (The difference between this and the second layer is that the source and destination MAC of the packet need to be replaced.)
  • the hardware forwarding table/routing table of the layer 3 switch 4012 already has the routing entry of the virtual machine VM 4004, so the switch will virtual machine VM The source and destination MAC addresses in the message sent from 4003 are replaced.
  • the TTL value is decremented by 1, and then sent to the Layer 3 switch 4013.
  • IPsec Common Layer 3 tunneling protocols are: GRE, IPsec and MPLS.
  • IPSec is a suite of protocols defined by the Internet Engineering Task Force (IETF) and consists of a set of protocols: Authentication Header (AH), Encapsulated Security Payload (ESP), Internet Security Association (SA), and Key Management Protocol ISAKMP Internet
  • IETF Internet Engineering Task Force
  • AH Authentication Header
  • ESP Encapsulated Security Payload
  • SA Internet Security Association
  • ISAKMP Key Management Protocol
  • DOI IP Security Interpretation Domain
  • ISAKMP Internet Key Management Protocol
  • IKE Internet Key Management Protocol
  • OAKLEY Key Determination Protocol etc.
  • the IPSEC tunnel mode is the application type of the two-layer IP address, that is, the outer IP address is used for routing and forwarding, and the inner IP packet is the real user data packet.
  • the client needs to send encrypted data:
  • Inner IP refers to the internal logical IP of VM4003: 10.0.0.2, that is, the IP used to interact with the peer VM2004 (Note: If the peer is inside the VLAN, it does not need to have IPSec Features) ;
  • IP 100.0.1.10: 100.0.1.1
  • IP 100.0.2.1
  • router 4021 the destination address IP: 100.0.2.10, ie three Layer switch 4013 ;
  • the security gateway After receiving the data, the security gateway "removes" the outer IP header and the ESP header from the message, and decrypts the encrypted data to restore the original data;
  • the Layer 3 switch 4013 forwards the network original data packet.
  • the forwarding is based on the IP address of the inner layer IP address, namely VM4004: 10.0.1.2.
  • the third layer engine looks for the hardware forwarding table process similar to step 4), so it will not be described.
  • the hardware forwarding table/routing table of the switch 4013 already has the virtual machine VM 4004.
  • the routing table entry replaces the source and destination MAC addresses in the packets sent by the virtual machine VM 4003, and the TTL value is decremented by one, and then sent to the virtual machine VM 4004.
  • the virtual machine VM 4003 sends the data packet to the virtual machine VM 4004 on a different network segment.
  • the hardware forwarding entries of the virtual machine VM 4003 and the virtual machine VM 4004 are also saved on the switch, and the virtual machine VM 4003 and the virtual machine VM 4004 are mutually accessed, and the other network segment hosts access the virtual machine VM 4003 or VM 4004.
  • the switches 4012 and 4013 can forward directly according to the hardware forwarding entry without having to look up the routing table.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了多租户网络系统，以使多租户的网络支持完全相同的多个逻辑POD，即Multi-tenant POD问题。其技术方案为：系统包括多个数据中心租户，该多个数据中心租户各自包括一逻辑POD，系统内设有一物理POD，多个数据中心租户自身的逻辑POD在私有云数据中心内分享同一个物理POD，并运行各自的系统实例的多租户方式，其中物理POD是在数据中心网络中经过定义和划分设备集合所构成的资源供应物理单元，可不依赖于其它设备而独立工作，最终形成POD资源服务单元，逻辑POD是按照用户所定规格订阅的用户业务项目所需的计算、网络、存储逻辑资源的组合，其中的资源具有共享空间或共享时间的特性，该多个数据中心租户的POD的网络分享同一套IP地址。

Description

多租户网络系统
发明领域
本发明涉及多租户技术， 具体地说， 涉及多租户的网络需要支持完全相同 的两 （多） 个逻辑 POD, g卩 Multi-tenant POD问题。 背景技术
多租户技术是一种软件架构技术， 它是在探讨与实现如何于多用户的环境 下共用相同的系统或程序组件， 并且仍可确保各用户间数据的隔离性。
在多租户技术中， 租户 （tenant) 是指使用系统或电脑运算资源的客户， 但在多租户技术中， 租户包含在系统中可识别为指定用户的一切数据， 以及用 户本身的客制化应用程序环境等， 都属于租户的范围。 而租户所使用的则是基 于供应商所开发或建置的应用系统或运算资源。 供应商所设计的应用系统会容 纳数个以上的租户在同一个环境下使用 （各自的应用系统实例 instance ) ， 为 了要让多个租户在运算环境上使用同一个应用程序的多个实例， 则应用程序与 运算环境必须要特别设计， 除了可以让服务器可以 (通过虚拟化技术)允许同时 运行多份相同的应用程序外， 网络能够支持多个逻辑 POD 的实现也是多租户 技术的关键之一。
POD (point of delivery) 的概念最早是由 Cisco提出来的， 就是可以快速部 署的建设模块、 快速交付的模块， 里面包括服务、 安全、 网络、 管理、 虚拟化 软件、 数据中心互联技术。 POD的建设有多种类型， 首先有一个定义， POD是 可复制的物理的环境， 包括计算资源、 网络资源、 应用资源等等。 最重要的是 在同一个 POD 之内的虚拟化应用可以自由地迁移， 没有所谓的三层路由的障 碍。 针对不同的用户， POD用户的设计可能会有不同， 可能一个数据中心核心 交换机下面所有的汇聚交换机都是一个 POD; 也可能小一点儿。 比较大的情况 下整个系统资源利用率会比较高， 应用能够在大的范围内、 大的集群里面自由 的获取资源运行， 但是必然不灵活。 如果这个 POD必须要 2000平米的机房， 那么旁边有一个 1000平米的机房就不可用。 POD 比较小会非常灵活， 但是资 源利用率效率不高， 因为资源的调配都是在小范围内实现的。 POD在服务提供 商的基础设施中显得尤为重要， 比如： 支持云计算服务的数据中心， POD可在 荷载 /数据量增长时维持其可扩展性。
在本发明中， POD可分为逻辑的和物理的。 所谓逻辑 POD， 是指用户业务 项目所需的计算、 网络、 存储逻辑资源的组合， 按照用户所定规格 "订阅" 而 来， 其中的资源具有共享空间或共享时间 (所谓分时)的特性。 所谓物理 POD， 乃是在数据中心网络中经过定义和划分设备集合所构成的资源供应物理单元; 该单元可不依赖于其他设备而独立工作，最终形成 POD资源服务单元。 也就是 说， 资源供应的基本单元， 不是一个物理服务器、 一个虚拟服务器或一个虚拟 交换机， 而是它们之间的一个 (有意义的） "集合" 。 逻辑 POD和物理 POD的 关系可以用一个通俗的例子来比喻： 逻辑 POD 就好比某个婚宴所预定的酒席， 包括桌数、座数以及菜色等等规格属性； 而物理 POD则是婚宴当日宾主实际享 用到的宴席。 Cisco所提出的 POD仅专指物理 POD。区分逻辑的和物理的 POD， 特别是将逻辑 POD映射到物理 POD的方法为本发明所特有。
在私有云的环境中， 租户指企业或政府中对 IT 资源占用的各个部门， 这 种占用不同于以往对资源的永久占有， 而是指在特定的时间段或地点共享私有 云中的资源。比如某银行的开发部门按逻辑 POD A的规格将清算系统部署在私 有云数据中心中进行开发，而测试部门按逻辑 POD B的规格将清算系统部署在 私有云数据中心中进行测试， 逻辑 POD A和 POD B的规格完全一致。 这个银 行的开发部门和测试部门就是租户， 它们的逻辑 POD 在私有云数据中心内分 享同一个物理 POD, 并运行各自的清算系统实例。
多租户的计算环境要求网络应根据多租户应用的需求， 为其提供相应的网 络服务。 相对于传统的网络技术， 多租户的网络技术为了适应计算资源池化的 特点， 会面临一些不同的需求。 例如：
1.多租户网络必须满足虚拟服务器之间的隔离需求。 每个租户必须和云服 务提供商签署关于网络服务策略， 即每个租户有自己独立的网络策略部署方 案。
2.多租户的网络必须确保每个租户不同的服务质量。 在多租户网络中， 每 个租户有不同的应用， 所以， 云服务提供商必需确保每个租户的服务质量。 在 多租户网络中， 每个用户的 QoS策略及其流量策略非常重要。
3.多租户网络必须能够实现租户跨广域网或城域网的互联互通。 在多租户 网络中， 租户的虚拟服务器的部署并不一定都集中在一个数据中心， 有的需要 跨越城域网甚至广域网。 在这种情况下， 多租户网络必须能够跨越互联网实现 租户的互联互通。
除上面所述的三种基本需求外， 本发明所描述的多租户的网络还需面临特 殊的需求， 例如， 某银行的开发部门和测试部门， 分别按自己的逻辑 POD 规 格在私有云数据中心内分享同一个物理 POD, 并运行各自清算系统。 这时， 该 多租户的网络就面临着两（多）个租户分享同一套 IP地址的问题。 出于各种原 因， 例如清算系统是由第三方为银行所定制， 不便在程序中更改 IP地址； 或者 为了使被测试的清算系统更加忠实于开发或生产环境， 多租户的网络需要支持 完全相同的两 （多） 个逻辑 POD, g卩 Multi-tenant POD问题。
请参见图 1， 它描述了一个常见的单租户 POD, 即 Single-tenant POD。 单 租户 POD只能够运行一个应用程序的实例， 它不能够支持多租户。 图 1 即是 单租户 POD在面临多租户的网络时遇到的 Multi-tenant POD问题的一个实例。 虚拟机 VM 1002和 VM 1006同属于一个 POD, 由开发部门占用； 虚拟机 VM 1003和 VM 1004同属于另一个 POD, 计划中由测试部门使用。 而虚拟机 VM 1002和虚拟机 VM 1003所使用的 IP地址相同，均为 1.0.0.0.2; 虚拟机 VM 1004 和虚拟机 VM 1006所使用的 IP地址相同， 均为 1.0.0.1.2。 由此可见，两个 POD 分享了同一套 IP地址， 即: 1.0.0.0.2禾卩 1.0.0.1.2。
当虚拟机 VM 1002和 VM 1006部署完成后，它们可以通过路由器 1021来 进行通讯， 其对应的网关地址分别为： 1.0.0.0.1和 1.0.0.1.1。 然而， 虚拟机 VM 1003 (以及虚拟机 VM 1004) 却不能够同样通过路由器 1021来进行通讯， 因 为 VM 1003要使用的 IP地址 1.0.0.0.2已被 VM 1002占用， 而路由器 1021不 能够解决该种冲突。 发明概述
本发明的目的在于解决上述问题， 提供了一种多租户网络系统， 以使多租 户的网络支持完全相同的多个逻辑 POD ( Point Of Del ivery ) ， 即 Mult i-tenant POD问题。
本发明的技术方案为： 本发明揭示了一种多租户网络系统， 包括多个数据 中心租户，该多个数据中心租户各自包括一逻辑 P0D，该系统内设有一物理 P0D， 该多个数据中心租户自身的逻辑 POD在私有云数据中心内分享同一个物理 P0D， 并运行各自的系统实例的多租户方式， 其中物理 POD是在数据中心网络中经过 定义和划分设备集合所构成的资源供应物理单元， 可不依赖于其它设备而独立 工作， 最终形成 POD资源服务单元， 逻辑 POD是按照用户所定规格订阅的用户业 务项目所需的计算、 网络、 存储逻辑资源的组合， 其中的资源具有共享空间或 共享时间的特性， 该多个数据中心租户的 POD的网络分享同一套 IP地址。
根据本发明的多租户网络系统的一实施例， 该多个数据中心租户是通过虚 拟路由的方式在系统中运行多租户方式的。
根据本发明的多租户网络系统的一实施例， 虚拟路由的方式适用于无外界 存储的环境。
根据本发明的多租户网络系统的一实施例， 系统包括第一虚拟机、 第二虚 拟机、 第三虚拟机和第四虚拟机， 其中第一虚拟机和第四虚拟机同属于第一
P0D， 由第一部门占用， 第二虚拟机和第三虚拟机同属于第二 P0D， 由第二部门 占用， 第一虚拟机和第二虚拟机均使用第一 IP地址， 同在第一宿主机上， 第三 虚拟机和第四虚拟机均使用第二 IP地址， 同在第二宿主机上， 使用第一虚拟路 由和第二虚拟路由以避免 IP地址冲突， 其中第一虚拟机和第四虚拟机通过第一 虚拟路由交换数据包， 第二虚拟机和第三虚拟机通过第二虚拟路由交换数据 包， 分属于第一部门和第二部门的第一 POD和第二 POD分享了同一套 IP地址： 第 一 IP地址和第二 IP地址。
根据本发明的多租户网络系统的一实施例， 该多个数据中心租户是通过建 立管道的方式在系统中运行多租户方式的。
根据本发明的多租户网络系统的一实施例， 建立管道的方式既适用于无外 接存储的环境， 也适用于有外接存储的环境。
根据本发明的多租户网络系统的一实施例， 系统包括第一虚拟机、 第二虚 拟机、 第三虚拟机和第四虚拟机， 其中第一虚拟机和第四虚拟机同属于第一 P0D， 由第一部门占用， 第二虚拟机和第三虚拟机同属于第二 P0D， 由第二部门 占用， 第一虚拟机和第二虚拟机均使用第一 IP地址， 同在第一宿主机上， 第三 虚拟机和第四虚拟机均使用第二 IP地址， 同在第二宿主机上， 第一三层交换机 和第四三层交换机为第一虚拟机和第四虚拟机之间的通讯建立了第一管道， 第 二三层交换机和第三三层交换机为第二虚拟机和第三虚拟机之间的通讯建立 了第二管道， 利用管道上的第一三层交换机和第二三层交换机的 IP地址不同以 及第三三层交换机和第四三层交换机的 IP地址不同， 在第一三层交换机、 第二 三层交换机、 第三三层交换机和第四三层交换机之间通过路由器进行通讯， 分 属于第一部门和第二部门的第一 POD和第二 POD分享了同一套 IP地址： 第一 IP地 址和第二 IP地址。
根据本发明的多租户网络系统的一实施例， 在第一 POD和第二 POD中运行的 应用系统实例是分开的， 用虚拟机来实现三层的路由功能， 用以在 VLAN之间转 发数据包， 第一 POD和第二 POD内的数据包不会在任何点上相遇并冲突。 本发明对比现有技术有如下的有益效果： 本发明的方案是采用虚拟路由或 者建立管道 （Tunnel ) 的方式实现多租户网络系统， 前者较为简单， 适用于无 外接存储的情况， 后者较为复杂， 但对于有无外接存储的情况都能适用。 这两 种方式均有下列共同点： 1 ) 在两个 POD中运行的应用系统实例 （instance ) 是 分开的； 2 ) 用虚拟机 （VM) 来实现三层的路由功能， 用以在 VLAN间转发数据 包； 3 ) 两个 POD内的数据包不会在任何点上相遇并冲突； 4 ) 由虚拟机实现的 路由器性能上较硬件低但更加经济灵活。 附图说明
图 1示出了单租户 POD只能够运行一个应用程序的实例。
图 2示出了本发明的通过虚拟路由方式让多租户 POD能够运行一个应用程 序的多个实例。
图 3示出了通过虚拟路由方式实现多租户 POD的具体实施图。
图 4示出了本发明的通过建立管道的方式让多租户 POD能够运行一个应用 程序的多个实例。
图 5示出了通过虚拟路由方式实现多租户 POD的实现过程。 发明的详细说明 下面结合附图和实施例对本发明作进一步的描述。 多租户的计算模式是云计算技术架构中面向服务的最为典型的应用模式。 它要求服务器计算环境， 存储资源及其网络资源的设计和部署必须满足虚拟服 务器之间的隔离、 确保每个租户不同的服务质量、 和能够实现租户跨广域网或 城域网的互联互通等需求。 以下我们重点对多租户环境下网络需要满足上文中 提到的特殊需求， 即 Multi-tenant POD问题的解决方案予以以阐述。
多租户的网络需要支持完全相同的两 （多） 个逻辑 POD时解决 IP地址的 冲突问题的两种方法。 第一种是虚拟路由方式， 较为简单， 适用于无外接存储 的情况。 第二种是建立管道 （Tunnel) 方式， 较为复杂， 但对于有无外接存储 的情况均能适用。 请参见图 2， 图 2示出了本发明的通过虚拟路由方式让多租户 POD能够运 行一个应用程序的多个实例。 图 2中的虚拟机 VM 2001、 2002、 2003、 2004、 2005和 2006 即为图 1中的 VM 1001、 1002、 1003、 1004、 1005和 1006。 虚 拟机 VM 2002和虚拟机 VM 2003所使用的 IP地址相同， 均为 1.0.0.0.2; 虚拟 机 VM 2004和虚拟机 VM 2006所使用的 IP地址相同， 均为 1.0.0.1.2。 在本实 施例中可采用虚拟路由， 即用两个虚拟路由 2021a和 2021b来替代原来一个物 理路由 1021的简单方法来解决 IP地址的冲突问题。 这样， 当虚拟机 VM 2002 和 VM 2006部署完成后， 它们可以通过路由器 2021a来进行通讯， 其对应的网 关地址分别为： 1.0.0.0.1和 1.0.0.1.1。 当虚拟机 VM 2003和 VM 2004部署完成 后， 它们可以通过路由器 1021b来进行通讯， 其对应的网关地址也同样为： 1.0.0.0.1禾卩 1.0.0.1.1。 至此， 两个 POD分享了同一套 IP地址， 即: 1.0.0.0.2禾口 1.0.0.1.2。 请参见图 3，它是图 2所描述方案的具体实施图。图 3中的虚拟机 VM 3002、 3003、 3004和 3006 即为图 2中的 VM 2002、 2003、 2004和 2006。 虚拟机 VM 3002和 VM 3006同属于一个 POD, 由开发部门占用； 虚拟机 VM 3003和 VM 3004同属于另一个 POD，由测试部门使用。虚拟机 VM 3002和虚拟机 VM 3003 所使用的 IP地址相同，均为 1.0.0.0.2，它们在同一个宿主机（Host) 3051上； 虚 拟机 VM 3004和虚拟机 VM 3006所使用的 IP地址相同， 均为 1.0.0.1.2， 它们 在同一个宿主机 （Host) 3052上。 图 3中的两个 POD分享了同一套 IP地址： 1.0.0.0.2和 1.0.0.1.2。
图 3中的虚拟交换机 301 1代替了图 2中虚拟交换机 201 1和 2012的作用； 虚拟交换机 3013代替了图 2中虚拟交换机 2013和 2014的作用。 图 3中的 3 层路由器 （vRouter) 3021 a和 3021b实现了图 2中虚拟路由 2021 a和 2021b 的功能。 3021a和 3021b事实上由两个虚拟机 （VM ) 来实现的， 因此它们需要 Hypervisor的支持。
图 3中的二层交换机 3015代表了图 2中可省略的二层交换机 2015， 它可 以是物理的， 也可以是虚拟的。 二层交换机 3015的作用在于增加了图 2所描 述方案的灵活性， 例如： 在虚拟机 VM 3002和 VM 3006同属于一个 VLAN的 情况下， 从 VM 3002发往 VM 3006的数据包不必经过 3层路由器 3021a， 而是 直接由二层交换机 3015转发； 从 VM 3006发往 VM 3002的数据包亦然。 这样 可以大大加快 VM 3002和 VM 3006之间数据包的传输速度。
请参见图 5， 图 5示出了通过虚拟路由方法实现多租户 POD的实现过程。 虚拟路由的方法的实现过程步骤如下：
步骤 1) ： 首先设计一个应用 APP， 这个 APP需要两台服务器（A和 B ) ； 指定 A 的 IP为 " 100.0.0.100 " ， Gateway为 " 100.0.0.1 " ； 指定 B 的 IP为 " 200.0.0.100 " ， Gateway为 " 200.0.0.1 " ；
步骤 2) : 部署应用 APP—次， 到虚拟机 VM 5002和 VM 5006， 即为 APP 实例 INSTANCE 1。
步骤 3):启动 APP INSTANCE 1 , INSTANCE 1所在 VM 5002选择 VLAN100 进行通信， VM 5006选择 VLAN200进行通信，它们需在 2层交换机上触发"交 换服务"程序为其分配 VLAN100和 200， 在虚拟路由服务器中触发 "多房客 服务" 为这个实例创建出一个虚拟路由。
假定该虚拟路由命名为 vGatewayl , vGatewayl包括两个端口， 分别属于 VLAN 100和 200， 并指定 VLAN100的 IP为 " 100.0.0.1 " ， VLAN200的 IP为 " 200.0.0.1 " ， 如此 INSTANCE1 部署完成。 步骤 4): 再部署应用 APP—次， 到虚拟机 VM 5003和 VM 5004， 即为 APP 实例 INSTANCE2o
步骤 5):启动 APP INSTANCE2, INSTANCE2所在 VM 5003选择 VLAN300 进行通信， VM 5004选择 VLAN400进行通信，它们需在 2层交换机上触发"交 换服务"程序为其分配 VLAN300和 400， 在虚拟路由服务器中触发 "多房客 服务" 为这个实例创建出一个虚拟路由。
假定该虚拟路由命名为 vGateway2， vGateway2包括两个端口， 分别属于 VLAN 300和 400， 并指定 VLAN300的 IP为 " 100.0.0.1 " ， VLAN400的 IP为 "200.0.0.1 " ， 如此 INSTANCE2 部署完成。
该实施例有以下特点：
1.在两个 POD中运行的应用系统实例 （instance ) 在物理上是分开的。
2.用虚拟机（VM)来实现三层的路由功能， 用以在 VLAN间转发数据包。
3.两个 POD内的数据包不会再任何点上相遇并冲突。
4. 由虚拟机实现的路由器性能上较硬件低但更加经济灵活。
上述解决方案简洁明了。 它还可满足： 1) 多租户网络必须满足虚拟服务器 之间的隔离需求 2) 多租户的网络必须确保每个租户不同的服务质量这两个基 本要求。
虽然上述解决方案简洁明了， 但存在另外一个问题： 两个 POD无法同时 共享一套外接存储设备， 即图 2中的光纤交换机 /开关矩阵 2031和 FC SAN 磁 盘阵列 2041。 因此该种解决方案仅适用于无外接存储的情况， 虚拟机只能使用 与它们的宿主机 （Host) 相连接的本地存储磁盘。 本发明的第二种建立管道 （Tunnel) 的方法， 对于有无外接存储的情况均 能适用。 请参见图 4。 图 4中的虚拟机 VM 4001、 4002、 4003、 4004、 4005和 4006 即为图 1中的 VM 1001、 1002、 1003、 1004、 1005和 1006。虚拟机 VM 4002 和虚拟机 VM 4003所使用的 IP地址相同， 均为 1.0.0.0.2; 虚拟机 VM 4004和 虚拟机 VM 4006所使用的 IP地址相同， 均为 1.0.0.1.2。在本实施例中可采用虚 拟网关 vGateway代替虚拟交换机 vSwitch的方法，即用三层交换机 4011、4012、 4013和 4014来替代原来的虚拟交换机 1011、 1012、 1013和 1014的方法来解 决 IP地址的冲突问题。
请参见图 4， 虚拟机 VM 4002可以通过虚拟网关 401 1来和外部进行通讯， 其对应 VLAN的网关地址为： 1.0.0.0.1， 对外的网关地址为： 100.0.0.10; 虚拟 机 VM 4003可以通过虚拟网关 4012来和外部进行通讯， 其对应 VLAN的网关 地址为： 1.0.0.0.1， 对外的网关地址为： 100.0.1.10; 虚拟机 VM 4004可以通过 虚拟网关 4013来和外部进行通讯， 其对应 VLAN的网关地址为： 1.0.0.1.1， 对 外的网关地址为： 100.0.2.10; 虚拟机 VM 4006可以通过虚拟网关 4014来和外 部进行通讯， 其对应 VLAN的网关地址为： 1.0.0.1.1， 对外的网关地址为： 100.0.3.10。
请参见图 4， 尽管虚拟机 VM 4002和虚拟机 VM 4003所使用的 IP地址相 同， 均为 1.0.0.0.2， 从而可能形成如图 1所示的 IP地址冲突问题。 图 4中的三 层交换机 4011、4012将虚拟机 VM 4002和 VM 4003所在两个 VLAN相同的网 关地址 1.0.0.0.1分别转换为不同的对外的网关地址 100.0.0.10和 100.0.1.10；同 样地， 三层交换机 4013、 4014将虚拟机 VM 4004和 VM 4006所在两个 VLAN 相同的网关地址 1.0.0.1.1分别转换为不同的对外的网关地址 100.0.2.10和
100.0.3.10。 这样， 从路由器 4021来看， 四个网关地址 100.0.0.10、 100.0.1.10、 100.0.2.10和 100.0.3.10是各不相同的， 因此在路由器上不会发生冲突。
请参见图 4， 上述解决方案的实质是， 三层交换机 4011、 4014为虚拟机 VM 4002和 VM 4006之间的通讯建立了一个管道 （Tunnel) ， 类似地， 三层交 换机 4012、4013为虚拟机 VM 4003和 VM 4004之间的通讯建立了另一个管道。 这样， 如果是虚拟机 VM 4002和 VM 4006同属于一个 POD， 由开发部门占用； 而虚拟机 VM 4003和 VM 4004同属于另一个 POD， 由测试部门使用， 它们均 可以通过路由器 4021来进行通讯。至此，两个 POD分享了同一套 IP地址，即： 1.0.0.0.2和 1.0.0.1.2。 请继续参见图 4， 即建立管道 （Tunnel) 的方法实现多租户 POD的实现过 程。 建立管道并进行通信的步骤如下， 其具体过程较为复杂：
假如虚拟机 VM 4003想访问虚拟机 VM 4004， 首先虚拟机 VM 4003会将 自己的 IP地址和子网掩码做与操作，得出网路地址 (如： 虚拟机 VM 4003的 IP 地址 10.0.0.2与自身掩码 255.255.255.0做与操作后，得到的网络号是 10.0.0.0). 然后判断目的 IP地址 (即虚拟机 VM 4004的 IP地址)与自己的网络地址是不是 在同一个子网.因为图中虚拟机 VM 4003和 VM 4004不在同一子网内，所以需要 进行三层转发.
步骤 1 ) ： 虚拟机 VM 4003发送 ARP广播获取网关 MAC地址
虚拟机 VM 4003想访问虚拟机 VM 4004首先要有虚拟机 VM 4004的 MAC 地址， 由于虚拟机 VM 4003和 VM 4004不在同一子网， 所以虚拟机 VM 4003 首先会向缺省网关发送 ARP广播报文来获取网关的 MAC地址。
步骤 2 ) ： 三层交换机 4012形成虚拟机 VM 4003的 MAC表项， 并用网 关 MAC地址回应虚拟机 VM 4003的 ARP 请求
三层交换机 4012收到 ARP广播报文后，首先学习 ARP报文 Ethernet头部 的源 MAC地址， 交换机芯片将自动记录虚拟机 VM 4003的 MAC地址
(00e0-d26b-8121)、 接收该 ARP报文的交换机 4012接口号 (E1/0/0)及此接口所 属的 VLAN(VLAN 200)等信息，并形成一条 MAC表项放入交换机 4012的 MAC 表中.同时， 三层交换机 4012也会通过软件把虚拟机 VM 4003的 IP、 MAC, 上连到交换机 4012的接口等信息保存到交换机 4012的 ARP表里 （三层表项， MAC表是没有 IP的） 。
由于虚拟机 VM 4003发送的 ARP广播报文中的目的 IP地址（10.0.0.1)就是 交换机上接收该 ARP广播报文的接口（E1/0/0)所属 VLAN(VLAN 100)的 IP地 址， 所以交换机将使用 VLAN 100的 MAC地址回复虚拟机 VM 4003的 ARP 请求。
步骤 3 ) ： 虚拟机 VM 4003用网关 MAC发给网关
虚拟机 VM 4003收到网关的 ARP回应报文后， 会把数据帧发给网关， 这 样虚拟机 VM 4003发送数据给虚拟机 VM 4004时就会使用网关 MAC作为目的 MAC来封装数据帧。
步骤 4 ) ： 三层交换机 4012查找硬件转发表 /路由表进行三层转发 三层交换机 4012收到虚拟机 VM 4003发来的数据报文后， 仍然会首先学 习数据报文 Ethernet头部的源 MAC地址， 然后根据 Ethernet头部的目的 MAC 查找交换机的 MAC表，此时发现目的 MAC地址就是本地 VLAN的 MAC地址， 这种情况下交换机会把该报文上送到交换芯片的三层引擎处理。 三层引擎将首 先查找硬件转发表。
(1) 如果硬件转发表中有匹配项， 则根据报文目的 IP地址作相应处理： ①、 目的 IP地址就是本地的 IP地址， 则交相应模块处理。
②、 目的 IP是其他设备 IP地址，本地只是转发， 则根据硬件转发表项使用 出接口 MAC替换报文的源 MAC地址， 用下一跳 MAC替换报文的目的 MAC 地址， 同时 TTL值减 1， 继续转发。 （此处与二层的区别在于需要对报文进行 源、 目的 MAC进行替换）
(2) 如果不匹配则查找路由表， 有匹配项则按照上面 （2 ) 中的操作进行， 同时把相应的目的 IP、 下一跳 MAC：、 出接口等信息存储到硬件转发表项中， 下次就不需要查路由表了， 这就是所谓的一次路由多次交换。
(3) 如果路由表也没有匹配项， 则丢弃报文。
此处，由于虚拟机 VM 4003数据报文的目的 IP是虚拟机 VM 4004的地址， 三层交换机 4012的硬件转发表 /路由表已经有虚拟机 VM 4004的路由表项， 所 以交换机将虚拟机 VM 4003发来的报文中的源、 目的 MAC地址作替换， 同时
TTL值减 1， 然后发给三层交换机 4013。
步骤 5 ) ： 三层交换机 4012和 4013之间采用三层隧道协议 IPsec 常见的第三层隧道协议有： GRE、 IPsec和 MPLS。 IPSec是因特网工程任 务组 （IETF ) 定义的一种协议套件， 由一系列协议组成： 认证头 （AH ) 、 封 装安全载荷（ESP)、 Internet安全关联（SA )和密钥管理协议 ISAKMP的 Internet
IP安全解释域 （DOI ) 、 ISAKMP , Internet密钥管理协议 （IKE ) 、 OAKLEY 密钥确定协议等。
IPSEC 的隧道模式， 顾名思能义是双层 IP 地址的应用类型， 即外层 IP地 址用于路由转发， 内层 IP 报文是真正的用户数据报文。 当客户端需要发出加 密数据时：
(1) 首先生成需要加密的数据，其中 Inner IP 是指 VM4003的内部逻辑 IP : 10.0.0.2， 即用于与对端 VM2004交互的 IP (注： 如对端在 VLAN内部， 则不 需要具有 IPSec 功能） ；
(2)使用外部 IP 地址： 100.0.1.10进行封装， 同时加上 ESP 头对第一步生 成的数据进行加密
(3)网络对加密数据报文进行转发， 由 IP : 100.0.1.10转发 IP : 100.0. 1.1， 再经路由器 4021转换成 IP : 100.0.2.1， 继续转发到目的地址 IP : 100.0.2.10 , 即三层交换机 4013 ;
(4)安全网关收到数据后， 对报文 "剔除"外层 IP 头以及 ESP 头， 对加密 数据进行解密后恢复原始数据；
(5)三层交换机 4013将网络原始数据报文进行转发， 转发的依据是内层 IP 目的地址即 VM4004的 IP : 10.0.1.2。
步骤 6 ) ： 三层交换机 4013查找硬件转发表 /路由表进行三层转发 三层引擎查找硬件转发表过程类似于步骤 4 ) ， 故不赘述。 此处， 由于 虚拟机 VM 4003数据报文的目的 IP是虚拟机 VM 4004的地址， 并且虚拟机 VM 4004和三层交换机 4013直连，交换机 4013的硬件转发表 /路由表已经有虚 拟机 VM 4004的路由表项， 所以交换机 4013将虚拟机 VM 4003发来的报文中 的源、 目的 MAC地址作替换， 同时 TTL值减 1， 然后发给虚拟机 VM 4004。
这样虚拟机 VM 4003就把数据报文发到了不同网段的虚拟机 VM 4004。同 时交换机上也保存了关于虚拟机 VM 4003和虚拟机 VM 4004的硬件转发表项， 以后虚拟机 VM 4003和虚拟机 VM 4004互访， 以及其他网段主机访问虚拟机 VM 4003或 VM 4004三层交换机 4012和 4013就可以根据硬件转发表项直接转 发， 而不需要查找路由表。 上述实施例是提供给本领域普通技术人员来实现和使用本发明的， 本领域 普通技术人员可在不脱离本发明的发明思想的情况下， 对上述实施例做出种种 修改或变化， 因而本发明的保护范围并不被上述实施例所限， 而应该是符合权 利要求书所提到的创新性特征的最大范围。

Claims

权 利 要 求 书
1、 一种多租户网络系统， 包括多个数据中心租户， 该多个数据中心租户 各自包括一逻辑 POD， 该系统内设有一物理 POD， 该多个数据中心租户自身的 逻辑 POD在私有云数据中心内分享同一个物理 POD, 并运行各自的系统实例 的多租户方式， 其中物理 POD 是在数据中心网络中经过定义和划分设备集合 所构成的资源供应物理单元， 可不依赖于其它设备而独立工作， 最终形成 POD 资源服务单元， 逻辑 POD 是按照用户所定规格订阅的用户业务项目所需的计 算、 网络、存储逻辑资源的组合， 其中的资源具有共享空间或共享时间的特性， 该多个数据中心租户的 POD的网络分享同一套 IP地址。
2、 根据权利要求 1 所述的多租户网络系统， 其特征在于， 该多个数据中 心租户是通过虚拟路由的方式在系统中运行多租户方式的。
3、 根据权利要求 2 所述的多租户网络系统， 其特征在于， 虚拟路由的方 式适用于无外界存储的环境。
4、 根据权利要求 2 所述的多租户网络系统， 其特征在于， 系统包括第一 虚拟机、 第二虚拟机、 第三虚拟机和第四虚拟机， 其中第一虚拟机和第四虚拟 机同属于第一 POD， 由第一部门占用， 第二虚拟机和第三虚拟机同属于第二 POD, 由第二部门占用， 第一虚拟机和第二虚拟机均使用第一 IP地址， 同在第 一宿主机上，第三虚拟机和第四虚拟机均使用第二 IP地址，同在第二宿主机上， 使用第一虚拟路由和第二虚拟路由以避免 IP地址冲突，其中第一虚拟机和第四 虚拟机通过第一虚拟路由交换数据包， 第二虚拟机和第三虚拟机通过第二虚拟 路由交换数据包， 分属于第一部门和第二部门的第一 POD和第二 POD分享了 同一套 IP地址： 第一 IP地址和第二 IP地址。
5、 根据权利要求 1 所述的多租户网络系统， 其特征在于， 该多个数据中 心租户是通过建立管道的方式在系统中运行多租户方式的。
6、 根据权利要求 5 所述的多租户网络系统， 其特征在于， 建立管道的方 式既适用于无外接存储的环境， 也适用于有外接存储的环境。
7、 根据权利要求 5 所述的多租户网络系统， 其特征在于， 系统包括第一 虚拟机、 第二虚拟机、 第三虚拟机和第四虚拟机， 其中第一虚拟机和第四虚拟 机同属于第一 POD， 由第一部门占用， 第二虚拟机和第三虚拟机同属于第二 POD, 由第二部门占用， 第一虚拟机和第二虚拟机均使用第一 IP地址， 同在第 一宿主机上，第三虚拟机和第四虚拟机均使用第二 IP地址，同在第二宿主机上， 第一三层交换机和第四三层交换机为第一虚拟机和第四虚拟机之间的通讯建 立了第一管道， 第二三层交换机和第三三层交换机为第二虚拟机和第三虚拟机 之间的通讯建立了第二管道， 利用管道上的第一三层交换机和第二三层交换机 的 IP地址不同以及第三三层交换机和第四三层交换机的 IP地址不同， 在第一 三层交换机、 第二三层交换机、 第三三层交换机和第四三层交换机之间通过路 由器进行通讯， 分属于第一部门和第二部门的第一 POD和第二 POD分享了同 一套 IP地址： 第一 IP地址和第二 IP地址。
8、根据权利要求 4或 7所述的多租户网络系统，其特征在于，在第一 POD 和第二 POD 中运行的应用系统实例是分开的， 用虚拟机来实现三层的路由功 能， 用以在 VLAN之间转发数据包， 第一 POD和第二 POD内的数据包不会在 任何点上相遇并冲突。
PCT/CN2013/076067 2013-05-22 2013-05-22 多租户网络系统 WO2014186957A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2013/076067 WO2014186957A1 (zh) 2013-05-22 2013-05-22 多租户网络系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2013/076067 WO2014186957A1 (zh) 2013-05-22 2013-05-22 多租户网络系统

Publications (1)

Publication Number Publication Date
WO2014186957A1 true WO2014186957A1 (zh) 2014-11-27

Family

ID=51932715

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2013/076067 WO2014186957A1 (zh) 2013-05-22 2013-05-22 多租户网络系统

Country Status (1)

Country Link
WO (1) WO2014186957A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110611697A (zh) * 2019-08-02 2019-12-24 杭州网银互联科技股份有限公司 一种混合云的网络架构及网络部署方法
US11005810B2 (en) 2019-08-29 2021-05-11 International Business Machines Corporation Multi-tenant environment with overlapping address space
CN114679370A (zh) * 2021-05-20 2022-06-28 腾讯云计算（北京）有限责任公司 一种服务器托管方法、装置、系统及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102651775A (zh) * 2012-03-05 2012-08-29 国家超级计算深圳中心(深圳云计算中心) 基于云计算的多租户共享对象管理的方法、设备及系统
CN102857363A (zh) * 2012-05-04 2013-01-02 运软网络科技(上海)有限公司 一种虚拟网络的自主管理系统和方法
CN103080926A (zh) * 2010-03-04 2013-05-01 磁体系统公司 多租户环境中的个人和社会信息的可移植性

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103080926A (zh) * 2010-03-04 2013-05-01 磁体系统公司 多租户环境中的个人和社会信息的可移植性
CN102651775A (zh) * 2012-03-05 2012-08-29 国家超级计算深圳中心(深圳云计算中心) 基于云计算的多租户共享对象管理的方法、设备及系统
CN102857363A (zh) * 2012-05-04 2013-01-02 运软网络科技(上海)有限公司 一种虚拟网络的自主管理系统和方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110611697A (zh) * 2019-08-02 2019-12-24 杭州网银互联科技股份有限公司 一种混合云的网络架构及网络部署方法
US11005810B2 (en) 2019-08-29 2021-05-11 International Business Machines Corporation Multi-tenant environment with overlapping address space
CN114679370A (zh) * 2021-05-20 2022-06-28 腾讯云计算（北京）有限责任公司 一种服务器托管方法、装置、系统及存储介质
CN114679370B (zh) * 2021-05-20 2024-01-12 腾讯云计算（北京）有限责任公司 一种服务器托管方法、装置、系统及存储介质

Similar Documents

Publication Publication Date Title
Del Piccolo et al. A survey of network isolation solutions for multi-tenant data centers
US11063819B2 (en) Managing use of alternative intermediate destination computing nodes for provided computer networks
US10116559B2 (en) Operations, administration and management (OAM) in overlay data center environments
US10567198B2 (en) Method and apparatus for implementing a flexible virtual local area network
US9491002B1 (en) Managing communications involving external nodes of provided computer networks
US8948181B2 (en) System and method for optimizing next-hop table space in a dual-homed network environment
KR101371993B1 (ko) 가상화 네트워크 인프라구조를 갖는 투명 클라우드 컴퓨팅을 위한 방법 및 장치
CN116210204A (zh) 用于vlan交换和路由服务的系统和方法
US20150124823A1 (en) Tenant dhcp in an overlay network
JP2024503321A (ja) 仮想化されたクラウド環境におけるレイヤ２ネットワークのインターネットグループ管理プロトコル（ｉｇｍｐ）
CN108199963B (zh) 报文转发方法和装置
WO2013155943A1 (zh) 一种虚拟网络实现方法及系统
WO2015192563A1 (zh) 一种实现负载均衡的方法、装置及负载均衡服务系统
WO2017071328A1 (zh) 一种负载分担方法以及相关装置
JP2024507143A (ja) オーバーレイネットワークにおけるｉｐアドレスのスケーリング
WO2008037210A1 (fr) Procédé et dispositif servant à transférer un message dans un réseau local privé virtuel
WO2014186957A1 (zh) 多租户网络系统
JP2024503322A (ja) 仮想化されたクラウド環境におけるレイヤ２ネットワーキングストーム制御
CN113545130B (zh) 利用分布式散列的无线客户端的快速漫游和统一策略
JP2024503318A (ja) 仮想化されたクラウド環境においてアクセス制御リストを使用するレイヤ２ネットワーキング
Tu Cloud-scale data center network architecture
KR20150006575A (ko) 클라우드 다이렉트 연결 시스템

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: 13885212

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13885212

Country of ref document: EP

Kind code of ref document: A1