双机热备的原理

转自：码农翻身（微信号：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服务器， 可是平时只用一个，另一个一直空闲，是否是极大的浪费啊？”

怎么办？张大胖挠了挠头，犯难了。