有兩個問題一直沒有很好的對自己能解釋通，尤其是在沒有弄明白這兩個問題的相關術語的時候，又去研究相關的衍生問題，搞得自己差點口吐白沫。這兩個問題是這樣的：
1.集群軟體能否實現負載均衡的功能，兩者有何差別
2.如何實現資料庫的均衡。
現在看起來蠻easy的問題，可是當初俺是菜菜哦。不過說起來，要講清楚這個問題也是蠻考察功力的哦。好了，俺把俺研究的東東分享一下。
集群一般有兩種：高可用和高效能集群，一般的集群，包括現在的低端雙機容錯、ibm的hacmp、hp的mc serviceguard都是高可用性集群，不能做負載均衡；而高效能集群主要是科學計算、科研等一些特殊環境用，在現實應用中比較少。而oracle 的rac是基於特殊環境下的應用系統，要求有作業系統層面的分布式鎖（dlm)。具體使用起來要作相應的規劃，而且不能隨便使用，弄不好效能適得其反的差。
前面說過，負載均衡不能完全算高可用性集群的一種，是高效能性集群，普通的ha軟體沒辦法支援象oracle rac一樣的環境，這不完全是集群軟體的功能。
高可用性集群與負載均衡集群的工作原理不同，適用於不同型別的服務。通常，負載均衡集群適用於提供靜態資料的服務，如http服務；而高可用性集群既適用於提供靜態資料的服務，如http服務，又適用於提供動態資料的服務，如資料庫等。高可用性集群之所以能適用於提供動態資料的服務，是由於節點共享同一儲存介質，如san陣列。也就是說，在高可用性集群內，每種服務的使用者資料只有乙份，儲存在共用儲存裝置上，在任一時刻只有乙個節點能讀寫這份資料。
高可用性集群對一種服務而言不具有負載均衡功能，它可以提高整個系統的可靠性，但不能增加負載的能力。當然，高可用性集群可以執行多種服務，並適當分配在不同節點上，比如節點a提供oracle服務，同時節點b提供sybase服務，這也可以看成是某種意義上的負載均衡，不過這是對多種服務的分配而言。
負載均衡集群適用於提供相對靜態的資料的服務，比如http服務。因為通常負載均衡集群的各節點間通常沒有共用的儲存介質，使用者資料被複製成多份，存放於每乙個提供該項服務的節點上。
這樣一來，節點a和節點b都是身兼兩職，而使用者同時得到了乙個具有高可用性的oracle服務和乙個具有負載均衡功能的http服務。即使有乙個節點發生故障，oracle服務和http服務都不會因此而中斷。
這裡涉及到乙個關鍵問題：對於同一種服務，是不能同時獲得高可用性與負載均衡能力的（有不同意見的麼？）。對一種服務，要麼是只有乙份資料，放在共用儲存裝置上，一次被乙個節點訪問，獲得高可用性；要麼是把資料複製為多份，儲存於每個節點的本地硬碟上，使用者的請求同時傳送到多個節點上，獲得負載均衡能力。這也是f5裝置沒有提供資料庫均衡的解決方案的難點所在。
引文:－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
首先申明，除了唯讀型資料庫在某些特定條件下可能使用bigip實現負載均衡外。f5迄今未推廣過讀寫型資料庫的負載均衡方案。
資料庫的cluster和ha是兩個概念。在ha方式下，兩台資料庫伺服器只有一台在工作，並且是由active裝置控制盤陣。在發生ha切換時，backup裝置接管盤陣。在cluster狀態下，比如oracle rac，可以實現兩台伺服器對同一盤陣的同時控制，並且使用的是同乙份資料庫檔案。在rac存在的情況下，理論上有可能使用bigip實現負載均衡，但實際上很難發揮作用，只有在c/s結構下有可能實現，或者是多台應用伺服器訪問少量資料庫伺服器的狀況下有可能。現在f5中國還未有進行此類測試，如果那位有此類環境可以做乙個測試。f5會全力支援測試。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
對於高可用性集群，由於它在設計時的目的就是為了最大可能地減少服務中斷時間，因此服務的切換受到很大的關注。當乙個節點上的服務故障時，會被很快地檢測到並被切換到其他節點上。但在切換時，不能忽略對資料完整性的保護。
再研究一下：在什麼情況下資料完整性會被破壞呢？由於高可用性集群中至少有兩個節點，連線在乙個共用的儲存裝置上，對於非裸分割槽而言，如果被兩個節點同時讀寫，就會造成檔案系統被破壞。因此就需要利用i/o屏障來防止這一事件的發生。
i/o屏障的目的是為了保證故障節點不能再繼續讀寫某一服務的共用分割槽，實現的方式有多種。kimberlite使用硬體開關來實現，當乙個節點發生故障時，另一節點如果能偵測到，就會通過序列口發出命令，控制連線在故障節點電源上的硬體開關，通過暫時斷電，而後又上電的方式使得故障節點被重啟動。
i/o屏障有多種形式。對於支援scsi reserve/release命令的儲存裝置，也可以用sg命令實現i/o屏障。正常節點應使用scsi reserve命令「鎖住」共用儲存裝置，保證其不被故障節點讀寫。如果故障節點上的集群軟體仍在執行，如發現共用儲存裝置已被對方鎖住，就應把自己重啟動，以恢復正常工作狀態。
實際上，使用f5裝置有變通的方法：把兩台伺服器放入乙個pool中，設不同的優先順序，讓優先順序高的伺服器對磁碟有讀寫操作，當高優先順序的伺服器宕機時，切到低優先順序的機器上，這也實現了ha， 這有點強詞奪理，但也能解釋，比ha軟體切換的快，因為用ha軟體做雙機時，備機上的各個服務都是宕的，只能當備機探測到主機服務宕機時，才開始啟動相應的服務，有時服務還啟不了；而用f5做雙機時，備機的各服務都是正常啟動著的，只是f5裝置不把客戶請求發到備機上去而已，當主機宕機時，f5裝置才把客戶請求發到備機，而備機的各服務都是正常啟動著的，所以…………
呵呵，想明白了為什麼我說是強詞奪理麼？
如果按照上面的方法作資料庫負載均衡，則必須解決乙個重要的問題：資料庫的同步，如果切換的速度很快，則要求兩台資料庫的同步也很快…………。其它可能還存在一些問題，所以迄今為止還是沒有見過類似結構。
oops，扯遠了。我來詳細說說為什麼高可用集群不能對資料庫系統進行負債均衡。俺的理由是對負債均衡的定義。
就如我開篇所說
引文:－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
集群一般有兩種高可用性和高效能集群，…………負載均衡不能完全算高可用性集群的一種，是高效能性集群
普通的ha軟體沒辦法支援象oracle rac一樣的環境，這不完全是集群軟體的功能。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
我們就拿ops來說事兒吧，ops的核心元件是分布式鎖管理器(dlm)，它為ops例項提供並行快取記憶體管理。ops群集的每個節點在加入群集時都啟動dlm程序的乙個例項，然後這些例項就可以通過網路互相通訊。
然後，ops的工作機制和simon說的沒錯，但是最終，它對庫檔案的讀寫還是靠快取排隊的，最終仍然同一時刻只有一台主機在讀寫。可是，真正的負債均衡是n份檔案的分布式讀取哦。負債均衡是所有資源的均衡哦。
因此我的結論二：即使ha軟體配合ops，仍然不是真正的負債均衡。當然，我們和客戶不能這麼說。
不過，我有乙個想法，在資料庫唯讀的應用環境下，比如高考考分查詢，是不是可以多台機器建多個庫，庫內容都一樣，這樣的話由於不涉及資料同步的問題，應該可以實現真正均衡的。
順便分享一下我查到的ops介紹。總會有人不了解的。
引文:－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
1、什麼是ops
ops(oracle parallel server)可以讓位於不同系統的多個例項同時訪問同乙個資料庫。並行伺服器可以有效地提高系統的可用性和對多系統的訪問效能，但是，如果你的資料沒有做很好的分割，效能可能還會下降。
安裝ops時，多個例項mount同一資料庫檔案，例項間的通訊由分布式鎖管理器（dlm）來管理。需要注意的是分布式鎖管理器與你所使用的硬體和作業系統有著密切的關係。為了確定多個企圖同時修改同一資料的例項，oracle使用了十個後台程序：lck0-lck9，來鎖定某一例項所使用的資源。
ops主要用於unix/linux集群環境中。
3、所有的應用都是適合ops嗎？
可以根據功能或資料進行分割的應用最適合ops。那些有"熱資料"（經常被多例項同時訪問的資料）的應用並不適合使用ops。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
結束語：儘管ha軟體的功能足夠強大，但是我們在系統設計的時候盡量用專用硬體來代替軟體能實現的功能比如f5實現http負債均衡。理由1:利潤更豐厚2:伺服器應該只做單一的伺服器從而最大化利用服務資源3:出現問題便於排錯4：降低使用者的維護成本5：……很多啦，不一一說了
附件：simon寫的ha情況下，資料庫的操作
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
a、在乙個多節點資料庫系統的集群中，是將資料儲存在乙個公用的磁碟空間上的方式來保證資料的統一性的。 而在沒有外來機制的情況下，乙個磁碟空間上的邏輯空間也是只能被乙個主機系統所控制的，即該主機取得了邏輯空間的讀寫控制權後，其他的主機系統是無法再去進行讀寫的（unix/windoes平台均是如此），這是由陣列卡的工作機制所決定的。 而這個時候hacmp軟體（或者其他的集群軟體）出馬了，它通過接管控制陣列卡，協調多個主機的作業系統，使他們可以同時去讀寫同乙個邏輯空間（這裡的同時只是指訪問同乙個邏輯空間，而不是同時乙個資料記錄），這使得多資料庫節點共同處理訪問請求成為可能，因為它們可以讀寫同乙個後台資料庫了。
b、從另乙個方面來說，乙個資料記錄同時只能被乙個i/o操作所控制，即乙個節點上的資料庫系統對資料記錄進行讀寫時，其他的資料庫系統是無法去讀寫該記錄的；而在乙個多節點的資料庫集群中，這就需要對資料記錄進行協作、控制，即保證該記錄在被乙個i/o讀寫時必須被縮定，禁止其他的資料庫對它進行讀寫，而當該i/o操作完成時必須能釋放掉該資料記錄，使之能被其他的資料庫系統讀寫。 這點顯然是nlb所不能實現的，是需要資料庫系統本身的功能支援（主流的資料庫oracle/sql/sybase均可實現該功能）。而這點實現了多節點資料庫系統間的共同協作處理，也保證了多節點資料庫系統的處理能力均衡分載的應用層基礎。
在以上2點的保證下，通過hacmp集群軟體對外提供同乙個公用ip位址（serviceip）接受訪問請求，由資料庫系統的集群元件將請求分配給各個節點上的資料庫系統，並協調他們進行後台資料的讀寫，真正的實現了資料庫系統的處理能力上的負載分擔、均衡。
資料庫負載均衡（上）
雖然搭建了集群,但是不使用資料庫負載均衡,單節點處理所有請求，負載高，效能差 使用haproxy做負載均衡，請求被均勻分發給每個節點，單節點負載低，效能好 1.安裝haproxy映象 從docker倉庫拉取haproxy映象 docker pull haproxy2.建立haproxy配置檔案 ha...
資料庫負載均衡（下）
單節點haproxy不具備高可用,必須要有冗餘設計 雙機就是兩個請求處理程式，比如兩個haproxy，當乙個掛掉的時候，另外 乙個可以頂上。linux系統可以在乙個網絡卡中定義多個ip位址，把這些位址分配給多個應用程式，這些位址就是虛擬ip，haproxy的雙機熱備方案最關鍵的技術就是虛擬ip。定義...
關於集群資料負載均衡
一 環境 1 hadoop 0.20.2 2 作業系統 linux 二 關於負載均衡 1 一般情況下，資料在錄入集群的時候就進行負載均衡，根據各個節點的情況來做資料平衡分發存放。2 但是如果在新增節點之後，如果想做到負載均衡則需要使用balancer的命令。對於這個命令，一般是有乙個閥值，預設是10...