双机热备的原理
轉載自?雙機熱備的原理
夜半驚魂
上次的文章《負載均衡的原理》中講到，張大胖在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地址就唯一了?！?/p>
看來虛擬IP + 虛擬的MAC 地址才能完整地解決問題！
申請機器
張大胖把軟件開發出來了，小心翼翼地向摳門的老板去申請機器，老板看了方案，提了一個讓張大胖大跌眼鏡的問題： “你這里整了兩個Load Balancer服務器， 但是平時只用一個，另外一個一直空閑，是不是極大的浪費啊？”
怎么辦？張大胖撓了撓頭，犯難了。
總結
- 上一篇： 防止鸟撞玻璃，腾讯宣布为深圳滨海大厦总部
- 下一篇： Linux下如何避免误操作执行 rm