The release and support of VXLAN has raised a great level of interest in the community. As one of the first to deliver content with regards to VXLAN implementation examples I’ve been approach by customer and colleagues with questions around VXLAN architecture designs and use cases. For the most part, I see there is a large audience not really up to speed with the logistics of VXLAN as it relates to vSphere and vCloud infrastructures supported implementation scenarios. The knowledge gap is not entirely around the value of VXLAN technology but more around the architectures and uses cases where it can successfully be used today.
Based on my experiences lately, the use of VXLAN becomes the topic of conversation whenever connecting multiple data centers where each site has separate vSphere/vCloud Infrastructure becomes to topic of conversation. I can see how some folks have been mislead into thinking VXLAN is the answer for that as they can now leverage VXLAN to connect multiple vCenter Server and vCloud Director infrastructure together today. Well the truth is that plain and simple VXLAN CANNOT be use as the technology to connect multiple vCenter Server and vCloud Director environments today.
The reality is that with the current release of VXLAN there is no supported way of connecting multiple vSphere or vCloud Infrastructures together. Considering the platforms architectures and components both vSphere and vCloud based infrastructures have a lot of dependencies and moving parts which makes it very challenging to integrate in a way that would make that possible today. From what I understand this is something that all of the partners involved with the development of the VXLAN technology are looking to address soon.
One of the publications which I have found a lot of people reading and using as guidance for vCloud Director is the vCloud Architecture Toolkit (vCAT). As part of the vCAT implementation examples we have included a couple of VXLAN scenarios one of them being around disaster recovery and based on conversation this very topic I’ve noticed that some people have overlooked or missed one critical piece of the information discussed and illustrated as part of that example.
As one of the contributors to the vCloud Architecture Toolkit (vCAT) I have to come out and defend some of the misconceptions folks are gathering around the VXLAN implementation example in vCAT topic. The VXLAN disaster recovery example scenario is based around a stretched cluster scenario, and not two separate infrastructures. Two physical data centers in two different locations with one logical datacenter (vSphere/vCloud) spanning both physical data centers.
That means one vCenter catalog, as well as one vCloud infrastructure. The purpose of that example was not meant to illustrate two entirely different vSphere/vCloud infrastructures (2 separate clouds, 2 separate vCenter catalogs) somehow the understanding of the logical component that calls out “stretched” resource cluster was misunderstood.
The ability of using VXLAN to connect multiple and independent vSphere/vCloud infrastructures is a capability that everyone faced with network capacity and other issues around that wants. This again is something that is VMware and others are addressing. So I want to clearly point out and illustrate what are currently supported implementations implementations of VXLAN with vSphere and vCloud Infrastructures.
One more thing, VXLAN is not just a vCloud Director networking technology, VXLAN can be used in plain vSphere Infrastructures as well.
Supported VXLAN Implementation Scenarios
Local Data Center scenario – vSphere/vCloud Infrastructures management components such the ones listed below reside in the same physical site:
- vCenter Server
- Update Manager
- Database Management System for all components
- vCenter Orchestrator
- vCenter Configuration Manager
- vCenter Site Recovery Manager
- vCenter Server Heartbeat
- vCenter Chargeback
- vCenter Operations Manager
- vCloud Director
- vCloud Connector
- vCloud Director Database
- vCloud Network and Security
In this scenario all of the vSphere/vCloud management components are configured as one large management domain in which all depend on the same centralized global management catalog (this is not AD related, its just the way I’m referring to it) provided by vCenter Server instances.
Physical hardware (Switches, Routers, Storage, etc) are all dedicated and consumed by workloads local to the site. From a vCloud Director perspective, you can have as many provider virtual datacenters (PVDC), organizations virtual datacenters (OrgVDC), networks, and network pools and customers organizations the infrastructure can support based on available resource capacity.
From a network standpoint, when the infrastructures network capacity (number of networks) gets to be so large that it will reach the network limits defined by the IEEE 801.1Q standards, this is where VXLAN can help by extending the logical network limitation from 4000 to a possible 16 million logical networks.
Stretch ClusterData Center Scenario – The vSphere/vCloud Infrastructures management components listed above can reside in both locations. The important item to point out in this scenario and the illustration below is that this is a Single vSphere/vCloud Management Domain (Single Global Management Domain). Because the same management domain is extended across both sites and its managed by the same core management components (vCenter, vCNS, vCD, etc).
The point of the diagram above is to illustrated the extension of one management domain between two physical data centers. In this scenario the VXLAN technology can be leverage to enable network communications across the two locations. The illustration is not meant to imply that two separate data centers with separate and independent vSphere/vCloud infrastructures. That is the part that currently can’t be done folks. There is no supported way to connect two separate vCenter Servers, VSM, and vCD at the moment to then to use VXLAN as the communication transportation method.
I hope this is some what useful and clear a few things up. If anything at the very least I’ve listed the two VXLAN supported implementations as of today.
For future updates, be sure to follow me on Twitter at @PunchingClouds