Seting up multisite PAM clustering Site for Disaster Recovery
search cancel

Seting up multisite PAM clustering Site for Disaster Recovery


Article ID: 215717


Updated On:


CA Privileged Access Manager (PAM)


CA PAM is multisite clustered application which entails that CA PAM can failover service from problematic nodes within each site but there is no automatic failover from one site to another without using a thirdparty load balancer. The specific requirements and expected configuration should be considered when designing the architectural flow to allow for your desired results.


Release : 3.x, 4.x

Component : CA PAM


With CA PAM 3.3 and higher you should always be using 3 or more nodes in the primary cluster for a fault tolerant cluster. If you configure your cluster with only 2 nodes then you simply have a processing cluster where if either node is inaccessible the entire cluster is inaccessible and will require manual intervention. This is documented in the on-line manuals, please see "Primary Site Fault Tolerance" ( )  for more information


To configure a disaster recovery to handle an entire site level outage you will have to configure a CA PAM secondary site. You can have a single node in the secondary site which would receive updates from the primary site and can manually be started as the master server assuming the entire production site became importable, please review "Site Promotion Using Replication Analysis" ( ) for more information. The concept of having at least one node in an offsite location is important to ensure quick recoverability for certain types of outages. If you choose to have more than one node in this site for this type of disaster recovery scenario then you should consider the possibility of using the disaster recovery location for the CA PAM primary site and have endusers connect only to the secondary site for normal daily operations. This idea is based on the following considerations.

  1. From the endusers' perspective, connecting to a secondary site is no different than connecting to a primary site. Switching endusers to accessing secondary site nodes would have no impact to their daily usage.
  2. The primary site holds all the administrative and scheduled tasks so if you have secondary site nodes that are not being used then it makes more sense to move the enduser access to these nodes freeing up resources on the primary nodes currently being used for access. The primary site would still be used by the CA PAM administrators so they would also still be used as well on a regular basis. For details and  a graphic in our manual see  " Set Up a Cluster " ( ). 
  3. The addition and subtraction of secondary site nodes has little impact to the overall cluster stability so having any kind of maintenance work to do on a secondary node will have less impact than having the same on a primary node. Also you can easily add or remove the number of secondary site nodes to manage the overall utilization from endusers very easily.
  4. If you have access to a thirdparty load balancer you could automate failovers from a problematic secondary site back to the DR site if the DR site is the CA PAM primary but you might not be able to do this if the primary site was the site with the issue. This is because the secondary site relies on the primary site being fully functional but the primary site does not require the secondary sites stay functional (see link above on site promotion).


Basically the health of the overall cluster depends on the health of the primary cluster site. If you only have a single CA PAM appliance set aside for disaster recovery then changing this may not be cost effective. If you do have several nodes provisioned simply for disaster recovery then it may be beneficial to consider changing your architecture to distribute the load. Before making any such changes you should evaluate your specific environment for any additional concerns this type of change may impact.

Additional Information