Haproxy achieves load balancing and dynamic/static Separation

Haproxy achieves load balancing and dynamic/static Separation

After haprxy Server Load balancer and dynamic/static separation, haproxy is more professional in these two aspects than nginx, including session persistence, cookie guidance, and url monitoring backend, mysql Server Load balancer is not available in nginx, but it cannot be said that haprox can replace nginx, and nginx cache is not available in proxy.

Next we will use haproxy to do some basic configuration.

Haproxy: 192.168.3.124

Node1: 192.168.3.128

Node2: 192.168.3.129

I. Basic Configuration:

1. Install proxy

Yum install haproxy-y

Current stable version 1.5.X

Cp/etc/haproxy. cfg/etc/haproxy. cfg. bak

2. Enable the proxy System Log

 

vim/etc/rsyslog.conf $ModLoad imudp$UDPServerRun 514local2.*                                               /var/log/haproxy.logservice rsyslog restart

3. modify the configuration file to implement simple Load Balancing

Global log 127.0.0.1 local2 chroot/var/lib/haproxy pidfile/var/run/haproxy. pid maxconn 4000 # defines the maximum number of connections for each haproxy process. Since each connection includes one client and one server, the maximum number of TCP sessions for a single process is twice the value. User haproxy group haproxy daemon # Run nbproc 16 in daemon mode # set the number of processes when haproxy starts. According to the explanation in the official documentation, I understand it: this value should be set to the same number of CPU cores as the server, that is, the common two eight-core CPU servers, that is, a total of 16 cores, you can set the value to: <= 16, creating multiple processes reduces the number of task queues for each process. However, excessive processes may crash. Here I set it to 16 # turn on stats unix socket stats socket/var/lib/haproxy/statsdefaults mode http log global option httplog option dontlognull # enable this option, no empty connections will be recorded in the log. The so-called empty connection is when the upstream Server Load balancer or monitoring system needs to regularly connect to or obtain a fixed component or page to detect whether the service is alive or available, or whether the scan port is listening or opening is called an empty connection. this parameter is not recommended if no other Server Load balancer instance exists in the upstream of the service, because malicious scanning or other actions on the Internet are not recorded, option http-server-close # Some servers do not support http persistent connections, this parameter can be used to establish persistent connections from the client to haproxy, while from haproxy to the server is short connection option forwardfor processing t 127.0.0.0/8 option redispatch # When cookie is used, haproxy inserts the serverID of the backend server requested by haproxy into the cookie to ensure SESSION persistence. If the backend server is down, however, the cookie on the client is not refreshed. If this parameter is set, the customer's request will be forcibly directed to another backend server to ensure normal service. Retries 3 # define the number of failed reconnections to the backend server, when the number of connection failures exceeds this value, the corresponding backend server will be marked as unavailable timeout http-request 10 s timeout queue 1 m timeout connect 10 s timeout client 1 m timeout server 1 m timeout http-keep-alive 10 s timeout check 10 s maxconn 3000 frontend main *: 80 # define a front-end application named main default_backend app # if there is no matching, the backend app pointing to the backend server by default # define a backend server named app balance roundrobin server app1 192.168.3.128: 80 check server app2 192.168.3.129: 80 check stats enable # enable the server status monitoring page

After the configuration is complete, restart haproxy.

Service haproxy restart

4. Test

[Root @ usvr-124 haproxy] # curl 192.168.3.124/1.html

Hello, 192.168.3.129

[Root @ usvr-124 haproxy] # curl 192.168.3.124/1.html

Hello, 192.168.3.128

From this we can see that the load balancing policy is round-robin access.

5. Let's take a look at the status monitoring page.

 

Through the above basic configuration, we have almost understood the working mechanism of haproxy. Let's take a look at the next step.

2. Implementing static/dynamic separation of access pages

 

Global chroot/var/lib/haproxy pidfile/var/run/haproxy. pid maxconn 4000 user haproxy group haproxy daemon # turn on stats unix socket stats socket/var/lib/haproxy/statsdefaults mode http log global option httplog option dontlognull option http-server-close option forwardfor failed t 127.0.0.0/8 option redispatch retries 3 timeout http-request 10 s timeout queue 1 m timeout connect 10 s timeout client 1 m timeout server 1 m timeout http-keep-alive 10 s timeout check 10 s maxconn 3000 frontend main *: 80 acl url_static path_beg-I/static/images/javascript/stylesheets # create an acl Policy path_beg: access path starting with/static/images, -I ignore case-insensitive acl url_static path_end-I. jpg. gif. png. css. js # create an acl Policy path_end: To .jpg. -I ignores use_backend static if url_static # if the URL policy matches url_static, the backend default_backend app will be used. # if no configuration is available, use the default backend appbackend static balance roundrobin # Round Robin Access server static 192.168.3.128: 80 checkbackend app balance roundrobin # Round Robin Access server app2 192.168.3.129: 80 check

Here we have created several new acl policies for implementing

1. when accessing the paths starting with/static/images/javascript/stylesheetsand ending with .jpg. gif. png. css. js, point to the backend server 192.168.3.180

2. If there is no matching, point to the default backend server 192.168.3.129

I will not post the access results.

Conclusion: through the two examples above, we have learned about the power of haproxy in load balancing, and of course we can also achieve mysql read load balancing, for more advanced features, let's get to know it.