keepalived负载均衡(负载均衡 haproxy)

nginx+keepalive实现负载均衡高可用

? ? ? 在实际生产环境中负载均衡是一个至关重要的位置，负载均衡关乎着整个网站访问的命脉，所以运维人员对于它的处理机制和高可用的重视非常高，负载均衡存在单点故障无疑是对整个网站埋下了定时炸弹，nginx +keeplive实现负载高可用，保障业务持续提供服务避免负载均衡的单点故障。

角色? ? ? ? ? ? ? ? IP地址? ? ? ? ? ? ? ? 主机名

负载01? ? ? ? ? ? 10.0.0.2? ? ? ? ? ? ? ?LB01

负载02? ? ? ? ? ? 10.0.0.3? ? ? ? ? ? ? ?LB02

虚拟服务? ? ? ? ?10.0.0.4? ? ? ? ? ? ? ? ? ? ? ?

? ? ? 两台nginx负载均衡+keepalive实现负载高可用两台LB的IP地址分别为：10.0.0.2、10.0.0.3 keepalive的vip为：10.0.0.4,当10.0.0.2正常在vip工作在10.0.0.2,10.0.0.3服务出现宕机则vip自动跳转到10.0.0.3的LB

? ? 我们可以看见两台LB中的负载配置相同，server name为vip,当请求到达vip所在的LB服务器则会代理到对应的node池进行负载均衡，通过keepalive的vip漂移为我们的服务提供高可用，保障网站7*24提供服务

? ? ? ? ?通过演示视频我们模拟LB01宕机，发现vip漂移至第二台LB并且这个切换对于用户是无感知的，今天nginx+keepalive的测试就到这里谢谢！

主备服务器因为硬件或者软件问题（网线松动或者nginx进程）造成keepalived服务无法检测到心跳信息，nginx服务down掉keepalive还在正常运行没有进行主备切换等等都会造成高可用没有达到理想的效果我们可以通过主备机脚本来规避这些因素造成keepalive无法正常主备切换

????主机能不通，VIP在备机则认为非正常主备切换可能主机状态正常vip在主备机都存在

判断主机nginx服务是否正常，如果nginx服务down掉尝试启动，如果nginx尝试启动未成功则停掉主机keepalive服务切换至备机保证业务正常运行??

通过以上两个脚本检测，我们能够做到规避主备之间心跳检测不正常，但是主备机服务正常会存在主备之间都会有VIP导致负载脑裂的问题以及负载服务down掉，keepalive服务正常导致业务中断问题。

lvs 和 keepalived的有什么区别

1、特点不同：lvs基于4层的网络协议的，抗负载能力强，对于服务器的硬件要求除了网卡外，其他没有太多要求。keepalived主要的工作是提供lvs控制器的一个冗余，并且对real服务器做健康检查，发现不健康的real服务器，从lvs集群中剔除，real服务器只负责提供服务。

2、性质不同：LVS是一个开源的软件，可以实现LINUX平台下的简单负载均衡。LVS是Linux Virtual Server的缩写，意思是Linux虚拟服务器。keepalived是一个类似于layer3, 4 5交换机制的软件。

3、作用不同：Keepalived主要用作RealServer的健康状态检查以及LoadBalance主机和BackUP主机之间failover的实现。LVS的作用是在网上能找到一些相关技术资源。

扩展资料：

注意事项：

在LVS方案中，虚拟ip地址与普通网络接口大大不同，这点需要特别注意。虚拟ip地址的广播地址是lvs本身，子网掩码是255.255.255.255，因为有若干机器要使用同一个ip地址，用本身做广播地址和把子网掩码设成4个255就不会造成ip地址冲突了,否则lvs将不能正常转发访问请求。

假如两台VS之间使用的互备关系，那么当一台VS接管LVS服务时，可能会网络不通，这时因为路由器的MAC缓存表里关于vip这个地址的MAC地 址还是被替换的VS的MAC。

参考资料来源：百度百科-Keepalived

参考资料来源：百度百科-LVS

负载均衡基本介绍

【负载均衡架构部分转自】 58沈剑 [架构师之路](

负载均衡： 是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】

常见的负载均衡方案：

【客户端层】到【反向代理层】的负载均衡，是通过“DNS轮询”实现的：DNS-server对于一个域名配置了多个解析ip，每次DNS解析请求来访问DNS-server，会轮询返回这些ip，保证每个ip的解析概率是相同的。这些ip就是nginx的外网ip，以做到每台nginx的请求分配也是均衡的。

【反向代理层】到【站点层】的负载均衡，是通过“nginx”实现的。通过修改nginx.conf，可以实现多种负载均衡策略：

【站点层】到【服务层】的负载均衡，是通过“服务连接池”实现的。

上游连接池会建立与下游服务多个连接，每次请求会“随机”选取连接来访问下游服务。（也即是rpc框架实现的）

在数据量很大的情况下，由于数据层（db，cache）涉及数据的水平切分，所以数据层的负载均衡更为复杂一些，它分为“数据的均衡”，与“请求的均衡”。

数据的均衡是指 ：水平切分后的每个服务（db，cache），数据量是差不多的。

请求的均衡是指 ：水平切分后的每个服务（db，cache），请求量是差不多的。

（1）按照range水平切分

（2）按照id哈希水平切分

[图片上传中...(-6b2508-1561902875888-0)]

常见的负载均衡系统包括 3 种：DNS 负载均衡、硬件负载均衡和软件负载均衡。

硬件负载均衡是通过单独的硬件设备来实现负载均衡功能，这类设备和路由器、交换机类似，可以理解为一个用于负载均衡的基础网络设备。比如业界非常出名的F5

缺点：

（1）价格实在非常昂贵

（2）扩展性不强

软件负载均衡通过负载均衡软件来实现负载均衡功能，常见的有 Nginx 和 LVS。

nginx和F5：

nginx和lvs比较：

lvs：

ELB：

SLB：

题目：日活跃用户 1000 万的论坛的负载均衡集群，该如何设计呢？

（1）评估流量

1000万DAU，换算成秒级（一天12小时），平均约等于232。

考虑每个用户操作次数，假定10，换算成平均QPS=2320。

考虑峰值是均值倍数，假定5，换算成峰值QPS=11600。

考虑静态资源、图片资源、服务拆分等，流量放大效应，假定10，QPS 10=116000。

（2）容量规划

考虑高可用、异地多活，QPS 2=232000。

考虑未来半年增长，QPS*1.5=348000。

（3）方案设计

可以用三级导流：

第一级，DNS，确定机房，以目前量级，可以不考虑。

第二级，确定集群，扩展优先，则选Haproxy/LVS，稳定优先则选F5。

第三级，Nginx+KeepAlived，确定实例。

（4）架构图

接入层技术：

缺点：

优点：

缺点：

优点：

缺点：

缺点：

nginx毕竟是软件，性能比tomcat好，但总有个上限，超出了上限，还是扛不住。lvs就不一样了，它实施在操作系统层面；f5的性能又更好了，它实施在硬件层面；它们性能比nginx好很多，例如每秒可以抗10w，这样可以利用他们来扩容。

99.9999%的公司到这一步基本就能解决接入层高可用、扩展性、负载均衡的问题。 假设还扛不住的话，就要考虑使用硬件设备f5等。如果还是扛不住，那么只有DNS来扩容了。

水平扩展，才是解决性能问题的根本方案，能够通过加机器扩充性能的方案才具备最好的扩展性。 facebook，google，baidu的PV是不是超过80亿呢，它们的域名只对应一个ip么，终点又是起点，还是得通过DNS轮询来进行扩容：

比如购买了阿里云或者aws。那么基本会使用云厂商提供的负载均衡中间件，比如aws（elb）、阿里云（slb）。这个负载均衡软件可以认为是 lvs+keepalived的高可用负载均衡服务

后端的service有可能部署在硬件条件不同的服务器上：

1）如果对标最低配的服务器“均匀”分摊负载，高配的服务器的利用率不足；

2）如果对标最高配的服务器“均匀”分摊负载，低配的服务器可能会扛不住；

（1）通过“静态权重”标识service的处理能力

优点： 简单，能够快速的实现异构服务器的负载均衡。

缺点： 权重是固定的，无法自适应动态调整，而很多时候，服务器的处理能力是很难用一个固定的数值量化。

（2）通过“动态权重”标识service的处理能力

提问：通过什么来标识一个service的处理能力呢？

回答：其实一个service能不能处理得过来，能不能响应得过来，应该由调用方说了算。调用服务，快速处理了，处理能力跟得上；调用服务，处理超时了，处理能力很有可能跟不上了。

动态权重设计：

例如：

（1）设置一个阈值，超过阈值直接丢弃

（2）借助“动态权重”来实施过载保护

案例策略：

1）service的负载均衡、故障转移、超时处理通常是RPC-client连接池层面来实施的

2）异构服务器负载均衡，最简单的方式是静态权重法，缺点是无法自适应动态调整

3）动态权重法，可以动态的根据service的处理能力来分配负载，需要有连接池层面的微小改动

4）过载保护，是在负载过高时，service为了保护自己，保证一定处理能力的一种自救方法

5）动态权重法，还可以用做service的过载保护

负载均衡：F5，Haproxy，lvs, nginx

阅读本文前，需熟悉OSI七层参考模型。

常见的负载均衡设备，有F5，Haproxy，lvs, nginx等。

F5是商用硬件负载均衡，性能很好，但是价格昂贵，除了负载均衡，还有应用交换、会话交换、状态监控等众多功能。

F5一般做四层负载均衡，但也支持七层负载均衡。

Haproxy(以下简称ha)是软件负载均衡，开源，一般做七层负载均衡，但也支持四层负载均衡。

Linux Virtual Server(以下简称lvs)是软件负载均衡，开源，二层或四层负载均衡，已集成到linux内核，自身有完备的热备方案（keepalived+lvs），稳定性极强。

nginx也是软件负载均衡，开源，通过反向代理实现负载均衡，是七层负载均衡，性能不如上面的几个。

tips1

有些公司，测试环境用ha/lvs/nginx，生产环境用F5。

tips2

nginx做web服务器时，一般做静态资源服务器和php的web服务器，所以很多公司，会采用F5+nginx或者ha+nginx的架构

tips3

微服务中的ribbon属于客户端负载均衡，上面的几种都是服务端负载均衡

二层负载均衡

在数据链路层通过修改mac地址实现，如lvs的DR模式（直接路由模式）

三层负载均衡

在网络层通过DNAT协议修改目标地址实现

四层负载均衡

用ip+端口实现请求转发

备注：tcp报文里并没有ip，但是四层负载均衡可以用ip+端口，是因为server可以拿到ip

七层负载均衡

通过重新发起http请求实现，即client把请求发给lb，lb把请求代发给server，再把server的响应返回给client，因此七层负载均衡也经常被称为代理，七层负载均衡设备也被称为代理设备。

七层负载均衡常用于内网与外网的通信，比如内网无法直接访问外网，需要通过代理设备代发http请求，这种情况下，代理设备需要配置双网卡，以同时与内外网络通信。

由于需要重发http请求，七层负载均衡性能较差，但是更智能和安全，因为应用层可以获取甚至修改请求的真实内容（即应用数据），比如cookie、url等，可以做一些智能的操作，比如根据cookie/url转发请求，也可以做一些安全操作，比如过滤特定报文、防止SYN Flood攻击等。

使用七层负载均衡时，服务的性能受限于代理设备的网卡带宽。

常见的负载均衡策略，有轮询、加权轮询、ip_hash、cookie、url_hash，根据服务器响应时间转发、根据最少连接转发等等。

备注：nginx可以安装第三方插件，使用第三方实现的策略

轮询：按服务器列表顺序转发请求，轮询是nginx默认的策略，本策略适合服务器配置相当、请求无状态（即不依赖session）的场景

加权轮询：如果不同服务器配置不同，可以为配置高的服务器增加权重

ip_hash：根据ip哈希结果转发，可以实现同一用户持续请求同一服务器（即会话保持），适合有状态（即依赖session）的场景，对png、jpg、js、css等静态资源的请求，不适合使用本策略

cookie：根据特定cookie转发请求，一般也是用于实现会话保持，比如为服务器A、B分别增加service-flag=a、service-flag=b的cookie，后续请求根据cookie转发

可以参考 haproxy实现会话保持

url_hash：根据url哈希结果转发，同一个接口始终请求同一台服务器，一般配合缓存使用，缓存接口返回结果

根据服务器响应时间转发：优先转发到响应时间较快的服务器

根据最少连接转发：优先转发到连接数较少的服务器

F5有一些特有的负载均衡策略：利用从应用程序和服务器收集到的各项性能指标，分析并转发

负载均衡有两个步骤：

1.根据什么算法选择真实服务端，即负载均衡策略，如轮询、加权轮询、ip_hash、cookie、url_hash等；

2.把请求转发到真实服务器，转发方式有二层到七层负载均衡

keepalived软件一开始是专为lvs设计的，后来加入了可以实现高可用的VRRP (Virtual Router Redundancy Protocol ,虚拟路由器冗余协议）功能，因此，keepalived还可以作为nginx、haproxy、mysql等服务的高可用解决方案。

以nginx为例，为了防止nginx本身由于宕机等原因导致网站不可用，一般会搭两套nginx反向代理，用keepalived提供一个VIP。

一般情况下，VIP只在nginx主节点上工作，如果nginx主节点不可用了，VIP会自动漂移到从节点，自动漂移的原理即VRRP协议。

VIP漂移到从节点后，如果主节点恢复正常了，VIP是否漂移回主节点，取决于当前模式是抢占模式还是非抢占模式。

下图是一张简单的架构图，解释如下：

以上观点纯属个人意见，如果错误，欢迎指出，有些地方写的很简单，是因为我也不懂~

Keepalived工作原理

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

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广播包,告诉备它还活着，此时备不会抢占主，当主不可用时，即备监听不到主发送的广播包时，就会启动相关服务接管资源，保证业务的连续性.接管速度最快

出现脑裂的原因：

高可用服务器对之间心跳线链路发生故障，导致无法正常通信。

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

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

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

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

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

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

其他服务配置不当等原因，如心跳方式不同，心跳广插冲突、软件Bug等。

如何解决脑裂：

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

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

③?做好对裂脑的监控报警（如邮件及手机短信等或值班）.在问题发生时人为第一时间介入仲裁，降低损失。管理员可以通过手机回复对应数字或简单的字符串操作返回给服务器.让服务器根据指令自动处理相应故障这样解决故障的时间更短。

一、实验环境

操作系统：CentOS7.2 Minial

###################

serverA：

eno16777736 ? ?192.168.1.104

eno33554984 ? ?192.168.1.105

##########################

serverB：

eno16777736 ? ?192.168.1.109

eno33554984 ? ?192.168.1.106

###########################

vip01:192.168.1.111

vip02：192.168.1.112

二、设置防火墙

/usr/bin/firewall-cmd --direct

--permanent --add-rule ipv4 filter INPUT 0 --in-interface eth0 --destination ${组播地址} --protocol vrrp -jACCEPT

/usr/bin/firewall-cmd --reload

三、软件安装

在serverA和serverB上

# rpm -ivh --force libnl3-3.2.28-4.el7.x86_64.rpm

# rpm -ivh --forcelm_sensors-libs-3.4.0-4.20160601gitf9185e5.el7.x86_64.rpm

# rpm -ivh --force net-snmp-agent-libs-5.7.2-32.el7.x86_64.rpm

# rpm -ivh --force net-snmp-libs-5.7.2-32.el7.x86_64.rpm

# rpm -ivh --force ipset-libs-6.38-3.el7_6.x86_64.rpm

# rpm -ivh --force keepalived-1.3.5-6.el7.x86_64.rpm

四、配置keepalived

如果不使用 VRRP Sync Groups 如果keepalived 主机有两个网段，每个网段开启一个VRRP 实例，如果对外的网段出现问题，VRRPD认为自己仍然认为健康，因此 Master和Backup 相互切换，从而导致服务不能正常使用，同时高可用集群也不能正常运行，Sync group 就是为了解决该问题，可以把两个实例放进同一个Sync Group 中！

serverA

# vim /etc/keepalived/keepalived.conf

######################################

! Configuration File for keepalived

global_defs {

router_id LVS_DEVEL

}

vrrp_sync_group VG1 {

group {

VI_1

VI_2

}

}

vrrp_instance VI_1 {

state BACKUP

interface eno16777736

virtual_router_id 51

priority 100

nopreempt

advert_int 1

authentication {

auth_type PASS

auth_pass 1111

}

track_interface {

eno16777736

eno33554984

}

virtual_ipaddress {

192.168.1.111

}

}

vrrp_instance VI_2 {

state BACKUP

interface eno33554984

virtual_router_id 52

priority 100

nopreempt

advert_int 1

authentication {

auth_type PASS

auth_pass 2222

}

track_interface {

eno16777736

eno33554984

}

virtual_ipaddress {

192.168.1.112

}

}

serverB

# vim /etc/keepalived/keepalived.conf

######################################

! Configuration File for keepalived

global_defs {

router_id LVS_DEVEL

}

vrrp_sync_group VG1 {

group {

VI_1

VI_2

}

}

vrrp_instance VI_1 {

state BACKUP

interface eno16777736

virtual_router_id 51

priority 90

nopreempt

advert_int 1

authentication {

auth_type PASS

auth_pass 1111

}

track_interface {

eno16777736

eno33554984

}

virtual_ipaddress {

192.168.1.111

}

}

vrrp_instance VI_2 {

state BACKUP

interface eno33554984

virtual_router_id 52

priority 90

nopreempt

advert_int 1

authentication {

auth_type PASS

auth_pass 2222

}

track_interface {

eno16777736

eno33554984

}

virtual_ipaddress {

192.168.1.112

}

}

五、测试

在serverA 和 serverB上

# systemclt start ?keepalived

在serverA

Keepalived详解

一、Keepalived介绍

Keepalived是一款由C编写的软件，一般解决负载均衡器的高可用性问题，提供了负载均衡、健康检查和高可用的功能，高可用功能是由VRRP协议来实现的。

二、软件设计

Keepalived启动后由3个进程组成。

三、Keepalived安装

在Red Hat 系服务器上安装

在Debian系服务器上安装

四、keepalived配置

vrrp_script段配置

real_server段配置

tcp_check段配置

五、实际案例：主主配置

两台互为主主同时可提供服务，一台服务宕掉后另一台可接管