Valentin Hamburger

The Programmable Datacenter - Advanced NSX Functions

Blog Post created by Valentin Hamburger Employee on Oct 13, 2016

When old meets new

In my previous post I was sharing how easy it is to install NSX on top of UCP Director using its unique and built in management

and automation functions. This time I want to share a real world networking use case. A lot of customers who have implemented NSX

or who are in the process of implementing it still have traditional networking in place. Instant switching is not really possible since all

the VMs have to be migrated thoughtfully and without disruption if possible.

 

 

However, there might still be physical workload with no option for a direct connect "virtual wire" (an NSX enabled virtual network).

UCP Director fully supports bare metal deployments. The bare metal deployment within Director is able to install a server running
only an OS (no Hypervisor underneath) right out of vCenter.

This might be shocking news for some vSphere administrators in the first place, but it is actually quite handy!

BareMetal.png

Figure 1: UCP Bare metal Blade in VMware vCenter

 

Since you can now manage your entire datacenter operations out of one single control interface, in this case: vCenter. UCP Director also supports
its own GUI if vCenter might be having troubles or is not the tool of choice for bare metal deployments. However, a datacenter is a diverse place and
having the option to manage as many assets as possible out of one console might be exactly what operators have been waiting for.

When one of these blades gets deployed, they will be most likely attached to the network using good old VLANs. Now, the question is, how

do you unify this old world with the shiny new NSX world?

 

Living on the Edge

NSX has the ability to connect to the outside world (outside of NSX) through a so called "Edge Services Gateway". Since this is a bit of a tongue twister many

call it simply ESG. The second important function NSX has to offer to solve our dilemma is the so called Distributed Logical Router or DLR.

Together they form a dream team when it comes to network connectivity. The ESG can have an active connection into the legacy VLAN world, while the DLR

can connect to all the virtual wires and provide them a route to the physical network.


This is a powerful mix when connecting two different networks:

  • One is a VLAN housing physical servers with its own IP Subnet
  • One is a virtual wire housing VMs also with its own IP Subnet

 

The end result could look a little bit like the following graphic.

(Beware - techy content ahead...)

P2VNetwork.pngAt the bottom of this picture you will find the VMs on the virtual wire happily using 172.16.0.0 as their network.

 

The next thing to look at is the DLR which is able to route between the transport (often also referred to as "uplink") network and the VM network. In this picture the uplink network is 172.18.0.0.

 

At the top of all NSX components sits the Edge Services Gateway which is providing access to the physical network (amusing to say that and then refer to VLANs).
The ESG shares an IP address in the physical network to bridge it - in this case it is 192.168.0.254 in VLAN 100.

 

 

Everything connects to the physical switch inside UCP director. Obviously the ESG will run on a vSphere cluster and then the vSphere cluster connects physically to that switch - but the picture is less busy when you only look at the network components.

 

Finally the physical UCP Blade connects to the same switch. During deployment it is brought into the same VLAN and UCP Director will also ask for an IP Address to access the blade. No manual interaction required.

 

What is the Programmable part?

The beauty of UCP Director and NSX is that: both have nice APIs to play with. These APIs will enable a wide spectrum of possibilities with this combination. One can deploy blades on demand in a "not yet" existing VLAN and then re-configure the ESG to access this VLAN in order to establish connectivity for certain VMs or applications.

 

Additionally, it might be possible to control the access to physical resources based on NSX policies (some other cool features of NSX). Instead of having static firewall rules, the policy is applied on the VM level. So only this VM can access the physical network.

 

 

 

Cloud providers will have their fair share of fun with this, since it could basically enable them to put the physical blade in a tenant. This can be done by simply allowing only
this tenant to access specific physical blades. All of this fully automated using UCP Director and NSX APIs.


There are a ton of other use cases where this model might make a lot of sense. However, the nice thing about UCP Director is though that all the VLAN automation is baked
into the product, all we need to do is let NSX know (via APIs) that there is a new VLAN.

 

Of course this is only a schematic graphic and you want to make sure that OSPF (Open Shortest Path First) or BGP (Border Gateway Protocol) is configured
in your physical network and the NSX DLR. The underlay (the physical part of the network) network is still an important part and routing needs to work flawlessly.

 

Call to action

Stay tuned into this blog to find out more what we can do with NSX and our latest family member, Hitachi Enterprise Cloud. All this will be available to view at VMworld Europe.
Do visit us at VMworld at the HDS Stand #403 in the Solution Exchange! Looking forward to meeting you there!

Outcomes