Shulou(Shulou.com)06/02 Report--

Through the blog post: Nginx+Tomcat to achieve load balancing cluster instance, you can follow!

Detailed explanation of LVS load balancing Cluster

We have been able to use Nginx and LVS to do load balancing clusters, each of which has its own characteristics. Today, we know a more popular cluster scheduling tool-Haproxy.

I. Overview of Haproxy

Haproxy is a popular cluster scheduling tool at present, and there are many similar cluster scheduling tools, such as LVS and Nginx. Comparatively speaking, LVS has the best performance, but the construction is relatively complex; the upstream module of Nginx supports the cluster function, but the health check function of the cluster node is not strong, and the performance is not as good as Haproxy.

2. 1.HTTP request for knowledge points that you must know when using Haproxy

The protocol used to access a website through URL is the HTTP protocol, and such requests are generally referred to as HTTP requests.

The method of HTTP request can be divided into GET method and POST method. The difference between the two is as follows:

GET mode: less content (generally not more than 8kB), unsafe, and content is directly attached to URL; POST mode: more content and security

When accessing a URL using a browser, the status code is returned according to the request URL. Normally, the status code is 2 XX and 3 XX (e.g. 201,301). If an exception occurs, it returns 4 XX and 5 XX (such as 401,501).

For more information on the return status code for HTTP request, please see blog post: HTTP request return status code for more information.

two。 Common scheduling algorithms for load balancing

There are three most commonly used scheduling algorithms for building clusters using LVS, Haproxy and Nginx:

(1) RR (polling algorithm)

RR (Round Robin): the RR algorithm is the simplest and easiest to understand, that is, polling scheduling. This algorithm also has a weighted polling, which allocates access requests according to the weight of each node.

This algorithm is mainly used for node server performance is similar, to work all work

(2) LC (minimum number of connections algorithm)

LC (Least Connections): the minimum number of connections algorithm, which dynamically allocates front-end requests according to the number of back-end node connections. It is guaranteed that new requests will be assigned to the client with the least number of connections. Due to the actual situation, the number of connections of each node is dynamically released, so it is difficult to have the same number of connections, so this algorithm wants to have a great improvement compared with the RR algorithm, and it is the most widely used algorithm at present.

(3) SH (source-based access scheduling algorithm)

SH (Source Hashing): source-based access scheduling algorithm. This algorithm is used in some scenarios where Session sessions are recorded on the server. Cluster scheduling can be done based on the source IP, Cookie, and so on. The advantage of this algorithm is to achieve session persistence, but when some IP visits are very large, it will cause load imbalance, and some nodes have a large number of visits, which will affect business usage.

3. Common Web Cluster Scheduler

At present, the most common Web cluster scheduler is divided into software and hardware; software usually uses open source LVS, Haproxy, Nginx; hardware generally use F5, and many people use some domestic products. Such as barracuda, Green League and so on.

Application Environment of 4.Haproxy

As shown in the figure:

Third, install Haproxy

Haproxy installation package network disk link: https://pan.baidu.com/s/10masYgp7VSWuZu8ebZ-pfQ

Extraction code: 2l44

1. Compile and install Haproxy[ root @ localhost ~] # yum-y install pcre-devel bzip2-devel// install dependency package, let Haproxy service support regular expressions, extract [root@localhost ~] # tar zxf haproxy-1.5.19.tar.gz-C / usr/src [root ~] # cd / usr/src/haproxy-1.5.19/ [root@localhost haproxy-1.5.19] # make TARGET=linux26 / / means 64 system / / decompress normally But this software does not need to be configured. [root@localhost haproxy-1.5.19] # make install2.Haproxy service configuration (1) create Haproxy configuration file [root@localhost haproxy-1.5.19] # mkdir / etc/haproxy [root@localhost haproxy-1.5.19] # cp / usr/src/haproxy-1.5.19/examples/haproxy.cfg / etc/haproxy/// copy haproxy.cfg file to configuration file directory (2) Haproxy configuration item details

The Haproxy configuration file is usually divided into three parts:

Global (global configuration); defaults (default configuration); listen (application component configuration)

Global (Global configuration) usually has the following configuration parameters:

Global log 127.0.0.1 local # configure logging. Local0 is the logging device, which is stored in the system log by default. Log 127.0.0.1 local1 notice # notice is the log level, and there are usually 24 levels # log loghost local0 info maxconn 4096 # maximum number of connections chroot / usr/share/haproxy # the root directory set by the service Generally, you need to comment out this line uid 99 # user UID gid 99 # user GID daemon # daemon mode

Defaults (default configuration) is generally inherited by the application component. If there is no special declaration in the application component, the default configuration parameter settings will be installed. Common parameters are:

Defaults log global # defines logs as logs in global configuration defines mode http # mode as http option httplog # logs are recorded in http log format option dontlognull retries 3 # check node server failures, up to three consecutive failures It is considered that the node is unavailable redispatch # when the server load is high Automatically end long-processed connections in the current queue maxconn 2000 # maximum number of connections contimeout 5000 # connection timeout clitimeout 50000 # client timeout srvtimeout 50000 # server timeout

Listen (configuration item) General configuration application module parameters:

Listen appli4-backup 0.0.0.0 listen appli4-backup 10004 # defines an application called appli4-backup / index.html # to check the server's index.html file option persist # to force the request to be sent to a server that has already dropped down. This option is generally disabled. Balance roundrobin # load balancing scheduling algorithm uses polling algorithm server inst1 192.168.114.56 check inter 80 check inter 2000 fall 3 # defines an online node server inst2 192.168.114.56 check inter 81 check inter 2000 fall 3 backup # defines a backup node # Note: among the parameters that define the backup node above, # "check inter 2000" represents a heartbeat rate between the haproxy server and the node # "fall 3" means that the node fails if the heartbeat rate is not detected for three times in a row. The configuration of a # node with "backup" means that the node is only a backup node, and it will only be installed if the primary node fails. # remove backup, which means that the master node provides services together with other master nodes. (3) Parameter tuning of Haproxy

As shown in the figure:

The following modified configuration file can meet the normal requirements. If you read the meaning of the above configuration items in detail, you can add your own requirements.

Global log 127.0.0.1 local0 log 127.0.0.1 local1 notice # log loghost local0 info maxconn 4096 # chroot / usr/share/haproxy uid 99 gid 99 daemon # debug # quietdefaults log global mode http option httplog option dontlognull retries 3 # redispatch maxconn 2000 Contimeout 5000 clitimeout 50000 srvtimeout 50000listen appli1-rewrite 0.0.0.0:80 option httpchk GET / index.html balance roundrobin server app1_1 192.168.1.3:80 check inter 2000 rise 2 fall 5 server app1_2 192.168.1.4:80 check inter 2000 rise 2 fall 5

I won't explain exactly what it means here.

(4) create a startup script [root@localhost ~] # cp / usr/src/haproxy-1.5.19/examples/haproxy.init / etc/init.d/haproxy [root@localhost ~] # ln-s / usr/local/sbin/haproxy / usr/sbin/haproxy [root@localhost ~] # chmod + x / etc/init.d/haproxy [root@localhost ~] # chkconfig-- add / etc/init.d/haproxy [root@localhost ~] # / etc/init.d/haproxy startStarting Haproxy (via systemctl): [OK] / / are all very basic commands I won't explain what it means here. (5) the log of Haproxy service.

The log of Haproxy is output to the syslog of the system by default, which is very inconvenient to view. In order to better manage the log information of Haproxy, we generally define it separately in the sound field environment. The methods are as follows:

[root@localhost ~] # vim / etc/haproxy/haproxy.cfg global log / dev/log local0 info log / dev/log local0 notice// add two lines to comment out the original information about the log [root@localhost ~] # systemctl restart haproxy// restart service [root@localhost ~] # vim / etc/rsyslog.d/haproxy.conf// defines where the log files of the Haproxy service are stored Add the following: if ($programname = = 'haproxy' and $syslogseverity-text = =' info') then-/ var/log/haproxy/haproxy-info.log& ~ if ($programname = = 'haproxy' and $syslogseverity-text = =' notice') then-/ var/log/haproxy/haproxy-notice.log& ~ [root@localhost ~] # systemctl restart rsyslog// restart the log service

When the client accesses, you can use the following command to view the log file of the Haproxy service

[root@localhost] # tail-f / var/log/haproxy/haproxy-info.log

-this is the end of this article. Thank you for reading-

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.