Charlene
Assistant Engineer
Assistant Engineer
  • UID626
  • Fans0
  • Follows1
  • Posts53
Reads:2355Replies:0

Configuration Instructions

Created#
More Posted time:Jul 19, 2016 15:35 PM
Configuring and managing a Server Load Balancer instance primarily involves three operations: configuring Server Load Balancer instance attributes, configuring Server Load Balancer Monitoring, and configuring backend ECS instances for the Server Load Balancer instance. You can configure instance attributes to define the type of Server Load Balancer instance, configure service listeners to define policies and forwarding rules for the Server Load Balancer instance, and configure the Server Load Balancer instance with backend ECS instances used to process user requests.

Configuring Server Load Balancer Instance Attributes
Server Load Balancer Instance Name

You can specify an easily recognizable name for the Server Load Balancer instance you create. If you do not specify a name for the instance, the LoadBalancerID of the Server Load Balancer instance is used as the instance name. LoadBalancerID is the unique identifier of the Server Load Balancer instance and cannot be modified.
Types of Server Load Balancer

There are two types of Server Load Balancer available, namely that for the public network and that for the private network. You can choose the public or private Server Load Balancer service based on your business scenarios. The system will assign a public IP address or private IP address according to your choice.
IP Addresses of Server Load Balancer

Different service IP addresses are distributed based on the selected type of Server Load Balancer. For applications that offer external services via a domain name, you must resolve the domain name to the public IP address of the corresponding Server Load Balancer instance. You can access the service via the domain name only after successful domain name resolution.
Configuring Server Load Balancer Monitoring
Server Load Balancer Protocols/Ports

    Protocols: Currently, Server Load Balancer is available for both Layer-4 (TCP and UDP) and Layer-7 (HTTP and HTTPS) protocols.
    Ports: In a Server Load Balancer instance offering external or internal services, the frontend ports which receive requests and forward the requests to backend servers shall not be repeated within the same Server Load Balancer instance.

Backend Protocols/Ports

    Protocols: Currently, Server Load Balancer is available for both Layer-4 (TCP and UDP) and Layer-7 (HTTP and HTTPS) protocols.
    Ports: The group of backend ports added after the Server Load Balancer instance for processing external or internal requests and receiving requests from ECS can be repeated within the same Server Load Balancer instance. When multiple application services are deployed in the same group of backend ECS instances, a Server Load Balancer instance supports up to 50 monitoring services at the moment.

Forwarding Rule

Currently, Server Load Balancer supports two types of forwarding: round-robin and least-connection. In “round-robin mode”, external and internal access requests are distributed to the backend ECS instances in order. In “least-connection mode”, these requests are distributed to the backend ECS instance with the least connections.
Obtaining Visitors’ Real IP Addresses

    Layer-7 (HTTP) Server Load Balancer replaces the IP address of the HTTP header file to forward requests. Therefore, the access IP address displayed on the backend ECS instances is the local IP address of the Server Load Balancer system instead of the real IP address of the visitor. Therefore, the system allows the use of X-Forwarded-For to obtain the visitor’s real IP address. The “Obtain the Visitor’s Real IP Address” function is enabled for Layer-7 (HTTP) Server Load Balancer Monitoring by default, and cannot be disabled. For how to configure common application servers, [click here] (27703).
    For Layer-4 (TCP) Server Load Balancer, the backend ECS instances directly obtain the visitor’s real IP address.

Session Persistence

After session persistence is enabled, Server Load Balancer will distribute the access requests from a client to the same backend ECS instance for processing.For Layer-7 (HTTP and HTTPS) Server Load Balancer, the system supports cookie-based session persistence. The Server Load Balancer system provides two cookie-based processing methods:

    Cookie seeding means the cookie on the client side is directly allocated and managed by the Server Load Balancer system. You need to specify the timeout time of session persistence during configuration.

NOTE: When the “Cookie seeding” Mode is configured for session persistence and the HTTP status code returned from backend RS is 4xx, Server Load Balancer does not seed the Set-Cookie header, which may result in session persistence failure. Server Load Balancer seeds the header necessary for session persistence when the HTTP status code returned from the backend RS is 200, 201, 204, 206 301, 302, 303, 304, or 307.

    Cookie rewriting means the Server Load Balancer system will allocate and manage the cookie seeding operation on the client side according to the custom cookie name. This allows you to identify and distinguish the custom cookie name, and therefore set session persistence rules for different applications on backend servers. You need to specify a name for the corresponding cookie during configuration. For how to configure different persistence rules under multiple domain names, click here.

For Layer-4 (TCP and UDP) Server Load Balancer, the system supports IP address-based session persistence. Server Load Balancer forwards access requests from an IP address to the same backend ECS instance for processing.
Health Check

    After health check is enabled, if a backend ECS instance is abnormal, Server Load Balancer forwards requests to other normal ECS instances, and automatically restores the ECS instance when it becomes normal again and can provide external or internal services.
    For Layer-7 (HTTP and HTTPS) Server Load Balancer, the system performs health check as follows: By default, the Server Load Balancer system uses the intranet IP address of backend ECS to initiate a HTTP head request to the default page configured by the application server (the default page is accessed through the backend ECS port specified in the server listener configuration). When a 200 OK message is returned, the backend ECS runs normally; otherwise, the backend ECS runs abnormally. If the page for heath check is not the default page of the application server, you need to specify a corresponding URI. If you define parameters of the host field for the HTTP head request, you need to specify a corresponding URL. You can set the health check frequency, healthy threshold value and unhealthy threshold value to better control the health check function.
    For Layer-4 (TCP and UDP) Server Load Balancer, the system performs health check as follows: By default, the Server Load Balancer system uses the backend ECS port specified in the service listener configuration to initiate an access request. If the port can access the system, the backend ECS instances run normally; otherwise, they run abnormally.
    For how to troubleshoot health check exceptions, click here.

The following TCP/HTTP/HTTPS health check parameter settings are recommended:


    Response timeout: 5 seconds
    Health check interval: 2 seconds
    Unhealthy threshold value: 3
    Healthy threshold value: 3
    This configuration facilitates the rapid convergence of user services and application statuses:
    ECS health check failure response time (in case of a network exception): (2 + 5) × 3 = 21 seconds    
    For faster response, lower the response timeout value. However, ensure that your service is normally processed within a timeframe less than this value.
    ECS health check success response time: 2×3=6 seconds

The following UDP health check parameter settings are recommended:


    Response timeout time: 10 seconds
    Health check interval: 5 seconds
    Unhealthy threshold value: 6
    Healthy threshold value: 6
    This configuration facilitates the rapid convergence of user services and application statuses:
    ECS health check failure response time (in case of a network exception): (5 + 10) × 6 = 90 seconds
    For faster response, lower the response timeout value. However, ensure that your service is normally processed within a timeframe less than this value.
    ECS health check success response time: 5 × 6 = 30 seconds

Bandwidth Peak

You can set different bandwidth peaks for different listeners to restrict the capacity of different applications on the backend ECS instances to offer external services.

The rules for setting bandwidth peaks are as follows:

    Up to 50 listeners can be added to a Server Load Balancer instance. Different rules can be set for each listener.
    The bandwidth peak for a single listener can be set in the range of 5 to 1,000 Mbps.
    The bandwidth peak limit can be lifted for higher bandwidth needs.

Backend ECS Configuration for Server Load Balancer

In principle, no special configuration is required for the backend ECS instances added to a Server Load Balancer instance. If a Linux ECS instance cannot be accessed normally after being attached to Layer-4 (TCP and UDP) Server Load Balancer, check whether the following three values in the system configuration file /etc/sysctl.conf are 0:

    net.ipv4.conf.default.rp_filter = 0
    net.ipv4.conf.all.rp_filter = 0
    net.ipv4.conf.eth0.rp_filter = 0

If the ECS instances in the same intranet segment cannot communicate with each other, check whether the following parameters are set correctly:

    net.ipv4.conf.default.arp_announce =2
    net.ipv4.conf.all.arp_announce =2

Run the “sysctl –p” command to update the parameter settings.
Backend ECS Weight

You can specify the forwarding weighting of each ECS instance in the backend ECS pool. An ECS instance with the higher weight ratio will receive more access requests. The forwarding weighting can be set based on the external service capacity and status of the backend ECS instance.
Guest