vCloud Director 1.0.1: Networking Samples
My old vCloud Director Networking for Dummies post is still going strong according to my blog statistics. I believe this is an indicator that people are looking for more information about this topic so I thought I'd give it a little bit more color and create a few real life examples on how that theory works in practice. I suggest you read the Networking for Dummies post linked above before you dive into this one.
Note also that the other post as well as this one are based on vCloud Director 1.0.1 which is the latest release available as of June 2011. Things may change in the future so, if the vCD release you are using at the time you read this is above 1.0.1, chances are that things could be slightly different. I can't really say more than this at this point.
Last but not least, everything I will be doing below can be done as a cloud consumer in self service mode. As a matter of fact I will be doing everything as an Org Admin.
Introduction
To walk through an actual implementation of the networking stack I'll use my IT20 organization hosted in the Stratogen cloud. This discussion starts with the description of the networking plumbing in my vCloud organization. From the vCD UI it looks like this:
From a logical perspective it looks like this:
My Org has four public Internet addresses that Stratogen associated to my "Routed Network" when they created the tenant. For security reasons I am not going to widely advertise them in this post.
You can see these assigned addresses if you right-click on the Routed Network and select "Configure Services":
The last piece of the puzzle is three vApps I have created in this Org and that we are going to connect to the various networks you have seen above. This is supposed to give you a practical idea on how things can be configured. The names of the vApps should be self-explanatory.
Direct Internet Connection
Let's start with the most simple of the networking scenarios. Note there is a vApp called "Turnkey_Internet" which is comprised of a single VM. That VM is connected to the "Direct Internet" connection available in my Org. I have only one comment for this example: scaring! Never do this because you are in fact plugging your VM directly into the Internet without any level of protection (other than what you could have inside the Guest OS of course).
This is how my VM is configured:
And this is how the VM fits into the logical network view:
The way this works is pretty straightforward and, if you read the vCloud Director Networking for Dummies post, it should be explained there. Basically the cloud administrator has configured a pool of available IP addresses for this "External Network" (since this is a vSphere PortGroup with native Internet connectivity this pool will contain native Internet IP addresses). Since the Direct Internet connection in my Org is nothing more than a pointer to this vCD External Network which in turns is a pointer (with metadata) to the PortGroup backing it, the result is that the vNIC of my VM gets connected directly to this PortGroup. vCD assigns the (vNIC) an IP in the pool.
I am glad Stratogen configured this network for me - as it is handy if you are experimenting with vCD networking - but in a real life scenario you would never want to connect VMs to a connection like this (directly connected to the Internet). However this may become pretty interesting if you, as an Enterprise, are using virtual data centers hosted in a cloud where the Service Provider has configured an MPLS connectivity back to your headquarter. Something like this:
It goes without saying that, doing so, you are effectively dedicating an External Network (and in turn a PortGroup) to the IT20 Org. If for any reason you give access to another Org to the same External Network (either
Routed Network - single-tier vApp
This is where things start to become more interesting, slightly more difficult to explain and very reach at the same time. I have another vApp that is called "Turnkey-Routed". It contains a single VM which is connected to the Routed Network available in the IT20 organization. You can imagine this Routed Network as a dedicated layer 2 segment protected by a firewall device (vShield Edge). For more information on how this work from a vSphere perspective read the vCloud Director Networking for Dummies post. Essentially the VM in this vApp gets assigned an IP address available in the pool defined for this layer 2 segment. This is how vCD shows the details of the Hardware Properties for this virtual machine:
And this is how it logically fits into our diagram:
Note that in the diagram above we went a couple of steps forward. Not only we are protecting the VM with the Edge: I have also configured the Edge to NAT the private IP. To do so I have created a one-to-one mapping rule to one of the four Internet addresses Stratogen assigned to me. I have also configured a firewall rule to only allow traffic on port 12320 to reach the VM (this is because the Turnkey appliance uses particular ports to get access to SSH and web admin interfaces). How did I do this? Move onto the Routed Network and right-click on Configure Services. Point to the "External IP Mapping" tab and configure the NAT rule:
You would then point to the "Firewall" tab where you can configure the firewall rule I have described above (as an example).
I have just blocked all traffic coming into this VM except for traffic directed to port 12320. As easy as it is.
Routed Network - multi-tier vApp
The single-tier vApp is still pretty simple. Let's now focus on the third vApp I have mentioned. This is the "2Tiers" vApp which is comprised of a front-end Windows VM (Win-Web) and a back-end Linux VM (REHL-DB). The idea is to provide IT20 customers with access to this application protected by multiple levels of security. The first step is to connect the front-end to the Routed Network in the Org and NAT it. This is similar to what we have already done with the single-tier vApp discussed above. I am not going to show screenshots of the NAT and Firewall configurations because the steps are very similar. It goes without saying that the Win-Web VM has a different private IP and I will be using another public IP to create the DNAT rule. This is how the logical layout looks like for this specific vApp. I am opening port 80 for this example:
As you can see the back-end VM is not yet connected to any network. As I said we want to provide an additional level of security for that VM and we don't want to connect it "directly" to the Org network. How do we do this? This is where the so called "vApp Networks" come into place. You can imagine vApp Networks as layer 2 network segments dedicated (and only available) to the specific vApp they have been created for. In other words a vApp Network created for one vApp cannot be used by any other vApp. If you want to know more about this concept please refer again to the vCloud Director Networking for Dummies post.
You can create vApp Networks in multiple ways but the easiest one is to click on the "Add Network" choice in the drop-down menu for the vNIC connectivity available in the Hardware Properties of the VM:
Selecting it kicks off a brief wizard that asks you the very basic metadata to create a new network (Subnet Mask, Default Gateway, IP Pool etc). You can then select whether you want to protect this dedicated vApp Network with NAT and Firewall functionalities. You can do this in the Networking tab when you "Open" the vApp:
Let's pause for a second here (too many screenshots to digest).
Don't be fooled. What we are trying to do is to create a logical layout like the one depicted below:
In a way we are applying to this vApp Network the same NAT and Firewall principles that we applied to the Routed Network at the organization level. Where do you configure these rules for the Edge device that is backing this vApp Network? Easy. Look at the latest screenshots above and click Details. Done.
This is the tab where you configure the NAT rule so that the DB private IP gets mapped to the Routed Network in the organization:
Below is the tab where you configure the Firewall rule to allow DB traffic only (this rule is just an example):
Conclusions
Let's now try to put all these piece together and look how the logical layout of the workloads running in the organization looks like as a whole:
As you can see the self-service networking stack in vCloud Director is pretty powerful and flexible although there are certainly things that could (and should) be done better. For example you may argue there is a lot of NATting going on (and I would have a problem arguing the opposite). But, as we said, this post is based on the 1.0.1 version of the product and things may change in the future.
Note that we haven't covered any example on how to use the "Internal Network" since it should be pretty straightforward. It's basically a flat layer 2 network that doesn't go anywhere and only allows VMs attached to it to communicate to each others.
I hope you found this post useful. I'd like to get your feedbacks.
Massimo.