Nginx load balancing and configuration
1 Load Balancing Overview The
origin of load balancing is that when a server has a large amount of traffic per unit time, the server will be under great pressure. When it exceeds its own capacity, the server will crash. To avoid crashing the server. The user has a better experience, born load balancing to share the pressure of the server.
Load balancing is essentially implemented by the principle of reverse proxy, is a kind of technology that optimizes server resources and reasonably handles high concurrency, and can balance Server pressure to reduce user request wait time and ensure fault tolerance. Nginx is generally used as an efficient HTTP load balancing server to distribute traffic to multiple application servers to improve performance, scalability, and high availability.
Principle: Internal A large number of servers can be built on the network to form a server cluster. When users access the site, they first access the public network intermediate server. The intermediate server is assigned to the intranet server according to the algorithm and shares the pressure of the server. Therefore, each visit of the user will ensure the server. The pressure of each server in the cluster tends to balance, sharing server pressure and avoiding servers The collapse of the case.
The nginx reverse proxy implementation includes the following load balancing HTTP, HTTPS, FastCGI, uwsgi, SCGI, and memcached.
To configure HTTPS load balancing, simply use the protocol that begins with ‘http’.
When you want to set load balancing for FastCGI, uwsgi, SCGI, or memcached, use the fastcgi_pass, uwsgi_pass, scgi_pass, and memcached_pass commands, respectively.
2 Common Balancing Mechanisms of Load Balancing
1 round-robin: The requests are distributed to different servers in a polling manner. Each request is assigned to different back-end servers in chronological order. If the back-end server goes down, it is automatically removed to ensure normal service. .
Configuration 1:
upstream server_back {#nginx distribution service request
server 192.168.162.49;
server 192.168.162.50;
}
Configuration 2:
http {
upstream servergroup { # service group accepts requests, nginx polling distribution service requests
server srv1.demo.com;
server srv2.demo.com;
server srv3.demo.com;
}
server {
listen 80;
location / {
Proxy_pass http://servergroup; #All requests are proxied to servergroup service group
}
}
}
proxy_pass is followed by proxy server ip, can also be hostname, domain name, ip port mode
upstream set load balancing background server list
2 Weight load balancing: If no weight is configured, the load of each server is the same. When there is uneven server performance, weight polling is used. The weight parameter of the specified server is determined by load balancing. a part of. Heavy load is great.
Upstream server_back {
server 192.168.162.49 weight=3;
server 192.168.162.50 weight=7;
}
3 least-connected: The next request is allocated to the server with the least number of connections. When some requests take longer to respond, the least connections can more fairly control the load of application instances. Nginx forwards the request to the less loaded server.
Upstream servergroup {
least_conn;
server srv1.demo.com;
server srv2.demo.com;
server srv3.demo.com;
}
4 ip-hash: Client-based IP address. When load balancing occurs, each request is relocated to one of the server clusters. Users who have logged in to one server then relocate to another server and their login information is lost. This is obviously not appropriate. Use ip_hash to solve this problem. If the client has accessed a server, when the user accesses it again, the request will be automatically located to the server through a hash algorithm.
Each request is assigned according to the result of the IP hash, so the request is fixed to a certain back-end server, and it can also solve the session problem
upstream server group {
ip-hash;
server srv1.demo.com;
server srv2.demo.com;
server srv3. Demo.com;
}
Attach an instance:
#user nobody;
worker_processes 4;
events {
# maximum number of concurrent
workers_connections 1024;
}
http{
# The list of pending servers to be followed by the
upstream myserver{
# ip_hash instruction to bring the same user to the same server.
Ip_hash;
server 125.219.42.4 fail_timeout=60s; tentative time after the failure of #max_fails 60s
server 172.31.2.183;
}
Server{
# listening port
listen 80;
# root
location / /
# select which server list
proxy_pass http://myserver;
}
}
}
Max_fails allows the number of request failures to default to 1
fail_timeout=60s fail_timeout=60s timeout for failed timeouts
down indicates that the current server is not participating in the loadbackup. All nonbackup
machines will request backups when they are busy, so their stress will be lightest.
Recent Comments