Concepts

• Frontend network: A frontend network is a type of network that is associated with a load balancer. Requests from the network are distributed by the load balancer to backend servers based on a specified policy.
  • Shared-performance load balancer: You can specify a public network or VPC network as a frontend network.
  • Dedicated-performance load balancer: You can specify a public network, flat network, or VPC network as a frontend network.
• Backend network:A backend network is a type of network that is associated with a load balancer. Requests from frontend networks are distributed by the load balancer to servers in the backend network.
  • Shared-Performance Load Balancer:
    • If you specify a public network as the frontend network, you can specify any one of the VPC networks of the VPC vRouter to which the public network is attached as the backend network.
    • If you specify a VPC network as the frontend network, you can specify any one of the VPC networks of the VPC vRouter to which the VPC network is attached as the backend network.
  • Dedicated-Performance Load Balancer:
    • If you specify a public network as the frontend network, you can specify a flat network or any one of the VPC networks of the VPC vRouter to which the public network is attached as the backend network.
    • If you specify a flat network as the frontend network, you must specify the same network as the backend network.
    • If you specify a VPC network of a VPC vRouter as the frontend network, you must specify the same network as the backend network. If you need to associate the load balancer with more backend networks, you can attach more NICs to the load balancer instance. Note that the backend networks that you associate are among the other VPC networks of the VPC vRouter.
• Load balancer instance: A load balancer instance is a custom VM instance used to provide load balancing services.
  • The network where the default NIC of a load balancer instance resides is the frontend network of the load balancer instance. The default NIC cannot be detached from a load balancer instance.
  • The networks of the NICs of a load balancer instance, except the default NIC, are the backend networks of the load balancer.
  • The management NIC (if any) cannot be detached.
• LB image: A dedicated-performance load balancer (LB) image encapsulates dedicated-performance load-balancing services and can be used to create load balancer instances. However, a dedicated-performance load balancer image cannot be used to create VM instances.
  Note: ZStack Cube Ultimate provides two versions of LB image: VyOS 1.1.7 and openEuler 22.03. The following lists the differences on the features supported by the two version.

  Feature	VyOS 1.1.7	openEuler 22.03
  ACL	Support	Support
  Attching VF NIC to LB instance (SR-IOV)	Not Support	Support

• Load balancer instance: A load balancer (LB) instance offering defines the CPU, memory, image, and management network configuration settings used to create LB instances. LB instances provide load balancing services for the public network, flat network, and VPC network.
• Listener: A listener monitors the frontend requests of a load balancer and distributes the requests to a backend server based on the specified policy. In addition, the listener performs health checks on backend servers.
  • Listeners support the TCP, HTTP, HTTPS, and UDP protocols.
  • A load balancer can be associated with multiple listeners while a listener can be associated with only one load balancer.
  • If the listener uses the weighted round-robin load-balancing algorithm, you can set the weight value for each individual backend server on the backend server group details page.
• Forwarding rule: A forwarding rule forwards the requests from different domain names or URLs to different backend server groups.
  • A forwarding rule is composed of a domain name and URL.
  • A listener can have up to 40 forwarding rules.
  • You can configure a domain-based or URL-based forwarding rule for a load balancer. You can add multiple forwarding rules to a listener and associate these rules with different backend server groups.
  • A forwarding rule is matched by using the exact match and fuzzy match mechanisms. If multiple forwarding rules are matched, the forwarding rule matched through the exact match mechanism is used.
• Certificate: If you select HTTPS for a listener, associate it with a certificate to make the listener take effect. You can upload either a certificate or certificate chain.
• Backend server group: A backend server group is a group of backend servers that handles requests distributed by load balancers. It is the basic unit for traffic distribution by load balancer instances.
  • A load balancer can be associated with multiple backend server groups, while a backend server group can be associated with only one load balancer.
  • A backend server group can be associated with multiple listeners in the same load balancer.
  • Creating a load balancer will automatically create an empty backend server group.
• Backend server: A backend server handles requests distributed by a load balancer. You can add a VM instance on the Cloud or a server on a third-party cloud as a backend server.

Background

When receiving incoming client requests, a load balancer selects a backend server and establishes a new TCP connection to the selected backend server. Then, the load balancer forwards the requests to the backend server. When receiving responses from the backend server, the load balancer forwards the responses to the client. Therefore, the backend server can only obtain the forwarded IP address instead of the actual client IP address from a TCP session.

When Layer 7 listeners (HTTP/HTTPS protocols) are used, you can use the X-Forwarded-For header to obtain the actual client IP address. The X-Forwarded-For header is an HTTP request header used to record the actual client IP address. You can add the X-Forwarded-For header only when connecting clients through an HTTP proxy server or a load balancer. Common proxy servers (such as IIS 6, IIS 7, Apache, Tomcat, and Nginx) can use the X-Forwarded-For header to obtain the actual client IP address.

Note: You can achieve the same feature by using the Proxy protocol, which only requires a header to be added to the TCP session to forward requests from clients. However, you need to make sure that the corresponding backend servers support the Proxy protocol. Currently, considering the potential impact on performance, the Cloud does not support transparent Proxy for the time being.

The following sections describe how to configure the X-Forwarded-For header on Apache and Nginx servers in a CentOS 7 system.

Configure Apache Servers

1. Install the Apache.

   # Run the following installation command in a CentOS 7 system
   [root@localhost ~]# yum -y install httpd
   
   # Enable the HTTP service and set the HTTP service to start on boot
   [root@localhost ~]# systemctl start httpd
   [root@localhost ~]# systemctl enable httpd
   
   # Disable the VM firewall
   [root@localhost ~]# iptables -F

2. Modify configurations.

   # Modify the httpd.conf configuration file
   [root@localhost ~]# vi /etc/httpd/conf/httpd.conf
   
   # Add the following fields
    LoadModule remoteip_module modules/mod_remoteip.so  //Load the mod_remoteip.so module
    RemoteIPHeader X-Forwarded-For  //Set the RemoteIPHeader header
    RemoteIPInternalProxy <ip_range1> <ip_range2> ... <ip_rangeX>  //<ip_range1> <ip_range2> ... <ip_rangeX> are the back-to-origin CIDR blocks of backend servers. Seperate multiple CIDR blocks with spaces
   
   # Change the log format
    LogFormat "%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
   
   # Restart Apache for the configurations to take effect
   [root@localhost ~]# systemctl restart httpd

   
   
   

   
   
   

3. View the results.

   # View the access_log file to obtain the source client IP address
   [root@localhost ~]# tail -f /var/log/httpd/access_log

   
   
   

Configure Nginx Servers

1. Install the Nginx.

   # Download the installation package and unzip the package
   [root@localhost ~]# wget http://nginx.org/download/nginx-1.0.12.tar.gz
   [root@localhost ~]# tar zxvf nginx-1.0.12.tar.gz
   [root@localhost ~]# cd nginx-1.0.12
   
   # Install dependencies
   [root@localhost ~]# yum -y install pcre pcre-devel
   [root@localhost ~]# yum -y install zlib zlib-devel
   [root@localhost ~]# yum -y install openssl openssl-devel
   
   # Install and start
   # Use http_realip_module module to read X-Forwarded-For records
   [root@localhost ~]# ./configure --prefix=/usr/local/nginx --with-http_stub_status_module --without-http-cache --with-http_ssl_module --with-http_realip_module
   [root@localhost ~]# make
   [root@localhost ~]# make install
   
   # Check the service status
   [root@localhost ~]# ps -ef | grep nginx
   
   # Test whether the service is successfully enabled
   [root@localhost ~]# curl http://IP address:80
   
   # Disable the VM firewall
   [root@localhost ~]# iptables -F

2. Modify configurations.

   # Modify the nginx.conf configuration file
   [root@localhost ~]# vi /usr.local/nginx/conf/nginx.conf
   
   # Add the following fields
    set_real_ip_from <ip_range1>;
    set_real_ip_from <ip_range2>; 
    ...
    set_real_ip_from <ip_rangex>;  //<ip_range1>, <ip_range2>, and <ip_rangeX> are the back-to-origin CIDR blocks of backend servers. Seperate multiple IP ranges with spaces
    real_ip_header X-Forwarded-For;
   
   # Restart the Nginx service for the configurations to take effect
   [root@localhost ~]# ps -ef|grep nginx
   [root@localhost ~]# kill -9 nginx.pid
   [root@localhost ~]# cd /root/nginx/sbin
   [root@localhost ~]# ./nginx -c /usr/local/nginx/conf/nginx.conf

   
   
   

3. View the results.

   # View the access_log file to obtain the source client IP address
   [root@localhost ~]# tail -f /usr/local/nginx/logs/access.log

   
   
   

Create a Shared-Performance LB

Create a Dedicated-Performance LB

After you create a LB, you can add a listener and associate VM NICs with the listener to make the LB take effect.

Basic Monitoring

Access Log

Records the access information of the load balancer in the log file, including the client IP, backend server, access time, request method, and request path. The access log helps you with issue identification and troubleshooting.

Advanced Monitoring

The advanced monitoring mode displays the load balancer's monitoring data in a detailed and visualized way. Compared with the basic monitoring and access log, the advanced monitoring provides more comprehensive metrics and enables a more intuitive and flexible presentation.

The Advanced Monitoring page is divided into two parts: Monitoring Data and Connection Statistics.

Connection Statistics: Displays detailed access information of the load balancer in a list, including the listener handling the access, client IP, frontend IP, backend server IP, status code, inbound traffic volume, outbound traffic volume, active connections, and concurrent connections.

Note:

• Currently, the advanced monitoring mode applies to HTTP and TCP listeners.
• Before you can view the connection statistics of an HTTP/TCP listener, make sure the listener has at least one backend server associated.
• Access Data generated within the same second and with identical listener, client IP, frontend IP, backend server IP, status code, inbound/outbound traffic, and active/concurrent connections are aggregated as one entry for display.
• The UI displays a maximum of 1000 connection records at once. You can adjust the time span or the filter criteria (listener, client IP, frontend IP, and backend server IP) to view the records you need.

Forwarding Rule Matching Algorithm

Forwarding rules are matched based on the following algorithm:

• • If the domain name is specified, the system attempts to match URLs:
    • If a URL is matched, the request is forwarded to the associated backend server group. If multiple URLs are matched based on the exact match mechanism, the request is forwarded to the backend server group associated with the URL that is matched most accurately.
    • If the specified URLs of the domain name are not matched, the request is forwarded to the backend server group associated with the root URL.
    • If the root URL is not configured, errors are returned.
  • If the domain name is not specified in the frontend request or no domain name is matched, the system attempts to match forwarding rules that have their domain names unspecified:
    • If a forwarding rule is matched, the request is forwarded to the associated backend server group.
    • If no forwarding rule is matched, the request is forwarded to the backend server group that is not associated with any rule.
    • If all backend server groups associated with the listener have associated forwarding rules, errors are returned.

Note: If you have enabled HTTP Redirect for a listener, note that all forwarding rules you configure for it are invalid because all flows accessing it are forwarded to and processed by the destination HTTPS listener in fact. If you need, configure forwarding rules for the destination HTTPS listener instead of the original HTTP listener.

Create Backend Server Group by Instance NIC

Create Backend Server Group by IP Address

Considerations

• A backend server group is a group of backend servers that share the same configurations. You can associate one or more listeners with a backend server group. The listeners distribute traffic based on the weight that you assign to each backend server.
• A load balancer can be associated with multiple backend server groups, while a backend server group can be associated with only one load balancer.
• An empty backend server group is automatically created when you create a load balancer.

Considerations

If an LB listener uses the HTTPS protocol, you must associate certificates with the listener. You can upload individual certificates or a certificate chain.