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.
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:
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.
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:
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.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。