We are finally going to dive into VMware vCloud Director vApps. Yeah! vApps consist of a single or multiple virtual machines that are packaged and maintained as a single entity. vApps act like a wrapper for multi-tier applications, for example if you had a web application for client information called Contact that consisted of 3 web servers, 1 application server, and 1 database server they would be contained in a vApp cell.
This diagram gives a depiction of the Contact vApp:
vApps aren't new to the VMware ecosystem, they existed in vSphere, but the entire vCloud Director infrastructure is designed to work with vApps. Even if you deploy a single virtual machine it will be in a vApp.
Your vApps are going to map to Organization vDCs that are supplied by the Cloud Provider (infrastructure staff). In this example we have allocated a subset of the Provider vDC resources in Gold, Silver, and Bronze to the Sales Organization. The Organization Administrator can then place the vApp applications in the appropriate Organization vDC based on SLEs provided by the cloud provider.
One really nice aspect of vApps, it uses the open virtualization format (OVF). OVF is a platform independent, extensible, and open packaging and distribution format for virtual machines. OVF captures meta data about the VMs which allows you to import and export them between clouds in a standard format.
This enables enterprise organizations to encapsulate applications and their dependencies, and then move them to other datacenter cites and private cloud providers such as Terramark or Bluerock. In order to take advantage of this scenario you need to setup your organization with an external organization network (nat/routed) which will deploy a vShield Edge. We will talk about networking in more detail in a future blog post.
A great situation for using a hybrid cloud would be for disaster recovery exercise. You could move your vApp out to a third party partner to validate that you can bring the application online in the event of a disaster. This saves your corporation a significant amount of capital because you are leasing the equipment from the provider instead of building out the server infrastructure that lies dormant for 10 months out of the year.
To copy your vApp to a private cloud provider you will use vCloud Connector. vCloud Connector is a virtual appliance that installs on vCenter Server that facilitates the migrations. vCloud Connector allows you to see and access vApps and templates on private and public clouds, work with VMs, vApps, and templates on other vSphere instances, and copy VMs, vApps, and templates between vSphere and vClouds.
vCloud Connector is still bound by the laws of physics, like I said in a previous blog post there really is no "bursting" to the cloud. Testing shows that even on an internal network it can take up to 40 minutes to move a vApp with a single VM between vCloud environments, and it requires an outage to the resources during the migration. That is fine when you are staging a disaster recovery environment or moving templates out to a provider, but there is no bursting an application to the cloud unless you setup storage replication.
This gives a basic overview of vApps in vCloud Director, in my next post we will talk about Catalogs and Fast Provisioning.
A great situation for using a hybrid cloud would be for disaster recovery exercise. You could move your vApp out to a third party partner to validate that you can bring the application online in the event of a disaster. This saves your corporation a significant amount of capital because you are leasing the equipment from the provider instead of building out the server infrastructure that lies dormant for 10 months out of the year.
To copy your vApp to a private cloud provider you will use vCloud Connector. vCloud Connector is a virtual appliance that installs on vCenter Server that facilitates the migrations. vCloud Connector allows you to see and access vApps and templates on private and public clouds, work with VMs, vApps, and templates on other vSphere instances, and copy VMs, vApps, and templates between vSphere and vClouds.
vCloud Connector is still bound by the laws of physics, like I said in a previous blog post there really is no "bursting" to the cloud. Testing shows that even on an internal network it can take up to 40 minutes to move a vApp with a single VM between vCloud environments, and it requires an outage to the resources during the migration. That is fine when you are staging a disaster recovery environment or moving templates out to a provider, but there is no bursting an application to the cloud unless you setup storage replication.
This gives a basic overview of vApps in vCloud Director, in my next post we will talk about Catalogs and Fast Provisioning.
