Symantec PAM Documentation: Set Up a Cluster

Differences Between Primary and Secondary Sites and Their Members In a Multi-Site Cluster

Internal and External Load-Balancing

Single-and Multiple-Site Clusters

Separation of administrative and access tasks: To designate specific PAM nodes to handle global administrative functions (such as policy maintenance and credential rotation) and others to handle user requests for access to privileged devices, configure a multi-site cluster . Address all administrative requests to the VIP of the primary site and all access requests to the VIPs of secondary sites.

Geographical distribution of data centers: If all your PAM nodes are deployed at a single geographical location and you do not need to separate them for administrative and access tasks, you only require a single-site cluster . If your PAM servers are deployed over multiple geographically dispersed locations, configure a multi-site cluster .

Primary site members are co-located and are typically designated for administrative activities (policy maintenance, credential rotation). If user requests for access to privileged devices must also be handled at the same data center, create and designate a secondary site at the same location for that purpose. Data that is saved on one member of the primary site is synchronously replicated across all primary site members. Only one primary site exists within a cluster at any time. The primary site in a multi-site cluster behaves the same as a single-site cluster with the same properties. primary sites and single-site clusters both use group replication to keep themselves in sync.

Secondary site are typically designated for access activities, that is, handling user requests for access to devices. Asynchronous replication is performed from the primary site to secondary sites. Replication allows secondary site members to recover gracefully and continue operating should a network issue exist between the sites, like a brown-out or DC outage. A secondary site can also be to primary site status, providing a warm backup if the primary site goes down. For more information, see Cluster Synchronization, Promotion, and Recovery .

Properties Of Single-Site Clusters and Primary Sites In Multi-Site Clusters

Colocation: All members of a single-site cluster should be colocated in the same data center. Group replication is best supported in geographical proximity. If you have remote data centers, create a multi-site cluster where each remote data center is a secondary site.

Primary leader: The first cluster member that is listed in the primary site is designated as the primary leader and is the data synchronization source for all cluster members.

Cluster size: A primary site is limited to nine member nodes. We recommend three and a maximum of five members. (See Quorum .) The more members that you add, the more communication work the cluster has to do. The total number of members in all sites is limited to 1,000. If the entire cluster has only two members, do not put both members in the primary site. Instead, create a 1 x 1 configuration (one member at the primary site and one member at a secondary site). For more information, see Primary Site Fault Tolerance .

Quorum: In MySQL Group Replication, a "quorum" is the number of members that are required to make decisions for the cluster, such as whether a member has failed. The quorum is the majority of cluster members, or in this case the primary Site. For this reason, we recommend an odd number of members, such as 3 (whose quorum is 2), or 5 (whose quorum is 3). However, we do support fewer members.

Data replication: Changes to administrative and Credential Management data can be made through any member and can propagate to the other members. When starting the cluster, the database from the first member is replicated to the other members, overwriting their data. Member-specific information, such as logs and some configuration data are not replicated.

Disaster recovery: Add a secondary site (creating a multi-site cluster) to a single-location deployment to provide a warm backup for disaster recovery.

Differences Between Primary and Secondary Sites and Their Members In a Multi-Site Cluster

There can only be one primary site, which is the source of data for all secondary sites. If the primary site fails, you must manually promote a secondary site to be the primary site to restore cluster operation.

Secondary site members are typically intended to support end-user access rather than global administrative functions, which are typically handled on the primary site. Some local administrative functions are available on secondary site members, including: managing sessions, logs, and recordings; managing password approvals, viewing credentials, and disaster recovery; some diagnostics; network, and security.

Secondary sites, with few exceptions, do not support REST API or CLI operations. (The specific CLI command documentation mentions this, as in checkInAccountPassword .) Use the VIP of the primary site for REST API and CLI commands.

The best practice is to have each member of a particular secondary site in the same data center.

Each secondary site has a leader which receives updates from the primary site. The secondary leader then replicates the data to the other site members and relays updates from secondary members to the primary site. This topology minimizes WAN traffic between the sites.

If the secondary leader goes offline, the other site members communicate directly with the primary site.

Secondary members can “self-heal” after being disconnected. See Cluster Synchronization, Promotion, and Recovery for details.

Members can be added or removed from secondary sites without stopping the cluster. This process requires a VIP for the site you are subscribing to.

Multi-site clustering uses MySQL 8 traditional asynchronous replication to communicate between primary and secondary sites. Almost all data changes start with data on a primary site node. When replication starts with data on a secondary site node, it first is replicated to the primary leader and the data is distributed normally from there.

Internal and External Load-Balancing

Floating IP : (Default) Use the internal PAM software-based load-balancing solution in which requests addressed to the VIP are handled by the site leader (the first node added to the site) which redirects them to the least-loaded site member. If the site leader is down, the node is automatically to be the site leader, and so on, until the site leader is back online (This was the only load-balancing option before release 4.1).

External Load Balancer : Use an external load-balancing solution to handle requests that are addressed to the VIP and redirect them to one of the cluster site members based on the external load balancer algorithm. For important guidelines for configuring external load balancers, see External Load Balancer Configuration Guidelines

Cluster Deployment Requirements and Guidelines

Cluster Synchronization, Promotion, and Recovery

Configure Load Balancers to Determine the Availability of Cluster Nodes