A server group is a logical group of backend servers that support the Geneve protocol. Each server group routes traffic from a GWLB instance to one or more backend servers. This topic describes the key concepts of server groups.
Server group types
GWLB supports two types of server groups: Server and IP Address.
Server group type | Backend server type | Description |
Server | You can add ECS instances, ENIs, and ECI instances as backend servers. | The added backend servers must be deployed in the same VPC as the server group. The backend servers receive requests from GWLB. |
IP address | You can add IP addresses as backend servers. | You can enter private IP addresses within the following CIDR blocks:
|
When a backend server in a server group of the server type for a GWLB instance is released or its private IP address is modified, GWLB supports automatic updates of the backend servers.
If a backend server in an IP-type server group for a GWLB instance is released, GWLB does not automatically update the server group. We recommend that you remove the backend server from the GWLB server group before you release or modify the backend server of the IP-type server group for the GWLB instance. This ensures that your services are not affected.
Traffic scheduling algorithm
GWLB supports the following traffic scheduling algorithms.
Five-tuple hash: Routes requests by hashing the five-tuple (source IP address, source port, destination IP address, destination port, and IP protocol). All requests with the same five-tuple are sent to the same backend server.
Three-tuple hash: Routes requests by hashing the three-tuple (source IP address, destination IP address, and IP protocol). All requests with the same three-tuple are sent to the same backend server.
Two-tuple hash: Routes requests by hashing the two-tuple (source IP address and destination IP address). All requests with the same two-tuple are sent to the same backend server.
Connection draining
You can enable connection draining to ensure existing connections are handled properly when you remove a backend server. You can configure a connection draining timeout to allow in-flight requests to complete.
When a backend server is removed, the GWLB instance no longer routes new connection requests to the removed backend server. The GWLB instance manages existing connections that are routed to that backend server as follows:
If connection draining is disabled (default): Existing connections are maintained until the idle connection timeout expires. After this timeout, GWLB stops forwarding packets to the server.
If connection draining is enabled: Existing connections are maintained for the configured connection draining timeout. After this timeout, the idle connection timeout applies. If the idle timeout is also exceeded, GWLB closes the connection and stops forwarding packets to the server.
Health check
You can configure health checks to monitor the availability of your backend servers. GWLB allows you to define GWLB health check configurations at the server group level.
Supported protocols: TCP and HTTP.
Health checks are enabled by default for server groups. The default protocol is TCP, and the default port is 80.
When health checks are enabled, GWLB automatically routes new connections to healthy servers and continuously monitors all backend servers in the group. A server is considered healthy only after it passes a specified number of consecutive health checks (the health threshold). Requiring multiple checks reduces false positives and prevents service interruptions caused by transient failures.
If a backend server fails health checks, GWLB stops sending new connections to it and routes them to other healthy backend servers. Existing connections can continue until the idle timeout expires, after which GWLB stops forwarding packets to the unhealthy server.
When the server recovers and passes health checks, GWLB restores it to the GWLB service.
After each health check, GWLB closes the connection.