對于初學(xué)者，總是會對集群和負載均衡功能進行混淆。那么在這里我們從一些資料中，總結(jié)了一些網(wǎng)友的學(xué)習(xí)經(jīng)驗，在此分享給廣大的讀者?？纯磩e人的理解和表述，對你的學(xué)習(xí)是否有所幫助呢？現(xiàn)在就來看看負載均衡功能的實現(xiàn)問題吧。

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

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

2.如何實現(xiàn)數(shù)據(jù)庫的均衡

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

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

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

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

負載均衡集群適用于提供相對靜態(tài)的數(shù)據(jù)的服務(wù)，比如HTTP服務(wù)。因為通常負載均衡集群的各節(jié)點間通常沒有共用的存儲介質(zhì)，用戶數(shù)據(jù)被復(fù)制成多份，存放于每一個提供該項服務(wù)的節(jié)點上。

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

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

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

引文:

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

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

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

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

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

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

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

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

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

就如我開篇所說

引文:

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

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

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

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

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

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

不過，我有一個想法，在數(shù)據(jù)庫只讀的應(yīng)用環(huán)境下，比如高考考分查詢，是不是可以多臺機器建多個庫，庫內(nèi)容都一樣，這樣的話由于不涉及數(shù)據(jù)同步的問題，應(yīng)該可以實現(xiàn)真正均衡的。