Docs
ulb
Application Load Balancer ALB
Product Introduction
Technical Architecture

Technical Architecture

Application Load Balancer ALB

ALB is a load balancing service dedicated to application layer load scenarios such as HTTP, HTTPS, based on Nginx, and can receive both intranet and extranet traffic. The architecture is as follows:

ALB adopts a cluster deployment, with at least 4 servers in a single cluster (at least 2 servers in overseas clusters). Tenants share servers at the underlying level, but use Docker for resource isolation and CPU isolation. ALB can simultaneously include a VIP (Virtual IP) and multiple EIPs, using a Proxy mode (that is, Fullnat mode). After receiving the client’s request, ALB converts the client’s connection to ALB VIP (Virtual IP) or EIP into ALB’s proxy IP connection to Backend (service node) actual IP. Therefore, the Backend (service node) cannot directly see the client ip, it can only be obtained through X-Forwarded-For (HTTP mode). In addition, the node health check module is integrated in the ALB process, so there is no need for additional node health check modules.

The intranet traffic of ALB is implemented by ECMP+ BGP for high availability. The ALB server establishes a BGP connection with the uplink switch through Quagga. Multiple servers in the same cluster will initiate the same VIP (Virtual IP) declaration to the uplink switch. In this way, the uplink switch will balance the traffic to each server in the cluster according to the ECMP algorithm. When a server fails, the BGP will be interrupted within three seconds, kicking the failed server out of the cluster and ensuring that the service can still work normally.

When the traffic of ALB enters from the public network, the Client’s access request agent ALB’s traffic enters the UCloud Global POP point and enters UVER (UCloud Global Virtual Edge Router). UVER is a public network traffic computing center independently developed by UCloud Global, which can obtain the next hop information of all EIPs from the business library. After BGP diversion, it will establish a tunnel to deliver the EIP’s traffic to the corresponding next hop. The EIP of an ALB will fall on all servers in the ALB cluster, so UVER will send this part of the traffic to the servers in the ALB cluster according to the consistent hash algorithm.

In ALB, the cluster health check module will periodically probe the server’s survival status. If it finds a problem with the server, it will notify UVER to excise the abnormal server, thereby ensuring high availability. Similarly, the ALB cluster is also highly available across availability zones.