Architecting a Distributed vCAC Cloud

In order to install a multiple VM vCAC cloud, one must first need to get to know all of the vCAC components. Lets overview:

vCAC Database

The actual DB Server, (Microsoft SQL in our case) contains all of the inventory data on the existing endpoints, contains the AZMan store for maintaining each user’s role and permissions (if you chose to set it up in as an MSSQL store of course). Also, the database holds one interesting table, with all types of policy workflows that can (and can’t) be loaded and edited on the vCAC designer.

HA Considerations: vCAC DB Could be set up as an MS SQL MSCS Cluster. Although, personally I’m not a big fan of MSCS on my virtual infrastructure ( thus, any infrastructure, as physical servers are not an option ;) )

vCAC Manager Service & DEM Orchestrator

The vCAC Manager Service is the service responsible for all of the connections between the vCAC components (Website, Agents, DB, SMTP).
So overall, its an important part of the system.
The DEM Orchestrator, is the component that actually orders each DEM Workers to run which workflows, according to Skill tags, or if several DEMs are involved.

HA Considerations: As both of these components are pretty crucial to the system working properly, you might want to set it up in HA mode, which is Active/Passive solution today. Of course, it all depends on the use case and HA requirements. Also, for this to work, you should put both of the servers set up in HA behind a load balancer.

Model Manager Data & Web

The model manager role actually refers to two types of data. One is the “Model Manager Data” and the other being  the actual vcac website, also named “Model Manager Web”.
The model manager data installation, actually installs all of the data structures that vCAC uses to manage different endpoints and workflows into the database (thus only has to be installed once in a web-server scale-out scenario)
The model manager web installation, installs the required web data for that web server running the vCAC portal / self-service portal / reporting website.

HA Consideration: If servicing a lot of users, and you want to make it scale, you should probably install these components behind a load-balancer.

vCAC DEM Worker / Agent

The vCAC DEM worker is the component required to to execute actual vCAC workflows like:
– Data collection from different endpoints
– Executing provisioning workflows to certain endpoints
– Executing all of the actual stub and non-stub workflows during the different states of the machine request

The vCAC Agents are actually somewhat of equivalent to DEMs but handle certain types of endpoint like vSphere endpoint, Hyper-V and KVM.

HA Considerations: vCAC DEM workers can actually be installed in several instances, thus allowing the DEM Orchestrator to order different DEMs to do different types of work.

HA Consideration: Well, this one depends on scale, and on amount of workflows you run. Each DEM worker, will actually only run up to 15 workflows at a time, while queuing the others. While this sounds like a big number, one should keep in mind that apart from provisioning workflows, the vCAC system will also perform a lot of scheduled system workflows to perform various tasks , such as keeping track of endpoint inventory, and more. So in this case, installing more than one DEM in an environment could prove quite useful, and help the environment perform more operations.

Architecture Examples

Here are some architecture examples that can be used for several environment scenarios

This is a fairly straight forward example of installing vCAC 5.2 in a medium environment, to support Dev / Test provisioning . According to vCAC Reference Architecture Guide, this environment size should fit above 1000 VMs.
Another, more robust example of vCAC architecture, is the one for production use cases:
Production vCACNotice, that here, the vSphere agent is shown in a different manner, because I’ve tried to represent a different design approach for it,  installing it on the vCenter itself. Thus constraining the vSphere agent’s availability and vSphere provisioning as a whole , with the availability of vCenter itself. which makes a lot of sense in many use cases where vCenter is a VM relying on vSphere HA.

Distributed installs ‘Gotchas’

When installing vCAC 5.2 in a distributed manner, you should look out for the following specific “Gotcha’s”

  • When using self-signed certificates, you must import the certificate from the manager server, and the management model , to every other component in the vCAC environment that will access them via 443, meaning : DEMs , vSphere Agents, and also Model Manager Web server to the Manager Server. Everyone, needs to trust pretty much everyone else :)
  • When deploying an environment where the web servers reside behind a load balancer, use sticky sessions on the load-balancer. Other wise, you will have to deploy the servers in “Web Farm” mode, which requires for an additional database to handle the users sessions and keep track of it. This degrades performance.
  • As always, use the pre-requisites checker to make sure that all of the parts and pieces needed for the system install on each server are in place. Check the right hand menu in the Pre-req application, to make sure you selected the right components to be installed on the system.
  • DEM workers, need nothing but secondary logon service turned on, and a firewall to be switched off. So nothing to prepare in that case

Hit the comment section for any questions, i’m a quick replier. Also, be ready for the same article recreated for a vCAC 6.0 deployment after it’s GA :).

vCAC 5.2 Icon Pack

Here’s a small something for you guys using vCAC 5.2. I’ve created an icon pack with a consistent design of icons (picked up and edited from the net) for you to use on your vCAC 5.2 deployment. As I see it, “The Cloud” should be a fun thing to use, and also something that the user actually wants to use.

In that context, eye candies are always an awesome solution! so hit the vCAC icon pack download button below, and if you have any more ideas / icon requests i’ll be glad to help :) Hit the comment section, or tweet me @elastic_skies

vCAC 5.2 Icon Pack

vCAC 6.0 Has Been Announced! – What’s New?

vCAC 6.0 was just announced at VMworld 2013 Barcelona. This version brings a lot of new features, enhancements and new capabilities!

here’s an overview:

Revamped UI , featuring a new service catalog looks

The vCAC 6.0 version introduces a new UI, which includes a new self service catalog that can contain multiple different service catalogs, and any catalog item you can think of (more on that later…) each vCAC tenant, can also customize his own UI and dashboard, for a tenant specific experience of the product. Also, Icons got a bit bigger and customized icons with larger resolution and detail can be inserted for each of your catalog items and service catalogs.

vCAC 6.0 Service Catalog

New and enhanced approval policy mechanism

Approvals can now be set to pretty much anything in the request fields, and complex conditions can also take part in the approval process. Also, you could set approvals to go to different users, and delegate them according to each user’s role.
Example: IT storage guy should approve if the VM is bigger than X GB, but the VI Admin should approve if the CPU count is above 4 vCPUs

You can set multiple levels of approval, each for specific user, and each can specify which fields are editable by the approver.

XaaS, the ability to offer ANYTHING as a service.

vCAC 6.0 comes with a vCO appliance pretty much built in to the vCAC appliance itself. Part of the new way the self service catalog works is that you can have several service catalogs, each one having different “catalog items”

As you can see in the previous picture, we have HRaaS , containing stuff like “create user” for new users in our company, or create mailbox account etc. For the Iaas of course we will have all of the regular blueprints for our machines. As I mentioned before, its quite easy and simple to create new service catalogs, and the nice thing is, any  thing you could orchestrate with vCO could easily become a Catalog Item, with approvals, and a customised request form.

Additional Infrastructure Support

vCAC 6.0 now supports provisioning IaaS with OpenStack, provision networking with vCNS and NSX! Also, some additional Cloud Endpoints are supported like VMware vCloud Hybrid Service, and also Red Hat distributions of OpenStack Clouds. vCAC is now compatible with SRM, recognising same VMs in different sites, and differentiating between the Primary and DR VMs. It can also be used with Test / Recovery modes as well.
vCAC also supports Storage DRS, showing the entire cluster, and each datastore in it on the reservation.

Stay tuned for more vCAC 6.0 info coming up!

Creating & Running vCAC Workflows, in an “On” State

One of the things that I like about vCAC , is the ability to run workflows in each different stage of the machine provisioning. This enables us to do a lot of the manual work that usually occurs when a machine is requested in our organisation , automatically with vCAC workflows. In order to take advantage of the full vCAC workflow capabilities, we will need a CDK license for our vCAC instance. “CDK” is actually an acronym for “Cloud Development Kit”.

What the CDK actually does is allow us to upload new workflows to the database, using the cloudutil.exe utility, installed when we install it and the vCAC Designer. Also, it will install a Visual Studio plugin for us, allowing us to easily create new xaml files (Microsoft’s .Net Workflow file format) with all the stuff we need to run in vCAC. The installation is fairly simple (Just remember to put the vCAC Web Server FQDN name, and the 443 port ), so I’ll jump to the more important stuff.

Before we get started, I must say I know there are quite a bit of “how to create a custom workflow” posts, but I posted this with the intent of showing some interesting fact I found regarding an “On” state workflow specifically. Lets get started!

To create a new workflow, we will open Visual Studio (needs to be 2010/2012) and create a new project

The new project should be of a type C# workflow, as seen on the right pane, and I usually choose activity library, which is simply an empty workflow file.

vCAC WF Generator

Now, we will click the vCAC Workflow Generator from the tool menu. If you’re seeing it as greyed out, just click the Add-In Manager, uncheck the tool, and try to select it once more from the tool menu.

vCAC Workflow Generator

After that, we’ll see the workflow menu popping up. Here, we’ll click the two “Add” buttons, in order to generate a new workflow xaml file in our project, and also so we can add the necessary references from vCAC dll’s so we could use the vCAC CDK activities.

our second menu will require us to enter a workflow name, and type. Yes I named mine “AppDeployMonitoringAgent” as a hint to what will this workflow do. Generally, naming workflows with good names is a real best practice, as things get complicated once we run a lot of custom workflows. The workflow is a “StateChange” workflow, since it will activate once a machine’s state had been changed to an “On” state.

Also, I’ve put a good Custom Property name as indication that the workflow should run. “App.Deploy.MonitoringAgent”.

Next step is to grab the workflow files from the project’s folder, and do the following:

1. External-<Name of workflow>.xml

– Put this file in the vCAC Manager Server, at: <vCAC Install Directory>\Server\ExternalWorkflows\xmldb

Example: C:\Program files (x86)\VMware\vCAC\Server\ExternalWorkflows\xmldb

Attention! –  In order to run an “On” state workflow, you need to edit the file , and replace the


from “On” , to “^On$”. Why? Well, vCAC will catch the machine’s state with RegEx, so by catching the phrase “On” we’re actually running the workflow at “InitialpowerOn” and “TurningOn” states as well… This could lead to unwanted workflow results. The replaced value will make sure that the workflow will run only once the machine is up and running.

After replacing the value, and putting the file in the xmldb folder, you should restart the vCAC Manager Service.

2. <Name of Workflow>.xaml

– Grab the file from the project’s folder, and put it somwhere it would be easily accessible from command line.

– Open a command prompt and navigate to <vCAC install folder>\DesignCenter

– We will use the cloudutil.exe file (AKA “vCAC Designer”) to enter the command:

[powershell]cloudutil.exe workflow-install -f workflowfilename.xaml -n workflowname[/powershell]

A good install would look like this:

That’s it, you’ve now installed a new workflow in the vCAC Repository and can access it from the “Load” button in the designer. We can now edit the workflow to do whatever we want, usually it’s going to be some powershell activity in an “On” state. But, I’ve got even more interesting scenarios for this machine state than you think. Find out in my next post!

BTW, do not forget to add the custom property you gave your workflow in the desired blueprint.

Installing vCenter 5.5 What’s New?

Well , as I am really excited about our newest GA release, I thought I’d share with you the install process for vCenter 5.5. I’ve ready myself and installed MS SQL 2008R2 SP2 , and prepared the usual database, and vpxuser that I like so much.

The new installer, depicts the installation order, in a really simple manner

vCenter 5.5 Installer

We can see the new installation scheme , and the way to install everything in a pretty straight forward way. Lets move on with Single-Sign-On installation.

So in vSphere 5.5 we actually have some big changes in SSO, mainly, the fact that you do not need to install/create a database. I repeat, you are not asked to create a Database, in any part of a new single node installation. Lets go through the steps:

SSO Install

First thing, we get a nice general check that basic settings for the servers are correct. For those of you night birds installing vCenter Server 5.5 in 2:20am (like me :) ), this is quite a nice addition.

Next we face the type of SSO installation we would like to install.

1. The first represent our regular SSO install, and I say ‘regular’ intently, since I believe this does not have the restrictions of a 5.1 SSO basic install. As far as i’m aware, this should be like the “create new primary sso instance” kind of choice for the new vSphere 5.5 SSO.

2. The Second option, is the HA option , adding an SSO server to an existing SSO instance, in a single site.

3. The Third option, is the equivalent of multi-site mode, installing a new sso server, for the same instance, in a different site.

The database created here is an internal db, that does not require an external SQL or other DB.

new sso instance

Next, we will enter a new administrator password for our instance, but wait! look at the new “system-domain” it is now “vSphere.local” , with administrator, instead of the “admin” user.

SSO Site Name

Next up, we will be prompted to name our newly created site, as always, adding some reasonably logical name for this is probably a good thing to do…

Summary screenNext we’ll see a short summary screen, which is always great for complex install scenarios. The next button will simply install the SSO server, and prompt you when all is done! we’re finished with SSO.

As for webclient and Inventory service , which are next in line, i’ll elegantly skip those, as the install procedure remains exactly the same. For the web client, you can change the default port (still 9443) .

As for Inventory service , the installer still offers you to configure the JVM heap size, between:

– Small (3GB)

– Medium (6 GB)

– Large (12GB)

Lets continue with installing vCenter Server! (after installing web-client, and Inventory service of course)

For most of its parts, the vCenter installer remains the same, so for all of you who ever got to install vSphere 5.1, you’ll do fine. There are two screens i’d like to take a minute and to talk about:

The screen for choosing vCenter Service account. In previous versions, when selecting an mssql server user (vpxuser I created) you we’re only allowed to run the server with the NTAuthority\System user. This never made sense to me, and in 5.5, although I picked simple SQL authentication, I can now de-select the “Use Windows Local System Account” which was once selected and greyed out, and opt to put any user I’d like. This is great news and i’m glad it got fixed in this release.

The second screen I mentioned worth noting, is the following:

For some reason I get a lot of customers pretty confused by this page, when it’s actually really simple, the installer asks for us to select the first user to get vSphere administrator credentials. This user should be recognised by SSO (thus the default option is for the administrator@vsphere.local user). This screen appears because since 5.1, vCenter Server local administrators will not get the “vSphere Administrator” Role by default, as in previous vCenter versions.

This is all for the Installation of vCenter 5.5 . The installer completes, and login is done via administrator@vsphere.local user. Remember to assign some new vSphere administrators, and to configure SSO. More on that, next time around…