Keepalived介绍（链接）

1、Keepalived是什么（what）

（一）概述

       Keepalived[保持在线] 是一个基于VRRP协议来实现的LVS服务高可用方案，能够利用其来避免单点故障。一个LVS服务会有2台服务器运行Keepalived，一台为主服务器（MASTER），一台为备份服务器（BACKUP），可是对外表现为一个虚拟IP，主服务器会发送特定的消息给备份服务器，当备份服务器收不到这个消息的时候，即主服务器宕机的时候， 备份服务器就会接管虚拟IP，继续提供服务，从而保证了高可用性。   

       Keepalived的做用是检测服务器的状态，若是有一台web服务器死机，或工做出现故障，Keepalived将检测到，并将有故障的服务器从系统中剔除，同时使用其余服务器代替该服务器的工做，当服务器工做正常后Keepalived自动将服务器加入到服务器群中。

       负载均衡器（Load Balancer, LB ）是一组可以将IP数据流以负载均衡形式转发到多台物理服务器的集成软件。有硬件负载均衡器和软件负载均衡器之分，硬件负载均衡器主要是在访问网络和服务器之间配置物理负载均衡设备，客户端对物理服务器的访问请求首先会抵达负载均衡设备，而后再由负载均衡设备根据必定的负载算法转发到后端服务器。相比而言，软件负载均衡器不须要特定的物理设备，只需在相应的操做系统上部署具备负载均衡功能的软件便可。

        在Opens tack高可用集群部署中，服务的负载均衡和高可用主要有两种主流的实现方案，即 HAProxy+ Keepalived和Pacemaker+HAProxy方案。因为OpenStack服务组件多样，不一样服务均须要进行特定的高可用设计，而且从集群资源统一调度和集群稳定性的角度考虑，后一种方案是多数OpenStack厂商的高可用部署方案首选，可是选用后一方案并不意味着Keepalived在OpenStack高可用集群部署中不被使用。因为Keepalived 的主要做用之一是进行虚拟路由的故障切换，其在Neutron 的L3 高可用设计与实现中起着举足轻重的做用。

Keepalived工做原理

    Keepalived软件起初是专为LVS负载均衡软件设计的，用来管理并监控LVS集群系统中各个服务节点的状态，后来又加入了能够实现高可用的VRRP功能。所以，Keepalived除了可以管理LVS软件外，还能够做为其余服务（例如：Nginx、Haproxy、MySQL等）的高可用解决方案软件。

       Keepalived为Linux系统和基于Linux 的架构提供了负载均衡和高可用能力，其负载均衡功能主要源自集成在Linux内核中的LVS项目模块IPVS( IP Virtual Server ），基于IPVS提供的4 层TCP/IP协议负载均衡， Keepalived也具有负载均衡的功能，此外， Keepalived还实现了基于多层TCP/IP 协议（ 3 层、4 层、5/7 层）的健康检查机制，所以， Keepalived在LVS 负载均衡功能的基础上，还提供了LVS 集群物理服务器池健康检查和故障节点隔离的功能。

      Keepalived (的做用)就是为LVS 集群节点提供健康检查和为LVS 负载均衡服务器提供故障切换的用户空间进程。

Keepalived采用是模块化设计，不一样模块实现不一样的功能；

keepalived主要有三个模块，分别是core、check和vrrp。 

 

core：是keepalived的核心，负责主进程的启动和维护，全局配置文件的加载解析等 

check： 负责healthchecker(健康检查)，包括了各类健康检查方式，以及对应的配置的解析包括LVS的配置解析；可基于脚本检查对IPVS后端服务器健康情况进行检查。 

vrrp：VRRPD子进程，VRRPD子进程就是来实现VRRP协议的

 

keepalived配置文件：

Keepalived配置文件为：keepalived.conf；

主要有三个配置区域，分别是：全局配置(Global Configuration)、VRRPD配置、LVS配置 

全局配置又包括两个子配置： 全局定义(global definition) 静态IP地址/路由配置(static ipaddress/routes)

Keepalived服务VRRP的工做原理：

    Keepalived高可用对之间是经过 VRRP进行通讯的， VRRP是经过竞选机制来肯定主备的，主的优先级高于备，所以，工做时主会优先得到全部的资源，备节点处于等待状态，当主宕机的时候，备节点就会接管主节点的资源，而后顶替主节点对外提供服务。

在 Keepalived服务对之间，只有做为主的服务器会一直发送 VRRP广播包,告诉备它还活着，此时备不会枪占主，当主不可用时，即备监听不到主发送的广播包时，就会启动相关服务接管资源，保证业务的连续性.接管速度最快；

 

出现脑裂的缘由：

 

1. 高可用服务器对之间心跳线链路发生故障，致使没法正常通讯。

2. 因心跳线坏了（包括断了，老化）。

3. 因网卡及相关驱动坏了，ip配置及冲突问题（网卡直连）

4. 因心跳线间链接的设备故障（网卡及交换机）

5. 因仲裁的机器出问题（采用仲裁的方案）

6. 高可用服务器上开启了 iptables防火墙阻挡了心跳消息传输。

7. 高可用服务器上心跳网卡地址等信息配置不正确，致使发送心跳失败

8. 其余服务配置不当等缘由，如心跳方式不一样，心跳广插冲突、软件Bug等。

 

如何解决脑裂：

 

① 同时使用串行电缆和以太网电缆链接，同时用两条心跳线路，这样一条线路坏了，另外一个仍是好的，依然能传送心跳消息。

② 当检测到裂脑时强行关闭一个心跳节点（这个功能需特殊设备支持，如Stonith、feyce）。至关于备节点接收不到心跳消患，经过单独的线路发送关机命令关闭主节点的电源。

③ 作好对裂脑的监控报警（如邮件及手机短信等或值班）.在问题发生时人为第一时间介入仲裁，下降损失。

管理员能够经过手机回复对应数字或简单的字符串操做返回给服务器.让服务器根据指令自动处理相应故障这样解决故障的时间更短。

 

1.1 keepalived及LVS概述

Keepalived的项目实现的主要目标是简化LVS项目的配置并加强其稳定性，即Keepalived是对LVS项目的扩展加强。

Keepalived为Linux系统和基于Linux 的架构提供了负载均衡和高可用能力，其负载均衡功能主要源自集成在Linux内核中的LVS项目模块IPVS( IP Virtual Server ），基于IPVS提供的4 层TCP/IP协议负载均衡， Keepalived也具有负载均衡的功能，此外， Keepalived还实现了基于多层TCP/IP 协议（ 3 层、4 层、5/7 层）的健康检查机制，所以， Keepalived在LVS 负载均衡功能的基础上，还提供了LVS 集群物理服务器池健康检查和故障节点隔离的功能。

除了扩展LVS的负载均衡服务器健康检查能力， Keepalived 还基于虚拟路由冗余协议（ Virtual Route Redundancy Protocol, VRRP )实现了LVS 负载均衡服务器的故障切换转移，即Keepalived还实现了LVS负载均衡器的高可用性。Keepalived 就是为LVS 集群节点提供健康检查和为LVS 负载均衡服务器提供故障切换的用户空间进程。

图3-1为Keepalived的原理架构图，从图中能够看到， Keepalived的多数核心功能模块均位于用户空间，而仅有IPVS和NETLINK模块位于内核空间，可是这两个内核模块正是Keepalived 实现负载均衡和路由高可用的核心模块，其中的NETLINK主要用于提供高级路由及其相关的网络功能。Keepalived的大部分功能模块位于用户空间，其中几个核心功能模块的介绍以下。

• WatchDog ：其主要负责监控Checkers和VRRP子进程的运行情况。

• Checkers ：此功能模块主要负责真实服务器的健康检查（ HealthChecking )，是Keepalived最主要的功能之一，由于HealthChecking是负载均衡功能稳定运行的基础， LVS集群节点的故障隔离和从新加入均依赖于HealthChecking的结果。

• VRRPStack ：此功能模块主要负责负载均衡器之间的故障切换，若是集群架构中仅使用一个LVS负载均衡器，因为自己不具有故障切换的条件，则VRRPStack不是必须的。

• IPVS Wrapper ：此模块主要用来发送设定的规则到内核IPVS代码。Keepalived的设计目标是构建高可用的LVS 负载均衡群集， Keepalived在运行中将会经过IPVSWrapper模块调用IPVSAdmin工具来建立虚拟服务器，检查和管理LVS集群物理服务器池。

• Netlink Reflector ：此功能模块主要用来设定VRRP的VIP地址并提供相关的网络功能，该模块经过与内核中的NETLINK模块交互，从而为Keepalived 提供路由高可用功能。

      从Keepalived 的实现原理和功能来看， Keepalived是开源负载均衡项目LVS的加强和虚拟路由协议VRRP实现的集合，即Keepalived经过整合和加强LVS与VRRP来提供高可用的负载均衡系统架构。

1.linux虚拟服务器---lvs

     LVS是Linux Virtual Server的简称，即Linux虚拟服务器。目前，LVS项目已经被集成到Linux内核中。LVS具备良好的可靠性、可扩展性和可操做性，加上其实现最优的集群服务性能所需的低廉成本， LVS的负载均衡功能常常被用于高性能、高可用的服务器群集中。

       基于LVS技术能够实现不少高伸缩、高可用的网络服务，例如Web服务、Cache服务、DNS服务FTP服务、MAIL服务、视频／音频点播服务等， LVS的功能也在发展过程当中获得了不少用户的实践验证，例如不少著名网站和组织都在使用基于LVS架构的集群系统，包括Linux门户网站（ www.linux.com ）向RealPlayer 提供音频视频服务的Real公司（ www.real.com ） 、全球最大的开源网站( sourceforge.net ）等都是LVS项目的使用者。

      在基于LVS 项目架构的服务器集群系统中，一般包含三个功能层次：最前端的负载均衡层（ Load Balancer ）、中间的物理服务器群组层（ Server Array ）以及最底端的数据共享存储层（ Shared Storage ），典型的LVS 集群架构如图3-2 所示。在LVS负载均衡集群架构中，尽管整个集群内部有多个物理节点在处理用户发出的请求，可是在用户看来，全部的内部应用都是透明的，用户只是在使用一个虚拟服务器提供的高性能服务，这也是Linux虚拟服务器项目，即LVS项目的主要名称来源，以下是对LVS 集群架构中各个层次的功能描述。

( 1 ) Load Balancer层

      负载均衡层位于整个集群系统的最前端，由一台或者多台负载调度器（ Director Server )组成， LVS模块就安装在Director Server的系统上，而Director Server的主要功能相似路由器，其包含了完成LVS 负载转发功能所设定的路由表， Director利用这些路由表信息把用户的请求分发到Sever Array层的物理服务器（ Real Server ）上。此外，为了监测各个Real Server服务器的健康情况，在Director Server上还要安装监控模块Ldirectord，而当监控到某个Real Server不可用时，该服务器会被从LVS 路由表中剔除，恢复时又会从新加入。

( 2 ) Server Array 层

     服务器阵列或服务器池由一组实际运行应用服务的物理机器组成，Real Server能够是Web服务器、Mail 服务器、FTP服务器、DNS服务器以及视频服务器中的一个或者多个的组合。每一个Real Server之间经过高速的LAN或分布在各地的WAN 相链接。在实际应用中，为了减小资源浪费， Director Server也能够同时兼任Real Server的角色，即在Real Server同时部署LVS模块。

( 3) Shared Storage 层

          存储层是为全部Real Server提供共享存储空间和内容一致性的存储区域，在物理实现上，该层通常由磁盘阵列设备组成。而为了提供一致性的内容，一般利用NFS网络文件系统提供集群的共享数据，可是NFS在繁忙的业务系统中，性能并非很好，此时能够采用集群文件系统，例如Redhat的GFS文件系统和IBM的GPFS文件系统等。

1.          LVS的核心功能是为集群服务提供软件负载均衡，而负载均衡技术有不少实现方案，如基于DNS 域名轮流解析方案、基于客户端调度访问方案、基于应用层系统负载的调度方案，以及基于IP地址的调度方案。在上述列举的负载调度算法中，执行效率最高的是IP负载均衡技术，LVS 的IP 负载均衡技术是经过IPVS模块来实现的， IPVS是LVS 集群系统的核心软件，其主要安装在集群的Director Server上，并在Director Server上虚拟出一个服务IP地址，用户对服务的访问只能经过该虚拟IP地址实现。这个虚拟IP一般称为LVS的VIP( Virtual IP ），用户的访问请求首先通过VIP到达负载调度器，而后由负载调度器从Real Server列表中按照必定的负载均衡算法选取一个服务节点响应用户的请求。在这个过程当中，当用户的请求到达Director Server后， Director  Server如何将请求转发到提供服务的Real Server节点，而Real Server节点又如何将数据返回给用户， 这是IPVS实现负载均衡的核心技术。IPVS 实现数据路由转发的机制有三种，分别是NAT 、TUN 和DR技术。

（1） VSNAT (Virtual Server via Network Address Translation)

      即经过网络地址转换的虚拟服务器技术。在这种负载转发方案中，当用户的请求到达调度器时，调度器自动将请求报文的目标IP地址（ VIP ）替换成LVS选中的后端Real  Server地址，同时报文的目标端口也替换为选中的Real Server对应端口， 最后将报文请求发送给选中的Real Server进行处理。当Real Server处理完请求并将结果数据返回给用户时，须要再次通过负载调度器，此时调度器进行相反的地址替换操做，即将报文的源地址和源端口改为VIP地址和相应端口，而后把数据发送给用户，完成整个负载调度过程。能够看出，在这种方式下，用户请求和响应报文都必须通过Director Server 进行地址转换，请求时进行目的地址转换（ Destination Network Address Translation, DNAT ），响应时进行源地址转换（ Source Network Address Translation, SNAT ）。在这种状况下，若是用

户请求愈来愈多，调度器的处理能力就会成为集群服务快速响应的瓶颈。

( 2) VSTUN (Virtual Server via IP Tunneling)

即IP隧道技术实现的虚拟服务器。VS TUN与VSNAT技术的报文转发方法不一样，在VS TUN方式中，调度器采用IP隧道技术将用户请求转发到某个选中的Real Server上，而这个Real Server将直接响应用户的请求，再也不通过前端调度器。此外， IP TUN技术对RealServer的地域位置没有要求，其既能够与Director Server位于同一个网段，也可位于独立网络中。所以，在VS TUN方式中，调度器将只处理用户的报文请求，而无需进行转发， 故集群系统的响应速率相对而言获得极大提升。

( 3) VSDR (Virtual Server via Direct Routing)

       即直接路由技术实现的虚拟服务器。这种技术在调度链接和管理上与VSNAT和VSTUN 技术是同样的，不过它的报文转发方式与前两种均不一样， VSDR经过改写请求报文的MAC地址，将请求直接发送到选中的Real Server ，而Real Server则将响应直接返回给客户端。所以，这种技术不只避免了VSNAT 中的IP地址转换，同时也避免了VS TUN 中的IP隧道开销，因此VSDR 是三种负载调度机制中性能最高的实现方案。可是，在这种方案下， Director Server与Real Sever必须在同一物理网段上存在互联。

2 . 虚拟路由冗余协议一VRRP

       虚拟路由冗余协议（ Virtual Router Redundancy Protocol, VRRP ）是一种容错协议，其主要目的是解决路由单点故障的问题。VRRP协议将局域网内的一组路由器虚拟为单个路由，一般将其称为一个路由备份组， 而这组路由器内包括一个Master路由（ 即活动路由器）和若干个Backup 路由（即备份路由器）， VRRP虚拟路由示意图如图3-3所示。在图3-3中RouterA 、RouterB 和RouterC属于同一个VRRP组，组成一个虚拟路由器，而由VRRP协议虚拟出来的路由器拥有本身的IP地址10.110.10.1 ，而备份组内的路由器也有本身的IP 地址（如Master的IP地址为10.110.10.5, Backup 的IP地址为10.110.10.6和10.110.10.7）。

         在实际使用中，局域网内的主机仅仅知道这命虚拟路由器的IP 地址10 .110.10.1，而并不知道具体的Master路由器的IP地址以及Backup路由器的IP地址。局域网内的主机将本身的默认路由下一跳地址设置为该虚拟路由器的IP地址10.110.10.1 以后，网络内的主机就经过这个虚拟的路由器来与其余网络进行通讯。在通讯过程当中，若是备份组内的Master路由器故障，则Backup路由器将会经过选举机制从新选出一个新的Master路由器，从而继续向网络内的主机提供路由服务，最终实现了路由功能的高可用。

        路由器开启VRRP功能后，会根据设定的优先级肯定本身在备份组中的角色。优先级高的路由器成为Master路由器，优先级低的成为Backup路由器，而且Master路由器按期发送VRRP通告报文，通知备份组内的其余Backup路由器本身工做正常， 而备用路由器则启动定时器等待通告报文的到来。（如何判断Master路由器是否正常工做？）若是Backup路由器的定时器超时后仍未收到Master路由器发送来的VRRP通告报文， 则认为Master 路由器已经故障，此时Backup路由器会认为本身是主用路由器（备份组内的路由器会根据优先级选举出新的Master路由器），并对外发送VRRP通告报文。此外， VRRP在提升路由可靠性的同时，还简化了主机的路由配置， 在具备多播或广播能力的局域网中，借助VRRP能在某台路由器出现故障时仍然提供高可靠的默认链路，有效避免单一链路发生故障后网络中断的问题，而且无需修改主机动态路由协议、路由发现协议等配置信息。

1.2 KeepAlived工做原理

         Keepalived 本质上是提供数据流转发与服务器健康检查并具有故障切换的高可用路由，而数据转发与健康检查是对LVS功能的扩展和加强，所以也能够认为Keepalived是运行在用户空间的LVS 路由（LVS Router) 进程。在实际应用中， Keepalived一般部署在两台主备或一主多备的服务器上，即Keepalived进程既运行在Active/Master状态的LVS Router中，也运行在Passive/Slave状态的LVS Router中，而全部运行Keepalived进程的LVS Router都遵循虚拟路由冗余协议VRRP。在VRRP的协议框架下，做为Master的Router将会处理两个主要任务，即转发客户端访问请求到后端物理服务器以进行负载均衡和周期性的发送VRRP协议报文，而做为Slave的Routers则负责接收VRRP报文，若是某一时刻做为Slave 的Routers 接收VRRP报文失败，则认为Master Router故障， 并从Slave Routers中从新选举产生一个新的Master Router 。

         Keepalived是一个与LVS Router相关的控制进程，在RHEL7 /Centos7 系统中，Keepalived 由Systemctl 命令经过读取/etc/keepalived/keepalived.conf配置文件来启动。在遵循VRRP协议的Master Router 中， Keepalived进程会启动内核中的LVS服务以建立虚拟服务器，并根据配置拓扑对服务运行情况进行监控。此外，Master Router还会向Slave Routers 发送周期性的VRRP广播报文，而Master Router运行状态的正常与否是由Slave Routers上的VRRP 实例决定的。若是在用户预置的时间段内Slave Router不能接收到VRRP 报文，则Keepalived认为Master Router故障，同时触发LVS Router 的Failover操做。

         在Failover 的过程当中， Keepalived 建立的虚拟服务器会被清除，新的Master Router将接管VIP 发送ARP信息、设置IPVS Table记录条目（Virtual Server）以及物理服务器的健康检查和发送VRRP 广播报文。Keepalived的Failover操做针对的是四层TCP/ IP 协议，即传输层，由于TCP在传输层上进行的是基于链路链接的数据传输。因此，当服务器在响应TCP请求时，若是出现设置时间段的Timeout，则Keepalived的健康检查机制将会监测到该状况并认为该服务器故障，而后将其从服务器池中移除（故障服务器隔离） 。图3-4 是基于Keepalived 设计的具备二层拓扑的负载均衡架构，该架构分为两个层次。第一层为负载均衡层，由一个Active 和多个Backup的LVS Routers组成，其中，每一个LVS Router 都配置有两个网络接口，一个接入Internet 网络，另外一个接入内部私有网络， Active的LVS Router 在这两个网络接口间进行数据转发。在图3-4 的负载均衡架构中，位于第一层的LVS Routers和第二层的物理服务器经过私网接口接人相同的局域网中， Active的LVSRouter经过NAT 技术将Internet数据流转发到私网物理服务器上，而这些位于第二层的物理服务器运行着最终响应请求的服务。

        位于二层私网中的服务器在与Internet交互时必须通过主LVS Router的NAT转发， 而且对于外部网络中的客户端而言，访问二层私网中的物理服务器就如访问同处Internet网络中的服务，由于从客户端的角度来看，访问请求的目的地址正是位于主LVS Router上的VIP地址，而该VIP与客户端地址处于相同网络中， VIP 还能够是管理员指定的互联网域名，如www.example.com 。VIP在Keepalived的配置中一般被指定到一个或者多个虚拟服务器上，而虚拟服务器的主要任务即是监昕VIP及相应端口上的请求，当主LVS Router进行Failover操做的时候， VIP会从一个LVS Router转移到另外一个LVS（所以VIP 也称为浮动IP)。

       在Keepalived负载均衡架构的VIP 配置中，每一个将LVS Router链接到Internet的物理网卡接口都可配置多个VIP ，而且每一个VIP对应着不一样的Virtual Server ，即多个VirtualServers 能够同时监听相同物理网卡上的不一样VIP ，其中每一个VIP都对应着不一样的服务。例如， Linux 系统中的接口eth0将LVS Router链接到Internet中，则能够在eth0上配置一个地址为192.168.115.100 的VIP以用于响应HTTP服务请求，同时还能够在eth0上配置另外一个地址为192.168.115.200 的VIP 以用于响应FTP 服务请求。在这里， HTTP 服务和FTP服务均对应着监听不一样VIP 的Virtual Server 。在由一个Active Router和一个Backup Router组成的Keepalived 负载均衡架构中， Active Router的主要任务就是将VIP 上的请求转发到选中的某个后端服务器上，具体服务器的选举机制则由Keepalived 所支持的负载均衡算法来决定。

       此外， Active Router还负责动态监控后端服务器上特定服务的健康情况，监控方式主要是Keepalived自带的三种健康检测机制，即简单TCP链接、HTTP和HTTPS。就简单TCP链接检测方式， Active Router会周期性地对服务器上某个特定端口进行TCP链接，若是TCP 链接超时或者中断则认为服务不可用，而对于HTTP和HTTPS检测方式， ActiveRouter经过周期性地抓取（ Fetch ）请求URL并验证其内容来判断服务的可用性。与此同时， Backup Router一直处于Standby状态， LVS router的Failover由VRRP来处理。

 

        在Keepalived 进程启动的时候，全部LVS Routers会加人一个用来接收和发送VRRP广播的多播组， 因为VRRP是一种基于优先级的协议，所以在启动之初优先级高的LVS Router会被选举为Master Router ，而Master Router将会周期性地向多播组中的成员发送VRRP广播。若是多播组中的Backup Routers在必定时间内接收VRRP广播失败，则从新选举新的Master Router ，新的Master Router将会接管VIP并广播地址解析协议（ Address ResolutionProtocol, ARP ）信息。而当故障Router 从新恢复后，根据该Router 的优先级状况，其可能恢复到Master 状态也可能保持为Backup 状态。

图3-4中的两层负载均衡架构是最多见的部署环境，主要用于不少数据源变化不是很频繁的数据请求服务中，如静态Web页面站点，由于后端独立服务器（Real Severs ）之间不会自动进行数据同步。图3-5为基于Keepalived的三层负载均衡架构，在三层负载均衡架构中，前端的LVS Router负责将访问请求转发到物理服务器（ Real Servers ）中，而后Real Server再经过网络形式访问可共享的数据源。

       对于数据请求比较繁忙的FTP站点，三层架构是最为理想的负载均衡架构，在这种架构下，可供访问的数据源集中存储在高可用的集群服务器上， Real Servers经过NFS共享目录或者Samba文件共享等网络文件系统形式来访问数据。此外，相似的三层负载均衡架构在须要提供中心化及数据库事务处理高可用的Web站点中也被广泛使用，若是将Keepalived负载均衡器配置为Active/Active 双活模式，则还能够将三层负载均衡架构同时用于提供FTP和Web数据库服务。

1.3 KeepAlived的负载均衡算法

       Keepalived所使用的负载均调度机制由集成到内核中的IPVS模块提供， IPVS是LVS项目的核心功能模块，其设计的主要目的之一就是解决单IP多服务器的工做环境，IPVS模块使得基于TCP/IP传输层（ 第4 层）的数据交换成为可能。在实际使用中， IPVS会在内核中建立一个名为IPVS Table的表，该表记录了后端服务器的地址及服务运行状态，经过IPVS Table, Keepalived即可跟踪并将请求路由到后端物理服务器中， 即LVS Router利用此表未来自Keepalived 虚拟服务器地址的请求转发到后端服务器池中，同时将后端服务器的处理结果转发给客户端。此外， IPVS table的表结构主要取决于管理员对指定的虚拟服务器所设置的负载均衡算法， Keepalived支持如下几种负载均衡算法。

( 1 ) Round-Robin

        即所谓的轮询负载均衡，在这种算法中，服务请求会被依次转发到服务器池中的每个服务器上，而不去评估服务器的当前负载或者处理能力，服务器池中的每个服务器都被平等对待。若是使用Round-Robin负载均衡算法，每台后端服务器会轮询依次处理服务请求。

( 2 ) Weighted Round-Robin

         即加权Round-Robin 算法，是对Round-Robin 算法的一种扩展。在这种算法中，请求被依次转发到每一台服务器上，可是当前负载较轻或者计算能力较大的服务器会被转发更多的请求，服务器的处理能力经过用户指定的权重因子来决定，权重因子能够根据负载信息动态上调或者下调。若是服务器的配置差异较大，致使不一样服务器的处理能力相差较大，则加权的Round-Robin 算法会是不错的选择，可是若是请求负载频繁变更，则权重较大的服务器可能会超负荷工做。

( 3 ) Least-Connection

       即最少链接算法，在这种算法中，请求被转发到活动链接较少的服务器上。在Keepalived的实际使用中， LVS Router一直在利用内核中的IPVS Table来记录后端服务器的活动链接，从而动态跟踪每一个服务器的活动链接数。最少链接数算法是一种动态决策算法，它比较适合服务器池中每一个成员的处理能力都大体至关，同时负载请求又频繁变化的场景， 若是不一样服务器有不一样的处理能力，则下面的加权最少链接数算法较为合适。

( 4 ) Weighted Least-Connections

       即加权最少链接数算法，在这种算法中，路由会根据服务器的权重，转发更多的请求到链接数较少的服务器上。服务器的处理能力经过用户指定的权重因子来决定，权重因子能够根据负载信息动态上调或者下调。通常来讲，服务器加权算法主要用于集群存在不一样类型服务器，而服务器配置和处理能力相差较大的场景中。

( 5) Destination Hash ScheduIing

         即目标地址哈希算法，经过在静态Hash表中查询目的IP地址来肯定请求要转发的服务器，这类算法主要用于缓存代理服务器集群中。

( 6 ) Source Hash Scheduling

      即源地址哈希算法，经过在静态Hash表中查询源IP地址来肯定请求要转发的服务器，这类算法主要应用于存在多防火墙的LVS Router中。

( 7 ) Shortest Expected Delay

       即最小延时算法，在这种算法中，请求被转发到具备最小链接响应延时的服务器上。

1.4 Keepalived 路由方式

（1） NAT

      图3-6 为基于NAT 路由实现的Keepalived 负载均衡器，在NAT 机制下，每一个LVS Router 须要两个网络接口。假设eth0为接人Internet 的网络接口，则eth0上配置有一个真实的IP 地址，同时还配置了一个浮动IP地址（Floating IP ）假设eth1为接入后端私有网络的接口， 则eth1上也配置有一个真实IP地址和一个浮动IP地址。在出现故障切换Failover的时候， 接人Internet 的虚拟接口和接入私有网络的虚拟接口会同时切换到Backup的LVSRouter 上，而为了避免影响对Internet 客户端的请求响应，位于私有网络中的后端服务器均使用NAT路由的浮动IP做为与主LVS Router通讯的默认路由。

       对外提供服务的公有VIP(Public Virtual IP Address ）和私有NAT VIP(NAT Virtual IP Address）均被配置在物理网卡上而最佳的配置方式是将两个VIP 各自配置到不一样的物理网卡上，即在这种配置下，每一个LVS Router节点最多只需两个物理网卡。在NAT 路由转发中，主LVS Router 负责接收请求，并将请求的目的地址替换成LVS Router的NAT Virtual IP地址，再将其转发到选中的后端服务器上，同时服务器处理后的应答数据也经过LVS Router将其地址替换成LVS Router的Public Virtual IP 地址，而后再转发给Internet客户端，这个过程也称为IP假装，由于对客户端而言，服务器的真实IP地址已被隐藏。

        在NAT路由实现的负载均衡中，后端服务器上能够运行各类操做系统，即后端服务器上的操做系统类型并不影响LVS Router 的NAT 路由功能，可是，使用NAT 路由方式存在的一个缺点是， LVS Router在大规模集群部署中可能会是一个瓶颈，由于LVS Router要同时负责进出双向数据流的IP地址替换。

（2） DR

      相对于其余的负载均衡网络拓扑， DR(Direct Routing）路由方式为基于Keepalived 的负载均衡系统提供了更高的网络性能， DR路由方式容许后端服务器直接将处理后的应答数据返回给客户端，而无需通过LVS Router的处理操做，DR路由方案极大下降了LVS Router 形成网络瓶颈的可能性。如图3-7所示。在基于Keepalived的负载均衡架构中， Keepalived的最佳路由方式是DR 路由，即在配置Keepalived的路由方式时，优先将其设置为DR 。

1.5 Keepalived 配置与使用

Keepalived高可用负载均衡器的配置主要是编辑Keepalived的配置文件/etc/keepalived/keepalived.conf为了演示Keepalived负载均衡的配置使用，本节采用两个独立服务器来做为前端Keepalived负载均衡器，其中一台服务器做为主用负载均衡器（LBl )，另外一台服务器做为Standby负载均衡器一备（LB2），后端服务器池由四台运行HTTP服务的节点构成，后端服务器位于同一个私有网络中，其真实IP地址段为192.168.1.20-192.168.1.23 ，由Keepalived 控制的VIP 为10 .0 .0.1 。此外，每一个负载均衡器配有两张物理网卡eth0和eth1,其中eth0接入Internet, eth1与后端服务器一块儿接人私有网络，此处的负载均衡器采用Round-Robin调度算法， 因为后端节点数量很小， Keepalived的路由方法能够设置为NAT，其架构和图3-4类似，典型二层负载均衡架构。LB1的配置文件／etc/keepalived/keepalived.conf以下。

//全局配置段
global_defs {
notification_email{
admin@example . com
}
notification_email from noreply@example.com
smtp_server 127.0 . 0.1
smtp_connect_timeout 60
router_id LVS DEVEL
}
/ /VRRP配置段
vrrp_sync_group VG1 {
group {
VRRP EXT
VRRP INT
}
/ /VRRP 实例VRRP_EXT配置段
vrrp_instance VRRP_EXT {
state MASTER
interface eth0
virtual_router_id 50
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass passwordl23
}
virtual_ipaddress {
10.0.0.1
}
}
// VRRP 实例VRRP_ INT 配置段
vrrp_instance VRRP_ENT {
state MASTER
interface eth1
virtual_router_id 2
priority 100
advert_int 1
authentication{
auth_type PASS
auth_pass passwordl23
}
virtual_ipaddress {
192 .168 .1.1
}
}
//虚拟服务器LVS 配置段
virtual_server 10 .0.0 .180 {
delay_loop 6
lb_algo rr
lb_kind NAT  //NAT路由方式
protocol tcp
//后端服务器1
real_server 192.168.1.20 80 {
TCP_CHECK {
connect timeout 10
}
}
//后端服务器2
real_server 192 .168 .1.21 80 {
TCP_CHECK {
connect timeout 10
}
}
//后端服务器3
real_server 192.168.1.22 80 {
TCP_CHECK {
connect timeout 10
}
}
//后端服务器4
real_server 192.168.1.23 80 {
TCP_CHECK {
connect timeout 10
}
}

 

从Keepalived 配置文件/etc/keepali ved/keepali ved. conf 中的内容能够看到， Keepalived的配置主要分为三个模块， 即全局配置段、VRRP 定义段、虚拟服务器LVS 配置段。

1. 全局配置段

global_defs {
notification_email {
admin@example.com
}
notification_ email_from noreply@example.com
smtp_server 127 0 . 0.1
smtp_connect_timeout 60
router id LVS DEVEL
}

 

全局配置段（ global_defs ）的主要做用之一就是Keepalived出现故障时的邮件通知管理员，让管理员以邮件形式知道Keepalived的运行状况。一般状况下，邮件通知不是必须的，用户能够选择其余监控方式来对Keepalived 进行监控，如Nagios。须要说明的是，全局配置段对Keepalived来讲是可选的，其内容并非Keepalived 配置所必须的。全局配置段的几个主要配置参数说明以下：

• Notification_email ：用于配置接收邮件的负载均衡器的管理员群组邮箱。

• Notification_email_from ：自定义发出邮件的邮箱地址，即管理员邮件显示的发件人。

• SMTP ：指定简单邮件参数协议服务器地址，通常为本机。

• LVS_ID: LVS 负载均衡器标志，同一网络中其值惟一。

2. VRRP 配置段

 

vrrp_sync_group VGl (
group {
VRRP EXT
VRRP INT
}
vrrp_instance VRRP_EXT {
state MASTER
interface eth0
virtual_router_id 50
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass password123
}
virtual_ipaddress {
10.0.0.1
}
}
vrrp_instance VRRP_ INT {
state MASTER
interface eth1
virtual_router_id  
priority 100
advert_int 1
authentication {
auth_type PASS
auth__pass password123
}
virtual_ipaddress {
192.168 .1.1
}
}

 

VRRP配置段（ vrrp sync group ）主要用于定义VRRP组，在Keepalived发生任何状态

变化时，被定义在VR即组中的VRRP实例做为逻辑总体一致行动，如在发生LVS Router故障切换Failover的过程当中， VRRP组中的实例会做为一致总体同时切换。在本节的演示配置中，同一个VRRP组内配置了两个VRRP实例，分别是针对外部网络的VRRP_EXT实例和针对内部私有网络的VRRP_INT 实例。VRRP 配置段中的关键参数说明以下。

• vrrp_sync_group : VRRP实例一致组，用于定义VRRP一致组中的成员，组内的VRRP实例行为是一致的，如在Failover的时候， 一致组内的VRRP实例将同时迁移。在本机示例中，当LBl出现故障时， VRRP INT和VRRP EXT实例将同时切换到LB2上。

• vrrp_instance: VRRP实例，用于配置一个VRRP服务进程实例，其中的State设定了当前节点VRRP实例的主备状态，在主LVS Router中，该值应该为MASTER,在备LVS Router中，其值为BACKUP 。正常状况下只有Master的LVS Router在工做， Backup的LVS Router处于Standby状态。

• interface ：对外提供服务的网络接口，如eth0和eth1，选择服务接口时，必定要核实清楚，LV Router 的VIP将会配置到这个物理接口上。

• Virtual_Router_id ：虚拟路由标志，同一个VRRP实例使用惟一的标识。即同一个VRRP实例中， MASTER和BACKUP状态的VRRP实例中， virtual_router_id 值是相同的，同时在所有VRRP 组内是惟一的。

• Priority ：此参数指明了该VRRP实例的优先级，数字越大说明优先级越高，取值范围为0-255 ，在同一个VRRP实例里， MASTER的优先级高于BACKUP。若MASTER的Priority值为100 ，那BACKUP 的Priority只能是90或更小的数值。

• Advert_ int: Master路由发送VRRP广播的时间间隔，单位为秒。

• Authentication ：包含验证类型和验证密码，类型主要有PASS 和AH两种，一般使用的类型为PASS 验证密码为明文，同一VRRP实例MASTER与BACKUP使用相同的密码才能正常通讯。

• Virtual_ipaddress ：虚拟IP地址，即VIP，能够有多个虚拟IP 、地址，每一个地址占一行，不须要指定子网掩码。做为Standby的负载均衡器， LB2的keepalived.conf 配置文件与LB1相似，其不一样之处在于VRRP实例配置段中的的VRRP 实例State和Priority参数的设置，如LBl 中的State为Master, LB2 中的State为BACKUP ，而且LB2 中VRRP实例的Priority 必须小于LBl 中的优先级。

3. 虚拟服务器LVS 配置段

 

virtual_server 10.0.0.1 80 {
delay_loop 6
lb_algo rr
lb_kind NAT
protocol tcp
real_server 192 .16 8.1.20 80 {
TCP_CHECK {
connect timeout 10
}
real_server 192 .16 8.1.21 80 {
TCP_CHECK {
connect timeout 10
}
real_server 192 .16 8.1.22 80 {
TCP_CHECK {
connect timeout 10
}
real_server 192 .16 8.1.23 80 {
TCP_CHECK {
connect timeout 10
}
}

 

虚拟服务器（ Virtual Server ）配置段主要定义LVS的监昕虚拟IP地址和对应的后端服务器及其健康检测机制，虚拟服务器的定义段是Keepalived框架最重要的部分，也是其配置文件keepalived.conf 中必不可少的部分。此部分的定义主要分为一个Virtual Server的定义和多个Real Servers的定义， Virtual Server由VRRP中定义的VIP 加上端口号构成，而Real Server由后端服务器节点IP和端口号构成，相关的配置参数说明以下。

• Delay_Loop ：健康检查的时间间隔，单位为秒。

• LB_Algo ：选用的负载均衡算法，示例中的rr表示Round-Robin算法。

• LB_Kind ：采用的路由方法，示例中采用的是NAT路由，还能够采用DR和TUN路由。

• Protocol ：转发协议，通常有TCP 和UDP两种。

• TCP CHECK ：表示采用TCP链接对Real Servers 进行健康检查。

• Connect timeout : TCP链接容许中断的时间，单位为秒，超过此值认为TCP链接Timeout ，即后端服务器不可用。

上述示例中Keepalived的配置采用的是NAT路由方式，而在大规模负载均衡集群中，NAT 路由一般形成网络性能瓶颈， 所以建议采用DR路由方式。DR路由方式的配置与NAT 方式相似，，为了使用DR路由，将LB_Kind参数配置为DR。

在LBJ 和LB2 上配置完keepalived.conf 后，分别在两个节点上启动Keepalived服务，便可正常使用Keepalived的负载均衡功能。

//启动Keepalived服务
systemctl start keepalived . service
//将Keepalived服务设置为开机启动
systemctl enable keepalived . service

 

 

 

链接 ：

Keepliaved介绍 ：https://blog.csdn.net/huwh_/article/details/77113410