Linux运维架构之LVS+Keepalived 实现高可用负载均衡
Linux运维架构之LVS+Keepalived 实现高可用负载均衡
王先森keepalived介绍
keepalived软件起初是专为LVS负载均衡软件设计的,用来管理并监控LVS集群系统中各个服务节点状态,后来又加入了可以实现高可用的VRRP功能.此,keepalived除了能够管理LVS软件外,还可以作为其他服务(例如:Nginx,Haproxy,MySQL等)的高可用解决方案软件。
VRRP(Virtual Router Redundancy Protocol)虚拟路由器冗余协议,是一种容错的主备模式的协议,保证当主机的下一跳路由出现故障时,由另一台路由器来代替出现故障的路由器进行工作,通过VRRP可以在网络发生故障时透明的进行设备切换而不影响主机之间的数据通信。
Keepalived软件主要是通过VRRP协议实现高可用功能,在安装keepalived的服务器主机上会在配置文件中设置一个虚拟IP,当该keepalived节点为主节点且正常运行时,设置的虚拟Ip就会在该节点生效且绑定在该主机的网卡上,而其他备用主机设置的虚拟IP就不会生效。当测到主keepalived节点出现故障时,备用keepalived节点检会进行抢占提供服务,抢占成功的keepalived节点就会将配置的虚拟IP绑定在自己的网卡上,这样对外部用户来说虚拟IP提供的服务是一直可用的,当故障服务器被修复后可以正常工作时Keepalived会自动的将该服务器加入到服务器群中。在整个过程中,故障检测、故障服务器剔除以及修复后的服务器重新上线这些操作都是由keepalived自动完成,运维人员只需要关注故障服务器的修复。
安装keepalived环境说明
1 | [root@lb01 ~]# yum install keepalived -y |
keepalived配置
keepalived配置文件一般在/etc/keepalived/keepalived.conf下
1 | 全局配置 |
1 | ! Configuration File for keepalived |
1 | ! Configuration File for keepalived |
启动并检查
1 | systemctl start keepalived |
lvs简介
LVS,全称Linux Virtual Server,是国人章文嵩发起的一个开源项目。
在社区具有很大的热度,是一个基于四层、具有强大性能的反向代理服务器。早期使用lvs需要修改内核才能使用,但是由于性能优异,现在已经被收入内核。
通用体系结构
LVS的一些相关术语:
LVS的模型中有两个角色:
调度器: Director,又称为Dispatcher,Balancer调度器主要用于接受用户请求。
**真实主机:**Real Server,简称为RS。用于真正处理用户的请求。
而为了更好地理解,我们将所在角色的IP地址分为以下三种:
**Director Virtual IP:**调度器用于与客户端通信的IP地址,简称为VIP
Director IP:调度器用于与RealServer通信的IP地址,简称为DIP。
Real Server : 后端主机的用于与调度器通信的IP地址,简称为RIP。
LVS的三种调度模式
LVS-NAT模式
NAT模式称为全称Virtualserver via Network address translation(VS/NAT)
,是通过网络地址转换的方法来实现调度的。首先调度器(Director)接收到客户的请求数据包时(请求的目的IP为VIP),根据调度算法决定将请求发送给哪个后端的真实服务器(RS)。然后调度就把客户端发送的请求数据包的目标IP地址及端口改成后端真实服务器的IP地址(RIP),这样真实服务器(RS)就能够接收到客户的请求数据包了。真实服务器响应完请求后,查看默认路由(NAT模式下我们需要把RS的默认路由设置为DS服务器。)把响应后的数据包发送给DS,DS再接收到响应包后,把包的源地址改成虚拟地址(VIP)然后发送回给客户端。
具体工作流程:
原理:
基于ip伪装MASQUERADES
,原理是多目标DNAT。
所以请求和响应都经由Director调度器。
LVS-NAT的优点与缺点
优点:
- 支持端口映射
- RS可以使用任意操作系统
- 节省公有IP地址。
RIP和DIP都应该使用同一网段私有地址,而且RS的网关要指向DIP。
使用nat另外一个好处就是后端的主机相对比较安全。
缺点:
- 请求和响应报文都要经过Director转发;极高负载时,Director可能成为系统瓶颈。
就是效率低的意思。
LVS-TUN(IP隧道)
在LVS(NAT)模式的集群环境中,由于所有的数据请求及响应的数据包都需要经过LVS调度器转发,如果后端服务器的数量大于10台,则调度器就会成为整个集群环境的瓶颈。我们知道,数据请求包往往远小于响应数据包的大小。因为响应数据包中包含有客户需要的具体数据,所以LVS(TUN)的思路就是将请求与响应数据分离,让调度器仅处理数据请求,而让真实服务器响应数据包直接返回给客户端。LVS/TUN
工作模式拓扑结构如图所示。其中,IP隧道(IP tunning)是一种数据包封装技术,它可以将原始数据包封装并添加新的包头(内容包括新的源地址及端口、目标地址及端口),从而实现将一个目标为调度器的VIP地址的数据包封装,通过隧道转发给后端的真实服务器(Real Server),通过将客户端发往调度器的原始数据包封装,并在其基础上添加新的数据包头(修改目标地址为调度器选择出来的真实服务器的IP地址及对应端口),LVS(TUN)模式要求真实服务器可以直接与外部网络连接,真实服务器在收到请求数据包后直接给客户端主机响应数据。
原理
基于隧道封装技术。在IP报文的外面再包一层IP报文。
当Director接收到请求的时候,选举出调度的RealServer
当接受到从Director而来的请求时,RealServer则会使用lo接口上的VIP直接响应CIP。
这样CIP请求VIP的资源,收到的也是VIP响应。
LVS-TUN的优点与缺点
优点:
- RIP,VIP,DIP都应该使用公网地址,且RS网关不指向DIP;
只接受进站请求,解决了LVS-NAT时的问题,减少负载。
请求报文经由Director调度,但是响应报文不需经由Director。
缺点:
- 不指向Director所以不支持端口映射。
- RS的OS必须支持隧道功能。
- 隧道技术会额外花费性能,增大开销。
LVS-DR模式
全称:Virtual Server via Direct Routing(VS-DR),也叫直接路由模式,用直接路由技术实现虚拟服务器。当参与集群的计算机和作为控制管理的计算机在同一个网段时可以用此方法,控制管理的计算机接收到请求包时直接送到参与集群的节点。直接路由模式比较特别,很难说和什么方面相似,前种模式基本上都是工作在网络层上(三层),而直接路由模式则应该是工作在数据链路层上(二层)。
原理
当Director接收到请求之后,通过调度方法选举出RealServer。
讲目标地址的MAC地址改为RealServer的MAC地址。
RealServer接受到转发而来的请求,发现目标地址是VIP。RealServer配置在lo接口上。
处理请求之后则使用lo接口上的VIP响应CIP。
LVS-DR的优点与缺点
优点:
- RIP可以使用私有地址,也可以使用公网地址。
只要求DIP和RIP的地址在同一个网段内。
- 请求报文经由Director调度,但是响应报文不经由Director。
- RS可以使用大多数OS
缺点:
- 不支持端口映射。
- 不能跨局域网。
总结
三种模型虽然各有利弊,但是由于追求性能和便捷,DR是目前用得最多的LVS模型。
LVS的八种调度方法
静态方法:仅依据算法本身进行轮询调度
- RR:Round Robin,轮询调度
一个接一个,自上而下
- WRR:Weighted RR,加权轮询调度
加权,手动让能者多劳。
- SH:SourceIP Hash 源地址散列调度
来自同一个IP地址的请求都将调度到同一个RealServer
- DH:Destination Hash 目标地址散列调度
不管IP,请求特定的东西,都定义到同一个RS上。
动态方法:根据算法及RS的当前负载状态进行调度
LC:least connections(最小链接数)
链接最少,也就是Overhead最小就调度给谁。
假如都一样,就根据配置的RS自上而下调度。
WLC:Weighted Least Connection (加权最小连接数)
各个服务器相应的权值表示其处理性能。服务器的缺省权值为1,系统管理员可以动态地设置服务器的权值
SED:Shortest Expection Delay(最小期望延迟)
WLC算法的改进。
NQ:Never Queue 最少队列调度
SED算法的改进,无需队列。如果有realserver的连接数等于0就直接分配过去
LBLC:Locality-Based Least-Connection,基于局部的的LC算法
算法是针对请求报文的目标IP地址的 负载均衡调度,目前主要用于Cache集群系统,因为在Cache集群客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求,算法的设计目标是在服务器的负载基本平衡情况下,将相同目标IP地址的请求调度到同一台服务器,来提高各台服务器的访问局部性和Cache命中率,从而提升整个集群系统的处理能力。LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于一半的工作负载,则使用’最少连接’的原则选出一个可用的服务器,将请求发送到服务器。
LBLCR:Locality-Based Least-Connection with Replication(带复制的lblc算法)
算法也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统,它与LBLC算法不同之处是它要维护从一个目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。按’最小连接’原则从该服务器组中选出一一台服务器,若服务器没有超载,将请求发送到该服务器;若服务器超载,则按’最小连接’原则从整个集群中选出一台服务器,将该服务器加入到这个服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的程度。
keepalived配合LVS高可用
配置LVS-DR
主机名 | 主机地址 | 角色 |
---|---|---|
lb01 | 10.1.1.11 ,VIP:10.1.1.50 | LVS+keepalived主(Director) |
lb02 | 10.1.1.12 ,VIP:10.1.1.50 | LVS+keepalived备(Director) |
node1 | 10.1.1.15 | Nginx(RealServer) |
node2 | 10.1.1.16 | Nginx(RealServer) |
设置后端服务器
在RealServer中修改ARP内核参数
由于LVS服务器和后端服务器的网卡上都配置了VIP,那么当客户端联系VIP的时候肯定是和LVS服务器的VIP进行通信,然后由LVS服务器基于规则进行调度,我们知道2层通信是基于MAC地址的,那么首次通信时客户端可能并不知道LVS服务器的MAC地址,那么就需要进行ARP广播来解析出VIP所在的服务器的MAC地址,那么显然对客户端进行ARP应答的只能是LVS服务器不能是后端服务器,所以我们就要在后端上修改内核参数来禁止ARP应答和宣告。那么有2个内核参数表示这两个设置:
arp_ignore:表示接收到ARP广播时的响应级别,默认值为0
- 0 默认值,表示响应所有,只要对方查询的IP配置在我自己这台主机上且无论ARP请求从哪个网卡进来,该主机都会响应
- 1 表示收到该ARP请求的网卡IP与ARP请求的IP一致,该主机才响应
arp_announce:定义将自己的地址向外通告的级别,默认是0
- 0 表示将本机所有的MAC地址都向外通告
- 1 表示多网卡主机且都配置了IP地址,那么该主机接入到网络时,无论哪个网卡接入到网络,该网卡都会向外宣告自己所有的MAC地址,所以1表示如果IP不在这个接口上,就避免向外通告,但是不保证一定不会下外通告。
- 2 表示仅向网卡IP直连的网络进行通告
为什么会有这些级别呢?因为主机可以有多个网卡,每个网卡都对应一个网段,默认情况下这个多网卡主机只要接入网络它就会把自己所在的所有网络地址都向外进行通告。
所以对于后端服务器,也就是本例子中的Nginx,我们应该在lo上配置子接口,且设置arp_ignore为1,arp_announce为2。
1 | echo "1" > /proc/sys/net/ipv4/ip_forward |