負載均衡排程演算法大全
負載主機可以提供很多種負載均衡方法,也就是我們常說的排程方法或演算法:
輪循(Round Robin)
這種方法會將收到的請求迴圈分配到伺服器叢集中的每臺機器,即有效伺服器。如果使用這種方式,所有的標記進入虛擬服務的伺服器應該有相近的資源容量以及負載形同的應用程式。如果所有的伺服器有相同或者相近的效能那麼選擇這種方式會使伺服器負載形同。基於這個前提,輪循排程是一個簡單而有效的分配請求的方式。然而對於伺服器不同的情況,選擇這種方式就意味著能力比較弱的伺服器也會在下一輪迴圈中接受輪循,即使這個伺服器已經不能再處理當前這個請求了。這可能導致能力較弱的伺服器超載。
加權輪循(Weighted Round Robin)
這種演算法解決了簡單輪循排程演算法的缺點:傳入的請求按順序被分配到叢集中伺服器,但是會考慮提前為每臺伺服器分配的權重。管理員只是簡單的通過伺服器的處理能力來定義各臺伺服器的權重。例如,能力最強的伺服器A給的權重是100,同時能力最低的伺服器給的權重是50。這意味著在伺服器B接收到第一個請求之前前,伺服器A會連續的接受到2個請求,以此類推。
最少連線數(Least Connection)
以上兩種方法都沒有考慮的是系統不能識別在給定的時間裡保持了多少連線。因此可能發生,伺服器B伺服器收到的連線比伺服器A少但是它已經超載,因為伺服器B上的使用者開啟連線持續的時間更長。這就是說連線數即伺服器的負載是累加的。這種潛在的問題可以通過“最少連線數”演算法來避免:傳入的請求是根據每臺伺服器當前所開啟的連線數來分配的。即活躍連線數最少的伺服器會自動接收下一個傳入的請求。接本上和簡單輪詢的原則相同:所有擁有虛擬服務的伺服器資源容量應該相近。值得注意的是,在流量率低的配置環境中,各伺服器的流量並不是相同的,會優先考慮第一臺伺服器。這是因為,如果所有的伺服器是相同的,那麼第一個伺服器優先,直到第一臺伺服器有連續的活躍流量,否則總是會優先選擇第一臺伺服器。
最少連線數慢啟動時間(Least Connection Slow Start Time)
對最少連線數和帶權重的最小連線數排程方法來說,當一個伺服器剛加入線上環境是,可以為其配置一個時間段,在這段時間內連線數是有限制的而且是緩慢增加的。這為伺服器提供了一個‘過渡時間’以保證這個伺服器不會因為剛啟動後因為分配的連線數過多而超載。這個值在L7配置介面設定。
加權最少連線(Weighted Least Connection)
如果伺服器的資源容量各不相同,那麼“加權最少連線”方法更合適:由管理員根據伺服器情況定製的權重所決定的活躍連線數一般提供了一種對伺服器非常平衡的利用,因為他它借鑑了最少連線和權重兩者的優勢。通常,這是一個非常公平的分配方式,因為它使用了連線數和伺服器權重比例;叢集中比例最低的伺服器自動接收下一個請求。但是請注意,在低流量情況中使用這種方法時,請參考“最小連線數”方法中的注意事項。
基於代理的自適應負載均衡(Agent Based Adaptive Balancing)
除了上述方法之外,負載主機包含一個自適用邏輯用來定時監測伺服器狀態和該伺服器的權重。對於非常強大的“基於代理的自適應負載均衡”方法來說,負載主機以這種方式來定時檢測所有伺服器負載情況:每臺伺服器都必須提供一個包含檔案,這個檔案包含一個0~99的數字用來標明改伺服器的實際負載情況(0=空前,99=超載,101=失敗,102=管理員禁用),而伺服器同構http get方法來獲取這個檔案;同時對叢集中伺服器來說,以二進位制檔案形式提供自身負載情況也是該伺服器工作之一,然而,並沒有限制伺服器如何計算自身的負載情況。根據伺服器整體負載情況,有兩種策略可以選擇:在常規的操作中,排程演算法通過收集的伺服器負載值和分配給該伺服器的連線數的比例計算出一個權重比例。因此,如果一個伺服器負載過大,權重會通過系統透明的作重新調整。和加權輪循排程方法一樣,不正確的分配可以被記錄下來使得可以有效的為不同伺服器分配不同的權重。然而,在流量非常低的環境下,伺服器報上來的負載值將不能建立一個有代表性的樣本;那麼基於這些值來分配負載的話將導致失控以及指令震盪。因此,在這種情況下更合理的做法是基於靜態的權重比來計算負載分配。當所有伺服器的負載低於管理員定義的下限時,負載主機就會自動切換為加權輪循方式來分配請求;如果負載大於管理員定義的下限,那麼負載主機又會切換回自適應方式。
固定權重(Fixed Weighted)
最高權重只有在其他伺服器的權重值都很低時才使用。然而,如果最高權重的伺服器下降,則下一個最高優先順序的伺服器將為客戶端服務。這種方式中每個真實伺服器的權重需要基於伺服器優先順序來配置。
加權響應(Weighted Response)
流量的排程是通過加權輪循方式。加權輪循中所使用的權重是根據伺服器有效性檢測的響應時間來計算。每個有效性檢測都會被計時,用來標記它響應成功花了多長時間。但是需要注意的是,這種方式假定伺服器心跳檢測是基於機器的快慢,但是這種假設也許不總是能夠成立。所有伺服器在虛擬服務上的響應時間的總和加在一起,通過這個值來計算單個服務物理伺服器的權重;這個權重值大約每15秒計算一次。
源IP雜湊(Source IP Hash)
這種方式通過生成請求源IP的雜湊值,並通過這個雜湊值來找到正確的真實伺服器。這意味著對於同一主機來說他對應的伺服器總是相同。使用這種方式,你不需要儲存任何源IP。但是需要注意,這種方式可能導致伺服器負載不平衡。
相關文章
- kubernetes叢集內排程與負載均衡負載
- 解密負載均衡技術和負載均衡演算法解密負載演算法
- 負載均衡演算法負載演算法
- 負載均衡的演算法負載演算法
- F5負載均衡系列教程八【負載均衡演算法詳解】負載演算法
- 6種負載均衡演算法負載演算法
- 漫談負載均衡演算法負載演算法
- kubernetes負載感知排程負載
- 負載均衡負載
- 負載均衡演算法需要改進負載演算法
- gRPC負載均衡(客戶端負載均衡)RPC負載客戶端
- gRPC負載均衡(自定義負載均衡策略)RPC負載
- Linux程序排程器-CPU負載Linux負載
- NGINX 負載均衡Nginx負載
- WebSocket負載均衡Web負載
- IP負載均衡負載
- 【Nginx】負載均衡Nginx負載
- nginx負載均衡Nginx負載
- 負載均衡技術(一)———負載均衡技術介紹負載
- Nginx + IIS 負載均衡實現過程詳解Nginx負載
- Dubbo原始碼分析(九)負載均衡演算法原始碼負載演算法
- 淺談負載均衡演算法與實現負載演算法
- Kafka的Consumer負載均衡演算法Kafka負載演算法
- 5大負載均衡演算法 (原理圖解)負載演算法圖解
- 負載均衡常見的演算法有哪些?負載演算法
- 雲原生應用負載均衡系列 (2): 入口流量分發、容錯與高可用排程負載
- 負載均衡技術(二)———常用負載均衡服務介紹負載
- 【知識分享】四層負載均衡和七層負載均衡負載
- 淺談負載均衡負載
- 漫談負載均衡負載
- Nginx負載均衡模式Nginx負載模式
- 面試之負載均衡面試負載
- 負載均衡知多少?負載
- 負載均衡簡介負載
- 負載均衡詳解負載
- LoadBalancer負載均衡負載
- 負載均衡叢集負載
- 負載均衡---ribbon負載