基于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

  • 发表于:
  • 原文链接:https://kuaibao.qq.com/s/20180606G1CIC400?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券