icon-zia.svg
Secure Internet and SaaS Access (ZIA)

Understanding Multi-Cluster Load Sharing

The Multi-Cluster Load Sharing feature allows multiple ZIA Public Service Edge clusters in different network address blocks to participate in a Virtual IP (VIP) from any network address block in a data center. The ingress traffic will enter a given VIP and access the end destination via any instance of the Service Edge clusters from any of the network address blocks listed for the data center (DC). To view the complete list of Data Center information, go to config.zscaler.com/<Zscaler Cloud Name>/cenr.

You can find the name of your cloud in the URL your admins use to log in to the Zscaler service. For example, if an organization logs into admin.zscalertwo.net, then that organization's cloud name is zscalertwo.net. In this case, you should go to config.zscaler.com/zscalertwo.net/cenr. To learn more, see What is my cloud name for ZIA?

All the traffic is distributed across every participating cluster load balancer (LB) instance, and they can forward traffic to any service node in any participating cluster.

Schematic Diagram of Multi-Cluster Load Sharing

This feature allows Zscaler to scale its DCs without the need to migrate your clusters while using the same existing VIPs.

For example, in the following table, ZSC Cluster 1 resides in the 165.225.80.0/23 network address block, and ZSC Cluster 3 in the 147.161.166.0/23 network address block. Both these clusters can serve the GRE VIP 165.225.80.36, allowing us to add more Service Edge capacity without impacting your GRE VIP destination. So, you no longer need to move your GRE tunnels to a new VIP when a new cluster is added to a DC.

ClusterVIPCluster TypeNetwork address block
ZSC Cluster 1165.225.80.36GRE165.225.80.0/23
165.225.80.37VPN165.225.80.0/23
165.225.81.247PAC165.225.80.0/23
ZSC Cluster 3 (Shared VIPs with Cluster1)165.225.80.36GRE147.161.166.0/23
165.225.80.37VPN147.161.166.0/23
165.225.81.247PAC147.161.166.0/23

This feature rollout follows the monthly infrastructure upgrade schedule as per the Zscaler Service Continuity Customer Notification Protocol.

Related Articles
Choosing Traffic Forwarding MethodsBest Practices for Traffic ForwardingHandling DNS Resolution for Various Traffic Forwarding MethodsUnderstanding Zscaler Authoritative DNS ServersAbout SubcloudsUnderstanding SubcloudsEditing a SubcloudAbout Data Center Exclusion Based on Traffic Forwarding MethodExcluding a Data Center Based on Traffic Forwarding MethodAbout Static IPSelf-Provisioning of Static IP AddressesImporting Static IP Address from a CSV FileUnderstanding Multi-Cluster Load SharingUnderstanding Proxy ModeDetermining Optimal MTU for GRE or IPSec TunnelsImplementing Zscaler in No-Default Route EnvironmentsVerifying a User's Traffic is Being Forwarded to the Zscaler ServiceAlternative Options to Caching Web TrafficTroubleshooting Users' Traffic not Going to the Nearest ZIA Public Service EdgeConfiguring Disaster RecoveryZscaler Traffic Bypasses