Now that I got my lab re-configured for just vSphere 5.1 only I wanted to simulate not only the use case for Stretch Deploy into vCloud Air, but specifically doing so when you only have a vSphere infrastructure. Doing so has some different nuances you will need to consider that would not be present when doing a stretch deploy from a private vCloud Director install in premise to the Public Cloud. I will go through the use case setup and provide some of my findings and interesting nuggets of information. There is a lot to go over here so I may break up some of the more in-depth components later. I have already blogged about how to set up a Site to Site VPN from your local datacenter to your vCloud Air, but stretch deploying a single Virtual Machine or vSphere vApp, is separate from this.
vSphere Stretch Deploy Use Case
The basic use case for this is that you have spun up your vCloud Air, and you want to migrate an existing workload or group of workloads from your vSphere environment to your shiny new vCloud Air solution. Generally this would require changing the IP address of the virtual machine, but with stretch deploy through vCloud Connector, this is no longer required. There are a few basic assumptions I need to make before I go on as I will not cover the specifics of these. If people comment they need the specifics I can consider writing them up later.
- You have a vCloud Connector Server running locally on premise
- You have a vCloud Connector Node running locally in premise with a connection to your vCenter server
- You have configured vCloud Connector Server for the local node and the proper vCloud Air Multi-Tenant Node
- You have enabled both vCloud Connector nodes for Stretch Deploy
- You have a vCloud Networking and Security Manager (AKA vShield Manager) Installed on premise
vSphere Stretch Deploy – What Does It Do?
This is the interesting part of all this. What basically happens without going too deep into the details, is that your Virtual Machine is copied to your public cloud. A vApp Network Edge Gateway is deployed and configured for you and an SSL VPN is established between that Edge Gateway and the local premise Edge Gateway. Once that is in place your stretch deployed virtual machine will be able to still communicate back to the local site as if it were still sitting there. The resources would now be bill against your vCloud Air account instead of using your local resources. In thinking about the architecture of this there are some considerations to think about:
- The stretched virtual machine will still have it;s original network settings. This means any communication back to its Directory servers, DNS, or other static resources will traverse the VPN. In turn internet connectivity will traverse the VPN then return to the internet since the virtual machine appears to still be in its original subnet.
- You need to possibly have multiple external IP addresses which will be covered later.
- Troubleshooting the virtual machine’s workloads will need to require knowledge of the networking connectivity and the stretch deploy architecture. It may add a layer of complexity to troubleshooting.
- You will need to deploy and configure an Edge Gateway in your local datacenter. This may require some work on your part just to make sure that the virtual machines will properly stretch deploy. Since it is an SSL VPN between Edge Gateways at least one will be required on both sides.
vSphere Stretch Deploy Requirements
As with anything there are a few technical requirements you need to adhere to. A couple of these I will go into depth on since as a requirement it’s easy to read, but was a little more interesting to configure and comprehend. Because we are dealing specifically with a vSphere virtual machine a few of these may need to be added to your infrastructure before you proceed. The long list of requirements can be found Online Here, I will grab the ones that seemed the most important.
- Licensing Requirements – Yes it must be licensed properly.
- System Requirements – 5.1 minimum across the board.
- Network Requirements for Destination Cloud – I will cover these below
- Network Requirements for Source vSphere – I will detail this below
vSphere Stretch Deploy – Network Requirements for Destination Cloud
Most of the basic requirements are already met by vCloud Air as a consumer of the service Things like Distributed Virtual Switches will already be there. You just need to make sure you have an Edge Gateway deployed and also have either routed or direct organization networks in your cloud. For my purposes I will be using a routed organization network that is behind the Edge Gateway. Most importantly is that you need to have public IP’s available for DNAT’s to be created during the process. Your Edge Gateway when deployed should always have at least one external IP address on it. The challenge is the following statement from the requirements:
The DNAT entry is created for port 443. Select an IP address that is not already being used for port 443
What this statement means is that you can only establish one SSL VPN per external IP Address. So if you use the primary external IP of your Edge Gateway you will not be able to use port 443 again on that IP address. Therefore if you have multiple virtual machines or multiple vApps to stretch deploy you may need more external IP addresses. For my case it was one virtual machines and I did use the external IP of the Edge Gateway itself. I do have other IP addresses available for further testing.
vSphere Stretch Deploy – Network Requirements for Source vSphere
This is where there is much more to consider. There is a long list of requirements that you need to meet on the vSphere side. From what I have been internalizing, this is because most vSphere shops will not have an Edge Gateway deployed. The first and most important requirement is that an Edge Gateway is required. With the new Edge Gateway you could have one device with a single external interface and multiple internal interfaces mapped to your vSphere Port groups. In order to move an existing virtual machine you will need to have an Edge Gateway Interface on the port group where the virtual machine resides. In my case I disabled NAT and firewall functions on the Edge Gateway for simplicity. Due to this you may have some additional considerations:
- An Edge Gateway is a firewall, you need to determine the rules if any
- Determine if you will Re-IP for a NAT – This a bit defeats the purpose of stretch deploy, so you may use no NAT
- The Edge Gateway needs to have external internet access
vSphere Stretch Deploy – Part 1 Summary
The idea of stretch deploying a virtual machine from vCenter to your vCloud Air is very attractive. As I continue to test some more I will put together some additional details about the process. My limitation in my home lab is the horrible upload bandwidth I have but I will be sure to document the setup architectures in diagrams for Part 2 of this so you can see the setup. I want to be sure to show that there is still a Site to Site VPN in place, but getting an actual vApp moved could take many hours for the copy process. Even with the smallest CentOS Minimal install it was still over 1GB of disk data. If I can get myself access to a more robust lab with better upload capabilities I can maybe get some better tests for the copy process. I hope to be able to speak more to this at the upcoming VMUG’s and VMworld sessions as well.