CA PAM Tech Tip by Christian Lutz, Support Engineer for March 27, 2017
As you may or may not already know, CA PAM 2.8.2 has been released & contains a new feature, Multi-Site Clustering. This is not meant to replace the original clustering system, but rather to improve reliability & accessibility it in WAN type environments. If you are not going to be deploying CA PAM across a WAN then the original clustering system should still be used. I have compiled some notes below to help start understanding what's different.
The first thing of note is that the cluster settings have been moved from "Config > Synchronization" to "Config > Clustering". Also, once clustering has been enabled you will see the updated cluster management page where you can check out the health of your cluster.
The original clustering system is a "multi-master" system, where EVERY appliance is a master. Since every appliance is a master they each have a full always updated databases. If one appliance loses contact it will become out of sync and then depending on settings the cluster may need to be completely restarted before it can be used at all. This system can cause problems in WAN environments, mostly due to replication problems over large geographical areas.
The new Multi-Site system uses a combined approach of "multi-master" with additional "secondary nodes", introducing the concepts of a "primary sites" and "secondary sites".
The Primary Site will have the main authoritative database from which all other sites replicate their data. All appliances in the primary site will use the original multi-master system to keep in sync with each other. This allows the primary site to have redundant data and in case of a disaster on one primary site appliance the other(s) would still have accurate data to revert to.
The Secondary Site does NOT use multi-master, each secondary node is all on its own. A secondary "site" is really a logical grouping only, but load balancing via VIP is still used within the logically grouped site. The secondary nodes keep themselves updated in a more sporadic way, requesting updates regularly as opposed to attempting to keep in sync with every transaction like multi-masters do. This allows Secondary nodes to come and go from the cluster without effecting the cluster as a whole. If it goes out of sync then it is simply brought back into sync when it comes back online.
Read more on Multi-site clustering here: Set Up a Cluster - CA Privileged Access Manager - 2.8.2 - CA Technologies Documentation
Read more on the original Multi-Master Clustering here: Set up Clusters for High Availability Deployments - CA Privileged Access Manager - 2.8.1 - CA Technologies Documentation
There are a few known issues with the clustering system that you may need to be aware of: Known Issues - CA Privileged Access Manager - 2.8.2 - CA Technologies Documentation