I’ve been spending a fair amount of time with my head inside vCAC 6 of late, and one of the things that seems to come up a lot is that people don’t understand the relationships between the various logical constructs that vCAC uses.

Here’s a quick rundown on some of the key ones (I’m not trying to be obtuse with these, I promise!):

Endpoint

Endpoints are your provisioning platform – such as vCenter, AWS, vCD, Hyper-V and so on. Each endpoint can contain multiple Compute Resources.

 

Compute Resource

A Compute Resource consists of a set of logical resources within an Endpoint, such as a cluster on a vCenter Server, or an AWS Availability Zone. A Compute Resource can be administered by multiple Fabric Groups, and would normally have multiple Reservations.

Reservation

Reservations include CPU, Memory and Storage – depending on the endpoint type it can also contain network information, although it doesn’t reserve network bandwidth. Each Reservation is aligned to a Business Group, and within a Reservation you can nominate a Resource Pool to attach to, which you can then choose to overcommit (or not). You also have the ability to tag a Reservation with a Reservation Policy.

Reservation Policy

A Reservation Policy ties together Blueprints and Reservations. A Reservation Policy can be assigned to multiple Blueprints, and multiple Reservations. This means that a Blueprint can be deployed to any Reservation with a common Reservation Policy, within the constraints of your Business Group membership.

Business Groups

Business Groups are equivalent to a cost centre. You can grant or restrict access, carve up Compute Resources into different Reservations for different Business Groups and grant Entitlements to members of a given Business Group. Each Business Group is able to access multiple Reservations and be granted multiple Entitlements.

Cost Profile

Cost Profiles get associated with a Compute Resource, and while in my diagram I show that each Compute Resource can only have one associated Cost Profile, that is not strictly speaking true. You can also allocate one or more Storage Cost Profiles with the storage associated to the Compute Resource. By default, storage will inherit the allocated storage cost from the associated Cost Profile however this can then be overridden with a specific Storage Cost Profile.

Fabric Group

Fabric Groups have the capability to carve up defined Compute Resources into Reservations. Each Compute Resource can have multiple Fabric Groups associated with it, and Fabric Groups can administer multiple Compute Resources.

Blueprint

A blueprint encompasses an operating system (deployment method constrained by Endpoint) with a range of properties for resource allocation/addition, lifecycle, permissible actions and other applicable properties. A Blueprint can be assigned to a single Reservation Policy (or no Reservation Policy), and has a 1:1 relationship with a Catalog Item.

Entitlements

Entitlements are a big step forward from 5.2. They enable us to wrap specific approval policies around an Object (my term, encompassing Services, Catalog Items and Actions) and then give a set of users within a Business Group access to it. This means that a Blueprint can be given to multiple Business Groups but with different Approval Policies per Business Group (in the form of a Catalog Item).

Services

Services contain both Catalog Items and associated Actions. They can be grouped in whichever way you see fit – in our lab I’ve split them into Private Cloud, vCloud Powered, Amazon and Other. Care of Advanced Service Designer we could also split out “XaaS” categories into specific services. I think this is something that will require some thought in terms of visualisation of services for consumption.

Catalog Items

As alluded to in the Entitlements section above, a Catalog Item can be a Blueprint wrapped in an Approval Policy. It can also be an “XaaS” workflow along with it’s associated Approval Policy.

Actions

Actions can be performed against Catalog Items and can be defined at both the Blueprint level (for IaaS) or at the Entitlement Level (for IaaS and XaaS).

Approval Policy

An Approval Policy consists of two components – Approvers (where any Approver or all Approvers are required to permit deployment) and Conditions (request approval for any deployment or under specific conditions). Within an Entitlement only one Approval Policy can be applied to each of: Service, Catalog Item and Action.

 

 

 

Putting that all together, you get the following:

 

It looks complex, but when you break it down it’s not so bad. If you have any questions, please leave a comment and I’ll do my best to address it!