Server

Part 1 explained the basic concepts of networking within vCD(VMware vCloud Director), Part 2 focussed on Network Pools and Part 3 focussed on a use case which was a vApp directly connected to an External routed Org Network. It took me a while to develop part 3 and I wasn’t sure if I could find the time to do another use case or not. I received a dozen requests for another use case so I decided to free up some time to help you guys out. Please read the other parts of this series before you start reading this part. Okay, let’s dive into those trenches.

vApp fenced to an Internal Org Network

Use case:

1. Environments where vApps are copied and redeployed for  test and development purposes. There is no connection back to the customers datacenter to avoid any interference that could be cause by these test environments.

We will start with the basics. The flow of the network in this case will be:

Although only two different type of networks are used, this could of course result in multiple layers if and when for instance multiple vApp Networks are created. For the purpose of this exercise we will create a vApp with 3 VMs including two different networks. You could say you classical three-tier application.

1. WEB = Web Frontend
2. APP =Application Server
3. DB = Databaser Server

As you can imagine we don’t need users accessing the Application or Database Server so these two will be on a separate network segment. The Web Frontend will need to be accessible though and it will need to be able to access both the Application and the Database Server. Logically speaking that will look as follows:

Please note that the Org Network doesn’t connect back to anything! This means that in order for you to connect to your WEB vm you will need to go through the vCD Portal! Of course you could still test if your web services are working by simply deploying a desktop VM with windows XP in the same Org. Now I can hear some of you think why not just a NAT-Routed Org Network, well that is something that would work as well, but than it would be really similar to what use case 1 provided and this is purely for educational purposes.

Creating the Networks

The first step of course is to ensure you have a Network Pool. If you haven’t already created, you can use Part 2 of this series as a reference.  I am assuming here you already have a network pool and will go straight to the Org Network, which is option 7 on the home screen.

Now you will need to select the Org that this Network will belong to and then you can decide what type of network you will create. You can do this in either “Typical” or “Advanced” mode. Both will give you the same options but it is named slightly different and Advanced will only allow you to create 1 network at a time where with Typical you can create multiple. As we have used Typical in the previous use case we will use Advanced this time. We are going to create a fully isolated Org Network so we will select “Internal Organization Network”.

Next up we will need to select a network pool. Now you might ask yourself why we will need one when the Org Network is completely isolated? Well we will need cross-host communication when vApp/VMs need to communicate with each other and don’t reside on the same host. Although it sounds very logical, it is often overseen that this is what a network pool does. It enables cross-host communication. In this case we will select the vCloud Network Isolation Network Pool.

Now we will need to specify the IP details for this Org Network. These IP addresses will be consumed by the VMs that are configured to use the “static pool”, in our case that will be the vShield Edge device that is deployed as part of this Isolated Network (deployed for DHCP services etc) and the WEB virtual machine.

Of course we will need to give it a name. I tend to use the name of the Org and the type of Org Network I created.

Now we will need to build a vApp. As stated this vApp will contain multiple VMs.

We will give it a name.

And we will start adding multiple VMs to it. The WEB virtual machine will have 2 NICs as it will need to connect to a device outside of vApp and to two VMs inside of the vApp.

The following two VMs “APP” and “DB” will be configured with a single NIC as they will only need to connect to each other, all contained within the vApp.

Now this is the part where we will assign specific network segments to the NICs. For WEB we will connect “NIC 0” to the Internal Org Network and NIC 1 will need to be connected to a vApp Network.

This vApp Network however will need to be created first. Please note that this is a vApp network, so only available to those VMs which are part of this vApp! Again we will need to specify IP details for the VMs to consume.

When we have done this and have given the vApp network a name we can connect the remaining VMs to the same network.

Now in order to have multiple copies of the same vApp running within the Org we will select “Fenced” mode for the vApp which basically will deploy a vShield Edge device.

I guess this diagram that vCD creates makes it a bit more clear what your vApp connectivity will look like:

And if that isn’t enough you can also check the Maps functionality that vCenter offers. This will give you a great view of how this vApp is connected within vSphere.

So what about that desktop? And what about if we have two copies of that vApp running? Well this is what the map would look like if when we have created these. On the middle left you will see the desktop that is used for testing the WEB VMs. Both WEB virtual machines can be accessed through the VSE device, which of course means that you will need to setup NAT, but we will leave an in-depth explanation around that for the next article.

Summary

vCloud Director Network is really powerful, but as shown by this use case it can get very complex rather fast especially when you are using multiple layers. In this example we kept it simple by using an isolated network, an External NAT/Routed Org Network would have added another layer. Features like vCenter Maps will however make it easier to understand what has been created on the vSphere layer to enable these layers of networking, make sure you take advantage of functionality like this when exploring vCD!