保證持續穩定的系統運行時間變得越來越重要，而傳統意義上的小型機系統讓普通用戶望而卻步。用戶需要的是更高的可用性以及更低的成本。高可用性（HA）技術能自動檢測服務器節點和服務進程錯誤、失效，並且當發生這種情況時能夠自動適當地重新配置系統，使得集群中的其他節點能夠自動承擔這些服務，以實現服務不中斷。
Cluster應用可分為三方面：High-Availability（HA）（高可用性集群）、Load Balance（負載均衡集群）、Scientific（科學集群）。在集群的這三種基本類型之間，經常會發生混合與交雜。於是，可以發現高可用性集群也可以在其節點之間均衡用戶負載，同時仍試圖維持高可用性程度。同樣，可以從要編入應用程序的集群中找到一個並行群集，它可以在節點之間執行負載均衡。而本文則側重於介紹基於Linux的HA解決方案方面的問題。
基於LVS的HA方案
Linux要進入高端市場就必須在這方面有相應的措施，所以許多公司都在這方面加大了研究力度。現在，我們可以使用一些現存的軟件去構築具有高可用性的LVS系統。下面列出兩種方案，以供參考。
［方案一］mon+heartbeat+ fake+coda
我們可以使用“mon”、“heart beat”、“fake”和“coda”四個軟件來構築具有高可用性的Virtual Server（虛擬服務器）。“mon”是一個大眾化的資源管理系統，用來監控網絡上的服務器節點和網絡服務。“heartbeat”實現在兩台計算機間通過在串行線上使用UDP協議傳送“心跳信息”。“Fake”是一個使用ARP欺騙的方法來實現IP接管。
當服務器故障時，處理過程如下：“mon”進程運行在負載均衡器上，負責監測整個集群的服務器節點和服務進程。在配置文件“fping.monitor”中寫入要檢測服務器節點，然後“mon”進程將會隔t秒檢查一下相應的服務器節點是否還活著。
另外相關的服務監視器也要做相應的配置，這樣“mon”進程將每m秒檢測一下所有節點的相應服務進程。例如：http.monitor：用於配置監控http服務；ftp.monitor：用於配置監控ftp服務；以此類推。當配置完成後，某個服務器節點失效或重新生效、服務進程失效或重新生效時都會發送一個通告信息，因此，負載均衡器能夠知道服務器節點是否能接受服務。
現在，負載均衡器成為了整個系統的單點失效。為了防止這一現象，我們必須安裝一個負載均衡器的備份服務器。“fake”軟件實現當負載均衡器失效時，備份服務器自動接管IP地址，並繼續服務。而“heartbeat”則隨時根據負載均衡器的狀態自動激活/關閉備份服務器上的“fake”進程。在負載均衡器和備份服務器上都運行著一個“heartbeat”進程，它們通過串行線周期性地發送“I'm alive ”消息。如果備份服務器在一個預定時間內接收不到來自負載均衡器的“I'm alive”信息時，將自動激活“fake”進程接管負載均衡器的IP地址，並開始提供負載均衡服務；而當再次收到來自負載均衡器的“I'm alive ”消息時，備份服務器將自動將“fake”進程關閉，釋放出它接管的服務器，負載均衡器重新開始工作。
但是，如果負載均衡器在客戶正在請求時失效，這時會引起客戶請求失敗，客戶必須重新發出請求信息。
“coda”是一個容錯的分布式文件系統，源於Andrew文件系統。服務器上的目錄能夠存儲在“coda”上，所以文件能夠實現高可用性，並且易於管理。
［方案二］ldirectord+heartbeat
“ldirectord”（Linux Director Daemon）是Jacob Rief編程實現的一個獨立進程，以實現對服務和物理服務器的監測，廣泛地用於http和https服務。
“ldirectord”安裝簡單，能很好地與“heartbeat”配合工作。“ldirectord”程序包含在“ipvs”包中的“contrib”目錄中。
以下是“ldirectord”的一些優點：
“ldirectord”是專門撰寫的LVS監測程序。
它從/etc/ha.d/xxx.cf文件中讀取所有關於IPVS路由表的配置信息。當“ldirectord”運行起來後，IPVS路由表將會被適當地配置。
可以將Virtual service配置放在多個配置文件中，所以可以單獨修改某一種服務的參數，而不影響其他的服務。“ldirectord”能被“heartbeat”輕松地管理----啟動、關閉。
將“ldirectord”放到/etc/ha.d/resource.d/目錄下，然後在/etc/ha.d/haresources中增加一行：
node1 IPaddr::10.0.0.3
ldirectord::www ldirectord::mail
“ldirectord”能夠手動開啟、關閉。可以在無備份負載均衡器的LVS集群中使用它。
Xlinux的LATCH HA方案
正如前面所述，高可用性解決方案（HA）是極為重要的，許多廠商為此投入了大量的研究。其中，Xlinux發行版就提供LATCH HA解決方案。下面我們就一起看看LATCH HA方案。
LATCH HA解決方案的最典型的系統結構：兩台主機A、B共享一個磁盤陣列，A為工作機，B為備份機。它們之間用一根心跳線來連接，這稱為“心跳檢測”，主要通過一條RS232檢測鏈路來完成。LATCH HA也采用了用Ping來驗證系統宕機的方法。安裝在主機上的HA軟件通過心跳線來實時監測對方的運行狀態，一旦正在工作的主機A因為各種硬件故障導致系統發生故障，主機B立即投入工作。怎麼樣，與IBM的HACMP有點像吧！
LATCH HA實現了“高可靠性共享存儲”架構。該架構由兩個或三個冗余服務器、一個共享冗余磁盤陣列、一個可選DBMS及LATCH HA系統軟件構成。在LATCH HA的保護下，企業的計算機系統能夠提供不間斷的信息服務，避免由於硬件故障或日常維護所帶來的宕機，因而能夠保障最佳的可靠性及最大程度地減少宕機時間。
方案應用
LATCH HA能夠應用在各種集中式、客戶機/服務器模式或OLTP系統中。同時其與市場上各種主流的數據庫系統與OLTP軟件（如：Oracle、SYBASE、Informix、Tuxedo）也都保持兼容。LATCH HA同時提供了各種應用程序接口。因此，客戶能夠在其私有軟件中集成各種功能來保證系統的高可靠性。
LATCH HA /HS2000 在線待機模式
在這種模式下，一個服務器作為主服務器。正常情況下其承當所有的服務。另外一台服務器作為待機服務器（正常情況下除了監控主服務器的狀態，不進行其他的操作）。一旦主服務器宕機，待機服務器就接手工作，成為新的主服務器。客戶仍然可以擁有同樣的服務器IP地址、NFS、數據、數據庫及其他……這種應用模式近似於上面介紹的典型應用模式（兩台服務器實際上是在完成同一個功能應用），安裝在主機上的HA軟件通過心跳線來實時監測對方的運行狀態，一旦正在工作的主機A因為各種硬件故障，如電源失效、主要部件失效或者啟動盤失效等導致系統發生故障,主機B立即投入工作。
LATCH HA /DA2000雙機就緒模式
在這種模式下，兩個主機都作為主服務器，共享自己的磁盤陣列，各自承當一部分服務。例如：服務器A在執行應用A, 服務器B在執行應用B, 兩個主機在正常情況下各自獨立運行自己的應用邏輯，兩個主機同時又都作為對方的待機服務器，通過心跳線監控對方的狀態。一旦某一服務器宕機，另一台服務器就承擔所有的服務，為所有的客戶服務。一旦服務器A發生故障，服務器B馬上接管服務器A上原來的應用；或者服務器B發生故障，服務器A馬上接管服務器B上原來的應用，這是一種互為冗余的模式。
很明顯，一旦某一服務器宕機，另一台服務器的工作負擔就比較重，於是就有了三主機模式。
LATCH HA /HC2000 三主機模式
這種應用模式是最高端的HA應用模式，它既保證了系統的設備冗余，避免系統宕機，而且又能保證在一旦宕機的情況下有足夠的系統資源可供使用。
在這種模式中，待機服務器C同時監控主服務器A與B的狀態。一旦服務器A或B宕機，服務器C將承擔其服務，為客戶服務。這種系統結構既保證了系統的安全運行，又保證了系統資源。
Linux HA的解決方案當然不限於上述兩種，但其核心思想是一致的，即提供不間斷的服務。近年來隨著Linux操作系統不斷走向成熟，功能不斷增強，特別是其遵循GPL和標准化的PVM、MPI消息傳遞機制的特性和在普通PC機上越來越好的高性能網絡的支持，所有這些為基於Linux的集群系統的發展提供了堅實的技術基礎，在把技術轉化為具體的應用過程中，高端的HA應用以其穩定可靠的性能和與Unix相比價格上的優勢而脫穎而出。隨著基於Intel平台的服務器業已成為關鍵性業務和應用的主流服務器，Linux HA集群技術的應用亦將日益廣泛。
HA集群結構圖
HA實際上是兩台（或更多）計算機通過一定方式互相監聽，實現熱備份。當其中Primary server出現問題時，Standby server能夠自動立即接替工作，使用戶感覺不到停機。在Primary server恢復正常之後，Standby server又會把工作還給Primary server。
