導航:首頁 > IDC知識 > 伺服器負載均衡解決方案

伺服器負載均衡解決方案

發布時間:2020-12-11 20:38:20

1、多台伺服器負載均衡,怎麼選擇?

一般用的就用簡單的輪詢就好了
調度演算法
靜態方法:僅根據演算法本身實現調度;實現起點公平,不管伺服器當前處理多少請求,分配的數量一致
動態方法:根據演算法及後端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地 址對應的伺服器組,按「最小連接」原則從伺服器組中選出一台伺服器,若伺服器沒有超載,將請求發送到該伺服器;若伺服器超載,則按「最小連接」原則從這個集群中選出一台伺服器,將該伺服器加入到伺服器組中,將請求發送到該伺服器。同時,當該伺服器組有一段時間沒有被修改,將最忙的伺服器從伺服器組中刪除, 以降低復制的程度。

2、多台伺服器如何做網路負載均衡?

1:找分區或目錄同步軟體,某台伺服器改動了自動把修改應用到別的伺服器,比如紅旗的HA。

2:換種建伺服器的思路,後台用一台獨立的伺服器做資料庫和文件伺服器,用來存放資料庫和上傳的文件,另外的做負載均衡運行伺服器,把不需要變動的網頁程序放上面。

3、伺服器負載均衡解決了什麼問題

負載均衡主要解決當數據量過大,連接數較多情況下,伺服器硬體無法滿足需要處理的性能消耗,也就是是說伺服器成了瓶頸,伺服器負載均衡解決伺服器瓶頸,使大量的連接平均分發到多台伺服器。

4、多台異地伺服器如何實現負載均衡?

一般用的就用簡單的輪詢就好了
調度演算法
靜態方法:僅根據演算法本身實現調度;實現起點公平,不管伺服器當前處理多少請求,分配的數量一致
動態方法:根據演算法及後端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地 址對應的伺服器組,按「最小連接」原則從伺服器組中選出一台伺服器,若伺服器沒有超載,將請求發送到該伺服器;若伺服器超載,則按「最小連接」原則從這個集群中選出一台伺服器,將該伺服器加入到伺服器組中,將請求發送到該伺服器。同時,當該伺服器組有一段時間沒有被修改,將最忙的伺服器從伺服器組中刪除, 以降低復制的程度。

5、為什麼需要伺服器負載均衡?採用伺服器負載均衡器有什麼優點?

隨著網站、應用訪問量的增加,一台伺服器已經不能滿足應用的需求,而需要多台伺服器集群,這時就會用到負載均衡

它的好處

負載均衡優化了訪問請求在伺服器組之間的分配,消除了伺服器之間的負載不平衡,從而提高了系統的反應速度與總體性能;

負載均衡可以對伺服器的運行狀況進行監控,及時發現運行異常的伺服器,並將訪問請求轉移到其它可以正常工作的伺服器上,從而提高伺服器組的可靠性採用了負均衡器器以後,可以根據業務量的發展情況靈活增加伺服器,系統的擴展能力得到提高,同時簡化了管理。

6、伺服器如何實現集群和負載均衡

你可以直接買一台負載均衡交換機啊,何必要浪費1台伺服器呢。
2 應該是每台都會有一個IP地址 外網 訪問連接到的那個IP地址 是你的負載均衡交換機的IP地址 他隨機把你的訪問請求分配到你的3台伺服器上
3 無主從關系,負載均衡交換機它會沒2秒左右向你的伺服器發送一個健康檢查,如果發現你的伺服器出現問題,它會自動屏蔽你這台伺服器
4 你問的重復問題。

7、伺服器負載均衡問題,需要的設備和軟體

你上面說到的這些伺服器只有Web伺服器需要做負載均衡,而且一般都是前置機才做負載均衡,做伺服器負載均衡的條件是:
1. 你要有提供相同應用的多台Web伺服器。
2. 要有負載均衡的設備(可以是軟體也可以是硬體)。
3. 要為這個服務分配一個虛擬地址(作為服務訪問的統一入口)和若干真實地址(有幾台Web伺服器需要幾個真實地址)。
註:一般建議採用硬體設備,通常需要做負載均衡的應用說明他的負載很大,專用的硬體比較可靠。
具備以上條件後將Web伺服器連接到負載均衡設備上,在負載均衡設備上配置虛擬地址和真實地址、配置負載均衡演算法,配置負載均衡策略,將負載均衡設備接入網路。
這樣,外面的用戶只需要訪問這個虛擬地址就可以了,負載均衡設備收到請求後會按照負載均衡策略和演算法把請求分配到真實地址上,實現負載功能。
以上所說只是負載均衡的一種部署方式,根據實際需要選擇單臂、雙臂接入網路;根據應用的特點選擇健康檢查的方式;根據應用選擇是否使用回話保持演算法等。

8、文件伺服器的負載均衡方法

1:不在同一個子網共享給誰?怎麼共享?
2:負載均衡,冗餘容錯等等。你幾個人在區域網有必要做NFS么?幾百個人訪問就需要了。冗餘了速度就快。
3;NFS能對用戶做許可權設置。你在區域網共享可以給某用戶設置許可權么?只能一視同仁吧?

補充答:
1:先道個歉:不好意思,我昨天搞錯了。不是NFS。是FTP
2:文件共享,主要是針對乙太網。文件伺服器主要針對廣域網或者有很多部分公司的區域網。
3:按理論分析,文件共享是物理層傳輸,不需要協議轉發。而FTP是應用層服務,傳輸文件需要使用FTP協議轉發。這樣效率肯定就不及直接傳輸。所以對於我們同一個子網的區域網共享是比FTP要快的。但是如果隔壁和你不在一個子網,而你需要他的資料,共享是行不通的。如果按你所說用路由器鏈接,那倒不如直接拿U盤去拷。那麼我們把問題再加深一點。我在武漢,你在北京。我需要你的資料。你會花成本去去架設路由器么?即便能架設,你這么架設?用FTP?或者VPN(如果有條件)?對於簡單的區域網來說的,共享是比FTP更好的選擇。
4:相比簡單的區域網,公司的區域網就和我們學生寢室的區域網不同了。。他們有很多部門。有不同的VLAN,一個子網中user和另一個子網user需要共享資料怎麼辦?用路由器,U盤,恐怕都不是辦法。那麼FTP當然就是選擇。
5:而且公司的復雜區域網有這樣的問題。我們學生共享了魔獸別人愛拷不拷,無論誰拷都可以。但是公司一般他只需要共享資料給同區域網的某一個人,這些資料是財務資料,不需要其他人知道。我能用共享么?NTFS的許可權是做不到的。如果硬要鑽牛角尖,那麼共享能做到,用隱藏共享,但是許可權的設置和安全策略配置是個復雜的過程。這種情況在財務等部門是經常碰到的。所以FTP更好。這樣一說,你應該個就明白了。在區域網中相比共享,FTP唯一的功能就是安全。你需要速度,還是安全。這才是你的選擇要點。對於廣域網,共享肯定就無用武之地了。

可以做個朋友;172014284

與伺服器負載均衡解決方案相關的知識