In a previous post on my blog I wrote about the experience of cloning an entire virtual infrastructure by leveraging NetApp FlexClone. Once that was complete I began planning the design of the new development environment.
Background
The only hard requirement was that all production servers need to be available in a segregated lab. Simple enough. My problem was that such a lab did not take into account the various network zones that existed in real life. Now, if all you are doing is testing updates, upgrade scenarios and functionality, it may be fine. But if you want to simulate a production environment and intend to provide end users with access to evaluate performance and usability, the setup is simply inaccurate.
For example, a lab I had seen in the past made use of a single network segment. On this one network were placed “high security” database servers, usual “production” servers and desktop workstations for end users. Needless to say, this was not the same networking that existed in reality. The real production setup included multiple clusters, each dedicated to a specific network zone and each segregated by various firewalls, IPS appliances and strict access controls.
The testing in that scenario was great. Everyone loved it. But once the servers were deployed into production, things slowed down. Suddenly the access was not as smooth. The response time of the application was noticeably longer from the end user desktops. The app servers were being disconnected from the secure databases. Great big holes in the firewall were being requested to allow for uninterrupted traffic to flow. Yes, the network was not taken into account when the dev environment was built.
The Challenge
It sounds funny, but I wanted to introduce into the development environment some of the difficulties that existed in the real production environment. The challenge was that while the production had a variety of security appliances and dedicated VMware clusters, the simulated development environment was given just two ESXi servers.
How was I going to create the various zones, each in a separate subnet, enforce the required minimal communication and still make use of the features afforded by a cluster like vMotion and DRS?
vDS Private VLANs
Note: Before I offer a very brief explanation of private VLANs I just have to remind you that private VLANs are only available on the vNetwork Distributed Switch. The Distributed Switch is provided as part of Enterprise+ licensing.
If you are new to Private VLANs you may find the explanation a bit confusing. This is normal. I assure you that the concept is in fact very simple and straight forward. You may simply need to draw it out on paper to understand how the traffic will flow.
There are three types of Private VLANs: Promiscuous, Community and Isolated.
Each one has a specific set of characteristics and any VM placed within one will take on the appropriate features and/or limitations.
Promiscuous -
VMs in a Promiscuous VLAN can communicate with any other VLAN. Nothing complicated. They talk to anyone they can reach.
Promiscuous VLANS are always the first type of Private VLAN created, this is to allow the other Private VLANs a method of communicating back. This happens by default when you first create a Private VLAN.
Promiscuous VLANs will often be tagged with the same VLAN id being used for the VM Port Group. That will allow for a machine in the Promiscuous VLAN to communicate both outside with non Private networks and inside to the other Private VLANs.
Community-
VMs in a Community VLAN can communicate with other VMs in the same Community VLAN and with VMs in a Promiscuous VLAN.
Isolated-
VMs in an Isolated VLAN can communicate only with the Promiscuous VLAN. Machines placed into Isolated VLANs cannot communicate with each other nor with machines in a Community VLAN.
I know, it’s not easy to grasp what all that means. Let’s look at a diagram.
Notice how each VLAN is a member of the Promiscuous VLAN as well.
Now back to the dev lab.
The Design
After I drew what it was I wanted to achieve, I was happy to realize that I had a use case for Private VLANs. This allowed me to use the existing IP subnets that were configured on the cloned machines, to guarantee the lab would not “leak” into production and to maintain the accurate access controls between the zones.
Inside the Promiscuous VLAN I placed a virtual appliance firewall that was given interfaces on all the VLANs. Static routes were created where required. The rules used on production firewalls were created on the virtual appliance, thus allowing only authorized communication to occur. All machines tagged with the Private VLAN ids were forbidden from passing through the firewall up into the “real” network.
On the physical side, the only requirement was to create all Private VLAN ids on the Switch and add them to the trunk connecting the hosts. Thus machines in the Private VLANs could still be vMotioned.
Here is a rough, sanitized diagram of what I did:
I was very happy with the design and being able to use Private VLANs. I know there were ways to achieve the same end result but I wanted to use the Private VLANs. They are definitely under utilized by most.
This became even more clear to me when I was looking for use cases for them. There are practically none out there except the DMZ use case.
I hope anyone looking to use Private VLANs will stumble on to this. I would have been happy to read some more experiences and use cases before I implemented my design but as I said, there are only a hand full of people writing about them.
Have you had any experiences with Virtual Private VLANs? What use cases have you found for them? Drop a line and we can all learn some more.