nginx

---

实验环境

server—172.20.10.9----外部主机
server1—172.20.10.7-----调度器
server2—172.20.10.6----真实服务器real server
server3—172.20.10.8----真实服务器real server

---

安装nginx

实现七层负载均衡

调度器、真实服务器都不需要设置vip

真实服务器需要： systemctl start httpd

方式1： nginx -s reload

方式2：
nginx -s stop
nginx stop

在外部主机172.20.10.9查看：

nginx 自带健康检测

外部主机访问

real server 2 关闭httpd服务

real server 3 开启httpd服务

外部主机访问

real server 2 与real server 3 都关闭httpd服务

外部主机访问

nginx配置优化

worker_processes 工作进程数

ps ax:

work_connections 单个工作进程并发连接数

weight 权重

backup备份

server3 down：
server2 down：

server2正常工作：

server3正常工作：

外部主机访问：只要server2或者server3其中一个正常工作，都不会启用backup：

ip_hash算法

根据客户端ip进行负载均衡，相同客户端IP访问时，会访问到同一个server。一对一，一个sever对一个IP
缺点：可能导致后端某一个real server的访问压力变大，

添加nginx模块sticky，扩展调度算法

访问流程：client–>dns—>CDN—>server
CDN是内容分发网络，主要保存缓存信息。客户端直接向CDN访问，可以缓解后端服务器的压力，且可以提升客户端访问速度。

这里可以理解为：
client -> cdn(proxy) -> nginx -> httpd ,
CDN对于客户主机来说是透明的，client不知道cdn,以为就是从服务器访问得到的， 对于nginx来说，nginx也不知道client的IP，拿到的只有cdn的IP. 那么设置ip_hash算法就无效了，因为nginx只能拿到cdn的IP地址（源地址即client的地址会转换成cdn的地址），始终用一个服务器响应。【nginx的反向代理机制】

如何既使用cdn，又能使得后端服务器负载均衡呢？需要另外的算法Sticky cookie。算法Sticky cookie不是根据源IP地址来进行负载均衡，而是根据客户端浏览器上的cookie进行负载均衡。

Sticky cookie算法，根据服务器给客户端浏览器发送的cookie，客户端再次请求时会带上此cookie，nginx会把有此cookie的请求转发到颁发cookie的服务器上
Sticky是基于cookie的一种负载均衡解决方案，默认cookie标识名为route ：

sticky工作机制:

1. 客户端首次发起访问请求，nginx接收后，发现请求头没有cookie，则以轮询方式将请求分发给后端服务器。
2. 后端服务器处理完请求，将响应数据返回给nginx。
3. 此时nginx生成带route的cookie，返回给客户端。route的值与后端服务器对应，可能是明文，也可能是md5、sha1等Hash值
4. 客户端接收请求，并保存带route的cookie。
5. 当客户端下一次发送请求时，会带上route，nginx根据接收到的cookie中的route值，转发给对应的后端服务器

session是在服务器端，cookie是在客户端的浏览器上，如果通过浏览器的cookie进行负载均衡，就需要对当前的nginx扩展模块

如果使用了Sticky模块，那么最好不要在real server后面设置权重（weight）
Nginx sticky模块不能与ip_hash同时使用

首先下载sticky模块包，并解压

fence

比如在server 1执行： echo c > /proc/sysrq-trigger server1的内核就崩溃了，会无任何相应，，，，，，fence就像是一个插线板，上面插着网线，通过网络可以控制它。假如server1 为master，server4为backup。server1上挂载着存储系统，这个存储系统可能不是共享存储，不支持多点读写。如果server1出现异常，“晕过去了”，无法工作。正常情况下，server1应将VIP、服务和存储都释放出来，并由server4接管server1的VIP，服务和存储。但是如果server1未正常释放资源，此时资源又再server4上挂接了。考虑这样的情况，server1又突然能正常工作了，就会导致server1和server4上同时有VIP、服务和存储，server1和server4能同时接管业务。这就说明server1和4会同时写入存储。而存储不支持多点写入，这就会产生问题，导致存储损坏。fence的作用就是当server1出现问题，“晕过去了”。那么server4会连接fence并发送请求将server1的电源关闭，彻底使得server1无法工作。然后再远程给server1加电，相当于将server1重新启动。而server1上的服务设定了开机自启，server1就又可以重新加入，并正常工作。在将server1重启的过程中，server4也已经接管了业务。

编写nginx脚本

通过二进制文件控制nginx：

nginx -s reload------重新加载
nginx -s stop-----停止
nginx -t -----语法检查
nginx------开启nginx

通过脚本控制nginx：
systemctl start nginx
systemctl stop nginx
systemctl restart nginx
systemctl enable nginx
systemctl status nginx

server 1:

nginx+pacemaker高可用

server—172.20.10.9----外部主机
server1—172.20.10.7-----调度器
server2—172.20.10.6----真实服务器real server
server3—172.20.10.8----真实服务器real server
server4—172.20.10.10-----调度器

server1与server4实现高可用。

高可用： 提供服务的调度器，如果出现服务资源故障或者节点故障都能被检测到，并自动切换至备用机

添加VIP的原因：
不能让客户端直接访问调度器server1的IP，如果调度器down了，那服务不可用了，因此调度器不能只有一个IP地址，需要有个公共的VIP，让集群做迁移

外部主机访问：

服务由谁接管，VIP就在谁上面

lamp架构

lamp架构=linux/unix/windows apache/nginx mysql/pgsql php/jsp/python/go

nginx的平滑升级

升级

版本回退