This topic describes the architecture of Server Load Balancer (SLB). SLB instances deployed in clusters to synchronize sessions and protect backend servers from single points of failure (SPOFs), improving redundancy and ensuring service stability.

As a traffic forwarding service, SLB forwards client requests to backend servers through SLB clusters and receives responses returned by the backend servers over internal networks.

SLB Features

SLB Components

Basic Architecture Description

Apsara Stack SLB operates at Layer 4 where TCP and UDP are present and Layer 7 where HTTP and HTTPS are present.

• Layer-4 SLB balances loads by using the open-source linux Virtual Server (lvs) and Keepalived software versions that are adapted to cloud computing.
• Layer-7 SLB uses Tengine to balance loads. Tengine is a web server project launched by Taobao (another branch of the Alibaba Group). Based on NGINX, Tengine provides a wide range of advanced features to support high-traffic websites.

In an LVS cluster, each machine uses multicast packets to synchronize sessions with the other machines. As shown in the following figure, Session A established on LVS1 is synchronized to the other LVS machines after the client sends three data packets to the ECS instance. Solid lines indicate the current active connections. Dotted lines indicate a possible data path along which traffic can be sent to the ECS instance if LVS1 fails or is being maintained. This way, you can perform hot upgrades, machine failure maintenance, and cluster maintenance without affecting the operation of business applications.

Inbound network traffic flow

SLB distributes incoming traffic according to the forwarding rules configured in the console or by using APIs. The following figure shows the inbound network traffic flow.

1. For TCP, UDP, HTTP, and HTTPS protocols, the incoming traffic must be forwarded through the LVS cluster first.
2. Large amounts of access requests are evenly distributed among all servers in the LVS cluster. Servers synchronize sessions to guarantee high availability.

• For layer-4 listeners (the frontend protocol is UDP or TCP), the node servers in the LVS cluster distribute requests directly to backend ECS instances according to the configured forwarding rules.
• For layer-7 listeners that use the frontend protocol HTTP, the node servers in the LVS cluster first distribute requests to the Tengine cluster. Then, the node servers in the Tengine cluster distribute the requests to backend ECS instances according to the configured forwarding rules.
• For layer-7 listeners that use the frontend protocol HTTPS, the request distribution is similar to the HTTP protocol. However, before distributing requests to backend ECS instances, the system calls the Key Server to validate certificates and decrypt data packets.

Outbound network traffic flow

SLB communicates with backend ECS instances through the internal network.

• If backend ECS instances only need to handle the traffic distributed from SLB, no public bandwidth (Elastic IP address, NAT gateway, and public IP address) is required, and you do not need to purchase any public bandwidth.

• If you want to provide external services through backend ECS instances, or backend ECS instances need to access the Internet, you must configure at least one of the following: a public IP address, an Elastic IP Address (EIP), or a NAT Gateway.

In general, the traffic goes out from where it comes in:

1. For outbound traffic from SLB instances (that is, traffic transferred through the Internet), traffic is sent at speeds dependent on the current network capacity, and is charged. However, you are not charged for internal communications, such as traffic transferred between SLB instances and backend ECS instances.
2. For outbound traffic from an Elastic IP address or from NAT Gateway (that is, traffic transferred through the Internet), traffic is sent at speeds dependent on the current network capacity, and is charged. Additionally, if an ECS instance is configured with a public IP address when it is created, the outbound traffic from this instance is also charged.
3. SLB supports dynamic access to the Internet. Specifically, if a backend ECS instance needs to access the Internet, you must first configure a public IP address for it (by using an EIP or using NAT Gateway).
4. A public IP address (configured when you create an ECS instance), Elastic IP address, and NAT Gateway all allow mutual Internet access. That is, ECS instances can access the Internet or be accessed from the Internet through any of these. Note, however, that they cannot forward traffic or balance traffic loads.

Read More: https://www.alibabacloud.com/help/doc-detail/27544.htm