Master-slave clustering for high availability
SafeSquid supports clustered deployments for high availability, failover, and horizontal scaling. A master node holds policy and reporting; slave nodes enforce policy and forward data. Use a load balancer in front of slaves for distribution and failover.Problem statement
Single-node deployments create both scale risk and availability risk. Clustering is the documented way to reduce that risk while keeping policy consistent across enforcement nodes.When to use clustering
Prerequisites
- Same SafeSquid version on all nodes
- Same activation key on master and slaves
- Network connectivity: slaves can reach master Configuration Portal (port 8888 by default)
- Load balancer configured to distribute traffic to slave nodes (not to master)
- Time synchronization (NTP) across all nodes
- A reporting plan so evidence from all active nodes remains visible
Architecture overview
Master node:- Hosts Configuration Portal for policy management
- Aggregates reporting data from slaves
- Does NOT process client traffic directly
- Enforce policies synced from master
- Process client traffic
- Forward reporting data to master
- Distributes client requests across slave nodes
- Provides failover if a slave goes down
- Does NOT route to master (master is for management only)
Verification and validation
After clustering is configured, validate:- policy changes replicate to every node
- the load balancer does not send client traffic to the master
- a failed slave is removed from active service
- reporting still captures traffic from each surviving node
- authentication and SSL inspection behavior remain consistent across nodes