Nginx load balancing weighted round robin and ip_hash

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

Nginx acts as a reverse proxy for backend web servers (apache, nginx, tomcat, and weblogic).

Several backend web servers need to consider file sharing, database sharing, and session sharing. File sharing can use nfs, shared storage (fc, ip storage), and redhat GFS cluster file system.
System, rsync + inotify file synchronization. nfs is used in small-scale clusters. for the content management system, it is a good choice to publish information on a single node and use rsync + inotify to synchronize multiple nodes.
Small-scale clusters, a single high-performance database (such as Zhiqiang dual-quad-core, 32/64/GB memory), large-scale clusters may have to consider the database cluster, you can use the cluster software officially provided by mysql
You can use keepalived + lvs read/write splitting to create a Mysql Cluster.
Session sharing is a big problem. If nginx uses the ip_hash round robin method, each ip address will be fixed to the backend server within a certain period of time, so we do not need to solve the session sharing problem. Otherwise,
When requests from an ip address are round-robin and distributed to multiple servers, session sharing needs to be solved. You can use nfs shared sessions to write sessions to mysql or memcache. When the machine size is large
Generally, the session is written into memcache.

We will not discuss how to configure the backend web servers here. The backend servers may be apache, nginx, tomcat, lighthttp, etc. The front end does not care what the backend is.
First, create a new proxy. conf file to facilitate subsequent calls (if multiple clusters are configured, it is good to write public parameters to a file and then continue to include)
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 4 k;
Proxy_buffers 4 32 k;
Proxy_busy_buffers_size 64 k;
Proxy_temp_file_write_size 64

Here we will discuss two load balancing methods of nginx round robin weighted (or not weighted, that is, load) and ip_hash (the same ip address will be allocated to a fixed backend server to solve the session problem)
This configuration file can be written to nginx. conf (if there is only one web cluster), if there are multiple web clusters, it is best to write them into vhosts. In the form of a virtual host, here I write to nginx. conf
Configuration 1: Weighted Round Robin (WRR), weighted by server performance. In this example, it is allocated.
Upstream lb {

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

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. You cannot add weight to the server.

Upstream lb {

Server 192.168.196.130 fail_timeout = 20 s;
Server 192.168.196.132 fail_timeout = 20 s;
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 2 nginx server load balancer implements session pasting based on ip_hash


1. Round Robin (default)
Each request is distributed to different backend servers one by one in chronological order. If the backend servers are down, they can be removed automatically.

Upstream backserver {
Server 192.168.0.14;
Server 192.168.0.15;
}
2. Specify the weight
Specify the round-robin probability. weight is proportional to the access ratio, which is used when the backend server performance is uneven.

Upstream backserver {
Server 192.168.0.14 weight = 10;
Server 192.168.0.15 weight = 10;
}
3. Bind an IP address to ip_hash
Each request is allocated according to the hash result of the access ip address, so that each visitor accesses a backend server at a fixed time, which can solve the session problem.

Upstream backserver {
Ip_hash;
Server 192.168.0.14: 88;
Server 192.168.0.15: 80;
}
4. fair (third party)
Requests are allocated based on the response time of the backend server. Requests with short response time are prioritized.

Upstream backserver {
Server server1;
Server server2;
Fair;
}
5. url_hash (third-party)
Requests are allocated based on the hash result of the access url so that each url is directed to the same backend server. The backend server is effective when it is cached.

Upstream backserver {
Server squid1: 3128;
Server squid2: 3128;
Hash $ request_uri;
Hash_method crc32;
}
Add

Proxy_pass http: // backserver /;
Upstream backserver {
Ip_hash;
Server 127.0.0.1: 9090 down; (down indicates that the server before the order is not involved in the load for the time being)
Server 127.0.0.1: 8080 weight = 2; (the default value of weight is 1. The larger the weight value, the higher the load weight)
Server 127.0.0.1: 6060;
Server 127.0.0.1: 7070 backup; (requests to backup machines when all other non-backup machines are down or busy)
}
Max_fails: the default number of failed requests is 1. If the maximum number of failed requests is exceeded, an error defined by the proxy_next_upstream module is returned.
Fail_timeout: the pause time after max_fails fails.

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.