Before you use the Classic Load Balancer (CLB) service, you must add Elastic Compute Service (ECS) instances as the backend servers of CLB to receive requests forwarded by CLB.

Introduction

CLB uses virtual IP addresses to distribute network traffic across groups of ECS instances in the same region to ensure high performance and high availability. You can also use vServer groups to manage backend servers. You can associate listeners with different server groups. This way, CLB can distribute requests to backend servers that use different ports.

Note If you associate a listener with a vServer group, the listener distributes requests to the ECS instances in the vServer group instead of the ECS instances in the default server group.

Limits

You can add ECS instances to or remove ECS instances from a CLB instance anytime. CLB distributes network traffic across groups of ECS instances. Before you use CLB, make sure that health checks are enabled and at least one ECS instance works as expected to ensure service stability.

When you add backend servers, take note of the following items:
  • By default, CLB does not support cross-region deployment. Make sure that the ECS instances and the CLB instance belong to the same region. If your CLB instance is deployed in a virtual private cloud (VPC), you can add only ECS instances that belong to the same VPC to the CLB server group.
  • You can add two ECS instances that run different operating systems to a CLB instance. However, the applications deployed on the ECS instances must be the same and have consistent data. To simplify management and maintenance, we recommend that you add ECS instances that use the same operating system to a CLB instance.
  • A CLB instance supports up to 50 listeners. Each listener serves a backend application. CLB uses listening ports to receive client requests and forward the requests to backend ports that are used by the applications on ECS instances.
  • You can specify a weight for each ECS instance in a server group. An ECS instance with a higher weight receives more requests.
  • If session persistence is enabled, requests may not be evenly distributed to each backend server. We recommend that you disable session persistence and check whether the issue persists.

    If requests are not evenly distributed, troubleshoot the issue by performing the following steps:

    1. Count the numbers of access log entries generated on different ECS instances within a specified time period.
    2. Check whether the numbers of access log entries generated on different ECS instances have deviations based on the CLB configurations. If session persistence is enabled, you must exclude access log entries that contain the same IP address. If the ECS instances have different weights, you must check whether the numbers of access log entries are also weighted.
  • When an ECS instance performs hot migration, persistent connections to CLB may be closed. Make sure that your applications are configured with the automatic reconnection mechanism.

Default server group

You can add ECS instances to the default server group of a listener to receive requests. If no vServer group or primary/secondary server group is specified for a listener, the listener forwards all requests to the ECS instances in the default server group.

Before a CLB instance can process requests, you must add at least one backend server to the default server group to receive requests. For more information, see Add an ECS instance to the default server group.

vServer group

You can create vServer groups for CLB to distribute different requests to different backend servers. To allow CLB to distribute requests based on domain names and URLs, you can specify vServer groups in domain name-based forwarding rules and URL-based forwarding rules. For more information, see Create and manage a vServer group.

Primary/secondary server groups

A primary/secondary server group contains only two ECS instances. One ECS instance serves as the primary server and the other ECS instance serves as the secondary server. CLB does not perform health checks on the secondary server in a primary/secondary server group. If the primary server is down, network traffic is automatically distributed to the secondary server. When the primary server recovers, traffic is switched back to the primary server. For more information, see Create and manage a primary/secondary server group.

Note You can add primary/secondary server groups only to TCP and UDP listeners.