最近在做mysql的高可用集羣時，採用了heartbeat + drbd 來實現。在做災難測試時發現兩個問題：
1、發現當禁用網卡連接，模擬網卡失效時，主/備服務器不能實現正常的故障轉移。後查資料發現，原來heartbeat 的故障切換只能在主服務器宕機或heartbeat 服務關閉的情況下，才能實現故障的正常切換。不能實現對網卡狀態的監控。其實這個問題可以通過 heartbeat 中的 ipfail 功能來實現。原本我認爲ipfail功能是一個可有可無的功能，有的話，對系統加多一層保障，沒有的話，也不會產生影響。但經過這一次，我發現我錯了，ipfail功能還是很有用的，它並不是虛設的，它是真正實用的工具。ipfail 可以實現對網絡狀態的監控，當 ipfail 的機制發現所監控的網絡沒有網絡連接時，將會觸發一個主/備故障轉移操作。在做 ipfail 操作時，注意一點就是 ipfail 只能用於監控公網接口，不能與內部的心跳接口放在一起監聽，如果在同一個接口的話，會導致 ipfail 工作失效。這或許是爲什麼很多朋友在網上說，ipfail不能正常工作的原因吧。網上有些朋友說，ipfail 已經過時，不能用啦。我個人覺得，這是理解錯誤，如果ipfail功能失效，那爲什麼在heartbeat安裝後，還會有這個工具呢？ipfail 在Heartbeat的CRM模式下據說會與CRM有衝突，這個沒有測試過，不敢發表意見。
2、當主/備之間的心跳線斷開網絡連接時，不能進行故障的切換。這個原本按着我對集羣的理解是，當主/備之間的心跳斷開連接時，就會產生一次主/備故障切換的過程。但經過這次實際的測試，發現事實並非如此，事實是當主/備之間的心跳斷開連接時，此時主/備都會將自己作爲主服務器，此時兩臺服務器都會擁有集羣資源，這時，也就是發生了大家常說的“裂腦”現象。在紅帽的 RHCS 中有一種專門用來解決這種“裂腦”現象的機制叫 Fence 。RHCS通過使用一種專業的 Fence 設備來對集羣進行心跳監聽，Fence 設備會不斷對集羣中的主服務器進行主跳監聽，當發現集羣中的主服務器沒有心跳時，Fence 設備會向主服務器發送一個強制關機的信號，將失去網絡連接的主服務器關機，以實現網絡中只會有一臺服務器擁有集羣的資源。我現在終於明白，爲什麼我當初在學習RHCS的時候，有一位牛人說，如果RHCS中沒有使用Fence 機制，RHCS 是不完美的，無法稱爲真正意義上的集羣。現在我終於明白啦。Heartbeat 中沒有這種機制，也許 Heartbeat 的CRM 模式會有，但CRM的配置太複雜了一點，而且至今沒有發現有這方面的成功案例。但我想 CRM模式只是實現資源的監控，但對於這種裂腦現象，卻不一定有效。目前解決這種問題的方法，我認爲行之有效，而又直接便利的方法：是使用 bonded 技術，將兩塊網卡綁定起來，實現網卡冗餘。這樣當兩臺服務器的其中一塊網卡出現故障時，不會影響到服務器之間的心跳監測。
收穫：
1、對 Heartbeat 的故障切換與Heartbeat 的 ipfail 使用有一個更清晰的瞭解。
2、對於集羣中的“裂腦”現象，認識更深刻啦。
3、終於認清了半知半懂的 Fence 機制啦。
YEAH！