Earlier this week VMware announced VMware NSX – an upcoming offering that takes network virtualization to new levels. NSX appears to be somewhat of a fusion between Nicria’s SDN technology (acquired last year by VMware) and vCloud Network and Security (vCNS – formerly known as vShield App and Edge). Since I already had intentions to write a post about vCNS this seemed like the perfect opportunity to do so while taking a look at the new NSX solution at the same time. Before we begin exploring vCNS, let’s just take a quick step back.
SOFTWARE DEFINED EVERYTHING
About a year and a half ago, I wrote this post in an attempt to define cloud as abstraction leading to automation leading to agility. In a sense this is what SDN – Software Defined Networking – aims to do as well. First the server hardware (compute) layer was abstracted with hypervisors like ESXi, and now this concept is being extended into the area of networking (and also storage) to provide new opportunities for automation, orchestration and integration. Let’s start by taking a look at what vCNS is already offering today.
vCloud Network and Security (vCNS)
Originally VMware offered three different vShield products, but with the release of the vCloud Suite, the vShield App and vShield Edge solutions now constitute much of the vCNS product, along with support for VXLAN and integration into the vCloud ecosystem including vCloud Director and vCenter Server. vCNS Standard Edition is included with vCloud Suite Standard, while an upgrade to vCNS Advanced adds high availability (HA) for the virtual appliances, load balancing and data security capabilities.
Central to vCNS is the vShield appliance where all of the vCNS configuration is done via a web UI which is also exposed as a tab in the vSphere client. The vShield appliance has the ability to backup the entire vCNS configuration to an FTP/SFTP server on a regular basis, allowing you to deploy a new vShield appliance and then restore your configuration backup.
EDGE (not that guy from U2)
You can deploy Edge servers in your environment which are hardened virtual appliances which provide – well…edge services. You deploy Edge appliances from vShield manager and then – once properly configured – you can point your servers to them as gateways. Besides basic gateway services, the Edge appliances can also provide the following:
- Layer 3 firewall
- NAT Services
- Site-to-Site VPN (IPSEC)
- Web Load Balancing (Advanced Edition)
There is a lot of potential here. Some of you might be thinking “why should I use virtual for this”? There’s many answers and use cases here but some of the best examples involve multi-tenancy. Sure you can use dedicated hardware and/or VLANS for each tenant but this can be quite complex and may no longer be the most efficient approach. By virtualizing these edge services we now have logical (versus physical) boundaries which can lead to more scale, more automation and less complexity as tenants are added and removed.
vShield Edge and multi-tenancy
[click image to zoom]
Also I should quickly mention a lesser known feature which is the SSL VPN which since it uses common TCP ports you should be able to use it from networks where IPSEC might be restricted. You can quickly turn this feature on an Edge appliance and then access a VPN home page from which you can either expose internal websites or offer a full VPN client download – which I tried and worked flawlessly on my Windows 8 system.
APP (Virtual Layer 2 Firewall)
Like vShield Edge, vShield App is a hardened virtual appliance deployed from vShield manager, but this appliance is deployed on a per-host basis. You can optionally configure vShield App to “fail closed” meaning that traffic to VMs will be denied unless the vShield App firewall is available. To mitigate against this you can deploy a second appliance to work in an active/passive pair (HA requires advanced edition).
A quick sidebar on the virtual appliances – both Edge and App appliances can be deployed in active/passive pairs and there are different sized appliances based on the size of your network (the large appliances allocate 2 vCPUs each). Keep this mind from a resource perspective as you may need to reserve resources for a pair of large sized appliances.
Now that you have a layer-2 application firewall running on each host you now have many new possibilities on how to design your network. What’s great about vShield App is that your firewall rules are now abstracted from the IP addresses. Today most firewall rules have any affinity to each and every IP address – what if we could do this on a virtual machine basis, or even a VM folder or Resource Pool. Drop a VM into the “Web Tier” resource pool and suddenly in inherits the appropriate firewall rules that you’ve already defined – regardless of what the IP is. And if someone changes the IP inside the VM, the firewall policy is sustained at the VM level. Depending on the environment, this can provide many benefits ranging from a reduction in network hardware, to lower operational complexity and quicker execution. In some environments a traditional DMZ may no longer be necessary depending on what new design is settled on.
Another little sidebar but another nice extra available in vShield App is the ability to monitor your network flows. This can be done either at the host level (App) or at the gateway level (Edge), but even without any firewall rules you now have the ability to monitor your network flows at various points and see which protocols are using the most network traffic.
NSX – The Future
At a high level VMware’s NSX appears to be a fusion of Nicria’s Network Virtualization Platform (NVP) and the vCNS product we just discussed, along with a few twists. VMware acquired Nicria for $1.26 billion last year, and their Open vSwitches (OVS) do the packet pushing while the NVP Controller Cluster features a RESTful web API for managing and defining these virtual switches.
Below is a full slide from VMware introducing the concept of the NSX offerings which has a few interesting features. The support for OpenStack at the top is not really new, but the “multi-hypervisor” support at the bottom is. Since Nicria’s OVS is hypervisor agnostic (Xen, KVM, ESX) it would seem that NSX is now abstracted from even ESX.
[click to zoom]
There’s a few more hints in this VMware blog post on NSX
including mention of Layer 2 Gateway services, active/active HA (active/passive in vCNS today) and even mention of MPLS support. And of course you know VXLAN is going to be baked in as well. And remember the backup support in vShield Manager? Well it seems that the new NSX manager takes this a step further – allowing you perform VM-style snapshots of the entire network state and ecosystem for backup or even to revert a recent change (undo).
So many scenarios for this new paradigm, but here’s just one – the cloud on-ramp. You want to move some virtual machines from your datacenter to a vCloud provider, between providers or even VMware’s new Hybrid vCloud offering. Just deploy a gateway (edge) appliance in your datacenter and establish a site-to-site VPN to the hosting datacenter running NSX. Now start migrating those virtual machines!
VMware expects to launch NXS in the second half of this year, and having seen the benefits of vCNS I’m really excited about the possibilities and benefits that Software Defined Networking (SDN) with VMware NSX can provide. I suspect that VMware is also working on advancing “Software Defined Storage” as well and I hope to also share some thoughts on those possibilities in future posts.