Classic Load Balancer (CLB) uses a cluster-based architecture to provide Layer 4 (TCP and UDP) and Layer 7 (HTTP and HTTPS) load balancing. It supports session synchronization to eliminate single points of failure (SPOFs), increase redundancy, and ensure service stability.
As a traffic forwarding service, CLB routes requests from clients through a load balancing cluster to backend servers. The backend servers then return responses to CLB over the internal network.
Architecture overview
Alibaba Cloud provides Layer 4 and Layer 7 load balancing services.
-
Layer 4 load balancing uses the open-source Linux Virtual Server (LVS) and Keepalived stack, which is customized by Alibaba Cloud to meet the demands of cloud computing.
-
Layer 7 load balancing uses Tengine, a web server project initiated by Taobao. Based on Nginx, Tengine includes advanced features for handling high-traffic websites.
As shown in the following figure, the Layer 4 load balancing service in each region runs on a cluster of LVS servers. This architecture ensures the availability, stability, and scalability of the load balancing service, even when individual nodes fail.
Each LVS server synchronizes all sessions with other servers in the cluster by using multicast packets. As shown in the following figure, after a client sends three data packets to the server, Session A is established on LVS1 and begins to synchronize with other LVS servers. The solid lines represent existing connections, while the dashed lines show how traffic fails over to a healthy server, LVS2, if LVS1 experiences a failure or undergoes maintenance. This architecture allows the cluster to support hot upgrades. Failures and maintenance are transparent to users and do not affect your services.
During a hot upgrade, connections may be interrupted if the three-way handshake is incomplete, or if an established connection has not yet triggered session synchronization. In these cases, the client must reconnect.
Inbound traffic path
For inbound traffic, CLB forwards and processes requests based on the forwarding rules that you configure in the console or the Developer Portal. The following figure illustrates the data flow.
Figure 1. Inbound traffic path
-
All TCP, UDP, HTTP, and HTTPS traffic passes through the Layer 4 cluster.
-
Each node in the Layer 4 cluster evenly distributes a high volume of requests, and session synchronization policies between nodes ensure high availability.
-
If the listener for the CLB instance uses a Layer 4 protocol (TCP or UDP), each node in the Layer 4 cluster directly distributes requests to the backend Elastic Compute Service (ECS) instances based on the forwarding rules of the CLB instance.
-
If the listener for the CLB instance uses the Layer 7 HTTP protocol, each node in the Layer 4 cluster first distributes requests evenly to the Layer 7 cluster. Then, each node in the Layer 7 cluster distributes the requests to the backend ECS instances based on the forwarding rules of the CLB instance.
-
If the listener for the CLB instance uses the Layer 7 HTTPS protocol, the process is similar to that for HTTP. However, before distributing requests to the backend ECS instances, CLB calls the Key Server to perform certificate validation and packet encryption and decryption.
-
Outbound traffic path
CLB and backend ECS instances communicate with each other over the internal network.
-
If your ECS instances only process requests from CLB, you do not need to purchase public bandwidth resources, such as public IP addresses for ECS instances, elastic IP addresses (EIPs), Anycast EIPs, or NAT gateways.
NoteSome earlier ECS instances were directly assigned a public IP address. You can view this address by running the
ipconfigcommand on the instance. If these instances serve traffic exclusively through CLB, you will not incur public network charges for the ECS instance, even if traffic statistics are visible on the elastic network interface. -
If your backend ECS instances need to serve external traffic directly or require internet access, you must configure or purchase the necessary services, such as a public IP address, EIP, Anycast EIP, or NAT gateway for the instances.
The following figure shows the public traffic path for an ECS instance.
Figure 2. Outbound traffic path
The general principle is: traffic exits through the same path it enters.
-
Traffic that enters through CLB is throttled or billed at the CLB instance. Communication between CLB and ECS instances occurs over the Alibaba Cloud internal network and does not incur public traffic fees.
-
Traffic from an EIP or a NAT gateway is throttled or billed at the respective resource. If you purchase public bandwidth when you create an ECS instance, throttling and billing occur at the instance level.
-
CLB provides only responsive internet access. This means a backend ECS instance can access the internet only to respond to requests forwarded by CLB. To allow a backend ECS instance to initiate outbound connections, you must associate an EIP with the instance or place it behind a NAT gateway.
-
Public bandwidth configured for an ECS instance, an EIP, an Anycast EIP, or a NAT gateway provides two-way internet access for the instance. However, these resources do not offer traffic distribution or load balancing capabilities.
FAQ
CLB bandwidth calculation
No.
The bandwidth of a CLB instance applies separately to inbound and outbound traffic. Alibaba Cloud allocates the purchased amount of bandwidth for each direction. Therefore, both inbound and outbound traffic can independently reach the maximum bandwidth peak.
For more information, see Bandwidth limits.