VCAP-CID Study Notes: Objective 2.2

This is Objective 2.2 in the VCAP-CID blueprint Guide 2.8. The rest of the sections/objectives can be found here.

Bold items that have higher importance and copied text is in italic.


  • Identify policy/quotas/limits available to a vCloud design.
    • The organizational policy/quota/limits are the following:
      • Allocation models
        • Organization vDC needs to have a single allocation model which will in some instances limit the resources available to the organization. This will explained later in this Objective.
          • Pay as you go:
            • CPU Quota GHz – CPU guarantee % – vCPU speed
            • Memory Quota – Memory guarantee %
          • Allocation Pool:
            • CPU Allocation GHz – CPU guarantee %
            • Memory Allocation GB – Memory guarantee %
          • Reservation Pool:
            • CPU Allocation GHz
            • Memory Allocation GB
      • Storage Space
        • An organization vDC requires storage space for vApps and vApp templates. You can allocate storage from the space available on provider vDC datastores.
        • This storage quota either has a limit of certain GB/TB or unlimited.
        • Thin-provisioning and Fast-provisioning are also available options when selecting storage for organizations
      • Network Pools
        • An Organization need network pools to create vApp networks or isolated internal networks.
        • When creating a Organization vDC you can limit how many such networks can be created.
      • Rate limits
        • You can configure inbound and outbound rate limits on Edge gateways for organizations.
        • Those are in gigabit per second
      • Max number of VM’s
        • When choosing allocation models you can limit how many VM’s can create in that Organization vDC.
      • Catalog sharing/publishing
        • You can choose whether or not the organization can publish catalogs.
        • Also you can choose if can share catalogs to other organizations
      • Leases
        • You can specify for how long a VM can run
        • Also how long VM’s are available before they are “cleaned up”
        • What should be done when the are “cleaned up”
          • Move to Expires Items or Delete permanently
        • vApp template lease – how long they are kept before they are “cleaned up”
          • Move to Expires Items or Delete permanently
      • Default Quotas
        • The organization administrator can change how many VMs can be kept and how many can be powered on at any given time
      • Limits
        • There are 3 DOS (Denial of Service) limits, and are best described by vCloud director:
          • These limits provide a defense against Denial of Service attacks. Resource intensive operations, such as copy, move, Add to My Cloud, Add to Catalog, and so on, can be contained at a maximum number. Simultaneous connections to a VM through the VMRC console can also be limited, although this does not limit user-created connections though protocols such as VNC or RDP.
        • Number of resource intensive operations per user.
        • Number of resource intensive operations per organization
        • Number of simultaneous connections per VM.
  • Explain inter- and intra- organization vApp deployment and migration constraints.
    • I might be wrong but I think the mean Elastic vDCs.
      • Elastic vDCs are made of several resource pools on different Resource pools associated with its provider vDC.
        • 1 Cluster of ESXi host is one resource pool, so you can have two clusters available to an organization through the same provider vDC
      • So when the virtual machine is powered on a placement engine decides where it should run and can be moved to another Resource pool (which is most likely a vSphere HA cluster)
    • Intra organization migration
      • They might as well be talking about the fact you can move a vApp to another vDC.
        • Turn the vApp off – Click My Cloud – Select vApps – Select Move to and select the vDC you want to move the vApp to.
        • You can also copy it the same way.
    • Inter-organization Deployment
      • Only way to deploy a vApp in another Organization is to publish it as a Public vApp Template. Then deploy it from there or move it to an Organization catalog and deploy it.
    • Inter-organization migration
      • The same as deployment.
    • Intra organization deployment
      • This is just an ordinary deployment of a vApp and you can control who has access to deploy it.

Skills and Abilities

  • Given resource requirements and constraints, determine policy/quotas/limits for a logical design.
    • Since we are talking about organizations, I presume they mean organizational policy/quota/limits.
    • As these are resource based this applies to allocation models and best described in the vCloud Director Administration Guide (page 54-57) and vCAT Architechting a vCloud (page 42-44, 5.4)
    • All the above mentioned bullets in Identify policy/quotas/limits available to a vCloud design can be used to control the creation of an organization and its vDC.
  • Determine how service dependencies impact components in a logical design.
    • The Datacenter Operational Excellence Through Automated Application Discovery & Dependency Mapping document in the Objective Tools is something everyone should read, but the highlights are:
      • Automated application discovery and dependency mapping can deliver tremendous value when applied to projects related to datacenter consolidation, capacity planning, business continuity planning, and application  migration. All of these projects have one common requirement: a deep, thorough understanding of how servers, applications, and infrastructure work together and relate to each other.
      • With automated application discovery and dependency mapping, you get that capability—whether its establishing a baseline asset inventory before a datacenter consolidation, ensuring a new application rollout doesn’t impact legacy architectures in unexpected ways, or understanding of how the servers, applications, and infrastructure work together so you can deliver application services right away when recovering from a disaster.  You know what applications are involved, how they are delivered, and what business services and users will be impacted by a proposed change or move.
      • Furthermore, by leveraging automation for application discovery and dependency mapping, you save tremendous amounts of money that would have been spent dedicating personnel hours—even worse, likely using highly skilled IT personnel—collecting and analyzing this data. And in the end, you’d still have risk with manual application discovery and dependency mapping because manual processes done by people are extremely prone to error.
      • In addition, by having automated application discovery and dependency mapping capabilities, these kinds of activities start to move away from being one-off projects, and become properly positioned to move toward being ongoing operational processes. Moving away from reactive, project-based approaches to proactive, process-based approaches for these kinds of activities, IT operations moves that much closer to achieving operational excellence—the data provided by automated application discovery and dependency mapping provides the key linchpin necessary to continuously improve these types of activities, rather than simply react when the need arises.
      • Automated application discovery and dependency mapping supports IT operations before and after a consolidation and virtualization effort by automatically discovering all of the critical dependencies that exist among your applications and your information infrastructure.
      • Before virtualization, automated application discovery and dependency mapping augments your virtualization plan by determining the key dependencies that exist between applications and their physical hosts. For example, automated application discovery and dependency mapping could identify a critical dependency between an application and database that could reduce overall network traffic. To maintain proper levels of performance after virtualization, IT operations could then ensure the application and database remain on the same server for greater efficiency.
      • By using automated application discovery and dependency mapping to identify critical dependencies between applications and servers before consolidation and virtualization occurs, you have a smoother transition to virtualization while ensuring the delivery and performance of IT services.
      • After consolidation and virtualization, changes occur rapidly in the new environment. Automated discovery and dependency-mapping information also helps IT operations by ensuring ongoing performance and improvement. This dependency information can help you identify potential application-related performance bottlenecks and reduce unnecessary network traffic. Automated application discovery and dependency mapping helps you deliver on the promise of virtualization by allowing you to optimize the performance of critical IT applications and services.
  • Given business requirements, determine the appropriate organizational structure for a logical design.
    • Business requirements are what needs to be done to provide value to the business. I had some examples in Objective 2.1 and I’ll use those as an example:
      • System must provide self-service capability
        • That is a integral part of vCloud Director and vCAC (vRealize now) so that wont impact organizational structure in most design. Unless you have a requirement to block self-service for certain organizations (a static organization with no ability to create more VM’s).
      • System must provide 99.9% availability
        • This is more of a infrastructure matter, hardware, networking, high-availability of management services, HA etc. The resources should be available to the organizations according to SLA’s and that is the only thing that should matter regarding availability (they should not need to worry about at least).
      • System must provide optimal scalability and elasticity
        • vCloud Director and vSphere is highly scalable and elastic by design, but you need to design for it though (see what I did there? 🙂 vSphere clusters can scale to 32 ESXi hosts, and even so you can add multiple clusters for one Provider vDC. And elasticity is baked in as well, as you can move your workloads between clouds, private or public fairly easily with vCloud Connector.
      • System must provide multitenancy
        • This is also an integral part of vCloud director as it supports multitenancy.
      • System must provide metering capabilities for cost reporting
        • VMware vCenter Chargeback Manager is the service that helps with that, please note that Chargeback is EOA for non-service provider customers June 10, 2014.
      • System must support vApp use cases defined
        • This depends on the use-cases that were defined. Please check out Objective 1.1 for some Use-cases.
      • System must leverage shared infrastructure and resources pooling
        • That’s a part of vSphere.
      • System must support a catalog of templates that end users can create
        • Yes also a part of vCloud Director.
      • System must provide differentiated offerings based on cost.

About larushjartar
VMware Specialist and IBM Technician.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: