Nginx的反向代理及负载均衡

标签：Nginx

    简单来说，集群就是指一组相互独立的计算机，利用高速通信网络组成的一个较大的计算机服务系统，每个集群节点都是运行各自服务的独立服务器。这些服务器之间可以彼此通信，协同向用户提供应用程序、系统资源和数据，并以单一系统的模式加以管理。当用户客户机请求集群系统时，集群给用户的感觉就是一个单一的服务器，而实际上用户请求的是一组集群服务器。

    集群主要包括几大特点：高性能、价格有效性、可伸缩性、高可用性、透明性、可管理性和可编程性。

2.负载均衡集群

    常见的负载均衡的架构包括有负载均衡集群、高可用性集群、高性能计算集群等等。这里着重介绍负载均衡集群，其他的集群方式不做介绍。

    负载均衡集群为企业提供了更为实用、性价比更高的系统架构解决方案。负载集群可以把很多客户集中的访问请求负载压力尽可能平均分摊到计算机集群中处理。客户访问请求负载均衡通常包含应用程序处理负载均衡和网络流量负载。这样的系统非常适合使用同一组应用程序为大量用户提供服务的模式，每个节点都可以承当一定的访问请求负载压力，并且可以实现访问请求在各节点之间动态分配，以实现负载均衡。

    负载均衡集群运行时，一般是通过一个或多个前端负载均衡器将客户访问请求分发到后端的一组服务器上，从而达到整个系统的高性能和高可用性。一般高可用性集群和负载均衡集群使用类似的技术，或同事具有高可用与负载均衡的特点。负载均衡的作用为：分担用户访问及数据流量、保持业务的连续性、应用于Web业务及数据库从库等服务器的业务。

3.Nginx负载均衡集群介绍

    互联网企业中常见的开源集群软件有：Nginx、LVS、Haproxy、Keepalived等，硬件有F5、Netscaler等。

    严格地说，Nginx仅仅是作为Nginx Proxy反向代理使用的，因为反向代理功能表现的效果是负载均衡集群的效果，所以也叫做Nginx负载均衡。反向代理和负载均衡的区别在于负载均衡通常都是对请求的数据包的转发（也有可能会改写数据包）、传递，其中DR模式明显的特征就是从负载均衡下面的节点服务器来看，接收到的请求还是来自负载均衡器的客户端的真实用户。而反向代理，反向代理接收访问用户的请求后，会代理用户重新发起请求代理下的节点服务器，最后把数据返回给客户端用户。在节点服务器来看，访问节点服务器的客户端用户是反向代理服务器，而不是真实的网站访问用户。

    Nginx负载均衡的模块主要有两个，ngx_http_proxy_module,ngx_http_upstream_module。编译的时候需要把这两个模块编译进去。

4.Nginx负载均衡的配置

    本次实验的图解如下，很基础的一个负载均衡实验。负载均衡的高可用性以后再说。Nginx负载均衡器接收到请求后会把数据分发到后端的web01和web02服务器上，web01、web02上已经搭建了Nginx服务，并且搭建了两个虚拟主机www和bbs。

    （1）配置Web01和Web02服务器，搭建虚拟主机

    Web01和Web02的配置如下，nginx.conf文件。可以参见之前的博客。

worker_processes  1;
error_log logs/error.log;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
	server_tokens off;    #这个是关闭nginx版本号
	client_max_body_size 8m;    #限制上传文件的大小
	log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
	                  '$status $body_bytes_sent "$http_referer" '
					  '"$http_user_agent" "$http_x_forwarded_for"';
					  
	include extra/www.conf;
	include extra/bbs.conf;

}

    Web02的文件参数也一样，语法检查没有问题之后重新加载nginx的配置文件

/usr/local/nginx/sbin/nginx -t
/usr/local/nginx/sbin/nginx -s reload

    填充测试文件,以web01为例，web02也同理

echo "这是www站点,IP地址为：192.168.31.10" >/usr/local/nginx/html/www/index.html
echo "这是bbs站点,IP地址为：192.168.31.10" >/usr/local/nginx/html/bbs/index.html

    修改hosts文件，最后在web01和web02本机上测试，得出的结果如下。

    （2）在Nginx负载均衡服务器上安装Nginx服务

./configure --prefix=/usr/local/nginx-1.12.2 --user=nginx --group=nginx --with-http_stub_status_module --with-http_ssl_module
make
make install

    （3）修改nginx.conf配置文件如下，加入web、bbs地址池，然后启用

worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
	upstream www_server_pools {
		server 192.168.31.10:80 weight=1;
		server 192.168.31.11:80 weight=1;
	}
	upstream bbs_server_pools {
		server 192.168.31.10:80 weight=1;
		server 192.168.31.11:80 weight=1;
   }
   server {
        listen       80;
        server_name  www.pcm.com;
        location / {
			proxy_pass http://www_server_pools;
        }
	}
    server {
        listen       80;
        server_name  bbs.pcm.com;
        location / {
			proxy_pass http://bbs_server_pools;
        }
	}
    
}

    （4）检查语法没有问题之后，重新加载nginx.conf文件。

/usr/local/nginx/sbin/nginx -t
/usr/local/nginx/sbin/nginx -s reload

    （5）修改hosts文件

    （6）检验效果,从结果上我们看到设置的负载均衡已经起效了，按照权重轮询分发数据包。但是设置的bbs虚拟主机的负载均衡不起效，同样给到了www虚拟主机去处理了。

    （7）增加proxy_set_header字段，实现虚拟主机的访问。上面出错的原因在于：虽然用户访问了带www,bbs这些主机头请求nginx反向代理服务器，但是反向代理服务器向下面的节点重新发出请求时，默认没有在请求头里告诉节点服务器要找哪台虚拟主机。所以，web节点服务器接收到信息后发现没有主机头信息，因此，就把节点服务器的第一个虚拟主机发给了反向代理了。解决这个问题的办法就是当反向代理服务器重新发起请求时，要携带主机头信息，以明确告诉节点服务器要找哪个主机。具体的配置很简单，就在Nginx代理www和bbs服务虚拟主机配置里面增加一行

proxy_set_header Host $host;

    重新加载Nginx服务后，用curl检查，发现成功了。

    （8）增加节点服务器记录的IP字段。

    默认情况下，节点服务器只能记录到反向代理服务器的IP地址，而记录不到请求客户端真实的IP地址。原因就是前面说到的反向代理和负载均衡的一个明显的区别，要让下面的节点服务器能记录客户端的IP，那就需要让反向代理服务器发出请求的时候带上客户端的IP信息。配置也很简单，只需要加上一个字段即可：

 proxy_set_header X-Forwarded-For $remote_addr;

    检查语法之后重新加载nginx服务，然后用浏览器访问，到节点服务器上看到对应的日志信息：

    PS:有这个日志信息的前提是，节点服务器的nginx.conf配置的日志信息和前面的一致。到这里，基本就配置完成了。

Nginx的反向代理及负载均衡

标签：Nginx

原文地址：http://blog.51cto.com/superpcm/2095324