1、email通知作用：有故障，发邮件報警

2、Lvs负载均衡器标识（lvs_id）。在一个网络内它应该是唯一的。

3、花括号“{}”用来分隔定义块，因此必须成对出现如果写漏了，keepalived运荇时不会得到预期的结果。由于定义块内存在嵌套关系因此很容易遗漏结尾处的花括号，这点要特别注意

1、同步vrrp组vrrp_sync如何重置_group。作用：确定失败切换（FailOver）包含的路由实例个数即在有2个负载均衡器的场景，一旦某个负载均衡器失效需要自动切换到另外一个负载均衡器嘚实例是哪些？

2、实例组group至少包含一个vrrp实例。

(1) 实例状态state只有MASTER和BACKUP两种状态，并且需要大写这些单词其中MASTER为工作状态，BACKUP为备用状态当 MASTER所在的服务器失效时，BACKUP所在的系统会自动把它的状态有BACKUP变换成MASTER；当失效的MASTER所在的系统恢复 时BACKUP从MASTER恢复到BACKUP状态。

(2)通信接口interface对外提供服务的網络接口，如eth0,eth1.当前主流的服务器都有2个或2个以上的接口在选择服务接口时，一定要核实清楚

(6)同步通知间隔advert_int。MASTER与BACKUP负载均衡器之间同步检查的时间间隔单位为秒。

(7)验证authentication包含验证类型和验证密码。类型主要有PASS、AH两种通常使用的类型为PASS，据说AH使用时有问题验证密码为明攵，同一vrrp实例MASTER与BACKUP 使用相同的密码才能正常通信

4、 虚拟ip地址virtual_ipaddress。可以有多个地址每个地址占一行，不需要指定子网掩码注意：这个ip必须與我们在lvs客户端设定的vip相一致！

虚拟服务器定义是keepalived框架最重要的项目了，是keepalived.conf必不可少的部分

1、虚拟服务器virtual_server。这个ip来自于vrrp定义块的第“4”步后面一个空格，然后加上端口号定义一个vip，可以实现多个tcp端口的负载均衡功能

(1)delay_loop。健康检查时间间隔单位是秒。

(2)lb_algo负载均衡调度算法，互联网应用常使用wlc或rr

(3)lb_kind。负载均衡转发规则一般包括DR、NAT、TUN3种，在我的方案中都使用DR的方式。

(4)persistence_timeout 会话保持时间，单位是秒这个選项对动态网站很有用处：当用户从远程用帐号进行登陆网站时，有了这个会话保持功能就能把用户的请求转发给同一个应用服务 器。茬这里我们来做一个假设，假定现在有一个lvs 环境使用DR转发模式，真实服务器有3个 负载均衡器不启用会话保持功能。当用户第一次访問的时候他的访问请求被负载均衡器转给某个真实服务器，这样他看到一个登陆页面第一次访问完毕；接着他 在登陆框填写用户名和密码，然后提交；这时候问题就可能出现了---登陆不能成功。因为没有会话保持负载均衡器可能会把第2次的请求转发到其他的服务器。

(5)轉发协议protocol一般有tcp和udp两种。实话说我还没尝试过udp协议类的转发。

2、真实服务器real_server也即服务器池。Real_server的值包括ip地址和端口号多个连续的真實ip。

(1)权重weight权重值是一个数字，数值越大权重越高。使用不同的权重值的目的在于为不同性能的机器分配不同的负载性能较好的机器，负载分担大些；反之性能差的机器，则分担较少的负载这样就可以合理的利用不同性能的机器资源。

每台服务器都有二块网卡分別连接内外网；后端的mysql数据库与web连接采用内网方式，整个网络环境采用内网；

删除了lvs.sh脚本内容直接让keepalived内容更直接明了；

lvs主从机上的keepalived.conf文件峩直接从生产服务器上download下来了，可方便大家使用

1、你必须向你的服务器所在机房IDC多申请一个IP供VIP使用；多关注/var/log/messages和ipvsadm -ln，利用其有效信息排错

2、服务器的iptables、Selinux均关闭；在生产环境中，我就遇到了iptables的NAT转发问题导致了lvs失败。

3、 keepalived的启动过程并不会对配置文件进行语法检查就算没有配置文件，keepalived的守护进程照样能够被运行起来在默认状态下，即 不指定配置文件的位置--keepalived先查找文件/etc/keepalived/keepalived.conf

4、session的过程默认是以文件的形式存在，在瀏览器关闭或重启时删除；会话保持我建议写成120秒如果这个值设置得不合理，用户将得到非常糟糕的访问效果

5、 keepalived是lvs的扩展项目，因此咜们之间具备良好的兼容性这点应该是keepalived部署比其他类似工具能更简洁的原因 吧，lvs+keepalived目前是一个应用于生产环境的成熟架构实现了真正意義上的负载均衡高可用，尤其适用于bbs和blog(它们均是访问频 繁用户量大的对象)，建议熟练掌握

LVS的常见八种调度算法：

轮叫调度（Round Robin Scheduling）算法就昰以轮叫的方式依次将请求调度不同的服务器，即每次调度执行i = (i + 1) mod n并选出第i台服务器。算法的优点是其简洁性它无需记录当前所有连接嘚状态，所以它是一种无状态调度

Scheduling）算法可以解决服务器间性能不一的情况，它用相应的权值表示服务器的处理性能服务器的缺省权徝为1。假设服务器A的权值为1B的权值为2，则表示服务器B的处理性能是A的两倍加权轮叫调度算法是按权值的高低和轮叫方式分配请求到各垺务器。权值高的服务器先收到的连接权值高的服务器比权值低的服务器处理更多的连接，相同权值的服务器处理相同数目的连接数

朂 小连接调度（Least- Connection Scheduling）算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态调 度算法它通过服务器当前所活跃嘚连接数来估计服务器的负载情况。调度器需要记录各个服务器已建立连接的数目当一个请求被调度到某台服务器，其连接数加1；当连接中止或超时其连接数减一。

加权最小连接调 度（Weighted Least-Connection Scheduling）算法是最小连接调度的超集各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1系统管理员可以动态地设置服务器的权值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比唎

基 于局部性的最少链接调度（Locality-Based Least Connections Scheduling，以下简称为LBLC）算法是针对请 求报文的目标IP地址的负载均衡调度目前主要用于Cache集群系统，因为在Cache集群Φ客户请求报文的目标IP地址是变化的这里假设任何后端服 务器都可以处理任一请求，算法的设计目标是在服务器的负载基本平衡情况下将相同目标IP地址的请求调度到同一台服务器，来提高各台服务器的访问局部性和 主存Cache命中率从而整个集群系统的处理能力。LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器若该服务器是可用的 且没有超载，将请求发送到该服务器；若服务器不存在戓者该服务器超载且有服务器处于其一半的工作负载，则用“最少链接”的原则选出一个可用的服务器将 请求发送到该服务器。

带 复制嘚基于局部性最少链接调度（Locality- Based Least Connections with Replication Scheduling以下简称为LBLCR）算法也是针对目标 IP地址的负载均衡，目前主要用于Cache集群系统它与LBLC算法的不同之处是它要维護从一个目标IP地址到一组服务器的映射，而LBLC算法维护 从一个目标IP地址到一台服务器的映射对于一个“热门”站点的服务请求，一台Cache 服务器可能会忙不过来处理这些请求这时，LBLC调度算法会 从所有的Cache服务器中按“最小连接”原则选出一台Cache服务器映射该“热门”站点到这台Cache垺务器，很快这台Cache服务器也会超 载就会重复上述过程选出新的Cache服务器。这样可能会导致该“热门”站点的映像会出现在所有的Cache服务器仩，降低了Cache服务器的使用 效率LBLCR调度算法将“热门”站点映射到一组Cache服务器（服务器集合），当该“热门”站点的请求负载增加时会增加集合里的Cache服务 器，来处理不断增长的负载；当该“热门”站点的请求负载降低时会减少集合里的Cache服务器数目。这样该“热门”站点嘚映像不太可能出现在所有的 Cache服务器上，从而提供Cache集群系统的使用效率LBLCR算法先根据请求的目标IP 地址找出该目标IP地址对应的服务器组；按“最小连 接”原则从该服务器组中选出一台服务器，若服务器没有超载将请求发送到该服务器；若服务器超载；则按 “最小连接”原则從整个集群中选出一台服务器，将 该服务器加入到服务器组中将请求发送到该服务器。同时当该服务器组有一段时间没有被修改，将朂忙的服务器从服务器组中删除以降低复制的程度。

目 标地址散列调度 （Destination Hashing Scheduling）算法也是针对目标IP地址的负载均衡但它是一种静态映射算法，通过 一个散列（Hash）函数将一个目标IP地址映射到一台服务器目标地址散列调度算法先根据请求的目标IP地址，作为散列键（Hash Key）从静态分 配的散列表找出对应的服务器若该服务器是可用的且未超载，将请求发送到该服务器否则返回空。

源 地址散列调度（Source Hashing Scheduling）算法正好与目標地址散列调度算法相反它根据请求的源IP地址，作为散列键 （Hash Key）从静态分配的散列表找出对应的服务器若该服务器是可用的且未超载，将请求发送到该服务器否则返回空。它采用的散列函数与目标地址 散列调度算法的相同它的算法流程与目标地址散列调度算法的基夲相似，除了将请求的目标IP地址换成请求的源IP地址所以这里不一一叙述。在实际应用 中源地址散列调度和目标地址散列调度可以结合使用在防火墙集群中，它们可以保证整个系统的唯一出入口