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 exist 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.
USPTO Backgrounds
USPTO Backgrounds