postheadericon Diagram: VMware vCloud Director Networking Architecture

If we are gonna perform Inception then we need imagination. An elegant solution for keeping track of reality – The “Inception” Movie.

 

Before I introduce this new diagram to you, I would like to make a bold statement: No matter how complex this diagram will look to you from the first glance, I can tell you that you’ve been practicing all its core technical concepts for a quite long time. You will just need a bit of imagination and I guarantee to you that everything will make a perfect sense faster than you can imagine. Read on…

Let’s go back to the very first VMware product that has changed the way we think in our IT industry – Workstation! When you create a new virtual machine in Workstation, you get four options for networking:

  • Bridged connection – a pass-through network to the outside world.
  • NAT’ed connection – a network translated connection.
  • Host-only connection – a private network isolated from the outside world.
  • None – no network at all.

Guess what? that’s the core technical concepts I’ve been talking about. Here are the new names that we will be using from now on when we refer to vCD (in the same order):

  • Direct connection
  • Routed connection.
  • Isolated (private)
  • None (no network)

Now, have you seen the “Inception” movie? (if you haven’t, you missed one of the greatest movies in this decade!) Do you remember the layer of dreams in that movie? Well, that is somehow what we have here. Imagine your virtual machines running in different layers of dreams networks, and depending on which layer you are looking at, it might be direct, routed or isolated. Let’s see that from a closer look:

  • First Layer: the real world – this is the actual physical network which we are in most cases not concerned about.
  • Second Layer: the vNetwork Standard Switch, Distributed Switch or even Cisco Nexus 1000V.
  • Third Layer: the External network – this is sort of your gateway to the outer world.
  • Forth Layer: the Organization network – this is sort of the gatekeeper for your VMs. It will always show you what is your logical boundaries.
  • Fifth and last layer: the vApp Network – this is the ultimate end your VM can reach (think LIMBO!)

Now that you have these basic concepts in mind, let’s see what we have in this diagram:

  • This is an A2 size diagram. I’ve really tried my best to keep it in the A3 scale but it’s just not possible with all this amount of information in one place.
  • The diagram covers nearly all the networking options of the vCD but from a “Private Cloud” perspective. In the world of Public Clouds this might be a bit different to layout (which i will do in the future) but the core concepts remains exactly the same.
  • The diagram comes with some text describing the various components and elements. I’m introducing this for the first time here to help you understand what you are looking at instantly without taking your focus away from the diagram.
  • You will see a different PDF layers in the diagram, you can hide/show them as you need. Example: when you are having a closer look into a specific area in the diag, you might find the descriptions useful to have while they might be a bit distracting if you are zooming out to have a holistic view of the diagram.
  • You will see the actual screens of the vCenter networking – the vSS, vDS and the different port groups. Not just that, you will actually see how the VMs in your cloud ultimately look like in vCenter. Add to that all the other components like the External/Organization networks as well as the vShield Edge devices. Of course i’m taking just examples of everything in most cases to avoid the complexity.
  • I’ve included as well the screens of the vCloud Director to show you how the Network Pools looks like along with the other panels of the External and Organization networks.
  • The IP addresses can play a very important role towards your understanding on how all these vApps communicate together. For example, when you see two vApps sharing the same OrgNetwork and still have the exact same IP addressing, it automatically means that they are routed through an edge device.
  • I included three connectivity examples for the outside world of your private cloud. A production cloud, an Internet cloud and an MPLS cloud. Please note that these are just examples not the only options you can have. This is something that can be very specific from a customer use case to another.
  • Last but not least, the vApp networks are laid out like that to fit the best view in the diagram. This is not an attempt to tell you how you should run your vApps but rather show you the different options you have. Again, this is something that is very specific to the customer use cases and requirements.

In the future networking posts on vCD i will start going deeper in the discussion and reference the examples shown in this diagram all the way through. I encourage you to print out this diagram and keep it somewhere near your home/office desk and have a glance through it from time to time. There is nothing better than visualizing something that is as complex rich as the vCD networking. I highly recommend also checking out Duncan Epping’s article on vCD networking, this is a must read for all the vCD newbies.

One more thing. I’d like to give some credit to my colleague at VMware, Massimo Re Ferre’, for showing me the way to understand this great networking topic. Massimo along with Eddie Dinel, Mike D and Vishal Kumar, presented together one of the most interesting presentations I’ve attended for vCD when it was still in Beta. I believe parts of this great presentation have been divided into more than one session in VMworld 2010, so I urge you to go and have a look into the recordings when the sessions are available online.

UPDATE: (14-09-2010): The networking part of the presentation I’ve mentioned above has been re-written by the master at this link. Another MUST-READ.

  • William Li
    I'm wondering if those 192.168.2.x address should be 192.168.1.x since they seems to be part of Org Network of OrgNet-ITDev-Isolated?
  • Not sure which vApp you are referring to (I will actually number them in the next update), but in general, it’s valid to have a vAppNetwork with a different IP addressing from its OrgNet if the former is using an Edge device to NAT it’s traffic down to the OrgNet.
  • William Li
    Now I understand what you said. I was referring to the scenario to have vApp fenced within Org Network. Your diagram implies that vApp Network was created and then connected to Org Networks, approach is different, end result seems to be similiar, looks like I have more scenarios to try on ;-)

    The vApp network gets created on the fly and can be defined with any IP ranges, biggest question is how does it work? Is it associated with any network resource? Imaging VMs in same vApp may be on different ESX hosts, the traffic flows through physical switch, anything needs to be done on physical switch in order to get this work?

    Thanks!
  • Good questions, here are some clarifications:

    - The vApp Networks (like the OrgNetworks) consume their network resources from what we call “Network Pools”. It’s like a predefined network templates if you will.

    - You need a special agent called “vslad” running on the physical hosts in order to do this cross-host-fencing mechanism. This agent is auto deployed when the vCD prepares the ESX hosts. There is no special or manual steps needed from you side.

  • William Li
    I was referring to fenced vApp. I tried myself with vApp connecting to External Org Ntwk Routed, fenced with NAT, VMs were assigned with internal IP from OrgNet-ITDev-Routed and vSE would NAT each internal IP with external IP in the same IP range i.e. 192.168.0.0/24.

    I'm trying more scenarios.
  • Hi William,

    It doesn’t matter what IP addressing you will be using inside the vApp Network if you are going to NAT it. It’s isolated anyways so there will be no conflict with the downstream OrgNetwork.
  • Hany,
    You should have a line connecting VLAN-backed network pools to Cisco Nexus 1000V. The only network pool type not yet supported by Nexus 1000V is VCD-NI.
    Great diagram!!

    Cheers,
    Brad
  • Hi Brad,

    Many thanks for the feedback! I’m very glad you liked the diagram!
    As far as I know, vCD currently supports only the Portgroup-backed network pools with Cisco Nexus 1000V. The vCNI and VLAN-backed NetPools are supported only with the vNetwork Distributed Switch.

    Regards
  • Hany,
    I just double checked my information and you are right! It looks like a jumped to an inaccurate conclusion. Nexus 1000V (at this time), as you stated, does not support VLAN-backed or vCNI network pools.
  • Thanks Brad, glad it’s confirmed from both sides, VMware and Cisco :)
  • Chad King
    VCAP or vCloud....? what to do, what to do...
blog comments powered by Disqus

My name is Hany Michael and I’m a Senior Consultant at VMware. I blog about various topics ranging from the core vSphere technologies all the way to the vCloud based products. (Read more)
Disclaimer
Any views or opinions expressed on this blog are strictly my own and not the opinions and views of my employer.