My colleague Lyubomir Lyubenov from VMware OneCloud team (OneCloud is internal huge vCloud Director based cloud for field enablement) recently published VCDonAWS CloudFormation templates with which you can deploy vCloud Director management components under 30 minutes on AWS.
I have seen customer (Service Providers) asking what is it for and what it means for the vCloud Director future. Let me give you my own view.
What is it?
vCloud Director is one of a few VMware products that is not provided in form of virtual appliances. The vCloud Director binaries can be installed on any compatible Linux virtual or physical machine and that means it can be installed anywhere – even on EC2 instances running on AWS. The VCDonAWS project in a clever way uses AWS resources (not VMC on AWS!) to deploy vCloud Director management stack from a single CloudFormation template. It leverages VPC (optionally stretched across 2 availability zones) for the networking, EC2 instances for jumphosts and vCloud Director cells, PostgreSQL RDS for vCloud Director database, S3 (S3FS) for vCloud Director transfer share (although this will be in the future replaced with Elastic File System for better performance), Elastic Load Balancers (for UI/API and ConsoleProxy cells) and even Auto Scaling Groups to automatically deploy additional VCD cells. The certificates are provided with AWS Certificate Manager.
The following picture taken from the VCDonAWS website shows the overall architecture.
What is it not?
As you can see above it only deploys the vCloud Director management components. You will still need to attach resource vCenter Servers/NSX Manager pairs and these obviously cannot be running on (native) AWS. You cannot even use VMC on AWS instances (at least not yet) as they have RBAC and VC/NSX inventory access limitations which prevent vCloud Director from working properly.
Cassandra VM metric datastore and RabbitMQ messaging bus optional components are not deployed either although I see no reason why they should not run on AWS.
Is it supported?
No. The deployment uses unsupported OS – Amazon Linux (the CentOS deployment option is not working at the time of writing).
Beside the OneCloud team use case which I cannot speak here about I see it as a very nice proof of concept of how VCD deployment can be automated. How simply it can be done with infrastructure as code approach. And obviously once VMC on AWS restrictions will be resolved these two can be used together to provide multitenant VMware platform IaaS.
Try it yourself!
If you have AWS account try it yourself and really in about an hour you can have a deployed vCloud Director instance.
Here are some tips:
Use only US regions as the provided templates do not have AMI mappings for other regions
Use Amazon Linux HVM as base operating system for Bastion and cell hosts (CentOS option is not working)
For VCD installation ID do not use 7-9 due to bug in verification regex.
You will need VCD binary uploaded in an S3 bucket. I used VCD 9.1 GA bits. You will also need working license key.
You will need certificate (even self signed) uploaded to Certification Manager.
And lastly generate key pair for accessing bastion hosts and cells.
In today’s reality of multi cloud world customers are asking how to set up connection between them. In this article I am going to demonstrate how to set up IPsec VPN tunnel between AWS VPC and vCloud Director Org VDC.
IPSec is standard protocol suite which works at OSI Layer 3 and allows encrypting IP packet communication. It is supported by many software, hardware and cloud vendor implementations, however it is also quite complex to set up due to large sets of different settings which both tunnel endpoints must support. Additionally as it does not rely on TCP L4 protocol NAT traversal can be a challenge.
In my example I am using my home lab vCloud Director instance running behind NATed internet connection. So what could go wrong 🙂
The diagram below shows the set up.
AWS Virtual Private Cloud on the left is created with large subnet 172.31.0.0/16, a few instances, and Internet and VPN gateways.
On the right is vCloud Director Org VDC with a network 192.168.100.0/24 behind an Org VDC Edge Gateway which is connected to the Internet via my home ADSL router.
We start by taking care of IPSec NAT traversal over the ADSL router. As I have dd-wrt OS on the router, I am showing how I enabled port forwarding of UDP ports 500 and 4500 to the Edge GW IP 10.0.2.121 and added DNAT for protocols 50 (AH) and 51 (ESP) to the router startup script. iptables -t nat -A PREROUTING -p 50 -j DNAT –to 10.0.2.121 iptables -t nat -A PREROUTING -p 51 -j DNAT –to 10.0.2.121
Now we can proceed with the AWS VPN configuration. In AWS console, we go to VPC, VPN Connections – Customer Gateways and create Customer Gateway – the definition of the vCloud Director Org VDC Edge Gateway endpoint. We give it a name, set it to static routing and provide its public IP address (in my case the public address of the ADSL router).
Next we define the other end of the tunnel – Virtual Private Gatway – in menu below. We give it a name and right after it is created, associate it with the VPC by right clicking on it.
Now we can create VPN Connection in the next menu below (VPN Connections). We give it a descriptive name and associate Virtual Private Gateway from step #3 with Customer Gateway from step #2. We select static routing and provide the subnet at the other end of the tunnel, which is in our case 192.168.100.0/24. This step might take some time to finish.
When the VPN Connection is created we need to download its configuration. AWS will provide the configuration in various formats customized for the appliance on the other side of the tunnel. Generic format will do for our purposes. Needless to say, AWS does not allow custom setting of any of the given parameters – it is take it or leave it.
Before leaving AWS console we need to make sure that the subnet at the other side of the tunnel is propagated to the VPC routing table. This can be done in the Route Table menu, select the existing Route Table, in the Route Propagation tab find the Virtual Private Gateway from step #3 and check Propagate check box.
To configure the other side of the VPN endpoint – the Org VDC Edge Gateway we need to collect the following information from the configuration file obtained in the step #5.
Virtual Private Gateway IP: 52.x.y.z
Encryption Algorithm: AES-128
Perfect Forward Secrecy: Diffie-Hellman Group 2
Pre-Shared Key (PSK): 32 random characters
MTU: 1436. Note: As was said before, none of these parameters can be changed on AWS side. So the router on the other side must support all of them. And here we hit a little issue. AWS pre-shared key is generated with number and letter (upper and lower case) characters and a special character – like dot, underscore, etc. Unfortunately vShield Edge does not support PSK with special character. NSX Edge does, but the legacy vCloud Director UI/API will not allow us to create IPsec VPN configuration with PSK containing special character. There are various ways how to solve it. One is not to use the native AWS VPN Gateway and instead use software VPN option, another is to create/edit the VPN configuration directly in NSX Manager (only Service Provider can do this) and lastly convert the Edge Gateway to Advanced Gateway and take advantage of the new networking UI and API that does not have this limitation (this functionality is currently available only on vCloud Air, but will soon be available to all vCloud Air Network providers).
In vCloud Director UI go to Administration, select your Virtual Datacenter, Edge Gateways tab and right click on the correct Edge GW to select its Edge Gateway Services.
In The VPN tab Enable VPN by clicking the checkbox. In my NATed example I also had to configure public IP for the Edge GW (which is the address of the ADSL router).
Finally we can create the VPN tunnel by clicking the Add button and selecting Establish VPN to a remote network pulldown option. Select local network(s) (192.168.110.0/24), in peer networks enter AWS VPC subnet (172.31.0.0/24), select internet interface of the Edge in the Local Endpoint, enter its IP address (10.0.2.121). For Peer ID and Peer IP use public address of Virtual Private Gateway from step #7. Change Encryption algorithm to AES and paste Shared Key (see the note in #7). Finally modify MTU size (1436).
If everything was set correctly then back in AWS console, under VPN Connections, Tunnel details we should see the tunnel status change to UP.
AWS offers two tunnel endpoints for redundancy, however in our case we are using only Tunnel 1.
If the firewall in Org VDC and Security Groups in AWS are properly set, we should be able to prove tunnel communication with pings from AWS instance to the Org VDC VM.