This is part 4 of the vCloud Director 101 posts I have recently been writing. This article covers the vCloud Director Networking concepts and how they fit together.
You can read the previous posts by clicking here.
To understand some of the terms contained within this post, you need to read the first post that discuses the terms “consumers” and “providers”. We will be using these terms regularly throughout this article.
vCloud Director network layers
We will start by discussing the three different networking layers. These are:
- External Networks
- Organization Networks
- vApp Networks
These networks are managed at two different layers: Consumers and Providers.
External Networks and Organization Networks are created and managed by the Cloud Admins or Providers, where as vApp Networks are created and managed by the users or consumers of vCloud Director.
So what is an External Network?
- A Network that is external to VMware vCloud Director
- It is created in vSphere
- It provides external connectivity to Organizations
- It maps to a port group at the VMware vSphere layer
- The port group is attached to VMware vCloud Director as an “External Network”
External Networks allow the vCloud to connect to the outside world. These are exactly as described, external to the cloud. Think of these are your external VLANs or Internet connectivity.
What are the Use cases for this network type?
- Internet access
- Network endpoints
- IP based storage
- Backup servers
- Backend network infrastructure to the datacenters
- Internal IT Infrastructure
- Second Datacenter
So what is an Organization Network?
- A network that is contained within an organization
- Allows vApps within the organization to communicate with each other or to outside the organization
- Backed By Network Pools
An Org network can be connected to External networks as:
- Public (External Org Direct)
- Bridged connection to an External Network
- Others outside the organization can see
- Connected to an External Network through a vShield Edge
- Can be configured for NAT & Firewall
- …or left unconnected to external
- Private Internal (Internal Org)
- No External connectivity
Organization networks are again created by the Cloud Admins or Providers and are contained within the Organizations. The key purpose is to allow multiple vApps to communicate with each other and provide connectivity of the vApps to the external world by connecting to the External Networks.
Organization Networks are provisioned from a set of pre-configured network resources called Network Pools. These again are configured at the vSphere layer. We will discuss Network Pools further on in this article.
What is a vApp Network?
vApp networks are created by the users or consumers of the cloud and are contained within the vApp container. The key purpose of a vApp Network is to connect multiple VMs together and allow them to communicate with each other, or communicate to VMs in other vApps via the Organization Networks and isolate specific VMs of a vApp.
Confused? I was the first time I heard all these different pools and network types. This should become clearer as we go further.
What are the use cases for this network type?
- vApp networks are contained within a vApp so they are Private Internal networks
- Allows VMs in a vApp to communicate with each other
- Communicate with other vApps by connecting to an Org Network
- Backed by a Network Pool
A vApp Network can be connected to an Org network as:
- Public (Direct)
- Bridged connection to a organization network
- Private Routed
- Connected to a organization network through a vShield Edge
- Can be configured for NAT & Firewall
As with Organisation networks they are provisioned from Network Pools, which are backed by vSphere Port groups.
So to recap the three different types of network types, the following diagrams will demonstrate the different use cases we have discussed previously. The diagram below shows a vApp network with 3 VMs connected to this.
The next diagram is demonstrating what we discussed under Org networks. This shows how you can connect multiple vApps together using an Organization network.
This final diagram demonstrates how the three network types all fit together. You can see in the diagram below we have multiple vApps connected to an Org network which is subsequently connected to an External network providing access to the physical network external to the vCloud.
So we have mentioned them a couple of times now;
What are Network Pools?
Network Pools are a collection of isolated, Layer 2 networks that can be used to create Organization and vApp Networks on-demand and are available to both the Providers and Consumers. The Provider or Cloud Admin creates a network pool before they can be utilized.
There are three types of Network pools that are used in vCloud Director. These are:
- Port group-backed
- vCloud Network Isolation-backed (vCD-NI)
Port group backed network pools
- Preconfigured port groups at the vSphere layer
- Assign meaningful names so its obvious what is being mapped
- If using vSS portgroups, they must exist on all hosts in the cluster
How it works
- The system administrator manually creates the port groups.
- When creating the network pool, you are given a list of unused port groups that exist in the cluster.
- Works with all types of vSwitches.
- Requires manual work or orchestration to create all of the portgroups
- Portgroups needs to be keep in sync on a vSS
- To ensure isolation portgroups rely on VLANs for L2 isolation
The provider or cloud admin is responsible for creating pre-provisioned portgroups on either a Standard vSwitch or a Distributed vSwitch in vSphere. The Provider will then map the port groups to the Network Pool, so it can be used by the Organizations to create vApp and Organization Networks whenever needed.
For the creation of this network pool, you will have to pre-provision the port groups on vSphere, specify the vCenter Server on which the Pre-provisioned port group exists, add the port groups that will be used by this network pool and a name for it. This is ok for a limited number, but does cause a challenge from a management perspective.
VLAN backed network pools
- A vDS that’s connected to all hosts in your cluster
- A range of unused VLANs
How it works
- vCD admin creates the network pool and chooses an “Organization” vDS to attach it to, then provides a range of valid VLANs, for example, 10 – 15.
- When an isolated network is needed, vCD will automatically create a portgroup on the vDS and assign it one of the unused VLAN numbers.
- Many isolated portgroups can coexist on the same vDS because they are isolated by the VLAN tag
- Isolated networks
- Requires VLANs to exist in the physical network hardware (physical switches)
- VLANs are limited to 4096 and depending on your design, the pool can quickly run out
In VLAN-backed, the Provider is responsible for creating a physical network with a range of VLANs and trunk them accordingly to all the hosts. The Provider will then map the DvS along with the range of VLANs to the VLAN-backed Network Pool, so it can be used by the Organizations to create vApp and Organization Networks whenever needed. Each time a vApp or an Organization Network is created, the Network Pool will create a dvportgroup on the DvS and assign one of the VLANs from the range specified. Each time a vApp or an Organization Network is destroyed, the VLAN ID will be returned to the Network Pool, so it can be available for others.
For the creation of this network pool, you will have to provide a range of VLAN IDs and the respective DvS which is connected to the uplink ports that are trunked with the range of VLANs and a name for it.
vCloud Network Isolation (vCDNI) backed network pools
- A vDS that’s connected to all hosts in your cluster.
How it works:
- vCD creates an overlay “transport” network for each isolated network to carry encapsulated traffic
- Each overlay network is assigned a Network ID number.
- Encapsulation contains source and destination MAC addresses of ESXi hosts where VM endpoints reside as well as the Network ID
- ESXi host strips the vCD-NI packet to expose the VM source and destination MAC addressed packet that is delivered to the destination VM
- Does not have to use VLANs.
- Allows on-demand creation of networks by the consumer
- No management overhead required to pre-provision multiple port groups or VLANs
- Small performance overhead due to encapsulation (dvFilter) runs at around 1% CPU utilization.
- Added MAC header require an increase in MTU same as in MPLS networks
Chris Colotti and I like to describe this network pool type as being the one “That makes Cloud, Cloud”. It enables you to create on-demand networks as and when they are required. The standard practice to create vCDNI networks is to use a VLAN as a transport layer. You create this VLAN isolated and non-routable and only accessible by the hosts providing your vCloud resources. This network pool then uses this transport layer to pass the encapsulated traffic to the hosts.
Feeling better? Hopefully this has become clearer now.
So how does all these fit together?
The following diagram shows how the different layers of networks can be connected together:
Quick Disclaimer: I take no credit for the diagrams in this article. These have been created internally at VMware and have been used extensively throughout the company.
This is the end of Part 4 covering the vCloud Director networking concepts. Part 5 will discuss catalogues and best practices for setting up organisations.