資料庫集群負載均衡
A. 資料庫集群 應該
集群主要分成三大類 (高可用集群, 負載均衡集群,科學計算集群)
高可用集群( High Availability Cluster)
負載均衡集群(Load Balance Cluster)
科學計算集群(High Performance Computing Cluster)
1、高可用集群(High Availability Cluster)
常見的就是2個節點做成的HA集群,有很多通俗的不科學的名稱,比如」雙機熱備」, 「雙機互備」, 「雙機」。高可用集群解決的是保障用戶的應用程序持續對外提供服務的能力。 (請注意高可用集群既不是用來保護業務數據的,保護的是用戶的業務程序對外不間斷提供服務,把因軟體/硬體/人為造成的故障對業務的影響降低到最小程度)。
2、負載均衡集群(Load Balance Cluster)
負載均衡系統:集群中所有的節點都處於活動狀態,它們分攤系統的工作負載。一般Web伺服器集群、資料庫集群和應用伺服器集群都屬於這種類型。
負載均衡集群一般用於相應網路請求的網頁伺服器,資料庫伺服器。這種集群可以在接到請求時,檢查接受請求較少,不繁忙的伺服器,並把請求轉到這些伺服器上。從檢查其他伺服器狀態這一點上看,負載均衡和容錯集群很接近,不同之處是數量上更多。
3、科學計算集群(High Performance Computing Cluster)
高性能計算(High Perfermance Computing)集群,簡稱HPC集群。這類集群致力於提供單個計算機所不能提供的強大的計算能力。
高性能計算分類:
3.1、高吞吐計算(High-throughput Computing)
有一類高性能計算,可以把它分成若干可以並行的子任務,而且各個子任務彼此間沒有什麼關聯。象在家搜尋外星人( SETI@HOME – Search for Extraterrestrial Intelligence at Home )就是這一類型應用。
這一項目是利用Internet上的閑置的計算資源來搜尋外星人。SETI項目的伺服器將一組數據和數據模式發給Internet上參加SETI的計算節點,計算節點在給定的數據上用給定的模式進行搜索,然後將搜索的結果發給伺服器。伺服器負責將從各個計算節點返回的數據匯集成完整的 數據。因為這種類型應用的一個共同特徵是在海量數據上搜索某些模式,所以把這類計算稱為高吞吐計算。
所謂的Internet計算都屬於這一類。按照 Flynn的分類,高吞吐計算屬於SIMD(Single Instruction/Multiple Data)的范疇。
3.2、分布計算(Distributed Computing)
另一類計算剛好和高吞吐計算相反,它們雖然可以給分成若干並行的子任務,但是子任務間聯系很緊密,需要大量的數據交換。按照Flynn的分類,分布式的高性能計算屬於MIMD(Multiple Instruction/Multiple Data)的范疇。
下面說說這幾種集群的應用場景:
高可用集群這里不多作說明。
想Dubbo是比較偏向於負載均衡集群,用過的猿友應該知道(不知道的可以自行了解一下),Dubbo同一個服務是可以有多個提供者的,當一個消費者過來,它要消費那個提供者,這里是有負載均衡機制在裡面的。
搜索引擎Elasticsearch比較偏向於科學計算集群的分布計算。
而到這里,可能不少猿友都知道,集群的一些術語:集群容錯、負載均衡。
我們以Dubbo為例:
集群容錯(http://bbo.io/User+Guide-zh.htm#UserGuide-zh-%E9%9B%86%E7%BE%A4%E5%AE%B9%E9%94%99)
Dubbo提供了這些容錯策略:
集群容錯模式:
可以自行擴展集群容錯策略,參見:集群擴展
Failover Cluster
失敗自動切換,當出現失敗,重試其它伺服器。(預設)
通常用於讀操作,但重試會帶來更長延遲。
可通過retries="2"來設置重試次數(不含第一次)。
Failfast Cluster
快速失敗,只發起一次調用,失敗立即報錯。
通常用於非冪等性的寫操作,比如新增記錄。
Failsafe Cluster
失敗安全,出現異常時,直接忽略。
通常用於寫入審計日誌等操作。
Failback Cluster
失敗自動恢復,後台記錄失敗請求,定時重發。
通常用於消息通知操作。
Forking Cluster
並行調用多個伺服器,只要一個成功即返回。
通常用於實時性要求較高的讀操作,但需要浪費更多服務資源。
可通過forks="2"來設置最大並行數。
Broadcast Cluster
廣播調用所有提供者,逐個調用,任意一台報錯則報錯。(2.1.0開始支持)
通常用於通知所有提供者更新緩存或日誌等本地資源信息。
負載均衡(http://bbo.io/User+Guide-zh.htm#UserGuide-zh-%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1)
Dubbo提供了這些負載均衡策略:
Random LoadBalance
隨機,按權重設置隨機概率。
在一個截面上碰撞的概率高,但調用量越大分布越均勻,而且按概率使用權重後也比較均勻,有利於動態調整提供者權重。
RoundRobin LoadBalance
輪循,按公約後的權重設置輪循比率。
存在慢的提供者累積請求問題,比如:第二台機器很慢,但沒掛,當請求調到第二台時就卡在那,久而久之,所有請求都卡在調到第二台上。
LeastActive LoadBalance
最少活躍調用數,相同活躍數的隨機,活躍數指調用前後計數差。
使慢的提供者收到更少請求,因為越慢的提供者的調用前後計數差會越大。
ConsistentHash LoadBalance
一致性Hash,相同參數的請求總是發到同一提供者。
當某一台提供者掛時,原本發往該提供者的請求,基於虛擬節點,平攤到其它提供者,不會引起劇烈變動。
演算法參見:http://en.wikipedia.org/wiki/Consistent_hashing。
預設只對第一個參數Hash,如果要修改,請配置<bbo:parameter key="hash.arguments" value="0,1" />
預設用160份虛擬節點,如果要修改,請配置<bbo:parameter key="hash.nodes" value="320" />
B. 集群、負載均衡與分布式有什麼區別
集群、負載均衡與分布式的區別:
1、Linux集群主要分成三大類( 高可用集群, 負載均衡集群,科學計算集群)(下面只介紹負載均衡集群)
負載均衡集群(Load Balance Cluster)
負載均衡系統:集群中所有的節點都處於活動狀態,它們分攤系統的工作負載。一般Web伺服器集群、資料庫集群和應用伺服器集群都屬於這種類型。
負載均衡集群一般用於相應網路請求的網頁伺服器,資料庫伺服器。這種集群可以在接到請求時,檢查接受請求較少,不繁忙的伺服器,並把請求轉到這些伺服器上。從檢查其他伺服器狀態這一點上看,負載均衡和容錯集群很接近,不同之處是數量上更多。
2、負載均衡系統: 負載均衡又有DNS負載均衡(比較常用)、IP負載均衡、反向代理負載均衡等,也就是在集群中有伺服器A、B、C,它們都是互不影響,互不相乾的,任何一台的機器宕了,都不會影響其他機器的運行,當用戶來一個請求,有負載均衡器的演算法決定由哪台機器來處理,假如你的演算法是採用round演算法,有用戶a、b、c,那麼分別由伺服器A、B、C來處理;
3、分布式是指將不同的業務分布在不同的地方。
而集群指的是將幾台伺服器集中在一起,實現同一業務。
分布式中的每一個節點,都可以做集群。
而集群並不一定就是分布式的。
舉例:就比如新浪網,訪問的人多了,他可以做一個群集,前面放一個響應伺服器,後面幾台伺服器完成同一業務,如果有業務訪問的時候,響應伺服器看哪台伺服器的負載不是很重,就將給哪一台去完成。
而分布式,從窄意上理解,也跟集群差不多, 但是它的組織比較鬆散,不像集群,有一個組織性,一台伺服器垮了,其它的伺服器可以頂上來。
分布式的每一個節點,都完成不同的業務,一個節點垮了,哪這個業務就不可訪問了。
C. 伺服器如何實現集群和負載均衡
很多組織機構慢慢的在不同的伺服器和地點部署sql
server資料庫——為各種應用和目的——開始考慮通過sql
server集群的方式來合並。
將sql
server實例和資料庫合並到一個中心的地點可以減低成本,尤其是維護和軟硬體許可證。此外,在合並之後,可以減低所需機器的數量,這些機器就可以用於備用。
當尋找一個備用,比如高可用性的環境,企業常常決定部署microsoft的集群架構。我常常被問到小的集群(由較少的節點組成)sql
server實例和作為中心解決方案的大的集群哪一種更好。在我們比較了這兩個集群架構之後,我讓你們自己做決定。
什麼是microsoft集群伺服器
mscs是一個windows
server企業版中的內建功能。這個軟體支持兩個或者更多伺服器節點連接起來形成一個「集群」,來獲得更高的可用性和對數據和應用更簡便的管理。mscs可以自動的檢查到伺服器或者應用的失效,並從中恢復。你也可以使用它來(手動)移動伺服器之間的負載來平衡利用率以及無需停機時間來調度計劃中的維護任務。
這種集群設計使用軟體「心跳」來檢測應用或者伺服器的失效。在伺服器失效的事件中,它會自動將資源(比如磁碟和ip地址)的所有權從失效的伺服器轉移到活動的伺服器。注意還有方法可以保持心跳連接的更高的可用性,比如站點全面失效的情況下。
mscs不要求在客戶計算機上安裝任何特殊軟體,因此用戶在災難恢復的經歷依賴於客戶-伺服器應用中客戶一方的本質。客戶的重新連接常常是透明的,因為mscs在相同的ip地址上重啟應用、文件共享等等。進一步,為了災難恢復,集群的節點可以處於分離的、遙遠的地點。
在集群伺服器上的sql
server
sql
server
2000可以配置為最多4個節點的集群,而sql
server
2005可以配置為最多8個節點的集群。當一個sql
server實例被配置為集群之後,它的磁碟資源、ip地址和服務就形成了集群組來實現災難恢復。
sql
server
2000允許在一個集群上安裝16個實例。根據在線幫助,「sql
server
2005在一個伺服器或者處理器上可以支持最多50個sql
server實例,」但是,「只能使用25個硬碟驅動器符,因此如果你需要更多的實例,那麼需要預先規劃。」
注意sql
server實例的災難恢復階段是指sql
server服務開始所需要的時間,這可能從幾秒鍾到幾分鍾。如果你需要更高的可用性,考慮使用其他的方法,比如log
shipping和資料庫鏡像。
單個的大的sql
server集群還是小的集群
下面是大的、由更多的節點組成的集群的優點:
◆更高的可用新(更多的節點來災難恢復)。
◆更多的負載均衡選擇(更多的節點)。
◆更低廉的維護成本。
◆增長的敏捷性。多達4個或者8個節點,依賴於sql版本。
◆增強的管理性和簡化環境(需要管理的少了)。
◆更少的停機時間(災難恢復更多的選擇)。
◆災難恢復性能不受集群中的節點數目影響。
下面是單個大的集群的缺點:
◆集群節點數目有限(如果需要第9個節點怎麼辦)。
◆在集群中sql實例數目有限。
◆沒有對失效的防護——如果磁碟陣列失效了,就不會發生災難恢復。
◆使用災難恢復集群,無法在資料庫級別或者資料庫對象級別,比如表,創建災難恢復集群。
虛擬化和集群
虛擬機也可以參與到集群中,虛擬和物理機器可以集群在一起,不會發生問題。sql
server實例可以在虛擬機上,但是性能可能會受用影響,這依賴於實例所消耗的資源。在虛擬機上安裝sql
server實例之前,你需要進行壓力測試來驗證它是否可以承受必要的負載。
在這種靈活的架構中,如果虛擬機和物理機器集群在一起,你可以在虛擬機和物理機器之間對sql
server進行負載均衡。比如,使用虛擬機上的sql
server實例開發應用。然後在你需要對開發實例進行壓力測試的時候,將它災難恢復到集群中更強的物理機器上。
集群伺服器可以用於sql
server的高可用性、災難恢復、可擴展性和負載均衡。單個更大的、由更多的節點組成的集群往往比小的、只有少數節點的集群更好。大個集群允許更靈活環境,為了負載均衡和維護,實例可以從一個節點移動到另外的節點。
D. 如何實現mssql資料庫負載均衡
SQL Server 負載均衡集群
一個應用系統隨著業務量的提高,以及訪問量和數據流量的快速增長,各個核心部分的處理性能和計算強度也相應增大,使得單一設備根本無法承擔。在此情況下,如果扔掉現有設備去做大量的硬體升級,必將造成現有資源的浪費,而且下一次業務量的提升,又將導致再一次硬體升級的高額成本投入。於是,負載均衡機制應運而生。 對於應用系統的負載均衡的硬體和軟體比比皆是,因為應用伺服器上的程序基本上認為是不變化的,而且一般的各個應用伺服器上的程序是不交互的。因此應用伺服器的負載均衡非常好做,只需要能夠進行分流的軟體或者硬體把多個客戶端的連接分配到多個應用伺服器上去即可。
因為資料庫內的數據是頻繁變化的,為了數據的一致性以及鎖資源的分配協調等,所以像應用伺服器那樣只有分流是不夠的,各個節點需要頻繁的交互。這也是資料庫集群軟體難做的原因,當然也是賣的貴的原因了。
Oracle Real Application Clusters
對於資料庫負載均衡,大家最為耳熟能詳的就是Oracle RAC了。RAC是雙機並行伺服器(8i及以前版本稱作Oracle Parallel Server,OPS),用來在集群環境下實現多機共享資料庫,以保證應用的高可用性,同時可以自動實現並行處理及均分負載,還能實現資料庫在故障時的排錯和無斷點恢復。它可以自動進行負載平衡、故障修復和規劃停機時間,以支持高可用性應用程序。若並行伺服器中某節點失效,透明的應用程序容錯能夠把用戶自動轉接到另一節點上繼續運行,應用程序在用戶沒有察覺的情況下繼續執行。這使周期性和非周期性發生故障的系統增大了連續可用性。進程的失效可以完全透明地轉移到另一節點上去,通過適當地配置,可以指定所有查詢都在客戶端進行緩存,這樣它們便可以在轉移後的節點上重新設置。
Moebius for SQL Server
截至到SQL Server 2008,微軟還是沒有推出負載均衡組件,只能靠第三方軟體來實現,好在這個軟體是幾個從微軟出來的人寫的,也算是個小小的巧合。說他們是微軟出來的並不是說他們的技術多厲害,而是他們利用SQL Server的一些內部介面把集群做的非常透明, 無論是應用程序的調用還是開發/管理人員的使用都和面對一個資料庫一樣。
他們的實現原理是這樣的:和SQL Server鏡像一樣,每個資料庫節點都有自己的數據,也就是無共享磁碟架構。他們稱之為「中間件」的程序宿主在資料庫的內部,每個節點資料庫上寫入數據導致數據變化時,SQL Server會激活「中間件」,「中間件」把變化的數據同步到其他的節點上。其他節點發生變化也是一樣。因為「中間件」宿主在資料庫內, 所以它能夠把每個同步的Session和SQL Server的Session綁定到一起,也就是使用戶的執行和數據的同步成為一個原子操作,從而保證數據在每時每刻都是一致的。因此查詢可以隨便到每個機器上去查,從而做到了真正的負載均衡。
這是一種叫"資料庫路由器"的技術,這種技術的特點是靈活性好,但效率比RAC要低,畢竟RAC是在引擎里實現的不管怎麼樣有比沒有強!
E. 怎樣實現資料庫負載均衡集群
集群系統的概要
現在的計算機社會中,持續的提供不停止的服務已經成為通往成功的關鍵。例如僅由於 1
台機器故障或超負荷而宕機就導致對客戶的服務全面停止。這樣的話,不但會帶來莫大的
損失,還會失去客戶的信任。
隨著集群系統的導入,發生意外事故時會將系統停止時間(宕機時間)降低到最小限度、使
負載均衡,提高其可用性。
所謂集群,有「集團」、「團」的意思,顧名思義是「將多個計算機匯集成一群(或者多群),謀求
提升可靠性及處理性能的系統」。集群系統有多個種類,可分為下列3 種。其中,
NEC ExpressCluster 屬於High Availability 集群。
HA (High Availability) 集群
是平時作為運行伺服器作業,在運行伺服器發生故障時將業務交接到待機伺服器的集
群。是以高可用性為目的的集群。包括共享磁碟型、鏡像磁碟型。
負載均衡集群
是將客戶端的請求遵從恰當的負荷均衡原則分配給各節點的集群。是以高擴展性為目
的的集群、一般無法進行數據交接。包括load balance 集群、並列資料庫集群。
HPC (High Performance Computing)集群
是指計算量非常大的集群。是為使用超級計算機執行單一業務的集群。使用所有節點
的CPU 來執行單一業務的網格計算技術近年來已成為熱點。
F. SQLSERVER怎麼搭建伺服器集群實現負載均衡
很多組織機構慢慢的在不同的伺服器和地點部署SQL Server資料庫——為各種應用和目的——開始考慮通過SQL Server集群的方式來合並。
將SQL Server實例和資料庫合並到一個中心的地點可以減低成本,尤其是維護和軟硬體許可證。此外,在合並之後,可以減低所需機器的數量,這些機器就可以用於備用。
當尋找一個備用,比如高可用性的環境,企業常常決定部署Microsoft的集群架構。我常常被問到小的集群(由較少的節點組成)SQL Server實例和作為中心解決方案的大的集群哪一種更好。在我們比較了這兩個集群架構之後,我讓你們自己做決定。
什麼是Microsoft集群伺服器
MSCS是一個Windows Server企業版中的內建功能。這個軟體支持兩個或者更多伺服器節點連接起來形成一個「集群」,來獲得更高的可用性和對數據和應用更簡便的管理。MSCS可以自動的檢查到伺服器或者應用的失效,並從中恢復。你也可以使用它來(手動)移動伺服器之間的負載來平衡利用率以及無需停機時間來調度計劃中的維護任務。
這種集群設計使用軟體「心跳」來檢測應用或者伺服器的失效。在伺服器失效的事件中,它會自動將資源(比如磁碟和IP地址)的所有權從失效的伺服器轉移到活動的伺服器。注意還有方法可以保持心跳連接的更高的可用性,比如站點全面失效的情況下。
MSCS不要求在客戶計算機上安裝任何特殊軟體,因此用戶在災難恢復的經歷依賴於客戶-伺服器應用中客戶一方的本質。客戶的重新連接常常是透明的,因為MSCS在相同的IP地址上重啟應用、文件共享等等。進一步,為了災難恢復,集群的節點可以處於分離的、遙遠的地點。
在集群伺服器上的SQL Server
SQL Server 2000可以配置為最多4個節點的集群,而SQL Server 2005可以配置為最多8個節點的集群。當一個SQL Server實例被配置為集群之後,它的磁碟資源、IP地址和服務就形成了集群組來實現災難恢復。
SQL Server 2000允許在一個集群上安裝16個實例。根據在線幫助,「SQL Server 2005在一個伺服器或者處理器上可以支持最多50個SQL Server實例,」但是,「只能使用25個硬碟驅動器符,因此如果你需要更多的實例,那麼需要預先規劃。」
注意SQL Server實例的災難恢復階段是指SQL Server服務開始所需要的時間,這可能從幾秒鍾到幾分鍾。如果你需要更高的可用性,考慮使用其他的方法,比如log shipping和資料庫鏡像。
單個的大的SQL Server集群還是小的集群
下面是大的、由更多的節點組成的集群的優點:
◆更高的可用新(更多的節點來災難恢復)。
◆更多的負載均衡選擇(更多的節點)。
◆更低廉的維護成本。
◆增長的敏捷性。多達4個或者8個節點,依賴於SQL版本。
◆增強的管理性和簡化環境(需要管理的少了)。
◆更少的停機時間(災難恢復更多的選擇)。
◆災難恢復性能不受集群中的節點數目影響。
下面是單個大的集群的缺點:
◆集群節點數目有限(如果需要第9個節點怎麼辦)。
◆在集群中SQL實例數目有限。
◆沒有對失效的防護——如果磁碟陣列失效了,就不會發生災難恢復。
◆使用災難恢復集群,無法在資料庫級別或者資料庫對象級別,比如表,創建災難恢復集群。
虛擬化和集群
虛擬機也可以參與到集群中,虛擬和物理機器可以集群在一起,不會發生問題。SQL Server實例可以在虛擬機上,但是性能可能會受用影響,這依賴於實例所消耗的資源。在虛擬機上安裝SQL Server實例之前,你需要進行壓力測試來驗證它是否可以承受必要的負載。
在這種靈活的架構中,如果虛擬機和物理機器集群在一起,你可以在虛擬機和物理機器之間對SQL Server進行負載均衡。比如,使用虛擬機上的SQL Server實例開發應用。然後在你需要對開發實例進行壓力測試的時候,將它災難恢復到集群中更強的物理機器上。
集群伺服器可以用於SQL Server的高可用性、災難恢復、可擴展性和負載均衡。單個更大的、由更多的節點組成的集群往往比小的、只有少數節點的集群更好。大個集群允許更靈活環境,為了負載均衡和維護,實例可以從一個節點移動到另外的節點。
G. 對於實現mysql資料庫集群負載均衡和高可使用 哪些措施具有實際意義
本文我們主要介紹了MySQL資料庫集群實現負載均衡的安裝配置工作,接下來我們就讓我們一起來了解一下這部分內容。
MySQL資料庫集群關系如下圖:
ndbd:資料庫節點,物理數據實際存放位置。
mysqld:MySQL伺服器節點。
ndbd_mgmd:管理節點。管理/查看各庫節點和伺服器節點的狀態。程序直接訪問的是這台機器的IP。默認埠仍是3306。
1.在ndb_mgmd、mysqld、Node
A、Node
B上安裝MySQL5.0
安裝目錄:/usr/local/mysql
2.配置
Node
A、Node
B、mysqld:
#
cp
/usr/local/mysql/support-files/my-medium.cnf
/etc/my.cnf
#
vi
/etc/my.cnf
在文件尾加入
#
my.cnf
#
example
additions
to
my.cnf
for
MySQL
Cluster
#
(valid
in
MySQL
5.0)
#
enable
ndbcluster
storage
engine,
and
provide
connectstring
for
#
management
Server
host
(default
port
is
1186)
[mysqld]
ndbcluster
ndb-connectstring=192.168.56.30
#
provide
connectstring
for
management
Server
host
(default
port:
1186)
[ndbd]
connect-string=192.168.56.30
#
provide
connectstring
for
management
Server
host
(default
port:
1186)
[ndb_mgm]
connect-string=192.168.56.30
#
provide
location
of
cluster
configuration
file
[ndb_mgmd]
config-file=/var/lib/mysql-cluster
在Node
A、Node
B上創建日誌文件夾
H. 什麼是資料庫負載均衡
負載均衡集群是由一組相互獨立的計算機系統構成,通過常規網路或專用網路進行連接,由路由器銜接在一起,各節點相互協作、共同負載、均衡壓力,對客戶端來說,整個群集可以視為一台具有超高性能的獨立伺服器。
I. mysql集群 如何做負載均衡
它們是按SMP、NUMA、MPP、集群、分布處理從最緊密到最鬆散的排列。
SMP(多處理系統):這種系統是在一台計算機里有多個CPU,CPU之間的地位是平等的,它們共享內存空間和I/O設備。其工作方法是由操作系統負責將任務分解成多個並發進程,然後讓其在不同的CPU上運行。
NUMA(非統一內存存取):這種系統可以讓多處理計算機的CPU比SMP更高效地共享本地內存,CPU可以更快速地存取單一的內存區域,不過如需要也可以用間接方式存取其他區域的內存,這種方法是讓某些CPU在給定范圍的物理內存中有更大的優先使用權。
MPP(巨型並行處理):這種系統的節點都有自己的CPU,並有自己的專有資源。此種結構相對獨立,但各個節點一般沒有完全存取I/O的能力。
集群:集群系統是由獨立的計算機組成,但有控制管理工具統一管理。
分布處理:它是比我們要構築的集群系統更鬆散的連接,一般是任務在不同的地方完成,沒有可以作為整體管理的單一實體。
以上的聚合方式有緊有疏,它們都有自己的適用范圍,這里就不多說了,有興趣可自己找些資料看,這里只是想讓大家了解它所處的位置。
實現負載均衡的方法
集群的目的是共享和高效地利用資源,提供大型運算,提供負載均衡分配請求壓力以及出現故障時能夠進行切換實現高可用性。
限於篇幅,本文只對負載均衡的實現做些介紹(針對TurboLinux Cluster Server)。通過對相關軟體的分析,實現集群負載的功能是通過流量管理實現的,具體有這樣幾種實現方法:直接路由(Direct forwarding)、網路地址轉換(NAT)、隧道技術(Tunneling)。
直接路由(Direct forwarding)
當參與集群的計算機和作為控制管理的計算機在同一個網段時可以用此法,控制管理的計算機接收到請求包時直接送到參與集群的節點。優點是返回給客戶的流量不經過控制主機,速度快開銷少。
網路地址轉換(NAT)
這種方法可能大家較熟悉,地址轉換器有能被外界訪問到的合法IP地址,它修改來自專有網路的流出包的地址,外界看起來包是來自地址轉換器本身,當外界包送到轉換器時,它能判斷出應該將包送到內部網的哪個節點。優點是節省IP地址,能對內部進行偽裝;缺點是效率低,因為返回給請求方的流量經過轉換器。
隧道技術(Tunneling)
這種方式是在集群的節點不在同一個網段時可用的轉發機制,是將IP包封裝在其他網路流量中的方法,為了安全的考慮,應該使用隧道技術中的VPN,也可使用租用專線。
集群所能提供的服務是基於TCP/IP的Web服務、Mail服務、News服務、DNS服務、Proxy伺服器等等,下面我們將就具體的產品TurboLinux Cluster Server 來實現一個進行負載均衡集群系統,用於提供Web和ftp的服務。四台伺服器的負載均衡實例
所提供的服務:Web、FTP。
系統的實現目的:做一個較完善負載均衡的系統,以便能用到其中的較多的功能。
採用設備狀況:使用四台伺服器,其中3台裝TurboLinux Cluster Server,1台安裝Windows 2000 Sever。系統安裝1.在兩台伺服器上安裝TurboLinux, apache和wu-ftpd也要安裝,因為集群要提供這種服務,安裝完後重啟,掛接光碟機在目錄/mnt/cdrom下,執 行./TLCS-install,然後按提示完全安裝。