Server Load Balancer:FAQ about CLB listeners

Does CLB support port forwarding?

Yes, CLB supports port forwarding.

For more information, see Redirect requests from HTTP to HTTPS.

If I disable the public network interface controller (NIC), is my CLB service affected?

If an Elastic Compute Service (ECS) instance is assigned a public IP address, your service will be interrupted after you disable the public NIC.

By default, if an ECS instance is assigned a public IP address, the ECS instance uses the public IP address to communicate with the Internet. In this case, network traffic is transferred through the public NIC of the ECS instance. If you disable the public NIC, the ECS instance cannot send responses to the Internet. We recommend that you do not disable the NIC of your ECS instance. If you must, change the destination of the default route to a private IP address. Otherwise, services are affected. In addition, confirm whether you require Internet access, such as access to ApsaraDB RDS instances over the Internet.

Why do connections fail to reach the maximum bandwidth in some scenarios?

• Description: If you purchase an Internet-facing CLB instance whose Internet metering method is pay-by-bandwidth, and you perform stress tests on a client or use a client to transfer large packets, connections may fail to reach the maximum bandwidth.

• Causes:

  CLB provides load balancing services by evenly distributing requests across groups of backend servers. Therefore, bandwidth is evenly allocated to each connection.

  Peak bandwidth for download on a single connection = Total bandwidth of the CLB instance/(N - 1). N represents the number of server groups, which is 4. For example, if you set the maximum bandwidth to 10 Mbit/s in the CLB console, the total bandwidth can reach 10 Mbit/s if multiple clients are used at the same time. The maximum bandwidth of each client is calculated based on the following formula: 10/(4 - 1) = 3.33 Mbit/s.

• Recommended solutions:

  • Change the Internet metering method of the CLB instance to pay-by-data-transfer.

  • Use a Network Load Balancer (NLB) or Application Load Balancer (ALB) instance, an elastic IP address (EIP), and an EIP bandwidth plan. This solution increases the scalability of the ALB or NLB instance and ensures that connections can reach the maximum bandwidth.

Why does CLB fail to reach the maximum QPS in some scenarios?

• Description: In scenarios in which a small number of persistent connections are used, not all backend servers in server groups are allocated persistent connections. As a result, the CLB instance cannot reach the maximum QPS.

• Causes:

  CLB provides load balancing services by evenly distributing requests across groups of backend servers. The maximum QPS that you configure is evenly allocated to each backend server.

  The maximum QPS of each backend server is calculated by using the following formula: Maximum QPS of each backend server = Total QPS/(N - 1). N is the number of backend servers in server groups. For example, if you purchase a CLB instance of the Small I (slb.s1.small) specification in the CLB console, the maximum QPS is 1,000. When multiple clients are used at the same time, the total QPS can reach 1,000. If the number of backend servers is 8, the maximum QPS of each backend server is calculated based on the following formula: 1000/(8 - 1) = 142.

• Recommended solutions:

  • Use short-lived connections on a single client for stress testing.

  • Reduce connection reuse based on business requirements.

  • Upgrade the specification of the CLB instance. For more information, see Upgrade or downgrade a pay-as-you-go (pay-by-specification) instance.

  • Use an ALB instance, which supports higher scalability.

How long is the connection timeout period for each type of listener?

• TCP listener: 10 to 900 seconds.

• HTTP listener:

  • Idle connection timeout period: 1 to 60 seconds.

  • Connection request timeout period: 1 to 180 seconds.

• HTTPS listener:

  • Idle connection timeout period: 1 to 60 seconds.

  • Connection request timeout period: 1 to 180 seconds.

In some scenarios, why does the number of new connections fail to reach the upper limit?

• Problem: After I purchase a CLB instance that uses the pay-by-specification metering method, new connections fail to reach the maximum bandwidth in some scenarios, such as client-side stress testing and single-source access.

• Causes:

  The load balancing system uses cluster deployment to ensure high availability and scalability. Connections from external networks are distributed to multiple system servers in the cluster. As a result, the quota on connections per second is evenly distributed among the servers.

  Maximum number of connections per second = Total number of connections per second of the CLB instance/(N - 1). N represents the number of servers.

  For example, if you purchase a Small I (slb.s1.small) instance, the maximum number of connections per second supported by the CLB instance is 3,000. When multiple clients access the CLB instance, the total number of connections per second can reach 3,000 on the CLB instance. 3,000/(4 - 1) = 1,000. Therefore, each server supports a maximum of 1,000 connections per second.

• Recommended solutions:

  • Change the metering method of the CLB instance: Change the metering method of the CLB instance from pay-by-specification to pay-as-you-go, which does not require you to specify a specification and supports higher performance.

  • Use NLB: NLB is ideal for scenarios that require high concurrency or a large number of new connections per second. NLB supports higher performance and scalability than CLB. CLB supports Limited by servers, CLB supports only a limited number of connections per second. However, NLB can withstand a large number of concurrent connections.

Why do connections to the service address of CLB time out?

Possible causes:

• The service IP address of CLB is blocked for security reasons.

  The IP address of CLB may be blocked due to traffic blackholing, traffic scrubbing, or WAF. WAF offers protection by sending Reset (RST) packets to the client and backend server after a connection is established.

• Client port exhaustion

  Client port exhaustion can cause connection errors, especially in stress tests. By default, CLB removes the timestamps of TCP connections. As a result, the tw_reuse setting does not take effect and connections in the time_wait state cannot be reused. These accumulated connections exhaust all ports.

  Solutions: Set clients to establish persistent connections instead of short-lived connections. Set the so_linger socket option to close connections by sending RST packets instead of FIN packets.

• The accept queue of a backend server is full.

  If the accept queue on the backend servers is full, the backend servers can no longer return syn_ack packets. As a result, requests from clients time out.

  Solution: Set net.core.somaxconn to 128. Specify a proper value based on your business requirements and run the sysctl -w net.core.somaxconn=<Desired value> to change the value of the parameter and restart applications on the backend servers.

• Layer 4 CLB is accessed from backend servers.

  If you access Layer 4 CLB from a backend server, the connection fails. For example, a request that reaches a backend server is redirected to the application on another backend server.

• RST packets are not correctly responded to.

  If no data is transmitted within 900 seconds after a TCP connection is established on CLB, CLB sends RST packets to the client and the backend server to close the connection. If the application on the backend server does not correctly respond to the RST packet, the application may send data packets after the connection is closed. As a result, a CLB connection timeout occurs.

  Note

  The default timeout period is 900 seconds. You can modify the timeout period based on your business requirements.

Why does session persistence fail in some scenarios?

• Check whether session persistence is enabled for the listener.

• HTTP and HTTPS listeners cannot persist sessions by inserting cookies into responses that carry 4xx status codes.

  Solutions: Use TCP listeners instead of HTTP or HTTPS listeners. TCP listeners persist sessions based on client IP addresses. Backend servers can insert or validate cookies to ensure that sessions are persisted.

• HTTP 302 redirects change the SERVERID string for persisting a session.

  When CLB inserts a cookie into a response that carries the HTTP status code 302, the SERVERID string is changed. As a result, the session cannot be persisted.

  To verify the cause, check the requests and responses by using your browser or packet capture software. Then, check whether a 302 status code is included in the packets and whether the SERVERID string in the cookie is changed.

  Solutions: Use TCP listeners instead of HTTP or HTTPS listeners. TCP listeners persist sessions based on client IP addresses. Backend servers can insert or validate cookies to ensure that sessions are persisted.

• The timeout period is set to a small value. You can set the timeout period to a greater value.

How do I view a cookie?

Open your browser and press F12 to check whether SERVERID or a user-defined cookie is inserted into the response. You can also run the curl www.example.com -c /tmp/cookie123 command to save a cookie and then run the curl www.example.com -b /tmp/cookie123 command to view the cookie.

How do I test session persistence by using the Linux curl command?

1. Create a test page.

   Create a test page on each backend server. You can view the private IP address of the backend server on the test page. The following figure shows an example of a test page. The private IP address indicates the backend server to which requests are distributed. The private IP address is used to test whether CLB can persist sessions.

   

2. Run the curl command in Linux.

   In this example, the IP address of the CLB instance that runs Linux is 10.170.XX.XX and the URL of the created page is http://10.170.XX.XX/check.jsp.

   1. Log on to a server that runs Linux.

   2. Run the following command to query the cookie inserted by the backend server:

      curl -c test.cookie http://10.170.XX.XX/check.jsp

      Note

      By default, CLB persists sessions by inserting cookies. However, curl does not send or save cookies. Therefore, you must save a cookie before you perform the test. Otherwise, the curl test result may show that session persistence is invalid.

   3. After you save the cookie, run the following command:

      for ((a=1;a<=30;a++));
          do curl  -b test.cookie http://10.170.XX.XX/check.jsp  | grep '10.170.XX.XX';
          sleep 1;
      done

      Note

      a<=30 indicates the number of tests to be performed. You can set this value based on your business requirements. Set the IP address in grep '10.170.XX.XX' to the private IP address of your ECS instance.

   4. Check the IP addresses that are returned in the preceding tests. If the same IP address is returned, it indicates that CLB can persist sessions.

If a client closes the connection with CLB before the client receives a response, does CLB closes the connection on the backend server side?

No, CLB does not close the connection on the backend server side in this case.

If a request already carries a TCP Option Address (TOA) header before the request is sent to CLB, can CLB preserve the client IP address in the header?

No, CLB cannot preserve the client IP address in the TOA header. By default, if the TOA module is installed, CLB automatically adds the TOA header to preserve client IP addresses. If CLB receives a request that already carries a TOA header, CLB cannot preserve the client IP address in the header.

How do I enable WAF protection for CLB?