Shulou(Shulou.com)06/01 Report--

This article mainly introduces Tengine how to add nginx upstream module, has a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, the following let the editor take you to understand it.

Back-end long connection timeout function

The ngx_http_upstream_keepalive_module module adds timeout support for nginx back-end long connections:

Upstream backend {server 127.0.0.1 keepalive 8080; keepalive 32; keepalive_timeout 30s; # set the maximum idle time for backend connections to 30s}

1) keepalive_timeout

Syntax: keepalive_timeout timeDefault:-Context: upstream

This instruction sets the maximum idle timeout of the back-end long connection. The time unit of the parameter can be s (seconds), ms (milliseconds), m (minutes). The default time unit is seconds.

Health check module function

Ngx_http_upstream_check_module, which provides Tengine with the function of active back-end server health check. This module is not enabled by default before the Tengine-1.4.0 version, and it can be turned on when configuring compilation options:. / configure-with-http_upstream_check_module.

1) check

Syntax: check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true | false] [type=tcp | http | ssl_hello | mysql | ajp] [port=check_port] Default: interval=30000 fall=5 rise=2 timeout=1000 default_down=true type=tcpContext: upstream this directive can turn on the health check function of the backend server. The parameter meaning after the directive is: interval: the interval between health check packets sent to the backend. Fall (fall_count): if the number of consecutive failures reaches fall_count, the server is considered down. Rise (rise_count): if the number of successive successes reaches rise_count, the server is considered up. Timeout: the timeout of the backend health request. Default_down: set the initial state of the server. If it is true, it means it is down by default, and if it is false, it is up. The default value is true, which means that the server is considered unavailable at first and will not be considered healthy until the health check package has reached a certain number of successes. Type: the type of health check package. Many types of tcp are now supported: simple tcp connection. If the connection is successful, the backend is normal. Ssl_hello: sends an initial SSL hello packet and accepts the server's SSL hello packet. Http: send a HTTP request to determine whether the backend is alive by the status of the reply packet at the backend. Mysql: connect to the mysql server and determine whether the backend is alive by receiving the server's greeting packet. Ajp: send the Cping packet of AJP protocol to the backend, and determine whether the backend is alive by receiving the Cpong packet. Port: specify the check port of the backend server. You can specify the port of the back-end server that is different from the real service, for example, the back-end provides port 443 applications, you can check the status of port 80 to determine the health status of the back-end. The default is 0, which is the same as the port on which the back-end server provides real services. This option appears in Tengine-1.4.0.

2) check_keepalive_requests

Syntax: check_keepalive_requests request_numDefault: 1Context: upstream

This directive can configure the number of requests sent by a connection, with a default value of 1, which means that Tengine closes the connection after completing one request.

3) check_http_send

Syntax: check_http_send http_packetDefault: "GET / HTTP/1.0" Context: upstream

This directive configures the content of the request sent by the http health check package. In order to reduce the amount of data transmitted, the "HEAD" method is recommended. When using a long connection for health check, you need to add a keep-alive request header to the directive, such as "HEAD / HTTP/1.1\ r\ nConnection: keep-alive\ r\ n\ n". At the same time, in the case of "GET" method, the size of the request uri should not be too large to ensure that the transmission can be completed within 1 interval, otherwise it will be regarded as a back-end server or network exception by the health check module.

4) check_http_expect_alive

Syntax: check_http_expect_alive [http_2xx | http_3xx | http_4xx | http_5xx] Default: http_2xx | http_3xxContext: upstream

This directive specifies the successful status of the HTTP reply, which defaults to the healthy status of 2XX and 3XX.

5) check_shm_size

Syntax: check_shm_size sizeDefault: 1MContext: http

All back-end server health check status is stored in shared memory, and this instruction sets the size of shared memory. The default is 1m, and if you have more than 1000 servers and make errors in configuration, you may need to expand the size of the memory.

6) check_status

Syntax: check_status [html | csv | json] Default: check_status htmlContext: location

Displays the health status page of the server. This directive needs to be configured in the http block. After Tengine-1.4.0, you can configure the format of the display page. Supported formats are: html, csv, json. The default type is html. You can also specify the format through the requested parameters. Suppose'/ status' is the URL of your status page, and the format parameter changes the format of the page, for example:

/ status?format=html/status?format=csv/status?format=json

You can also use the status parameter to get a list of the same server status, such as:

/ status?format=html&status=down/status?format=csv&status=up

Here is an example of a HTML status page (server number is the number of back-end servers and generation is the number of Nginx reload. Index is the index of the server, Upstream is the name of the upstream in the configuration, Name is the status of the server IP,Status, Rise is the number of consecutive successful checks of the server, Fall is the number of consecutive failed checks, Check type is the check method, and Check port is the port set by the backend specifically for health check):

Here is an example of a page in csv format:

0,backend,106.187.48.116:80,up,46,0,http,80

Here is an example of a page in json format:

{"servers": {"total": 1, "generation": 3, "server": [{"index": 0, "upstream": "backend", "name": "106.187.48.116index 80", "status": "up", "rise": 58, "fall": 0, "type": "http", "port": 80}]}}

Examples of enhanced upstream usage:

Http {# simple round-robin server 192.168.0.1 simple round-robin server 80; server 192.168.0.2 server 80; check interval=3000 rise=2 fall=5 timeout=1000 type=http; check_http_send "HEAD / HTTP/1.0"; check_http_expect_alive http_2xx http_3xx;} upstream cluster2 {# simple round-robin server 192.168.0.3 Server 192.168.0.4 HEAD 80; check interval=3000 rise=2 fall=5 timeout=1000 type=http; check_keepalive_requests 100; check_http_send "HEAD / HTTP/1.1 Connection: keep-alive"; check_http_expect_alive http_2xx http_3xx;} server {listen 80; location / 1 {proxy_pass http://cluster1; } location / 2 {proxy_pass http://cluster2;} location / status {check_status; access_log off; allow SOME.IP.ADD.RESS; deny all;}

Upstream domain name resolution module function

Ngx_http_upstream_dynamic_module, this module provides the function of dynamically parsing server domain names in upstream at run time, but it is not often used. Dynamic_resolveSyntax: dynamic_resolve [fallback=stale | next | shutdown] [fail_timeout=time] Default:-Context: upstream.

Specifies that the dynamic domain name resolution feature is enabled in a upstream, and the fallback parameter specifies the action to be taken when the domain name cannot be resolved:

Stale, use the old address next obtained when tengine is started, select the next servershutdown in upstream, and end the current request fail_timeout parameter specifies the time during which the DNS service is regarded as unavailable, that is, when a DNS request fails, it is assumed that the DNS service is still unavailable for a subsequent period of time, so as to reduce queries for invalid DNS. Upstream backend {dynamic_resolve fallback=stale fail_timeout=30s; server a.com; server b.com;}

Limit upstream tries function

Limit upstream retries, which limits the maximum number of attempts per request to access the back-end server, and supports proxy, memcached, fastcgi, scgi and uwsgi modules. You can limit the number of visits by using the following instruction.

# limit the number of backend attempts of fastcgi Agent fastcgi_upstream_tries num # limit the number of backend attempts of proxy Agent proxy_upstream_tries num # limit the number of backend attempts of memcached Agent memcached_upstream_tries num # limit the number of backend attempts of scgi Agent scgi_upstream_tries num # limit the number of backend attempts of uwsgi Agent uwsgi_upstream_tries num Thank you for reading this article carefully I hope the article "how to add nginx upstream Module to Tengine" shared by the editor will be helpful to you. At the same time, I also hope that you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.