General Problems

Besides Baidu AI Cloud, can the BLB support other servers?

Yes. Currently, BLB real servers support not only Baidu Cloud Compute BCC, Dedicated Compute Cluster DCC, and Elastic Baremetal Compute BBC from Baidu AI Cloud, but also other servers through the IP group of Application BLB.

What is the difference between enabling and disabling public network access for a BLB instance?

If public network access is disabled, it provides an internal IP by default for intranet traffic balancer services. If enabled, it automatically purchases and binds a public IP for handling public internet access traffic.

Can I set up a load sharing service on Baidu AI Cloud?

You can purchase a Baidu Cloud Compute instance and deploy HAproxy or Nginx to achieve the load balancer service. However, considering cost-effectiveness, maintainability, and scalability, we recommend directly using the BLB service.

The total count of BLB instances exceeds the upper limit. Can the current service needs increase the BLB quota?

Currently, a user can create up to 60 BLB instances by default. To create more BLB instances, please apply via Quota Management. For other quotas, please refer to: BLB Usage Limits.

The real server does not have a public network EIP. Can I access the public network through BLB?

BLB is solely designed for load balancing and does not allow real servers to access external networks directly. To enable external access, you can bind an EIP to BCC or create a NAT gateway.

Does BLB support IPv6?

BLB now supports IPv6, but usage requires allowlist approval. Users in need can submit a ticket to apply.

Can Windows OS use BLB?

BLB resolves and distributes HTTP/HTTPS protocol requests while WAF provides security protection in between. The operating system of real servers has no specific requirements.

Explanation on the intranet IP of a Ping load balancer instance

Ping messages are responded to by the load balancer device, making it impossible to test the server-side connectivity. To test client-to-server connectivity, use methods for verification, like telnet. When one client experience packet loss via ping, test with multiple clients simultaneously to eliminate potential network issues specific to one client. When multiple clients experience packet loss or connectivity failure via ping, submit a ticket for further investigation.

Explanation on Telnet load balancer listener ports

After setting up a Layer-4 (TCP) listener, Telnet is inaccessible at the listener port unless real servers are bound. Once bound and health checks are successful, Telnet becomes accessible at the listener port.

Under what circumstances is HTTPS mutual authentication required?

Certain clients, such as those in financial services, impose stringent data access security requirements. They require HTTPS certification for both servers and client origins. To meet these clients' needs, we have introduced the HTTPS mutual certification feature.

Does BLB support mounting different ports of the same real server under the same listener?

The current application-type BLB supports configuring different ports for real servers through IP group mounting.

Does BLB support creating multiple listeners with different protocols on the same port?

Supported. Users can create listeners via the console or OpenAPI while choosing different protocols. [Note] TCP and HTTP protocols cannot share the same port simultaneously.

Does BLB support cross-VPC access within the same region?

Supported. Users can create application-based BLB by mounting IP groups and selecting the cross-VPC option on the console. VPC connectivity can be established by configuring peering connections, and users can submit a ticket for technical support to set up OBIP routing. [Note] This feature is currently supported only by Gen-4 or newer virtual machines. All newly created virtual machines are Gen-4 or higher models, so they support this capability.

Does BLB communicate with real cloud server via public network or intranet?

When traffic reaches the designated listener port of the BLB instance, all communication between BLB and Baidu Cloud Compute happens via the internal network. If BLB products are accessed through an EIP, communication between Baidu Cloud Compute and the EIP takes place via the public network, while communication between BLB and Baidu Cloud Compute still occurs internally.

What are the differences between BLB's UDP and TCP protocols?

TCP is a connection-oriented protocol that requires a reliable connection before transmitting data formally. UDP is a connectionless protocol, sending data directly without a three-way handshake. UDP is ideal for scenarios prioritizing real-time performance over reliability, like video chat, financial real-time data push, DNS, and IoT.

Which TCP ports can BLB perform load balancing for?

The BLB product supports TCP listener ports ranging from 1 to 65,535. It is recommended to use standard industry ports when provisioning services since some ports may be blocked during public network access.

What is the length limit of request forwarded by BLB? Adjustment supported or not?

The URI length of requests to the BLB cannot exceed 32 KB, nor can the header length exceed this limit. However, custom adjustments can be made using the client_header_buffer_size and large_client_header_buffer parameters.

• If a client request exceeds the stated limits, a 400 or 414 status code may be returned.
• For transferring large volumes of data, POST transmission is recommended, supporting a maximum request body size of up to 10 GB.

How is BLB cascading scenario used?

For LB cascading scenarios, it is recommended to use non-triangular mode data streams. Avoid using DR or IMF triangular mode data streams, as they may cause communication failures. It is not recommended to cascade BLB, as it may cause data stream interruptions. If users encounter connectivity issues during use, they can contact technical support.

What is the principle of achieving session persistence by load balancer cookies?

Cookie-based session persistence in load balancers offers two approaches: cookie insertion and cookie rewriting. In cookie insertion, the timeout duration of the cookie is sent back to the client, whereas in cookie rewriting, no timeout duration is defined.

In cookie insertion mode, BLB takes responsibility for inserting cookies into the client without requiring modifications from the real server. When a client makes an initial HTTP request without any cookies, BLB uses its load balancing algorithm to select a real server, forwards the request, and receives an HTTP response from the server. Before returning the response to the client, BLB appends a set-cookie header to the reply.

When a client makes a repeated request, the client HTTP request (containing the cookie inserted by BLB previously) reaches BLB. BLB reads the session persistence value from the cookie, compares the cookie value with the real server, and directs the HTTP request (with the same cookie) to the designated server. The real server processes the request and sends a response. Since the server does not modify the cookie, the HTTP reply will not include a cookie, and BLB will not reinsert the cookie into the response but returns it directly to the client.

If BLB cannot resolve the client cookie or finds the RS health check associated with the cookie in a DOWN state, it selects another real server using the configured load balancing algorithm, reinserts the cookie into the response, and returns it to the client.

In cookie rewriting, the rewriting mode modifies the session persistence cookie in the real server based on the server identifier. In inserting mode, if the real server headers lack the corresponding cookie, the cookie is added directly. However, inserting mode assumes that the current request does not require session stickiness and takes no further action. During a client's initial request, the client HTTP request (without a cookie) arrives at BLB. BLB chooses a real server using the load balancing algorithm, forwards the request, and receives an HTTP response (with a cookie) from the real server. BLB processes this response, compares it to the preconfigured cookie name in BLB, modifies the cookie name accordingly, and inserts it into the client’s response.

When a client makes a repeated request, the client HTTP request (containing the cookie inserted by BLB previously) reaches BLB. BLB reads the session persistence value from the cookie, compares the cookie value with the real server, and directs the HTTP request (with the same cookie) to the designated server. The real server responds with an HTTP reply (containing a cookie), which BLB processes, matches the preconfigured cookie name, rewrites it, and inserts it into the client’s response.

What port does HTTPS listener use?

This is not mandatory, but it is recommended to use port 443.

Why does traffic statistics decline after changing TCP listeners to HTTPS/HTTP listeners?

TCP listener is a Layer 4 load balancer, where traffic statistics are measured by the length of IP data messages; Modifying TCP listener to HTTP/HTTPS listener, is a Layer 7 load balancer, where traffic statistics are measured by the body length of HTTP/HTTPS messages; Therefore, after changing the TCP listener to HTTP/HTTPS listener, there will be a numerical decrease in the traffic statistic.

What is real server weight?

Users can define the forwarding weight of each RS in the real server pool. Servers with greater weight ratios receive more connection requests. Users should adjust the settings based on the RS's workload and service capacity.

What are the explanations and potential causes for request responses with status codes 500, 502, 503, or 504?

500（Internal Server Error） The real server encounters an internal error and cannot execute requests. Potential reasons:

• If the real server directly responds with a 500 status code, BLB will pass this status code to the client. Investigate the cause of the 500 error on the real server.
• If a real server unexpectedly terminates connections before sending responses, use packet capturing on the server to diagnose the cause of the abnormal connection interruptions.

502（Bad Gateway） After HTTP or HTTPS listener receives a connection request from the client, if the BLB cannot forward the request to the real server or receive a response from it, it will send an HTTP 502 Bad Gateway status code to the client. Potential reasons:

• If the real server directly responds with a 502 status code, BLB will pass this status code to the client. Investigate the cause of the 502 error on the real server.
• If the BLB real server returns other error status codes, BLB will standardize the response to a 502 status code. Check the upstream_status and status fields in the access logs or use packet capturing to determine whether the real server is functioning correctly.
• TCP communication between BLB and the real server is malfunctioning. Diagnose whether the real server is operational, confirm proper service port listening, or use packet capturing to verify the TCP handshake messages.
• The real server's backlog is full, causing messages to be discarded. Inspect the network statistics of the real server using netstat to verify drop counts, for example with: netstat -s | grep -i listen.
• If health checks for all real servers within the same server group detect issues, the related BLB instance cannot forward requests and will immediately return a 502 status code. Check the real server's logs or examine the health check status to identify potential issues.
• If the client’s message length surpasses the real server’s maximum transmission unit (MTU), this may result in normal health checks or short message handling while issues occur with longer messages. Use packet capture on the real servers to confirm whether message lengths are within acceptable limits.
• The real server might return messages with improper formatting or invalid HTTP headers. Use packet capture on the server to confirm the validity of the HTTP format.
• If the BLB real server cannot complete request processing in a timely manner, analyze its logs and monitor its CPU and memory usage.

503（Service Temporarily Unavailable） The server is temporarily unavailable. Potential reasons:

• If the real server directly responds with a 503 status code, BLB will pass this status code to the client. Investigate the cause of the 503 error on the real server.
• The request is not directed to the appropriate BLB listener. This may occur due to missing listener configuration on the BLB or mismatched listener policies. Review the configuration settings.

504（Gateway Time-out） The real server's response has timed out. Potential reasons:

• If the real server directly responds with a 504 status code, investigate whether the server's workload is excessively high.
• If BLB encounters a connection timeout while attempting to establish a connection with a real server (default timeout: 30 seconds), check whether the upstream_connect_time field in the access logs exceeds 30 seconds. Packet capturing is recommended to determine the cause of server response delays.
• The load on the real server increases, causing the response time to exceed the configured request timeout. For instance, if the request timeout is set to 60 seconds, a response time of 60.001 seconds will trigger a 504 error from the BLB. Check the upstream_response_time in the access logs.

How to check for request imbalance?

Typical factors affecting load balancer distribution include allocation strategies, session persistence, persistent connections, and weights. In other words, whether the final distribution is balanced depends not only on the allocation strategy but also on factors such as using persistent or non-persistent connections and the performance load of the real server.

1. Verify whether session persistence is enabled. If session persistence is configured and the number of clients is small, imbalances can easily occur.
2. Check if the health status of the real cloud servers is normal, paying close attention to any intermittent health check exceptions. Abnormal health checks or status transitions can lead to uneven traffic distribution.
3. Determine whether the load balancer algorithm is using the source IP algorithm. In such cases, requests from the same IP address will be routed to the same backend server, potentially causing uneven traffic distribution.
4. Verify if the real service has enabled TCP keepalive to maintain persistent connections. If enabled, traffic imbalance may occur due to varying request counts over persistent connections.
5. When adding Baidu Cloud Compute to the LB backend, the weight settings will determine the distribution of traffic.
6. The time when a real server is added to the LB can also impact the uneven distribution of requests.

How to troubleshoot uneven traffic distribution on RS?

The current scheduling unit selected by BLB for RS is based on connection scheduling. Once a new connection selects a specific RS, traffic will be forwarded continuously to the RS until the connection ends or times out. Thus, when traffic imbalance occurs on RS, verify whether the connection requests are balanced.

Troubleshoot the condition from the following points:

• Check the scheduling algorithm and confirm whether weight-based scheduling algorithms, such as weighted round robin (wrr), are being used. Also, ensure RS weights are consistently configured to avoid traffic imbalances.
• Examine whether the new connections per second (CPS) are evenly distributed across all RSs. If they are not, it could lead to traffic imbalances.
• Check if all RSs are mixing persistent and non-persistent connections.
• Ensure that the number of connections is not set too low.

How to check high latency in load balancer service access?

Generally, check from the following aspects:

1. Bind an EIP to the real cloud servers to bypass the elastic load balancer, directly access the backend service, and observe the access latency. This helps determine if the issue lies with the elastic load balancer, frontend network, or backend service.
2. Check whether the service traffic exceeds the EIP bandwidth limit, as this can cause congestion, packet loss, and other anomalies.
3. If direct access to the backend shows significant latency, troubleshoot to confirm whether the backend service is under excessive pressure or if security policies are configured, among other factors.
4. Analyze the abnormal host counts to see if the health status of real cloud servers shows instability. When backend conditions are poor, the elastic load balancer's retry mechanism may redirect a request to the next server after a connection timeout. While the request ultimately succeeds, this can cause significant latency during service access.
5. If the issue persists, please contact us by submitting a support ticket.

Does BLB instance support client IP passthrough?

Currently, for TCP/UDP-based BLBs, newly added BCC real servers have client IP passthrough enabled by default, meaning the source address seen on real servers will be the client IP.

For HTTP/HTTPS listeners, client IP passthrough is not supported. Users can enable the "Obtain real IP via X-Forwarded-For" option to retrieve the client IP by parsing the HTTP header on the real server.

For SSL listeners, the ProxyProtocol is supported. Users can enable this option and parse the ProxyProtocol standard protocol on the real server to obtain the client IP.

The BLB instance's real servers send back responses to the request in batches, but the client sees that only one request is received. Does BLB support not caching the response requests from real servers?

With proxy buffering enabled, the BLB stores real server responses in local memory or on disk before delivering them to clients at an optimized rate.

BLB provides custom configuration functionality for clients to disable this function. To disable proxy buffering: Enable the Custom Configuration option and enter "proxy_buffering:off" in the command input box For other custom configuration fields, see: Custom Configuration Guide.

What scheduling algorithms does the BLB product support?

BLB currently offers support for weighted round-robin, least connections, and source IP distribution methods.

1. Weighted round-robin When the scheduling algorithm is set to weighted round-robin, servers are queried sequentially based on their weight settings, to ensure that the actual connections align with the weight configuration. It is commonly used for non-persistent connection services, such as HTTP services.
2. Least connections When the scheduling algorithm is set to “least connections”, weight settings become invalid, and BLB always selects the real server with the minimum current connections to establish links. It is commonly used for persistent connection services, such as database services.
3. Source IP When the scheduling algorithm is set to source IP, weight settings become invalid. After performing a hash operation on the source IP of the request, the request is dispatched to a matching server. This can ensure that requests from the same client IP are always dispatched to a specific server.

Under what circumstances should BLB be purchased together with EIP?

When requesting a BLB instance, binding an EIP allows access to public network services, if needed.