Differences Between Classic and Shared Load Balancers

Each type of load balancer has their advantages.

Table 1 compares the features supported by the two types of load balancers. √ indicates that an item is supported, and — indicates that an item is not supported.

Table 1 Features supported by each type of load balancers

Feature

Description

Classic

Shared

Load balancing over public and private networks

  • Each load balancer on a public network has a public IP address bound to it and routes requests from clients to backend servers over the Internet.
  • Load balancers on a private network work within a VPC and route requests from clients to backend servers in the same VPC.

Layer 4 and Layer 7 load balancing

  • Layer 4 load balancing: After receiving TCP or UDP requests from the clients, the load balancer directly routes the requests to backend servers. Load balancing at Layer 4 features high routing efficiency.
  • Layer 7 load balancing: After receiving an HTTP or HTTPS request, the load balancer identifies the fields in the HTTP/HTTPS packet header and routes the request based on these fields. Though the routing efficiency is lower than that at Layer 4, load balancing at Layer 7 provides some advanced features such as encrypted transmission and cookie-based sticky sessions.

√ (UDP is not supported for load balancers on a private network.)

Load balancing algorithm

Round robin, least connections, and source IP hash

Sticky session

If you enable sticky sessions, requests from the same client will be routed to the same backend server during the session.

WebSocket protocol

WebSocket is a new HTML5 protocol that provides full-duplex communication between the browser and the server. WebSocket saves server resources and bandwidth, and enables real-time communication.

Domain name- or URL-based forwarding

ELB allows you to add forwarding policies to forward requests to different backend server groups based on the domain names or URLs specified in the forwarding policies.

√ (Currently, you can add forwarding policies only to HTTP or HTTPS listeners.)

Adding ECSs as backend servers

You can add ECSs to backend server groups to handle requests from load balancers.

Whitelist-based access control

You can whitelist the IP addresses that can access a listener.

Standard OpenStack APIs

OpenStack APIs are supported and are compatible with self-developed APIs.

Adding BMSs as backend servers

BMSs can also be used as backend servers to handle requests distributed by load balancers.

SNI for certificates

Server Name Indication (SNI) is an extension to Transport Layer Security (TLS) and is used in cases that a server uses multiple domain names and certificates. After SNI is enabled, certificates corresponding to the domain names are required.

SSL protocol

Load balancers use SSL to receive requests from clients.

OBS storage for access logs

Access logs of load balancers can be dumped to OBS buckets for storage.

Server weight

You can configure different weights for backend servers when you select the round robin or least connections as the load balancing algorithm.

Modifying certificate content

You can modify the content of a certificate.

Mutual authentication

The identities of both communication parties are authenticated to ensure security. You need to deploy both the server certificate and client certificate. Only HTTPS listeners support this feature.

HTTP redirection

HTTP traffic is redirected to HTTPS. When the client sends an HTTP request, the backend server returns an HTTPS response.

Performance monitoring on a per listener basis

Cloud Eye allows you to monitor your resources, including load balancers.

Parent topic: Service Overview