This article describes how to deploy a High Availability (HA) configuration for a GCP vSocket site.
You can configure High Availability (HA) for Cato vSockets in Google Cloud Platform (GCP) by deploying two vSockets in separate zones and placing a Google Cloud Load Balancer in front of their LAN interfaces. The Load Balancer provides a single static IP address that internal resources use to connect to the vSockets. It continuously monitors the health of each vSocket and forwards traffic only to the active (master) vSocket. This can be either the primary Socket or, in case of a failover, the secondary.
In addition, the vSockets use Virtual Router Redundancy Protocol (VRRP) to exchange state information between them. When the secondary Socket is in standby mode, it reports to the Load Balancer as unhealthy so that traffic is forwarded only to the active vSocket. Together, the Load Balancer health checks and VRRP provide automatic failover with minimal disruption. Typical failover time is approximately 3–5 seconds.
Note
Note: The minimum supported vSocket version for HA in GCP is 24.0.20395.
HA vSocket configurations in GCP rely solely on the Load Balancer to direct traffic to the active vSocket.
This is the workflow when the primary active vSocket fails over to the secondary standby one in a GCP site.
- In normal operation, the primary vSocket has the active role, and the secondary vSocket has the standby role.
- The load balancer probes the Sockets for their health status. The primary reports that it is healthy, the secondary reports it is unhealthy.
- The primary and secondary Sockets communicate over the LAN using VRRP protocol.
- The load balancer IP directs traffic to the primary vSocket’s IP.
- The LAN route table prefixes use the load balancer IP as the next hop.
- The primary (active) vSocket goes down.
- The secondary (standby) vSocket stops receiving keepalive packets from the primary vSocket.
- The secondary vSocket assumes the active (master) role and starts reporting to the load balancer as healthy.
- The load balancer stops receiving responses from primary vSocket, and now directs traffic only to secondary vSocket.
- The secondary vSocket is now the active vSocket and passes traffic for the site in both directions.
- When the primary vSocket recovers, it resumes the active role, and the secondary vSocket returns to standby status. The load balancer now directs the traffic back to the primary vSocket.
-
A GCP project with permissions to create the following resources:
- VPCs and subnets
- Compute instances
- Firewall rules
- Load balancer
- Health checks
- Static IPs
- Service accounts
- Terraform is installed and authenticated to GCP
- Cato account credentials or tokens required by the Terraform module
- Two availability zones in the target region (for example, us-central1-a and us-central1-b)
- (Optional) Reserved DNS name pointing to the Load Balancer’s static IP address
- Minimum vSocket version: 24.0.20395
- Each vSocket includes three interfaces: MGMT, WAN, and LAN. The LAN interfaces participate in VRRP for state synchronization.
- The load balancer operates on the LAN side to provide a consistent IP address to internal clients.
- Health checks probe each vSocket’s LAN interface. Only instances that report to the load balancer as healthy receive traffic.
- VRRP ensures state synchronization between the two vSockets.
All required resources (VPCs, vSockets, Load Balancer, and health checks) should be defined in a single Terraform stack.
The official Cato vSocket Terraform modules, available in the Terraform Registry, include detailed documentation and examples for vSockets in a High Availability configuration. For more information about the GCP HA module, see here.
To extend the configuration for HA in GCP:
- Deploy two vSockets across different zones using the same approach
- Add a Load Balancer resource on the LAN side to front both vSockets
- Allow VRRP communication between the two vSockets for state synchronization
Note
Note: Refer to the official Cato vSocket Terraform module documentation for details on module inputs, outputs, and advanced configuration options
This section explains how to manage HA for the GCP site:
- Show the HA status for each vSocket
- Change the load balancer IP for the site
- Change the management IP addresses for the vSockets
- Disable HA for the site and remove the secondary vSocket
The Network > Sites > Socket page for the site shows the HA status for the primary and secondary vSockets.
| Item | Description |
|---|---|
| HA Status | The High Availability status for the site (Ready or Not Ready) only shows Ready when each HA status indicator is OK |
| Connected (status indicator) | The status |
| Keepalive (status indicator) | The status |
| Same Version (status indicator) | The status |
If you change the IP address settings for the vSockets in GCP, you need to update the same settings in the Cato Management Application. These are the settings that you can configure:
- Native Range subnet - Use the Networks section for the site
- Load balancer IP - Use the Networks or High Availability section for the site (the new value is automatically updated in the other section)
- Management IP - Use the High Availability section for the site
Use the Networks section to change the Native Range subnet.
Use the High Availability section to change the Load Balancer IP and the Management IP. You can also change the load balancer IP in the Networks section.
To change the load balancer or Management IP for a site:
- From the navigation menu, click Network > Sites and select the GCP site.
- From the navigation menu, click Site Configuration > Socket.
- Expand the High Availability Configurations section.
- Enter the new Primary Management IP.
- Enter the new Secondary Management IP.
- Enter the new LAN Load Balancer IP.
- Click Save.
You can remove the secondary vSocket from a GCP site and disable HA for that site. After you remove the secondary vSocket from the Cato Management Application, the deployed vSocket can no longer connect to the Cato Cloud. The settings for the site are restored to the configuration for a single vSocket:
- The High Availability section is disabled and no longer appears on the page
- In the Networks section, the Local IP replaces the Load Balancer IP
Note
Note: You can't undo the Unassign Socket action. The serial number for the secondary vSocket is no longer valid.
If you want to add the secondary vSocket again, you must install a new vSocket on the VM with the new serial number.
To disable HA for the GCP site:
- From the navigation menu, click Network > Sites and select the GCP site.
- From the navigation menu, click Site Configuration > Socket.
- From the Actions menu of the Secondary vSocket, click Unassign.
- In the Warning window, click OK. HA is disabled for the site, and the secondary vSocket is removed from it.
Known Limitations
- In GCP HA deployments, failback to the primary vSocket can take longer than failover to the secondary vSocket. During failback, traffic can be interrupted for up to 8 seconds.
- During a split-brain condition in a GCP HA deployment, existing continuous ping traffic can continue through both the primary and secondary vSockets. This can cause GCP load balancer health checks to show both vSockets as healthy and make failover validation less clear, although new traffic initiated after the split-brain condition is routed only through the secondary vSocket.
0 comments
Article is closed for comments.