双机热备的原理

33次阅读

共计 2406 个字符,预计需要花费 7 分钟才能阅读完成。

转自:码农翻身(微信号:coderising)

夜半惊魂

上次的文章《负载均衡的原理》中讲到,张大胖在 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 服务器,但是平时只用一个,另外一个一直空闲,是不是极大的浪费啊?”

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

正文完
 0