nginx集群

一、集群(Cluster)介绍

1.1.集群(Cluster)概念

1.2.集群的优点

1.3.集群的类型

1.3.集群实现的方式

1.4.负载均衡的分层结构

二、Nginx负载均衡集群

2.1.反向代理与负载均衡概念简介

2.2.nginx负载均衡核心组件介绍

2.2.1.upstream模块介绍

2.2.2.upstream模块语法

2.2.3.upstream模块调度算法

2.2.4.http_proxy_module模块

三、nginx反向代理、负载均衡案例

3.1.案例描述：

3.2.实施步骤

3.2.1.三台服务器web部署

3.2.2.nginx配置负载均衡

3.2.3.nginx配置反向代理

3.2.3.验证反向代理、负载均衡

四、反向代理多虚拟主机实现

4.1.节点服务器站点部署

4.2.反向代理多虚拟主机实现

4.3.节点服务器统计真机客户端IP地址

4.3.1.nginx代理服务器打开Forwarded模块

4.3.2.节点服务器设置日志格式

4.4.nginx实现动静分离

4.4.1.nginx代理服务器配置

4.5. Nginx负载均衡监测节点状态

一、集群(Cluster)介绍

1.1.集群(Cluster)概念

所谓集群，指一组(多台)相互独立的计算机利用高速通信网络组成的一个规模较大的计算机服务系统，每个集群节点(即集群中的一台服务器)都是运行各自服务的独立服务器。这些服务器之间相互连接，协同为用户提供应用程序、数据资源，并以单一系统的模型进行管理。当用户请求集群系统时，集群给用户的感觉就像是一台独立的服务器在为客户提供服务，而实际上处理客户请求的这个步骤是由很多台服务器共同实现的。

1.2.集群的优点

（1）高性能（Performance）

一些国家重要的计算密集型应用（如天气预报、核试验模拟等）需要计算机有很强的运算处理能力。以全世界现有的技术，即使是大型机，其计算能力也是有限的，很难单独完成此任务。因为计算时间可能会相当长，也许几天，甚至几年或更久。因此，对于这类复杂的计算业务使用了计算机集群技术，集群中有几十台、上百台，甚至成千上万台计算机协同计算。

（2）价格有效性（Cost-effectiveness）

通常一套系统集群架构，只需要几台或数十台服务器主机即可。与动辄价值上百万的专用超级计算机相比便宜了很多。在达到同样性能需求的条件下，采用计算机集群架构比采用同等运算能力的大型计算机具有更高的性价比。

（3）可伸缩性（Scalability）

当服务负载、压力增长时，针对集群系统进行较简单的扩展即可满足需求，且不会降低服务质量。

（4）高可用性（Availability）

单一的计算机系统总会面临设备损毁的问题，如CPU、内存、主板、电源、硬盘等，只要一个部件坏掉，这个计算机系统就可能会宕机，无法正常提供服务。在集群系统中，尽管部分硬件和软件也会发生故障，但整个系统的服务可以是7×24小时可用的。目前几乎100%的互联网网站都要求7×24小时提供服务的。

（5）透明性（Transparency）

多个独立计算机组成的松耦合集群系统构成一个虚拟服务器；用户或客户端程序访问集群系统时，就像访问一台高性能、高可用的服务器一样，集群中一部分服务器的上线下线不会中断整个系统服务，这对用户也是透明的。

1.3.集群的类型

LB/负载均衡（Load Balancer）集群

HA/高可用（High Available）集群

HPC/高性能运算（High Performance Computer）集群

无论哪种集群、都至少包括两台节点服务器，而且对外表现为一个整体，只提供一个访问入口(域名或IP)。

LB/负载均衡集群

以提高应用系统的响应能力、尽可能处理更多的访问请求，减少延迟为目标获得高并发、高负载的整体性能。例如，“DNS轮询”、“应用层交换”、“反向代理”等都可以用作负载均衡集群。LB的负载分配主要依赖于主节点的分流算法，将来自客户机的访问请求分担给多个服务器节点，从而缓解整个集群系统的压力。

负载均衡集群的作用如下：

❑ 分担用户访问请求及数据流量（负载均衡）。

❑ 保持业务连续性，即7×24小时服务（高可用性）。

❑ 应用于Web业务及数据库从库等服务器的业务。

负载均衡集群典型的开源软件包括LVS、Nginx、Haproxy等。

HA/高可用集群

以提高应用系统的可靠性，尽可能地减少中断时间为目标，确保服务的连续性，达到高可用的容错效果。例如“故障切换”、“双机热备”、“多机热备”等都属于高可用集群技术。HA的工作方式包括双工和主从两种模式，双工即所有节点同时上线，而主从只有主节点在线提供服务，当主节点出现问题后备接替出故障的主节点为用户提供服务。

HPC/高性能运算集群

以提高应用系统的CPU运算速度、扩展硬件资源和分析能力为目标，获得相当于大型、超级计算机的高性能运算(HPC)能力。例如“云计算”、“网格计算”也可视为高性能运算的一种。高性能运算集群的高性能依赖于“分布式运算”、“并行运算”，通过专用硬件和软件将多台服务器的CPU、内存等硬件资源整合到一起，实现只有大型、超级计算机才具备的计算能力。

在互联网网站架构中，比较常用的是负载均衡集群和高可用性集群。

1.3.集群实现的方式

在企业中一般通过软件、硬件两种方式来实现集群

企业中常用的开源集群软件有：Nginx、LVS、Haproxy、Keepalived、Heartbeat等

企业中常用的商业集群硬件有：F5、Netscaler、Radware、A10等

相比较而言，商业的负载均衡产品成本高、性能好，更稳定，缺点是不能二次开发，开源的负载均衡软件对运维人员的能力要求较高，如果运维及开发能力强，那么开源软件的负载均衡是不错的选择，目前的互联网行业更偏向使用开源的负载均衡软件。

1.4.负载均衡、高可用的分层结构

在典型的负载均衡集群中，主要包括三个层次的组件。如下图所示，前端至少有一个负载调度器(Director) 负责响应并分发来自客户机的访问请求；后端有大量独立节点服务器(Real Server)构成服务器池(Server Pool)提供实际的应用服务，整个集群的伸缩性通过增加、删除节点服务器来完成，而这些过程对客户机都是透明的；为了保持服务、数据的一致性，所有节点使用共享存储设备。

第一层，负载均衡调度器

这是访问整个集群系统的唯一入口，对外使用所有服务器的共有VIP（Virtual IP）地址，也称为集群IP地址。通常会配置主、备两台调度器实现双机热备效果，当主调度器失效后，可以平滑替换至备用调度器，从而确保高可用性。

第二层，服务器池

集群所提供的应用服务(如web、ftp等)由服务器池承担，其中每个节点具有独立的RIP(Real IP,真实IP)地址，只处理调度器分发过来的客户机请求，当某个节点暂时失效时，负载调度器的容错机制将会将其隔离，等待错误排除后再重新加入服务器池。

第三层，共享存储

为服务器池中的所有节点提供稳定、一致的文件存储服务，确保整个集群的统一性。在Linux/UNIX环境中，共享存储可以使用NAS设备，或者提供NFS(网络文件系统)共享服务的专用服务器。

二、Nginx负载均衡群集

2.1.反向代理与负载均衡概念简介

严格来说，Nginx仅仅是作为Nginx Proxy反向代理使用的，因为这个反向代理功能表现的效果是负载均衡集群的效果，所以称之为Nginx负载均衡。那么，反向代理和负载均衡有什么区别呢？

普通负载均衡软件，如大名鼎鼎的LVS，其实现的功能只是对请求数据包的转发（也可能会改写数据包）、传递，其中DR模式明显的特征是：从负载均衡下面的节点服务器来看，接收到的请求还是来自访问负载均衡器的客户端的真实用户，而反向代理就不一样了，反向代理接收访问用户的请求后，会代理用户重新向代理下的节点服务器发起请求，最后把数据返回给客户端用户，在节点服务器看来，访问节点服务器的客户端用户就是反向代理服务器了，而非真实的网站访问用户。

lvs工作在四层，只转发请求不涉及流量，效率更高

nginx工作在七层能够针对域名、目录做特定转发，功能更全面

一句话概括：LVS等的负载均衡是转发用户请求的数据包，而Nginx反向代理是接收用户的请求然后重新发起请求去请求其后面的节点。

如右图，所有用户的请求统一发到Nginx负载均衡器，然后由负载均衡器根据调度算法来请求Web01和Web02。

2.2.nginx负载均衡核心组件介绍

Nginx HTTP功能模块

模块说明

ngx_http_proxy_module

proxy代理模块，用于把请求转发给节点服务器

ngx_http_upstream_module

可以实现网站的负载均衡功能及节点的健康检查

2.2.1.upstream模块介绍

Nginx的负载均衡功能依赖于ngx_http_upstream_module模块，所支持的代理方式包括proxy_pass、fastcgi_pass、memcached_pass等，本文主要针对proxy_pass代理方式进行讲解。ngx_http_upstream_module模块允许Nginx定义一组或多组节点服务器，使用时可以通过proxy_pass代理方式把网站的请求发送到事先定义好的对应upstream组上，具体写法为“proxy_pass http://www_pools”，其中www_pools就是一个upstream节点服务器组名字。

2.2.2.upstream模块语法

基本的upstream配置案例：

http {

        upstream www_pools { //www_pools为集群组名称

                server 192.168.1.12:80 weight=10;

                server 192.168.1.13:80 weight=20;

                server 192.168.1.14:80 backup; //其他服务器不可以时启用该服务器

        }

}

upstream参数详细说明：

2.2.3.upstream模块调度算法

调度算法一般分为以下两类：

静态调度算法：即负载均衡器根据自身设定的规则进行分配，不需要考虑后端节点服务器情况。例如：rr、wrr、ip_hash都属于静态调度算法。

动态调度算法：即负载均衡器会根据后端节点的当前状态来决定是否分发请求。例如：连接数少的优先获得请求，响应时间短的优先获得请求，least_conn、fair等都属于动态调度算法。

常用的调度算法：

（1）rr轮询（默认调度算法，静态调度算法）

按客户端请求顺序把客户端的请求逐一分配到不同的后端节点服务器，这相当于LVS中的rr算法，如果后端节点服务器宕机（默认情况下Nginx只检测80端口），宕机的服务器会被自动从节点服务器池中剔除，以使客户端的用户访问不受影响。新的请求会分配给正常的服务器。

（2）wrr（权重轮询，静态调度算法）

在rr轮询算法的基础上加上权重，即为权重轮询算法，当使用该算法时，权重和用户访问成正比，权重值越大，被转发的请求也就越多。可以根据服务器的配置和性能指定权重值大小，从而有效解决新旧服务器性能不均带来的请求分配问题。

（3）fair（动态调度算法）

此算法会根据后端节点服务器的响应时间来分配请求，响应时间短的优先分配。这是更加智能的调度算法。此种算法可以依据页面大小和加载时间长短智能地进行负载均衡，也就是根据后端服务器的响应时间来分配请求，响应时间短的优先分配。Nginx本身是不支持fair调度算法的，如果需要使用这种调度算法，必须下载Nginx的相关模块upstream_fair。

（4）least_conn（动态调度算法）

least_conn算法会根据后端节点的连接数来决定分配情况，哪个机器连接数少就分发给哪个节点。

2.2.4.http_proxy_module模块

proxy_pass指令属于ngx_http_proxy_module模块，此模块可以将请求转发到另一台服务器，在实际的反向代理工作中，会通过location功能匹配指定的URI，然后把接收到的符合匹配URI的请求通过proxy_pass抛给定义好的upstream节点池。

下面是proxy_pass的使用案例:

server {

        location /name/ {

                proxy_pass http://127.0.0.1/remote/;

        }

 }

server {

        location /some/path {

                proxy_pass http://127.0.0.1;

        }

 }

server {

        location / {

                proxy_pass www_pools;

        }

 }

三、nginx反向代理、负载均衡案例

3.1.案例描述：

通过三台服务器实现nginx反向代理、负载均衡集群功能，三台服务器配置如下：

主机

操作系统

IP地址

主要软件

Nginx Server

CentOS 7.5_64

192.168.1.11/24

nginx-1.20.1.tar.gz

Web Client_1

CentOS 7.5_64

192.168.1.12/24

Web Client_2

CentOS 7.5_64

192.168.1.13/24

3.2.实施步骤

3.2.1.三台服务器web部署

nginx服务器主要部署nginx-1.20.1.tar.gz，用于实现反向代理、负载均衡，而两台Web Client可yum方式部署Apache并提供不同访问页面用于验证：

1.nginx服务器的nginx编译安装此处不再体现。

2.两台Web节点服务器的安装：

# yum install -y httpd

# systemctl start httpd

# echo "这是节点服务器1111111111" > /var/www/html/index.html

# echo "这是节点服务器222222222222222222222" > /var/www/html/index.html

3.在nginx服务器中验证节点服务器的可用性：

# curl 192.168.1.12

这是节点服务器1111111111

# curl 192.168.1.13

这是节点服务器222222222222222222222

3.2.2.nginx配置负载均衡

在nginx主配置文件的“http {”中加入以下内容：

    upstream www {

                server 192.168.1.12:80 weight=10;

                Server 192.168.1.13:80 weight=10;

ip_hash; //基于IP地址链接的调度，同一个源地址的请求发往同一个节点服务器

        }

3.2.3.nginx配置反向代理

在nginx主配置文件的server {中加入以下内容：

        location / {

                proxy_pass http://www;

        }

并禁用掉以下内容：

        location / {

             root   html;

             index  index.html index.htm;

        }

3.2.3.验证反向代理、负载均衡

# nginx -t  

# systemctl restart nginx

客户端访问前端nginx代理服务器192.168.1.11，重复访问可分别得到两台节点服务器的页面信息：

四、反向代理多虚拟主机实现

如何实现客户访问www.nginx.com访问到节点服务器的www.nginx.com内容，

而访问www.apache.com访问到节点服务器的www.apache.com内容？

4.1.节点服务器站点部署

以下命令在两台节点服务器中配置：

# mkdir /var/wwwnginx /var/wwwapache

 echo "www.nginx11111.com" > /var/wwwnginx/index.html

 echo "www.apache11111.com" > /var/wwwapache/index.html

 echo "192.168.1.12 www.nginx.com www.apache.com" >> /etc/hosts

 echo "www.nginx22222.com" > /var/wwwnginx/index.html

 echo "www.apache22222.com" > /var/wwwapache/index.html

 echo "192.168.1.13 www.nginx.com www.apache.com" >> /etc/hosts

在两台节点服务器httpd主配置文件末尾分别加入以下内容：

节点服务器1：

    DocumentRoot "/var/wwwnginx"

    ServerName www.nginx.com

    ErrorLog "logs/www.nginx.com.error.log"

    CustomLog "logs/www.nginx.com.access.log" common

    DocumentRoot "/var/wwwapache"

    ServerName www.apache.com

    ErrorLog "logs/www.apache.com.error_log"

    CustomLog "logs/www.apache.com.access_log" common

再修改默认网页根目录为

节点服务器2：

    DocumentRoot "/var/wwwnginx"

    ServerName www.nginx.com

    ErrorLog "logs/www.nginx.com.error.log"

    CustomLog "logs/www.nginx.com.access.log" common

    DocumentRoot "/var/wwwapache"

    ServerName www.apache.com

    ErrorLog "logs/www.apache.com.error_log"

    CustomLog "logs/www.apache.com.access_log" common

再修改默认网页根目录为

# systemctl restart httpd

验证网站资源可用性：

客户端解析nginx服务器域名: 

C:\Windows\System32\drivers\etc\hosts

nginx服务器如何设置才能定义不同域名访问节点服务器的不同虚拟主机？

在nginx主配置文件中定义两个server_name ?

server {

        listen       80;

        server_name  www.nginx.com;

        server_name  www.apache.com;

4.2.反向代理多虚拟主机实现

通过以上设置，在客户端访问不同域名时发现并未访问到不同内容，始终是第一个虚拟主机的网页内容。

对于上述问题，究其原因是，用户访问域名时确实携带了www.nginx.com或者www.apache.com主机头请求Nginx反向代理服务器，但是反向代理向下面节点重新发起请求时，默认并没有在请求头里告诉节点服务器要找哪台虚拟主机，所以，Web节点服务器接收到请求后发现没有主机头信息，因此，就把节点服务器的第一个虚拟主机发给了反向代理（而节点上的第一个虚拟主机放置的是www.nginx.com。解决这个问题的办法，就是当反向代理向后重新发起请求时要携带主机头信息，以明确告诉节点服务器要找哪个虚拟主机。具体的配置很简单，就是在Nginx代理WWW服务虚拟主机配置里增加如下一行配置：

        location / {

                proxy_pass http://www;

proxy_set_header Host $host; //新增内容

        }

# systemctl restart nginx

客户端继续验证：

发现实现了我们多虚拟主机的需求！

以下抓包为不带$host参数和带参数的抓包区别：

4.3.节点服务器统计真机客户端IP地址

由于使用的是nginx反向代理，因此节点服务器收到的web请求的源地址为nginx代理服务器，因此无法统计真实的客户访问情况，解决该问题：

4.3.1.nginx代理服务器打开Forwarded模块

        location / {

                proxy_pass http://www;

                proxy_set_header Host $host;

                proxy_set_header X-Forwarded-For $remote_addr;

        }

4.3.2.节点服务器设置日志格式

1.修改主配置文件：

    LogFormat "%{X-FORWARDED-FOR}i %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

以上红色部分为新增内容，表示在记录日志时加入真实客户端的ip地址。

2.修改虚拟主机日志记录格式为“combined”，两台节点服务器都需要修改：

    DocumentRoot "/var/wwwnginx"

    ServerName www.nginx.com

    ErrorLog "logs/www.nginx.com.error.log"

    CustomLog "logs/www.nginx.com.access.log" combined

    DocumentRoot "/var/wwwapache"

    ServerName www.apache.com

    ErrorLog "logs/www.apache.com.error_log"

    CustomLog "logs/www.apache.com.access_log" combined

客户端再次访问并在节点服务器中查看日志，可以发现日志的第一列为真实客户机的IP地址，第二列为nginx代理服务器的IP地址。

4.4.nginx实现动静分离

当用户请求www.nginx.com/static/x地址时，实现由静态服务器池（static_pools）处理请求。

而对于其他访问请求全部由默认的动态服务器池（default_pools）处理请求。

此案例静态服务器为192.168.1.12，动态服务器为192.168.1.13。

4.4.1.nginx代理服务器配置

1.修改nginx服务器的负载均衡配置：

http {

    include       mime.types;

    default_type  application/octet-stream;

    upstream www {

                server 192.168.1.12:80 weight=10; //删除该项

                server 192.168.1.13:80 weight=10;

        }

以上配置即为动态服务器的配置。

2.增加静态服务器池配置：

在upstream www区域下增加以下内容：

    upstream static {

                server 192.168.1.12:80 weight=10;

        }

在下方配置文件中的上面新增红色字体部分内容：

        location /static {

                proxy_pass http://static;

                proxy_set_header Host $host;

                proxy_set_header X-Forwarded-For $remote_addr;

        }

        location / {

                proxy_pass http://www;

                proxy_set_header Host $host;

                proxy_set_header X-Forwarded-For $remote_addr;

        }

重启nginx服务：# systemctl restart nginx

3.增加静态服务器的验证信息，该静态服务器为192.168.1.13：

# mkdir /var/wwwnginx/static

# echo "这是静态服务器的静态页面！！！！" > /var/wwwnginx/static/index.html

4.5. Nginx负载均衡监测节点状态

利用第三方Nginx插件监控代理后端节点的服务器淘宝技术团队开发了一个Tengine（Nginx的分支）模块nginx_upstream_check_module，用于提供主动式后端服务器健康检查。通过它可以检测后端realserver的健康状态，如果后端realserver不可用，则所有的请求就不会转发到该节点上。Tengine原生支持这个模块，而Nginx则需要通过打补丁的方式将该模块添加到Nginx中（安装nginx时已经安装该补丁）。补丁下载地址：https://github.com/yaoweibin/nginx_upstream_check_module。下面介绍一下如何使用这个模块。

# vim /usr/local/nginx/conf/nginx.conf

    upstream www {

                server 192.168.1.12:80 weight=10;

                check interval=3000 rise=2 fall=5 timeout=1000 type=http;

        }

上面配置的意思是，对static_pools这个负载均衡条目中的所有节点，每隔3秒检测一次，请求2次正常则标记realserver状态为up，如果检测5次都失败，则标记real-server的状态为down，超时时间为1秒，检查协议是HTTP。

新增以下内容：

        location /status {

                check_status;

        }

客户端访问：192.168.1.11/status

上图可以发现12服务器无法使用

重新启动12HTTP访问之后的效果：