VMware Cloud Community
VirExprt
Expert
Expert

Need more information on High Avaiability

Hello

I am looking for more information on Configuration of High Availability of vCAC as what I can get from Installation Guide is not sufficient and it lacks actual approach for the deployment.

1- What is the load balancer it is being referred in document? Is it windows NLB or some third party Load Balancer?

2- Can current deployed vCAC server be included in Farm Based Deployment?

3- What is the Session Affinity & how can it be configured?

Is there any practical approach for installing vCAC in High Availability scenario?

I would highly appreciate if anyone can provide me information

Br,

MG

Regards, MG
2 Replies
ShibbyB
Enthusiast
Enthusiast

1- What is the load balancer it is being referred in document? Is it windows NLB or some third party Load Balancer? - External load balancer, F5, Cisco, etc.

2- Can current deployed vCAC server be included in Farm Based Deployment? - Depends, where did you put your AzMan store? SQL / AD based, and you can possibly deploy additional web servers. You mentioned "Farm Based", you don't necessarily have to deploy multiple web servers in a Web Farm type deployment, I believe this configuration (Web Farm) puts additional configuration information in the web.config as it pertains to the location of a session state database. I'm not positive that you could convert a standard vCAC web server deployed into a web farm type web server, but I would think you probably could if you found out what the specific entries are in the web.config file.

3- What is the Session Affinity & how can it be configured? This is something that you configure on the load balancer, if you ARE NOT using Web Farm with session state in a database, the session affinity insures that a web client (end user) goes to the same web server so that session state can be tracked by the web server the load balancer connected the client to. If you ARE using web farm deployment, session affinity (sticky sessions) is not required, as each web server in the farm should know the state of each session via the SQL session state database. If you look at the reference architecture pdf there is a little bit on load balancer considerations.

Is there any practical approach for installing vCAC in High Availability scenario?

  • Take load balancer names into consideration when doing the certificate request, simple scenario, 2 web servers vcacweb01 & vcacweb02, 2 app/dem/pa servers vcacapp01 & vcacapp02 - your load balancer is configured with a name vcacweb for the two web servers and vcacapp for the two app servers. You could have one certificate that you share between all four servers, with the Subject Alternative Names to include vcacweb01, vcacweb02, vcacapp01, vcacapp02, vacaweb, vcacapp. Or you could do two certs, one for the app layer and the other for the web.
  • When you do the install, you will want to reference the load balancer "friendly name", in the above scenario, when you install the manager service, and it asks for the FQDN of the web repository, you would put in vcacweb.domain.com. When you install DEM's and Proxy Agents, you would put in vcacapp.domain.com for when being asked for the Manager Service, and vcacweb.domain.com for the web services.
  • There is a note in the install guide, when you setup the web servers, put in the actual server name of the particular web server not the load balancer to prevent looping.
  • Direct users to go to vcacweb.domain.com, they load balancer will send them to one of the web servers based on the rules in the load balancer.
  • The manager service is a manual failover, there are notes on the load balancer for what URL to look at, think it is https://managerserver.domain.com/VMPS2 but check the documentation. The load balancer should always send requests to the primary manager service unless that URL isn't available, in that case it should go to the secondary (the service will have to manually be started).
christianpg
Enthusiast
Enthusiast

Good & important stuff - certificate SAN, vCAC Manager's FQDN reference to the web repository and the loopback issue on each web server behind the LB are all elements that puzzled me while digging through the documentation (it's still not very clear in the 5.2 docs).

0 Kudos