此文凝聚筆者不少心血請尊重筆者勞動，轉載請注明出處。http://freeze.blog.51cto.com/
随着Internet技術的迅猛發展，網絡技術、性能的不斷提高，高可伸縮性、高可用性、可管理性、價格有效性的網絡服務技術将成為網絡服務技術的主導。各種平台下的技術方案應運而生。本文試圖以一篇完整的理論+實踐性的文字來介紹如何在優秀的開源作業系統Linux下建立低成本、高性能、高可用的服務叢集系統（也叫叢集系統），希望通過筆者努力，讓您對叢集有一定的了解。
叢集的起源：叢集并不是一個全新的概念，其實早在七十年代計算機廠商和研究機構就開始了對叢集系統的研究和開發。由于主要用于科學工程計算，是以這些系統并不為大家所熟知。直到Linux叢集的出現，叢集的概念才得以廣為傳播。對叢集的研究起源于叢集系統的良好的性能可擴充性(scalability)。提高CPU主頻和總線帶寬是最初提供計算機性能的主要手段。但是這一手段對系統性能的提供是有限的。接着人們通過增加CPU個數和記憶體容量來提高性能，于是出現了向量機，對稱多處理機(SMP)等。但是當CPU的個數超過某一門檻值，象SMP這些多處理機系統的可擴充性就變的極差。主要瓶頸在于CPU通路記憶體的帶寬并不能随着CPU個數的增加而有效增長。與SMP相反，叢集系統的性能随着CPU個數的增加幾乎是線性變化的。幾種計算機系統的可擴充性:
- 高可擴充性：如上所述。
- 高可用性：叢集中的一個節點失效，它的任務可以傳遞給其他節點。可以有效防止單點失效。
- 高性能：負載平衡叢集允許系統同時接入更多的使用者。
- 高成本效益：可以采用廉價的符合工業标準的硬體構造高性能的系統。
| 叢集類型 ： 最常見的三種叢集類型包括： 負載均衡叢集： LB: load balancing 高可用性叢集： HA：High Availability 高性能也叫科學叢集：HP : High Performance
負載均衡叢集 (LB:load balancing) 負載均衡叢集為企業需求提供了更實用的系統。如名稱所暗示的，該系統使負載可以在計算機叢集中盡可能平均地分攤處理。該負載可能是需要均衡的應用程式處理負載或網絡流量負載。這樣的系統非常适合于運作同一組應用程式的大量使用者。每個節點都可以處理一部分負載，并且可以在節點之間動态配置設定負載，以實作平衡。對于網絡流量也是如此。通常，網絡伺服器應用程式接受了太多入網流量，以緻無法迅速處理，這就需要将流量發送給在其它節點上運作的網絡伺服器應用。還可以根據每個節點上不同的可用資源或網絡的特殊環境來進行優化。
高可用性叢集 (HA:High Availability) 高可用性叢集的出現是為了使叢集的整體服務盡可能可用，以便考慮計算硬體和軟體的易錯性。如果高可用性叢集中的主節點發生了故障，那麼這段時間内将由次節點代替它。次節點通常是主節點的鏡像，是以當它代替主節點時，它可以完全接管其身份，并且是以使系統環境對于使用者是一緻的。 在叢集的這三種基本類型之間，經常會發生混合與交雜。于是，可以發現高可用性叢集也可以在其節點之間均衡使用者負載，同時仍試圖維持高可用性程度。同樣，可以從要編入應用程式的叢集中找到一個并行叢集，它可以在節點之間執行負載均衡。盡管叢集系統本身獨立于它在使用的軟體或硬體，但要有效運作系統時，硬體連接配接将起關鍵作用。
高性能叢集 (HP :High Performance ) 通常，第一種涉及為叢集開發并行程式設計應用程式，以解決複雜的科學問題。這是并行計算的基礎，盡管它不使用專門的并行超級計算機，這種超級計算機内部由十至上萬個獨立處理器組成。但它卻使用商業系統，如通過高速連接配接來連結的一組單處理器或雙處理器 PC，并且在公共消息傳遞層上進行通信以運作并行應用程式。是以，您會常常聽說又有一種便宜的 Linux 超級計算機問世了。但它實際是一個計算機叢集，其處理能力與真的超級計算機相等，通常一套象樣的叢集配置開銷要超過 $100,000。這對一般人來說似乎是太貴了，但與價值上百萬美元的專用超級計算機相比還算是便宜的。 |
下面筆者着重介紹前兩種叢集方式，也是企業中最常用的。（不是做科學研究，模拟×××爆炸，宇宙曲線計算等的大型項目高性能叢集一般用不到）
一、負載均衡叢集 (LB:load balancing)
| 負載均衡技術主要應用 1、DNS負載均衡 最早的負載均衡技術是通過DNS來實作的，在DNS中為多個位址配置同一個名字，因而查詢這個名字的客戶機将得到其中一個位址，進而使得不同的客戶通路不同的伺服器，達到負載均衡的目的。DNS負載均衡是一種簡單而有效的方法，是以，對于同一個名字，不同的用戶端會得到不同的位址，他們也就連結不同位址上的Web伺服器，進而達到負載平衡的目的。例如 : 當用戶端連結 www.51cto.com這名稱時，DNS 有能力依序将名稱解析到 202.1.1.1 、 202.1.1.2 、202.1.1.3和 202.1.1.4等不同的網絡位址，而這些是提供相同服務的主機，讓用戶端不自覺有不同 . 2、代理伺服器負載均衡 使用代理伺服器，可以将請求轉發給内部的伺服器，使用這種加速模式顯然可以提升靜态網頁的通路速度。然而，也可以考慮這樣一種技術，使用代理伺服器将請求均勻轉發給多台伺服器，進而達到負載均衡的目的。 3、位址轉換網關負載均衡 支援負載均衡的位址轉換網關，可以将一個外部IP位址映射為多個内部IP位址，對每次TCP連接配接請求動态使用其中一個内部位址，達到負載均衡的目的。 4、協定内部支援負載均衡 除了這三種負載均衡方式之外，有的協定内部支援與負載均衡相關的功能，例如HTTP協定中的重定向能力等，HTTP運作于TCP連接配接的最高層。 5、NAT負載均衡 NAT（Network Address Translation 網絡位址轉換）簡單地說就是将一個IP位址轉換為另一個IP位址，一般用于未經注冊的内部位址與合法的、已獲注冊的Internet IP位址間進行轉換。适用于解決Internet IP位址緊張、不想讓網絡外部知道内部網絡結構等的場合下。 6、反向代理負載均衡 普通代理方式是代理内部網絡使用者通路internet上伺服器的連接配接請求，用戶端必須指定代理伺服器,并将本來要直接發送到internet上伺服器的連接配接請求發送給代理伺服器處理。反向代理（Reverse Proxy）方式是指以代理伺服器來接受internet上的連接配接請求，然後将請求轉發給内部網絡上的伺服器，并将從伺服器上得到的結果傳回給internet上請求連接配接的用戶端，此時代理伺服器對外就表現為一個伺服器。反向代理負載均衡技術是把将來自internet上的連接配接請求以反向代理的方式動态地轉發給内部網絡上的多台伺服器進行處理，進而達到負載均衡的目的。 7、混合型負載均衡 在有些大型網絡，由于多個伺服器群内硬體裝置、各自的規模、提供的服務等的差異，我們可以考慮給每個伺服器群采用最合适的負載均衡方式，然後又在這多個伺服器群間再一次負載均衡或群集起來以一個整體向外界提供服務（即把這多個伺服器群當做一個新的伺服器群），進而達到最佳的性能。我們将這種方式稱之為混合型負載均衡。此種方式有時也用于單台均衡裝置的性能不能滿足大量連接配接請求的情況下。 |
筆者用一幅圖為例，簡單介紹下負載均衡原理：
使用者通過網際網路通路到某個網站時，，前端的Load Balancer（類似負載均衡器）根據不同的算法或某種特定的方式，将請求轉發到後端真正的伺服器（節點），背景多台伺服器共同分擔整個網站的壓力。背景的某個節點如果有當機，其他節點也可以提供服務，進而維持整個網站的正常運作.
負載均衡可以針對不同的網路層次
鍊路聚合技術（第二層負載均衡）是将多條實體鍊路當作一條單一的聚合邏輯鍊路使用，網絡資料流量由聚合邏輯鍊路中所有實體鍊路共同承擔，由此在邏輯上增大了鍊路的容量，使其能滿足帶寬增加的需求.
現在經常使用的是4至7層的負載均衡。
第四層負載均衡将一個Internet上合法注冊的IP位址映射為多個内部伺服器的IP位址，對每次TCP連接配接請求動态使用其中一個内部IP位址，達到負載均衡的目的。在第四層交換機中，此種均衡技術得到廣泛的應用，一個目标位址是伺服器群VIP（虛拟IP，Virtual IP address）連接配接請求的資料包流經交換機，交換機根據源端和目的IP位址、TCP或UDP端口号和一定的負載均衡政策，在伺服器IP和VIP間進行映射，選取伺服器群中最好的伺服器來處理連接配接請求。
第七層負載均衡控制應用層服務的内容，提供了一種對通路流量的高層控制方式，适合對HTTP伺服器群的應用。第七層負載均衡技術通過檢查流經的HTTP報頭，根據報頭内的資訊來執行負載均衡任務。
第七層負載均衡優點表現在如下幾個方面：
1。通過對HTTP報頭的檢查，可以檢測出HTTP400、500和600系列的錯誤資訊，因而能透明地将連接配接請求重新定向到另一台伺服器，避免應用層故障。
2。可根據流經的資料類型（如判斷資料包是圖像檔案、壓縮檔案或多媒體檔案格式等），把資料流量引向相應内容的伺服器來處理，增加系統性能。
3。能根據連接配接請求的類型，如是普通文本、圖象等靜态文檔請求，還是asp、cgi等的動态文檔請求，把相應的請求引向相應的伺服器來處理，提高系統的性能及安全性。
缺點: 第七層負載均衡受到其所支援的協定限制（一般隻有HTTP），這樣就限制了它應用的廣泛性，并且檢查HTTP報頭會占用大量的系統資源，勢必會影響到系統的性能，在大量連接配接請求的情況下，負載均衡裝置自身容易成為網絡整體性能的瓶頸。
實作負載均衡有兩種方式：
1、硬體：
如果我們搜一搜"負載均衡",會發現大量的關于F5等負載均衡裝置的内容，基于硬體的方式，能夠直接通過智能交換機實作,處理能力更強，而且與系統無關，這就是其存在的理由．但其缺點也很明顯：
首先是貴，這個貴不僅是展現在一台裝置上，而且展現在備援配置上．很難想象後面伺服器做一個叢集，但最關鍵的負載均衡裝置卻是單點配置，一旦出了問題就全趴了．
第二是對伺服器及應用狀态的掌握：硬體負載均衡，一般都不管實際系統與應用的狀态，而隻是從網絡層來判斷，是以有時候系統處理能力已經不行了，但網絡可能還來得及反應（這種情況非常典型，比如應用伺服器後面記憶體已經占用很多，但還沒有徹底不行，如果網絡傳輸量不大就未必在網絡層能反映出來）。
是以硬體方式更适用于一大堆裝置、大通路量、簡單應用。
一般而言，硬體負載均衡在功能、性能上優于軟體方式，不過成本昂貴。
在網站上搜尋了一些硬體負載均衡裝置的報價.是不是很吓人.動則幾十萬，貴則上百萬.
| 硬體load balance廠商和産品清單: 公司名稱: Alteon Websystems(Nortel): 産品 ACEDirector, AceSwitch 180等 http://products.nortel.com/go/product_content.jsp?segId=0&parId=0&prod_id=37160&locale=en-US ------------------------------------------------------------------------------------------------------------------------------------------公司名稱: F5 networks: 産品: BIG-IP http://www.f5networks.co.jp/ http://www.f5networks.co.jp/product/bigip/ltm/index.html http://www.f5.com/products/bigip/ ------------------------------------------------------------------------------------------------------------------------------------------ 公司名稱: Arrow Point(Cisco): 産品: CS-100 http://www.ecrunch.com/listingview.php?listingID=59&PHPSESSID=3c21a8f95a6459132a120d4335dcf506 公司名稱: Cisco 産品: Local Director 400 series http://www.cisco.com/en/US/products/hw/contnetw/ps1894/index.html 公司名稱: RADWARE 産品: APP Director (Web server director) http://www.radware.com/ http://www.radware.com/content/products/appdirector/default.asp 公司名稱: Abocom（友旺） 産品: MH系列多路負載均衡器 http://www.abocom.com.cn/product.asp?xlflid=12 台灣公司，生産家用和企業用負載均衡器， 看上去比較 業餘 公司名稱: Intel 産品: NetStructure(網擎) 7170 traffic director http://www.intel.com/support/netstructure/sb/cs-009599.htm 公司名稱: Coyote Point http://www.coyotepoint.com/ 專門做硬體load balance的公司好稱成本效益超過F5的公司 公司名稱: Foundry Networks 産品: ServerIron http://www.foundrynet.com/products/webswitches/serveriron/index.html 公司名稱: HydraWeb 産品: HydraWeb Dispatcher |
可以看出，硬體裝置的昂貴程度不是每個企業都可以用起的，而且實際上如果幾台伺服器，用F5之類的絕對是殺雞用牛刀（而且得用兩把牛刀），而用軟體就要合算得多，因為伺服器同時還可以跑應用，呵呵，下面來看看可以在linux平台實作負載均衡的軟體。
2、軟體：
軟體負載均衡解決方案是指在一台或多台伺服器相應的作業系統上安裝一個或多個附加軟體來實作負載均衡，它的優點是基于特定環境，配置簡單，使用靈活，成本低廉，可以滿足一般的負載均衡需求。
著名項目：開源軟體最著名的是LVS.
LVS提供了兩大類負載均衡技術及其配套叢集管理軟體
·三種IP負載均衡技術 + IP虛拟伺服器軟體IPVS·基于内容請求分發的核心Layer-7交換機KTCPVS和叢集管理軟體（解決後端伺服器組提供不同的内容的問題）
★★★LVS系統結構與特點
1. Linux Virtual Server:簡稱LVS｡是由中國一個Linux程式員章文嵩博士發起和上司的,基于Linux系統的伺服器叢集解決方案,其實作目标是建立一個具有良好的擴充性､高可靠性､高性能和高可用性的體系｡許多商業的叢集産品,比如RedHat的Piranha､ Turbo Linux公司的Turbo Cluster等,都是基于LVS的核心代碼的｡
2. 體系結構:使用LVS架設的伺服器叢集系統從體系結構上看是透明的,最終使用者隻感覺到一個虛拟伺服器｡實體伺服器之間可以通過高速的 LAN或分布在各地的WAN相連｡最前端是負載均衡器,它負責将各種服務請求分發給後面的實體伺服器,讓整個叢集表現得像一個服務于同一IP位址的虛拟伺服器｡
3. LVS的三種模式工作原理和優缺點: Linux Virtual Server主要是在負載均衡器上實作的,負載均衡器是一台加了 LVS Patch的2.2.x版核心的Linux系統｡LVS Patch可以通過重新編譯核心的方法加入核心,也可以當作一個動态的子產品插入現在的核心中｡
功能
有實作三種IP負載均衡技術和八種連接配接排程算法的IPVS軟體。在IPVS内部實作上，采用了高效的Hash函數和垃圾回收機制，能正确處理所排程封包相關的ICMP消息（有些商品化的系統反而不能）。虛拟服務的設定數目沒有限制，每個虛拟服務有自己的伺服器集。它支援持久的虛拟服務（如HTTP Cookie和HTTPS等需要該功能的支援），并提供詳盡的統計資料，如連接配接的處理速率和封包的流量等。針對大規模拒絕服務（Deny of Service）攻擊，實作了三種防衛政策。
負載均衡器可以運作在以下三種模式下:
簡單說明下圖簡稱：以下CIP為用戶端IP,VIP為伺服器向外提供服務的IP，DIP為Director與内部伺服器節點通信的IP，RIP為内部真實伺服器的IP。
(1)Virtual Server via NAT(VS-NAT):用位址翻譯實作虛拟伺服器｡位址轉換器有能被外界通路到的合法IP位址,它修改來自專有網絡的流出包的位址｡外界看起來包是來自位址轉換器本身,當外界包送到轉換器時,它能判斷出應該将包送到内部網的哪個節點｡優點是節省IP 位址,能對内部進行僞裝;缺點是效率低,因為傳回給請求方的流量經過轉換器｡
整個過程如圖所示：CIP為客戶Client的IP，VIP為伺服器對外的IP，RIP為内部真實伺服器的IP
(2)Virtual Server via Direct Routing(VS-DR):用直接路由技術實作虛拟伺服器｡當參與叢集的計算機和作為控制管理的計算機在同一個網段時可以用此法,控制管理的計算機接收到請求包時直接送到參與叢集的節點｡直接路由模式比較特别，很難說和什麼方面相似，前2種模式基本上都是工作在網絡層上（三層），而直接路由模式則應該是工作在資料鍊路層上（二層）。其原理 為，DR和REAL SERVER都使用同一個IP對外服務。但隻有DR對ARP請求進行響應，所有REAL SERVER對本身這個IP的ARP請求保持靜默。也就是說，網關會把對這個服務IP的請求全部定向給DR，而DR收到資料包後根據排程算法，找出對應的 REAL SERVER，把目的MAC位址改為REAL SERVER的MAC并發給這台REAL SERVER。這時REAL SERVER收到這個資料包，則等于直接從用戶端收到這個資料包無異，處理後直接傳回給用戶端。由于DR要對二層標頭進行改換，是以DR和REAL SERVER之間必須在一個廣播域，也可以簡單的了解為在同一台交換機上。
DR模式：DR模式是這樣工作的，當CIP通路VIP後，VIP把資料包通過DIP轉交給RIP,RIP在收到資料包後通過網卡别名欺騙（節點的網卡配置别名，IP為VIP），直接用别名的VIP相應用戶端，進而加快了回應速度，也避免了Director成為位址轉換的單點故障.目前主要應用的為DR模式的負載均衡.
(3)Virtual Server via IP Tunneling (VS-TUN):用IP隧道技術實作虛拟伺服器｡這種方式是在叢集的節點不在同一個網段時可用的轉發機制,是将IP包封裝在其他網絡流量中的方法｡為了安全的考慮,應該使用隧道技術中的×××,也可使用租用專線｡ 叢集所能提供的服務是基于TCP/IP的Web服務､Mail服務､News服務､DNS服務､Proxy伺服器等等.
TUN模式:采用NAT技術時，由于請求和響應封包都必須經過排程器位址重寫，當客戶請求越來越多時，排程器的處理能力将成為瓶頸。為了解決這個問題，排程器把請求封包通過IP隧道轉發至真實伺服器，而真實伺服器将響應直接傳回給客戶，是以排程器隻處理請求封包。由于一般網絡服務應答比請求封包大許多，采用 VS/TUN技術後，叢集系統的最大吞吐量可以提高10倍。(通過重寫ip來實作，真實伺服器直接回複用戶端。tun原理請參閱×××原理！），與上圖比較，注意節點的VIP和RIP的差別.
介紹完上面3種負載均衡模式，下面來看看負載均衡排程算法.
IPVS排程器實作了如下八種負載排程算法
| ·1.輪叫（Round Robin） 排程器通過"輪叫"排程算法将外部請求按順序輪流配置設定到叢集中的真實伺服器上，它均等地對待每一台伺服器，而不管伺服器上實際的連接配接數和系統負載。 ·2.權重輪叫（Weighted Round Robin） 排程器通過"權重輪叫"排程算法根據真實伺服器的不同處理能力來排程通路請求。這樣可以保證處理能力強的伺服器處理更多的通路流量。排程器可以自動問詢真實伺服器的負載情況，并動态地調整其權值。 ·3.最少連結（Least Connections） 排程器通過"最少連接配接"排程算法動态地将網絡請求排程到已建立的連結數最少的伺服器上。如果叢集系統的真實伺服器具有相近的系統性能，采用"最小連接配接"排程算法可以較好地均衡負載。 ·4.權重最少連結（Weighted Least Connections） 在叢集系統中的伺服器性能差異較大的情況下，排程器采用"權重最少連結"排程算法優化負載均衡性能，具有較高權值的伺服器将承受較大比例的活動連接配接負載。排程器可以自動問詢真實伺服器的負載情況，并動态地調整其權值。 ·5.基于局部性的最少連結（Locality-Based Least Connections） "基于局部性的最少連結" 排程算法是針對目标IP位址的負載均衡，目前主要用于Cache叢集系統。該算法根據請求的目标IP位址找出該目标IP位址最近使用的伺服器，若該伺服器是可用的且沒有超載，将請求發送到該伺服器；若伺服器不存在，或者該伺服器超載且有伺服器處于一半的工作負載，則用"最少連結"的原則選出一個可用的伺服器，将請求發送到該伺服器。 ·6.帶複制的基于局部性最少連結（Locality-Based Least Connections with Replication） "帶複制的基于局部性最少連結"排程算法也是針對目标IP位址的負載均衡，目前主要用于Cache叢集系統。它與LBLC算法的不同之處是它要維護從一個目标IP位址到一組伺服器的映射，而LBLC算法維護從一個目标IP位址到一台伺服器的映射。該算法根據請求的目标IP位址找出該目标IP位址對應的伺服器組，按"最小連接配接"原則從伺服器組中選出一台伺服器，若伺服器沒有超載，将請求發送到該伺服器，若伺服器超載；則按"最小連接配接"原則從這個叢集中選出一台伺服器，将該伺服器加入到伺服器組中，将請求發送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，将最忙的伺服器從伺服器組中删除，以降低複制的程度。 ·7.目标位址散列（Destination Hashing） "目标位址散列"排程算法根據請求的目标IP位址，作為散列鍵（Hash Key）從靜态配置設定的散清單找出對應的伺服器，若該伺服器是可用的且未超載，将請求發送到該伺服器，否則傳回空。 ·8.源位址散列（Source Hashing） "源位址散列"排程算法根據請求的源IP位址，作為散列鍵（Hash Key）從靜态配置設定的散清單找出對應的伺服器，若該伺服器是可用的且未超載，将請求發送到該伺服器，否則傳回空。 |
IPVS的缺點
在基于IP負載排程技術中不會區分内容！是以就要求後端伺服器提供相同的服務。而事實呢很多web應用總後端伺服器都擔任不同的角色，比如專門存放html的、專門存放圖檔的、專門存放CGI的
★★★核心Layer-7交換機KTCPVS（基于内容轉發可以提高單台伺服器cache的命中率）
KTCPVS工作流程
在基于IP負載排程技術中，當一個TCP連接配接的初始SYN封包到達時，排程器就選擇一台伺服器，将封包轉發給它。此後通過查發封包的IP和TCP封包頭位址，保證此連接配接的後繼封包被轉發到該伺服器。這樣，IPVS無法檢查到請求的内容再選擇伺服器，這就要求後端伺服器組提供相同的服務，不管請求被發送到哪一台伺服器，傳回結果都是一樣的。但是，在有些應用中後端伺服器功能不一，有的提供HTML文檔，有的提供圖檔，有的提供CGI，這就需要基于内容的排程 (Content-Based Scheduling)。
由于使用者空間TCP Gateway的開銷太大
他們提出在作業系統的核心中實作Layer-7交換方法，來避免使用者空間與核心空間的切換和記憶體複制的開銷。在Linux作業系統的核心中，我們實作了Layer-7交換，稱之為KTCPVS（Kernel TCP Virtual Server）。目前，KTCPVS已經能對HTTP請求進行基于内容的排程，但它還不很成熟，在其排程算法和各種協定的功能支援等方面，有大量的工作需要做。
雖然應用層交換處理複雜，它的伸縮性有限，但應用層交換帶來以下好處：
相同頁面的請求被發送到同一伺服器，可以提高單台伺服器的Cache命中率。
一些研究[5]表明WEB通路流中存在局部性。Layer-7交換可以充分利用通路的局部性，将相同類型的請求發送到同一台伺服器，使得每台伺服器收到的請求具有更好的相似性，可進一步提高單台伺服器的Cache命中率。
後端伺服器可運作不同類型的服務，如文檔服務，圖檔服務，CGI服務和資料庫服務等。
----------------------------------------------------------------------------------------------------------------------------------------------------
二、 高可用性叢集 (HA:High Availability)
1、什麼是高可用叢集
高可用叢集，英文原文為High Availability Cluster，簡稱HA Cluster，是指以減少服務中斷（如因伺服器當機等引起的服務中斷）時間為目的的伺服器叢集技術。簡單的說，叢集（cluster）就是一組計算機，它們作為一個整體向使用者提供一組網絡資源。這些單個的計算機系統就是叢集的節點（node）。
高可用叢集的出現是為了使叢集的整體服務盡可能可用，進而減少由計算機硬體和軟體易錯性所帶來的損失。它通過保護使用者的業務程式對外不間斷提供的服務，把因軟體/硬體/人為造成的故障對業務的影響降低到最小程度。如果某個節點失效，它的備援節點将在幾秒鐘的時間内接管它的職責。是以，對于使用者而言，叢集永遠不會停機。高可用叢集軟體的主要作用就是實作故障檢查和業務切換的自動化。
隻有兩個節點的高可用叢集又稱為雙機熱備，即使用兩台伺服器互相備份。當一台伺服器出現故障時，可由另一台伺服器承擔服務任務，進而在不需要人工幹預的情況下，自動保證系統能持續對外提供服務。雙機熱備隻是高可用叢集的一種，高可用叢集系統更可以支援兩個以上的節點，提供比雙機熱備更多、更進階的功能，更能滿足使用者不斷出現的需求變化。
2、為什麼要使用高可用叢集？
先來看一組資料說明：
系統可用性分類
| 可用比例 (Percent Availability) | 年停機時間 (downtime/year) | 可用性分類 |
| 99.5 | 3.7天 | 正常系統(Conventional) |
| 99.9 | 8.8小時 | 可用系統(Available) |
| 99.99 | 52.6分鐘 | 高可用系統(Highly Available) |
| 99.999 | 5.3分鐘 | Fault Resilient |
| 99.9999 | 32秒 | Fault Tolerant |
對于關鍵業務，停機通常是災難性的。因為停機帶來的損失也是巨大的。下面的統計數字列舉了不同類型企業應用系統停機所帶來的損失。表 2. 停機給企業帶來的損失
| 應用系統 | 每分鐘損失(美元) |
| 呼叫中心(Call Center) | 27000 |
| 企業資源計劃(ERP)系統 | 13000 |
| 供應鍊管理(SCM)系統 | 11000 |
| 電子商務(eCommerce)系統 | 10000 |
| 客戶服務(Customer Service Center)系統 |
随着企業越來越依賴于資訊技術，由于系統停機而帶來的損失也越拉越大。
高可用叢集主要是在linux平台搭建的，在linux上實作高可用的解決方案有哪些：
| Linux平台常見的高可用叢集 有這些: 1. 開放源代碼的 HA 項目 (http://www.linux-ha.org/) linux-HA 項目曆史悠久, 很多linux 發行附帶的HA叢集都是采用了linux-HA 的heartbeat系統和相關的元件.需要建構完全的開源，自由而且免費的高可用叢集的使用者可以選擇. 2 RedHat 公司 的 開放源代碼RedHat Cluster Suite, 簡稱RHCS . (産品介紹http://www.redhat.com/solutions/clustersuite/) - RHCS實際上是一個套件，除了現在提到的高可用叢集軟體，還包含了一個基于LVS的負載均衡軟體. - RHCS包含的叢集軟體，是GPL協定下開放源代碼的叢集系統. - RHCS目前的版本有 RHCS v3和 v4,分别對應于RedHat 企業版Linux的 3.0家族和4.0家族. - RHCS是一個獨立的産品，不包括在RedHat Enterprise Linux當中，無論是購買還是下載下傳，都是單獨存在的.（其實就是heartbeat的改進版，改個名，加入了些東西） 3. Novell 公司 的 開放源代碼高可用叢集HA套件 Novell 公司并購了歐洲Linux第一大廠SuSE之後，成為全球能夠抗衡RedHat的主要力量. SuSE企業版Linux 帶有一套開放源代碼的HA叢集軟體，包括 HA project的heartbeat, heartbeat-ldirectord, heartbeat-pils, heartbeat-stonith, 叢集關聯的存儲軟體drbd, 虛拟IP的 src_vipa軟體.和RHCS不同的是，SuSE/Novell 企業版Linux自帶的 HA叢集軟體并非一個獨立的軟體，如上介紹，而是由不同的開放源代碼項目提供的不同部分的程式。 4. Novell 公司的Novell Cluster Service Novell 在敗落前，曾經是一家非常偉大的公司，有着非常雄厚的技術力量。 早在10多年前，Novell公司就在叢集領域獨樹一幟，是當時唯一能夠在PC伺服器上建構出32節點叢集的廠商. Novell收購SuSE公司之後，将原來在Novell netware作業系統上的大量企業級應用移植和整合到了SuSE Linux Enterprise Linux平台, Novell 當時名震叢集領域的Novell Cluster Service 也被整合移植到了Linux平台. Novell Cluster Service是一個商業系統，并非開放源代碼産品 這裡可以看到細節 http://www.novell.com/products/openenterpriseserver/ncs.html 5. Steeleye Lifekeeper for linux (産品介紹http://www.steeleye.com/) steeleye 公司是叢集行業非常著名的公司，他們的叢集系統最早是AT&T 貝爾實驗室開發的，後來被賣給了金融行業的著名IT公司NCR公司。(不少朋友到ATM取錢的時候也許會看到NCR制造的ATM機). lifekeeper叢集的曆史非常悠久，後來steeleye又得到了幾個從當時的巨頭DEC跳槽來的核心開發人員.是以lifekeeper的構架和品質是有非常好的口碑的. 6. HP MC/Service Guard for linux (http://h71028.www7.hp.com/enterprise/cache/6468-0-0-0-121.aspx) HP在和Compaq合并之前，在HP-UX平台有一套旗艦級的高可用叢集系統(MC/SG for HP-UX)，被廣泛部署在各種關鍵業務計算領域。比如銀行，電信，金融等等。主要的硬體平台是PA-RISC架構的小型機和中型機系統. Compaq在和HP合并之前，在Alpha 平台有一套旗艦級的高可用叢集,叫做(TruCluster).被廣泛部署在各種關鍵業務計算領域，比如國防，航天，制造等等。主要的硬體平台是Alpha架構的小型機和中型機. 随着兩個公司的合并，兩套著名的叢集系統也完成了合并，新的産品仍舊叫做MC/SG,但是可以跑在PA-RISC, IA, IA64平台. 5年前，HP将MC/SG叢集系統移植到了linux平台，并發展至今. HP MC/SG for linux有着非常高的品質和長期在高度關鍵業務要求的領域發展的背景。 7. Turbolinux 高可用叢集系統 Turbolinux 這幾年發展的頗不順利，從創始人走人到公司在日本的股權變動. 頗讓人擔憂。 TurboLinux 的高可用叢集軟體有兩個. a. TurboLinux Cluster HA 3.1 b. TurboLinux8 ClusterPro 因為都沒有在具體的項目中深入用過，不做更多解釋. |
筆者以最常用的heartbeat為例介紹高可用叢集：
下圖是一個Heartbeat叢集的一般拓撲圖。在實際應用中，由于節點的數目、網絡結構和磁盤類型配置的不同，拓撲結構可能會有不同。
Heartbeat的組成：
Heartbeat提供了高可用叢集最基本的功能，例如，節點間的内部通信方式、叢集合作管理機制、監控工具和失效切換功能等。目前的最新版本是Heartbeat 2.x，這裡的講述也是以Heartbeat 2.x為主。下面介紹Heartbeat 2.0的内部組成，主要分為以下幾大部分。
heartbeat：節點間通信檢測子產品。
ha-logd：叢集事件日志服務。
CCM（Consensus Cluster Membership）：叢集成員一緻性管理子產品。
LRM（Local Resource Manager）：本地資源管理子產品。
Stonith Daemon：使出現問題的節點從叢集環境中脫離。
CRM（Cluster Resource Management）：叢集資源管理子產品。
Cluster policy engine：叢集政策引擎。
Cluster transition engine：叢集轉移引擎。
| 從上圖中可以看出，Heartbeat内部結構由三大部分組成。 （1）叢集成員一緻性管理子產品（CCM） CCM用于管理叢集節點成員，同時管理成員之間的關系和節點間資源的配置設定。Heartbeat子產品負責檢測主次節點的運作狀态，以決定節點是否失效。ha-logd子產品用于記錄叢集中所有子產品和服務的運作資訊。 （2）本地資料總管（LRM） LRM負責本地資源的啟動、停止和監控，一般由LRM守護程序lrmd和節點監控程序Stonith Daemon組成。lrmd守護程序負責節點間的通信；Stonith Daemon通常是一個Fence裝置，主要用于監控節點狀态，當一個節點出現問題時處于正常狀态的節點會通過Fence裝置将其重新開機或關機以釋放IP、磁盤等資源，始終保持資源被一個節點擁有，防止資源争用的發生。 （3）叢集資源管理子產品（CRM） CRM用于處理節點和資源之間的依賴關系，同時，管理節點對資源的使用，一般由CRM守護程序crmd、叢集政策引擎和叢集轉移引擎3個部分組成。叢集政策引擎（Cluster policy engine）具體實施這些管理和依賴；叢集轉移引擎（Cluster transition engine）監控CRM子產品的狀态，當一個節點出現故障時，負責協調另一個節點上的程序進行合理的資源接管。 在Heartbeat叢集中，最核心的是Heartbeat子產品的心跳監測部分和叢集資源管理子產品的資源接管部分。心跳監測一般由串行接口通過序列槽線來實作，兩個節點之間通過序列槽線互相發送封包來告訴對方自己目前的狀态。如果在指定的時間内未受到對方發送的封包，就認為對方失效，這時資源接管子產品将啟動，用來接管運作在對方主機上的資源或者服務 |
----------------------------------------------------------------------------------------------------------------------------------------------------
三.高性能叢集 (HP :High Performance )
這種叢集一般企業或者個人很少應用到， 高性能計算群集HPC。它可以解決世界上最為複雜和艱巨的計算難題，并且能夠輕松處理。在氣象模組化、模拟撞車試驗、人體基因繪圖以及核爆炸模拟等多種與人類生命相關的重要領域都要用到HPC。随着其性能突飛猛進的提高和成本的急劇下降，HPC迅速走出科學研究實驗室，步入主流商業領域。通過将叢集和大型SMP系統的性能進行完美結合，HPC正在步入網格計算時代，它将使任何人都能随時随地、經濟高效地進行計算，在商業上得到更好的應用。衆多企業都被其幾乎不可抗拒特性和優勢所打動，并争相進行部署。除政府、教育和國家實驗室等公共部門之外，HPC在制造、金融、能源、生命科學和數字媒體等行業都廣受青睐。（此類叢集應用有一定局限性，筆者接觸不多，不做過多介紹。）
下面是一張某公司的高性能叢集組成圖：
基礎架構：聚合結點、網絡以及存儲等硬體子系統的基礎設施，提供整個叢集系統的供電、散熱、布線等功能<登入結點：使用者登入到叢集的工作場所，使用者通過它來完成程式的編譯調試等工作
計算結點：用于執行使用者程式的結點伺服器。
存儲結點：是挂接儲存設備、向系統中的其它結點提供存儲服務的伺服器。
監控結點：用來監控系統各部分的運作狀态、進行遠端電源管理和事件告警服務等工作。
存儲交換網絡：用來連接配接存儲結點和磁盤陣列。
計算網：計算結點在運作程式時的通信設施。由高速的通信網絡構成，如Infiniband網絡。
管理網：用于叢集系統管理的網絡，一般采用千兆以太網。
視訊切換系統：通過它可以将標明結點機的keyboard、video和mouse重定向到監控台上，進而可以在監控台上對結點進行各種終端的操作
叢集軟體系統結構圖：
裝置系統固件層：通信軟體和外部裝置在擴充卡上的固件程式
結點系統軟體層：結點作業系統及其核心擴充，如作業系統、裝置驅動程式、檔案系統擴充等
叢集系統軟體層：叢集單一映象的操作管理軟體。包括叢集管理系統、叢集監控系統、作業排程系統等
應用支撐環境層：科學計算應用的支撐平台。如并行環境、數學庫、多核線程調試工具等
應用程式層：科學工程計算類的實際應用。
高性能叢集筆者接觸不多就不過多介紹了，筆者上傳一個惠普公司的一個高性能叢集案例，在附件裡，要想深入了解的話可以看下。