基于LVS的高可用架构

版权声明：

1.LVS 的模式

我们先分析实现虚拟网络服务的主要技术，指出 IP负载均衡技术是在负载调度器的实现技术中效率最高的。LVS实现了3种IP负载均衡技术（LVS/NAT、LVS/DR和LVS/TUN）。

本文主要描述这3种技术的原理，以及它们各自的优缺点。

1.1 LVS/NAT（Network Address Translation）网路地址转换

- 用户通过 VIP访问网络服务时，请求先达到LB(调度器)；

- 调度器根据连接调度算法从一组真实服务器中选出一台服务器，将报文的目标地址 Virtual IP Address改写成选定服务器的地址，报文的目标端口改写成选定服务器的相应端口，最后将修改后的报文发送给选出的服务器。

- 调度器在连接Hash表中记录这个连接，当这个连接的下一个报文到达时，从连接Hash表中可以得到原选定服务器的地址和端口，进行同样的改写操作，并将报文传给原选定的服务器；

- 后端的webserver 处理请求包，并返回数据包给调度器；

- 当来自真实服务器的响应报文经过调度器时，调度器将报文的源地址和源端口改为Virtual IP Address和相应的端口，再把报文发给用户。

NAT模式的特点是：

- 后端RS不需要外网IP，数据在内网环境完成交互；

- 一个LB承载的RealServer数量有限，LB容易成为整个web 集群的瓶颈。

1.2 DR (Direct Routing) 直接路由模式

DR模式

它的连接调度和管理与LVS/NAT中的一样，它的报文转发方法又有不同，将报文直接路由给目标服务器。

- LB和RS都使用同一个IP对外服务，必须在一个广播域/交换机上｡

- 但只有DR对ARP请求进行响应,所有RS对本身这个IP的ARP请求保持静默｡

- 网关会把对这个服务IP的请求全部定向给DR,而DR收到数据包后根据调度算法,找出对应的RS,把目的MAC地址改为RS的MAC（因为IP一致）并将请求分发给这台RS｡

- 这时RS收到这个数据包,处理完成之后，由于IP一致，可以直接将数据返给客户，则等于直接从客户端收到这个数据包无异,处理后直接返回给客户端｡

DR模式的特点在于：

- LB与Realserver 必须在物理上有一个网卡通过不间断的局域网相连，RealServer上绑定的VIP配置在各自Non-ARP的网络设备上(如lo或tunl)，LB的VIP地址对外可见；

- DR模式下，请求报文必须经过LB调度，响应报文不经过LB，而是直接转发给用户；

- 解决了NAT模式下的转发瓶颈问题，能够支撑更大规模的负载均衡场景；

- 比较耗费外网IP资源，在生产环境中，可以采用DR/NAT混合模式来缓解这个问题。

1.3 LVS Tunnel (IP Tunnel)隧道模式

原理：

其实TUN模式跟DR模式的数据流走向类似，但是两种方式的工作原理、应用场景完全不一样。DR模式基于数据报文重写（mac修改）；TUN基于IP Tunnel(IP 隧道)，是数据包的重新封装。

VS/TUN 的工作流程如图3所示：

- 它的连接调度和管理与VS/NAT中的一样，只是它的报文转发方法不同；

- 调度器根据各个服务器的负载情况，动态地选择一台服务器， 将请求报文封装在另一个IP报文中，再将封装后的IP报文转发给选出的服务器；

- 服务器收到报文后，先将报文解封获得原来目标地址为VIP的报文，服务器发 现VIP地址被配置在本地的IP隧道设备上，所以就处理这个请求，然后根据路由表将响应报文直接返回给客户。

适用场景：

在生产环境中由于业务需要、技术需要或者安全需要，可能使用交换机进行VLAN隔离（即形成若干个虚拟的独立的局域网），我们可能需要LVS节点在局域网A，而需要进行负载的多台web(或mysql)服务器可能在局域网B中，这个时候就需要用到LVS-TUN模式了

总结：

LVS在诞生初期就是为了高可用、可弹性伸缩的网络服务而设计，三种调度方式都是基于IP层做的负载均衡。LVS的优点是高性能、高可用、可伸缩性，现在已成linux 标准内核里面的一部分（kernel 2.4.24以后），用LVS应对高流量的业务场景是非常合适，而且性价比高。

结合当前的业务情况，我们生产环境选择用LVS-NAT模式，主要基于以下原因：

IP资源开销小；

后端的fullnode 服务节点不暴露公网IP，提升整体的安全性。

2.Keepalived 功能

VRRP协议为keepalived实现基础的

虚拟路由冗余协议，可以认为是实现路由器高可用的协议，即将N台提供相同功能的路由器组成一个路由器组，这个组里面有一个master和多个backup，

- master上面有一个对外提供服务的vip（该路由器所在局域网内其他机器的默认路由为该vip），master会发组播，当backup收不到vrrp包时就认为master宕掉了

- 这时就需要根据VRRP的优先级来选举一个backup当master。这样的话就可以保证路由器的高可用了。

keepalived主要有三个模块，Core、Check和VRRP

- core：主进程的启动、维护以及全局配置文件的加载和解析

- 用于监控LVS各个服务节点的状态

- check：健康检查

- vrrp：实现VRRP协议 (虚拟路由冗余协议)

VRRP：保证不间断运行，用最快的速度接管服务

防火墙一定要开启 vrrp协议的支持

用于监控LVS各个服务节点的状态

双主配置

Keepalived配置文件keepalived.conf的默认位置是/etc/keepalived

global_defs {

router_id sz_proxy_fn1

}

vrrp_instance VI_2 {

state BACKUP

interface eth0

virtual_router_id 55

priority 99

advert_int 1

authentication {

auth_type PASS

auth_pass proxyfn2

}

virtual_ipaddress {

120.197.130.119 dev enp3s0f1 label enp3s0f1:vip

}

}

其中router_id 中master必须和slave一只

advert_int 代表心跳检测

virtual_router_id 代表虚拟路由id

keepalived 用于VIP的快速切换，可以实现LB的主备，在服务器出现宕机或者维护的时候，可以迅速把流量导向备节点。目前对外的服务都会采用LVS+keepalived 的方式组成成对的LB调度器，以提供业务的持续服务能力。

3.Nginx VS HAproxy

介绍完了调度器之后，我们重点分析以下nginx /haproxy 在作为后端web server方面各自有的特点。随着互联网的快速发展，web类的服务越来越多，而且业务逻辑也非常复杂，并发能力已经不是考量一个web类服务的唯一指标， 更多的时候我们需要考量业务本身的需求。

这个时候就需要一个性能强大、配置灵活、支持第三方扩展、监控、访问日志审计等综合需求的web中间件。我们主要来比较nginx和haproxy作为webserver各自的特点。

nginx特点：

- nginx 对网络稳定性的依赖性较小，理论上只要ping得通，网页就能打得开；

- nginx工作在网络的第七层，侧重点在web服务器，可以针对Http应用做一些分流的策略，如域名、目录结构。nginx支持的协议类型有：HTTP/TCP/GRPC等，

- nginx有众多第三方模块，作为web 应用服务器，可以利用第三方模块灵活扩展，比如lua，应用可以根据场景，在nginx层完成逻辑处理；nginx自身的状态检测，比如nginx-module-vts等；

- 在静态文件处理上，加location可以灵活配置，比如重定向到CDN，或者缓存服务器等；

- nginx在转发效率高，专为性能优化而开发；支持epoll模型，能经受高并发的考验，优化后的理论并发可以达到几万

haproxy 特点：

- haproxy 可以工作在第四、七层，在web类应用中，配置策略没有nginx灵活，比如目录层次，https证书配置等。

- haproxy 的角色定位其实是一个LB(load blance)，是一款负载均衡软件，也支持很多负载均衡策略，比如：roundrobin/static-rr/source等。

总结：

http/https等web类服务，我们可以根据应用的复杂度，用户场景等方面具体考量用哪种webserver，目前EOShenzhen已经在接口类服务会采用haproxy作转发器，haproxy在转发效率和并发能力上是优于nginx的，而且支持的负载均衡策略非常多；

网站类服务（包括https）会采用LVS+nginx的方案，灵活配置，支持热重启等。特别是https 可以借助于intel QAT 加速卡+nginx第三方扩展来完成加解密的过程，极大提升nginx 对https的支撑性能。

EOShenzhen已经构建了成熟的LB集群、Web server集群，并会持续投入更多的资源，用一流的技术能力，来为开发者提供强有力的接入支撑。

本文图片由EOShenzhen制作，转载请声明

关于EOShenzhen，了解更多可点击：

加入我们的知识星球吧！

关于我们 更多联系：

Website：https://eoshenzhen.io

Steem：https://steemit.com/@eoshenzhen

Busy：https://busy.org/@eoshenzhen

Telegram：https://t.me/eoshenzhen

Twitter：https://twitter.com/eostechlover

简书：EOS技术爱好者

新浪微博：EOSTechLover