vCloud Catalogs, Networking, and External Dependencies

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.