企业运维 --- LAMP架构（nginx [1] 源码编译安装、平滑升级、负载均衡）

一、lamp架构

1、lamp其实就是一组通常一起使用来运行动态网站或者服务器的自由软件，包括Linux（操作系统）、Apache（HTTP服务器）、MySQL（也指MariaDB，数据库软件）和PHP（有时也是指Perl或Python）的第一个字母，一般用来建立web应用平台；

2、除Linux外其它各部件本身都是各自独立的程序，但是因为经常被放在一起使用，拥有了越来越高的兼容度，共同组成了一个强大的Web应用程序平台。本次实验我们使用Nginx替代Apache， nginx相比较apache最明显的优势是轻量级、高并发，配置也较apache更简洁。

二、nginx的安装与配置

为了便于后续实验，给server1添加一个172.25.0网段的ip

真机（172.25.254.36）打开火墙，开启地址伪装功能，使得虚拟机能够上网

真机添加一条iptables规则；
MASQUERADE的作用：从服务器的网卡上，自动获取当前ip地址来做NAT，这样不用指定SNAT的目标ip，不管现在eth0的出口获得了怎样的动态ip，MASQUERADE会自动读取eth0现在的ip地址然后做SNAT出去，这样就实现了很好的动态SNAT地址转换。

查看nat表所有链及所有规则，可以看到添加成功

此时server1就可以直接从服务器上获取所需文件

server1从服务器上下载nginx的源码压缩包nginx-1.20.1.tar.gz，解压后进入到nginx源码目录；
src/core存放着nginx的主干部分、基础数据结构和基础设施的源码

conf目录下由nginx的主配置文件nginx.conf

源码编译三部曲：配置(configure)、编译(make)、安装(make install)；
配置：通过./configure --help查看配置选项

nginx源码文件，需要gcc等依赖文件进行编译

设置安装的路径为/usr/local/nginx，加上需要的功能模块；
运行后可以看到提示缺少PCRE

开发包以devel结尾

提示缺少openssl


再次配置，显示成功

在configure执行完后，它会生成一些中间文件，中间文件会放在objs目录下；
Makefile是一种配置文件，定义了一系列的规则来指定，哪些文件需要先编译，哪些文件需要后编译，哪些文件需要重新编译，甚至于进行更复杂的功能操作

执行编译（静态编译）

编译成功

将编译好的文件安装到指定路径

此时objs目录下可以看到 nginx文件

在我们指定的路径下也能看到编译好的nginx文件

为方便nginx启动，设定软链接到/usr/local/sbin/（这样在开启nginx服务的时候就不需要进到目录下开启，软连接的方式可以方便开启全局nginx）；
nginx -t：检查配置脚本是否运行正常
nginx：启动nginx，并查看端口

测试：成功访问到nginx的默认发布目录

客户端访问测试

注意当nginx进程已经启动时，再次启动就会出现以下提示

停止nginx

当需要二次编译nginx时，必须先执行make clean（清除上次的make命令所产生的object文件（后缀为“.o”的文件）及可执行文件）；
最后执行make install（因为文件已经复制过去，不需要再次复制）

关闭c语言编译debug(轻量化编译文件)

在此Debug模式模式会插入许多追踪和ASSERT之类的信息，在正常编译过程中结束，会产生几兆大小的包，我们可以在编译之前关闭debug模式，这样在编译结束，只会产生几百K左右的包大小。
#CFLAGS=“$CFLAGS -g” ##本行注释掉，关闭debug日志模式，

显示 http response 的头信息，可以看到当前nginx版本

修改解压目录中的src/core/nginx.h

修改#define NGINX_VER（去掉版本）

重新进行配置、编译


执行编译，为了构建更加纯净的nginx脚本，不需要执行make install；

编译完成后，此时nginx大小为928k;
出现以下问题是因为没有关闭nginx

alias,则可列出目前所有的别名设置，在cp指令前面加反斜杠可以不弹出是否覆盖的询问而直接覆盖；
关闭nginx后，将新生成的文件更换安装目录中的文件；
再次启动nginx，并查看头信息，可以看到头信息已经更改（看不到当前nginx版本号）

如果想要使用systemctl来控制nginx

首先需要在服务器上获取nginx.service文件


首先确保nginx没启动，如果启动，需要关闭nginx；
刷新服务列表
启动nginx并设置服务开机自启，此时就可以通过systemctl来控制nginx

网页访问成功

三、nginx的worker管理

为了便于实验效果，首先修改server1的cpu的个数为2，内存为2048；
用cpu的个数控制nginx的work进程个数；

增加一个nginx用户

修改nginx主配置文件nginx.conf，设定用户为nginx，worker进程数为1

nginx -s reload ：平滑重启,不会强制结束正在工作的连接,需要等所有连接都结束才会重启

可以看到nginx的一个主控制端和被控制的一个worker

nginx并发优化：继续修改主配置文件，设定工作进程数为2

重启nginx后，查看nginx的worker进程；
当我们kill掉其中一个worker进程后，由于配置文件设定的worker进程数为2 ，因此会自动再运行一个新的worker进程

当设定worker进程数为auto后，会自动根据系统cpu的数量管理worker进程数



查看server1 cpu的详细信息

Nginx默认没有开启利用多核cpu，我们可以通过增加worker_cpu_affinity配置参数来充分利用多核cpu的性能;
cpu是任务处理，计算最关键的资源，cpu核越多，性能就越好；
2核cpu，开启2个进程 设定worker_cpu_affinity 01 10（将cpu和worker数目绑定）;
4个cpu，开启4个进程 设定worker_cpu_affinity 0001 0010 0100 1000;

worker_connections：设定每一个worker进程能并发处理（发起）的最大连接数为65535（包含所有连接数），不能超过最大文件打开数；

要求内核支持最大文件打开数>系统支持最大文件打开数>Worker支持最大文件打开数


查看server1内核支持的最大文件打开数

查看真机内核支持的最大文件打开数

显示系统目前资源限制的设定，可以看到系统支持的最大文件打开数为1024



修改系统的最大文件打开数

*: 表示所有的用户，也可以指定指定的用户或用户组
soft: 表示应用软件级别限制的最大可打开的文件数的限制
hard: 表示操作系统级别限制的最大可打开的文件数的限制

重新启动nginx服务，使设定生效

四、nginx平滑升级

1.版本升级

使用nginx1.21进行版本升级，为避免升级时掉线，采用平滑升级；
首先server1连接服务器，下载nginx1.21.1版本的源代码编译包

同样的关闭gcc的debug


进行源代码安装第一步，同样的对即将安装的软件进行配置

编译，不执行make install

此时objs目录就会生成新的nginx二进制文件
将nginx旧版本文件进行备份

将新生成的nginx文件覆盖安装目录下的旧的nginx

此时curl查看发现仍然是旧版本的nginx

需要用kill -USR2 老版本的进程号 ，升级新程序，从而产生新版本的master和worker

kill -WINCH 老版本的进程号，可以关闭旧版本的worker进程但保留主进程：为了回退；
测试，已经升级到1.20版本

2.版本回退

版本回退：
还原nginx程序：# cp -f nginx.old nginx
唤醒原进程：# kill -HUP 旧版本id
回收新版本的worker进程： kill -WINCH 新版本id
关闭新版本主进程： kill -QUIT 29761

首先将备份的旧版本nginx文件覆盖执行目录的nginx；
kill -HUP 旧版本id：唤醒原进程；
kill -WINCH 新版本id：回收新版本的worker进程；

curl测试，成功完成平滑回退

最后关闭新版本主进程

五、nginx负载均衡

1.配置nginx负载均衡

server1对server2/3进行免密认证，便于后续操作

将server1的nginx目录传输给server2/3


将server1的nginx.service文件传输给server2/3，使得server2/3也可以使用systemctl 命令来方便操作nginx的启动、停止和重启命令

server2/3分别执行：创建nginx用户、刷新服务列表、启动并设置nginx服务开机自启



server2/3修改默认发布页面


server1测试访问server2/3成功;
server1编辑nginx主配置文件，将均衡负载模块加入

在http加入upstream模块，设定反向代理负载均衡器westos；
upstream表示负载服务器池

location 指令的作用：根据用户请求的URI来执行不同的应用，URI就是根据用户请求到的网址URL进行匹配；
server_name ：代理的服务域名;
location：设定当外部访问www.westos.org这个域名时，nginx会把所有请求都发送到upstream定义的服务器节点池（westos）

检测语法无误后，刷新服务使设定生效

在真机进行地址解析

测试，可以看到访问可以实现负载均衡

查看nginx日志




继续编辑nginx主配置文件

设定服务器server2的权重为2


可以看到，访问时server2出现的次数大概是server3的两倍

2.配置nginx备用服务器

继续修改配置文件，设定server1为backup。只有当其他节点全部无法连接的时候，nginx才会启用这个节点。一旦有可用的节点恢复服务，该节点则不再使用，又进入后备状态。

server1测试访问

更改server1默认发布页面

测试访问

关闭server2的nginx服务


关闭server3的nginx服务

可以看到备用机server1启动成功

当server2的nginx服务开启后

备用节点server1将不再提供服务

3.配置nginx基于ip_hash的负载均衡模式

ip_hash：通过客户端请求ip进行hash，再通过hash值选择后端server；
当你服务端的一个特定url路径会被同一个用户连续访问时，如果负载均衡策略还是轮询的话，那该用户的多次访问会被打到各台服务器上，这显然并不高效（会建立多次http链接等问题）。所以，此类场景可以考虑采用nginx提供的ip_hash策略。既能满足每个用户请求到同一台服务器，又能满足不同用户之间负载均衡。

语法检测出错，这是因为ip_hash不能与backup一起用



可以看到当客户端对指定域名进行多次服务请求时， 只有server3对该客户端提供服务

4.配置nginx基于cookie的负载均衡

Cookie是某些网站为了辨别用户身份，进行Session跟踪而储存在用户本地终端上的数据（通常经过加密），由用户客户端计算机暂时或永久保存的信息；

在多台后台服务器的环境下，为了确保一个客户只和一台服务器通信，势必使用长连接。常见的有使用nginx自带的ip_hash来做,，但如果前端是CDN，或者说一个局域网的客户同时访问服务器，导致出现服务器分配不均衡，以及不能保证每次访问都粘滞在同一台服务器。因此可以采用基于cookie负载均衡，能保证每次都锁定同一台服务器；

server1从服务器下载额外的压缩包辅助cookie算法；
下载unzip压缩工具

解压文件

修改配置文件

语法检测失败，因为此时并没有cookie软件模块

所以先将sticky注释

停止nginx服务

重新配置，加上所需模块


make编译，将新的nginx覆盖旧的nginx

打开sticky设定

刷新服务

网页访问www.westos.org，按F12，即可查看到cookie访问记录，且采用cookie的方式访问时会锁定服务器

再按F5刷新页面，或者手动删除当前session，即可看到server2的cookie访问记录