A list of some vCloud Director best practices

Posted by on April 16, 2012 in vCloud, VMware | 0 comments

These are some of the best practices that I have come across in my workings with vCloud Director. Some are from VMware, other bloggers and from my experiences. If it makes sense I will add some editorial to them so that it’s just not a generic statement that might not be clear to everyone.

I’ve broken them up into a few sections. Best practices which are design covenants and processes to follow. Helpful tips are items that can make your life easier or help with performance, and things to avoid are simply that. I will continue to add to these list as new items come up. If you have any suggestions drop me a note or leave a comment.

Best Practices:

  • Connect a single provider datacenter with a vSphere cluster when possible rather than a resource pool. Using resource pools that further divide up the resources of clusters provides and extra layer of management for admins and increases your risk of affecting performance if settings are not correct for a particular resource pool.
  • Create a separate management cluster for the vCenter that controls resources clusters for vCloud, and other infrastructure services used to support vCloud.
    – Management components are separate from the resources they are managing
    – The overhead for cloud consumer resources is minimized. Resources allocated for cloud use have little overhead reserved. For example, cloud resource groups do not host vCenter VMs
    – Resources are dedicated to the cloud. Resources are consistently and transparently managed and carved up and scaled horizontally
    – Troubleshooting and problem resolution are quicker as management components are strictly contained in a relatively small and manageable management cluster
  • Create an organization with a pay per use vDC to store your global catalog vApp templates in. This will not consume any resources from the cluster because the vApps are never powered on.
  • To determine the number of vCloud director cells need use the following formula.  ( number of cell instances = n+1 where n is the number of vCenter server instances ) If your vCenter servers are small meaning less than 2000 VMs you can have a single vCloud cell manage several vCenter servers. ( number of cell instances = n/3000 + 1 where n is the number of expected powered on VMs)
  • Do not mix tiers of storage within a single provider datacenter

 

Helpful Tips:

  • If you have VMs that are do not generate High I/O-you can consider using Fast Provisioning (linked clones) to save on storage space and faster provisioning
  • Make sure to size your NFS volume attached to vCloud director cells large enough for concurrent events that might take place in your design. Refer to great post by Chris Colotti about when cells would use NFS.
  • When you crate a Pay as you go vDC you will be asked to set the default  vCPU speed for new vApps being provisioned. By default its a very low amount (.26Ghz), you will need to adjust for you environment. There are two great blog posts here and here about this topic.
  • vCloud limits linked clone length to 30 and performance can be affected as VMs hit this limit. If you are looking to find out the lengths of your linked clone chains William Lam wrote a script to do just this.
  • You can view the chain length of a specific VM by looking at its properties within vCloud dashboard.
  • Be mindful when choosing the reservation levels for CPU and Memory when creating Org vDCs. You may think going with a lower percentage of commitment to allow you to over provision is a OK strategy. But these reservation values are very pivotal when calculating the values that HA admission control uses for being able to restart VMs after a host failure. If you commit too low you may not be able to restart all the VMs in your vDCs. If you need more details about admission control I suggest reading Duncan’s post on HA.

 

Things to Avoid:

  •  If using fast provisioning (linked clones) on a VMFS datastore limit cluster nodes to eight or less.
  • Be aware that there is a chance to hit the snapshot chain length limit. If the current clone has become very slow compared to the prior clone, the clone may have hit the snapshot chain length limit 30. This can be resolved by virtual machine consolation.
  • When adding an existing vSphere cluster as a Provider vDC in vCloud beware that when VCD goes to prep the hosts and install the agents it wants to prepare all the hosts at once, rather then stagger them.  You might try to use a bad password. Then after the failure, go to the hosts list and prepare them one at a time.

 

About Brian Suhr

Brian is a VCDX5-DCV and a Sr. Tech Marketing Engineer at Nutanix and owner of this website. He is active in the VMware community and helps lead the Chicago VMUG group. Specializing in VDI and Cloud project designs. Awarded VMware vExpert status 6 years for 2016 - 2011. VCP3, VCP5, VCP5-Iaas, VCP-Cloud, VCAP-DTD, VCAP5-DCD, VCAP5-DCA, VCA-DT, VCP5-DT, Cisco UCS Design

0 Comments

Trackbacks/Pingbacks

  1. Top VMware vShield App best practices list | Virtualization Tips - [...] reading my list of vCloud best practices when you are done with this list, since they are used together …

Leave a Reply

%d bloggers like this: