HAProxy Usage Details

HAProxy Usage Details

HAProxy details

HAProxy is a free, fast, and reliable solution for providing high availability, load balancing, and proxy services for TCP and HTTP-based applications, it is especially suitable for websites with high load and require persistent connections or layer-7 processing mechanisms. HAProxy can also isolate backend servers from the network to protect backend servers. Although HAProxy's load balancing capability is not as good as LVS, it is also quite good. Because it is working on Layer 7, it can perform in-depth analysis on http request packets, forwarding packets to different backend servers (such as static/dynamic separation) as needed cannot be completed in layer-4 LVS.

Install and configure HAproxy

HAProxy has been integrated into the base source and can be downloaded directly through yum.

[Root @ node1 ~] # Yum install haproxy

Of course, you can also go to the official website to directly download the source code for compilation and installation.

/Etc/haproxy. cfg is the master configuration file of haproxy, which includes global settings and proxies ).

Global settings: Mainly used to define parameters related to haproxy process management security and performance.

Proxies: proxy-related configurations can be composed of the following configuration ends.

-Defaults <name>: Provides default parameters for other configuration segments. The default configuration parameters can be reset by the next "defaults.

-Frontend <name>: defines a series of listening sockets that can accept client requests and establish connections with them.

-Backend <name>: defines "backend" servers. The front-end Proxy Server schedules client requests to these servers.

-Listen <name>: defines the listening socket and backend server. Similar to putting frontend and backend segments together

Working Mode of HAproxy:

HAProxy generally works in two modes: tcp mode and http mode.

Tcp mode: The instance runs in TCP mode. A full-duplex connection is established between the client and the server, and no layer-7 packets are checked, it can only work in simple mode. This is the default mode and is usually used for SSL, SSH, SMTP, and other applications.

Http mode: The instance runs in HTTP mode. client requests are analyzed in depth before being forwarded to the backend server. All requests that are not compatible with the RFC format are rejected.

When implementing content exchange, the frontend and backend must work in the same mode (generally in HTTP mode). Otherwise, the instance cannot be started. The mode parameter can be defined in default, frontend, listen, and backend.

Mode {tcp | http}

-------------------------------------- Split line --------------------------------------

Haproxy + Keepalived build Weblogic high-availability server Load balancer Cluster

Keepalived + HAProxy configure high-availability Load Balancing

Haproxy + Keepalived + Apache configuration notes in CentOS 6.3

Haproxy + KeepAlived WEB Cluster on CentOS 6

Haproxy + Keepalived build high-availability Load Balancing

Configure an HTTP Load balancer using HAProxy

-------------------------------------- Split line --------------------------------------

The following describes common HAproxy usage.

Application Instance

Load Balancing Based on HAProxy

You can use the server to define backend nodes in the backend or listen segments.

Format: server <name> <address> [: port] [param *]

<Name>: Internal name specified for this server

[Param *]: A parameter set for this server. There are many available parameters. The following are common parameters.

Server parameters:

Backup: set as a backup server. Other servers in the server Load balancer scenario cannot be used to enable this server;

Maxconn <maxconn>: specifies the maximum number of concurrent connections accepted by this server. If the number of connections sent to this server is greater than the value specified here, it will be placed in the Request queue, wait for other connections to be released;

Maxqueue <maxqueue>: sets the maximum length of the Request queue;

Observe <mode>: checks whether the server is healthy by observing the communication status of the server. The default value is disabled. The supported types include "layer4" and "layer7 ", "layer7" can only be used in http Proxy scenarios;

Redir <prefix>: Enable the redirection function. The GET and HEAD requests sent to this server are all responded with a 302 status code;

Weight <weight>: Server weight. The default value is 1. The maximum value is. 0 indicates that Server Load balancer is not involved;

Defines the load balancing algorithm. In addition to the listen and backend segments, the algorithm can also be placed in the ults segments. The definition format is as follows:

Balance <algorithm> [<arguments>]

Balance url_param <param> [check_post [<max_wait>]

Common scheduling algorithms include:

Roundrobin: Round Robin Based on weights. This algorithm is dynamic and its weights can be adjusted at runtime.

Static-rr: Round Robin Based on weights. It is similar to roundrobin, but it is a static method and its server weight adjustment does not take effect at runtime.

Leastconn: New connection requests are distributed to backend servers with the minimum number of connections. It is a dynamic algorithm and is suitable for scenarios with long sessions.

Source: hash the requested source address, modulo the total weight of the backend server, and schedule the operation to a server; requests of the same IP address will always be scheduled to a specific server. The static algorithm can be modified using hash-type;

Uri: the left half of the URI ("?" (Previous part) or the whole URI for hash calculation, and the total weight of the backend server for modulo operation, and then scheduled to a server; requests of the same URI will always be scheduled to a specific server. For static algorithms, you can use hash-type to modify this feature;

Hdr (<name>): scheduling is performed based on the value of the http header specified in the user request message. It is often used to always send requests to the same virtual host to the same backend server.

Configuration example on the front-end Proxy Server (the others are the default configuration ):

#---------------------------------------------------------------------

# Main frontend which proxys to the backends

#---------------------------------------------------------------------

Frontend service *: 80

Default_backend app

#---------------------------------------------------------------------

# Static backend for serving up images, stylesheets and such

#---------------------------------------------------------------------

Backend app

Balance roundrobin

Server app1 192.168.2.7: 80 maxconn 3000 weight 2

Server app2 192.168.2.18: 80 maxconn 3000 weight 1

Server app3 127.0.0.1: 8080 backup

Configure the test page on app1 (192.168.2.7:

[Root @ node1 ~] # Vim/web/index.html

<H2> server node1

On app1 (192.168.2.18:

[Root @ node2 ~] # Vim/web/index.html

<H2> server node2

There are two interfaces on the proxy server: 192.168.1.116 (for the client) and 192.168.2.11. After the configuration is complete, start the haproxy service. Start the nginx service on the backend node.

Round-Robin access has been implemented.

The hash operation is involved in the preceding algorithm. The hash-type parameter can be used to define the hash operation mode. The format is as follows:

Format: hash-type <map-based | consistent>

Map-based: static method. online server weight adjustment cannot take effect immediately. A hash table is a static array containing all online servers. In short, requests are scheduled to a backend server through this operation. When the backend server changes (for example, a server is down or a new server is added ), most of the connections will be rescheduled to a different server.

Consistent: supports dynamic distribution and online server weight adjustment. The hash table is a tree structure filled by servers. This algorithm is used for scheduling. When the backend servers change, the connections in the large distribution will still be scheduled to the original servers.

The default mode is map-based, which can be used in most scenarios. However, if the backend server is a cache server, the default method is used. When the backend server is adjusted, the cache cannot be hit, thus affecting the system performance. Recommended Configuration Methods:

Backend <name>

Balance uri

Hash-type consistent

Server ....

Server...

Health Check of backend servers

Check is a server parameter that enables health check on this server. Check uses its additional parameters to implement a more precise monitoring mechanism.

Inter <delay>: interval between health status detection, in milliseconds. The default value is 2000. You can use fastinter and downinter to optimize the delay Based on the server status;

Rise <count>: number of times that an offline server needs to be successfully checked during health check from offline to normal;

Fall <count>: the number of times the server needs to be checked to switch from normal to unavailable;

Configuration example:

Backend app

Balance roundrobin

Server app1 192.168.2.7: 80 maxconn 3000 weight 2 check inter 1 rise 1 fall 2

Server app2 192.168.2.18: 80 maxconn 3000 weight 1 check inter 1 rise 1 fall 2

Server app3 127.0.0.1: 8080 backup

State page

Enable statistical report. You can view the status and related information of each server on the state page. We recommend that you define a listen separately for the state configuration.

Listen stats

Mode http

Bind 192.168.1.116: 1080 # listening port

Stats enable # enable the state Function

Stats scope app # report section of the statistical report. If this item is not enabled, all sections of the report will be reported.

Stats hide-version # hide the HAProxy version

Stats uri/haproxyadmin? Stats # access path of the state page

Stats realm Haproxy \ Statistics # authentication prompt information

Stats auth baby: baby # authenticated account and password

Stats admin if TRUE # enable management

After the configuration is complete, restart the haproxy service. Then access the defined path: http: // 192.168.1.116: 1080/haproxyadmin? Stats. Complete authentication first.

Based on the Health Check completed in the previous configuration, the nginx service of one of the backend servers is stopped.

[Root @ node1 web] # service nginx stop

Stopping nginx: [OK]

Red indicates that the service is not online. If the service of all backend servers is stopped, the server defined as backup will be accessed (the sorry page on 127.0.0.1 ).

For more details, please continue to read the highlights on the next page:

1 2 Next Page