Navigation
TAG: Design

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 :).

There are no more results.