一、简介
企业中常用的web架构主要的目的是实现高可用及其容灾备份，说白了就是让用户有更好的用提体验，一个架构的可用性只有在经历过上线后接受用户的使用才能体现出其稳定性及其不足之处。利用周末的时间出于无聊，所以想总结以前所学的知识，本文主要介绍lvs,keepalived,nginx-proxy,等常用服务的搭建及其原理。
二、lvs概述及NAT、DR原理
专题一：
lvs-nat(Linux virtual system)是根据请求报文的目标ip和目标端口进行调度转发至后端某主机。在实际生产中常用的模型有NAT(Network Address Translation)和DR(Direct Routing)，下面我们从这两开始展开叙述。
NAT模型拓扑图：
原理：客服端发起请求，请求到达lvs前端调度器，通过将请求报文中的目标IP地址和目标端口修改为后端真实服务器的IP地址和端口实现转发，后端真实主机处理请求后又将响应报文以相同的原理经过调度器响应给用户。如图所示，开始时源地址为CIP目标地址为VIP，经过LVS发生目标地址转换，将VIP转换为RIP,则源地址为CIP目标地址为RIP,real server发现目标地址为自己地址时开始拆报文并给出响应。
实战部署：
VIP1：10.1.10.65
DIP1：192.168.184.128
RIP1：192.168.184.129
RIP2：192.168.184.130
要求：两台real server网关要指向DIP.VIP和DIP需在同一个网段，且为内网地址
示例图：
两台real server网关必须指向directory routing.
添加ipvsadm规则，使用默认权重为1，进行测试，实验结果为轮询。
修改默认权重为1:2，及其静态调度算法为加权轮询，测试结果为1:2加权轮询。
总结：lvs-nat重要的注意点为路由需指向直连路由，需开启转发功能，常用的静态和动态轮询算法有：rr,wrr,SH,DH,LC,WLC.SED,NQ,LBLC,LBLCR等
专题二：
lvs-dr(lvs director routing)是通过将请求报文重新封装其MAC地址进行转发，源MAC地址为DIP所在接口的IP地址，而目标MAC地址为从后端挑选出来的real server的MAC地址IP首部不发生变换 。
DR模型拓扑图：
原理：lvs-dr模型中，请求报文的目标地址和源地址为发生改变，而在dr上重新封装了MAC地址，最大的改变是后端的real server和dr都配备了VIP地址，而real server响应用户请求时不经由dr进行转发，直接将报文发送给客服端主机。在每个real server和dr上配有VIP地址，因此为了达到real sever不直接响应dr,需修改内核参数，将VIP绑定在lo回环接口的别名上，两参数分别为：arp_ignore，arp_announce。
实战部署：
VIP1：10.1.10.88
DIP1：10.1.10.65
RIP1：10.1.10.66
VIP1：10.1.10.88
RIP2：10.1.10.67
VIP1：10.1.10.88
要求：需调整内核参数，为每一个需要VIP地址的主机添加VIP地址
上诉均可使用脚本实现如下：
示例图：
设置为加权轮询权重比为1:2，及其添加ipvs规则
实验结果如下图，实现1：2说明实验成功 ，可修改其调度算法再次验证其结果的真实性。
总结：lvs-dr重点在于给dr及其real server配置VIP地址，并且向real server设置内核参数，是的real server中的lo:0上的VIP地址不直接响应dr,而是由real server直接响应客服端请求。上诉实验中有个缺点，当real server主机服务提供服务时，用户请求页面很不友好，需给出相应的应急页面。
三、实战keepalived高可用集群解决方案
专题三：
keepalived是vrrp协议的实现，原生设计目的是为了高可用ipvs服务，keepalived能够配置文件中的定义生成ipvs规则，并能够对各RS的健康状态进行检测；通过共用的虚拟IP地址对外提供服务；在主备模式下，每个热备组内同一时刻只有一台主服务器提供服务，其他服务器处于冗余状态，若当前在线的服务器宕机，其虚拟IP地址将会被其他服务器接替（优先级决定接替顺序），实现高可用为后端主机提供服务。主/备，备/主双主模式下，两台调度器均处于提供服务的状态，当其中一台服务器宕机或出现故障时，VIP将会“漂移”至另一台服务器。
keepalived拓扑图：
原理：keepalived的实现主要是由vrrp协议，自定义vrrp_instance，vrrp_server和一些检测脚本一起共同合作，实现自动分配VIP，和ipvs规则，少去了手动配置ipvs的麻烦，同时还能够配置应急服务器、用简单脚本能在恢复模式下进行系统修复等，比起lvs优越性更高。
实战部署：
DIP1:10.1.10.65
VIP1：10.1.10.88
VIP2：10.1.10.99
DIP2：10.1.10.68
VIP1：10.1.10.88
VIP2：10.1.10.99
RIP1：10.1.10.66
VIP1：10.1.10.88
VIP2：10.1.10.99
RIP2：10.1.10.67
VIP1：10.1.10.88
VIP2：10.1.10.99
要求：配置过程中，主的优先级要高于备，同时将主备的state状态互调。
示例图：
配置完成后启动keepalived会自动生成ipvs规则
测试结果为设定的轮询算法，同时模拟后端某服务器故障，查看相应的服务器是否能符合正常需求
测试结果为设定的轮询算法，同时模拟后端服务器故障，查看相应的ipvs规则是否自动生成
测试结果为设定的轮询算法，同时模拟后端某服务器故障，查看相应的应急页面是否能符合正常需求
总结：在keepalived中需注意的事项为，配置vrrp_instance实例时需注意主备的状态及其优先级，比起lvs来说keepalived总体配置简单，且ipvs规则自动生成省去了“人工智能”。
四、nginx前端调度高可用实战
专题四：
对于一个大型网站来说，负载均衡是永恒的话题。随着硬件技术的迅猛发展，越来越多的负载均衡硬件设备涌现出来，如F5 BIG-IP、Citrix NetScaler、Radware等等，虽然可以解决问题，但其高昂的价格却往往令人望而却步，因此负载均衡软件仍然是大部分公司的不二之选。nginx作为webserver的后起之秀，其优秀的反向代理功能和灵活的负载均衡策略受到了业界广泛的关注。
nginx高可用拓扑图:
原理：nginx是高度模块化的应用程序，其中nginx_proxy模块即可实现负载均衡，将前端的用户请求通过调度算法分摊在后端的真实主机，达到均衡的效果。nginx_proxy也依赖于vrrp协议来实现VIP的自动分配和漂移，和keepalived不同的是nginx将不会生成ipvs规则，而是使用upstream模块将前端请求转发至后端。
实战部署：
VIP1:10.1.10.88
VIP2:10.1.10.99
RIP1:10.1.10.66
RIP2:10.1.10.67
要求：在配置过程中开启nginx的upstream模块，并代理到后端主机
示例图示：
配置vrrp实例后将遵循自动生成VIP地址及其自动实现地址漂移
模拟将后端一台服务器故障和全体故障的测试结果
实例中内嵌检测nginx健康状态检测脚本当nginx宕机时，则会自动将权重减去5，VIP地址漂移至优先级高的主机
总结：在所有的负载均衡调度中nginx配置最为简单而且高效，同时很灵活，所以可根据自己业务需求将选择合适自己企业的解决方案。
