CLB server groups - Server Load Balancer - Alibaba Cloud Documentation Center

A server group is logical group containing one or more backend servers. Each server group is responsible for routing requests distributed by CLB to backend servers according to the configured scheduling algorithm. CLB supports the default server group, vServer group, and primary/secondary server group.

Server group types

	Default server group	vServer group	Primary/secondary server group
Description	Each CLB instance only has one default server group.	Can be created and managed as needed.	Can be created and managed as needed.
Number of backend servers	One or more	One or more	Two, one primary and one secondary
Characteristics	Shared by all listeners on a CLB instance. Available by default and does not need to be created or managed. You only need to add backend servers to this server group to use it. All backend servers in this server group must use the same port to provide services.	You can create multiple vServer groups and associate them with different listeners to achieve complex traffic control. Supports advanced forwarding features including domain name-based and URL path-based forwarding rules, which enable granular traffic control. Backend servers in a vServer group can use different ports to provide services.	You can create multiple primary/secondary server groups and associate them with different listeners to achieve complex traffic control. Achieves high availability for your service. When the primary backend server works as expected, CLB forwards traffic to the primary server. When it fails, CLB forwards traffic to the secondary server. Backend servers in a primary/secondary server group can use various ports to provide services.
Use scenarios	Applications with a simple and clear architecture. You want all requests to be forwarded to the same group of backend servers. You don't need traffic to be distributed based on protocols and ports or domain names.	Applications with a complex architecture. For example, you want to forward HTTP and HTTPS requests to different groups of backend servers, or you want traffic to be distributed based on ports or domain names.	Key applications and services that are deployed in a primary/secondary mode, for example, database services and core API services.
Supported listener types	TCP, UDP, HTTP, and HTTPS	TCP, UDP, HTTP, and HTTPS	TCP and UDP

Usage notes

Relationships between CLB instances, listeners, and server groups:
- Listeners and server groups are configured for a specific CLB instance. Different CLB instances do not share listener or server group configurations.
- Different listeners on a CLB instance can be associated with different server groups.
- Each listener can forward traffic to only one server group, while a server group can be associated with multiple listeners.
Limitations on backend servers:
- A CLB instance can only forward traffic to backend servers deployed in the same region as the CLB instance.
  - For CLB instances of the VPC type, you can only add backend servers deployed in the same VPC.
  - For CLB instances not of the VPC type, you can add backend servers from both the same VPC and a different VPC.
- All three server group types support adding the following resources as backend servers: Elastic Compute Service (ECS) instances, elastic network interfaces (ENIs), and Elastic Container Instances.
- If a live migration of your service between ECS instances is in progress, the persistent connections established between CLB and the backend servers may be disrupted. These connections can be restored by reconnecting. Configure reconnecting mechanisms on your applications.
Recommendations for service high availability:
- Enabling health checks for CLB is recommended. Ensure at least one backend server is running as expected in the server group to ensure the availability of your service.
- In a primary/secondary server group, if the primary backend server fails health checks, CLB forwards traffic to the secondary backend server. Because no health checks are performed on the secondary server, you need to ensure the availability of the secondary server by your own means to ensure service continuity.