Configuring a Real Server Group

A real server group comprises real servers that process traffic.

Prerequisites

The IP addresses and port numbers of real servers are known.
The protocol services or types provided by real servers are known.
The performance and status of every real server are known.

Context

A real server group consists of one or more real servers, and one real server can join multiple real server groups. A real server group provides only one type of service; therefore, a real server supporting multiple types of services can be added to multiple real server groups. The FW uses the load balancing algorithm to determine how to distribute traffic to real servers. The selection of a load balancing algorithm relies on service types. The service health check function can be used to check real servers and exclude faulty servers from traffic distribution.

Procedure

In the user view, access the system view.
```
system-view
```
Access the SLB configuration view.
```
slb
```
Create a real server group or access the real server group view.
```
group [ group-id ] group-name
```
When creating a real server group, you can set only the real server name (group-name) or configure the real server group ID (group-id) and name. If you do not set a real server group ID, the system assigns an ID to the real server group.
Select a load balancing algorithm.
```
metric { roundrobin | weight-roundrobin | least-connection | weight-least-connection | source-ip-hash | weight-source-ip-hash}
```
The default algorithm is round robin (roundrobin). One real server group can use only one load balancing algorithm.

If real servers have different performance, use a weighted load balancing algorithm (weight-roundrobin or weight-least-connection) and set weights for each real server.

The weighted algorithm must be configured before the weights for real servers.
Optional: Set service health check parameters.
- The health-check type { dns | radius | tcp } [ tx-interval interval-value | times times-value | port port-number ] ^* command configures the DNS, RADIUS, or TCP health check.
- The health-check type http [ req-url req-url-value | ept-code ept-code-value | tx-interval interval-value | times times-value | port port-number ] ^* command configures the HTTP health check.
- The health-check type https [ req-url req-url-value | ept-code ept-code-value | tx-interval interval-value | times times-value | port port-number ] ^* command configures the HTTPS health check.
- The health-check type icmp [ tx-interval interval-value | times times-value ] ^* command configures the ICMP health check.
The health check method must match the virtual server protocol. Detailed requirements are as follows:
- When the virtual server protocol is ANY, the health check method can be set to dns, https, http, icmp, radius, or tcp.
- If the virtual server protocol is SSL, the health check method can be dns, https, icmp, or tcp.
- If the virtual server protocol is HTTP, the health check method can be http or icmp.
- If the virtual server protocol is HTTPS, the health check method can be http, https or icmp.
- If the virtual server protocol is TCP, the health check method can be dns, https, http, icmp, or tcp.
- If the virtual server protocol is UDP, the health check method can be dns, icmp, or radius.
- If the virtual server protocol is ESP, the health check method can be tcp, https, http, dns, icmp, or radius.
The FW constructs probe packets as follows:
- Source IP address: IP address of the outbound interface.
- Destination IP address: IP address of the real server.
- Destination port: If port-number is set, its value is used. If the destination port is not set but the real server port is set, the real server port is used. If neither the destination port nor the real server port is set, the virtual server port is used.
- HTTP or HTTPS probe packet: Get request sent to a specific URL of the real server. The URL is specified in req-url-value. If req-url-value is not set, the home page is requested. The requested Host is the address of the real server.
During an HTTP probe, the FW checks the status code in the response packet sent from the real server. If the status code does not match the FW configuration, the FW considers a probe failure. The default status code is 200.

If the number of times that probe results consecutively indicate a real server fault reaches the value of times-value, the FW sets the status of the real server to unavailable (Inactive), stops distributing traffic to it, and keeps sending probe packets to it.

The protocols of probe packets must be consistent with the services enabled on the real server. Otherwise, probes always fail. For example, if the FW sends DNS packets to probe a DNS-disabled server, the server does not respond.

The source IP address of the probe packets does not require manual configuration, because the FW automatically uses the IP address of the outbound interface for packet detection as that of the detection source.
Optional: Run the source-nat { address-group address-group-name | interface-address } command to enable source NAT.
After source NAT is enabled, the FW translates the source addresses of packets sent to a real server into addresses in the address pool or the IP address of the interface connecting to the real server. This implementation simplifies the route configuration for packets sent from the real server to clients. Only the route to an address in the source NAT address pool or the FW interface is required.

If the real server needs to perform authentication based on the IP addresses of packets sent from clients, source NAT should not be enabled on the FW. If the real server is a web server and can extract the client IP address from the X-Forward-For field, this restriction can be ignored. You can run the http x-forward enable command to enable the HTTP X-Forward function on the FW. The FW inserts the X-Forwarded-For field to each HTTP packet sent from a client. This field carries the real IP address of the client to the server.

The application mode of the NAT address pool referenced in the command must be PAT.
Run the action { override | optimize | discard} command to configure the action when the number of server connections in a real server group exceeds the limit on the maximum number of connections.

Add a real server to a real server group.

rserver  [ start-rserver-id [ to end-rserver-id ] ] rip rip-address [ max-connections max-connections-value | port port-number | status { inactive | health-check } | weight weight-value | description description-text ] ^*

By default, the weight of a real server (weight-value) is 1, and the status is health-check.

The weight sum of servers in a real server group must be equal to or less than 8192.

If you do not set an ID for a real server when adding it to a real server group, the FW assigns an ID to it. When modifying the IP address of a real server, you must specify the ID.

When the number of concurrent connections on a real server reaches max-connections-value, the FW no longer allocates new connections to the server. At the same time, the FW sends the log FW_SLB/5/SLB_SERV_OVERLOADED to inform the administrator of the server overload. After the number of concurrent connections on the real server falls below 80% of max-connections-value, the FW sends the log FW_SLB/5/SLB_SERV_NORMALRUN to inform the administrator of the server restoration.

If a real server supports multiple types of services, set different port numbers for it when you add it to different real server groups.

If you configure a real server to work in inactive state (inactive), the FW does not check its health status and the server does not participate in traffic distribution. You can configure a real server to work in inactive state when it needs to perform an operation, such as system software upgrade. After the operation is complete, restore the server to health-check state.

Table 1 describes how to use the rserver rip command.

**Table 1** Method of using the **rserver rip** command
Command	Function
rserver rip rip-address	Adds a real server to a real server group. The IP address of the real server is rip-address.
rserver start-rserver-id rip rip-address	Changes the IP address of the real server with the ID of start-rserver-id to rip-address.
rserver rip rip-address port port-number weight weight-value max-connections max-connections-value status health-check	Adds a real server to a real server group and sets the weight of the server to weight-value, maximum number of connections to max-connections-value, and status to health-check. The IP address of the server is rip-address and the port number is port-number.
rserver start-rserver-id to end-rserver-id rip rip-address	Adds multiple real servers to a real server group. The IP address of the first real server is rip-address and the ID is start-rserver-id. The IP address and ID of other servers increase in sequence based on those of the first server. For example, if the IP addresses of 10 real servers are 192.168.0.1 to 192.168.0.10, run the rserver 1 to 10 rip 192.168.0.1 command to add these servers in batch. The IP address of the real server with the ID of 1 is 192.168.0.1, the IP address of the real server with the ID of 2 is 192.168.0.2, and so on.
rserver start-rserver-id to end-rserver-id rip rip-address port port-number weight weight-value max-connections max-connections-value status health-check	Adds multiple real servers to a real server group. The IP address of the first real server is rip-address and the ID is start-rserver-id. The IP address and ID of other servers increase in sequence based on those of the first server. The port number of all the servers is port-number; the weight is weight-value; the maximum number of connections is max-connections-value; and the status is health-check.

If you need to modify the maximum number of connections, port number, weight, or status parameters of a real server, not the IP address of the real server, you can run the rserver rserver-id { max-connections max-connections-value | port port-number | status { inactive | health-check } | weight weight-value | description description-text } ^* command.

Return to the user view.
```
return
```

Example

Five real servers provide HTTP services. Their IP addresses are 192.168.0.1 to 192.168.0.5, and port numbers are all 80. The performance of the server with the IP address of 192.168.0.1 is approximately twice that of the other four servers. To ensure reliable services, configure policies for a busy real server and enable health check..

# Create a real server group named grp1 and configure the load balancing algorithm. The weighted least connections algorithm is used because the load and connection lifetimes of the HTTP services, as well as the server performance, are different.

<sysname> system-view
[sysname] slb
[sysname-slb] group 1 grp1
[sysname-group-1] metric weight-least-connection

# Add five real servers to the real server group. Set the weight to 2 and maximum number of connections to 1000 for the real server at 192.168.0.1. Set the weight to 1 and maximum number of connections to 500 for the real servers at 192.168.0.2 to 192.168.0.5.

[sysname-group-1] rserver 1 rip 192.168.0.1 port 80 weight 2 max-connections 1000
[sysname-group-1] rserver 2 to 5 rip 192.168.0.2 port 80 weight 1 max-connections 500

# Configure policies for a busy real server.

[sysname-group-1] action optimize

# Set service health check parameters. Set the protocol type of probe packets to HTTP, requested URL to /huawei/huawei.html, set the status code to 200, interval between sending probe packets to 4 seconds, and maximum number of consecutive probe failures is 5.

[sysname-group-1] health-check type http req-url /huawei/huawei.html ept-code 200 tx-interval 4 times 5
[sysname-group-1] return

Verification

Run the display slb group [ group-name ] command to view the basic configurations of the real server group.

<sysname> display slb group grp1
Group Information(Total 1)                                                      
---------------------------------------------------------------                 
  Group Name               : grp1                                               
  Group ID                 : 1                                                  
  Metric                   : weight-least-connection                            
  Source-nat Type          : NA
  Health Check Type        : http                                               
  Real Server Number       : 5                                                  
    RserverID  IP Address       Weight  Max-connection  Status      
    0          192.168.0.1      2       1000            Active                            
    1          192.168.0.2      1       500             Active            
    2          192.168.0.3      1       500             Active            
    3          192.168.0.4      1       500             Active            
    4          192.168.0.5      1       500             Active           
                                                                                
---------------------------------------------------------------

Table 2 shows the description of the display slb group grp1 command output.

**Table 2** Description of the **display slb group grp1** command output
Item	Description
Group Information	Information about a real server group.
Total	Number of real server groups.
Group Name	Name of a real server group.
Group ID	ID of a real server group.
Metric	Load balancing algorithm.
Source-nat Type	Source NAT mode.
Health Check Type	Protocol type for service health check.
Real Server Number	Number of real servers.
RserverID	ID of a real server.
IP Address	IP address of a real server.
Weight	Weight of a real server.
Max-connection	Maximum number of connections on a real server.
Status	Status of a real server. The available options are as follows: Admin-Active: indicates that the real server is available. As the real server is not configured to the inactive state (status inactive) and service health check parameters are not set, the real server is considered available by default. Admin-Invalid: indicates that the real server is unavailable. As the real server is configured to the inactive state (status inactive), the real server is considered unavailable regardless of the configuration of service health check parameters and the check result. status inactive has the highest configuration priority. Admin-Health-Check: indicates the transition status of service health check. Service health check is performed on the real server, but the check result is not generated. Active: indicates that the real server is available. Service health check is performed on the real server, and the check result shows that the real server is available. Inactive: indicates that the real server is unavailable. Service health check is performed on the real server, and the check result shows that the real server is unavailable.