Central namespace controller for multi-tenant cloud environments

A centralized namespace controller allocates addresses in a distributed cloud infrastructure on-demand. Upon receiving a request to allocate addresses for a network to be provisioned by a cloud computing system included in the distributed cloud infrastructure, the centralized namespace controller allocates a network address that is unique within the distributed cloud infrastructure. Further, the centralized namespace controller allocates a range of virtual network interface cards (NIC) addresses that are unique within the network. The centralized namespace controller then allocates addresses from the range of virtual NIC addresses on an as-requested basis—when a virtual NIC is being created by the first cloud computing system on the network. Advantageously, by centralizing the allocation of addresses and dedicating independent NIC address ranges to different cloud computing systems, the centralized namespace controller enables stretched L2 networks between cloud computing systems while preventing duplicated addresses on the stretched networks.

BACKGROUND

Cloud architectures are used in cloud computing and cloud storage systems for offering infrastructure-as-a-service (IaaS) cloud services. Examples of cloud architectures include the VMware vCloud™ Director cloud architecture software, Amazon EC2™ web service, and OpenStack™ open source cloud computing service. IaaS cloud service is a type of cloud service that provides access to physical and/or virtual resources in a cloud environment. These services provide a tenant application programming interface (API) that supports operations for manipulating IaaS constructs such as virtual machines (VMs) and logical networks. However, the use of such public cloud services is typically kept separate from the use of existing computing resources in data centers managed by an enterprise (i.e., private data centers).

By contrast, in “hybrid” cloud computing systems, public cloud services and existing computing resources in private data centers are combined. Further, a public cloud service may model support for multiple tenants with private data centers as a hub-and-spoke. In such a model, the public cloud service strives to integrate each independent tenant (spoke) seamlessly into the public cloud environment (hub), while maintaining “secure separation” between tenants. More specifically for each tenant, the pubic cloud environment provides access to tenant-assigned resources (e.g., virtual machines (VMs), network bandwidth, and storage) and prevents access to resources assigned to other tenants. In an attempt to provide comprehensive secure separation, the public cloud environment may employ a variety of techniques, such as access control, virtual local area network (VLAN) segmentation, and virtual storage controllers.

While conventional secure separation techniques may enable adequate separation of tenants, such techniques do not necessarily alleviate addressing conflicts due to the merging of multiple, potentially overlapping namespaces. Notably, unlike physical NICs which are assigned unique MAC addresses when the NIC is manufactured, each tenant may assign MAC addresses to virtual NICs in any technically feasible fashion. Further, to provide seamless integration between each tenant and the public cloud environment, particularly across Level 2 networks, it is desirable to preserve the MAC address when migrating a VM from the tenant data center to the public cloud environment. In a multi-tenant hybrid cloud system, maintaining MAC consistency across the tenants may cause duplicate MAC addresses to existing in the public cloud environments. For example, if a tenant “A” were to migrate a VM with MAC address “X” to the public cloud environment and then tenant “B” were to migrate a different VM with the same MAC address “X” to the public cloud, then two different VMs with the same MAC addresses would be created in the public cloud environment. If allowed to interact within the public cloud environment, VMs with duplicate MAC addresses can lead to a variety of undesirable behavior, such as destination host unreachable errors attributable to MAC address collisions between tenants. Consequently, there is a need for more effective address management techniques that ensure seamless integration without provoking addressing conflicts.

SUMMARY

One or more embodiments of the invention provide techniques for flexibly managing addresses across hybrid clouds. These techniques facilitate seamless integration of multiple private tenant data centers with a public cloud and/or seamless integration of multiple public clouds into a distributed cloud infrastructure, without provoking addressing conflicts attributable to the integration(s).

A method of supporting independent addressing for multiple tenants in a cloud computing system includes the steps of for each tenant, configuring a private network between the tenant and the cloud computing system, where the private network is managed by a tenant-facing cloud gateway; configuring the tenant-facing cloud gateways to preserve the source addresses of packets originating from the cloud computing system; and configuring a multi-tenant cloud gateway to a public network to translate the source addresses of packets originating from the cloud computing system to addresses that are unique within the public network.

A method of allocating addresses on-demand in a distributed cloud infrastructure includes the steps of receiving a request to allocate addresses for a network to be provisioned by a cloud computing system and, in response, allocating a network address and a virtual network interface card (NIC) address range, where the network address is unique within a distributed cloud namespace and the addresses in the virtual NIC address range are unique within the network; and receiving a request to allocate an address for a virtual NIC to be created by the cloud computing system on the network and, in response, allocating a first virtual NIC address, where the first virtual NIC address is within the first virtual NIC address range and is unique within the first network.

Further embodiments of the present invention include a non-transitory computer-readable storage medium comprising instructions that cause a hybrid cloud computing system to carry out one or more of the above methods as well as a distributed cloud infrastructure configured to carry out one or more of the above methods.

DETAILED DESCRIPTION

FIG. 1is a block diagram of a hybrid cloud computing system100in which one or more embodiments of the present disclosure may be utilized. Hybrid cloud computing system100includes a virtualized computing system102and a cloud computing system150, and is configured to provide a common platform for managing and executing virtual workloads seamlessly between virtualized computing system102and cloud computing system150. In one embodiment, virtualized computing system102may be a data center controlled and administrated by a particular enterprise or business organization, while cloud computing system150is operated by a cloud computing service provider and exposed as a service available to account holders, such as the particular enterprise in addition to other enterprises. As such, virtualized computing system102may sometimes be referred to as an on-premise data center(s), and cloud computing system150may be referred to as a “public” cloud service. In some embodiments, virtualized computing system102itself may be configured as a private cloud service provided by the enterprise.

As used herein, an internal cloud or “private” cloud is a cloud in which a tenant and a cloud service provider are part of the same organization, while an external or “public” cloud is a cloud that is provided by an organization that is separate from a tenant that accesses the external cloud. For example, the tenant may be part of an enterprise, and the external cloud may be part of a cloud service provider that is separate from the enterprise of the tenant and that provides cloud services to different enterprises and/or individuals. In embodiments disclosed herein, a hybrid cloud is a cloud architecture in which a tenant is provided with seamless access to both private cloud resources and public cloud resources.

Virtualized computing system102includes one or more host computer systems104. Hosts104may be constructed on a server grade hardware platform106, such as an x86architecture platform, a desktop, and a laptop. As shown, hardware platform106of each host104may include conventional components of a computing device, such as one or more processors (CPUs)108, system memory110, a network interface112, storage114, and other I/O devices such as, for example, a mouse and keyboard (not shown). Processor108is configured to execute instructions, for example, executable instructions that perform one or more operations described herein and may be stored in memory110and in local storage. Memory110is a device allowing information, such as executable instructions, cryptographic keys, virtual disks, configurations, and other data, to be stored and retrieved. Memory110may include, for example, one or more random access memory (RAM) modules. Network interface112enables host104to communicate with another device via a communication medium, such as a network122within virtualized computing system102. Network interface112may be one or more network adapters, also referred to as a Network Interface Card (NIC). Storage114represents local storage devices (e.g., one or more hard disks, flash memory modules, solid state disks, and optical disks) and/or a storage interface that enables host104to communicate with one or more network data storage systems. Examples of a storage interface are a host bus adapter (HBA) that couples host104to one or more storage arrays, such as a storage area network (SAN) or a network-attached storage (NAS), as well as other network data storage systems.

Each host104is configured to provide a virtualization layer that abstracts processor, memory, storage, and networking resources of hardware platform106into multiple virtual machines120Ito120N(collectively referred to as VMs120) that run concurrently on the same hosts. VMs120run on top of a software interface layer, referred to herein as a hypervisor116, that enables sharing of the hardware resources of host104by VMs120. One example of hypervisor116that may be used in an embodiment described herein is a VMware ESXi hypervisor provided as part of the VMware vSphere solution made commercially available from VMware, Inc. Hypervisor116may run on top of the operating system of host104or directly on hardware components of host104.

Virtualized computing system102includes a virtualization management module (depicted inFIG. 1as virtualization manager130) that may communicate to the plurality of hosts104via a network, sometimes referred to as a management network126. In one embodiment, virtualization manager130is a computer program that resides and executes in a central server, which may reside in virtualized computing system102, or alternatively, running as a VM in one of hosts104. One example of a virtualization management module is the vCenter® Server product made available from VMware, Inc. Virtualization manager130is configured to carry out administrative tasks for computing system102, including managing hosts104, managing VMs120running within each host104, provisioning VMs, migrating VMs from one host to another host, and load balancing between hosts104.

In one embodiment, virtualization manager130includes a hybrid cloud management module (depicted as hybrid cloud manager132) configured to manage and integrate virtual computing resources provided by cloud computing system150with virtual computing resources of computing system102to form a unified “hybrid” computing platform. Hybrid cloud manager132is configured to deploy VMs in cloud computing system150, transfer VMs from virtualized computing system102to cloud computing system150, and perform other “cross-cloud” administrative task, as described in greater detail later. In one implementation, hybrid cloud manager132is a module or plug-in complement to virtualization manager130, although other implementations may be used, such as a separate computer program executing in a central server or running in a VM in one of hosts104.

In one embodiment, hybrid cloud manager132is configured to control network traffic into network122via a gateway component (depicted as a gateway124). Gateway124(e.g., executing as a virtual appliance) is configured to provide VMs120and other components in virtualized computing system102with connectivity to an external network140(e.g., Internet). Gateway124may manage external public IP addresses for VMs120and route traffic incoming to and outgoing from virtualized computing system102and provide networking services, such as firewalls, network address translation (NAT), dynamic host configuration protocol (DHCP), load balancing, and virtual private network (VPN) connectivity over a network140.

In one or more embodiments, cloud computing system150is configured to dynamically provide an enterprise (or users of an enterprise) with one or more virtual data centers180in which a user may provision VMs120, deploy multi-tier applications on VMs120, and/or execute workloads. Cloud computing system150includes an infrastructure platform154upon which a cloud computing environment170may be executed. In the particular embodiment ofFIG. 1, infrastructure platform154includes hardware resources160having computing resources (e.g., hosts162Ito162N), storage resources (e.g., one or more storage array systems, such as SAN164), and networking resources, which are configured in a manner to provide a virtualization environment156that supports the execution of a plurality of virtual machines172across hosts162. It is recognized that hardware resources160of cloud computing system150may in fact be distributed across multiple data centers in different locations.

Each cloud computing environment170is associated with a particular tenant of cloud computing system150, such as the enterprise providing virtualized computing system102. In one embodiment, cloud computing environment170may be configured as a dedicated cloud service for a single tenant comprised of dedicated hardware resources160(i.e., physically isolated from hardware resources used by other users of cloud computing system150). In other embodiments, cloud computing environment170may be configured as part of a multi-tenant cloud service with logically isolated virtual computing resources on a shared physical infrastructure. As shown inFIG. 1, cloud computing system150may support multiple cloud computing environments170, available to multiple enterprises in single-tenant and multi-tenant configurations.

In one embodiment, virtualization environment156includes an orchestration component158(e.g., implemented as a process running in a VM) that provides infrastructure resources to cloud computing environment170responsive to provisioning requests. For example, if enterprise required a specified number of virtual machines to deploy a web applications or to modify (e.g., scale) a currently running web application to support peak demands, orchestration component158can initiate and manage the instantiation of virtual machines (e.g., VMs172) on hosts162to support such requests. In one embodiment, orchestration component158instantiates virtual machines according to a requested template that defines one or more virtual machines having specified virtual computing resources (e.g., compute, networking, storage resources). Further, orchestration component158monitors the infrastructure resource consumption levels and requirements of cloud computing environment170and provides additional infrastructure resources to cloud computing environment170as needed or desired. In one example, similar to virtualized computing system102, virtualization environment156may be implemented by running on hosts162VMware ESX™-based hypervisor technologies provided by VMwarc, Inc. of Palo Alto, Calif. (although it should be recognized that any other virtualization technologies, including Xen® and Microsoft Hyper-V virtualization technologies may be utilized consistent with the teachings herein).

In one embodiment, cloud computing system150may include a cloud director152(e.g., run in one or more virtual machines) that manages allocation of virtual computing resources to an enterprise for deploying applications. Cloud director152may be accessible to users via a REST (Representational State Transfer) API (Application Programming Interface) or any other client-server communication protocol. Cloud director152may authenticate connection attempts from the enterprise using credentials issued by the cloud computing provider. Cloud director152maintains and publishes a catalog166of available virtual machine templates and packaged virtual machine applications that represent virtual machines that may be provisioned in cloud computing environment170. A virtual machine template is a virtual machine image that is loaded with a pre-installed guest operating system, applications, and data, and is typically used to repeatedly create a VM having the pre-defined configuration. A packaged virtual machine application is a logical container of pre-configured virtual machines having software components and parameters that define operational details of the packaged application. An example of a packaged VM application is vApp™ technology made available by VMware, Inc., of Palo Alto, Calif., although other technologies may be utilized. Cloud director152receives provisioning requests submitted (e.g., via REST API calls) and may propagates such requests to orchestration component158to instantiate the requested virtual machines (e.g., VMs172).

In the embodiment ofFIG. 1, cloud computing environment170supports the creation of a virtual data center180having a plurality of virtual machines172instantiated to, for example, host deployed multi-tier applications. A virtual data center180is a logical construct instantiated and managed by a tenant that provides compute, network, and storage resources to that tenant. Virtual data centers180provide an environment where VM172can be created, stored, and operated, enabling complete abstraction between the consumption of infrastructure service and underlying resources. VMs172may be configured similarly to VMs120, as abstractions of processor, memory, storage, and networking resources of hardware resources160.

Virtual data center180includes one or more virtual networks182used to communicate between VMs172and managed by at least one networking gateway component (e.g., cloud gateway184), as well as one or more isolated internal networks186not connected to cloud gateway184. Cloud gateway184(e.g., executing as a virtual appliance) is configured to provide VMs172and other components in cloud computing environment170with connectivity to external network140(e.g., Internet). Cloud gateway184manages external public IP addresses for virtual data center180and one or more private internal networks interconnecting VMs172. Cloud gateway184is configured to route traffic incoming to and outgoing from virtual data center180and provide networking services, such as firewalls, network address translation (NAT), dynamic host configuration protocol (DHCP), and load balancing. Cloud gateway184may be configured to provide virtual private network (VPN) connectivity over a network140with another VPN endpoint, such as a gateway124within virtualized computing system102. In other embodiments, cloud gateway184may be configured to connect to communicate with virtualized computing system102using a high-throughput, dedicated link (depicted as a direct connect142) between virtualized computing system102and cloud computing system150. In one or more embodiments, gateway124and cloud gateway184are configured to provide a “stretched” layer-2(L2) network that spans virtualized computing system102and virtual data center180, as shown inFIG. 1.

WhileFIG. 1depicts a single connection between on-premise gateway124and cloud-side gateway184for illustration purposes, it should be recognized that multiple connections between multiple on-premise gateways124and cloud-side gateways184may be used. Furthermore, whileFIG. 1depicts a single instance of a gateway184, it is recognized that gateway184may represent multiple gateway components within cloud computing system150. In some embodiments, a separate gateway184may be deployed for each virtual data center, or alternatively, for each tenant. In some embodiments, a gateway instance may be deployed that manages traffic with a specific tenant, while a separate gateway instance manages public-facing traffic to the Internet. In yet other embodiments, one or more gateway instances that are shared among all the tenants of cloud computing system150may be used to manage all public-facing traffic incoming and outgoing from cloud computing system150.

In one embodiment, each virtual data center180includes a “hybridity” director module (depicted as hybridity director174) configured to communicate with the corresponding hybrid cloud manager132in virtualized computing system102to enable a common virtualized computing platform between virtualized computing system102and cloud computing system150. Hybridity director174(e.g., executing as a virtual appliance) may communicate with hybrid cloud manager132using Internet-based traffic via a VPN tunnel established between gateways124and184, or alternatively, using direct connect142. In one embodiment, hybridity director174may control gateway184to control network traffic into virtual data center180. In some embodiments, hybridity director174may control VMs172and hosts162of cloud computing system150via infrastructure platform154.

Although not shown inFIG. 1, cloud computing system150may support multiple tenants. Accordingly, hybridity director174is configured to enable separate, tenant-specific virtualized computing platforms between each virtualized computing system102and cloud computing system150, while maintaining secure separation between tenants. Hybridity director174may employ any technically feasible security and separation measures to implement secure separation. For instance, in some embodiments, hybridity director174coordinates access control, virtual local area network (VLAN) segmentation, virtual extensible LAN (VXLAN) identifiers (VNIs) and encapsulation, and virtual storage controllers to enforce secure separation. As used herein, tenants may represent unique customers, independently maintained on-premises virtualized computing systems102that are associated with a single customer, or any combination thereof.

Managing Virtual MAC Addresses

For a given tenant, virtualization manager130performs on-premises management tasks to support virtualized computing system102internally, independently of virtualization managers130of other tenants. Such tasks may include provisioning VMs120, migrating VMs120between hosts104, and allocating physical resources, such as CPU108and memory110. Further, for each VM120, virtualization manager130assigns a MAC address for each virtual network interface controller (NIC) provisioned within VM120. Notably, unlike physical NICs112which are assigned unique MAC addresses120when the NIC112is manufactured, virtualization manager130may assign MAC addresses to virtual NICs in any technically feasible fashion.

Further, for a given tenant, hybrid cloud manager132performs cross-cloud management tasks, such as deploying VMs in cloud computing system150, and migrating VMs from virtualized computing system102to cloud computing system150. Such cross-cloud management tasks involve interaction with a corresponding hybrid cloud manager132of a given tenant, and therefore such operations are sometimes referred as “tenant-facing” operations. To provide seamless interaction between VMs120and VMs174, hybrid cloud manager132ensures that MAC addresses assigned by virtualization manager130are preserved during migration operations.

However, because each conventional MAC address is specified by a limited number of bits (typically 6 eight-bit octets for a total of 48 bits), and each virtualization manager130allocates MAC addresses in isolation. MAC addresses assigned by different virtualization managers130sometimes overlap. If allowed to interact with each other or co-exist in a common domain such as cloud computing environment170, duplicate MAC addresses can lead to undesirable behavior attributable to MAC address collisions between tenants. For this reason, cloud computing environment170is configured to operate with the tenant-assigned MACs for tenant-facing operations, and translate tenant-assigned MAC addresses to unique MAC addresses when accessing non-tenant specific data or a public network, such as the Internet.

FIGS. 2A and 2Bare conceptual block diagrams that illustrate the migration of virtual machines120from virtualized computing systems102to cloud computing environment170. Migrating VMs120in this fashion enables virtualized computing systems102to add capacity derived from cloud computing system150to the capacity of on-premise data centers. BothFIGS. 2A and 2Bdepict two independent virtualized computing systems1021and1022. For explanatory purposes only,FIG. 2Adepicts virtualized computing system102, prior to migrating VM1202to cloud computing environment170and virtualized computing system1022prior to migrating VM1203to cloud computing environment170.FIG. 2Bdepicts cloud computing environment170and virtualized computing systems1021and1022after migrating, respectively, VM1202and VM1203to cloud computing environment170.

Initially, virtualized computing system1021is running VM1201and VM1202on hosts104included in virtualized computing system1021. Independently, virtualized computing system1022is running VM1203and VM1204on hosts104included in virtualized computing system1022. As annotated inFIG. 2A, virtualization manager130has configured network settings of virtualized computing system1021such that a virtual network interface (vNIC) of VM1201has been assigned a MAC address “J,” VM1202has a MAC address “X,” and VM1201and VM1202communicate via L2private network1221. As also shown inFIG. 2A, a corresponding virtualization manager has configured network settings within virtualized computing system1022such that VM1203has a MAC address “X,” VM1204has a MAC address “N,” and VM1203and VM1204communicate via L2private network1222.

To enable seamless migration, hybridity director174configures cloud gateway1841to “stretch” L2private network1221from a tenant data center to the multi-tenant cloud site, i.e., span virtualized computing system102, and cloud computing environment170. In one implementation, hybridity director174may configure gateway1841to provide virtual private network (VPN) connectivity to gateway1241within virtualized computing system1021. Similarly, hybridity director174configures cloud gateway1842to provide virtual private network (VPN) connectivity to gateway1242within virtualized computing system1022, stretching L2private network1222to span virtualized computing system1022and cloud computing environment170. In other embodiments, hybridity director174may use a direct connect142between virtualized computing system102and cloud computing system150.

As part of stretching L2private networks122, hybridity director174ensures that VMs120on the same L2private network122are able to interact consistently, irrespective of whether the VM120is running on hosts104included in virtualized computer system102or hosts162included in cloud computing system150. In particular, when migrating VM120, hybridity director174preserves the MAC address of VM120assigned by virtualized computing system102. Consequently, as depicted inFIG. 2Bafter migrating VM1202to cloud computing environment170, VM1202retains MAC address “X.” Advantageously, maintaining MAC addresses “X” enables VM1201and VM1202to continue to interact unaware of the migration of VM1202. Similarly, as also depicted inFIG. 2B, after migrating VM1203to cloud computing environment170, VM1203retains MAC address “X,” enabling VM1203and VM1204to continue to interact unaware of the migration of VM1203.

Since private networks1221and1222are isolated from each other, duplicate MAC addresses may co-exist within private networks1221and1222without MAC address collisions. For instance, address resolution protocol (ARP) probes on private networks1221will not interact with VM1203. However, using duplicate MAC address within the common cloud computing environment170and outside private networks122, such as to access non-tenant specific data and communicate with public networks (e.g., the Internet), may cause MAC address collisions that conflate VMs120with duplicate MAC addresses. In general, MAC address collisions may cause a variety of undesirable and inconsistent behavior, such as intermittently unreachable destination hosts. Accordingly, embodiments of the present disclosure provide a hybridity director174configured to assign a new MAC address for use with non-tenant-facing traffic and conditionally translate between the original tenant-provided MAC addresses and the new MAC addresses based on the destination network, as described in further detail below.

In operation, hybridity director174configures cloud gateways184to perform conditional network address translations of MACs. More specifically, hybridity director174configures tenant-facing cloud gateways184, such as1841and1822, to preserve MAC addresses. By contrast, hybridity director174configures public-facing gateways184, such as1843that connects to Internet240, to perform address network translation-mapping (potentially duplicate) internal tenant MAC addresses to the MAC addresses assigned by cloud computing system150that are unique to public network122.

FIG. 3depicts a flow diagram of method steps for conditionally translating the source media access control (MAC) addresses of packets sent from a multi-tenant cloud computing environment. Although the method steps in this flow describe translation of source MAC addresses, corresponding address network translation techniques may be used to recreate the original MAC addresses. Further, the techniques outlined inFIG. 3may be applied to any type of addresses and may be implemented in any type of addressing scheme to provide isolated, tenant-specific addressing while avoiding addressing conflicts. For example, the techniques outlined inFIG. 3may be applied to provide namespace management and translation of VLAN identifiers, VXLAN network identifiers (VNID), and Internet Protocol (IP) addresses.

This method begins at step302where, for each tenant, hybridity director174deploys private network122and configures a tenant-facing cloud gateway184to preserve MAC addresses on private network122. In particular, hybridity director174ensures tenant-facing cloud gateways184do not perform network address translation for MACs, extending the addressing scheme implemented by virtualized computing system102, to include tenant-specific VMs120that run on hosts162in cloud computing system150.

At step304, hybridity director174configures a public-facing cloud gateway184to translate source MAC addresses in outgoing packets to addresses unique within the destination network. Hybridity director174may generate, allocate, and maintain unique MAC addresses and the address mappings in any technically feasible fashion. For example, in some embodiments, hybridity director174may request a unique address from a central namespace controller. Typically, hybridity director174deploys a single public-facing cloud gateway184, however hybridity director174may deploy any number of public-facing cloud gateways184and interact with any number of public networks.

At step306, cloud gateway184receives an outgoing packet (i.e., a packet that originates in cloud computing system150). Cloud gateway184then processes the output packet per the configuration applied in step304or step306—performing conditional MAC translation based on the destination network. If at step308, cloud gateway184is a tenant-facing gateway184that manages private network122, then cloud gateway184preserves the source MAC address and this method proceeds directly to step314.

If at step308, cloud gateway184is a public-network facing gateway184that communicates with a public network, then this method proceeds to step310. At step310, hybridity director174translates the source MAC address of the outgoing packet to a MAC address that is globally unique within the public network. After obtaining the translated MAC address, cloud gateway184replaces the source MAC address in the packet with the globally unique MAC address and this method proceeds to step314.

In other embodiments, a cloud gateway184performs MAC translation on network packets based on whether the packets' destination network is to private network222or to a public network240(i.e., Internet). Responsive to determining a packet belongs within private network222, cloud gateway184uses the tenant-provided MAC address in the packet. Otherwise, responsive to determining the packet belongs to public network240, cloud gateway184uses the cloud-assigned MAC address in the packet. In addition to modifying packet fields, cloud gateway184may be further configured to respond to address resolution requests (e.g., ARP requests) with the tenant-provided MAC address or the cloud-assigned MAC address based on the source of the ARP request.

At step314, cloud gateway184forwards the packet, using the conditionally-translated source MAC address. This method then returns to step306, where cloud gateway184receives another outgoing packet. Cloud gateway184continues to execute steps306-314, conditionally translating source MAC addresses in outgoing packets based on destination network until cloud gateway184receives no more outgoing packets. For explanatory purposes, this method describes method steps306-314for a single cloud gateway184, however any number of cloud gateways184may be processing outgoing packets at least partially in parallel using method steps306-314.

FIG. 4is a conceptual diagram that illustrates addressing in multi-tenant hybrid cloud computing system100. For explanatory purposes,FIG. 4depicts selected communication traffic as bold lines with the source MAC addresses of the packets annotated above the bold line.FIG. 4illustrates the addressing of three separate packets, each of which has the same source MAC address—“X.”

As shown, the top-most packet travels from VM1202, hosted in cloud computing environment170, to VM1201, hosted in virtualized computing system1021. After originating at VM1202with source MAC address “X” and a destination included in stretched private network1221, the packet passes through cloud gateway1841. Cloud gateway1841is a tenant-facing gateway and, consequently, is configured to retain MAC address “X” without performing any MAC address translation.

Similarly, the bottom-most packet travels from VM1203, hosted in cloud computing environment170, to VM1204hosted in virtualized computing system1022. After originating at VM1203with source MAC address “X” and a destination included in stretched private network1222, the packet passes through cloud gateway1842Cloud gateway1842is a tenant-facing gateway and, consequently, is configured to retain MAC address “X” without performing any MAC address translation.

The middle-most packet travels from VM1203, hosted in cloud computing environment170, to an Internet240. After originating at VM1203with source MAC address “X” and an Internet-facing destination network, the packet passes through cloud gateway1842. Cloud gateway1842is an Internet-facing gateway and, consequently, is configured to translate MAC address “X” to a MAC address that is unique to Internet240, shown as MAC address “GA.”

In some embodiments, the hub-and-spoke model of a single cloud supporting multiple tenants that is described inFIGS. 1 through 4is extended to a grid model of multiple clouds, each supporting multiple tenants. More specifically, multiple, geographically disparate cloud computing systems150are connected to create a distributed cloud infrastructure. Theoretically, the techniques for managing addressing of multi-tenants described inFIGS. 1 through 4—per-packet, conditional network address translation—may be extended to techniques for managing addressing of multi-tenants with a distributed cloud infrastructure. Such an approach provides seamless integration while preventing address collisions between cloud computing systems150.

Central Namespace Controller

However, unlike the multi-tenant scenario in which multiple tenants manage addressing independently, often one provider supplies the distributed cloud infrastructure. In particular, some such providers leverage the ability to control the addressing across the distributed cloud infrastructure to provide centralized address management of a distributed cloud namespace. In particular, some embodiments may provide a central namespace controller that manages the distributed cloud namespace in a judicious fashion during provisioning—avoiding address collisions between cloud computing systems160without performing additional per-packet, conditional network address translations.

FIG. 5is a conceptual diagram that illustrates a central namespace controller512in a distributed cloud infrastructure500. In addition to a primary site510that includes central namespace controller512, multi-cloud computing system500includes, without limitation, three cloud computing systems150. Each cloud computing system150may be at a different geographic location and is interconnected with other cloud computing systems150in any technically feasible fashion. For instance, cloud computing system1501may be on London, cloud computing system1502may be on New Jersey, cloud computing system1503may be in San Jose, and cloud computing systems150may be connected via the Internet. For explanatory purposes,FIG. 5depicts connections between cloud computing systems150using thin arrows.

In alternate embodiments, distributed cloud infrastructure500may include any number of cloud computing systems150at any number of geographic locations. In some embodiments, primary site510is included in one of cloud computing systems150. Further, each cloud computing system150may support any number of virtualized computing systems102(i.e., tenants), and distributed cloud infrastructure500may support cross-cloud private networks that interconnect different virtualized computing systems102. For example, a corporation may have on-premises data centers in both New Jersey and San Jose connected via a common L2backbone network (not shown inFIG. 5).

As shown, each cloud computing system150includes hybridity director174. In addition to communicating with the corresponding hybrid cloud manager132in virtualized computing system102, each hybridity director174communicates with central namespace controller512. Each hybridity director174may communicate with central namespace controller512in any technically feasible fashion. For example, each hybridity director174may communicate with central namespace controller512using Internet-based traffic via a VPN tunnel, or alternatively, using a direct connection. For explanatory purposes,FIG. 5depicts connections between each hybridity director174and central namespace controller512using thick arrows.

In general, central namespace controller512allocates addresses for networks and components that are provisioned and created by hybridity directors174. More specifically, central namespace controller512judiciously assigns addresses in a distributed cloud address space to ensure that components (e.g., VMs172) that interact across multiple cloud computing systems150do not experience address collisions. In operation, as part of provisioning a network, hybridity director174coordinates with central namespace controller512to assign a VNI that is unique within a multi-cloud namespace. Subsequently, as part of creating a new VM172on the provisioned network, hybridity director174coordinates with central namespace controller512to assign a MAC address and IP address that are unique within the provisioned network.

FIG. 6Adepicts a flow diagram of method steps for managing a distributed cloud namespace when provisioning a network in a distributed cloud infrastructure. Although the steps in this method describe provisioning using MAC addresses, IP addresses, and VNIs, similar steps may be implemented to enable provisioning using alternative protocols. For instance, in some embodiments, provisioning may use VLANs instead of VNIs to identify networks.

This method begins at step602where hybridity director174receives a request to provision a network. Such a request may be generated in any technically feasible fashion, such as from user input to a graphical user interface or an application programming interface. At step604, hybridity director174sends a request for a VNI, a MAC address range, and an IP address range to the central namespace controller512that manages a distributed cloud namespace. In response, at step606, central namespace controller512selects a VNI that is unique within the distributed cloud namespace managed by central namespace controller512.

As part of step606, central namespace controller512also assigns MAC and IP address ranges that are unique within the network specified by the VNI. Because central namespace controller512assigns MAC and IP address ranges that are unique within the network, together central namespace controller512and hybridity directors174enable communications via tenant-specific networks that spans multiple cloud computing systems150—without provoking intra-tenant addressing collisions. However, the assigned MAC and IP address ranges are not necessarily unique within the distributed cloud namespace. Advantageously, by allowing MAC and IP address ranges on different networks to overlap, central namespace controller512optimizes the use of the limited available addresses in the distributed cloud namespace.

After central name space controller512provides the assigned VNI and the assigned MAC and IP address ranges, the hybridity director174provisions the network specified by the VNI with the specified MAC and IP address range (step608). Since the VNI and MAC and IP address ranges are centrally allocated, cloud computing systems150at different sites (managed by different hybridity directors174), flexibly share the distributed cloud namespace.

FIG. 6Bdepicts a flow diagram of method steps for managing a distributed cloud namespace when creating a virtual machine in a distributed cloud infrastructure. For explanatory purposes, the context of this method is that hybridity director174has already provisioned a network within the distributed cloud namespace. In general, the network will be provisioned with a VNI that is unique within the distributed cloud namespace and MAC and IP address ranges that are unique within the network. The network may be provisioned in any technically feasible fashion, such as using the method steps described inFIG. 6A. Although the steps in this method describes creating VMs172addressed using MAC addresses. IP addresses, and VNIs, similar steps may be implemented to create VMs172addressed using alternative protocols.

This method begins at step652where hybridity director174receives a request to create VM172on a provisioned network. Such a request may be generated in any technically feasible fashion, such as from user input to a graphical user interface or an application programming interface. Further such a request may be implied as a second step in a request to provision a network and create VM172on the newly provisioned network.

At step654, hybridity director174requests allocation of a MAC address and corresponding IP address on a network specified by a VNI within a distributed cloud namespace that is managed by central namespace controller512. In response, at step656, central namespace controller512selects a MAC address and an IP address that are both unique within the network specified by the VNI and also lie within the MAC and IP ranges defined for the provisioned network. In some embodiments, central namespace controller512dynamically adjusts the MAC and IP ranges for each network based on network-specific demand. Such MAC and IP ranges enable as-needed allocation of namespace resources, thereby optimizing the usage of the distributed cloud namespace across multiple networks and multiple cloud computing systems150compared to pre-defined allocation schemes. In some embodiments, MAC and IP ranges may be fragmented.

At step658, hybridity director172creates VM172, specifying the assigned MAC and IP addresses received from central name space controller512. Advantageously, since the VNI, MAC addresses, and IP addresses are centrally allocated, cloud computing systems150at different sites (managed by different hybridity directors174) flexibly share the multi-tenant network namespace without address overlaps within the namespace. Further, because distributed cloud computing infrastructure500only incurs address management overhead during provision time of networks and VMs172, not inline per-packet, overall processing time is optimized across distributed cloud infrastructure500.

In some embodiments, distributed cloud infrastructure500may be configured to provide MAC and IP addresses that are unique within Internet240. In such embodiments, distributed cloud infrastructure500may provide unique MAC addresses for MAC network address translations as described inFIGS. 2, 3, and 4.