Product Introduction

1.1 What is ULB 

1.1.1 Introduction to ULB

ULB (SCloud Load Balancer) is a load balancing service provided by SCloud, which can provide traffic distribution functions based on network packets or proxy for multiple hosts or other service instances. In a high-concurrency service environment, a service cluster composed of multiple real servers is constructed through ULB. The service cluster can expand the processing and fault tolerance capabilities of the service, and automatically eliminate the impact of the failure of a single real server on the service as a whole, and improve the availability of the service.

ULB supports HTTP and HTTPS protocols (like Nginx or HAproxy) for the seven-layer protocol; the four-layer protocol supports TCP protocol and UDP protocol (like LVS).

1.1.2 ULB composition

ULB service is mainly composed of the following three parts:

  • ULB service instance (SCloud LoadBalancer): used to receive and distribute traffic.
  • Virtual server/listener (VServer): Listener, each VServer is a set of load balancing front-end port configuration.
  • real server(RealServer/Backend): The backend actually processes the requested cloud resources.

 

 

1.2 Product function

Product function Public ULB Private ULB Description
Layer 4 forwarding (TCP/UDP)
Layer 7 forwarding (HTTP/HTTPS)
Load balancing algorithm Round robin, source address hashing, weighted round robin, least connections , primary/standby Round robin, source address hashing, consistent hashing, least connections , primary/standby
Health Check Perform health checks on back-end real servers according to rules, automatically isolate abnormal real servers. Once problems are found, quickly switch the problem nodes to ensure service availability.
Session persistence Support session persistence, users can forward their requests to the same back-end real server.
Disaster recovery cross availability zones Support binding back-end real servers in different availability zones to achieve disaster recovery cross availability zones
Public firewall Only request proxy type support, and only take effect for Layer 7 traffic
Domain name forwarding Support forwarding traffic to different back-end nodes according to the access domain name and URL
Certificate management Support HTTPS certificate management
SSL Offloading Support HTTPS SSL Offloading
WebSocket Only support when monitoring TCP protocol
IPv6 address support Support IPv6 traffic forwarding
Mount hybrid cloud node Only request proxy type support
ULB log Only proxy type support is requested
HTTP/2 Work order support Work order support Work order support HTTP/2
Redirection HTTP access redirection to HTTPS is not currently supported
Two-way authentication HTTPS two-way authentication is not currently supported

 

1.3 Technical architecture

ULB (SCloud Load Balancer) provides the ability to distribute traffic to ensure business scalability and high availability. It supports two scenarios, private network and public network, and supports two forwarding modes: request proxy and message forwarding. The following will introduce the basic architecture of ULB’s request proxy (hereinafter referred to as ULB7) and message forwarding mode (hereinafter referred to as ULB4) respectively.

1.3.1 Nouns

UVER: SCloud Virtual Edge Router, SCloud’s public network traffic forwarding center. UVER obtains the next hop information of all EIPs from the service database, and encapsulates and forwards EIP traffic.

1.3.2 Private ULB4

Private ULB4 is self-developed based on DPDK technology. A single server can provide more than 30 million concurrent connections, 10 million pps, and 10G wire-speed forwarding capability. Using cluster deployment, a single cluster has at least 4 servers. Use ECMP + BGP to achieve high availability.

The private ULB4 uses a forwarding mode similar to DR. The schematic diagram of private load balancer forwarding is as follows:

 

As shown in the figure above, the ULB4 cluster announces the same VIP (virtual IP) to its connected access switches, and the access switches are configured with ECMP algorithms, which can load balance traffic to multiple ULB servers, thus forming a ULB4 cluster. When some servers in the ULB4 cluster are forwarded abnormally, BGP packet forwarding will also stop forwarding. The ULB4 server will be removed from the server cluster within three seconds to ensure high availability. At the same time, the ULB4 cluster health check module will also issue an alarm, allowing the engineer to intervene in processing. In addition, the servers in the same ULB4 cluster are distributed across availability zones to ensure the high availability of the ULB4 cluster across availability zones. There is a module in ULB4 that is specifically responsible for the health check of the back-end node (currently only supports TCP/UDP port detection), and reports to ULB4Manager and ULB4 forwarding server. After the ULB4 forwarding server receives the client’s business message, it will select one of the normal back-end nodes, modify the destination mac and tunnel to the back-end node. The source IP and destination IP remain unchanged during the process. In ULB4 mode, the back-end node must bind ULB4’s VIP (virtual IP) address to the LO port and monitor the service to correctly process the message, and unicast the return packet directly to the Client. This is a typical DR process, so the private ULB4 can directly see the source IP of the Client.

1.3.3 Public ULB4

The public ULB4 is similar to the private ULB4 and is also self-developed based on DPDK technology. A single server can provide more than 30 million concurrent connections, 10 million pps, and 10G wire-speed forwarding capability. Using cluster deployment, a single cluster has at least 4 servers. Use ECMP + BGP to achieve high availability. Similarly, it uses a forwarding mode similar to DR. The diagram of public load balancer forwarding is as follows:

 

Unlike the private ULB4, the public traffic comes in from the public network. The traffic from the Client accessing ULB4 enters the SCloud POP point and enters UVER (SCloud Virtual Edge Router). UVER is a public network traffic calculation center developed by SCloud. It can obtain all EIP next hop information from the business database. After diversion through BGP, tunnel EIP traffic to the corresponding next hop. A ULB4 EIP will fall on all servers in the ULB4 cluster, so UVER will send this part of the traffic to each server in the ULB4 cluster according to the consistent hash algorithm. The subsequent process is similar to the private ULB4. The Backend node needs to bind the ULB’s EIP to the LO port and monitor the service, and the backhaul message will be sent directly to the UVER and returned to the Client via the internet.

In the public ULB4, the cluster health check module will periodically detect the survival status of the server. If it finds that there is a problem with the server, it will notify UVER and remove the abnormal server to ensure high availability. Similarly, the public ULB4 cluster is also highly available across availability zones.

1.3.4 Private ULB7

ULB7 is developed based on Haproxy, and a single instance can support more than 40w pps, 2Gbps, and at least 400,000 concurrent connections. The architecture is as follows:

 

Private ULB7 adopts cluster deployment, with at least 4 servers in a single cluster. Tenants share servers at the bottom layer, but use Docker for resource isolation and CPU isolation. Unlike the DR mode used by ULB4, ULB7 uses the Proxy mode (ie Fullnat mode). After receiving the client’s request, the private ULB7 converts the connection from the client to the ULB7 IP into a connection from the proxy IP of ULB7 to the actual IP of the Backend (real server). Therefore, the Backend (real server) cannot directly see the Client IP, and can only be obtained through X-Forwarded-For (HTTP mode).

The private ULB7 uses ECMP+BGP to achieve high availability, and the private ULB7 server establishes a BGP connection with the uplink switch through Quagga. Multiple servers in the same cluster will initiate the same VIP (virtual IP) announcement to the upstream switch. In this way, the uplink switch will load balance the traffic to the servers in the cluster according to the ECMP algorithm. When a server is abnormal, BGP will be interrupted within three seconds, thereby kicking the failed server out of the cluster and ensuring that the service can still work normally.

1.3.5 Public ULB7

ULB7 is developed based on Haproxy, and a single instance can support more than 40w pps, 2Gbps, and at least 400,000 concurrent connections. ULB uses the affinity of the CPU to achieve core isolation and resource control.

 

Unlike the DR mode used by ULB4, ULB7 uses the Proxy mode, which is Fullnat mode. After receiving the request from the Client, ULB7 converts the connection from the client to the ULB7 EIP into a connection between the proxy IP of ULB7 and the actual IP of the Backend (real server). Therefore, Backend cannot directly see the Client IP. In addition, the node health check module is integrated in the ULB7 process, so no additional node health check module is required.

Similarly, in the public ULB7, the cluster health check module will periodically detect the survival status of the server. If it finds a problem with the server, it will notify UVER and remove the abnormal server to ensure high availability. Similarly, the public ULB7 cluster is also highly available across availability zones.

1.3.6 Pattern comparison

Compared with ULB7, ULB4 has stronger forwarding capability, which is suitable for scenarios where forwarding performance is pursued. The ULB7 can process the layer 7 data, perform SSL offloading, perform domain name forwarding, path forwarding and other functions, and the back-end node does not need to configure additional VIP (virtual IP).

 

1.4 ULB performance index

  • New connections per second (CPS): The number of new connections per second, reflecting the ability to handle new connections.
  • Maximum number of concurrent connections: The total number of connections per second, reflecting the ability to handle connections concurrently.
  • Thenumber of packets processed per second (PPS): The amount of packets forwarded per second, reflecting the packet forwarding rate.
  • Maximum throughput: the bandwidth that can be supported.
  • Requests per second (QPS): The number of queries per second. QPS is not a core indicator for ULB. What really consumes performance is CPS. In the case of short connection, QPS = CPS; in the case of long connection, QPS > CPS.

Note that:

1) A single ULB packet can be forwarded to achieve the performance shown in the following table, request to proxy ULB instances in a single VPC to share resources.

2) After opening the ULB log management function, there will be a 10% performance loss.

Product Pattern New connections per second (cps) Maximum number of concurrent connections Maximum throughput (bps) The number of packets processed per second (PPS)
Public ULB Message forwarding 600,000 100,000,000 30G 18,000,000
Public ULB Request proxy 40,000 (4,000 ssl) 300,000 800M 400,000
Private ULB Message forwarding 600,000 100,000,000 30G 21,000,000
Private ULB Request proxy 40,000 (4,000 ssl) 300,000 800M 400,000

 

1.5 restrictions

1.5.1 Routing configuration

In order to ensure that ULB can correctly forward data to the back-end real server, it is necessary to ensure that the firewall/router of the ULB back-end real server allow access to the corresponding network segment, otherwise the host may not be able to normally provide service.

1.5.2 HTTP header restriction

The default header size of ULB is 8K. When configuring, make sure that the size of the HTTP header does not exceed 8K, otherwise the ULB will not work properly.

1.5.3 Quota restriction

Message forwarding ULB Request proxy ULB
The number of EIPs that can be bound 20 100

 

Purchasing guide

2.1 Product price

Network type ULB instance fee Bandwidth fee
Public ULB Free Please refer to EIP charging instructions for public bandwidth costs.
Private ULB Free Free

 

2.2 Product selection

2.2.1 ULB: Load balancing type/network mode

Load balancing type

Load balancing type Support protocols
Message forwarding HTTP, HTTPS, TCP
Request proxy TCP、UDP

The historically created instances are compatible and can include both request proxy and message forwarding VServers.

1) The difference between request proxy load balancing TCP and HTTP

TCP: Receive the request, select the back-end node, connect to the back-end node, and forward the content; it can directly forward the messages of other upper-layer protocols to the back-end real server.

HTTP: Receive the request, parse the request, select the real server cluster according to the forwarding rules, select the back-end real server according to the ULB algorithm, connect the real server, receive the response, parse the response header, add the appropriate response header (such as Set-cookie, etc.), and return Response content to the client.

2) The difference between request proxy TCP and message forwarding TCP

Request proxy: two TCP connections from the client to the ULB and ULB to the back-end real server need to be maintained (two TCP handshakes are required).

Message forwarding: Only the analysis and forwarding of the message is required, and the connection establishment overhead is reduced. The efficiency of message forwarding is several orders of magnitude higher than that of the request proxy mode, but it has the following limitations:

  • ULB only modifies the destination MAC address, and does not support the back-end real serverto monitor different ports. If the listening port is inconsistent with the service receiving port, it will cause data transmission errors.
  • The back-end real servermust be configured with the ULB service IP address.

If there is no need to monitor multiple ports on one real server, the message forwarding mode can be selected, and the forwarding performance is superior.

 

Network mode

1) Public ULB

The public ULB, the IP address for public services is the public EIP, which is used to receive client requests from the Internet. If you need ULB to forward public requests, select “Public Network” when creating ULB.

For EIP, attributes such as bandwidth and billing mode need to be selected according to the business.

2) Private ULB

In the private ULB, the IP address for private services is the private IP, which is used to receive client requests from the private network. If you need ULB to forward private requests, select “Private Network” when creating ULB. The private IP address will be assigned from the selected subnet.

2.2.2 VServer: Listener Protocol

The ULB protocols are divided into four-layer protocols and seven-layer protocols. The four-layer protocols include TCP/UDP. Seven-layer protocols include HTTP and HTTPS.

Four-layer protocol (TCP/UDP)

Load balancing is performed based on the IP address and the port number, and the processing is forwarded to the back-end real server.

  • UDP protocol: It only needs to perform load balancing according to the service IP address and port, does not require high reliability, and does not require error recovery and data retransmission services.
  • TCP protocol: It only needs to perform load balancing according to the service IP address and port, which requires high reliability. It is a business that requires handshake before data transmission to ensure data reliability.

 

Seven-layer protocol (HTTP/HTTPS)

On the basis of the four layers, considering the characteristics of the application layer, in addition to the IP address and port, load balancing can be performed based on information such as the URL of the seventh layer.

  • HTTP protocol: It not only needs to monitor the service IP address and port, but also needs to perform load balancing based on the content of the application layer, such as URL, but does not require high security services.
  • HTTPS protocol: Not only need to monitor the service IP address and port, but also need to perform load balancing according to the application layer content, such as URL, etc., which requires high security and requires encryption.

 

Selection guide

  • If the business does not need to perform load balancing for application layer information, only the service IP address and port need to be monitored, and the four-layer ULB can be selected.
  • For higher performance requirements, four-layer ULB can be selected.
  • If you need to perform load balancing based on application layer information such as URL and domain name, or require HTTP health detection, or HTTPS SSL offloading, you can choose seven-layer ULB.

2.2.3 Load balancing algorithm

  • Poll. After ULB receives the new TCP connection, it forwards it to each back-end real serverin turn.
  • Source address. ULB will use a certain hash algorithm to forward the request to a certain real serveraccording to the source address of the TCP connection. After the user accesses with the same source IP, if the number of real servers remains unchanged, the access will still fall to the real server.
  • Source address (compute port). ULB will use a certain hash algorithm to forward the request to a certain real serveraccording to the source address and source port of the TCP connection. (Only supported by message forwarding mode)
  • Consistent hash. The consistent hashing algorithm is based on the source and destination IP, using the consistent hashing algorithm to select the back-end real server. If you add or delete back-end real servers, only a small part of the connections will be affected. (Only supported by message forwarding mode)
  • Consistent hash (computing port). According to the source and destination IP, source and destination port, the back-end real serveris selected using the result of the consistent hash algorithm. If you add or delete back-end real servers, only a small part of the connections will be affected. (Only supported by message forwarding mode)
  • Weighted round robin. After ULB receives a new TCP connection, it will be assigned to each real serveraccording to the probability according to the different weights of the back-end real server you specify.
  • Least connections. After ULB receives a new TCP connection, it will count the number of connections between ULB and the back-end real serverin real time, and select the real server with the lowest number of connections to establish a new connection and send data. (Only request proxy mode support)
  • Primary/standby. Only two real servers can be added under the VServer as the primary/standby When the health check of the primary node fails, it will automatically switch to the standby node. (If there are real servers under the VServer, it is not allowed to switch from other load balancing algorithms to the primary/standby algorithm.)
Pattern Support forwarding algorithm
Message forwarding Round robin, source address, weighted round robin, source address (computing port), consistent hash, consistent hash (computing port), primary/standby
Request proxy Round robin, source address, weighted round robin, least connections , primary/standby

 

 

 

 

 

 

 

Operation guide

3.1 ULB

3.1.1 Create ULB

Operation steps

1) Enter the ULB load balancer page.

 

2) Click Create Load Balancer to create ULB instance.

3) Fill in the configuration information and create a ULB instance. Detailed configuration instructions are shown below.

 

4) Click Purchase Now, the creation is successful.

 

Configuration instructions

Configuration Instructions
Region The region to which the ULB belongs. After selecting a region, you can add back-end real servers only in that region.
Load balancing type Divided into two types: request proxy type (Application Load Balancer) and message forwarding type (Network Load Balancer). Request proxy type supports HTTP, HTTPS, TCP, and message forwarding type supports TCP, UDP.
Network scheme Divided into two modes: private (Internal Only) and public (Internet Facing). In the private network, the address provided by ULB is the private IP address. As for the public network, the address provided by ULB is the public EIP.
VPC The VPC network to which ULB belongs. After the VPC is selected, the back-end real server can only add cloud resources under the same VPC.
Subnet After selecting the Internal Only scheme, you need to select the corresponding subnet. Assign the private IP address from this subnet as the IP for ULB to provide services to the public.
EIP After selecting the Internet Facing scheme, you need to configure the public EIP as the IP address for ULB to provide public services. You can choose New Purchase or Existing EIP.
Billing method When choosing New Purchase EIP, you need to select the billing method. Options includes: bandwidth, traffic, shared bandwidth, etc.
Bandwidth When choosing New Purchase EIP, you need to select the bandwidth value.
DDos attack protection The protection function is provided by the UClean product, which supports distributed cleaning of attack traffic, and can resist hundreds of G-level large-flow attacks.
Firewall After selecting the Internet Facing scheme, you can bind the firewall for access control. Optional Not bound and Bind.
Instance name ULB instance name
UGroup The management business group to which the ULB belongs.

 

3.1.2 Delete ULB

After deleting the ULB instance, the bound EIP will be deleted.

If the EIP needs to be retained, you can unbind it first, and then delete the ULB instance.

Operation steps

1) Enter the ULB load balancer page.

2) Select the ULB instance to be deleted and click Delete.

 

3) The ULB instance will be deleted.

3.1.3 Edit ULB

Enter the ULB load balancer page, you can edit the properties of the ULB instance.

Modify name and remark

There are two ways to modify the name and remark, respectively on the ULB list page and ULB overview page.

1) ULB list page

On the ULB list page, click Edit Name and Remark in the name column.

 

Click the shield icon next to the resource ID to view the details of UClean (that is, the DDos attack protection is selected when ULB was created).

 

2) ULB overview page

On the ULB list page, select the ULB instance that needs to be modified.

Click Details to enter the details page.

In the basic information, click the edit icon behind the resource name.

 

 

Edit UGroup

Edit UGroup supports a single ULB instance change or in batches.

1) Change UGroup of a single ULB

Method 1: After selecting the resource on the ULB list page, click Edit UGroup.

Method 2: After selecting the resource on the ULB list page, click Details to enter the overview page. In the basic information, click the edit icon behind the UGroup.

2) Change UGroup in batches

In the ULB list page, select the check box on the left of the resource in batches. Then Click Edit UGroup at the top.

 

3.1.4 Bind/Unbind EIP

Enter the ULB load balancer page and perform the following operations on the EIP bound to the ULB.

The public ULB needs to be bound to at least one EIP to provide public services normally. Up to 20 EIPs can be bound to one ULB.

 

Bind EIP

Method 1:After selecting the public ULB resource in the ULB list page, click Bind Elastic IP, and select the existing EIP from the drop-down box. If there is no EIP, you can go to the UNet page to apply.

Method 2: After selecting the ULB resource in the ULB list page, click Details to enter the overview page. In the public EIP page, click to bind.

 

 

Unbind EIP

  • After selecting the ULB resource inthe ULB list page, click Details to enter the overview page. In the public EIP page, select the EIP that needs to be unbound, and click Unbind.

 

2) To unbind EIPs bound to ULB in batches, you can go to the UNet EIP page to operate.

 

Change bandwidth

After selecting the ULB resource in the ULB list page, click Details to enter the overview page. In the public EIP page, select the EIP whose bandwidth needs to be changed, and click Edit Bandwidth.

 

3.2 VServer

3.2.1 Add VServer

Operation steps

After the ULB instance is created, you can click Details to enter the VServer management page to add a VServer.

1) Click Add VServer on the VServer management page.

2) Fill in the configuration information and create the VServer. Detailed configuration instructions are shown below.

 

Configuration instructions

The options for creating a VServer listener include the following:

Configuration Instruction
VSserver name Required
Protocol and port The protocol and port monitored by the listener, including HTTP/HTTPS/TCP/UDP four protocols
Scheduling method How the listener loads data packets.
Real server In general, adding a real server needs to be done after the VServer listener is created. This option provides a method to copy the configuration of the real server pool from other VServers, so that it can be quickly created using the original configuration.
Session persistence For HTTP/HTTPS protocols, use Auto Generate/User-Defined KEY to keep the user login state. For TCP (message forwarding)/UDP, the default connection timeout period is 900s. After enabling/disabling the session persistence, the current long connection may be interrupted and reconnected. After enabling the session persistence, you can set the session persistence time, and the session persistence time and connection timeout both are the set values.
Connection Idle Timeout In TCP request proxy mode, or HTTP, HTTPS protocol, you can select the effective time of the client request connection. Optional time range [1-86400] seconds.
Real server health check Health check type. UDP protocol supports port check, PING check and UDP check; TCP protocol supports port check; HTTP/HTTPS protocol supports port check and HTTP check.

 

3.2.2 Delete VServer

Operation steps

Enter the VServer management page.

1) Delete a single VServer

Select the VServer to be deleted, and click the VServer name on the left.

In the overview information on the right, click Delete VServer to complete the deletion.

 

2) Delete VServers in batch

Click Manage VServer, and a management pop-up window will be displayed.

In the VServer list page, select the check box on the left of the resource in batches.

 

Click Delete to complete batch deletion.

3.2.3 Edit VServer configuration

Enter the VServer management page to Edit VServer configuration.

Operation steps

Basic information module on the right, click Edit settings.

 

A pop-up window for editing the VServer settings shows, and you can change the VServer configuration. The configuration that can be changed is as follows, and the configuration that is not modified remains unchanged.

 

Configuration Instruction
VSserver name Required
Protocol and port The protocol and port monitored by the listener, including HTTP/HTTPS/TCP/UDP four protocols
Session persistence For HTTP/HTTPS protocols, use Auto Generate/User-Defined KEY to keep the user login state. For TCP (message forwarding)/UDP, the default connection timeout period is 900s. After enabling/disabling the session persistence, the current long connection may be interrupted and reconnected. After enabling the session persistence, you can set the session persistence time, and the session persistence time and connection timeout both are the set values.
Connection Idle Timeout In TCP request proxy mode, or HTTP, HTTPS protocol, you can select the effective time of the client request connection. Optional time range [1-86400] seconds.
Real server health check Health check type. UDP protocol supports port check, PING check and UDP check; TCP protocol supports port check; HTTP/HTTPS protocol supports port check and HTTP check.

 

3.3 Real server

3.3.1 Add real server

After the VServer listener is created, you need to add a real server to the VServer before the load balancer can officially provide services to the outside world.

Operation steps

1) Go to the VServer management page and choose the real server page, click Add Real Server.

 

 

Configuration Instruction
Resource type Required
VPC If the real server type is a hybrid cloud host, you need to select a hybrid cloud VPC that has been connected to the VPC to which the current ULB belongs.
Corresponding subnet The subnet to which the real server belongs. You can select All subnets or Specified subnets.
Listener port The listening port of the real server. The real server port has the following restrictions: If the VServer listener type is a seven-layer ULB or four-layer ULB in request proxy mode, different ports can be added to the same back-end real server to achieve different service instances with the same IP; if using four-layer ULB UDP Protocol or TCP message forwarding mode, the port of the back-end real server must be the same as the listening port of the VServer.
Available resources According to the selected information, the current real server resources that can be added are displayed. If the resource type is a hybrid cloud host, you need to fill in the hybrid cloud host’s private IP.

When adding hybrid cloud (hosted cloud) resources, the hosted cloud VPC must communicate with the VPC where ULB is located.

2) In the list of available resources, select the check box that needs to add, and move it to the Real server to be added list on the right.

Add cloud host/physical cloud host/container/hosted Hadoop cluster, fill in the Listener Port and then select the resource.

3.3.2 Delete real server

Operation steps

Go to the VServer management page and click Real Server.

1) Delete a single real server

Select the real server to be deleted, and click Delete on the right. A pop-up window will display the selected real server information, and confirm whether it is the real server to be deleted. Click OK to finish deletion.

 

2) Delete real servers in batches

Select the check boxes on the left of the servers that need to be deleted in batches, and click Delete at the top. A pop-up window will display the selected real servers information, and confirm whether they are the real servers to be deleted. Click Delete to complete batch deletion.

 

3.3.3 Disable real server

After the node is added, the default state is the service enabled state.

If the real server needs maintenance, the public service of the real server can be stopped by disabling the real server to make the overall update and maintenance of the service smoother.

After the real server is disabled, the existing long connection will not be disconnected.

Operation steps

Go to the VServer management page and click Real Server.

1) Disable a single real server

Select the real server that needs to be disabled, and click the disable button.

 

A pop-up window will display the selected real server information, and confirm whether it is the real server to be disabled. Click OK to disable the node.

2) Disable real servers in batches

Select the check boxes on the left of the servers that need to be disabled in batches, and click Disable above.

 

A pop-up window will display the selected real servers information, and confirm whether they are the real servers to be disabled. Click OK to complete batch disable.

3.3.4 Message forwarding mode real server configuration

In message forwarding mode, since user access will be directly transparently transmitted via ULB, it is necessary to ensure that the access address falls on the real back-end real server, so the private/public IP address of the load balancer should be configured in the back-end real server. The configuration method is as follows.

 

CentOS 7 and below

1) Cloud host does not use cloud init

Create a virtual NIC configuration file:

touch /etc/sysconfig/network-scripts/ifcfg-lo:1

Add the following configuration in /etc/sysconfig/network-scripts/ifcfg-lo:1: (If ULB is bound to multiple EIPs, multiple EIPs need to be configured)

DEVICE=lo:1

IPADDR=$VIP

NETMASK=255.255.255.255

Enable the virtual NIC:

ifup lo:1

2) Cloud host uses cloud init

Add the following content to UserData:

#/bin/bash

echo -e “DEVICE=lo:1\nIPADDR=$VIP\nNETMASK=255.255.255.255”> /etc/sysconfig/network-scripts/ifcfg-lo:1

ifup lo:1

 

CentOS 8 and above

1) Cloud host does not use cloud init

Install network-scripts:

yum install network-scripts -y

Create a virtual NIC configuration file:

touch /etc/sysconfig/network-scripts/ifcfg-lo:1

Add the following configuration in /etc/sysconfig/network-scripts/ifcfg-lo:1: (If ULB is bound to multiple EIPs, multiple EIPs need to be configured)

DEVICE=lo:1

IPADDR=$VIP

NETMASK=255.255.255.255

Enable the virtual NIC:

ifup lo:1

2) Cloud host uses cloud init

Add the following content to UserData:

#!/bin/bash
yum install network-scripts -y
echo -e “DEVICE=lo:1\nIPADDR=$VIP\nNETMASK=255.255.255.255” > /etc/sysconfig/network-scripts/ifcfg-lo:1
ifup lo:1

 

Ubuntu16.04

1) Cloud host does not use cloud init

Add the following configuration in /etc/network/interfaces:

auto lo:1

iface lo:1 inet static

address $VIP

netmask 255.255.255.255

Enable the virtual NIC:

sudo /etc/init.d/networking restart

2) Cloud host uses cloud init

Add the following content to UserData:

#!/bin/bash

echo -e “auto lo:1\niface lo:1 inet static\naddress $VIP\nnetmask 255.255.255.255”>>/etc/network/interfaces

sudo /etc/init.d/networking restart

 

Ubuntu18.04/Ubuntu20.04

1) Cloud host does not use cloud init

Create a NIC configuration file in the /etc/netplan/ directory:

sudo touch lo-cloud-init.yaml

Add the following configuration to the file lo-cloud-init.yaml (note the indentation of each line):

network:

ethernets:

lo:

addresses:

-$VIP/32

Enable the virtual NIC:

sudo netplan apply

2) Cloud host uses cloud init

Add the following content to UserData:

#!/bin/bash
sudo touch lo-cloud-init.yaml
sudo echo -e “network:\n ethernets:\n lo:\n addresses:\n – $VIP/32” > /etc/netplan/lo-cloud-init.yaml
sudo netplan apply

3.4 Content forwarding

3.4.1 Add content forwarding rule

Under the HTTP/HTTPS protocol, VServer supports matching domain names or access paths according to forwarding policies, and can forward matching requests to specific back-end hosts, and perform fine-grained management of back-end real servers. By default, there will be a policy called the default rule. This policy takes effect when all requests are not matched successfully, and will be forwarded according to the usual forwarding rules.

The TCP/UDP protocol does not currently support content forwarding strategies.

 

Operation steps

Go to the VServer management page and click Content Forwarding to manage content forwarding rules.

1) Click Add Rule, and the Add Rule pop-up window will pop up.

 

2) Forwarding rules are divided into Domain forwarding and Path forwarding. Both of these forwarding methods can be described by regular expressions that comply with PCRE rules.

Take domain name forwarding as an example:

  • \[123\].demo.comcan match www.1.demo.com, www.2.demo.com, www.3.demo.com
  • .*.demo.com can match demo.com, news.demo.com

Take path forwarding as an example:

  • /path/img/.*.jpg can match /path/img/test.jpg, /path/img/photo.jpg

Note that: Currently regular matching does not support strings containing the escape character “\”. When creating a rule, the content of the rule cannot be empty.

3) Optional real server. Each rule needs to be associated with an existing real server, and the server that needs to be associated is selected.

4) Click OK to complete adding forwarding rules.

 

3.4.2 Delete content forwarding rule

The default rule does not support deletion.

Operation steps

Go to the VServer management page and click Content Forwarding to manage content forwarding rules.

1) Delete a single forwarding rule

Select the rule to be deleted, and click Delete. A pop-up window will display the selected forwarding rule information, and confirm whether it is the rule to be deleted. Click OK to delete the forwarding rule.

 

2) Delete forwarding rules in batches

Select the check boxes on the left of the rules to be deleted in batches, and click Delete rules above. A pop-up window will display the selected forwarding rule information, and confirm whether it is the rule to be deleted. Click OK to delete the forwarding rules in batches.

 

3.4.3 Manage content forwarding rule

Operation steps

Go to the VServer management page and click Content Forwarding to manage content forwarding rules. The default rules cannot be managed.

After adding a rule, you can edit the node associated with the current rule. Select the forwarding rule to be edited, and click Management. The management pop-up window pops up.

 

  • Optional realserver. The rule resource list is not associated with the current real server resource pool.
  • Forwarding realserver. The rule resource list has been associated with the current real server resource pool.

1) Add the real server associated with the rule

 

Select the check box on the left of the resource in the optional real server list to move to the forwarding real server list. Click OK to complete the associated node operation.

2) Cancel the associated real server

Select the check box on the left of the resource in the forwarding real server list to move to the optional real server list. Click OK to finish disassociating the server.

 

3.5 Certificate

3.5.1 Certificate format

Format requirement

The certificate currently supports two uploading methods, the first is to upload the certificate file directly, and the second is to manually fill in the certificate text information.

 

Upload files directly

If you choose to upload the certificate file directly, you need to prepare the following files:

  • Required, the certificate file of the website (cer/crt/pem format).The text format of the file is as follows:

—–BEGIN MY CERTIFICATE—–

—–END MY CERTIFICATE—–

  • Required, private key file.The text format of the file is as follows:

—–BEGIN RSA PRIVATE KEY—–

—–END RSA PRIVATE KEY—–

  • Optional, intermediate certificate, root certificate (certificate chain, cer/crt/pem format).The text format of the file is as follows:

—–BEGIN CERTIFICATE—–

—–END CERTIFICATE—–

—–BEGIN CERTIFICATE—–

—–END CERTIFICATE—–

The certificate you provide needs to remove password protected. When you upload the certificate or manually fill in the certificate, please make sure that the certificate format is correct. If the verification format is wrong, the certificate will be added unsuccessfully.

 

Fill in the certificate manually

If you choose to fill in the certificate manually, the text needs to include the following fields in sequence: private key, website certificate, intermediate certificate, root certificate, etc. The format is as follows (please check the integrity of the certificate when copying):

 

—–BEGIN RSA PRIVATE KEY—–

—–END RSA PRIVATE KEY—–

—–BEGIN MY CERTIFICATE—–

—–END MY CERTIFICATE—–

—–BEGIN MY CERTIFICATE—–

—–END MY CERTIFICATE—–

If your certificate is in another format, it is recommended that you use the openssl tool for format conversion.

DER to PEM:

Certificate conversion: openssl x509 -inform der -in certificate.cer -out certificate.pem

Private key conversion: openssl rsa -inform DER -outform PEM -in privatekey.der -out privatekey.pem

3.5.2 Add certificate

Certificate management stores the certificate in the ULB certificate management system for HTTPS protocol.

The certificate cannot be used across regions. If you need to use it in multiple regions, you need to upload a certificate in multiple regions.

 

Operation steps

Go to the ULB Load Balancer page and click Certificate Management.

1) Click Add Certificate, and the Add Certificate pop-up window will pop up.

 

2) You need to fill in the following information:

Configuration Instruction
Certificate name Required
Certificate content If you choose to Local Upload, select your local authorized certificate, including the .crt file and the .key file. If you choose Manual Input, you need to manually fill in the certificate in the input box.
Certificate format

Authorization certificate (.crt file): the public key file issued by the certificate authority.

Authorization certificate (.key file): the private key file issued by the certificate authority

 

3.5.3 Use certificate

After uploading the certificate, you can use the uploaded certificate when creating a VServer that listens to HTTPS.

Operation steps:

1) Select a ULB instance and click Manage.

2) Click Add VServer to add monitoring rules.

3) Select the monitoring type as Request Proxy (Layer 7), and after the monitoring protocol is HTTPS, select the SSL certificate. At this time, you can select the certificate stored in the certificate management system.

4) After the configuration is complete, you can see the newly added VServer on the left, and you can view the certificate bound to the VServer.

3.5.4 Replace certificate

Enter the VServer management page to update the certificate.

Operation steps

1) Basic information module on the right, click Edit settings.

2) Select the certificate to be replaced in the drop-down box, and click OK to replace it successfully.

3.5.5 Delete certificate

Operation steps

Go to the ULB Load Balancer page and click Certificate Management. The certificate that has been bound to the resource cannot be deleted.

1) Delete a single certificate

Select the certificate to be deleted, and click Delete. A pop-up window will display the selected certificate information and confirm whether it is the certificate to be deleted. Click OK to delete the certificate.

2) Delete certificates in batches

Select the check boxes on the left of the certificates that need to be deleted in batches, and click Delete Certificates above. A pop-up window will display the selected certificate information and confirm whether it is the certificate to be deleted. Click OK to complete the batch deletion of certificates.

 

3.6 Firewall

3.6.1 Bind firewall

ULB can be bound to a firewall to achieve access control to the source address.

 

Restrictions

Support instance type: public request proxy ULB

Restriction: only supports the restriction of Layer 7 traffic

Limited by the implementation of ULB firewall, it is recommended to use curl to verify whether the ULB firewall takes effect.

 

Operation steps

1) Enter the ULB page, select the ULB instance that needs to be bound to the firewall, and click Details.

2) Click Firewall to enter the firewall page.

3) Click Binding Now, and select the firewall to be selected.

4) Click OK to complete the binding.

Please note: Firewall rules are only effective for ULB instances in request proxy mode and public mode. Please make sure that the corresponding port of the VServer is allowed in the firewall rules. At the same time, ICMP-related rules are not effective.

5) After the binding is completed, the related information of the firewall will be displayed.

3.6.2 Edit firewall

Operation steps

1) Enter the ULB page, select the ULB instance that needs to be bound to the firewall, and click Details.

2) Click Firewall to enter the firewall page.

3) Click Edit firewall and select the firewall that needs to be re-bound.

4) Click OK to complete the firewall replacement.

3.6.3 Unbind firewall

Operation steps

1) Enter the ULB page, select the ULB instance that needs to be bound to the firewall, and click Details.

2) Click Firewall to enter the firewall page.

3) Click Unbind firewall.

4) Click OK to complete.

 

3.7 Log manager

3.7.1 Open log manager

ULB access logs can help you understand the client’s behavior and geographic distribution, and provide access path information to help troubleshoot problems.

1) Only request proxy type ULB supports the log manager function.

2) The log manager itself does not charge a fee, but the log needs to be stored in US3, and the corresponding fee needs to be paid.

3) There will be a 10% performance loss after opening the ULB log.

 

Operation steps

1) Click the ULB name or details on the ULB list page to enter the instance details page.

2) On the ULB overview page, click the edit icon behind the log manager in the basic information module to open the access log.

 

3) Select the US3 storage space and token for storing logs, and click OK.

ULB logs need to be stored in the US3 storage space of the local domain, so you need to enable the US3 permission first and create a storage space in the region where the ULB instance is located.

ULB log generates a log file in 5 minutes and stores it in the selected storage space.

 

Log analysis

1) HTTP/HTTPS protocol log

Private ULB

192.168.5.198–[24/Feb/2021:17:33:21 +0800] 200 5068 18070 192.168.5.208:8080 “” “curl/7.29.0”–192.168.5.30:80 2 ms 3 ms “GET /HTTP/1.1”

 

Client ip – [local time] The byte size of the status code that the server returns to the client. The ip of the client port ulb: the port of the ulb “http_referer” “http_user_agent” ssl_version (if there is no “-” character) ssl_ciphers (if there is no “-” character) rs service ip: rs service port response time request time “request”

Public ULB

117.50.92.198–[24/Feb/2021:18:19:19 +0800] 200 5068 35504 117.50.92.208:443 “” “curl/7.29.0” TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 rs_192 .168.5.30:80_670054 2 ms 3 ms “GET / HTTP/1.1”

 

Client ip – [local time] The byte size of the status code that the server returns to the client. The ip of the client port ulb: the port of the ulb “http_referer” “http_user_agent” ssl_version (if there is no “-” character) ssl_ciphers (if there is no “-” character) rs name (rs_rs service ip: rs service port_number) response time request time “request”

2) TCP protocol log

Private ULB

192.168.5.198–[25/Feb/2021:11:52:38 +0800] 5073 45508 192.168.5.238:80 192.168.5.30:80

 

Client ip – [local time] The size of bytes returned by the server to the client Client port ulb ip: ulb port rs service ip: rs service port

Public ULB

117.50.92.198–[25/Feb/2021:11:52:38 +0800] 5073 45508 FE_106.75.33.238:80 rs_192.168.5.30:80_665936

 

Client ip – [local time] The size of bytes returned by the server to the client Client port Service name (FE_service ip: service port) rs name (rs_rs service ip: rs service port_number)

3.7.2 Close log manager

Operation steps

1) Click the ULB name or details on the ULB list page to enter the instance details page.

2) In the ULB overview page, click the edit icon behind the log manager in the basic information module, and choose to close the access log.

3) Click OK and the log manager function will be closed.

After the log manager function is turned off, the generated log files will not be affected. If necessary, you can manually delete the storage space on the US3 product page.

 

3.8 Monitoring information

Go to the ULB Load Balancer page, select the ULB instance you want to view, and enter the details.

ULB monitoring

Enter the overview page, the public ULB will display the detailed information and monitoring information of the EIP bound to the ULB.

 

VServer monitoring

Enter the VServer management page, select the VServer, and the overview page on the right displays monitoring information.

The monitoring indicators supported by different types of VServers are as follows:

Monitoring indicatiors\VServer protocol HTTPS HTTP TCP (request proxy) TCP (message forwarding) UDP Instruction
The number of new connections (number/s) The number of new connections per second of VServer
The number of VServer connections (number/s) The number of existing connections of VServer
NIC ingress packets (number/s) x x x VServer ingress packets per second
Network ingress traffic (bps) x x x VServer ingress traffic per second
HTTP 2XX (number/s) x x x The number of 2XX status codes returned by the VServer per second
HTTP 3XX (number/s) x x x The number of 3XX status codes returned by the VServer per second
HTTP 4XX (number/s) x x x The number of 4XX status codes returned by the VServer per second
HTTP 5XX (number/s) x x x The number of 5XX status codes returned by the VServer per second
HTTP other codes (number/s) x x x The number of other status codes returned by the VServer per second

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

FAQ

4.1 Question about principles

4.1.1 How does ULB’s session persistence work?

1) Request proxy

In request proxy mode (HTTP, HTTPS), the session persistence function is implemented using cookies. ULB will write a cookie to the source and directly send the request to the corresponding back-end host based on the cookie information contained in the request.

  • Auto generate KEY: If you choose to automatically generate a key, the client’s cookie insertion operations are all allocated and managed by ULB.
  • User-defined KEY: ULB uses the client’s key to allocate and manage cookie insertion operations to the client

The request proxy mode of the TCP protocol does not support session retention.

 

2) Message forwarding

In the message forwarding mode (TCP, UDP), the session retention function is based on the IP address of the session persistence. ULB will forward access requests from the same IP address to the same back-end cloud server for processing.

 

4.1.2 What is the operating status of VServer?

Running refers to the state of the entire load balancing. As long as one back-end server is alive, the load balancing is still running.

The status of the back-end server is indicated by green/red indicator lights.

It should be noted that the back-end status is determined by the load balancing health check. If the health check fails, even if the server can still be pinged, it is considered down.

 

4.1.3 What is the principle of connection idle timeout?

For the request sent by the client to ULB, ULB will maintain two connections. One connection points to the client, and the other connection points to the back-end real server (RS, realserver).

After the connection idle timeout period expires, if no data is sent or received, the ULB will close the connection.

In ULB, connection retention is turned on by default, and the default connection retention time is 60 seconds. For example, the connection will be maintained for 60 seconds after the first packet is sent. If there is no new TCP packet within 60 seconds since the last packet was sent, the connection will be disconnected. Users can set the connection idle timeout threshold according to their business needs.

The current protocols with connection idle timeout include HTTP, HTTPS and TCP request proxy modes.

 

4.1.4 How does the ULB health check mechanism work?

ULB health check can determine whether the back-end server is normal. For abnormal back-end servers, ULB will remove them from the back-end server pool, and client requests will be distributed among other servers. When a server in an abnormal state returns to normal, it will be restored to the back-end server pool by ULB.

Health check methods supported by different types of VServers

ULB type Protocol Support health check method
Request proxy HTTP, HTTPS HTTP check, port check
Request proxy TCP port check
Message forwarding TCP port check
Message forwarding UDP Ping check, port check, UDP check

Applicable scenarios for different health checks

In general, the health check methods can be divided into two categories: check port survival and check service survival.

Check port survival: port check, Ping detection.

Check service survival: HTTP check, UDP check.

Details of different health check methods

1) Port check

ULB deploys a dedicated server pair in each availability zone to detect whether the IP+port of the back-end node is normal. The detection frequency is 2s. If the detection fails for three consecutive times, the back-end server status is abnormal. If the detection is normal for three consecutive times, the back-end server status is normal. Note that: Data update has a 6s delay, so the health check status may have a 6s delay.

All protocols support port checking. But the detection status is slightly different: HTTP, HTTPS, and TCP request proxy mode port checks are detected by TCP. The TCP packet forwarding mode and UDP protocol use the selected four-layer protocol for port detection.

2) HTTP check

Check whether the application on the backend server is available through HTTP HEAD request. The backend server is required to support HEAD requests.

To use HTTP health check, the user needs to configure the HTTP check path (if necessary, you can also configure the HTTP check domain name, generally do not need to fill in), the two are spliced to form the HTTP check URL, and ULB will initiate an HTTP HEAD request for this URL If the request response code is 2xx or 3xx, it is considered that the back-end server is normal. The health check detection cycle is 2s. The back-end node changes to unhealthy after 3 consecutive failed detections, and changes to healthy normally twice in a row.

HTTP check path, up to 227 characters, directly fill in the relative path file after the domain name or IP address. You can choose the home page, the page with a low probability of abnormality, and the empty file specially prepared for the health check (HTTP HEAD request can get a response code of 200). Choosing the home page may increase the server pressure. It is not recommended to choose the home page as HTTP health Check the domain name and path.

HTTP check domain name, it is not recommended to fill in “http:” or “https:”, just fill in the domain name or IP address directly. Support multi-level domain names such as primary domain name and secondary domain name.

Protocols supported by HTTP check: HTTP protocol, HTTPS protocol (seven-layer service).

3) UDP check

According to the health check configuration, the ULB health check service sends a UDP request message to the real server every 2s. If the predetermined UDP response message is received within 2s after the request is sent, the real server is deemed to have responded successfully.

Health check succeeded: The response was successful three times in a row.

Health check failed: Three consecutive failed responses.

If the current status of a real server is “healthy”, the node status will be changed to “failed” only if the real server fails to respond three times in a row.

Note that: During UDP check, in order to prevent the real server from responding to the request message incorrectly, the real server cannot be bound to 0.0.0.0/0.

 

4.2 Question about usage

4.2.1 How does ULB obtain the source address of the client?

ULB supports two types of message forwarding and request proxy. The message forwarding type supports TCP, UDP and other protocols, and the request proxy type supports HTTP, HTTPS, TCP and other protocols.

In the message forwarding mode, the source address of the request received by the back-end real server is the actual source address.

In request proxy mode, in the HTTP protocol, ULB has enabled the x-Forwarded-For, X-Forwarded-Proto and X-Forward-SrcPort options by default. The source address, client and load balance of the client can be obtained from the HTTP header. Between the application layer protocol and the client port. The TCP protocol cannot return the source address.

Get the client source address:

# Nginx example

log_format  upstream  ‘$time_iso8601 $http_x_forwarded_for $host $upstream_response_time $request $status $upstream_addr’;

 

# Apache example

SetEnvIf REMOTE_ADDR “(.+)” CLIENTIP=$1

SetEnvIf X-Forwarded-For “^([0-9.]+)” CLIENTIP=$1

LogFormat “%{CLIENTIP}e %D %u %t \”%r\” %>s %O \”%{Referer}i\” \”%{User-Agent}i\”” trueip_combined

CustomLog logs/access_log trueip_combined

 

# Modify the following parameters in tomcat’s server.xml file:

<Host name=”localhost” appBase=”webapps”

unpackWARs=”true” autoDeploy=”true”>

<Valve className=”org.apache.catalina.valves.AccessLogValve”

directory=”logs”

prefix=”tomcat_access.”

suffix=”.log”     pattern=”%{X-FORWARDED-FOR}i %l %u %t %r %s %b %D %q %{User-Agent}i %T” resolveHosts=”false”/>

</Host>

 

4.2.2 Is it normal for the real server to receive a large number of private IP access?

It is normal to receive a large number of private IP visits. In the request proxy mode, ULB uses ULB’s private proxy IP when forwarding requests to the back-end real server.

 

4.2.3 How to prohibit certain source addresses from accessing the back-end service node?

ULB supports the firewall function, which can be used as follows:

  • Binding the firewall when creating the load balancer, or in the details page of ULB, enter the PublicFirewall tab page to bind the firewall.

Note that:

  • The firewall only takes effect for ULB instances in request proxy and publicnetwork mode.
  • In the process of configuring the firewall, if you need to perform whitelist/blacklist restrictions on a VServer in request proxy mode, you need to configure the allow/deny policy of the corresponding port of the VServer in the firewall. Since the default behavior of the firewall is to deny, when configuring the firewall, be sure to add the corresponding source address release rules of the corresponding port of the VServer to avoid affecting the business.

 

4.2.4 Can the round robin algorithm balance the number of requests from all service nodes?

The round robin algorithm of load balancing is for connection. The same TCP connection will not be loaded to two back-end servers at the same time. If an uncertain number of multiple requests are sent on the same connection, the number of requests counted on the back-end server may be different.

 

4.2.5 Will the ULB server go down?

ULB adopts a cluster architecture, based on distributed deployment across availability zones, and uses BGP+ECMP to realize automatic disaster recovery of the cluster to ensure that it can still work normally under disasters at the availability zone level.

 

4.2.6 What are the ULB error codes?

The ULB error code basically follows the HTTP specification.

Client error, return 4XX

  • 400 Bad request: Your browser sent an invalid request.
  • 403 Forbidden: Request forbidden by administrative rules.
  • 408 Request Time-out: Your browser didn’t send a complete request in time.

Server error, return 5XX

  • 500 Server Error: An internal server error occured.
  • 502 Bad Gateway: The server returned an invalid or incomplete response.
  • 503 Service Unavailable: No server is available to handle this request.
  • 504 Gateway Time-out: The server didn’t respond in time.

 

4.2.7 Must the VServer port and the service node port be the same?

It is not necessary to keep the same. If the ULB message forwarding listening port is inconsistent with the back-end server listening port, you can configure the IpTables port forwarding rule in the service node to achieve the specific steps as follows:

1) Modify the /etc/sysctl.conf configuration file and set net.ipv4.ip_forward = 1 The default is 0.

2) Turn off the firewall service iptables stop.

3) Configuration rules:

iptables -t nat -A PREROUTING –d $vip_ip -p tcp –dport $ulb4_port  -j DNAT –to-destination $vip_ip:$vm_port

Among them: $vip_ip refers to the private IP address of the load balancer, $ulb4_port refers to the listening port of ulb4, and $vm_port is the listening port of the back-end server. Example: the private IP address of the load balancer is: 10.10.10.10, ulb_4 The listening port is 80, and the back-end server listening port is 8101, then the rule is:

iptables -t nat -A PREROUTING -d 10.10.10.10 -p tcp –dport 80 -j DNAT –to-destination 10.10.10.10:8101

4) Save configuration: service iptables save

5) Start iptables: service iptables start

 

4.3 Question about test

4.3.1 Why can’t I ping the IP address of the private ULB?

The private ULB only guarantees that it can be pinged through the same subnet. The port test can be used to confirm whether the private ULB is configured and working properly.

 

4.3.2 Why does the connection fail during the ULB pressure test?

Normally, when the Linux operating system is used as the stress test simulation client, the connection failure will not occur before the stress test performance reaches the ULB limit.

However, when using Windows as a simulated client for stress testing, TCP connection failure may occur. This is because in the stress test scenario, the Windows system will quickly reuse the client IP and port to initiate TCP connection establishment, and in the TCP protocol stack on the back-end Linux service node of the ULB under stress test, the same source address and The TCP connection established by the port may not have been released yet. If the “serial number of the new connection” is greater than the “serial number of the existing connection” at this time, the Linux service node will consider the SYN request for the new connection to be a renewal of the existing connection. This will cause the establishment of a new TCP connection to fail.

Therefore, when performing stress testing on ULB, please try to use Linux as the stress testing simulation client. If you must use the Windows system as the stress testing simulation client, you need to add the option for TCP timestamp in the system registry. This option is by default in It is not activated in Windows.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

glossary

ULB

ULB service instance achieve the functions of traffic balance and service fault tolerance by creating a listener (VServer) and adding a back-end service node (RealServer).

VServer

ULB listener, each VServer is a set of load balancing front-end port configuration, including protocol, port, load algorithm, session retention, client timeout, etc.

RealServer/RS

The real server is a back-end service instance composed of the cloud host’s private IP and the cloud host port.

Service IP address

For public ULB, the IP address that provides services is public Elastic IP (EIP).

For private ULB, the IP address that provides services is private IP.

 

 

 

 

 

 

 

 

 

 

 

API tools

UAPI provides users with a zero-code method to send requests to the API provided by SCloud, which can effectively improve the efficiency of debugging APIs.

You can select the corresponding cloud product in the API list and browse the APIs that the product has opened. Click the API name to enter the details page. The details page provides the following functions:

  • View the parameter description and fill in the request parameters
  • Execute the sending request and analyze the response result
  • Check the response description and copy the reference example

Take DescribeEIP as an example:

Select UNet in APL list and search for EIP. Click DescribeEIP.

 

Choose the Region and the ProjectID that you want to request.

 

Click confirm to send request and get the result on the right page.

 

 

No need to set up the environment, no need to write code, no need to process the signature to send the request (the request login state is the currently logged-in account).

Provide customized functions, such as providing public parameter selection without the need to consult documents twice, processing of multi-value parameters, etc.

Sending a request will directly operate on the resources in the account, and a pop-up prompt will appear for non-query API sending requests. Please confirm that the parameters are accurate before sending the request.