A server group is a logical group of one or more backend servers. Classic Load Balancer (CLB) distributes business requests to server groups, which then route the requests to the appropriate backend servers. CLB supports various types of server groups, such as default server groups, vServer groups, and primary/secondary server groups.
Differences between server group types
Server group type | Default server group | vServer group | Primary/secondary server group |
Description | Each CLB instance comes with one and only one default server group. | A server group that you can create and manage. | A server group that you can create and manage. |
Number of backend servers | One or more | One or more | Two (one primary and one secondary) |
Characteristics |
|
|
|
Use cases | Simple application architectures where all requests are forwarded to the same group of backend servers. Custom traffic distribution for different listeners or domain names is not required. | Complex application architectures. For example, you need to process HTTP and HTTPS requests separately, or distribute traffic to different server groups based on different listener ports or domain names. | Key applications or services that use a fixed active-passive mode, such as database services or core API services. |
Supported listener types | TCP/UDP/HTTP/HTTPS | TCP/UDP/HTTP/HTTPS | TCP/UDP only |
Notes on using server groups
Relationship between CLB instances, listeners, and server groups:
Listeners and server groups are resources of a CLB instance. Information about listeners and server groups is not shared among different CLB instances.
Different listeners can be associated with different server groups.
A server group can be associated with multiple listeners, but a listener can be associated with only one server group.
Restrictions on associated backend servers:
You can associate only backend servers that are in the same region as the CLB instance. Cross-region servers cannot be associated.
For a CLB instance in a virtual private cloud (VPC), you can associate only backend servers within the same VPC.
For a CLB instance that is not in a VPC, you can associate backend servers from different VPCs.
All types of CLB server groups support associating Elastic Computing Service (ECS) instances, Elastic Network Interfaces (ENIs), and Elastic Container Instances.
If a backend ECS instance undergoes hot migration, persistent connections to CLB may be disconnected. To restore the connections, ensure that your applications are configured to automatically reconnect.
For an Internet-facing CLB instance, you can add backend servers from any VPC in the same region. However, all backend servers that you add must belong to the same VPC.
High availability recommendations:
Enable health checks for CLB and ensure that at least one backend server for the CLB instance is healthy.
In a primary/secondary server group, failover from the primary to the secondary server is triggered by health checks. If the primary server fails a health check, traffic is switched to the secondary server. By default, health checks are not performed on the secondary server. You must ensure the availability of the secondary server so that it can take over traffic after a failover.
Manage server groups and backend servers
Default server group
Each CLB instance has exactly one default server group. You can add backend servers directly to this group.
All listeners of the CLB instance share this default server group.
You cannot create multiple default server groups.
Add backend servers
You can add backend servers to the default server group from the Backend Servers step when you create a listener, or from the Default Server Group page of the instance details.
Make sure that the backend servers are in the same region as the CLB instance.
Add ECS instances
Select the target ECS instances.
Configure weights.
When a listener uses the weighted round-robin scheduling algorithm, backend servers with higher weights receive more requests. For more information, see SLB scheduling algorithms.
If you set the weight to 0, the server does not receive new requests.
Add ENIs
You can add only ENIs that are already associated with ECS instances.
You can add the primary private IP address and secondary private IP addresses of an ENI.
Enable Advanced Mode, click the plus sign icon next to the ECS instance with the associated ENI, and find the target ENI.
Example of a target ENI:
Select the ENI that you want to associate and choose the primary private IP address or a secondary private IP address. You can associate multiple IP addresses.
Configure weights.
When a listener uses the weighted round-robin scheduling algorithm, backend servers with higher weights receive more access requests. For more information, see SLB scheduling algorithms.
If you set the weight to 0, the server does not receive new requests.
Add Elastic Container Instances
Select the target Elastic Container Instances.
Configure weights.
When the listener uses the weighted round-robin scheduling algorithm, backend servers with higher weights receive more access requests. For more information, see SLB scheduling algorithms.
If you set the weight to 0, the server does not receive new requests.
Configure ports for the default server group
You can set the service port for a default server group only when you first create a listener, in the Backend Servers step. Then, all servers in the default server group for that listener must use the same port.
For example:
After a listener is created, you cannot modify the service port of the default server group.
Different listeners can use different service ports for the default server group.
For example:
vServer group
Create a vServer group
You can create a vServer group in the following ways:
On the Configure Listener page:
On the instance management page:
Add backend servers
You can add backend servers when you create a listener and select to create a new server group, or on the vServer groups page for the instance.
Make sure that the backend servers are in the same region as the CLB instance.
A backend server can belong to multiple vServer groups.
Add ECS instances
Select the target ECS instances.
Configure ports and weights.
When a listener uses the weighted round-robin scheduling algorithm, backend servers with higher weights receive more access requests. For more information, see SLB scheduling algorithms.
If you set the weight to 0, the server does not receive new requests.
Different backend servers can use different ports. You can also configure multiple different ports for the same backend server.
Add ENIs
You can add only ENIs that are already associated with ECS instances.
You can add the primary private IP address and secondary private IP addresses of an ENI.
Enable Advanced Mode. Then, click the plus sign icon to the right of the ECS instance where the ENI is associated and find the target ENI.
Example of a target ENI:
Select the ENI that you want to associate and choose the primary private IP address or a secondary private IP address. You can associate multiple IP addresses.
Configure ports and weights.
When a listener uses the weighted round-robin scheduling algorithm, backend servers with higher weights receive more access requests. For more information, see SLB scheduling algorithms.
If you set the weight to 0, the server does not receive new requests.
Different backend servers can use different ports. You can also configure multiple different ports for the same backend server.
Add Elastic Container Instances
Select the target Elastic Container Instances.
Configure ports and weights.
When a listener uses the weighted round-robin scheduling algorithm, backend servers with higher weights receive more access requests. For more information, see SLB scheduling algorithms.
If you set the weight to 0, the server does not receive new requests.
Different backend servers can use different ports. You can also configure multiple different ports for the same backend server.
Delete a vServer group
If a vServer group is associated with a listener or a forwarding rule, you must first disassociate it from the listener or forwarding rule before you can delete the group.
Primary/secondary server group
Create a primary/secondary server group
Create a primary/secondary server group in the following ways:
On the Configure Server Load Balancer page:
On the instance management page:
Add backend servers
After you create a primary/secondary server group and add servers, you cannot modify the servers, ports, or primary/secondary roles. To make changes, you must recreate the server group. Configure these settings with care.
In a primary/secondary server group, failover from the primary to the secondary server is triggered by health checks. If the primary server fails a health check, traffic is switched to the secondary server. By default, health checks are not performed on the secondary server. You must ensure the availability of the secondary server so that it can take over traffic after a failover.
You can add backend servers when you create a new primary/secondary server group.
In a primary/secondary server group, you need to set one server as the primary server and another as the secondary server. After you select the primary/secondary server group for a listener, traffic is forwarded to the primary server if it is healthy. If the primary server is down, traffic is switched to the secondary server. The time it takes to switch from the primary server to the secondary server depends on the Health Check Response Timeout that you set for health checks. After the primary server becomes healthy again, traffic is automatically switched back to the primary server.
Make sure that the backend servers are in the same region as the CLB instance.
A backend server can belong to multiple primary/secondary server groups.
Add ECS instances
Select the target ECS instances.
Configure ports.
You must add exactly two backend servers to a primary/secondary server group.
Select one server as the primary server.
Add ENIs
You can add only ENIs that are already associated with ECS instances.
You can add the primary private IP address and secondary private IP addresses of an ENI.
Enable Advanced Mode, click the plus sign (+) next to the ECS instance with which the ENI is associated, and then find the target ENI.
Example of a target ENI:
Select the ENI that you want to associate and choose the primary private IP address or a secondary private IP address. You can associate multiple IP addresses.
Configure ports.
You must add exactly two backend servers to a primary/secondary server group.
Select one server as the primary server.
Add Elastic Container Instances
Select the target Elastic Container Instances.
Configure ports.
You must add exactly two backend servers to a primary/secondary server group.
Select one server as the primary server.
Delete a primary/secondary server group
If a primary/secondary server group is associated with a listener, you must first disassociate it from the listener before you can delete the group.
FAQ
Can I adjust the number of ECS instances while a CLB instance is running?
Yes, you can, if you use a default server group or a vServer group. You cannot adjust the number of servers in a primary/secondary server group.
If you use a default server group or a vServer group, you can increase or decrease the number of backend ECS instances for the CLB instance at any time. You can also change the ECS instances you selected. To ensure service stability, enable health checks for the CLB instance and make sure that at least one backend ECS instance is healthy when you perform these operations.
Can backend ECS instances run different operating systems?
Yes, they can.
CLB does not restrict the operating systems used by backend ECS instances, as long as the application services and data are consistent across the instances. However, we recommend that you use the same operating system to simplify future management and maintenance.
Can I use ECS instances from different regions as backend servers?
CLB does not natively support associating backend servers from different regions. However, you can use Global Traffic Manager (GTM) with CLB to achieve this. You can deploy GTM in front of multiple CLB instances in different regions to enable cross-region load balancing. For more information, see Use GTM and CLB instances to implement cross-region load balancing.
Application Load Balancer (ALB) and Network Load Balancer (NLB) support associating cross-region backend servers. For more information, see the following topics:
Why do IP addresses that start with 100 frequently access my ECS instances?
The CLB system not only forwards external requests to backend ECS instances but also performs health checks and availability monitoring on the ECS instances. These access requests originate from the CLB system.
The CLB system uses the 100.64.0.0/10 CIDR block, which is a reserved CIDR block for Alibaba Cloud internal services. (Because other users cannot be allocated IP addresses in this CIDR block, this practice prevents security risks.) Therefore, you may see access requests to your ECS instances from IP addresses that start with 100.
To ensure the availability of your services, make sure that you configure rules to allow access from these IP addresses.
Compression is not configured on my ECS instances. Why are HTTP responses from CLB compressed?
This may be because the client browser supports compression. You can disable the Gzip compression feature when you create a listener in the console, or use a TCP listener instead.
Do ECS instances that use HTTP 1.0 support chunked transfer encoding?
Yes, they do.
Why do backend ECS instances of a CLB instance frequently receive requests with the User-Agent 'KeepAliveClient'?
Symptom: Backend ECS instances of a CLB instance frequently receive GET requests even when there is no user access. The source IP address is an internal IP address of Alibaba Cloud, and the User-Agent is 'KeepAliveClient'.
Cause: The listener protocol is set to TCP, but the health check protocol is set to HTTP. When you use the HTTP protocol for health checks on a TCP listener, the GET method is used for requests by default.
Solution: Ensure that the listener protocol and the health check protocol are the same.
Can I modify the server ports in a default server group?
Scenario: When you modify the configuration of an existing listener, you cannot modify the server ports in the default server group. You can set the server port for the default server group only in the Backend Servers step when you first create a listener. Then, all servers in the default server group for the same listener must use the same port.
Solution: To configure different server ports for the same listener, select vServer Groups in the Backend Servers step when you configure the listener.
Do Layer 4 listeners of CLB support an ECS instance that acts as both a backend server and a client?
No, they do not. However, you can:
Use a Layer 7 listener of CLB.
Use an NLB instance and disable the Preserve Client IP feature for the NLB server group. For more information, see How do I configure my NLB instance to allow an ECS instance in the server group to work as both a backend server and a client?.
Why are there many TIME-WAIT connections on CLB backends but few on ALB backends?
CLB and ALB use different connection mechanisms when interacting with backend servers.
CLB: Uses short-lived HTTP connections by default. When CLB forwards a request to a backend server, it inserts the
Connection: closefield into the HTTP header. After the backend server processes the request, it actively sends a FIN packet to close the connection based on this header. Each time a connection is closed, it enters the TIME-WAIT state (60 seconds by default). In high-concurrency scenarios, many TIME-WAIT connections can accumulate quickly.ALB: Supports persistent HTTP connections (keep-alive) by default. A single TCP connection can be reused to process multiple requests. Enabling persistent connections reduces the number of disconnections, thus reducing the number of TIME-WAIT connections.