Backend servers that support the Geneve protocol can be organized into logical groups. Each server group contains one or more backend servers that process requests distributed by Gateway Load Balancer (GWLB). This topic describes the key terms of server groups.
Server group types
GWLB supports configuring servers and IP addresses as backend services.
Server group type | Backend server type | Description |
Server | Allows you to specify Elastic Compute Service (ECS) instances, elastic network interfaces (ENIs), and elastic container instances as backend servers. | The backend servers and the server group must belong to the same virtual private cloud (VPC). The backend servers are used to receive requests distributed by GWLB. |
IP address | Allows you to specify IP addresses as backend servers. | IP addresses that fall into the following CIDR blocks are supported:
|
After a backend servers in a specified server group for a GWLB instance is released or its private IP address is changed, GWLB automatically updates the status of the backend server.
After a backend server in the server group at a specified private IP address is released for a GWLB instance, GWLB does not update the status of the backend server. When you release or modify a GWLB backend server at a specified private IP address, we recommend that you remove the backend server from the GWLB server group to ensure that your business is not affected.
Traffic scheduling algorithm
GWLB supports the following traffic scheduling algorithms.
Five-tuple hash: Distributes a request based on a five-tuple (source IP address, source port, destination IP address, destination port, and IP protocol) hash of the request and ensures that requests with the same hash value are forwarded to the same backend server.
Three-tuple hash: Distributes a request based on a three-tuple (source IP address, destination IP address, and IP protocol) hash of the request and ensures that requests with the same hash value are forwarded to the same backend server.
Two-tuple hash: Distributes a request based on a two-tuple (source IP address and destination IP address) hash of the request and ensures that requests with the same hash value are forwarded to the same backend server.
Connection draining
You can enable the connection draining feature for backend server removing scenarios. By configuring a connection draining timeout, requests received through existing connections by a backend server can be processed before the server stops providing services.
If a backend server is removed, a GWLB instance stops routing new connection requests to the backend server. The GWLB instance manages existing connections to the backend server as follows:
By default, connection draining is disabled. Existing connections to the server remain open for a specified idle connection timeout. After this idle connection timeout, no more packets are forwarded to the server.
If connection draining is enabled, existing connections to the server remain open for a specified connection draining timeout. After this connection draining timeout, if no new requests are received by the server during the idle connection timeout, the existing connections are closed, and no more packets are forwarded to the server.
Health check
You can configure health checks to monitor the conditions of server groups. This helps you evaluate the availability of backend servers in server groups. GWLB allows you to configure health checks for server groups.
Supported health check protocols: TCP and HTTP.
Health checks are enabled by default for all server groups. The default health check protocol is TCP, and the default health check port is 80.
When health checks are enabled, GWLB automatically routes requests to healthy backend servers and probes the availability of all backend servers at a specified interval. A backend server must pass health checks for a specific number of times (N times) before the backend server is declared healthy. You can specify N based on your business requirements. Determining the availability based on mutiple health checks can reduce false positives caused by a single unhealthy result and prevent service interruption due to a transient failure.
If a backend server fails health checks for a specific number of times, the backend server is declared unhealthy. In this case, GWLB automatically stops distributing requests to the backend server, while existing connections to the server remain open for the idle connection timeout. After the idle connection timeout, no more packets are forwarded to the server.
After the backend server recovers, GWLB automatically distributes requests to the backend server.
Health checks use non-persistent connections. The connections are closed after health checks are completed.