When a GWLB backend server fails a health check or is removed, new traffic is routed to other available servers. However, existing traffic continues to flow to the unavailable server, which can cause packet loss. Enabling rebalance for a server group instructs GWLB to reroute this existing traffic to other available servers.
Why use rebalance
Rebalance status | Disabled | Enabled |
Scenario diagram |  |  |
How existing traffic is handled | Existing traffic continues to flow to the unavailable server, which may cause packet loss. | Existing traffic is immediately rerouted to other available servers, which ensures service continuity. |
The rebalance feature offers the following advantages:
It allows for seamless upgrades and maintenance on network virtual appliances (NVAs), such as third-party firewalls.
It eliminates the need for special application logic to handle traffic interruptions from NVA failovers.
How rebalance works
After a backend server fails a health check or is removed:
New traffic is routed directly to other available servers.
How existing traffic is handled depends on multiple conditions.
Reason for unavailability
Connection draining
Rebalance
Result
Health check failure
Not applicable
✅
Rerouted to other available servers
❌
Continues to be forwarded to the unavailable server
✅
Rerouted to other available servers
❌
Continues to be forwarded to the unavailable server
Server removal
✅
✅
Continues to be forwarded to the unavailable server during the connection draining timeout period.
After the connection draining timeout period expires, traffic is rerouted to other available servers.
✅
❌
Continues to be forwarded to the unavailable server
❌
✅
Rerouted to other available servers
❌
❌
Continues to be forwarded to the unavailable server
Enable rebalance
Console
In the GWLB console, navigate to the Server Group page. When you create a server group, in the Advanced Settings section, enable or disable Load Rebalancing (recommended).
Alternatively, for an existing server group, open the Modify Basic Information page to enable or disable Load Rebalancing (recommended).
After this feature is enabled, GWLB rebalances existing traffic to healthy servers when a server fails or is removed. If your traffic uses a stateful protocol, you must configure the NVAs on the backend servers accordingly.
API
To enable or disable rebalance, call the CreateServerGroup or UpdateServerGroupAttribute operation and set the ServerFailoverMode parameter.
Valid values for the ServerFailoverMode parameter are:
NoRebalance (default): Does not rebalance existing traffic.
Rebalance: Rebalances existing traffic.
To query the status of the rebalance feature, call the ListServerGroups operation.
If your traffic uses a stateful protocol, you must configure the network virtual appliances (NVAs) on the backend servers accordingly.
For example, for TCP traffic, the firewall must be configured to allow a TCP session to be established without an initial SYN segment.
How it works:
TCP uses a three-way handshake to establish a connection. This process involves the client sending a SYN segment, the server responding with a SYN-ACK segment, and the client sending an ACK segment to complete the connection.
When GWLB rebalances existing traffic, it may move an existing connection from one NVA to another. This operation can transfer a TCP session to a new NVA. If the new NVA does not support establishing a TCP session without an initial SYN segment, it will drop the connection. Therefore, the NVA must be able to seamlessly accept these "SYN-less" mid-stream connections to prevent interruptions.
Configuration example: On a FortiGate firewall, enable
tcp-session-without-synin the firewall policy. For more information, see the official documentation of your firewall vendor.
When rebalance is triggered, existing traffic that was forwarded to unhealthy or removed servers is redistributed to the remaining healthy servers in the server group.
Evaluate the capacity redundancy of your server group to ensure that if any single server fails, the remaining servers can handle the redistributed traffic and avoid overload caused by a sudden traffic spike. Check the load level of each server in the server group before making changes and reserve sufficient capacity redundancy.