Site icon Chris Colotti's Blog

vCloud Catalogs, Networking, and External Dependencies

Chris Colotti

There is often some confusion by customers that I speak to about VMware vCloud about how and where the “Catalogs” function becomes useful as well as how we deal with external dependancies, specifically Active Directory.  Mainly the catalog question stems from the traditional thinking of vCenter “Templates” and what we know and love about them.  However in reality although you can create basic templates in the catalogs of vCloud Director, there is some much more powerful things you could potentially do with them.  We also need to see how different catalog items can be leveraged and deployed, built upon, and re-submitted back to the same or even a different catalog.  One key thing to remember is that unlike vCenter templates, items in the vCloud Director catalogs that are published can be deployed to ANY vCenter that is controlled by vCloud Director.

Let’s stop and think aout that for just a minute as it relates to the enterprise private cloud specifically.  Up to now we have never really seen a good way to share templates across multiple vCenters.  Trust me I have tried some creative means to that end, and all of them have fallen short, mostly because each vCenter has it’s own database.  Now with vCloud Director in place you can upload items to the catalog that can be made available to multiple Organizations and therefore deployed to any number of vCenters hosting Virtual Datacenters.  This also means you are maintaing a minimal number of these items for updates, unlike with vCenter templates where each vCenter must have it’s own registered version of the VM.  So all this got me thinking about the Enterprise Customers and what really becomes useful in the catalog constructs.  Catalogs combined with the power of the vCloud network stack can provide some very interesting use cases for your POC but also some interesting challenges with those pesky existing external dependencies.

The “Admin” or “Master” Catalogs

Generally I see most customer stand up what they call the “Master” or “Admin” Catalog in vCloud Director hosted inside a “IT” organization with a specific vDC.  If you have noticed when you add items to the catalog you still need to specific a vDC to host the vApps or ISO Images.  Based on showback and chargeback most folks like to have these in their own vDC so they can track usage to the “IT Service Provider”, but not actually charge ant particular Organization.  This Organization also has rights to publish their catalogs to everyone else to consume.  This approach is to provide approved vApps to the consumers that are maintained by someone in IT.  Now the question comes up of how many of these master catalogs should we have?  Well some companies have one others do a breakdown like this so they can neatly organize things and the initial catalogs are usually SINGLE Virtual Machine vApps.

Single Virtual Machine vApp Examples:

Example of Published "Master" Catalogs (Click to Enlarge)

We will talk about ways to get all these built from a process flow at a later date but it is based on a building block approach.  I want to also touch on a concept of what I call “Utility” base vApps that usually end up being more than one Virtual Machine in the vApp and are setup to be used for specific purposes.  These vApps may only be allowed to be deployed by a system admin to an organization so they may or may not be published.  The intent of these Master Catalog items is to provide system user controlled functions so the users in the Organization can leverage them, but not make changes to them.  The two that really stand out are Active Directory and some sort of web load balancing, (Provided you have not upgraded your vShield licensing to support that feature).

Multi-Virtual Machine vApps:

Enterprise vApp Networking Concepts:

In order to really understand how to bring these two things together let’s review a little of the vCloud Director networking concepts and you might see why this has become a head scratcher for many enterprises deploying a private cloud.  For the service providers hosting customers this is usually not a big issue and makes the most sense because isolation is cut and dry.  For the purposes of the discussion et’s focus on Active Directory since that is the most common thing that comes up.  I think we have all see the diagram below in one form or another but what I have added is what we sometimes forget especially in an enterprise.  There are actual Active Directory servers on the corporate network somewhere in most cases I have run into.  However from the diagram below…..only ONE Virtual machine can actually reach AD.  The others are by definition of vCloud networking Isolated on the Org network as indicated by the connections.  Because of this most enterprises doing a POC tend to make all their vApp connections “Direct External” connections to the corporate network in some way so that Virtual Machines can join the domain or even get to DNS.  So when we look at this picture, what can we do to make things work a little bit better while maintaining network abstraction between organizations in an enterprise.

<!– –>

Using A Direct External Network

The first and most obvious as well as easiest is to create what we call “Direct External” Connections to the corporate network.  In some cases depending on the size of the POC, we ask for an external routable VLAN per organization so each organizations external IP space and VLAN is separate.  Because of the nature of an external network these are also by default Port Group Backed and need to be created in vCenter first.  These are just like every other “production” network in the enterprise but they are considered “External” to the cloud constructs  this allows simple, easy connectivity for all vApps to access existing dependencies like Active Directory, and allow the usual means of access to SSH or RDP.  Essentially it is just like having VM’s on the same networks……sounds like a plan, right?

Well there is a pro and con to everything.  Although this method is easy for the enterprises to follow, by default it is still binding all vCloud based vApps to the physical infrastructure and doe snot have very much flexibility.  It requires vSphere administrator to setup port groups, and network administrators to add VLAN trunks, basically no different than a standard vSphere implementation.  So does easy equal the right design?  Maybe so for some POC’s but I would submit we may want to try out the other methods to truly take advantage of the networking vCloud has to offer.  We can still use VLAN Backed Pools and VCD-NI Pools to provide isolated networks to vApps that we want to Isolate on vApp Networks, but generally the Organization Network is the same as the production network.

Using A vShield Edge NAT Routed Network

The other most common option is to put each organization behind their own NAT vShield Edge to not only minimize the External Network IP address usage but also to gain the true multi-tenancy of the organization.  This allows for multiple VLAN’s or VCD-NI networks to be created for each organization as well as the vApps themselves for fencing purposes.  Each vApp on the NAT routed organization network can still reach Active Directory for joining the domain technically, however the isolated network they are on may not be known to the Sites and Services configuration.  Also there is no way to route back to that isolated network because by default, well, it is isolated.  The core network will not know how to reach it unless static routes are configured and even then the vShield Edge firewall rules will not allow traffic through by default.

Agin this model has both pros and cons to it.  The pro is that the isolation is there, the firewalls are in place, however getting back to the VM’s for SSH and RDP although not impossible is a challenge.  You can setup jump boxes, additional external addresses to reach some of them but if you have a lot of vApps it can be tricky.  In this model we usually default to the Remote Console Connections through vCloud Director for access since it will almost always work.  That however is also a process change for many administrators, but not a giant thing to grasp over time.

<!– –>

Moving External Dependancies Into an Organization

One way to possibly address this is to use almost the same thing we would actually do in a hybrid model.  If your company was hosting a private cloud and you had contracted some hosted vCloud Datacenter services my guess is the first thing you would stand up in the provider would be a couple AD servers for you’re companies Organization inside you’re secure multi-tenant environment.  Your organization would be then connected to corporate most likely via VPN or direct pipe similar to any offsite or secondary datacenter.  Ad may look something like this.

Here what we can see is that your Company’s Organization at the hosted service provider would get some kind of connection to your isolated Organization.  Once that network is established you most likely would stand up dependencies like Active Directory on that NAT routed external network and assign that network in Sites and Services.  Once that is in place you can then bring up vApps on the SAME NAT routed network, OR you can also have additional isolated Internal only networks.  Maybe there are vApps hosted here that do not need any connections directly back to the home office and the entire vApp stack is hosted.  However it may still need access to Corporate DNS and authentication, so you can also tie the Active directory servers to that network as well.  Take this model into account now when thinking about a private only model with separate organizations.  The concept could in fact be similar using some of the utility vApps we talked about earlier.

We use the Master Catalog to deploy a vApp for Active Directory and DNS for use INSIDE the organization which can then be used on the Org Internal Network static pools for DNS allocation.  Post deployment will require configuration of the vApp to make it a domain controller.  What we then see below is a picture that makes much more sense.  Essentially the Organization gets a vApp that is owned and controlled by the “System” that is deployed and used by the organization.  This also allow the other vApps in the organization to authenticate within the organization and could potentially support moving the entire org to a hybrid model.  Some customers may feel this adds to the Active Directory Schema, but if each Organization is in effect like a new “Site” with it’s own networking, then could this solution be viable?  We would essentially only register the external NIC on the AD Virtual Machine in DNS and then configure the static pool for the org to use the Org network IP addresses.  Now in theory the Org based machines can join AD as long as a reverse DNS lookup zone exists for the Organization Network.

What we are now left with is massive flexibility inside an organization.  This is the true power fo the vCloud networking combined with Service Catalog items.  Here we can see we have a lot of options to connect to vApps.  We can connect some as Direct External if we cannot bring the dependencies in, like a Physical Load Balancer.  We also have an Organization only Internal Network with access to it’s own Active Directory or other Organization based dependencies.  Each AD server is only represented connected to NAT routed or Direct External as an option only one or the other would be used.  We also have the ability to further isolate vApps themselves, or connect them to the Internal Organization network in the same means as Direct or NAT routed.

Summary and Conclusions

What we see by experimenting with the networking and catalog constructs is we can build a robust private cloud, that is also prepared for a hybrid situation possibly in the future.  If we take the easy Direct External connection route, we are limiting not only our options for future isolation but we are still heavily bound to the physical infrastructure.  There are those that would argue or question if having that level of physical binding is still “Cloud”.  I have simply seen a lot of POC’s go the easy route because they simply cannot wrap their head’s around how we get from point “A” to point “B”.  I admit is is not easy, it takes work to think about it and determine what the best options are.  My personal opinion is to setup as many options as you can so you can test out the different aspects of the catalogs and networks.  I think those two areas are the least examined in depth during a POC usually based on time limitations and the obvious thought that is required.  You really need to know networking 101 before you even start this process.

I hope I have not left anyone with more questions than answers.  the goal here is to provide some insight and education if you are currently doing your own POC or a vCloud Accelerator or Jumpstart with VMware or a partner.  Take some time to think about how a private cloud can utilize the multi-tenancy constructs even inside the same physical datacenter.  Maybe it provides value you were not thinking of even though it may add a little complexity.  It is worth mentioning not all the challenges are solved by some of these ideas.  vShield edge is still a NAT routed firewall and we need to deal with allowing access through it if it is in place.

Exit mobile version