keepalived 都是backup模式

转载

mob6454cc647bdb 2024-09-12 14:05:05

KeepAlived,keepalive,keep-alive--简析

解释下标题

概述
KeepAlived VRRP协议
keepalive--一个与TCP有关的概念
keep-alive--一个HTTP协议中的概念

解释下标题

大家好，可能大家在搜索keepalived的时候无意中闯入或者就是专门来搜索相关内容的，可能会有一部分对标题有些疑问，为什么这三个差不多词会同时出现？这里对标题做个说明，本文不是介绍keepalived使用的（后面会写）而是介绍三者区别的。

概述

keepalived：keepalived其实是一种高可用的解决方案，依赖vrrp协议，是一个工作在网络3、4、5层的软件；
keepalive：比软件少了一个d，这是与tcp相关的；
keep-alive:比tcp的参数多了一个-，这是与http的相关的；
本文对软件keepalived不再详细描述使用方法仅介绍原理。详细使用和使用中的问题我在后面会另写一篇进行介绍。

KeepAlived VRRP协议

keepalived基于vrrp协议实现，vrrp（Virtual Router Redundancy Protocol）即虚拟路由冗余协议，还有个更通俗一些的名字叫备份路由协议。一般情况下一个局域网中的主机都会有一个默认的路由，当局域网中主机访问不在同一网段的外部网络时需要通过默认路由，而这个默认路由一旦down掉，局域网内的主机就不能与外部网络通信了，vrrp解决了上面的由于单一路由引起的问题，是一种容错协议。VRRP通过将一组路由器（一般会从这组路由器组中选举一台作为主路由器，其余为backup路由器）组成一个虚拟路由器（生成一个虚拟ip即vip），这组路由器称之为备份组。VRRP的工作过程如下：
1.备份组在启用时会选举优先级高的路由节点作为主路由，优先级低的作为备用路由。
2.主路由会发送VRRP通告报文给备用节点，报告自己是活着的，备份路由器会开启定时器接收通告报文。VRRP发送通告报文一般是通过组播模式进行，组播ip一般为224.0.0.18。
3.关于主备节点的切换有两种模式
抢占模式和非抢占模式。
抢占模式下，依据什么抢占，依据权重。主备通过比对权重确定路由组内的主备角色。
非抢占模式，就是不看权重，指定你是什么就是什么，即便备用节点的权重比主节点高。

以上就是VRRP的大致一个原理，keepalived的工作方式跟VRRP协议是一样的，而这种模式正好可以作为一个高可用的解决方案，但是主备却触动着企业的神经，比如说有两台机器，一主一备，那备用的岂不浪费，为了不让备用浪费，一般的做法是两台机器设置两组路由组，比如说A、B路由组，但是都在这两台机器上，基本情况如下：

keepalived 都是backup模式_服务端

这样就不存在备用节点闲置的问题，但是具体情况具体分析，有的即便有两组那也只能用其中一个。

高可用的主要方案还是通过keepalived的监测脚本监测需要保持高可用的应用进程，一般如果监测到应用进程没有尝试拉起应用，拉不起来就降低自己的权重或者直接干掉自己本身，以便及时切换到备用节点。

那本文标题的其他两个keepalive和keep-alive这俩是咋回事呢？下面我们简单介绍下。

keepalive–一个与TCP有关的概念

keepalive是一个概念，其实就是说了这么一个场景，小S这小伙子喜欢小C，俩人聊的好好的，你一句我一句，小S挺兴奋，就跟小C表白了，结果半天没得到回复，这时候小C就很焦急，于是采用了keepalive这么一种机制，再发几句试一下，如果小C还不回，小S就决定断绝来往另寻下家。其实就是客户端在跟服务端建立完连接后一直没再有下一步的动作，服务端采用的一种探测客户端是否正常的机制。大家应该清楚，服务器的连接是宝贵的，你一直占着不释放也太浪费了，不能占着茅坑不拉屎不是，所以就有了keepalive这么一种机制，它可以监测无用的长连接，释放系统资源。它不是TCP/IP协议规范的一部分，但是基本所有TCP/IP协议栈都实现了keepalive功能，比如linux和windows。
它有三个主要的参数：
1，tcp_keepalive_time：一般为两小时，如果连接空闲了俩小时，服务端（其实tcp没有客户端服务端一说，只是为了描述）会向客户端发送ACK，如果客户端端能正常返回ACK，那服务端就在等下一个两小时。
2，tcp_keepalive_intvl：检测的间隔75秒，如果空闲两小时，且客户端心跳后75秒仍未收到服务端返回，则发送另一次心跳。
3，tcp_keepalive_probes：连续无响应检测的最大次数，超过这个次数认为该链接无效关闭连接。
其实以服务端为例，服务端启动计时器来检查连接时间，这个时间为2小时，如果到2小时，那么发送ACK，此时客户端无非有下面几种情况
1，正常返回ACK，服务端重置计时器，等待下一个两小时。
2，客户端宕机，服务端在超时75s后发送第二次ACK，直至9次，连接关闭。
3，客户端当即后重启，服务端在重试到第7次的时候收到了客户端的响应，但是该响应为一个复位，服务端仍会关闭连接。
可能有些同学会说，这玩意在服务器上感觉没生效一样，确实，它默认是关闭的，但是可以通过上层应用开启。