伺服器如何做負載均衡

㈠ 網維大師如何開啟伺服器之間負載均衡功能

1.批量選中需要開啟負載均衡功能的客戶機，然後點擊右鍵=》修改。
註：必須有2台或2台以上系統虛擬盤伺服器時，才能使用伺服器負載均衡功能，而該功能默認開啟。
2.在批量修改客戶機界面中的左下角首選伺服器下拉框中，可以選擇是否進行伺服器「自動負載均衡」。
選擇「<自動負載均衡>」時，客戶機即啟用了伺服器間負載均衡功能。
選擇具體的某一台伺服器時，則不啟用自動負載均衡功能。
網管、網吧技術員、網吧維護團隊賺錢：-------

㈡ 怎樣利用緩存伺服器來負載均衡

根據一些專家的調查分析，發現企業在使用資料庫的時候，90%以上主要用來查詢。有些企業這個比例甚至更高。也就說，用戶對資料庫的操作，其實更新操作占的比例很少。大部分的操走都只是查詢操作。
如一些論壇，大部分用戶只會看貼，而不會發帖。這就是一個典型的查詢操作比例大大超過更新操作比例的例子。針對這種情況，其查詢操作往往是其資料庫性能的瓶頸。如何有效提高查詢的性能，這就使各個資料庫專家在考慮的問題。在SQL Server資料庫中，已經有了一個現成的解決方案。資料庫管理員可以利用緩存伺服器來提高資料庫的性能。筆者這里就以SQLServer2008為例，談談如何利用緩存伺服器來實現負載均衡，來提高資料庫的查詢效率。
一、 數據查詢與數據更新分開走。
如上圖所示，如果用戶要查看某個帖子，其就會打開某個連接。此時WEB應用伺服器就會從後台資料庫中查詢相關的記錄。這里需要注意的是，由於其只是查看帖子，而不涉及到更新的操作，為此WEB應用伺服器就只從緩存伺服器中讀取數據。這個緩存伺服器中的記錄跟資料庫伺服器的內容是同步的。WEB應用伺服器在從資料庫緩存伺服器讀取數據之前，還會先判斷一下哪台資料庫伺服器比較空。會優先連接到比較空閑的數據緩存伺服器中，然後從這台伺服器中讀取數據。所以，當訪問這個論壇的用戶比較多時，這個數據緩存伺服器能夠實現負載均衡的需要。
如果用戶看了某個帖子，現在需要發表一個評論，此時後台資料庫會怎麼操作呢?注意，當WEB應用伺服器發送了一個 Update更新操作的時候，其應用伺服器會自動連接到資料庫伺服器，而不會再連接到資料庫緩存伺服器。而是直接向資料庫伺服器發送更新操走的語句。當資料庫伺服器更新了相關的內容之後，會與資料庫緩存伺服器實現數據的同步。從上圖中可以看出，整個數據查詢與數據更新WEB應用伺服器是分兩條路走。其實這就好像是公路上分道行駛，機動車走機動車道;非機動車走非機動車道。
如此的話，就不會因為非機動車比較慢，而影響到機動車的速度。在這個方案中，將資料庫的更新操作與查詢操作分開來走，也是類似的道理。在查詢時，數據流是單向流動的，所以能夠在很大程度上提高查詢的效率。從而讓數據負載均衡的效果更加明顯。總之，當某個應用程序查詢操作大大超過更新操作時，通過在多個資料庫間緩存只讀數據，並在資料庫間均勻連接客戶端以分發負載，則就可以向外擴展工作負荷的讀取分區，即實現負載均衡的目的。
二、 採用這個方案需要注意的地方。
在部署這個解決方案時，仍然有些資料庫管理員需要關注的內容。如以下這些內容，資料庫管理員需要根據企業的實際情況來進行調整，以提高這個方案的價值。
首先需要考慮數據緩存伺服器與資料庫伺服器之間同步的頻率問題。這個同步操作是一把雙刃劍。若同步的頻率太高，會影響資料庫伺服器與緩存伺服器的性能;若同步頻率比較低的話，則資料庫緩存伺服器中的數據得不到及時的更新。
如此的話，用戶查詢時可能在短時間內無法獲取最新的數據。所以，一般來說，系統滯後的時間應該盡量的短，即資料庫伺服器的更新內容必須盡快與資料庫緩存伺服器進行同步。
理想的狀態時，在更新資料庫伺服器的同時更新資料庫緩存伺服器。但是，這么做是以犧牲資料庫與資料庫緩存伺服器的性能為代價的。為此資料庫管理員在實施這個解決方案時，往往不會這么做。而是設置在一段時間之後同步。如可以設置為10秒、60秒、300秒或者更長的時間後進行同步。
具體這個同步的時間間隔多少為好，沒有一個統一的標准。這需要資料庫管理員根據企業對數據同步的要求不同而定。一般來說，資料庫管理員在滿足用戶需要的前期下，可以將這個時間設置的相對長一點。這可以避免因為過多的同步操作而降低了這個方案的價值。其實，對於大部分用戶來說，60秒左右的時間差異還是可以接受的。如在論壇中，一個人發帖後，在一分鍾之後看到一般不會有什麼問題。對於人的感覺來說，這個一分鍾時間不長。但是對於資料庫伺服器來說，這一分鍾可以做很多事情。所以，適當延長這個同步時間，卻可以在很大程度上提高資料庫伺服器性能。這個時間的代價，有時候還是值得的。
其次，在資料庫伺服器與資料庫緩存伺服器之間，應該建立比較直接的、快速的網路連接。當用戶比較多時，資料庫伺服器與資料庫緩存伺服器之間若發生同步操作，則會造成很多的網路流量。有時候同步操作發生時，影響這個工作的效率可能並不是資料庫伺服器或者資料庫緩存伺服器本身，而是他們之間的網路連接。
由於其可用的帶寬跟不少資料庫伺服器系統的吞吐量，從而影響到了同步操作的效率。為此，在資料庫伺服器與資料庫緩存伺服器之間的網路連接，應該盡量的直接。如最好不要在中間夾著其他的不必要的網路設備;也最好不要在他們之間配備防火牆等安全策略。這些安全策略與網路設備都會在很大程度上影響到這個同步操作的效率。
另外，最好也不要有其他的應用服務來爭搶帶寬。所以簡單的說，如果可能的話，在資料庫伺服器上部署多張網卡，直接與資料庫源伺服器實現雙機互聯，而那傳輸同步操作需要的數據，這是一個很不錯的手段。由於其數據傳輸更直接、而且其他設備或者應用服務也會來爭奪其帶寬，同時又可以克服他們的非法攻擊。為此，只要他們之間多距離比較短的話，採用這種方案可能效果會比較好，可以在最大程度內縮短這個同步操作所需要的時間，從而讓其他用戶盡早看到更新的數據。
第三為同步選擇合適的復制方案。
那麼該如何實現資料庫伺服器與緩存伺服器之間的同步呢?在SQLServer資料庫中，有三個方案可供資料庫管理員選擇。這三個方案分別為快照復制、合並復制與事務復制。這三個復制模型各有各的特點。不過從最終效果來看，其都可以實現資料庫伺服器與資料庫緩存伺服器之間的同步。不過由於其內部的實現機制不同，為此其雖然結果相同，但是從性能等方面考慮，還是有差異的。
各種復制模型的原理與特點屬於基本知識的范疇，筆者在這里就不做過多闡述了。筆者認為，在利用這個資料庫緩存伺服器來實現負載均衡的方案中，最好採用事務復制的同步方案。因為相比其他方案來說，事務日誌能夠滿足事務的一致性、資料庫伺服器系統比較大的吞吐量、同步時盡量少的開銷、以及系統比較短的滯後時間等等需求。
另外在有些企業中採用這個方案的話，還要考慮到表與記錄的過濾需求。而通過事務復制的話，就可以實現對列和行的過濾。而其他復制模型的話，只能夠部分滿足這些需求。
所以，筆者認為，在選擇數據同步方案時，可能選擇事務復制來實現同步，更加的合適。不過最終是否真是如此，還是要求資料庫管理員根據企業的實際需要，然後分別採用幾個復制模型來進行測試，才能夠得出真正合理的結果。

㈢ 想做伺服器的負載均衡 都有哪些方式

最常見的一種方法,是在同一個機房的同一機櫃上面租用多台機器.並把網站的資料庫和頁面分開.把資料庫放在單獨的一台高配置伺服器上面.把網站前端頁面復製成多份.放在不同的其他幾台機器上面.然後用DNSPOD解析.把一個域名解析指向多個不同伺服器的IP.這樣就可以實現多台伺服器負載均衡的功能.而且相對比較簡單.
海騰數據楊闖為你解答.個人建議.希望對你有幫助.

㈣ 負載均衡是怎麼做的~

1、服務直接返回：這種安裝方式負載均衡的LAN口不使用，WAN口與伺服器在同一個網路中，互聯網的客戶端訪問負載均衡的虛IP（VIP），虛IP對應負載均衡機的WAN口，負載均衡根據策略將流量分發到伺服器上，伺服器直接響應客戶端的請求。

2、橋接模式：橋接模式配置簡單，不改變現有網路。負載均衡的WAN口和LAN口分別連接上行設備和下行伺服器。LAN口不需要配置IP（WAN口與LAN口是橋連接），所有的伺服器與負載均衡均在同一邏輯網路中。

3、路由模式：路由模式的部署方式，伺服器的網關必須設置成負載均衡機的LAN口地址，且與WAN口分署不同的邏輯網路。因此所有返回的流量也都經過負載均衡。這種方式對網路的改動小，能均衡任何下行流量。

(4)伺服器如何做負載均衡擴展閱讀

負載均衡的演算法:

1、隨機演算法：Random隨機，按權重設置隨機概率。在一個截面上碰撞的概率高，但調用量越大分布越均勻，而且按概率使用權重後也比較均勻，有利於動態調整提供者權重。

2、哈希演算法：一致性哈希一致性Hash，相同參數的請求總是發到同一提供者。當某一台提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。

3、URL散列：通過管理客戶端請求URL信息的散列，將發送至相同URL的請求轉發至同一伺服器的演算法。

參考資料

網路-負載均衡

㈤ 多台異地伺服器如何實現負載均衡

一般用的就用簡單的輪詢就好了
調度演算法
靜態方法：僅根據演算法本身實現調度；實現起點公平，不管伺服器當前處理多少請求，分配的數量一致
動態方法：根據演算法及後端RS當前的負載狀況實現調度；不管以前分了多少，只看分配的結果是不是公平
靜態調度演算法(static Sche)（4種）:
(1)rr (Round Robin) :輪叫,輪詢
說明：輪詢調度演算法的原理是每一次把來自用戶的請求輪流分配給內部中的伺服器，從1開始，直到N(內部伺服器個數)，然後重新開始循環。演算法的優點是其簡潔性，它無需記錄當前所有連接的狀態，所以它是一種無狀態調度。缺點：是不考慮每台伺服器的處理能力。
(2)wrr (Weight Round Robin) :加權輪詢(以權重之間的比例實現在各主機之間進行調度)
說明：由於每台伺服器的配置、安裝的業務應用等不同，其處理能力會不一樣。所以，我們根據伺服器的不同處理能力，給每個伺服器分配不同的權值，使其能夠接受相應權值數的服務請求。
(3)sh (Source Hashing) : 源地址hash實現會話綁定sessionaffinity
說明：簡單的說就是有將同一客戶端的請求發給同一個real server,源地址散列調度演算法正好與目標地址散列調度演算法相反，它根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的並且沒有超負荷，將請求發送到該伺服器，否則返回空。它採用的散列函數與目標地址散列調度演算法的相同。它的演算法流程與目標地址散列調度演算法的基本相似，除了將請求的目標IP地址換成請求的源IP地址。
(4)dh : (Destination Hashing) : 目標地址hash
說明：將同樣的請求發送給同一個server,一般用於緩存伺服器，簡單的說，LB集群後面又加了一層，在LB與realserver之間加了一層緩存伺服器，當一個客戶端請求一個頁面時,LB發給cache1,當第二個客戶端請求同樣的頁面時，LB還是發給cache1,這就是我們所說的，將同樣的請求發給同一個server,來提高緩存的命中率。目標地址散列調度演算法也是針對目標IP地址的負載均衡，它是一種靜態映射演算法，通過一個散列（Hash）函數將一個目標IP地址映射到一台伺服器。目標地址散列調度演算法先根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。
動態調度演算法(dynamic Sche)（6種）:
(1)lc (Least-Connection Scheling): 最少連接
說明：最少連接調度演算法是把新的連接請求分配到當前連接數最小的伺服器，最小連接調度是一種動態調度短演算法，它通過伺服器當前所活躍的連接數來估計伺服器的負載均衡，調度器需要記錄各個伺服器已建立連接的數目，當一個請求被調度到某台伺服器，其連接數加1，當連接中止或超時，其連接數減一，在系統實現時，我們也引入當伺服器的權值為0時，表示該伺服器不可用而不被調度。此演算法忽略了伺服器的性能問題，有的伺服器性能好，有的伺服器性能差，通過加權重來區分性能，所以有了下面演算法wlc。
簡單演算法：active*256+inactive (誰的小，挑誰)
(2)wlc (Weighted Least-Connection Scheling):加權最少連接
加權最小連接調度演算法是最小連接調度的超集，各個伺服器用相應的權值表示其處理性能。伺服器的預設權值為1，系統管理員可以動態地設置伺服器的許可權，加權最小連接調度在調度新連接時盡可能使伺服器的已建立連接數和其權值成比例。由於伺服器的性能不同，我們給性能相對好的伺服器，加大權重，即會接收到更多的請求。
簡單演算法：（active*256+inactive）/weight（誰的小，挑誰）
(3)sed (shortest expected delay scheling):最少期望延遲
說明：不考慮非活動連接，誰的權重大，我們優先選擇權重大的伺服器來接收請求，但會出現問題，就是權重比較大的伺服器會很忙，但權重相對較小的伺服器很閑，甚至會接收不到請求，所以便有了下面的演算法nq。
基於wlc演算法，簡單演算法：（active+1)*256/weight （誰的小選誰）
(4).nq (Never Queue Scheling): 永不排隊
說明：在上面我們說明了，由於某台伺服器的權重較小，比較空閑，甚至接收不到請求，而權重大的伺服器會很忙，所此演算法是sed改進，就是說不管你的權重多大都會被分配到請求。簡單說，無需隊列，如果有台real server的連接數為0就直接分配過去，不需要在進行sed運算。
(5).LBLC(Locality-Based Least Connections) :基於局部性的最少連接
說明：基於局部性的最少連接演算法是針對請求報文的目標IP地址的負載均衡調度，主要用於Cache集群系統，因為Cache集群中客戶請求報文的目標IP地址是變化的，這里假設任何後端伺服器都可以處理任何請求，演算法的設計目標在伺服器的負載基本平衡的情況下，將相同的目標IP地址的請求調度到同一個台伺服器，來提高伺服器的訪問局部性和主存Cache命中率，從而調整整個集群系統的處理能力。
(6).LBLCR(Locality-Based Least Connections with Replication) :基於局部性的帶復制功能的最少連接
說明：基於局部性的帶復制功能的最少連接調度演算法也是針對目標IP地址的負載均衡，該演算法根據請求的目標IP地址找出該目標IP地 址對應的伺服器組，按「最小連接」原則從伺服器組中選出一台伺服器，若伺服器沒有超載，將請求發送到該伺服器；若伺服器超載，則按「最小連接」原則從這個集群中選出一台伺服器，將該伺服器加入到伺服器組中，將請求發送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除， 以降低復制的程度。