對于初學者，總是會對集群和負載均衡功能進行混淆。那么在這里我們從一些資料中，總結了一些網友的學習經驗，在此分享給廣大的讀者。看看別人的理解和表述，對你的學習是否有所幫助呢？現在就來看看負載均衡功能的實現問題吧。

有兩個問題一直沒有很好的對自己能解釋通，尤其是在沒有弄明白這兩個問題的相關術語的時候，又去研究相關的衍生問題，搞得自己差點口吐白沫。這兩個問題是這樣的：

1.集群軟件能否實現負載均衡的功能，兩者有何差別

2.如何實現數據庫的均衡

集群一般有兩種：高可用和高性能集群，一般的集群，包括現在的低端雙機容錯、IBM的HACMP、HP的MCServiceGuard都是高可用性集群，不能做負載均衡；而高性能集群主要是科學計算、科研等一些特殊環境用，在現實應用中比較少。而ORACLE的RAC是基于特殊環境下的應用系統，要求有操作系統層面的分布式鎖（DLM)。具體使用起來要作相應的規劃，而且不能隨便使用，弄不好性能適得其反的差。

前面說過，負載均衡不能完全算高可用性集群的一種，是高性能性集群，普通的HA軟件沒辦法支持象ORACLERAC一樣的環境，這不完全是集群軟件的功能。

高可用性集群與負載均衡集群的工作原理不同，適用于不同類型的服務。通常，負載均衡集群適用于提供靜態數據的服務，如HTTP服務；而高可用性集群既適用于提供靜態數據的服務，如HTTP服務，又適用于提供動態數據的服務，如數據庫等。高可用性集群之所以能適用于提供動態數據的服務，是由于節點共享同一存儲介質，如SAN陣列。也就是說，在高可用性集群內，每種服務的用戶數據只有一份，存儲在共用存儲設備上，在任一時刻只有一個節點能讀寫這份數據。

高可用性集群對一種服務而言不具有負載均衡功能，它可以提高整個系統的可靠性，但不能增加負載的能力。當然，高可用性集群可以運行多種服務，并適當分配在不同節點上，比如節點A提供Oracle服務，同時節點B提供Sybase服務，這也可以看成是某種意義上的負載均衡，不過這是對多種服務的分配而言。

負載均衡集群適用于提供相對靜態的數據的服務，比如HTTP服務。因為通常負載均衡集群的各節點間通常沒有共用的存儲介質，用戶數據被復制成多份，存放于每一個提供該項服務的節點上。

這個困擾我已久一直沒有系統整理的問題到這里基本明了了，各位看官到這里旋即也會想到，如果用戶有一個由兩個節點組成的最小集群，是否可以同時獲得高可用性集群和負載均衡集群的效益呢？答案是肯定的。由于高可用性集群適用于提供動態數據的服務，而負載均衡集群適用于提供靜態數據的服務，所以我們不妨假設要同時提供Oracle和HTTP服務。用戶要在節點A和B上安裝HA和NLB軟件。把節點A作為Oracle正常工作的節點，節點B作為Oracle服務的后備節點，這是對HA軟件而言。對于NLB軟件而言，要設置節點B為主ATM（ApplicationTrafficManagement）節點，節點A為后備ATM節點，而節點A和節點B同時又都是HTTP的服務節點。

這樣一來，節點A和節點B都是身兼兩職，而用戶同時得到了一個具有高可用性的Oracle服務和一個具有負載均衡功能的HTTP服務。即使有一個節點發生故障，Oracle服務和HTTP服務都不會因此而中斷。

這里涉及到一個關鍵問題：對于同一種服務，是不能同時獲得高可用性與負載均衡功能的（有不同意見的么？）。對一種服務，要么是只有一份數據，放在共用存儲設備上，一次被一個節點訪問，獲得高可用性；要么是把數據復制為多份，存儲于每個節點的本地硬盤上，用戶的請求同時發送到多個節點上，獲得負載均衡功能。這也是F5設備沒有提供數據庫均衡的解決方案的難點所在。

引文:

首先申明，除了只讀型數據庫在某些特定條件下可能使用BIGIP實現負載均衡外。F5迄今未推廣過讀寫型數據庫的負載均衡方案。

數據庫的Cluster和HA是兩個概念。在HA方式下，兩臺數據庫服務器只有一臺在工作，并且是由Active設備控制盤陣。在發生HA切換時，Backup設備接管盤陣。在Cluster狀態下，比如OracleRAC，可以實現兩臺服務器對同一盤陣的同時控制，并且使用的是同一份數據庫文件。在RAC存在的情況下，理論上有可能使用BIGIP實現負載均衡功能，但實際上很難發揮作用，只有在C/S結構下有可能實現，或者是多臺應用服務器訪問少量數據庫服務器的狀況下有可能。現在F5中國還未有進行此類測試，如果那位有此類環境可以做一個測試。F5會全力支持測試。#p#

對于高可用性集群，由于它在設計時的目的就是為了最大可能地減少服務中斷時間，因此服務的切換受到很大的關注。當一個節點上的服務故障時，會被很快地檢測到并被切換到其他節點上。但在切換時，不能忽略對數據完整性的保護。

再研究一下：在什么情況下數據完整性會被破壞呢？由于高可用性集群中至少有兩個節點，連接在一個共用的存儲設備上，對于非裸分區而言，如果被兩個節點同時讀寫，就會造成文件系統被破壞。因此就需要利用I/O屏障來防止這一事件的發生。

I/O屏障的目的是為了保證故障節點不能再繼續讀寫某一服務的共用分區，實現的方式有多種。Kimberlite使用硬件開關來實現，當一個節點發生故障時，另一節點如果能偵測到，就會通過串行口發出命令，控制連接在故障節點電源上的硬件開關，通過暫時斷電，而后又上電的方式使得故障節點被重啟動。

I/O屏障有多種形式。對于支持SCSIReserve/Release命令的存儲設備，也可以用SG命令實現I/O屏障。正常節點應使用SCSIReserve命令“鎖住”共用存儲設備，保證其不被故障節點讀寫。如果故障節點上的集群軟件仍在運行，如發現共用存儲設備已被對方鎖住，就應把自己重啟動，以恢復正常工作狀態。

實際上，使用F5設備有變通的方法：把兩臺服務器放入一個POOL中，設不同的優先級，讓優先級高的服務器對磁盤有讀寫操作，當高優先級的服務器宕機時，切到低優先級的機器上，這也實現了HA，這有點強詞奪理，但也能解釋，比HA軟件切換的快，因為用HA軟件做雙機時，備機上的各個服務都是宕的，只能當備機探測到主機服務宕機時，才開始啟動相應的服務，有時服務還啟不了；而用F5做雙機時，備機的各服務都是正常啟動著的，只是F5設備不把客戶請求發到備機上去而已，當主機宕機時，F5設備才把客戶請求發到備機，而備機的各服務都是正常啟動著的，所以…………

如果按照上面的方法作數據庫負載均衡，則必須解決一個重要的問題：數據庫的同步，如果切換的速度很快，則要求兩臺數據庫的同步也很快…………。其它可能還存在一些問題，所以迄今為止還是沒有見過類似結構。

OOPS，扯遠了。我來詳細說說為什么高可用集群不能對數據庫系統進行負載均衡，理由是對負載均衡功能的定義。

就如我開篇所說

引文:

集群一般有兩種高可用性和高性能集群，負載均衡不能完全算高可用性集群的一種，是高性能性集群

普通的HA軟件沒辦法支持象ORACLERAC一樣的環境，這不完全是集群軟件的功能。

我們就拿OPS來說事兒吧，OPS的核心組件是分布式鎖管理器(DLM)，它為OPS實例提供并行高速緩存管理。OPS群集的每個節點在加入群集時都啟動DLM進程的一個實例，然后這些實例就可以通過網絡互相通信。

因此我的結論一：沒有DLM，不管你是HACMP還是ServiceGuard或者TurboCluste都不能并行跑數據庫。（不了解mssql、sybase和DB2，歡迎舉反例）

然后，OPS的工作機制和simon說的沒錯，但是最終，它對庫文件的讀寫還是靠緩存排隊的，最終仍然同一時刻只有一臺主機在讀寫。可是，真正的負載均衡是N份文件的分布式讀取哦。負載均衡是所有資源的均衡哦。

因此我的結論二：即使HA軟件配合OPS，仍然不是真正的負載均衡功能。當然，我們和客戶不能這么說。

不過，我有一個想法，在數據庫只讀的應用環境下，比如高考考分查詢，是不是可以多臺機器建多個庫，庫內容都一樣，這樣的話由于不涉及數據同步的問題，應該可以實現真正均衡的。