LVS以及keepalived

常见的硬件负载均衡器有：F5，A10，Citrix

常见的软件负载均衡器有：nginx（七层），lvs（四层），haproxy（四层七层都可以）

四层和七层有什么区别：四层设备只解析四层协议，所以对于应用层协议是什么内容不做处理，由于不解析更高层次协议，所以工作性能更好，所以例如不能根据用户的URL/URI来做负载均衡。

工作在七层的反向代理负载均衡设备，它是为某些特定协议提供的，因此他能精确解码该协议，而且还能再该协议上作出修改之后做出负载均衡，操纵能力更强。

——————–

LVS简介：

LVS-Linux Virtual Server

它能够接受用户请求，根据用户地址提供的IP和端口 来判定是不是需要转发至后端Real server，因为它是一个四层设备，他能够解析三层和四层请求，所以能够识别用户请求的IP和端口。

LVS工作机制：

LVS工作在Input链上，当用户的请求到达本机之后，一旦发现是本机（地址加端口）的请求，立即转到Input链上，而LVS就监控在Input链上，并且在input链上设置规则，一旦发现用户请求的是一个集群服务，会强行修改 文的行程，本来过了input该去用户空间了，强行将该 文送往forward链，并通过forward送往postrouting，转发至其他主机，所以LVS不能和iptables同时使用。

防火墙是使用iptables管理工具来管理内核模块netfilter，LVS是使用ipvsadm管理工具来管理内核模块ipvs。

ipvsadm：管理集群服务的命令行工具

ipvs：内核模块

LVS的类型：

NAT：地址转换

前端的Director需要两个 络接口（至少），一个 络接口面向于互联 ，另外一个接口以内 形式面向于各个real server，用户请求到达的时候，它是将用户请求的目标地址转换为real server中的某一个地址的方式来实现的。

TUN模型基本法则：

1、各集群节点可以不再同一物理 络

2、real server必须是公 地址

3、Director仅处理入站请求

4、real server 关不能指向Director

5、只有支持隧道功能的OS才能用于real server

6、不支持端口映射

———————-

DR：直接路由

用户请求来了之后通过交换机到达Director，Director知道自己有三个real server，根据调度算法挑选一个real server，将请求直接转发给real server，real server直接创建回应 文，通过交换机回应给客户端，不再需要经过Director，所以Director只需要处理进来的请求。

用户请求过程：

但是用户请求的时候，源IP是CIP，目标IP是VIP，real server回应的源IP是RIP，目标IP是CIP，Client根本没有请求RIP，所以不会接受该 文。那响应 文应该是VIP，所以在DR模型中，Director和real server都配有VIP，但是四个主机都有同一个VIP就出现地址冲突了，所以每个主机都有两个地址，一个配置在 卡（DIP/RIP）上，一个配置在 卡别名（VIP）上，VIP是配置在 卡别名的，并且是隐藏的，所在在整个 络上广播以下，问问谁是VIP们是不会回答的，只有在响应客户端请求的时候作为源地址使用。

客户端请求的时候，路由器将用户请求封装成帧，源MAC是路由器MAC，目标MAC是DirectorVIP所在的 卡的MAC地址，他怎么知道Director上VIP的MAC呢过ARP地址解析（广播方式），每一个real server不能受到，不会响应，只有Director上的VIP响应。

那Director怎么发给各个real server呢/p>

不需要修改目标地址，在DR模型中，Director转发 文到各real server时候，不需要修改目标地址的方式来实现的，而是仅仅修改了MAC地址。

所以每个DIP和RIP都可以通过ARP解析得到相应的MAC地址，所以当用户的请求到达Director上之后，Director发现请求的是一个集群服务，所以他不会拆IP首部的，只是把MAC首部拆了，在重新封装：源MAC改为Director的MAC，目标MAC就是调度算法挑出来的RMAC，real server收到之后发现MAC是自己的，拆掉之后IP也是自己的，由此， 文接受下来，响应时候人家请求的是VIP，用VIP响应，所以源IP是VIP，目标IP是CIP。

动态调度方法：

lc：最少连接，怎么计算谁的连接少，谁的连接多呢通过计算当前后端每一个活动连接以及非活动链接的总数并作比较之后，哪一个最少就使用哪一个。

active*256+inactive谁的小就选谁。

wlc：加权最少连接，谁小给谁

（active*256+inactive）/weight

不能确定第一次就选中最优秀的

sed：最短期望延迟：谁小给谁（忽略inactive）

（active+1）*256/weight

只能确定第一次挑中的是最优秀的，而后可能其他的服务器都要忙死了，可能有的服务器还没有连接请求

如上图，c有了，B有了，所以，第三个肯定给A，然后再根据权重进行计算。

LBLC：基于本地的最少连接（动态的dh）

类似于dh算法，但是来了一个新请求之后，会挑选一个最闲的服务器，并不是按次序轮流，有可能会破坏命中率。

LBLCR：基于本地的带复制功能的最少链接

只要是个新请求，一定会发给连接数最少的real server，这样会破坏缓存命中率，并不会，cache中会通过内容分发协议实现缓存共享的，如果一个请求在cache上没有，它不会去后端数据服务器上去找，而是去另外一个cache server上去找，找了的给自己缓存一份。

但是并不是我将所有的共享给你，而是你没有了，你来我这要，我有了我给你一份。它可以保证同一个请求尽量去同一个服务器上去，只有新请求才会进行挑选。

ipvs默认方法是：wlc

————————–

keepalived：

keepalived是用C语言编写的路由软件，该项目的主要目标是为Linux系统和基于Linux的基础结构提供负载均衡和高可用的简单而强大的功能。负载均衡框架依赖于提供第四层负载平衡的著名而广泛使用的Linux虚拟服务器（IPVS）内核模块。keepalived实现了一组检查器，以根据其运动状态动态，自适应的维护和管理负载平衡的服务器池。另一方面，VRRP实现了高可用性协议，VRRP是路由器故障转移的基础。此外，Keepalived还实现了一组VRRP有限状态机的挂钩，从而提供了低级和高速协议交互。为了提供最快的 络故障检测，Keepalived实施BFD协议。VRRP状态转换可以考虑BFD提示来驱动快速状态转换。Keepalived框架可以独立使用，也可以一起使用以提供弹性基础架构。

VRRP：虚拟路由冗余协议

虚拟路由冗余协议，为了解决局域 中配置静态 关出现单点失效现象的路由协议。广泛应用在边缘 络中，设计目标是支持特定情况下IP数据流量失败转移不会引起混乱，允许主机使用单路由器，以及及时在实际第一跳路由器使用失败的情形下仍能维护路由器件的连通性。

BFD：双向转发检测

双向转发检测，BFD是一种全 同意的检测机制，用于快速检测，监控 络中链路或者IP路由的转发连通状况。BFD控制 文封装在UDP 文中传送，对于单挑检测其UDP目的端口 为3784，对于多条检测其UDP目的端口 为4784或3784.

面试题：请解答一下keepalived的工作原理。
keepalived高可用对之间是通过VRRP通信的，因此，我从VRRP开始给您讲起：
1）VRRP，虚拟路由冗余协议，VRRP的出现是为了解决静态路由的单点故障。
2）VRRP是通过一种竞选协议机制来将路由任务交给某台VRRP路由器的。
3）VRRP用IP多播的方式（默认多播地址224.0.0.18）实现高可用对之间通信
4）工作时主节点发包，备节点收包，当备节点接收不到主节点发的数据包时，就启动接管程序接管主节点的资源。备节点可以有多个，通过优先级竞选，但一般keepalived系统运维中都是一对
5）VRRP使用了加密协议加密数据，keepalived官方目前还是推荐用明文的方式配置认证类型和密码。
介绍完VRRP，接下来我再介绍一下keepalived服务的工作原理：
keepalived高可用对之间通过VRRP进行通信的，VRRP是通过竞选机制来确定主备的，主的优先级高于备，因此，工作时主会优先获得所有的资源，备节点处于等待状态，当主挂了的时候，备节点就会接管主节点的资源，然后顶替主节点对外提供服务。
在keepalived服务对之间，只要作为主的服务器会一直发送VRRP广播包，告诉备他还活着，此时备不会抢占主，当主不可用时，备就会启动相关服务接管资源，保证业务的连续性，接管速度最快可以小于1秒。