Article From:https://www.cnblogs.com/liliuguang/p/9122555.html

If Nginx is not just a proxy for one server, it can’t be like this fire today, and Nginx can configure multiple servers and keep the system available when a server goes down. The specific configuration process is as follows:

1. Under the HTTP node, add the upstream node.

upstream linuxidc { 
      server 10.0.6.108:7080; 
      server 10.0.0.85:8980; 
}

  2.  The proxy_pass in the location node under the server node is configured as: http:// + upstream name, that is, “
http://linuxidc”.

location / { 
            root  html; 
            index  index.html index.htm; 
            proxy_pass http://linuxidc; 
}

    3.  Now the load balance is preliminarily completed. The upstream is loaded in a polling (default) manner, each of which is assigned to a different backend server in time order. If the back end server down falls, it can be removed automatically. Although this method is simple and cheap. But the drawback is: low reliabilityAnd the load distribution is not balanced. It is suitable for image server cluster and pure static page server cluster.

    In addition, upstream has other allocation strategies, which are as follows:

    weight(Weight)

    Specifies polling probability. Weight is proportional to the access ratio, and is used for uneven performance of back-end servers. As shown below, the access ratio of 10.0.0.88 is twice as high as that of 10.0.0.77.

upstream linuxidc{ 
      server 10.0.0.77 weight=5; 
      server 10.0.0.88 weight=10; 
}

    ip_hash(Access to IP)

    Each request is allocated according to the hash result of accessing IP, so that each visitor can access a back-end server with fixed access to solve the problem of session.

upstream favresin{ 
      ip_hash; 
      server 10.0.0.10:8080; 
      server 10.0.0.11:8080; 
}

    fair(Third party)

    The response time is allocated according to the response time of the back-end server, and the response time is short. It is similar to the weight allocation strategy.

 upstream favresin{      
      server 10.0.0.10:8080; 
      server 10.0.0.11:8080; 
      fair; 
}

url_hash(Third party)

The request is allocated according to the hash result of accessing URL, so that each URL is directed to the same back-end server, and the back-end server is more effective when caching.

Note: in the upstream, add hash statement, server statement can not write other parameters such as weight, hash_method is the hash algorithm used.

 upstream resinserver{ 
      server 10.0.0.10:7777; 
      server 10.0.0.11:8888; 
      hash $request_uri; 
      hash_method crc32; 
}

upstreamYou can also set the status values for each device. The meaning of these state values is as follows:

down The server in front of the list does not participate in the load for the time being.

weight By default, the larger the 1.weight, the greater the weight of the load.

max_fails :The number of times allowed to request failure is 1.. When the maximum number is exceeded, the error defined by the proxy_next_upstream module is returned.

fail_timeout : max_failsAfter the failure, the time of pause.

backup: All other non backup machines down or busy, request backup machine. So the machine will have the lightest pressure.

upstream bakend{ #Defining the Ip and device status of a load balancing device
      ip_hash; 
      server 10.0.0.11:9090 down; 
      server 10.0.0.11:8080 weight=2; 
      server 10.0.0.11:6060; 
      server 10.0.0.11:7070 backup; 
}

Similar Posts:

Leave a Reply

Your email address will not be published. Required fields are marked *