Classic Load Balancer (CLB) instances are the ingress for incoming traffic from clients. CLB instances forward the requests received from clients to backend servers, which handle the requests.
State
In most cases, a CLB instance is in one of the following states:
Running: The instance is running as expected. It cannot be deleted if Deletion Protection is enabled, or modified if Configuration Read-only Mode is enabled.
Locked (Overdue Payment): The instance is locked due to overdue payments on your account. You cannot delete or modify the instance. Complete all due payments to unlock your account and resume your instance.
Locked (Security Risks): The instance is locked due to security risks. It cannot be deleted or modified. Go to Security Control console - Network security control events to apply for unlocking.
Stopped: The instance is stopped. It can be deleted but cannot be modified.
Network type
When you create a CLB instance, you can make it an Internet-facing CLB instance or an internal-facing CLB instance.
An Internet-facing CLB instance is assigned a static public IP address. The instance uses this IP address to communicate over the Internet. This IP address cannot be disassociated from the instance or used for other instances. Clients cannot access the instance with private IP addresses.
The following figure shows how an Internet-facing CLB instance provides load balancing services.
An internal-facing CLB instance is assigned a private IP address within the CIDR block of the vSwitch (and VPC) you specify when you create the instance. The instance can only forward requests from clients with access to the VPC for the instance. The instance cannot be accessed with public IP addresses. However, if you associate an elastic IP address (EIP) with the instance, the instance becomes accessible over the Internet.
The following figure shows how an internal-facing CLB instance provides load balancing services.
Internet- and internal-facing CLB instances cannot convert to each other. Ensure you understand this limitation before creating a CLB instance.
Specification
You can specify how your CLB instance is billed when you create it, either Pay-By-Specification or Pay-By-LCU.
Pay-by-specification CLB instances
Pay-by-specification CLB instances include high-performance CLB instances and shared-resource CLB instances.
Shared-resource CLB instances are the previous generation of CLB instances and are not available for purchase now. New CLB instances you create are all high-performance CLB instances.
High-performance CLB instances
High-performance CLB instances have the following metrics:
Maximum concurrent connections
The maximum number of concurrent connections that a CLB instance supports. If this limit is reached, new connection requests are dropped.
Connections per second (CPS)
The maximum number of new connections that can be established per second. If this limit is reached, new connection requests are dropped.
Queries per second (QPS)
The number of HTTP or HTTPS queries (requests) that can be processed per second. This metric is specific to Layer 7 (HTTP and HTTPS) listeners. If this limit is reached, new query requests are dropped.
The specification for a CLB instance indicates the maximum performance it supports, measured by these metrics, as shown in the following table:
Specification | Maximum concurrent connections | CPS | QPS |
Small I (slb.s1.small) | 5,000 | 3,000 | 1,000 |
Medium I (slb.s2.small) | 50,000 | 5,000 | 5,000 |
Medium II (slb.s2.medium) | 100,000 | 10,000 | 10,000 |
Large I (slb.s3.small) | 200,000 | 20,000 | 20,000 |
Large II (slb.s3.medium) | 500,000 | 50,000 | 30,000 |
Super Large I (slb.s3.large) | 1,000,000 | 100,000 | 50,000 |
Shared-resource CLB instances
Pay-by-LCU CLB instances
The maximum performance for a pay-by-LCU CLB instance is the same as the Super Large I (slb.s3.large) specification.
If you require more concurrent connections for Layer 4 load balancing, use Network Load Balancer (NLB). If you require higher QPS for Layer 7 load balancing, use Application Load Balancer (ALB).
IP version
You can specify whether your CLB instance uses IPv4 or IPv6 to provide load balancing services.
IPv4: The CLB instance is assigned an IPv4 address for communication. Clients can access the instance only using IPv4 addresses, for example, 192.168.0.1.
IPv6: The CLB instance is assigned an IPv6 address for communication. Clients can access the instance only using IPv6 addresses, for example, 2001:db8:1:1:1:1:1:1.
CLB does not support dual-stack instances (cannot provide IPv4 and IPv6 services at the same time).
Benefits and limitations of IPv6 CLB instances
Benefits
You can switch backend services from IPv4 to IPv6 without service interruptions.
IPv6 CLB instances support backend servers that use IPv4 addresses. You can migrate services from IPv4 to IPv6 backend servers without changes to existing systems.
When network traffic increases, you can add an IPv6 gateway to your CLB instance and scale out backend servers without impacting exisiting IPv4 services.
Limitations
Only Internet-facing CLB instances support IPv6 addresses; internal-facing ones do not.
IPv6 CLB instances are only available in specific regions.
IPv6 packets have longer IP headers than IPv4 packets. To prevent oversized packets from being dropped, the maximum transmission unit (MTU) of your system may require updates.
If your CLB instance uses UDP listeners, the MTU supported by the ENI that each backend server uses to communicate with CLB cannot exceed 1,200 bytes. Also, modify the MTU settings in the configuration files of your applications accordingly.
If TCP listeners are used, no configuration changes are required because TCP supports the Maximum Segment Size (MSS) announcement.