企业架构LNMP高可用负载均衡服务器之Nginx
一、背景描述及其方案设计
1、业务背景描述
随着业务量骤增，之前单点服务器，已经不能够满足业务使用需要。如果主服务器宕机，备服务器提供服务，因为流量太大，备也宕机。需要多台服务器，同时提供服务。
2、模拟运维设计方案
以上架构服务器，已经不能够满足以上提到的业务需求。架构发生如下变化
二、服务器基本环境部署
1、克隆复制虚拟机
2、基础环境配置
网卡IP、主机名称、hosts解析
三、负载均衡服务器搭建
1、引入负载均衡技术
负载均衡技术 （load blance） 是一种概念 把资源的使用进行平均分配。
负载均衡：分发流量、请求到不同的服务器。使流量平均分配（理想的状态的）
作用：
服务器容灾 流量分发
主要作用：
①流量分发 请求平均 降低单例压力
其他作用：
②安全 隐藏后端真实服务
③屏蔽非法请求（七层负载均衡）
2、负载均衡分类
1）二层负载均衡（mac）
根据OSI模型分的二层进行负载，一般是用虚拟mac地址方式，外部对虚拟MAC地址请求，负载均衡接收后，再分配后端实际的MAC地址响应
2）三层负载均衡（ip）
一般采用虚拟IP地址方式，外部对虚拟的ip地址请求，负载均衡接收后，再分配后端实际的IP地址响应
3）四层负载均衡（tcp） 网络运输层面的负载均衡
在三层负载均衡的基础上，用ip+port接收请求，再转发到对应的机器
4）七层负载均衡（http） 智能型负载均衡
根据虚拟的url或IP，主机接收请求，再转向（反向代理）相应的处理服务器
3、常见实现方式
硬件是实现方式：
F5 BIG-IP 四层和七层
软件实现方式：
| OSI分层 | 实现方式 |
|---|---|
| 七层 | Nginx、HAProxy |
| 四层 | LVS、HAProxy、Nginx（1.9版本后） |
四层和七层对比:
4、Nginx负载均衡配置
官方文档：Module ngx_http_upstream_module
①在客户端解析域名到负载均衡服务器
②在负载均衡的Nginx配置
#注意本次架构中 server04的Nginx服务器是负载均衡服务器 shell > cd /usr/local/nginx/conf/nginx.conf
配置文件示例：
#在http段进行配置
#分发请求到后端服务器
upstream shop {
#web1 server01
server 192.168.17.102;
#web2 server02
server 192.168.17.101；
}
#修改之前的shop的server段配置
server {
listen 80；
server_name www.shop.com;
location / {
#代理转发到shop段 匹配到上面的upstream
proxy_pass http://shop;
#以下两条配置，实质是设置了传输的header头信息
#传输域名给后端服务器 进行识别 方便匹配对应server虚拟主机
proxy_set_header Host $host;
#发送客户端IP 给后端服务器 用来方便后端服务器识别用户真实IP
proxy_set_header X-Real-IP $remote_addr;
}
}
③重载负载均衡服务器Nginx配置测试查看效果
可以停掉其中一台web服务器进行测试
5、查看确认负载均衡
==方法一：在不同服务器写入不同信息==
①分别修改web服务器的信息
shell > vim /usr/local/nginx/html/tp5shop/application/home/controller/Base.php
写入一个动态参数，根据php语法自动调用当前主机名称
②访问查看负载均衡效果
方法二：查看后端web服务器的访问日志
shell > cat /usr/local/nginx/logs/access.log
##6、负载均衡后获取客户端IP
官方网址：Module ngx_http_realip_module
使用ngx_http_realip_module模块提供的set_real_ip_from语法，默认此模块没有安装，需要编译时添加编译参数
web服务器上配置set_real_ip_from 代表从哪儿来源的IP，需要识别真实客户端IP
示例配置：
#此配置在web服务器上的nginx #可配置到http、server、location中，推荐配置到server中 #配置需要识别的IP来源 负载均衡的IP set_real_ip_from 192.168.17.103
##7、upstream中server的关键字
upstream shop {
server 192.168.17.102 down;
server 192.168.17.101 backup；
}
##8、session一致性问题
访问管理后端页面，登录发现验证码不通过
分析原因：
①比如分发到web1服务器，生成验证码，存储到session中，默认在服务器本地
②再次校验的时候，请求分发到web2服务器了，所有验证码一直校验不通过
解决方案思路：
①生成和验证session都请求同一台服务器
②共享session nfs mysql ==内存缓存软件（memcached、redis）==
9、Nginx的负载均衡算法
Tip：
第三方模块实现的调度算法 需要编译安装第三方模块
④fair 根据后端服务器的繁忙程度 将请求发到非繁忙的后端服务器
⑤url_hash 如果客户端访问的url是同一个，将转发到同一台后端服务器
验证一：验证加权轮询算法
示例配置：
upstream shop {
#web1 server01
server 192.168.17.102 weight=5;
#web2 server02
server 192.168.17.101 weight=3；
}
server01 web 1 1 1 1 1 1
server03 web 2 1 1 1
8次中，server01分发5次，server03分发3次
验证二：ip一致性算法
示例配置:
upstream shop {
#ip hash 一致性算法配置 设置此项 weight就失效了
ip_hash;
#web1 server01
server 192.168.17.102 weight=5;
#web2 server02
server 192.168.17.101 weight=3；
}
10、实现负载均衡高可用
所有的请求流量，都要经过负载均衡服务器，负载均衡服务器压力很大，防止它宕机，导致后端服务所有都不可用，需要对负载均衡服务器，做高可用
给负载均衡服务器server04做一台备用服务器server05，通过keepalived实现高可用。
通过keepalived实现VIP在负载均衡服务器组的切换。
主负载均衡的keepalived配置
vrrp_instance VI_1 {
state BACKUP
interface eth0
#虚拟路由ID 新ID 不要之前的冲突
virtual_router_id 52
priority 100
nopreempt
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
#添加新VIP
192.168.17.201
}
track_script {
check_nginx
}
}
备负载均衡的keepalived配置
vrrp_instance VI_1 {
state BACKUP
interface eth0
#修改route_id
virtual_router_id 52
priority 99
nopreempt
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
#unicast_src_ip 192.168.17.101
#unicast_peer {
# 192.168.17.102
#}
virtual_ipaddress {
#新VIP
192.168.17.201
}
track_script {
check_nginx
}
}
