Wednesday, October 27, 2010

Resource Allocation Models in vCloud Director

While Resource Allocation Models are not one of the most exciting topics to come from VCD I think they are a critical one to understand because of the various effects they have on  Organizations and underlying Provider Virtual Datacenters.  Much of the power and flexibility of vCD comes from its ability to further abstract the objects at the vSphere virtualization layer including portgroups, datastores, Clusters, and Resource Pools.  So what is a Resource Allocation Model ?
Resource Allocation Models control exactly how resources are consumed in the underlying Provider Virtual Datacenters by the Organization Virtual Datacenters. 

When we are talking about the differences between Resource Allocation Models we are strictly talking about CPU and Memory.  You can define other consumption characteristics when you create your Org VDC such as storage and networks but the differences between the Models has to do with the diferent ways they handle CPU and RAM. 

When you create a new Organization VDC you must choose the underlying Provider VDC to draw resources from.  In essence you are matching the Service Level of the Organization VDC to the corresponding Provider VDC Service Level.


Once you have selected a Provider VDC you can select Next and you will have to choose a Resource Allocation Model.  This choice will determine how resources are consumed from the underlying Provider VDC by this Organization VDC.



Allocation Pool

Allocation Pool is the selection of a "chunk" or section of CPU and Memory for your Organization VDC but the reservation from the underlying Provider VDC of only a subset of those resources.  It is essentially resource thin provisioning.  For instance creating an Org VDC using Allocation Pool you would specify 24 GHz of CPU and 36 GB of RAM but using the percentages on the right you can specify how much of those resources need to be "reserved" for this Org VDC.



Pay-As-You-Go

Pay-As-You-Go (PAYG) is the consumption model that most people would probably equate with Cloud Computing.  It is a more granular consumption model based on the characteristics of individual vApps.  You can reserve 100% of the resources for each vApp or you can "thin provision" by specifying less than 100% for Guarantee.  This model allows for very good utilization of the underlying resources (Provider VDC's) while still providing the ability to Guarantee resources.




Reservation Pool

Reservation Pool is similar to Allocation Pool in that a "section" of CPU and Memory resources are selected for the Org VDC.  The one important difference is that as the name implies, there is no Thin Provisioning of resources and 100 percent of the resources specified are drawn down from the underlying Provider VDC. 


 One of the interesting characteristics of a Reservation Pool is that it allows for an additional level of configuration at the individual Virtual Machine level that exists within the vApp.  You will probably recognize the terminology (Shares, Reservations, Limits) which should give away how vCD is accomplishing the enforcement of these settings.  Essentially, you are allowed the ability to fine tune and prioritize workloads that exist in an Org VDC based on the Reservation Pool model.


I think my next post will be the practical application of these Resource Allocation Models in a vCD environment and which Models are good logical fits for different Service Level offerings.

Friday, October 22, 2010

vCD Networking Constructs

There have been many excellent posts on vCD networking.  Two in particular that helped me to quickly grasp some of the new concepts and objects effectively were Duncan's vCD - Networking Series and vCloud Director Networking for Dummies by Massimo.  I decided to approach the subject of vCD networking from a different angle and provide as concise a representation as possible.  I focused on the logical relationships and possibilities that exist between the different networking elements.  This can be a little difficult because of the total flexibility the Cloud Administrator has when configuring these network elements but here goes. . .

  1. External Network - This is a logical construct in vCD matched to a vSphere portgroup with vmnics connecting to the external network.  A colleague of mine described it best, saying it's "A network cable into and out of the Cloud".    
  2. Organization Network - This is the only mandatory network and it can take the following forms.
    1. External Direct - This is simply a bridged connection.  vApps on this network will have "direct" connectivity to the physical network just as if you plugged in a physical server connection to your physical network.
    2. External NAT/Routed - This is a NAT connection where there is Layer 2 isolation between this network and the External Network.  A vShield Edge device is deployed to provide NAT services in addition to firewall, DHCP, and more.
    3. Internal Isolated - A Layer 2 isolated network with no connectivity to other network segments.  If you choose to use DHCP services on this Isolated network than a vShield Edge device will be automatically deployed.
  3. vApp Network - Can be used to provide additional network isolation above Organization networks and can take the same form as the Organization networks.
    1. External Direct - This is simply a bridged connection to the underlying Organization network.  vApps on this network will have "direct" connectivity to the Organization network and depending on the type of underlying Organization network may or may not have external network connectivity.
    2. External NAT/Routed - This is a NAT connection where there is layer 2 isolation between this network and the Organization Network.  A vShield Edge device is deployed to provide NAT services in addition to firewall, DHCP, and more.
    3. Internal Isolated -A layer 2 isolated network with no connectivity to other network segments.  If you choose to use DHCP services on this Isolated network than a vShield Edge device will be automatically deployed.
  4. Network Pools - Network Pools back "External NAT/Routed" and "Internal Isolated" networks at both the Organization and vApp level.  Some characteristics of this network construct are:
    1. Used to pre-provision networking resources for later consumption by Organizations.
    2. Used to provide inter-host communication for isolated Layer 2 networks.  This sounds counter-intuitive but vApps within Isolated Layer 2 segments in vCloud can move across hosts within the cluster via DRS and vMotion or need to communicate with a vApp on the same Isolated network that lives on a different ESX hosts.  
    3. Used to provide "Agility with Control" - The Cloud administrator, vSphere administrator, and network administrator still control the resources available and network topology but in this model they pre-provision it allowing the Organizations to consume them later on without coming back to IT for every new vApp or workload need.
    4. There are three types of Network Pools
      1. VLAN-backed - As its name implies you create a list of availble VLANs that are already trunked into your DVS and these are consumed by vCloud as needed and portgroups with Virtual Switch Tagging created as needed on the dVS.  Requires a dVS.
      2. vCloud Network Isolation-backed - Proprietary technology that leverages Mac-in-Mac encapsulation to provide Layer 2 isolation without requiring VLAN's.  Requires a DVS.
      3. Portgroup-backed -  This is a more manual approach to configuring a network pool and requires the vSphere administrator to create these portgroups across all hosts in the cluster.  Can use a DVS or Standard vSwitch.

Monday, October 11, 2010

A new beginning

I have been working at VMware for a few months now and while I enjoyed a brief initial period of relative inactivity the pace is picking up at a dizzying rate.  Ironically, I joined the Cloud Practice on September 7th which is the week after VMware officially released their Cloud computing product VMware vCloud Director.

I began working with VMware vCloud Director before it was released in the Spring and started to become very interested in Cloud Computing and where the industry and VMware were going.  The more I researched the more I became interested until I finally decided I had to be involved with the technology and the wave that was coming at a very deep level.