CentOS7 Nginx的安装与http负载均衡配置

CentOS7 Nginx的安装与http负载均衡配置

技术杂谈小彩虹2021-08-19 12:01:47240A+A-

安装环境:4台Linux机,系统为CentOS 7.7。 Nginx版本:1.12.0

ip 作用
172.16.122.101 部署Nginx,代理真实服务器1、2、3
172.16.122.104 真实服务器1,已经部署应用,并对外暴露http端口10900
172.16.122.105 真实服务器2,已经部署应用,并对外暴露http端口10900
172.16.122.106 真实服务器3,已经部署应用,并对外暴露http端口10900

1、依赖安装

1.1、gcc 安装

安装Nginx需要先将官网下载的源码进行编译,编译依赖gcc环境,如果没有gcc环境,则需要安装:

yum install gcc-c++

1.2、PCRE pcre-devel 安装

PCRE(Perl Compatible Regular Expressions) 是一个Perl库,包括perl兼容的正则表达式库。Nginx的http模块使用pcre来解析正则表达式,所以需要在linux上安装 pcre库,pcre-devel是使用pcre开发的一个二次开发库。Nginx也需要此库。命令:

yum install -y pcre pcre-devel

1.3、zlib 安装

zlib库提供了很多种压缩和解压缩的方式,Nginx使用zlibhttp包的内容进行gzip,所以需要在Centos上安装zlib库。

yum install -y zlib zlib-devel

1.4、OpenSSL 安装

OpenSSL是一个强大的安全套接字层密码库,囊括主要的密码算法、常用的密钥和证书封装管理功能及SSL协议,并提供丰富的应用程序供测试或其它目的使用。 Nginx不仅支持http协议,还支持https(即在ssl协议上传输http),所以需要在Centos安装OpenSSL库。

yum install -y openssl openssl-devel

2、下载安装Nginx

2.1、下载

下载地址:http://nginx.org/download/ 选择一个版本进行下载,这里我用的是nginx-1.12.0.zip 版本。

2.2、安装

将下载的安装包上传至服务器。

tar -xvf nginx-1.12.0.tar.gz
cd nginx-1.12.0

编译

./configure --prefix=/usr/local/nginx
make && make install
  • prefix:指定安装路径,默认就是/usr/local/nginx

查看验证

cd /usr/local/nginx/sbin/
./nginx -V

结果:

[root@zxb01 sbin]# ./nginx -V
nginx version: nginx/1.12.0
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) 
built with OpenSSL 1.0.2k-fips  26 Jan 2017
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx

至此,Nginx安装已经完成。

3、Nginx的启停

3.1、启动

./nginx

浏览器访问http://172.16.122.101/,可以看到如下页面。 -w647

3.2、停止

./nginx -s quit # 待nginx进程处理任务完毕进行停止
./nginx -s stop # 先查出nginx进程id再使用kill命令强制杀掉进程

3.3、重载

Nginx的配置文件nginx.conf修改后,要想让配置生效需要重启Nginx,使用-s reload不用先停止Nginx再启动Nginx即可将配置信息在Nginx中生效,如下:

./nginx -s reload

3.4、其它命令

./nginx -h

-w768

4、http负载均衡

4.1、新增配置

修改nginx/conf/nginx.conf文件,在http{...}配置块中新增配置:

upstream backend {
    server 172.16.122.104:10900;
    server 172.16.122.105:10900;
    server 172.16.122.106:10900;
}
    
server {
	listen	*:11000;
	
	# 日志单独输出配置,默认输出到logs/access.log、logs/error.log
	access_log /usr/local/nginx/logs/test_access.log;
	error_log /usr/local/nginx/logs/test_error.log;
	
	location / {
		proxy_pass	http://backend;
	}
}

Nginx本地监听11000端口,然后转发到upstream中配置的后台服务器地址,默认是轮询策略。

当然这是最简单的配置,这里location定义的准入url规则是所有都接入,也可以缩小准入的url范围,比如定义location /api {...},就只能接入url后缀是/api开头的请求;Nginxurl匹配和转发规则非常灵活,可以做到改写要转发的url路径,还可以使用正则表达式。

upstream的配置这里使用了默认的策略,如果需要自定义做一些配置可以参考后面的章节内容。

4.2、负载均衡效果测试

postman调用http://172.16.122.101:11000/xxxNginx会将请求转发到对应的后端真实服务器http://172.16.122.104~6:10900/xxx,多次调用可以看到是轮询的效果。

5、upstream配置参数

5.1、主要参数

upstream backend{
    server 127.0.0.1:9001 weight=1;
    # 代表在10秒内请求某一应用失败2次,认为该应用宕机,后等待10秒,这期间内不会再把新请求发送到宕机应用,而是直接发到正常的那一台。
    # 时间到后再有请求进来继续尝试连接宕机应用且仅尝试1次,如果还是失败,则继续等待10秒...以此循环,直到恢复。
    server 127.0.0.1:9002 weight=4 max_conns=800 max_fails=2 fail_timeout=10;
    server 127.0.0.1:9003 backup; # 其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。
    server 127.0.0.1:9004 down; # 表示当前的server暂时不参与负载。
}
  • weight:服务器权重,默认为1。
  • max_conns:最大连接数,针对单台服务器。(Nginx版本1.11.5以上)
  • max_fails:允许请求失败的次数,默认为1,当超过最大次数时,认为这台服务器不可用。
  • fail_timeout:max_fails次失败后,暂停的时间,默认为10s。
  • backup:其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。
  • down:表示当前的server暂时不参与负载。

5.2、几种负载均衡策略

5.2.1、轮询(默认方式)
upstream backend {
    server 172.16.122.104:10900;
    server 172.16.122.105:10900;
    server 172.16.122.106:10900;
}
  • 在轮询中,如果服务器down掉了,会自动剔除该服务器。
  • 此策略适合服务器配置相当,无状态且短平快的服务使用。
5.2.2、权重
upstream backend {
    server 172.16.122.104:10900 weight=1;
    server 172.16.122.105:10900 weight=2;
    server 172.16.122.106:10900 weight=3;
}
  • 权重越高分配到需要处理的请求越多。
  • 此策略可以与least_connip_hash结合使用。
  • 此策略比较适合服务器的硬件配置差别比较大的情况。
5.2.3、ip_hash

每个请求按访问IP的hash结果分配,这样来自同一个IP的访客固定访问一个后端服务器,有效解决了动态网页存在的session共享问题。

upstream backend {
    ip_hash; # 保证每个访客固定访问一个后端服务器
    server 172.16.122.104:10900 weight=1;
    server 172.16.122.105:10900 weight=2;
    server 172.16.122.106:10900 weight=3 max_fails=2 fail_timeout=10;
}
  • Nginx版本1.3.1之前,不能在ip_hash中使用权重(weight)。
  • ip_hash不能与backup同时使用。
  • 此策略适合有状态服务,比如session
  • 当有服务器需要剔除,必须手动down掉。
5.2.4、least_conn

把请求转发给连接数较少的后端服务器。轮询算法是把请求平均的转发给各个后端,使它们的负载大致相同;但是,有些请求占用的时间很长,会导致其所在的后端负载较高。这种情况下,least_conn这种方式就可以达到更好的负载均衡效果。

upstream backend {
    least_conn; # 把请求转发给连接数较少的后端服务器
    server 172.16.122.104:10900 weight=1;
    server 172.16.122.105:10900 weight=2 max_fails=2 fail_timeout=10;
    server 172.16.122.106:10900 backup;
}
5.2.5、fair(需安装第三方插件)

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

upstream backend {
    fair; # 实现响应时间短的优先分配
    server 172.16.122.104:10900;
    server 172.16.122.105:10900;
    server 172.16.122.106:10900;
}
5.2.6、url_hash(需安装第三方插件)

按访问urlhash结果来分配请求,使每个url定向到同一个后端服务器,要配合缓存命中来使用。同一个资源多次请求,可能会到达不同的服务器上,导致不必要的多次下载,缓存命中率不高,以及一些资源时间的浪费。而使用url_hash,可以使得同一个url(也就是同一个资源请求)会到达同一台服务器,一旦缓存住了资源,再次收到请求,就可以从缓存中读取。

upstream backend {
    hash $request_uri; # 实现每个url定向到同一个后端服务器
    hash_method crc32; # 指定hash算法为crc32
    server 172.16.122.104:10900;
    server 172.16.122.105:10900;
    server 172.16.122.106:10900;
}

参考文章

个人网站

点击这里复制本文地址 以上内容由权冠洲的博客整理呈现,请务必在转载分享时注明本文地址!如对内容有疑问,请联系我们,谢谢!

支持Ctrl+Enter提交

联系我们| 本站介绍| 留言建议 | 交换友链 | 域名展示 | 支付宝红包
本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除

权冠洲的博客 © All Rights Reserved.  Copyright quanguanzhou.top All Rights Reserved
苏公网安备 32030302000848号   苏ICP备20033101号-1
本网站由 提供CDN/云存储服务

联系我们