SafeSquid Proxy Cluster
Problem statement
A single SWG node creates two enterprise risks: it becomes a single point of failure, and it limits growth to the capacity of one server. For large enterprises and mission-critical environments, that is not enough. The organisation needs multiple enforcement points with consistent policy, shared evidence, and a failover design that does not create policy drift.Client scenario
Use the cluster model when any of these are true:- a single-node outage would interrupt business-critical web access
- peak demand exceeds the practical capacity of one proxy instance
- multiple sites require common policy
- the rollout requires staged expansion without redesigning the enforcement model
Key benefits
- Scale-out by adding nodes rather than replacing the deployment model
- Automatic policy replication across nodes
- Consistent user experience across clustered enforcement points
- Better resilience when load balancers, WCCP, or egress design are planned correctly
Prerequisites
Before you build a cluster, define:- the traffic-distribution method
- the health-check method
- the failure domain for each node
- the logging and reporting path for clustered traffic
- the policy-change process and rollback path
Setup instructions
This page is the architecture overview, not the full build runbook. Use it to choose the design, then move to the implementation guide. SafeSquid’s cluster-ready architecture supports:- seamless addition of nodes for scale-out
- automatic policy replication across cluster nodes
- common operational behavior across nodes
- integration with load-balancing and traffic-redirection designs
- scale-up by adding CPU, RAM, and storage to a single node until the single-instance boundary no longer fits
- scale-out by adding nodes when you need more aggregate capacity or lower availability risk
Verification and validation
After clustering is implemented, validate all of the following:- traffic is actually distributed to the intended nodes
- policy changes replicate to all nodes
- a node failure does not create an unmanaged bypass path
- reporting still captures events from every active node
- SSL interception and identity-aware policies behave consistently across nodes
- load balancer or WCCP distribution state
- node-specific access logs
- policy-change timestamps across nodes
- reporting data showing traffic from each clustered member
Troubleshooting guide
Symptom: Users get inconsistent policy results across nodes.Likely cause: Policy replication drift or node-specific configuration deviation.
Isolation: Compare the active policy state and timestamps on each node.
Remediation: Re-run the synchronization workflow and verify the replication path.
Retest: Repeat the same policy-triggering request through multiple nodes. Symptom: Traffic fails over poorly during node loss.
Likely cause: Load-balancer health checks or redirection logic do not remove the failed node quickly enough.
Isolation: Check the health-check state and egress path behavior during a controlled failure test.
Remediation: Tune the health checks and remove stale node references.
Retest: Repeat a planned node failure and confirm uninterrupted enforcement. Symptom: Cluster capacity still saturates under growth.
Likely cause: The design scaled up one node instead of scaling out enough nodes, or distribution is uneven.
Isolation: Compare per-node concurrency and traffic distribution.
Remediation: Add nodes or rebalance traffic.
Retest: Re-run the peak-load scenario and confirm even spread.
Related controls / next steps
- Proxy Clustering for the implementation runbook
- Deployment Planning for sizing and failover preparation
- Reporting Service for clustered evidence collection
- SafeSquid SWG Overview for the full component model