VMware vCloud Director 1.5 Performance & Best Practices

VMware vCloud Director 1.5 gives enterprise organizations the ability to build secure private clouds that dramatically increase datacenter efficiency and business agility. Coupled with VMware vSphere, vCloud Director delivers cloud computing for existing datacenters by pooling virtual infrastructure resources and delivering them to users as catalog-based services. vCloud Director 1.5 helps you build agile infrastructure-as-a-service (IaaS) cloud environments that greatly accelerate the time-to-market for applications and responsiveness of IT organizations. vCloud Director 1.5 adds the following new features specific to accelerating application delivery in the cloud:

 

• Fast Provisioning  
• vCloud Custom Guest Data
• Expanded vCloud API and SDK
• vCloud API Query Service
• vCloud Messages
• Cisco Nexus 1000v Integration
• vSphere 5.0 Support
• Microsoft SQL Server Support
• Globalization
• vShield Five Tuple Firewall Rules
• Static Routing
• IPSec Site-to-Site VPN

 This white paper addresses three areas regarding vCloud Director performance:

• vCloud Director sizing guidelines and software requirements
• Best practices in performance and tuning  
• Performance characterization for key vCloud Director operations

Dowload the whitepaper

Get Started with vCloud Connector 1.5 – Part 1

The following is an excellent article on the latest version of vCloud Connector from Chris Colotti's personal blog...

vCloud Connector 1.5 Architecture

First I think it is important to understand the new architecture of vCloud Connector 1.5 as it differs greatly from 1.0.  Many who have played with both will see the differences out of the gate, but I wanted to also tie this to how I deployed the various components for testing.  Refer to the figure below which was taken from the vCloud Connector user guide.

vCloud Connector Server – The server component is the control and management point for vCloud Connector.  You really only need one server as long as it can connect to the various nodes.  In my case the server was hosted in my lab, on the management cluster for vCloud Director.  I did not host it inside my vCloud as a vapp simply because I did not see the need to.  I decided to treat it like any other management server workload supporting the vCloud Eco-System

vCloud Connector Node – The “nodes” are the 1:1 connection points managed by the server.  The 1:1 aspect is that you actually need a node per cloud, Organization, or vSphere instance you want to move workloads between.  So in my case I needed two nodes on premise and two nodes hosted at Virtacore.  These remote nodes were of course hosted in the cloud.  I needed two of them because their public cloud is made up of two datacenters, each with their own vCloud installation and thus two different API’s.  The nodes are also where the various exports happen during the process of the move and where you may need to increase the disk sizes, or mount them to NFS if you can.  In my case I connected all the nodes to either the SYSTEM level or the top-level of vSphere for testing.  In a hosted public cloud, you could need more nodes depending on the number or organizations you have as well as the number of datacenters.

vCloud.VMware.com – This is the remote web portal you can use to manage your various vCloud Connector servers in a single pane of glass.  There is some requirements to get connected to this which we will talk about in a little bit.

continue to article

Update on Monday, December 12, 2011 at 12:51 PM by Cloud Canuck

Here is a link to Part 2