Part 1: Why "Less Is More" in Symantec PAM Clustering
Why adding nodes to your primary site hurts performance, and how to scale with secondary sites instead
- Adding a fourth or fifth node feels like cheap insurance, but it actually increases overhead without buying meaningful extra resiliency.
- Secondary sites rely on a clever architectural split that lets you scale capacity across data centers without forcing the primary site to wait.
- True enterprise resilience and zero-downtime scaling depend on shifting your growth strategy away from the core site.
When designing high availability infrastructure, it is tempting to assume that bigger is always better. If a three node cluster is good, then a five, seven, or nine node primary site cluster must be twice as resilient, right?
In Symantec Privileged Access Manager (PAM), the opposite is true past a certain point. If your goal is maximum throughput, low latency, and fault tolerance, expanding your primary site past three nodes is a path toward diminishing returns.
In short, keep your primary site at three nodes. Three is all high availability requires, and every node past that adds transaction latency without a resiliency gain to justify it. Deploy secondary sites for scale and disaster recovery instead. The rest of this post explains why.
The engine under the hood: Synchronous consensus
Within a primary site, PAM uses MySQL Group Replication to maintain identical database states across all member nodes. Changes are replicated synchronously, which means that every time a privileged account is checked out, a policy is updated, or a credential is rotated, a majority of the members must agree on that transaction before it commits. That majority is the quorum.
Here is how quorum math works in practice:
Why three nodes is the right number
Adding more nodes to a single primary site might sound like extra insurance, but every transaction waits for enough members to confirm it. Three members keep that to a single confirmation, since the member handling the change already counts toward quorum. Five members require two, and seven require three.
Each step up meaningfully increases the odds that a minor hypervisor delay, CPU spike, or packet retransmission affecting any single node delays one of those confirmations and stalls the transaction.
PAM delivers high availability on three nodes, tolerating a complete node failure without losing quorum or interrupting operations. Three nodes also goes further than the number suggests. PAM was built for scale, and a single appliance handles significantly more concurrent privileged sessions than competing solutions.
Scaling the smart way: Asynchronous secondary sites
Symantec PAM gives you a dedicated path for scale and redundancy: secondary sites.
While primary site members replicate synchronously among themselves, replication from the primary site to secondary sites is asynchronous. The primary site commits the change locally first, then streams it to the secondary sites in the background, so nothing on the primary site ever waits on a remote data center.
Secondary site architecture provides a way to add capacity for user requests as your traffic increases, without adding nodes to the primary site and risking its performance.
This architectural split gives you the best of both worlds:
- Uncompromised primary speed. Your primary site stays small, so transactions commit with a single confirmation.
- True site-level resiliency. If your primary data center experiences a total outage, a secondary site holds a replicated copy of the database and can be promoted to take over the primary role.
- Scaling without downtime. Nodes can be added to or removed from secondary sites without stopping the cluster, so you can scale up over time without a maintenance window.
- Minimal WAN traffic. Each secondary site has a leader that receives the replication stream and distributes it locally, so only one copy crosses the WAN per site. The remaining nodes automatically fall back to the primary site if that leader goes offline.
Minimize latency, maximize availability
When building or reviewing your Symantec PAM topology: keep your primary site lean at three nodes, and handle scale and disaster recovery through secondary sites.
By capping your primary site at three nodes you minimize database consensus latency while maintaining high availability. And by pairing it with secondary sites, you achieve enterprise grade resilience without sacrificing daily user experience.
Once your primary site is sized, the next design decision is your secondary sites: how many nodes belong at each site, and where they should go. Part 2 of this series will walk through both.
