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

The following brings you to increase the sticky session module to support problem-solving and answer questions, hoping to bring some help to you in practical application. Load balancing involves more things, not many theories, and there are many books on the Internet. Today, we will use the accumulated experience in the industry to do an answer.

Everyone's website will inevitably encounter the issue of CAPTCHA, foreground and backstage login, all need to have CAPTCHA to do login verification.

Because the verification codes of some applications are generated in the system cache, if you use load balancer, it may be the same as mine: when verifying the verification code, load balancer plays a role, and the page visited by users can not be verified successfully because the page accessed by users is redirected between two CVMs, so you need to do sticky session support in load balancer to solve this problem.

So I'm going to deal with this problem.

Installation environment and software version:

Operating system version: CentOS 7.2 64bit

Load balancing layer: nginx-1.10.1

Service layer: Tomcat 7.0.72

Nginx-sticky-module version: 1.1

Because I have compiled and used nginx in the load balancing layer before, to add sticky session, I need to install a plug-in that supports sticky sessions on Nginx.

We can see Nginx plus's support for application modules on the official website, but it doesn't seem to be available for the open source free version of nginx, so let's first download the plug-ins supported by third parties.

1. Download address:

Https://nginx-sticky-module.googlecode.com/files/nginx-sticky-module-1.1.tar.gz

It is found that the latest nginx-sticky-module-1.1.tar.gz in nginx-sticky-module is also released in 2012, and there has been no new version since then, so just choose the latest version. Nginx-sticky-module-1.0.tar.gz no longer seems to support it, and version 1.1 adds weight parameters.

two。 Put the downloaded installation package in the location you want to place to extract it:

I'll just put it in the usual location / data0/soft/, and unzip it:

[root@soft] # tar-xf nginx-sticky-module-1.1.tar.gz

Some preparatory work needs to be done in / data0/soft/nginx-sticky-module-1.1, otherwise an error will be reported when compiling nginx later.

In order to clearly understand that you see the error message, you can check the compilation nginx directly, and you can also deal with it later. So to make it easier to understand the errors, I compiled them directly.

3. Install the sticky module on nginx

If you, like me, have installed nginx before, and do not remember which modules have been installed, but do not want to affect the original modules, there is a command that can help you.

Is to go to the sbin of the nginx directory where your current system is running and use. / nginx-V to view the history instructions that have been used when compiling

[root@~] # / data0/work/nginx/sbin/nginx-V

Nginx version: nginx/1.10.1

Built by gcc 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC)

Built with OpenSSL 1.0.1e-fips 11 Feb 2013

TLS SNI support enabled

Configure arguments:

-- prefix=/data0/work/nginx

-- pid-path=/data0/work/nginx/logs/nginx.pid

-- lock-path=/var/lock/nginx.lock

-- user=nginx

-- group=nginx

-- with-http_ssl_module

-- with-http_flv_module

-- with-http_stub_status_module

-- with-http_gzip_static_module

-- http-client-body-temp-path=/var/tmp/nginx/client/

-- http-proxy-temp-path=/var/tmp/nginx/proxy/

-- http-fastcgi-temp-path=/var/tmp/nginx/fcgi/

-- http-uwsgi-temp-path=/var/tmp/nginx/uwsgi

-- http-scgi-temp-path=/var/tmp/nginx/scgi

-- with-pcre

-- add-module=/data0/soft/nginx_upstream_check_module-master/

Then go to the nginx source package that you need to install, and refer to the original compilation statement, as long as you add the sticky session module-add-module=/data0/soft/nginx-sticky-module-1.1/ at the end

[root@~] # cd / data0/work/nginx-1.10.1

[root@nginx-1.10.1] #. / configure-prefix=/data0/work/nginx

-- pid-path=/data0/work/nginx/logs/nginx.pid

-- lock-path=/var/lock/nginx.lock

-user=nginx-group=nginx

-with-http_ssl_module-with-http_flv_module

-- with-http_stub_status_module

-- with-http_gzip_static_module

-- http-client-body-temp-path=/var/tmp/nginx/client/

-- http-proxy-temp-path=/var/tmp/nginx/proxy/

-- http-fastcgi-temp-path=/var/tmp/nginx/fcgi/

-- http-uwsgi-temp-path=/var/tmp/nginx/uwsgi

-- http-scgi-temp-path=/var/tmp/nginx/scgi

-- with-pcre

-- add-module=/data0/soft/nginx_upstream_check_module-master/

-- add-module=/data0/soft/nginx-sticky-module-1.1/

Followed by make compilation

[root@nginx-1.10.1] # make & & make install

It was found that the report was wrong:

Cc1: all warnings being treated as errors

Make [1]: * * [objs/addon/nginx-sticky-module-1.1/ngx_http_sticky_module.o] Error 1

Make [1]: Leaving directory `/ data0/work/nginx-1.10.1'

Make: * * [build] Error 2

How to handle it:

a. According to the data, the problem can be solved by modifying the 281 lines of ngx_http_sticky_misc.c as follows.

[root@~] vim / data0/soft/nginx-sticky-module-1.1/ngx_http_sticky_misc.c

Digest- > len = ngx_sock_ntop (in, digest- > data, len, 1)

Original digest- > len = ngx_sock_ntop (in,digest

-> data, len, 1)

Modified digest- > len = ngx_sock_ntop (in,sizeof (struct sockaddr_in), digest

-> data, len, 1)

b. Also modify line 322 of ngx_http_sticky_module.c as follows to solve the problem.

[root@~] vim / data0/soft/nginx-sticky-module-1.1/ngx_http_sticky_module.c

332 # if defined (nginx_version) & & nginx_version > = 1009000-add

333 iphp- > rrp.current = peer;-plus

334 # else-add

335 iphp- > rrp.current = iphp- > selected_peer;-original content

336 # endif-add

Note: actually find iphp- > rrp.current = iphp- > selected_peer; to add content before and after it.

Then proceed with make&& make install compilation.

[root@nginx-1.10.1] # make & & make install

4. Configure and enable the sticky module function in the configuration document of nginx

Because I compile and install on the original basis, and do not change the version upgrade, install directly, so the original nginx.conf configuration file will not be overwritten, but the nginx execution file will regenerate a

So how does nginx's upstream use sticky? it's very simple, as follows:

[root@~] # vim / data0/work/nginx/conf/nginx.conf

Find the upstream module to add sticky

Upstream information {

Sticky

Server 172.16.22.3:80 max_fails=2

Server 172.16.22.4:80 max_fails=2

Check interval=3000 rise=2 fall=5 timeout=1000 type=http

}

Note: sticky; is set for-- sticky module

Check interval=3000 rise=2 fall=5 timeout=1000 type=http; is used for upstream backend health check. The added module is nginx_upstream_check_module-master.

Of course, you haven't installed the nginx_upstream_check_module-master module, so you can comment out this setting first. Wait until there is a need to open it later.

Instructions for the use of other syntax in 5.nginx sticky

Sticky [name=route] [domain=.foo.bar] [path=/] [expires=1h] [hash=index | md5 | sha1] [no_fallback]

Name: can be any string character, default is route

Domain: which domain names can use this cookie?

Path: which paths enable sticky, such as path/test, then only the test directory will use sticky for load balancing

When the expires:cookie expires, the default browser expires when it is closed, that is, the session mode.

No_fallbackup: if this is set and the server corresponding to cookie fails, it will return 502 (bad gateway or proxy error). It is not recommended to enable it.

Nginx sticky expires usage:

Upstream information {

Sticky expires=1h

Server 172.16.22.3:80 max_fails=2

Server 172.16.22.4:80 max_fails=2

}

Expiration is enabled. Cookie takes 1 hour to expire.

6. After the above settings, you can check whether the problem in stitcky session has been solved successfully.

# Note: the tomcat servers mentioned below are clustered (that is, under the premise of session sharing)

a. Restart the nginx service

First test whether the configuration file is accurate

[root@~] # / data0/work/nginx/sbin/nginx-t

Nginx: the configuration file / data0/work/nginx/conf/nginx.conf syntax is ok

Nginx: configuration file / data0/work/nginx/conf/nginx.conf test is successful

# if there is a problem, please follow the prompts it gives to find and modify it

Restart the nginx service

[root@~] # / data0/work/nginx/sbin/nginx-s reload

b. For ease of viewing, let's set it on the two tomcat services at the back end.

Because I have two tomcat servers at the back end, the JESSIONED value of each server has a special flag.

So on both of my back-end Tomcat servers, I made some preparations to make it easier for me to identify and visit the load balancing layer through the browser to see which machine is actually providing the service.

Please do the following on your tomcat server:

[root@~] # vim / data0/work/tomcat01/conf/server.xml

Find line 103 inside.

Uncomment and modify it to read as follows:

# Note: in order to identify, I will change jvmRoute to Tomcat01, and the same Tomcat02 server does the same, except that jvmRoute is set to Tomcat02

Place an index.jsp page in the release document of the tomcat server with the following content:

[root@~] # vim / data0/work/tomcat01/webapps/ROOT/jsp/index.jsp

Tomcat01

Session serviced by tomcat

Session ID

Created on

However, the tomcat02 server does the same thing, only replacing tomcat01 in the index.jsp page with tomcat02

c. For example, 172.16.22.3 this one is tomcat01172.16.22.4 and this one is tomcat02. When you visit a http://172.16.22.2/index.jsp page, no matter how you refresh the page before opening the sticky session module, the JESSIONED value will remain the same, but the hosted tomcat will change alternately.

As shown in the following figure:

To undertake services on tomcat01:

After refreshing the page, it is found that the service is accepted on tomcat02, and the session ID remains unchanged.

But if the Nginx configuration file opens the sticky module, we can see that the JESSIONED value will not change. But no matter how much you refresh it, it sticks to one of the tomcat servers.

After reading the above question and answer about adding sticky session module to support problem solving, if you have anything else you need to know, you can find what you are interested in in the industry information or find our professional technical engineer to answer, the technical engineer has more than ten years of experience in the industry.

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.