Before we delve too deeply into vCloud Director we need to talk about one if its largest building blocks: the vApp. A vApp is a virtual application comprised of virtual machines, their networks and their policies. While vApps were concepts that were present previously in VMware Desktop, vCloud Express and Lab Manager they never truly represented isolated, independent virtual applications. This independence is the secret sauce and power of vCloud Director - here vApps work as complete environments that are completely isolated from other vApps.
Here's a great example: let's say you have an e-commerce application that is comprised three major tiers: a database server, two application servers, three web servers and their load balancer. They might have the following kind of layout:
|Type||Private Address||DMZ Address||Public Address||CPUs||Memory||Disk|
|Load Balancer||192.168.253.2||18.104.22.168||2 vCPUs||512 MB||20 GB|
|Web Server||10.0.0.3||192.168.253.3||2 vCPUs||1 GB||20 GB|
|Web Server||10.0.0.4||192.168.253.4||2 vCPUs||1 GB||20 GB|
|Web Server||10.0.0.5||192.168.253.5||2 vCPUs||1 GB||20 GB|
|Application Server||10.0.0.6||4 vCPUs||4 GB||40 GB|
|Application Server||10.0.0.7||4 vCPUs||4 GB||40 GB|
|Database Server||10.0.0.8||4 vCPUs||16 GB||120 GB|
This is a fairly typical layout but it still requires a bit of configuration. The application servers have to know the hostname or IP address of the database server, the HTTP servers have to know the addresses of the application servers and the load balancer needs to know how to farm out traffic to the HTTP servers. To help isolate and secure our applications we bridge three networks across one or two interfaces for each server. On top of that each tier has a slightly different hardware profile to ensure each server is appropriately sized to serve requests.
Let's assume we have spent the day building these virtual machines, installing the appropriate software stack and configuring each. Everything is finally perfect. Time to make some tea and celebrate? Not quite. You need a copy of this environment for quality assurance. And pre-production validation. And the developers want an environment of their own. Make that two... one for each scrum team. Now we're taking about seven virtual machines times five environments - a week and a half of operations time to build and configure 35 VMs.
At first glance a solution might be simply copying the virtual machines over and over again, however these cloned VMs would need to be re-mapped to appropriate networks, given a new set of non-conflicting addresses and then servers would need to be re-configued so they were talking to the appropriate servers. Assuming we push past that issue, what if a developer accidentally corrupts a guest filesystem? Do we keep snapshots of all 35 VMs and fill up the SAN just in case? If only there was a way to "snapshot" an entire environment along with its networks, policies, VMs and all.
Despair no more! Courtesy of vCloud Director, now entire environments can be captured as "vApps" that contain all the information about an environment and allow you to re-deploy it indefinitely. This gives you the power to freeze-dry an entire "rack" of servers, their managed switches and firewalls all into one logical, isolated unit.
vApps are entirely self-contained and isolated from each other so that IP addresses can no longer conflict. Previously you could not have two virtual machines with the same IP address within the same virtual data center - otherwise they would fight like rabid cat vampires. Since vCloud Director uses VMware's vShield technology to isolate layer 2 traffic and persist network policies, each vApp can have a number of private, vApp-only networks that never leak outside their environment. You can clone the environment detailed above five times in a row, never change a single IP address or configuration file and things will still work just fine.
Speaking of cloning, that's another fantastic feature of vApps. I can serialize my vApp as a template and add it to my own private catalog, then allow my development team to re-provision an environment on their very own. If someone needs to re-start from scratch they can now feel free and do it without bothering the operations team.
Even better - let's say I wanted to move this environment to a public cloud. Or another private cloud. Or to my desktop. Or burn it to a DVD. vApps export very neatly into the standard OVF format, allowing you to persist the entire environment to disk and copy it wherever you choose.
Just the vApp functionality of vCloud Director alone can save nearly two weeks of effort in the above scenario. Next week we will show everyone how BlueLock built even more functionality into vCloud Director; you can now increase your visibility into your virtualized inventory when you move it within the BlueLock Cloud!