双机热备原理(转)

文章来自刘欣老师「码农翻身」公众号

上一篇介绍负载均衡的2种实现方式:NAT、DR,这一篇介绍负载均衡器的可用性,使用互为主备的方式既可以提高处理效率和机器利用率,又可以避免一台负载均衡器挂掉的影响。


夜半惊魂

上次讲到,张大胖在Bill的指导下,成功地开发了一个四层的负载均衡软件, 把流量“均匀地”分发到了后面的几个服务器中, 获得了老板的1000块钱奖励。

但是张大胖心中隐隐不安,总觉得系统埋着一颗定时炸弹,随时会引爆,这个炸弹就是: Load Balancer 只有一台服务器,万一这个服务器挂掉了怎么办?

没有了Load Balancer这个入口,用户的请求无法分发过来,后面的这些服务器只能干瞪眼了。

系统有“单点失败(Single Point of Failure)”的风险就是这个意思。

有一天晚上张大胖做了一个梦,梦见这个Load Balancer在高峰期挂掉了,导致整个系统瘫痪,看到损失了无数的订单, 愤怒的老板不停地向他咆哮:扣你小子半年工资。

吓得张大胖半夜醒来,出了一身冷汗。

不想单点失败该怎么办? 张大胖稍微思索下就能想到解决方案: 上两台Load Balancer !

可问题是:客户端究竟要访问哪一个?

还用DNS轮询的方式? 那就回到最原始的问题了。

在这两个Load Balancer之前再加一个Load Balancer? 那岂不又是单点失败?

不,这个路子是走不通的。

张大胖准备另辟蹊径。

在客户端看来,这两个Load Balancer 最好是一个整体,就像一个虚拟的服务器, 这个虚拟的服务对外提供一个IP (简称VIP)。

两个Load Balancer中,一个叫做Master, 另外一个可以叫做Backup , 平时Master 负责干活, Backup待命,一旦Master挂掉, Backup 服务器立刻接管。 在外界看来,那个虚拟的服务器还在工作,并不知道内部发生的“大地震”。

想到这里,张大胖激动起来,竟然睡不着了, 干脆爬起来看邮件,写代码。

详细设计

第二天,张大胖七点就来到了公司,想着把昨晚的方案给Bill 汇报下。

可是他来得太早了,公司空无一人。 罢了,很多细节还没有完善,先不着急。

首先是这个虚拟的VIP , 怎么才能实现在两个服务器之间的“IP漂移”呢?

张大胖曾经记得,一个网卡可以设置多个地址,比如在Linux上eth0表示网卡1,它可以绑定一个IP, 与此同时,还可以设置一个ip alias 或者 secondary ip 。

eth0 –> 192.168.1.10

eth0:1 –> 192.168.1.100

张大胖想: 我可以让这个192.168.1.100为VIP,如果服务器是Master, 就可以把这个IP给绑定上, 如果是Backup,那就不绑定。

换句话说,通过动态地绑定/解绑 就可以让这个VIP在两个服务器之间来回“漂移”了。

“IP漂移”的问题可以这么解决, 但是那个Backup 怎么知道Master 挂掉了呢?

从道理上说,很简单,只需要让Master不断地给Backup发“心跳”消息即可(可以采用广播的方式发消息), 这个Backup(LoadBalancer2)得有个定时器, 如果在一个特定的时间(嗯,这个时间应该可以设置)内收不到心跳,那就认为Master完蛋了,就需要挺身而出,擦干眼泪,继承前任的遗志,很Happy地绑定VIP , 继续伟大的革命事业。

可是那个之前的Master(LoadBalancer1)如果又活了呢?

LoadBalancer2 该怎么办?革命的康庄大道还没走几步, 就要拱手让出还没捂热乎的VIP吗?

如果LoadBalancer1是个性能更加强悍的机器,同志们肯定希望由他来统领全局。

这里得定义一个策略,每个机器都得有个优先级(一个整数),在允许抢占的情况下,谁的优先级高,谁就是Master!

张大胖想到: 看来需要我开发一个软件了,实现这些通信“协议”和策略, 这个软件需要安装运行在每个Load Balancer上,让他们组成单个虚拟的Load Balancer, 对外提供服务。

在每个Load Balancer中,状态转换是这样的, 张大胖画了一张图:

汇报工作

到了9点钟, CTO Bill 准时上班, 张大胖赶忙跑去向领导汇报昨晚和今早的思想动态。

Bill 听完,沉吟片刻,说道:“这个主意不错,我支持! 可是。。。。。。”

张大胖立刻紧张起来, 自己想得挺完善的啊,难道还有问题?

只听Bill 说道:“你可以让那个IP地址在两个主机之间漂移,实现主备切换, 但是MAC地址怎么办? ”

张大胖说:“MAC地址 ? 关MAC地址什么事? ”

啊 ! 他突然明白了,确实是忽略了, IP包是被封装在以太网帧中发送的,其中需要MAC地址。

在发送第一个请求的时候,客户端(确切说是直接向Load Balancer发数据的那个机器)先是知道了VIP(如:192.168.1.100), 接下来它需要知道这个VIP的MAC地址,这样才能发送数据。

为了拿到MAC地址,它需要发起ARP查询: 这个VIP(192.168.1.100)的 MAC的地址是什么?

如果Load Balancer 1是Master ,就会回复: 是23:39:8D:9C:0A:33 (记为 MAC1)

这时候客户端就会缓存,记下来。

然后Load Balancer 1 挂掉, Load Balancer 2 成为 Master。

此时客户端如果再次发送数据,还会往MAC1去放送,于是就出错了。

想通了这一层, 张大胖犯了愁, 这可怎么办?

Bill 提醒道:“你不是有个虚拟的IP地址吗? 是不是也可以搞一个虚拟的MAC地址啊!”

张大胖如梦方醒: “对对, 无论是哪个机器成为Master, 每次响应ARP请求的时候,都返回这个虚拟的MAC地址。这样客户端面对的MAC地址就唯一了。”

看来虚拟IP + 虚拟的MAC 地址才能完整地解决问题!

申请机器

张大胖把软件开发出来了,小心翼翼地向抠门的老板去申请机器,老板看了方案,提了一个让张大胖大跌眼镜的问题: “你这里整了两个Load Balancer服务器, 但是平时只用一个,另外一个一直空闲,是不是极大的浪费啊?”

怎么办?张大胖挠了挠头,犯难了。

答:可以使用keepalived,两台Load balancer都作为master,分别为不同的业务做负载均衡,并且同时设置为对方的slave。

欢迎扫描下方二维码,关注我的个人微信公众号,分享我的工作、学习和生活 ~


情情说