Build Nginx and Tomcat servers under Debian to achieve load balancing schemes _nginx

Basic concepts of load balancing

Load balancing is a computer network technology used to distribute loads across multiple computers (computer clusters), network connections, CPUs, disk drives, or other resources to achieve optimal resource usage, maximize throughput, minimize response time, and avoid overloading. Balancing

Using multiple server components with load Balancing to replace a single component can improve reliability through redundancy. Load-balancing services are typically done by specialized software and hardware.

One of the most important applications of load balancing is the use of multiple servers to provide a single service, a scenario sometimes called a server farm. Typically, load balancing is primarily applied to Web sites, large Internet Relay chat networks, high volume file download sites, NNTP (network News Transfer Protocol) services, and DNS services. Now the load balancer is also starting to support database services, called the database load balancer.

For Internet services, load balancer is usually a software program, this program listens to an external port, the Internet user can access the service through this port, and as the software of load Balancer forwards the user's request to the backend intranet server, the intranet server returns the request response to the load balancer, The load balancer then sends the response to the user, which hides the intranet structure from the Internet user, prevents the user from accessing the backend (intranet) server directly, makes the server more secure, and can block attacks on the core network stack and the service running on other ports.

When all backend servers fail, some load balancers provide special features to handle this situation. such as forwarding requests to an alternate load balancer, displaying a message about a service outage, and so on. Load balancers enable IT teams to significantly improve fault tolerance. It can automatically provide a large amount of capacity to handle any increase or decrease in application traffic.

Let's take a look at how to build a NGINX+TOMCAT server portfolio with load balancing capabilities:

0. Preliminary preparation

Use a Debian environment. Install Nginx (default installation), a Web project, install Tomcat (default installation), and so on.

1. A copy of the nginx.conf configuration file

# define users and groups that nginx run if the corresponding server is exposed, it is recommended that users with lesser privileges be protected from intrusion # user www www;
#Nginx进程数, the recommended setting is equal to the total CPU core number worker_processes 8;
#开启全局错误日志类型 Error_log/var/log/nginx/error.log Info;
#进程文件 Pid/var/run/nginx.pid;
#一个Nginx进程打开的最多文件描述数目 recommendations are consistent with Ulimit-n #如果面对高并发时 Note that modifying the value Ulimit-n also has some system parameters rather than this individually determined worker_rlimit_nofile 65535;
 events{#使用epoll模型提高性能 use Epoll;
#单个进程最大连接数 worker_connections 65535;
 } http{#扩展名与文件类型映射表 include mime.types;
 #默认类型 Default_type Application/octet-stream;
 Sendfile on;
 Tcp_nopush on;
 Tcp_nodelay on;
 Keepalive_timeout 65;
 Types_hash_max_size 2048;
 #日志 Access_log/var/log/nginx/access.log;
 Error_log/var/log/nginx/error.log;
 #gzip compressed transport gzip on; Gzip_min_length 1k;
 #最小1K gzip_buffers 64K;
 Gzip_http_version 1.1;
 Gzip_comp_level 6;
 Gzip_types text/plain application/x-javascript text/css application/xml application/javascript;
 Gzip_vary on;
 #负载均衡组 #静态服务器组 upstream static.zh-jieli.com {server 127.0.0.1:808 weight=1; } #动态服务器组 upstream zh-jieli.com {sErver 127.0.0.1:8080;
 #server 192.168.8.203:8080;
 } #配置代理参数 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_max_body_size 10m;
 Client_body_buffer_size 128k;
 Proxy_connect_timeout 65;
 Proxy_send_timeout 65;
 Proxy_read_timeout 65;
 Proxy_buffer_size 4k;
 Proxy_buffers 4 32k;
 Proxy_busy_buffers_size 64k;
 #缓存配置 Proxy_cache_key ' $host: $server _port$request_uri ';
 Proxy_temp_file_write_size 64k;
 Proxy_temp_path/dev/shm/jielierp/proxy_temp_path;
 Proxy_cache_path/dev/shm/jielierp/proxy_cache_path levels=1:2 keys_zone=cache_one:200m inactive=5d max_size=1g;
Proxy_ignore_headers x-accel-expires Expires Cache-control Set-cookie;
 server{Listen 80;
 server_name erp.zh-jieli.com;
 Location/{index index; #默认主页为/index #proxy_pass Http://jieli; } location ~. *\. (Js|css|ico|png|jpg|eot|svg|ttf|woff)
 {Proxy_cache cache_one;
 Proxy_cache_valid 304 302 5d; Proxy_Cache_valid any 5d;
 Proxy_cache_key ' $host: $server _port$request_uri ';
 Add_header X-cache ' $upstream _cache_status from $host ';
 Proxy_pass http://static.zh-jieli.com;
 #所有静态文件直接读取硬盘 # root/var/lib/tomcat7/webapps/jielierp/web-inf; Expires 30d;
 #缓存30天} #其他页面反向代理到tomcat容器 Location ~ *$ {Index index;
 Proxy_pass http://zh-jieli.com;
 } server{Listen 808;
 server_name static; Location/{} location ~ *\. (Js|css|ico|png|jpg|eot|svg|ttf|woff)
 {#所有静态文件直接读取硬盘 root/var/lib/tomcat7/webapps/jielierp/web-inf; Expires 30d;
 #缓存30天}}}

The basic configuration of this file, you can implement the load. But it is more troublesome to understand the various relationships inside.

2. Basic explanation

Now if there is a computer 192.168.8.203 this computer, the above deployed Tomcat, inside 8080 ports have Java-EE services, through the browser can be normal browsing Web pages. Now there's a problem. Tomcat is a more comprehensive web container, the processing of static Web pages, should be relatively cost resources, especially every time to read from the disk static page, and then return. This consumes tomcat resources, and may cause those dynamic pages to resolve performance effects. Uphold the philosophy of Linux, a software to do only one thing principle. Tomcat should only process JSP dynamic pages. Here we use the previously known nginx to reverse the proxy. The first step of the proxy, the implementation of static and Dynamic Web page separation. This is very simple.

Worker_processes 8;
 
 Pid/var/run/nginx.pid;
 
 Worker_rlimit_nofile 65535;
 events{use Epoll;
 Worker_connections 65535;
 } http{include mime.types;
 Default_type Application/octet-stream;
 Sendfile on;
 Tcp_nopush on;
 Tcp_nodelay on;
 Keepalive_timeout 65;
Types_hash_max_size 2048;
 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_max_body_size 10m;
 Client_body_buffer_size 128k;
 Proxy_connect_timeout 65;
 Proxy_send_timeout 65;
 Proxy_read_timeout 65;
 Proxy_buffer_size 4k;
 Proxy_buffers 4 32k;
 
 Proxy_busy_buffers_size 64k;
 server{Listen 80;
 server_name xxx.com; 
 Location/{index index; } location ~. *\. (Js|css|ico|png|jpg|eot|svg|ttf|woff)
 {Proxy_pass http://192.168.8.203:8080; 
 Expires 30d;
 } location ~. *$ {index index;
 Proxy_pass http://192.168.8.203:8080;
}} worker_processes 8;
Pid/var/run/nginx.pid; Worker_rlimit_nofile 65535;
 events{use Epoll;
 Worker_connections 65535;
 } http{include mime.types;
 Default_type Application/octet-stream;
 Sendfile on;
 Tcp_nopush on;
 Tcp_nodelay on;
 Keepalive_timeout 65;
Types_hash_max_size 2048;
 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_max_body_size 10m;
 Client_body_buffer_size 128k;
 Proxy_connect_timeout 65;
 Proxy_send_timeout 65;
 Proxy_read_timeout 65;
 Proxy_buffer_size 4k;
 Proxy_buffers 4 32k;
Proxy_busy_buffers_size 64k;
 server{Listen 80;
 server_name xxx.com;
 Location/{index index; } location ~. *\. (Js|css|ico|png|jpg|eot|svg|ttf|woff)
 {Proxy_pass http://192.168.8.203:8080;
 Expires 30d;
 } location ~. *$ {index index;
 Proxy_pass http://192.168.8.203:8080;

 }
 }
 }

Modifying the Nginx profile/etc/nginx/nginx.conf default to have a configuration file. In fact, most of the same, the key or Server section settings. Here I set the server section as shown above, and the other segments are replicated. The explanation in the server section is as follows: The 35th behavior listens on native 80 ports. Line 37-39 represents the default home page, where the default home page I am index.jsp corresponds to a index in my project. This can be changed to

Index index.jsp index.html index.htm index.php

Refer to other articles in detail. The key 40th line, this is a regular match, there are a lot of introductions on the Internet. This matches all of the static page suffixes used in my project. Line 41st is the proxy address. Here I am acting on my web application. Expires 30d Cache is 30 days, where the cache corresponds to the front page, the user's Cache-control field,

The positive in line 44th is the page that matches the suffix. The JSP page in my project is no suffix. This can be modified as needed. The same agent to 192.168.8.203:8080 here. Here you may ask, I 艹, this has Mao meaning ah? Of course not. Simple to achieve static and dynamic separation, we can modify the 41st line, instead

Root  /var/lib/tomcat7/webapps/jielierp/web-inf

Means no proxy, take directly from the local disk. You can see that the static page is not accessible by looking up the Tomcat log. But there is another problem. This kind of flexibility is not good enough for the memory cache and cluster deployments that are described below, so this is the way it goes. Write one more Server section.

server{
 Listen 808;
 server_name static;
 Location/{
}
location ~ *\. ( Js|css|ico|png|jpg|eot|svg|ttf|woff) {
 #所有静态文件直接读取硬盘
 root/var/lib/tomcat7/webapps/jielierp/web-inf;
 Expires 30d; #缓存30天
 }
 }

This time listening to the 808 port, and then the above code 41 lines can be modified for Proxy_pass http://192.168.8.203:808, and here is the realization of static and dynamic separation. If more than one server, it is OK to modify the corresponding IP. If you find that the connection is not on, check the firewall, permissions, and other external issues, this configuration is the case.

If this is the case, we will find that the direct transmission of the page is too bandwidth consuming. corresponding to the optimization of the web, here is the idea of the page by gzip compression, and then uploaded to the user there, and then decompression, which can effectively reduce the bandwidth. The Nginx gzip module is used here. The default nginx is integrated with the Gzip module. Simply add the following configuration to the HTTP segment.

gzip on;
 Gzip_min_length 1k; #最小1K
 gzip_buffers 64K;
 Gzip_http_version 1.1;
 Gzip_comp_level 6;
 Gzip_types text/plain application/x-javascript text/css application/xml application/javascript;
 Gzip_vary on;

Give a home page to see the effect

Do not care about the number of requests are not the same, the two requests are Google Plug-ins to. Don't think I'm lying to you.

Caching must be something important to a site that many people visit. The beginning is to pass the plug-in, let Nginx and Redis for synthesis, and then Nginx use Redis to cache, but found configuration is very troublesome, but also to download their own plug-ins, recompile nginx, more trouble, so here feel the cache with the Nginx is also a good choice. Although the efficiency is not as good as redis, but there is still better than No. Nginx The default cache is a disk file system cache, not a memory-level cache like Redis. At first I thought Nginx was the only way. Later, I looked up the data to know that I was too naïve, not very understanding of Linux caused. Linux is all about files. Originally we can cache the file to the memory of the corresponding Linux file system. I said may be more difficult to understand, please search/dev/shm this file directory. We cache the files in this file directory, which is actually quite the same as the memory cache. It's just a file system management. So the memory cache is not as redis as the custom format.

Basic configuration in HTTP segment

#缓存配置
proxy_cache_key ' $host: $server _port$request_uri ';
Proxy_temp_file_write_size 64k;
Proxy_temp_path/dev/shm/jielierp/proxy_temp_path;
Proxy_cache_path/dev/shm/jielierp/proxy_cache_path levels=1:2 keys_zone=cache_one:200m inactive=5d max_size=1g;
Proxy_ignore_headers x-accel-expires Expires Cache-control Set-cookie;

Location ~. *\. (Js|css|ico|png|jpg|eot|svg|ttf|woff) {
 Proxy_cache cache_one;
 Proxy_cache_valid 304 302 5d;
 Proxy_cache_valid any 5d;
 Proxy_cache_key ' $host: $server _port$request_uri ';
 Add_header X-cache ' $upstream _cache_status from $host ';
 Proxy_pass http:
//192.168.8.203:808;
Expires 30d; #缓存30天
 }

After these two configuration will basically be achieved, here to say a few attention items, but also bothered me for a long time. Line 6th of the first code above, proxy_ignore_headers if the HTML head in the Web project

<meta http-equiv= "Pragma" content= "No-cache" >
<meta http-equiv= "Cache-control" content= "No-cache" >
<meta http-equiv= "expires" content= "0" >

These are not cached, it is necessary to add proxy_ignore_headers configuration items. The other thing is/DEV/SHM. The following file system permissions are only given to root by default, so it is not safe to chmod 777-r/dev/shm, if in fact the line can be given a user group, the setting of the user group is the first line of the configuration

User www www.

The 6th line of the second paragraph of the above code is to add a header field to see if hitting the cache.

We rm-rf/dev/shm/jielierp/proxy_* all the files below (note that if you are doing multiple tests here, you will nginx-s reload the configuration or restart the service because you RM-RF just deleted the cached file. However, the structure of the cached information is still in the nginx process, the structure is still, if not restarted, it will appear inaccessible.

So remember to reboot OH. The following are the effects of the operation

First time Access

Second access, Ctrl+shift+r forced flush in browser

Here we can see the effect. Let's take a look inside the/DEV/SHM.

It's almost over by here. Finally, a key technical point is the cluster, cluster, cluster. This is going to use the upstream, see the beginning of the configuration file, is that

#负载均衡组
#静态服务器组
upstream static {
 server 127.0.0.1:808 weight=1;
 Server 192.168.8.203:808 weight=1;
}

#动态服务器组
upstream Dynamic {
 server 127.0.0.1:8080;
 #server 192.168.8.203:8080;
}

The top one is the cluster group. Upstream is the keyword, static and dynamic are the names of two server cluster groups. In the first example, the server 127.0.0.1:808 is the address of the servers and the weight=1 is the weight. There are multiple write multiple. The pro tested that one of the clusters was broken and did not affect the system running. As for more polling rules, you can refer to more information on the Internet. There's not much to say here. As for how to use it? Proxy_pass http://192.168.8.203:808 changed to Proxy_pass http://static; This will achieve balance.

This is the end of it. The above parts according to their own requirements can be configured to achieve a single room load balance. The above method has a disadvantage is that in front of the Nginx if the machine, the back so the machine has lost the ability to access, so need to implement a number of nginx in front of the load of multiple computer rooms. About this is another topic. There is no research yet. I'll have a chance to say it later.

Dynamic server group above if it is the kind of need to save the user state, there will be a problem, is the session problem, such as I server1 login, the next dynamic server group after polling may be assigned to SERVER2, will cause to log in again. The solution is to configure the polling rules, hash according to the IP requested by the user, and then assign the corresponding server. The specific configuration is as follows:

Upstream dynamic{
Ip_hash;
Server 127.0.0.1:8080;
Server 192.168.0.203:8080;
}

This enables a user to correspond to a server node. This will not have the problem of duplicate logons. Another radical solution is to use the caching system for unified storage management of the session.