雙機熱備的原理

轉自：碼農翻身（微信號：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服務器， 可是平時只用一個，另一個一直空閒，是否是極大的浪費啊？」

怎麼辦？張大胖撓了撓頭，犯難了。