软 件 学 院
毕业实训报告
课题名称： 基于keepalived实现LVS高可用以及WEB高可用
个人博客欢迎访问
http://djy0000.blog.51cto.com/
摘 要
随着企业信息系统的广泛应用和深入的发展，客户数量也在随着时间的推移而快速增长，此时企业中对高性能、高可用性的业务系统的要求也是日益提高。目前，越来越多的网站采用linux操作系统来提供各种服务，包括搭建Web服务器、Mail服务器、FTP服务器、文件存储等。人们对Linux服务器的可靠性、负载能力和计算能力也日益的关注紧密起来，企业对这方面的人才需求也是日益的增加。
本次项目的实现是以企业中Web服务器的相关搭建为出发点，主要实现的是对前端Web服务器的高可用以及在LVS机制下完成的Web服务器的负载均衡。第一章介绍的是关于项目实现的分析以及工作计划的安排与介绍；第二章与第三章主要包括的内容是对LVS、Keepalived进行理论知识点的介绍以及它们自身工作的架构图实现；第四章是对LVS中DR模型以及基于Keepalived对LVS高可用、对Web服务的高可用和双主模型的综合实现与验证。
整个项目的完成过程中老师与同学给予了我很大的帮助，也让我对一些错误的查找方式以及相关细节配置有了很多程度的认识与理解。总之，在实验项目的顺利完成下对一些细节性、易错性的知识有了一个系统性的处理方法以及综合性的认识，整体的实现也会为大家对高可用服务集群的理解带来一些帮助。
关键词：LVS； Keepalived； 高可用；负载均衡
目 录
摘 要 ............................................................................................................................................ II 第1章 项目分析 ........................................................................................................................... 1 1.1 问题描述 .............................................................................................................................. 1 1.2技术分析 ............................................................................................................................... 1 1.3项目进度计划 ....................................................................................................................... 1 第2章 虚拟服务器集群系统LVS与WEB服务 ...................................................................... 2 2.1 什么是LVS .......................................................................................................................... 2 2.2 LVS类型 ............................................................................................................................... 2 2.3 高可用架构体系分析 ......................................................................................................... 3 2.4 负载均衡实现方案 .............................................................................................................. 4 2.5 IP调度方法技术实现 .......................................................................................................... 5 2.6 IPVS实现负载均衡的三种方式 ......................................................................................... 6 2.7 负载调度器算法 .................................................................................................................. 7 2.8 LVS集群系统的优与缺 ....................................................................................................... 8 2.9 WEB服务器介绍 ................................................................................................................... 9 2.9.1 什么是Web服务器 ..................................................................................................... 9 2.9.2 Web服务器的工作原理 ............................................................................................... 9 2.9.3 apache相关介绍 .......................................................................................................... 9 2.9.2 Nginx相关介绍 ........................................................................................................... 12 第3章 KEEPALIVED介绍 ....................................................................................................... 15 3.1 KEEPALIVED是什么 ............................................................................................................. 15 3.2 KEEPALIVED作用 ................................................................................................................ 15 3.3 KEEPALIVED体系结构 ......................................................................................................... 15 3.4 KEEPALIVED工作原理 ......................................................................................................... 16 第4章 VRRP介绍 ..................................................................................................................... 17 4.1 VRRP是什么 ..................................................................................................................... 17 4.2 VRRP的认证机制 ............................................................................................................. 19 4.3 VRRP工作原理 ................................................................................................................. 19 4.4 VRRP的功能特性 ............................................................................................................. 21 第5章 实现与测试 ..................................................................................................................... 22 5.1 LVS的DR模型实现 ........................................................................................................ 22 5.1.1 实验设备介绍 ............................................................................................................. 22 5.1.2 实验拓扑图及其相关内容介绍 ................................................................................. 22 5.1.3 DR模型实现流程 ....................................................................................................... 23 5.1.4地址规划 ...................................................................................................................... 24 5.1.5配置流程 ...................................................................................................................... 24
5.2基于KEEPALIVED实现LVS高可用 .................................................................................. 28 5.3基于KEEPALIVED实现WEB服务的高可用 ....................................................................... 31 5.3.1实验拓扑图及其相关内容介绍 .................................................................................. 31 5.3.2 配置实现流程 ............................................................................................................. 31 5.4双主模式实现 ..................................................................................................................... 35 5.4.1实验拓扑图及其相关内容介绍 .................................................................................. 35 5.5 测试 .................................................................................................................................... 36 5.5.1 DR模型实验完成测试 .............................................................................................. 36 5.5.2 Keepalived实验结果测试 ......................................................................................... 37 5.5.3 高可用web服务器实验测试 .................................................................................... 38 5.5.4 双主模式实验测试 ..................................................................................................... 39 第6章 结束语 ............................................................................................................................. 43 附录B: 主要源程序 .................................................................................................................... 45
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
第1章 项目分析
在企业的运行中，LVS的负载均衡机制使得我们可以投入更少的成本并且可以让服务集群发挥更高的性能为客户服务；Keepalived起初是特意为LVS设计，用来监控集群服务中各Real Server节点的状态，来实现对LVS的高可用，继而单独通过keepalived完成生产环境中的对Web服务的高可用。
1.1 问题描述
项目实验是基于keepalived来实现LVS的高可用以及实现对Web服务的高可用。生产环境的高可用配置很大程度的保障了企业的正常运转；实验内容涉及的有对keepalived、LVS、VRRP等知识点的分析介绍，并且实现了LVS的高可用以及Web服务的高可用
1.2技术分析
随着企业中网站业务量的不断增长，网站的服务器的压力越来越大，生产环境中很需要一个合适的负载均衡方案，商业硬件在经济上对一些刚起步、小型公司是一笔很大的支出。而LVS就是一个很强大的负载均衡方案，可以为企业节省不必要的浪费，同时还可以实现一套行之有效的可伸张、可扩展的负载均衡方案；并且LVS+Keepalived是基于完整开源软件的架构，搭建负载均衡器及高可用服务器
1.3项目进度计划
项目的实现计划分为三部分实施，完成对各个模块的学习、理解、与综合关系实现 第一部分：分别对LVS、WEB服务、以及Keepalived进行理论知识点的理解，对它们在企业中的应用进行了解，并且进一步的进行知识梳理，直到自己可以对它们有系统性的认识，并且可以认知它们之间的联系思想上的构图
第二部分：在了解项目试验所需要应用的知识点后，开始对它们之间的关系进行架构分析；对每个模块之间的联系，每个模块之间可以如何进行很好的配备进行构图，为接下来的实验可以有一个清晰的实现思路
第三部分：经过对各个模块知识点的基本整理总结以及架构图实现后，开始实现高可用的实验，实验分别有LVS中DR模型的实现、Keepalived实现LVS的高可用、Web服务的高可用（其中有双主模型的介绍）。
1
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
第2章 虚拟服务器集群系统LVS与WEB服务
LVS是一个虚拟的服务器集群系统,本项目在1998年5月由章文嵩博士成立，是中国国内最早出现的自由软件项目之一。LVS集群采用IP负载均衡技术和基于内容请求分发技术;调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序
2.1 什么是LVS
LVS是LinuxVirtual Server的简写即是Linux虚拟服务器，是一个虚拟的服务器集群系统；进行对请求合理分配的调度器以及多台提供服务的实际运行的应用服务器组成，并且可以根据企业自身的需求对其进行合理，灵活的架构；在有众多客户端进行并发访问企业相关服务器的时候，LVS集群中的调度服务器可以将大量的服务请求根据调度器自身多种不同的算法进行合理的分发；从而实现基于IP，连接数以及访问量等多种类型的负载均衡。而且一旦集群中的某台真实服务器出现故障而不可用时，集群软件能够快速侦测到这一状况并将服务请求定向到其它的正在运行的应用服务器上
2.2 LVS类型
（1）LB:load Balancing：负载均衡集群--大容量、增加处理能力；例如：通过rsync完成web服务器之间的页面复制即在一台web服务器上存储页面，其他web服务器从此服务上进行同步；并且可以通过内核中inotify机制进行通知其他服务器页面变化情况；让其他服务器不用等到指定的同步时间进行同步，实行立即同步
（2）HA:High Availabilty：高可用集群--实时在线一年在线时间为99.999%；例如当一台服务器挂掉可以通过调度器重新发送请求，不会因为一台服务器的崩溃而导致整个服务器的的挂掉，可以继续提供服务；这种高可用能力是依赖前端服务器调度的（调度机制的分发请求可根据后端服务器的状态检测；前端主机也会通过周期性的检测来判断节点服务器的在线状态）
（3）HP(HPC):High Performance：高性能集群--具有超高级计算能力；例如：评估每秒钟的浮点计算能力等；应用领域一般都是科学计算、天气预报等一些大型数据计算;高性能计算集群采用将计算任务分配到集群的不同计算节点而提高计算能力，因而主要应用在科学计算领域。比较流行的HPC采用Linux操作系统和其它一些免费软件来完成并行运算。这
2
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
一集群配置通常被称为Beowulf集群。这类集群通常运行特定的程序以发挥HPC cluster的并行能力。这类程序一般应用特定的运行库, 比如专为科学计算设计的MPI库;高性能处理集群：利用的是分布式存储：分布式文件系统，分布式文件系统把一个大任务切割为小任务、分别进行处理
2.3 高可用架构体系分析
高可用架构体系结构仍然分为三层，在HA负载均衡层由主DS与备用DS构成双机热备系统，双机之间通过心跳信息连接。在正常状态下主DS使用虚拟IP接收用户请求，并根据用户请求，并根据设定好的策略和算法将请求发给各个服务器节点，备用DS负责监控主DS的运行状况。当主DS发生异常时，备用DS会马上接过主DS的工作，负责对用户请求并发处理。通过这种相互监控策略，任意一方主机出现故障时，另一方能够将IP和服务接管，这样就保证了负载均衡层的工作请求的不间断运行 如图2.1所示
图2.1 高可用LVS集群系统结构图
3
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
2.4 负载均衡实现方案
（1）基于客户端的解决方法
需要每个客户程序都有一定的服务器集群的知识，进而把以负载均衡的方式将请求发到不同的服务器。例如，Netscape Navigator浏览器访问Netscape的主页时，它会随机地从一百多台服务器中挑选第N台，最后将请求送往wwwN.netscape.com。然而，这不是很好的解决方法，Netscape只是利用它的Navigator避免了RR-DNS解析的麻烦，当使用IE等其他浏览器不可避免的要进行RR-DNS解析。
Smart Client是Berkeley做的另一种基于客户端的解决方法。服务提供一个Java Applet在客户方浏览器中运行，Applet向各个服务器发请求来收集服务器的负载等信息，再根据这些信息将客户的请求发到相应的服务器。高可用性也在Applet中实现，当服务器没有响应时，Applet向另一个服务器转发请求。这种方法的透明性不好，Applet向各服务器查询来收集信息会增加额外的网络流量，不具有普遍的适用性
（2）基于应用层系统负载的调度方法
多台服务器通过高速的互联网络连接成一个集群系统，在前端有一个基于应用层的负载调度器。当用户访问请求到达调度器时，请求会提交给作负载均衡调度的应用程序，分析请求，根据各个服务器的负载情况，选出一台服务器，重写请求并向选出的服务器访问，取得结果后，再返回给用户。
应用层负载均衡调度的典型代表有Zeus负载调度器、pWeb、Reverse-Proxy和SWEB等。Zeus负载调度器是Zeus公司的商业产品，它是在Zeus Web服务器程序改写而成的，采用单进程事件驱动的服务器结构。pWeb就是一个基于Apache 1.1服务器程序改写而成的并行WEB调度程序，当一个HTTP请求到达时，pWeb会选出一个服务器，重写请求并向这个服务器发出改写后的请求，等结果返回后，再将结果转发给客户。Reverse-Proxy利用Apache 1.3.1中的Proxy模块和Rewrite模块实现一个可伸缩WEB服务器，它与pWeb的不同之处在于它要先从Proxy的cache中查找后，若没有这个副本，再选一台服务器，向服务器发送请求，再将服务器返回的结果转发给客户。SWEB是利用HTTP中的redirect错误代码，将客户请求到达一台WEB服务器后，这个WEB服务器根据自己的负载情况，自己处理请求，或者通过redirect错误代码将客户引到另一台WEB服务器，以实现一个可伸缩的WEB服务器。多服务器解决方法也存在一些问题。第一，系统处理开销特别大，致使系统的伸缩性有限。当请求到达负载均衡调度器至处理结束时，调度器需要进行四次从核心到用
4
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
户空间或从用户空间到核心空间的上下文切换和内存复制；需要进行二次TCP连接，一次是从用户到调度器，另一次是从调度器到真实服务器；需要对请求进行分析和重写。这些处理都需要不小的ＣＰＵ、内存和网络等资源开销，且处理时间长。所构成系统的性能不能接近线性增加的，一般服务器组增至3或4台时，调度器本身可能会成为新的瓶颈。所以，这种基于应用层负载均衡调度的方法的伸缩性极其有限。第二，基于应用层的负载均衡调度器对于不同的应用，需要写不同的调度器。 （3）基于IP地址的调度方法
用户通过虚拟IP地址（Virtual IP Address）访问服务时，访问请求的报文会到达负载调度器，由它进行负载均衡调度，从一组真实服务器选出一个，将报文的目标地址Virtual IP Address改写成选定服务器的地址，报文的目标端口改写成选定服务器的相应端口，最后将报文发送给选定的服务器。真实服务器的回应报文经过负载调度器时，将报文的源地址和源端口改为Virtual IP Address和相应的端口，再把报文发给用户。Berkeley的Magic Router、Cisco的Local Director、Alteon的ACE Director和F5的Big/IP等都是使用网络地址转换方法。Magic Router是在Linux 1.3版本上应用快速报文插入技术，使得进行负载均衡调度的用户进程访问网络设备接近核心空间的速度，降低了上下文切换的处理开销，但并不彻底，它只是研究的原型系统，没有成为有用的系统存活下来。Cisco的Local Director、Alteon的ACE Director和F5的Big/IP是非常昂贵的商品化系统，它们支持部分TCP/UDP协议，有些在ICMP处理上存在问题。
2.5 IP调度方法技术实现
LVS的IP负载均衡技术是通过IPVS模块实现，IPVS是安装在Director Server上的一个核心软件，通过在Director Server上虚拟出一个IP地址即VIP；客户端可通过这个虚拟的IP地址来访问服务器，当客户端请求通过访问VIP地址到的DirectorServer上后，然后根据负载调度器上的各种算法分发客户端请求到相对空闲或者是处理效率较高、性能较好的Real Server上。
调度器是服务器集群系统的唯一入口点（Single Entry Point），它可以采用IP负载均衡技术、基于内容请求分发技术或者两者相结合。在IP负载均衡技术中，需要服务器池拥有相同的内容提供相同的服务。当客户请求到达时，调度器只根据服务器负载情况和设定的调度算法从服务器池中选出一个服务器，将该请求转发到选出的服务器，并记录这个调度；当这个请求的其他报文到达，也会被转发到前面选出的服务器。在基于内容请求分发技术中，服务器可以提供不同的服务，当客户请求到达时，调度器可根据请求的内容选择服务
5
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
器执行请求。因为所有的操作都是在Linux操作系统核心空间中将完成的，它的调度开销很小，所以它具有很高的吞吐率。服务器池的结点数目是可变的。
当整个系统收到的负载超过目前所有结点的处理能力时，可以在服务器池中增加服务器来满足不断增长的请求负载。对大多数网络服务来说，请求间不存在很强的相关性，请求可以在不同的结点上并行执行，所以整个系统的性能基本上可以随着服务器池的结点数目增加而线性增长。 共享存储通常是数据库、网络文件系统或者分布式文件系统。服务器结点需要动态更新的数据一般存储在数据库系统中，同时数据库会保证并发访问时数据的一致性。静态的数据可以存储在网络文件系统（如NFS/CIFS）中，但网络文件系统的伸缩能力有限，一般来说，NFS/CIFS服务器只能支持3~6个繁忙的服务器结点。对于规模较大的集群系统，可以考虑用分布式文件系统，如AFS、GFS、Coda和Intermezzo等。分布式文件系统可为各服务器提供共享的存储区，它们访问分布式文件系统就像访问本地文件系统一样，同时分布式文件系统可提供良好的伸缩性和可用性。此外，当不同服务器上的应用程序同时读写访问分布式文件系统上同一资源时，应用程序的访问冲突需要消解才能使得资源处于一致状态。这需要一个分布式锁管理器（Distributed Lock Manager），它可能是分布式文件系统内部提供的，也可能是外部的。开发者在写应用程序时，可以使用分布式锁管理器来保证应用程序在不同结点上并发访问的一致性
2.6 IPVS实现负载均衡的三种方式
（1） VS/NAT:Virtual Server via Network AddressTranslation；调度器通过将请求报文的目标地址（VIP）改写成选定的RealServer地址，同时将报文的目标端口也改写成指定的Real Server的相应端口，最终将报文请求发送到选定的Real Server 上。Real Server将报文数据返回给客户端时，需要经过负载均衡器将报文源地址和源端口改写成Director Server上的VIP地址和相应端口，然后通过DirectorServer将报文数据返回给客户端
（2）VS/DR:Virtual Server via Direct Routing,DR方式通过改写请求的MAC地址通过Director Server将请求发送到Real Server，然后Real Server直接将客户端请求响应给客户端，Director Server只是做客户端请求的处理；其性能较好，也是应用最多的一种方式，DR方式中Director Server的DIP与Real Server的RIP在同一网段内直接路由模式；其原理为是DR和REALSERVER都使用同一个IP对外服务｡但只有DR对ARP请求进行响应,所有REALSERVER对本身这个IP的ARP请求保持静默｡也就是说,网关会把对这个服务IP的请求全部定向给DR,而DR收到数据包后根据调度算法,找出对应的REALSERVER,把目的MAC地址改为REALSERVER的MAC并发给这台REALSERVER｡这时
6
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
REALSERVER收到这个数据包,则等于直接从客户端收到这个数据包无异,处理后直接返回给客户端。
（3）VS/TUN:Virtual Server via IP Tunncling;客户端请求发送到Director Server上，然后调度器采用IP隧道技术将用户请求转送到远程的Real Server上，Real Server接受报文直接响应给客户端，TUN与DR不同点在于DR中的DIP与RIP在同一个网段，而TUN实现了DIP与RIP相异两地的情况直接路由模式
2.7 负载调度器算法
(1) 轮叫调度（Round Robin）
“轮叫”调度算法也可称为1:1调度算法；就是以轮叫的方式请求不同的服务器，算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。轮叫调度算法假设所有服务器处理性能均相同，不管服务器的当前连接数和响应速度。该算法相对简单，不适用于服务器组中处理性能不一的情况，而且当请求服务时间变化比较大时，轮叫调度算法容易导致服务器间的负载不平衡。
(2) 加权轮叫（Weighted Round Robin）
“加权轮叫”调度算法根据RealServer的不同处理能力来调度客户端访问请求，可以对每台Real Server配置不同的权值；权越高处理的客户端请求越多；这样可以保证处理能力强的Real Server能处理更多的访问流量。Director Server也可以自动问询Real Server的负载情况，并动态地调整其权值
(3) 最少链接（Least Connections）
“最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。适用于具有相近系统性能的Real Server
(4) 加权最少链接（Weighted Least Connections）
“加权最少链接”调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载，适用于在性能方面相差较大的Real Server
(5) 基于局部性的最少链接（Locality-Based Least Connections）
“基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡，根据请求的目标IP地址找出该目标IP地址最近使用的Real Server，若该Real Server是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用“最少链接”的原则选出一个可用的服务器，将请求发送到该服务器
7
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
(6) 带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）
“带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡，该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按“最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度
(7) 目标地址散列（Destination Hashing）
“目标地址散列”调度算法根据请求的目标IP地址，作为散列键（HashKey）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空
(8) 源地址散列（Source Hashing）
源地址散列调度算法正好与目标地址散列调度算法相反，它根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法的相同。
通过源地址hash，使来自于同一个客户端的请求，都转发给同一个Real Server，这样来保证cookie与session进行会话绑定
2.8 LVS集群系统的优与缺
LVS是一款自由软件，任何人都可以免费获取并使用它，而且Linux也是一个开源软件操作系统，这两者的组合大大节约了企业的应用成本。并且LVS具有高可用于高可靠性，在高并发和高吞吐量下，具有高负荷处理能力，当某个服务节点出现故障时，并不影响整个系统服务的正常运行。
LVS也不是十全十美的，它也有“瑕疵“，所有的用户请求都经过DS，当只有一台DS时，会出现单点故障点，如果此时DS出现故障，那整个系统将陷入瘫痪状态。
有缺点就要找方法克服，对于一个强大的集群系统来说，单点故障点是绝对不允许的，因此，最简单最实用的方法就是将DS做成高可用集群，常见的方法是为DS做一个双机热备：正常状态下主DS工作，备用DS监控主DS的状态，当主DS出现故障或异常时，备用DS会马上接过主DS的工作，负责对用户请求并发处理。
8
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
2.9 web服务器介绍
2.9.1 什么是Web服务器
WEB服务器也称为WWW(WORLD WIDE WEB)服务器，主要功能是提供网上信息浏览服务。 WWW 是 Internet 的多媒体信息查询工具，是 Internet 上近年才发展起来的服务，也是发展最快和目前用的最广泛的服务。正是因为有了WWW工具，才使得近年来 Internet 迅速发展，且用户数量飞速增长。Web服务器是指驻留于因特网上某种类型计算机的程序。当Web浏览器（客户端）连到服务器上并请求文件时，服务器将处理该请求并将文件反馈到该浏览器上，附带的信息会告诉浏览器如何查看该文件（即文件类型） 2.9.2 Web服务器的工作原理
Web服务器的工作原理并不复杂，一般可分成如下4个步骤：连接过程、请求过程、应答过程以及关闭连接。下面对这4个步骤作一简单的介绍。连接过程就是Web服务器和其浏览器之间所建立起来的一种连接。查看连接过程是否实现，用户可以找到和打开socket这个虚拟文件，这个文件的建立意味着连接过程这一步骤已经成功建立。请求过程就是Web的浏览器运用socke这个文件向其服务器而提出各种请求。应答过程就是运用HTTP协议把在请求过程中所提出来的请求传输到Web的服务器，进而实施任务处理，然后运用HTTP协议把任务处理的结果传输到Web的浏览器，同时在Web的浏览器上面展示上述所请求之界面。关闭连接就是当上一个步骤--应答过程完成以后，Web服务器和其浏览器之间断开连接之过程。Web服务器上述4个步骤环环相扣、紧密相联，逻辑性比较强，可以支持多个进程、多个线程以及多个进程与多个线程相混合的技术 2.9.3 apache相关介绍 （1） apache发展简介
Apache 起初由伊利诺伊大学香槟分校的国家超级电脑应用中心（NCSA）开发。此后，Apache 被开放源代码团体的成员不断的发展和加强。Apache 服务器拥有牢靠可信的美誉，已用在超过半数的因特网站中－特别是几乎所有最热门和访问量最大的网站。
开始，Apache只是Netscape网页服务器（现在是Sun ONE）之外的开放源代码选择。渐渐的，它开始在功能和速度超越其他的基于Unix的HTTP服务器。1996年4月以来，Apache一直是Internet上最流行的HTTP服务器: 1999年5月它在 57% 的网页服务器上运行；到了2005年7月这个比例上升到了69%。在2005年11月的时候达到接近70%的
9
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
市占率，不过随着拥有大量域名数量的主机域名商转换为微软IIS平台，Apache市占率近年来呈现些微下滑。而Google自己的网页服务器平台GWS推出后，加上Lighttpd这 个轻量化网页服务器软件使用的网站慢慢增加，反应在整体网页服务器市占率上，根据netcraft在2007年7月的最新统计数据，Apache的市占率已经降为52.65%，8月时又滑落到50.92%。尽管如此，它仍旧是现阶段因特网市场上，市占率最高的网页服务器软件。
广的解释是（也是最显而易见的）:这个名字来自这么一个事实:当Apache在1995年初开发的时候，它是由当时最流行的HTTP服务器NCSA HTTPd 1.3 的代码修改而成的，因此是“一个修补的（a patchy）”服务器。然而在服务器官方网站的FAQ中是这么解释的:“„Apache‟这个名字是为了纪念名为Apache(印地语)的美洲印第安人土著的一支，众所周知他们拥有高超的作战策略和无穷的耐性”。无论如何，Apache 2.x 分支不包含任何 NCSA 的代码
（2）apache软件拥有的特性介绍
支持最新的HTTP/1.1通信协议
拥有简单而强有力的基于文件的配置过程 支持通用网关接口
支持基于IP和基于域名的虚拟主机 支持多种方式的HTTP认证 集成Perl处理模块 集成代理服务器模块
支持实时监视服务器状态和定制服务器日志 支持服务器端包含指令(SSI) 支持安全Socket层(SSL) 提供用户会话过程的跟踪 支持FastCGI （3）apache程序结构
DSO是Dynamic Shared Objects（动态共享目标）的缩写，它是现代Unix派生出来的操作系统都存在着的一种动态连接机制。它提供了一种在运行时将特殊格式的代码，在程序 运行需要时，将需要的部分从外存调入内存执行的方法。Apache在1.3以后的版本后开始支持它。因为Apache早就使用一个模块概念来扩展它的功能 并且在内部使用一个基于调度的列表来链接扩展模块到Apache核心模块。
10
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
Apache本身这是一个很复杂的四层结构--每一层构建在下一层之上。第四层是用Apache模块开发的第三方库--比如open ssl一般来说在Apache的官方发行版中这层是空的，但是在实际的Apache结构中这些库构成的层结构肯定是存在的。第三层是一些可选的附加功能模块--如mod_ssl,mod_perl。这一层的每个模块通常实现的是Apache的一个独立的分离的功能，而这些模块没有一个是必须的，运行一个最小的Apache不需要任何一个此层的模块。第二层是Apache的基本功能库-这也是Apache的核心本质层--这层包括Apache内核，http_core(Apache的核心模 块）,它们实现了基本HTTP功能（比如资源处理（通过文件描述符和内存段等等），保持预生成（pre-forked)子进程模型，监听已配置的虚拟服务 器的TCP/IP套接字，传输HTTP请求流到处理进程，处理HTTP协议状态，读写缓冲，此外还有附加的许多功能比如URL和MIME头的解析及DSO 的装载等），也提供了Apache的应用程序接口（API)（其实Apache的真正功能还是包含在内部模块中的，为了允许这些模块完全控制Apache 进程，内核必须提供API接口）,这层也包括了一般性的可用代码库（libap)和实现正则表达式匹配的库（libregex)还有就是一个小的操作系统 的抽象库（libos)。最低层是与OS相关的平台性应用函数
在这个复杂的程序结构中有趣的部分是---事实上第三层和第四层与第二层之间是松散的连接，而另一方面第三层的模块间是互相依赖的--因这种结构造成的显著影响就是第三层和第四层的代码不能静态地连接到最低层平台级的代码上。因此DSO模式就成了解决它的一种手段。结合DSO功能，这个结构就变 得很灵活了，可以让Apache内核（mod_so模块）在启动时（不是安装）装载必要的部分以实现第三层和第四层的功能。
（4）DSO动态加载介绍
第一种方法在可执行文件启动时由系统程序ld.so自动加：DSO通常被称为共享库(shared libraries)或者DSO库(DSO libraries)，使用libfoo.so或者libfoo.so.1.2的文件名，被存储在系统目录中(通常是/usr/lib)，并在编译安装 时，使用连接器参数-lfoo建立了指向可执行程序的连接。通过设置连接器参数-R或者环境变量LD_LIBRARY_PATH，库中硬编码了可执行文件 的路径，使Unix加载器能够定位到位于/usr/lib的libfoo.so，以解析可执行文件中尚未解析的位于DSO的符号。通常，DSO不会引用可执行文件中的符号(因为它是通用代码的可重用库)，也不会有后继的解析动作。可执行文件无须自己作任何动作以使用DSO 中的符号，而完全由Unix加载器代办(事实上，调用ld.so的代码是被连入每个可执行文件的非静态运行时刻启动代码的一部分)。动态加载公共库代码的 优点是明显的：只需要在系统库libc.so中存储一个库代码，从而为每个程序节省了磁盘存储空间。
第二种方法在执行程序中手工地通过Unix加载器的系统接口执行系统调：DSO
11
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
通常被称为共享对象(shared objects)或者DSO文件(DSO files)，可以使用任何文件名(但是规范的名称是foo.so)，被存储在程序特定的目录中，也不会自动建立指向其所用的可执行文件的连接，而由可执 行文件在运行时自己调用dlopen()来加载DSO到其地址空间，同时也不会进行为可执行文件解析DSO中符号的操作。Unix加载器会根据可执行程序 的输出符号表和已经加载的DSO库自动解析DSO中尚未解析的符号(尤其是无所不在的libc.so中的符号)，如此DSO就获得了可执行程序的符号信息，就好象是被静态连接的。 2.9.2 Nginx相关介绍
（1）什么是Nginx
nginx是俄罗斯软件工程师Igor Sysoev开发的免费开源web服务器软件。nginx于2004年发布，聚焦于高性能，高并发和低内存消耗问题。并且具有多种web服务器功能特性：负载均衡，缓存，访问控制，带宽控制，以及高效整合各种应用的能力，这些特性使nginx很适合于现代网站架构。目前，nginx已经是互联网上第二流行的开源web服务器软件 （2）Nginx架构介绍
传统基于进程或线程的模型使用单独的进程或线程处理并发连接，因而会阻塞于网络或I/O操作。根据不同的应用，就内存和CPU而言，这是非常低效的。派生进程或线程需要准备新的运行环境，包括在内存上分配堆和栈、生成一个新的运行上下文。创建这些东西还需要额外的CPU时间，而且过度的上下文切换引起的线程抖动最终会导致性能低下。所有这些复杂性在如Apache web服务器的老架构上一览无遗。在提供丰富的通用应用功能和优化服务器资源使用之间需要做一个权衡。
最早的时候，nginx希望为动态增长的网站获得更好的性能，并且密集高效的使用服务器资源，所以其使用了另外一个模型。受不断发展的在不同操作系统上开发基于事件模型的技术驱动，最终一个模块化，事件驱动，异步，单线程，非阻塞架构成为nginx代码的基础。
Nginx大量使用多路复用和事件通知，并且给不同的进程分配不同的任务。数量有限的工作进程（Worker）使用高效的单线程循环处理连接。每个worker进程每秒可以处理数千个并发连接、请求 （3）Nginx代码结构
Nginx worker的代码包含核心和功能模块。核心负责维护一个紧凑的事件处理循环，并且在请求处理的每个阶段执行对应的模块代码段。模块完成了大部分展现和应用层功能。包括从网络和存储设备读取、写入，转换内容，进行输出过滤，SSI(server-side include)
12
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
处理，或者如果启用代理则转发请求给后端服务器。
nginx模块化的架构允许开发者扩展web服务器的功能，而不需要修改nginx核心。Nginx模块可分为：核心、事件模块，阶段处理器，协议、变量处理器，过滤器，上游和负载均衡器等。目前，nginx不支持动态加载模块，即模块代码是和nginx核心代码一起编译的。模块动态加载和ABI已经计划在将来的某个版本开发
Nginx在Linux、Solaris和BSD系统上使用kqueue、epoll和event ports等技术，通过事件通知机制来处理网络连接和内容获取，包括接受、处理和管理连接，并且大大增强了磁盘IO性能。目的在于尽可能的提供操作系统建议的手段，用于从网络进出流量，磁盘操作，套接字读取和写入，超时等事件中及时异步地获取反馈。Nginx为每个基于Unix的操作系统大量优化了这些多路复用和高级I/O操作的方法 （4）Nginx的工作进程模型
nginx不为每个连接派生进程或线程，而是由worker进程通过监听共享套接字接受新请求，并且使用高效的循环来处理数千个连接。Nginx不使用仲裁器或分发器来分发连接，这个工作由操作系统内核机制完成。监听套接字在启动时就完成初始化，worker进程通过这些套接字接受、读取请求和输出响应。
事件处理循环是nginx worker代码中最复杂的部分，它包含复杂的内部调用，并且严重依赖异步任务处理的思想。异步操作通过模块化、事件通知、大量回调函数以及微调定时器等实现。总的来说，基本原则就是尽可能做到非阻塞。Nginx worker进程唯一会被阻塞的情形是磁盘性能不足。
由于nginx不为每个连接派生进程或线程，所以内存使用在大多数情况下是很节约并且高效的。同时由于不用频繁的生成和销毁进程或线程，所以nginx也很节省CPU时间。Nginx所做的就是检查网络和存储的状态，初始化新连接并添加到主循环，异步处理直到请求结束才从主循环中释放并删除。兼具精心设计的系统调用和诸如内存池等支持接口的精确实现，nginx在极端负载的情况下通常能做到中低CPU使用率。
nginx派生多个worker进程处理连接，所以能够很好的利用多核CPU。通常一个单独的worker进程使用一个处理器核，这样能完全利用多核体系结构，并且避免线程抖动和锁。在一个单线程的worker进程内部不存在资源匮乏，并且资源控制机制是隔离的。这个模型也允许在物理存储设备之间进行扩展，提高磁盘利用率以避免磁盘I/O导致的阻塞。将工作负载分布到多个worker进程上最终能使服务器资源被更高效的利用。
针对某些磁盘使用和CPU负载的模式，nginx worker进程数应该进行调整。这里的规
13
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
则比较基本，系统管理员应根据负载多尝试几种配置。通常推荐：如果负载模式是CPU密集型，例如处理大量TCP/IP协议，使用SSL，或者压缩数据等，nginx worker进程应该和CPU核心数相匹配；如果是磁盘密集型，例如从存储中提供多种内容服务，或者是大量的代理服务，worker的进程数应该是1.5到2倍的CPU核心数。一些工程师基于独立存储单元的数目来决定worker进程数，虽然这个方法的有效性取决于磁盘存储配置的类型，。
Nginx开发者在下个版本中要解决的一个主要问题是怎么避免磁盘I/O引起的阻塞。目前，如果没有足够的存储性能为一个worker进程的磁盘操作提供服务，这个进程就会阻塞在磁盘读写操作上。一些机制和配置指令用于缓解这个磁盘I/O阻塞的场景，最显著的是sendfile和AIO指令，这通常可以降低许多磁盘利用率。应该根据数据集（data set），可用内存数，以及底层存储架构等来规划安装nginx。
当前的worker模型的另一个问题是对嵌入脚本的支持有限。举例来说，标准的nginx发布版只支持Perl作为嵌入脚本语言。这个原因很简单：嵌入脚本很可能会在任何操作上阻塞或者异常退出，这两个行为都会导致worker进程挂住而同时影响数千个连接。将脚本更简单，更可靠地嵌入nginx，并且更适合广泛应用的工作已经列入计划 （5）nginx发展优势
部署nginx最关键的好处就是能够高性能高效的处理高并发。同时，还有更多有意思的好处。web架构拥抱解耦的理念并且将应用层设施从web服务器中分离。虽然现在仅仅是将原先基于LAMP(Linux, Apache, MySQL, PHP, Python or Perl)所构建的网站，变为基于LEMP（E表示Engine x）的。但是，越来越多的实践是将web服务器推入基础设施的边缘，并且用不同的方法整合这些相同或更新的应用和数据库工具集。
Nginx很适合做这些工作。他提供了必要的关键功能用于方便将下列功能从应用层剥离到更高效的边缘web服务器层：并发、长连接处理、SSL，静态内容、压缩和缓存、连接和请求限速，以及HTTP媒体流等。Nginx同时也允许直接整合memcached、Redis或者其他的NoSQL解决方案，增强为处理大规模并发用户的性能。随着现代编程语言和开发包广泛使用，越来越多的公司改变了应用开发和部署的方式。Nginx已经成为这些改变范例之中的最重要的部件之一，并且已经帮助许多公司在预算内快速启动和开发他们的web服务。
14
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
第3章 Keepalived介绍
3.1 keepalived是什么
keepalived的是一个路由软件用C语言编写的，这个项目的主要目标是提供简单的设施和强大的负载平衡和高可用性Linux系统和基于Linux的基础设施。负载平衡框架依赖于知名的和广泛使用的Linux虚拟服务器（IPVS）的 内核模块提供层4负载平衡。keepalived实现了一套动态自适应维护和管理loadbalanced的服务器。另一方面，高可用性VRRP协议来实现 。VRRP路由器故障转移是一个根本性的应用。此外，keepalived的VRRP有限状态机提供低层次的和高速的协议交互实现了一套钩子，keepalived的框架，可以独立使用，或全部在一起，以提供弹性的基础设施
keepalived是一个类似于layer3, 4 & 5交换机制的软件，也就是我们平时说的第3层、第4层和第5层交换。Keepalived的作用是检测web服务器的状态，如果有一台web服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除，当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的web服务器。
3.2 Keepalived作用
Keepalived起初是特意为LVS设计，用来监控集群服务中各Real Server节点的状态，根据Layer3,4,5交换机制检查每个服务节点的状态；当某个服务节点出现故障，Keepalived检测到后将这个故障节点从服务中剔除；当故障节点重新恢复到正常状态后，Keepalived可根据自身机制自动将服务加进集群服务添加到集群服务列表中；后来Keepalived加入了VRRP功能，使得现在的Keepalived具有服务器运行检测功能与HA Cluster功能。
3.3 keepalived体系结构
（1）WatchDog 负责监控checkers和VRRP进程的状况。
（2）Checkers 负责真实服务器的监控检查healthchecking 是keepalived最主要的功能 （3）VRRP Stack 负责负责均衡器之间的失败切换Failover,如果只用一个负载均衡器，则VRRP不是必须得
（4）IPVS wrapper 用来发送设定的规则到内核ipvs代码 （5）Netlink Reflector 用来设定vrrp的vip 地址
15
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
3.4 keepalived工作原理
Layer3,4&5工作在IP/TCP协议栈的IP层，TCP层，及应用层,原理分别如下： Layer3：Keepalived使用Layer3的方式工作式时，Keepalived会定期向服务器群中的服务器 发送一个ICMP的数据包（既我们平时用的Ping程序）,如果发现某台服务的IP地址没有激活，Keepalived便报告这台服务器失效，并将它从服务器群中剔除，这种情况的典型例子是某台服务器被非法关机。Layer3的方式是以服务器的IP地址是否有效作为服务器工作正常与否的标准。
Layer4: Layer4主要以TCP端口的状态来决定服务器工作正常与否。如web server的服务端口一般是80，如果Keepalived检测到80端口没有启动，则Keepalived将把这台服务器从服务器群中剔除。
Layer5：Layer5就是工作在具体的应用层了，比Layer3,Layer4要复杂一点，在网络上占用的带宽也要大一些。Keepalived将根据用户的设定检查服务器程序的运行是否正常，如果与用户的设定不相符，则Keepalived将把服务器从服务器群中剔除
16
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
第4章 VRRP介绍
4.1 VRRP是什么
VRRP：Virtual Router Redundancy Protocol，虚拟路由冗余协议，是一种选择协议，它可以把一个虚拟路由器的责任动态分配到局域网上的 VRRP 路由器中的一台。控制虚拟路由器 IP 地址的 VRRP 路由器称为主路由器，它负责转发数据包到这些虚拟 IP 地址。一旦主路由器不可用，这种选择过程就提供了动态的故障转移机制，这就允许虚拟路由器的 IP 地址可以作为终端主机的默认第一跳路由器。使用 VRRP 的好处是有更高的默认路径的可用性而无需在每个终端主机上配置动态路由或路由发现协议。 VRRP 包封装在 IP 包中发送。也可以理解：“VRRP说白了就是实现地址漂移的，是一种容错协议，在提高可靠性的同时，简化了主机的配置。该协议能够实现将可以承担网关功能的一组路由器加入到备份组中，形成一台虚拟路由器，由VRRP的选举机制决定哪台路由器承担转发任务，局域网内的主机只需将虚拟路由器配置为缺省网关。”VRRP它可以把一个虚拟路由器的责任动态分配到局域网上的 VRRP 路由器中的一台。控制虚拟路由器 IP 地址的 VRRP 路由器称为主路由器，它负责转发数据包到这些虚拟 IP 地址。VRRP（Virtual Routing Redundant Protocol）可以通过在多台路由器组合成一个虚拟路由组(一个VRRP组)之间共享一个虚拟IP(VIP)解决静态配置的问题，此时仅需要客户端以VIP作为其默认网关即可，虚拟IP配置在哪个路由设备上取决于VRRP的工作机制，实现网关地址漂移；MASTER与BACKUP设备之间有优先级设定，数字越大优先级越高，通过各节点之间不停的传送通告信息来确认对方是否在线；当MASTER宕机的时候，虚拟IP会漂移到备用路由上，实现前端网关的高可用; VRRP中一主多从模式如图4.1所示。
17
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
图4.1 VRRP中一主多从模式
通常，同一网段内的所有主机都设置一条相同的、以网关为下一跳的缺省路由。主机发往其他网段的报文将通过缺省路由发往网关，再由网关进行转发，从而实现主机与外部网络的通信。当网关发生故障时，本网段内所有以网关为缺省路由的主机将无法与外部网络通信，仅能实现内部主机间通信。缺省路由为用户的配置操作提供了方便，但是对缺省网关设备提出了很高的稳定性要求。增加出口网关是提高系统可靠性的常见方法，此时如何在多个出口之间进行选路就成为需要解决的问题。而VRRP正好解决了此问题。在VRRP协议出现之前，为了不让单个路由器成为本地与外部通信的瓶颈，我们需要有多个路由，在此种模式下，我们内部的主机就需要将自己的网关指向不同的路由器，这样的配置对我们的网关管理员来说是很麻烦的，且不容易实现。在VRRP协议出现后，为了不让单个路由器成为本地与外部通信的瓶颈，我们仍需要有多个路由，但可以使用同一个缺省网关，我们只需将内部主机指定一个缺省网关即可。VRRP协议会根据优先级来选择一个正常的路由作为主路由器实现与外部的通信，而其他路由则作为备份路由不参与转发。在此模式下，多个路由器组成虚拟路由器组，物理上是多个路由器组成，但在逻辑上却是表现为只有一个路由。VRRP根据优先级来确定备份组中每台路由器的角色（Master 路由器或Backup
18
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
路由器）。优先级越高，则越有可能成为Master 路由器。VRRP优先级的可配置的取值范围为1 到254。
4.2 VRRP的认证机制
为了防止非法用户构造报文攻击备份组，VRRP通过在VRRP报文中增加认证字的方式，验证接收到的VRRP报文。VRRP提供了两种认证方式：
simple：简单字符认证。发送VRRP 报文的路由器将认证字填入到VRRP 报文中，而收到VRRP 报文的路由器会将收到的VRRP 报文中的认证字和本地配置的认证字进行比较。如果认证字相同，则认为接收到的报文是真实、合法的VRRP 报文；否则认为接收到的报文是一个非法报文。
md5：MD5 认证。发送VRRP 报文的路由器利用认证字和MD5 算法对VRRP 报文进行摘要运算，运算结果保存在Authentication Header（认证头）中。收到VRRP 报文的路由器会利用认证字和MD5 算法进行同样的运算，并将运算结果与认证头的内容进行比较。如果相同，则认为接收到的报文是真实、合法的VRRP 报文；否则认为接收到的报文是一个非法报文。
4.3 VRRP工作原理
一个VRRP路由器有唯一的标识：VRID，范围为0—255。该路由器对外表现为唯一的虚拟MAC地址，地址的格式为00-00-5E-00-01-[VRID]。主控路由器负责对ARP请求用该MAC地址做应答。这样，无论如何切换，保证给终端设备的是唯一一致的IP和MAC地址，减少了切换对终端设备的影响。
VRRP控制报文只有一种：VRRP通告(advertisement)。它使用IP多播数据包进行封装，组地址为224.0.0.18，发布范围只限于同一局域网内。这保证了VRID在不同网络中可以重复使用。为了减少网络带宽消耗只有主控路由器才可以周期性的发送VRRP通告报文。备份路由器在连续三个通告间隔内收不到VRRP或收到优先级为0的通告后启动新的一轮VRRP选举。
在VRRP路由器组中，按优先级选举主控路由器，VRRP协议中优先级范围是0—255。若VRRP路由器的IP地址和虚拟路由器的接口IP地址相同，则称该虚拟路由器作VRRP组中的IP地址所有者；IP地址所有者自动具有最高优先级：255。优先级0一般用在IP地址所有者主动放弃主控者角色时使用。可配置的优先级范围为1—254。优先级的配置原则
19
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
可以依据链路的速度和成本、路由器性能和可靠性以及其它管理策略设定。主控路由器的选举中，高优先级的虚拟路由器获胜，因此，如果在VRRP组中有IP地址所有者，则它总是作为主控路由的角色出现。对于相同优先级的候选路由器，按照IP地址大小顺序选举。VRRP还提供了优先级抢占策略，如果配置了该策略，高优先级的备份路由器便会剥夺当前低优先级的主控路由器而成为新的主控路由器。
为了保证VRRP协议的安全性，提供了两种安全认证措施：明文认证和IP头认证。明文认证方式要求：在加入一个VRRP路由器组时，必须同时提供相同的VRID和明文密码。适合于避免在局域网内的配置错误，但不能防止通过网络监听方式获得密码。IP头认证的方式提供了更高的安全性，能够防止报文重放和修改等攻击
总而言之VRRP的工作机制是实现网关地址漂移；MASTER与BACKUP设备之间有优先级设定，数字越大优先级越高，通过各节点之间不停的传送通告信息来确认对方是否在线；在实现网关的漂移以及优先级设定时可以实现多主模式，即有多个虚拟IP；每个虚拟IP相对在某一个虚拟主机优先级是最高的；当其中的一个MASTER宕机的时候，虚拟IP会漂移到其他Master主机上，实现前端网关的高可用及负载; VRRP中多主模式如图4.2所示。
20
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
图4.2 VRRP多主模式结构
4.4 VRRP的功能特性
冗余：可以使用多个路由器设备作为LAN客户端的默认网关，大大降低了默认网关成为单点故障的可能性；
负载共享：允许来自LAN客户端的流量由多个路由器设备所共享； 多VRRP组：在一个路由器物理接口上可配置多达255个VRRP组；
多IP地址：基于接口别名在同一个物理接口上配置多个IP地址，从而支持在同一个物理接口上接入多个子网；
抢占：在master故障时允许优先级更高的backup成为master； 通告协议：使用IANA所指定的组播地址224.0.0.18进行VRRP通告；
VRRP追踪：基于接口状态来改变其VRRP优先级来确定最佳的VRRP路由器成为master主机
21
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
第5章 实现与测试
通过keepalived实现LVS高可用以及Web服务的高可用；实现LVS的高可用机制是基于LVS中DR模型来实现；实现Web服务的高可用分别从主备与双主模式进行实现
5.1 LVS的DR模型实现
5.1.1 实验设备介绍
实验中是在VM9上完成的，系统是红帽5.8；共开启了5台虚拟机，两台Real Server，一台Director Server，一台路由设备B，一个window XP客户端（路由设备A这里没有添加使用，测试时直接配置window XP的地址与VIP在同一网段，网卡连接模式为桥接） 5.1.2 实验拓扑图及其相关内容介绍
（1）LVS的DR模型实现拓扑结构如图5.1所示。
图5.1 DR模型实现拓扑结构图
（2） 图示内容分析
大写字母C：IP地址是公网地址，与Director Server是同一网段
22
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
大写字母V: 是Director Server上的VIP，是公网地址，与路由设备A的C网卡地址是同一网段
大写字母D：Director Server上的DIP，是内网地址
大写字母R：Real Server的RIP，是内网地址，与DIP是同一网段，连接在同一个交换机上
数字1：路由设备A的真正连接到因特网上的网卡接口 数字2：路由设备B的连接RIP的网卡是内网地址 数字3：路由设备B的连接因特网的网卡，地址是公网地址 5.1.3 DR模型实现流程
外网客户端访问Director上的VIP地址，其过程是客户端通过因特网，然后通过路由设备与VIP建立通信，此时VIP与这个路由设备的网卡地址是在同一个网段的，请求到达Director后，通过交换机就可以把请求转发到Real Server上，Real Server向外响应报文时，源地址是VIP；但是可以与路由通信的是RealServer上的RIP，所以RIP是报文的回应接口（但源地址是VIP）；RIP完成请求回应，则其网关是RIP所指定的网关，但是此时RIP与DIP是同一个网段，VIP是公网的一个网段，所以此时RIP要实现通信就要借助一个中间设备建立连接然后实现与外网的通信，每个Real Server的VIP需要屏蔽ARP地址请求的响应，根据arptables对arp地址进行访问控制 arp_announce:向外通告本机源地址的时候，设定通告级别
0：只要本地配置的有相应地址，就给予响应
1：仅在请求的目标地址配置请求到达的接口上的时候，才给予响应 2：仅向与本地接口上地址匹配的网络进行通告 arp_ignore:设定接受arp广播地址请求的时候的响应级别
0：将本地任何接口上的任何地址向外通告；
1：仅在目标IP是本地地址，并且配置在arp地址请求进来的接口上时，才给予响应 2：仅向与本地接口上地址匹配的网络进行通告；
3：不回应该网络界面的arp请求，而只对设置的唯一和连接地址做出回应 4-7：保留未使用
8：不回应所有（本地地址）的arp查询
23
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
5.1.4地址规划
表5.1 IP地址规划
Director Server DIP VIP 172.16.51.76 10.10.10.10 Real Server1 RIP VIP 172.16.51.77 10.10.10.10 Real Server2 RIP VIP 172.16.51.78 10.10.10.10 路由设备B Eth1 Eth0 172.16.51.69 10.10.10.21 5.1.5配置流程
（1）DirectorServer eth0上配置DIP地址（模拟为内网网段）如图5.2所示
图5.2 配置DIP地址
（2）Director Server上VIP地址配置 # ifconfig eth0:0 10.10.10.10/8
（3）设定路由，定义当是请求VIP地址时让eth0:0接口作为送出报文接口 # route add –host 10.10.10.10/8dev eth0:0 （4）RS1RIP地址配置 如图5.3所示
图5.3配置RS1的RIP地址
（5）配置RS1arp_announce与arp_ignore配置 # sysctl –wnet.ipv4.conf.eth0.arp_announce=2 # sysctl –wnet.ipv4.conf.all.arp_announce=2 #sysctl –w net.ipv4.conf.eth0.arp_ignore=1 #sysctl –w net.ipv4.conf.all.arp_ignore=1
（6）配置的广播地址是自己的地址掩码是255.255.255.255：意思此地址只跟自己在同一网段内不跟其他任何地址在同一网段内
# ifconfig lo:0 10.10.10.10broadcast 10.10.10.10 netmask 255.255.255.255 up （7）添加路由
# route add –host 10.10.10.10 dev lo:0 （8）RS2RIP地址配置 如图5.4所示
24
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
图5.4 RS2RIP地址配置
（9）配置RS1arp_announce与arp_ignore配置 # sysctl –wnet.ipv4.conf.eth0.arp_announce=2 # sysctl –w net.ipv4.conf.all.arp_announce=2 #sysctl –w net.ipv4.conf.eth0.arp_ignore=1 #sysctl –w net.ipv4.conf.all.arp_ignore=1
（10）配置VIP地址
# ifconfig lo:0 10.10.10.10 broadcast 10.10.10.10 netmask 255.255.255.255 up （11）添加路由
# route add –host 10.10.10.10 dev lo:0 （12）设定ipvsadm规则
# ipvsadm –A –t 192.168.0.100:80 –s wlc
# ipvsadm –a –t 192.168.0.100:80 –r172.16.51.77 –g –w 2 # ipvsadm –a –t 192.168.0.100:80 –r172.16.51.78 –g –w 1
(13)在Director Server测试RS1与RS2 的web服务是否正常 如图5.5所示
图5.5测试RS1与RS2
（14）设定ipvsadm规则
# ipvsadm –A –t 192.168.0.100:80 –s wlc
# ipvsadm –a –t 192.168.0.100:80 –r172.16.51.77 –g –w 2 # ipvsadm –a –t 192.168.0.100:80 –r172.16.51.78 –g –w 1 （15）查看ipvsadm规则 如图5.6所示
图5.6查看ipvsadm规则
（16）路由设备B的网卡eth1模拟为内网地址，与Real Server的RIP在同一个网段 如图5.7所示
25
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
图5.7 eth1IP配置
（17）网卡eth0模拟为内网地址，与Real Server的VIP在同一个网段如图5.8所示
图5.8 eth0IP配置
（18）打开路由器B设备的路由转发功能 # echo “1” >/pro/sys/net/ipv4/ip_forward
（19）在RS1与RS2上添加路由使其可以通过路由设备B将报文通过互联网送至客户端 # route add –net default gw 172.16.51.69
（20）模拟的外网客户端IP地址配置（虚拟机中window XP机器）如图5.9所示
图5.9客户端IP地址配置
26
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
（21）DR模型的实现脚本 #!/bin/bash #
# Script to start LVS DR real server. # description: LVS DR real server #
. /etc/rc.d/init.d/functions
VIP=172.16.50.1 host=`/bin/hostname`
case \"$1\" in start)
# Start LVS-DR real server on this machine. /sbin/ifconfig lo down /sbin/ifconfig lo up
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
/sbin/ifconfig lo:0 $VIP broadcast $VIP netmask 255.255.255.255 up /sbin/route add -host $VIP dev lo:0 ;; stop)
# Stop LVS-DR real server loopback device(s).
/sbin/ifconfig lo:0 down
echo 0 > /proc/sys/net/ipv4/conf/lo/arp_ignore echo 0 > /proc/sys/net/ipv4/conf/lo/arp_announce echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce ;;
status)
# Status of LVS-DR real server.
islothere=`/sbin/ifconfig lo:0 | grep $VIP` isrothere=`netstat -rn | grep \"lo:0\" | grep $VIP` if [ ! \"$islothere\" -o ! \"isrothere\" ];then # Either the route or the lo:0 device # not found.
echo \"LVS-DR real server Stopped.\" else
echo \"LVS-DR real server Running.\" fi ;; *)
# Invalid entry.
echo \"$0: Usage: $0 {start|status|stop}\"
27
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
exit 1 ;; esac
5.2基于keepalived实现LVS高可用
（1）IP地址规划 HA1 HA2 FQDN node1.magedu.com 172.16.51.76 FQDN IP 表5.2 IP地址规划 Real Server1 node2.magedu.com 172.16.51.100 FQDN Real Server2 test2.magedu.com 172.16.51.78 test1.magFQDN edu.com 172.16.51.77 IP IP IP （2）Resal Server配置准备安装web服务 # yum install httpd –y
（3）RS1上web服务测试 如图5.10所示
图5.10 测试web页面
（4）RS2上web服务测试 如图5.11所示
图5.11 测试web页面
（5）Rea lServer1上VIP配置
# sysctl -w net.ipv4.conf.lo.arp_ignore=1 # sysctl -w net.ipv4.conf.all.arp_ignore=1 # sysctl -w net.ipv4.conf.lo.arp_announce=2 # sysctl -wnet.ipv4.conf.all.arp_announce=2
# ifconfig lo:0 172.16.51.70 broadcast172.16.51.70 netmask 255.255.255.255 up # route add -host 172.16.51.70 dev lo:0
（6）Rea lServer2上VIP配置与RealServer1相同，在Rea lServer1与Rea lServer2上安装ipvsadm
# yum -y install ipvsadm
（7）在HA1与HA2上安装keeplived
28
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
# yum -y --nogpgcheck localinstallkeepalived-1.2.7-5.el5.i386.rpm （8）修改配置文件（HA1上操作） # cd /etc/keepalived/ # vim keepalived.conf
全局配置更改（关于邮件这里未做太多的更改）
global_defs {
notification_email { acassen@firewall.loc failover@firewall.loc sysadmin@firewall.loc }
notification_email_from root@localhost smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id LVS_DEVEL }
更改虚拟路由组配置
vrrp_instance VI_1 { state MASTER interface eth0
virtual_router_id 51 priority 101 advert_int 1 authentication { auth_typePASS auth_pass password }
virtual_ipaddress { 172.16.51.70 } }
更改Virtual_server与real_server设置
virtual_server 172.16.51.70 80 { delay_loop 6 lb_algo wlc lb_kind DR
nat_mask 255.255.0.0 persistence_timeout 50 protocol TCP
real_server 172.16.51.77 80 { weight 1 SSL_GET { url { path /
status_code 200 }
connect_timeout 3 nb_get_retry 3
delay_before_retry 3 }
29
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
}
virtual_server 172.16.51.70 80 { delay_loop 6 lb_algo rr lb_kind DR
nat_mask 255.255.0.0 persistence_timeout 50 protocol TCP
real_server 172.16.51.78 80 { weight 1 url { path /
status_code 200 }
connect_timeout 3 nb_get_retry 3
delay_before_retry 3
（9）复制到HA2上相同的一份
# scp /etc/keepalived/keepalived.conf node2:/etc/keepalived/ （10）修改node2上keepalived配置文件，修改项如下 state BACKUP priority 100
（11）启动keepalived 如图5.12所示
图5.12 启动keepalived
（12）查看配置是否生效 如图5.13所示
图5.13 查看配置的IP地址信息
（13）查看生成的ipvsadm规则信息 如图5.14所示
图5.14 查看生成的ipvsadm规则
30
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
5.3基于keepalived实现web服务的高可用
5.3.1实验拓扑图及其相关内容介绍
（1）keepalived实现web服务的高可用架构图 如图5.15所示
图5.15 keepalived实现web服务的高可用架构图
5.3.2 配置实现流程
（1）关闭node1与node2的keepalive #service keepalived stop
（2）在node1与node2上安装web服务 #yum -y install httpd
（3）启动web服务后，分别准备web页面
# echo \"node1.magedu.com\" >/var/www/html/index.html # echo \"node2.magedu.com\" >/var/www/html/index.html （4）访问HA1的web进行测试 如图5.16所示
31
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
图5.16 HA1的web页面
（4）访问HA2的web进行测试 如图5.17所示
图5.17 HA2的web页面
（5）配置文件准备与配置
# cp keepalived.conf.haproxy_examplekeepalived.conf # vim keepalived.conf （6）修改配置文件内容
! Configuration File for keepalived
全局定义邮箱以及server地址相关配置
global_defs { #全局默认配置
#主节点发生变化，通知管理员
notification_email { root@localhost }
notification_email_from root@localhost { smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id LVS_DEVEL }
vrrp_instance VI_1 { #定义虚拟路由组 state MASTER
interface eth0 virtual_router_id 51 priority 101
32
#连接时间超时时长
#定义主从
#server_id #优先级
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
advert_int 1 authentication {
auth_type PASS auth_pass passwd
}
virtual_ipaddress {
172.16.51.70 } }
virtual_server 172.16.1.70 80 { delay_loop 6 lb_algo wlc lb_kind DR
nat_mask 255.255.0.0 protocol TCP
real_server 172.16.51.76 80 { weight 1 url {
path /
status_code 200 }
connect_timeout 2 nb_get_retry 3
delay_before_retry 1 } }
virtual_server 172.16.51.70 80 { delay_loop 6 lb_algo wlc lb_kind DR
nat_mask 255.255.0.0
# 间隔一秒通告 #安全认证 #字符串认证
#密码
#VIP地址
#定义获取服务等待的时间 #负载均衡调度算法
# LVS类型
# 监控url的状态
# 连接超时时长 # 重试时长
#延时前的重试时长
33
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
protocol TCP
real_server 172.16.51.100 80 { weight 2 url { path /
status_code 200 }
connect_timeout 2 nb_get_retry 3 delay_before_retry 1 } }
（7）复制配置文件到node2主机
# scp /etc/keepalived/keepalived.confnode2:/etc/keepalived/ （8）编辑修改一下内容 state BACKUP priority 100
（9）启动keepalived服务 如图5.18所示
图5.18 启动keepalived服务
（10）查看MASTER（node1）上主机定义的VIP（eth0别名IP）是否成功 如图5.19所示
图5.19 查看Master的VIP
34
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
5.4双主模式实现
5.4.1实验拓扑图及其相关内容介绍 （1）双主模式实现架构图 如图5.20所示
图5.20双主模式架构图
（2）双主模式介绍
双主模式下两个主机web服务同时开启，在两台主机的设备下设置两个VIP，每个主机相对其中的一个为主，另一个为从；当有一台主机出现在故障时，VIP会漂移到一个主机上；他们之间是以互为主从的模式存在 （3）修改keepalived.conf配置文件
（4）查看node1主机上的VIP地址配置 如图5.21所示
35
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
图5.21 查看node1主机上的VIP地址
（5）查看node2主机上的VIP地址配置 如图5.22所示
图5.22 查看node2主机上的VIP地址
5.5 测试
5.5.1 DR模型实验完成测试
（1）客户端浏览器访问VIP 如图5.23所示
图5.23访问VIP
36
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
（2）刷新浏览器查看是否可以均衡访问 如图5.24所示
图5.24 均衡设置访问验证
（3）刷新N次之后，查看分发请求次数及请求报文数据 如图5.25所示
图5.25 查看报文数据匹配状态
5.5.2 Keepalived实验结果测试
（1）使用window主机浏览器进行访问测试 如图5.26所示
图5.26 访问vip
（2）刷新浏览器 如图5.27所示
图5.27 访问vip
37
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
(3)查看相关匹配信息 如图5.28所示
图5.28 查看匹配次数信息
5.5.3 高可用web服务器实验测试 （1）访问虚拟IP地址 如图5.29所示
图5.29 访问VIP
（2）主备服务器转换测试 如图5.30所示 # cd /etc/keepalived/ #touchdown
图5.30 查看VIP是否转移
38
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
（3）在备用节点node2上查看 如图5.31所示
图5.31 查看VIP是否成功转移到node2节点
（4）访问虚拟IP 如图5.32所示
图5.32 访问VIP
5.5.4 双主模式实验测试
（1）修改的keepalived.conf配置文件 启用VI_2路由组 vrrp_instance VI_2 {
interface eth0
state BACKUP # BACKUP forslave routers priority 100 # 100 for BACKUP virtual_router_id 52 garp_master_delay 1 authentication { auth_type PASS
#加密 #加密密码
#定义router_id
auth_pass password }
track_interface { eth0
39
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
}
virtual_ipaddress {
#vip配置
172.16.51.80/16 dev eth0 label eth0:1 }
track_script { chk_httpd chk_schedown }
主机故障后相关功能定义
notify_master \"/etc/keepalived/notify.sh master eth0:1\" notify_backup \"/etc/keepalived/notify.sh backup eth0:1\" notify_fault \"/etc/keepalived/notify.sh fault eth0:1\" }
（2）修改的keepalived.conf配置文件 启用VI_2路由组
# vim /etc/keepalived/keepalived.conf
vrrp_instance VI_2 { interface eth0
state MASTER # BACKUP for slave routers priority 101 # 100 for BACKUP virtual_router_id 52 garp_master_delay 1
authentication { auth_type PASS auth_pass password }
track_interface { eth0 }
virtual_ipaddress {
172.16.51.80/16 dev eth0 label eth0:1
40
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
} track_script { chk_httpd chk_schedown }
notify_master \"/etc/keepalived/notify.sh master eth0:1\" notify_backup \"/etc/keepalived/notify.sh backup eth0:1\" notify_fault \"/etc/keepalived/notify.sh fault eth0:1\" }
（2）配置文件定义完成后，重启服务，访问其中的一个VIP 如图5.33所示
图5.33 访问VIP
（2）访问另外一个VIP 如图5.34所示
图5.34 访问VIP
（3）模拟node1出现故障 # cd /etc/keepalived/ # touch down
（4）查看node2上虚拟IP地址 如图5.35所示
41
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
图5.35 查看node2上虚拟IP地址
（5）访问172.16.51.70 如图4.36所示
图4.36访问172.16.51.70
（6）访问172.16.51.80 如图5.37所示
图5.37访问172.16.51.80
42
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
第6章 结束语
个人博客欢迎访问
http://djy0000.blog.51cto.com/
43
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
参考文献
[1] 高俊峰. 高性能Linux服务器构建实战[M]. 北京：机械工业出版社，2011.12 [2] 刘鑫. 高性能网站构建实战[M] 北京：人民邮电出版社，2013.01
[3] 周奇. Linux网络服务器配置、管理与实践教程[M] 北京：清华大学出版社，2011.12 [4] Apache Software Foundation!.[EB/OL]. http://www.apache.org/, 2013-05-20.
44
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
附录B: 主要源程序
基于keepalived实现web服务的高可用中keepalived.conf脚本配置文件
LVS中ipvsadm服务脚本
#!/bin/bash #
# Startup script handle the initialisation of LVS # chkconfig: - 11 89
# description: Initialise the Linux Virtual Server # config: /etc/sysconfig/ipvsadm #
# Source function library . /etc/rc.d/init.d/functions IPVSADM=ipvsadm
IPVSADMRESTORE=${IPVSADM}-restore IPVSADMSAVE=${IPVSADM}-save # Saved IPVS data
IPVSADM_DATA=/etc/sysconfig/$IPVSADM # Configuration
IPVSADM_CONFIG=/etc/sysconfig/${IPVSADM}-config IPVS=ip_vs
PROC_IPVS=/proc/net/$IPVS
VAR_SUBSYS_IPVSADM=/var/lock/subsys/$IPVSADM
if [ ! -x /sbin/$IPVSADM ]; then
echo -n $\"${IPVSADM}: /sbin/$IPVSADM does not exist.\"; warning; echo exit 5 fi
# Old or new modutils
/sbin/modprobe --version 2>&1 | grep -q module-init-tools \\ && NEW_MODUTILS=1 \\ || NEW_MODUTILS=0
# Default IPVSADM configuration: IPVS_MODULES_UNLOAD=\"yes\" IPVS_SAVE_ON_STOP=\"no\" IPVS_SAVE_ON_RESTART=\"no\" IPVS_STATUS_NUMERIC=\"yes\"
45
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
# Load IPVSADM configuration.
[ -f \"$IPVSADM_CONFIG\" ] && . \"$IPVSADM_CONFIG\"
rmmod_r() {
# Unload module with all referring modules.
# At first all referring modules will be unloaded, then the module itself. local mod=$1 local ret=0 local ref=
# Get referring modules.
# New modutils have another output format. [ $NEW_MODUTILS = 1 ] \\
&& ref=$(lsmod | awk \"/^${mod}[[:space:]]/ { print \\$4; }\" | tr ',' ' ') \\ || ref=$(lsmod | grep ^${mod} | cut -d \"[\" -s -f 2 | cut -d \"]\" -s -f 1)
# recursive call for all referring modules for i in $ref; do rmmod_r $i
# Unload module.
# The extra test is for 2.6: The module might have autocleaned, # after all referring modules are unloaded. if grep -q \"^${mod}\" /proc/modules ; then modprobe -r $mod > /dev/null 2>&1 res=$?
[ $res -eq 0 ] || echo -n \" $mod\" let ret+=$res; fi
return $ret } start() {
# Do not start if there is no config file. [ ! -f \"$IPVSADM_DATA\" ] && return 6
# check if ipvs module load is deactivated echo $\"${IPVSADM}: ${IPVS} is disabled.\" return 150 fi
46
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
# If we don't clear these first, we might be adding to pre-existing rules. action $\"${IPVSADM}: Clearing the current IPVS table:\" $IPVSADM -C
echo -n $\"${IPVSADM}: Applying IPVS configuration: \" $IPVSADMRESTORE < ${IPVSADM_DATA}
if [ $? -eq 0 ];then success; echo; else failure; echo; return 1;fi
touch $VAR_SUBSYS_IPVSADM } stop() {
# Do not stop if ipvs module is not loaded. [ ! -e \"$PROC_IPVS\" ] && return 0
action $\"${IPVSADM}: Clearing the current IPVS table:\" $IPVSADM -C
ret=0
if [ \"x$IPVS_MODULES_UNLOAD\" = \"xyes\" ]; then
action $\"${IPVSADM}: Unloading modules:\" rmmod_r $IPVS [ $? -ne 0 ] && ret=1 fi
rm -f $VAR_SUBSYS_IPVSADM
return $ret } status () {
# Do not print status if lockfile is missing and ipvs modules are not # loaded.
if [ ! -f \"$VAR_SUBSYS_IPVSADM\" -a ! -e \"$PROC_IPVS\" ]; then echo $\"${IPVSADM}: IPVS is not running.\" return 3 fi
# Do show status if ipvs module is not loaded. if [ ! -e \"$PROC_IPVS\" ];then
echo $\"${IPVSADM}: IPVS module is not loaded.\" return 3
47
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
fi
NUM=\"\"
[ \"x$IPVS_STATUS_NUMERIC\" = \"xyes\" ] && NUM=\"-n\"
$IPVSADM -L $NUM && echo } save() {
# Check if module is loaded [ ! -e \"$PROC_IPVS\" ] && return 0
echo -n $\"${IPVSADM}: Saving IPVS table to ${IPVSADM_DATA}: \" $IPVSADMSAVE -n > ${IPVSADM_DATA} 2>/dev/null if [ $? -eq 0 ];then success; echo; else failure; echo; return 1;fi
return 0 } restart() {
[ \"x$IPVS_SAVE_ON_RESTART\" = \"xyes\" ] && save stop start }
# See how we were called. case \"$1\" in start)
[ -f \"$VAR_SUBSYS_IPVSADM\" ] && exit 0
# If we have no configuration, save the current one [ -f ${IPVSADM_DATA} ] || save start RETVAL=$? ;; stop)
[ \"x$IPVS_SAVE_ON_STOP\" = \"xyes\" ] && save stop RETVAL=$? ;;
restart|force-reload)
48
邓俊阳：基于keepalived实现LVS高可用以及WEB高可用
restart
[ -f ${IPVSADM_DATA} ] || save start RETVAL=$? ;; stop)
[ \"x$IPVS_SAVE_ON_STOP\" = \"xyes\" ] && save stop RETVAL=$? ;;
restart|force-reload) restart RETVAL=$? ;; reload)
# Start will flush everything, so it counts as a reload start RETVAL=$? ;; status) status RETVAL=$? ;; save) save RETVAL=$? ;; *)
echo \"Usage: $0 {start|stop|restart|force-reload|reload|status|save}\" RETVAL=2 esac
exit $RETVAL
49
因篇幅问题不能全部显示，请点此查看更多更全内容