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:
- Base Linux Operating Systems
- May include 32-bit and 64-bit versions
- Different Distributions
- Base Windows Operating Systems
- May include 32-bit and 64-bit versions
- Includes both Server and Desktop Operating Systems
- Linux Web Servers
- Apache or other web servers pre-installed
- Windows Web Servers
- Windows Database Servers
- May include various release like 2005 or 2008 preinstalled
- Oracle for Windows Pre-installed
- Linux Database Servers
- May include different Oracle versions installed
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:
- Windows Active Directory vApp
- Two windows machines with pre-requisites installed to run DCPROMO like DNS
- These would still require post deployment configuration
- Custom Virtual Disk configurations
- Usually connected to an “External” network on deployment
- Load Balancer vApp
- Two VIrtual Appliances for an Organization to use
- Usually connected to an “External” Network
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.