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


Comments
Harvey Specter
Posted at 11:30 am April 10, 2014
vman
Reply
Author

What is the configuration of the load balancer between the Active and Passive nodes of the vCAC Manager and DEM Orchestrator in the Large Production configuration. I’m not getting how a load balancer is applicable there as only one is working at time.

    Harvey Specter
    Posted at 1:45 pm April 10, 2014
    Omer Kushmaro
    Reply
    Author

    There is a specific url /VMPS2 that is only available when manager service is up.
    so the LB needs to point to the node where this url is up. This is not for actually balancing the load, but rather for having 1 name for the active/passive nodes so when you fail them over , no system configuration will have to be made

Harvey Specter
Posted at 4:55 pm April 24, 2014
aenagy
Reply
Author

What are the changes for vCAC 6?

    Harvey Specter
    Posted at 9:13 am April 25, 2014
    Omer Kushmaro
    Reply
    Author

    For the IaaS part – None , this could definitely be used to architect the IaaS side of vCAC 6.
    You will also have to take into consideration the vCAC Appliance components, and SSO.
    hopefully i’ll have time to blog about a 6 architecture soon enough.

Harvey Specter
Posted at 9:45 pm July 16, 2015
Danny
Reply
Author

In the Large Production environment can you explian to me where the IAAS sits? I’m having a hard time understanding the services that make up IAAS.

    Harvey Specter
    Posted at 10:15 am July 31, 2015
    Kushmaro
    Reply
    Author

    IAAS is everything installed on windows,right?
    Keep in mind this post is a bit old, and was written originally for v5.2 release. So it doesn’t contain any CAFE pieces.
    If you run the IaaS installer , and select a ‘custom install’ you’ll be able to see all of the components i mention here and try to make more sense out of this post.

Leave a Reply

Navigation