Nginx load Balancing weighted polling and Ip_hash

Source: Internet
Author: User
Tags hash inotify rsync tomcat nginx load balancing

The following summarizes a number of real nginx load balancing function, here we add a weight to judge the method is based on the state of the Nginx load allocation of access to the user to the weight of the machine, the specific configuration is as follows.

Nginx for back-end Web server (apache,nginx,tomcat,weblogic), such as reverse proxy

Several back-end Web servers need to consider file sharing, database sharing, session sharing issues. File sharing can use NFS, shared storage (Fc,ip storage) +redhat GFs Cluster File system
Rsync+inotify file synchronization, and so on. Smaller clusters use more NFS. For the Content management system, a single station to publish information, to more than one synchronized use of rsync+inotify is a good choice.
Small-scale clusters, a single high-performance database (such as strong dual quad-core, 32/64/128g memory) can be, large-scale clusters may have to consider the database cluster, you can use the MySQL officially provided by the cluster software, but also
You can use Keepalived+lvs read-write separation to do MySQL cluster.
Session sharing problem is a big problem, if Nginx uses Ip_hash polling method, each IP will be fixed in a certain time back-end server, so we do not have to solve the session sharing problem. Conversely,
One IP request is polled distributed to multiple servers, to solve the problem of session sharing, you can use the NFS sharing session, the session is written to MySQL or Memcache method, when the machine size is larger
, it is generally used to write the session to memcache inside.

How the backend Web server is configured we will not discuss here, the backend server may be apache,nginx,tomcat,lighthttp, etc., the front end does not care what the backend is.
First, create a new proxy.conf file, convenient for us to make a call (configure multiple clusters, the public parameters to write a file, and then continue to include is a good way)
Vi/usr/local/nginx/conf/proxy.conf
Proxy_redirect off;
Proxy_set_header Host $host;
Proxy_set_header X-real-ip $remote _addr;
Proxy_set_header x-forwarded-for $proxy _add_x_forwarded_for;
Client_body_buffer_size 90;
Proxy_connect_timeout 90;
Proxy_read_timeout 90;
Proxy_buffer_size 4k;
Proxy_buffers 4 32k;
Proxy_busy_buffers_size 64k;
Proxy_temp_file_write_size 64

We discuss the two load balancing methods of Nginx polling weighting (also can not be weighted, that is, 1:1 load) and Ip_hash (the same IP will be assigned to a fixed back-end server, solve the session problem)
This configuration file, we can write to nginx.conf inside (if there is only one Web cluster), if there are multiple Web clusters, it is best to write to vhosts inside, to the virtual host way, here I write to nginx.conf inside
The first configuration: Weighted polling, weighting by server performance, this example is 1:2 allocation
Upstream lb {

                Server 192.168.196.130 weight=1 fail_timeout=20s;
                Server 192.168.196.132 weight=2 fail_timeout=20s;
 }

server {
Listen 80;
server_name safexjt.com www.safexjt.com;
Index index.html index.htm index.php;
Location/{
Proxy_pass http://lb;
Proxy_next_upstream http_500 http_502 http_503 error timeout invalid_header;
Include proxy.conf;
}
}

Second configuration: Ip_hash polling method, do not add weight to the server

Upstream lb {

                Server 192.168.196.130 fail_timeout=20s;
                Server 192.168.196.132 fail_timeout=20s;
  ip_hash;
 }

server {
Listen 80;
server_name safexjt.com www.safexjt.com;
Index index.html index.htm index.php;
Location/{
Proxy_pass http://lb;
Proxy_next_upstream http_500 http_502 http_503 error timeout invalid_header;
Include proxy.conf;
}
}

Method two the Nginx load balancer implements the session pasting based on Ip_hash


1. Polling (default)
Each request is assigned to a different back-end server in chronological order, and can be automatically rejected if the backend server is down.

Upstream Backserver {
Server 192.168.0.14;
Server 192.168.0.15;
}
2. Assigning weights
Specifies the polling probability, proportional to the weight and access ratios, for situations where the performance of the backend server is uneven.

Upstream Backserver {
Server 192.168.0.14 weight=10;
Server 192.168.0.15 weight=10;
}
3. IP binding Ip_hash
Each request is allocated according to the hash result of the access IP, so that each visitor has fixed access to a back-end server that resolves the session issue.

Upstream Backserver {
Ip_hash;
Server 192.168.0.14:88;
Server 192.168.0.15:80;
}
4. Fair (third party)
The response time of the back-end server is allocated to the request, and the response time is short of priority allocation.

Upstream Backserver {
server Server1;
Server Server2;
Fair
}
5. Url_hash (Third Party)
Assign requests by the hash result of the access URL so that each URL is directed to the same back-end server, which is more efficient when the backend server is cached.

Upstream Backserver {
Server squid1:3128;
Server squid2:3128;
Hash $request _uri;
Hash_method CRC32;
}
In servers that need to use load balancing, add

Proxy_pass http://backserver/;
Upstream backserver{
Ip_hash;
Server 127.0.0.1:9090 down; (down indicates that the server is temporarily not participating in the load)
Server 127.0.0.1:8080 weight=2; (weight defaults to 1.weight, the greater the load weight)
Server 127.0.0.1:6060;
Server 127.0.0.1:7070 Backup; (When all other non-backup machines are down or busy, request the backup machine)
}
Max_fails: The number of times that a request failed is allowed defaults to 1. When the maximum number of times is exceeded, the error that is defined by the Proxy_next_upstream module is returned
The time paused after Fail_timeout:max_fails failed

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.