linux服務器LB羣集之lvs-nat

時間 2020-05-12

標籤 linux 服務器羣集 lvs nat 欄目 Linux 简体版

原文原文鏈接

羣集也稱集羣。在實驗以前，首先要來了解一下羣集的相關知識。

1. 類型linux

1）LB load balancing 負載均衡2）HA high available 高可用3） HP 高性能LBweb

分發器 director算法

硬件實現：F5sql

軟件實現：squid，lvs(linux virtual servr)apache

Squid是七層轉發，lvs是四層轉發vim

四層轉發：ip 協議端口後端

七層轉發：squid websqlcentos

2.調度算法：緩存

當一個director收到一個訪問集羣服務的請求，選擇的機制就是lvs調度算法。
(1)靜態調度方法 fixed scheduling
不關心當前鏈接的活動和非活動狀態，不檢查realservers的鏈接狀態
相應算法：
1，輪叫調度（Round-RobinScheduling）
    輪叫調度算法就是以輪叫的方式依次將請求調度不一樣的服務器，而後進行相應的處理，這種算法的優勢是其簡潔性，它無需記錄當前全部鏈接的狀態，因此它是一種無狀態調度。
2，加權輪叫調度（WeightedRound-Robin Scheduling）
    加權輪調算法用於區分後端服務器響應能力，權重越大分配的鏈接越多，能夠解決服務器間性能不一的狀況，它用相應的權值表示服務器的處理性能，服務器的缺省權值爲1。它是按權值的高低和輪叫方式分配請求到各服務器，權值高的服務器先收到的鏈接，權值高的服務器比權值低的服務器處理更多的鏈接，相同權值的服務器處理相同數目的鏈接數。
3，目標地址散列調度（DestinationHashing Scheduling）
    目標地址hash算法以目標地址爲標準，針對目標地址的請求進行定向轉發，可以實現來自同一用戶的同一請求轉發到同一臺服務器上（基於緩存的架構，可以提升緩存的命中率），它經過一個散列（Hash）函數將一個目標IP地址映射到一臺服務器。目標地址散列調度算法先根據請求的目標IP地址，做爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空。
4，源地址散列調度（SourceHashing Scheduling）
    源地址hash ，以源地址爲標準，未來自同一地址的用戶轉發給同一網絡，算法正好與目標地址散列調度算法相反，它根據請求的源IP地址，做爲散列鍵（HashKey）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空。它採用的散列函數與目標地址散列調度算法的相同。它的算法流程與目標地址散列調度算法的基本類似。在實際應用中，源地址散列調度和目標地址散列調度能夠結合使用在防火牆集羣中，它們能夠保證整個系統的惟一出入口。
靜態調度算法的缺陷：不能考慮後臺服務器當前的狀態
(2)動態調度方法 dynamic scheduling
優勢：可以基於後臺服務器當前的活動鏈接數，進行請求的分配，更合理，避免了一臺服務器負載太多，而另外的服務器處於閒置狀態。
兩種標準：
1）非活動狀態的鏈接（但仍在鏈接狀態）   2）活動狀態的鏈接數
  相應的算法：
1，最小鏈接調度（Least-Connection Scheduling）
    最少鏈接調度是把新的鏈接請求分配到當前鏈接數最小的服務器，它經過服務器當前所活躍的鏈接數來估計服務器的負載狀況。調度器須要記錄各個服務器已創建鏈接的數目，當一個請求被調度到某臺服務器，其鏈接數加1；當鏈接停止或超時，其鏈接數減一。同時檢查非活動狀態鏈接數和活動狀態鏈接數，基於overhead決定，誰的overhead小就會接受下一次請求。
例：overhead=當前活動狀態的鏈接數*256+當前處於非活動狀態
2，加權最小鏈接調度（Weighted Least-Connection Scheduling）
    加權最少鏈接數是最小鏈接調度的超集，各個服務器用相應的權值表示其處理性能。服務器的缺省權值爲1，系統管理員能夠動態地設置服務器的權值。加權最小鏈接調度在調度新鏈接時儘量使服務器的已創建鏈接數和其權值成比例，是最經常使用的算法。例：overhead=（當前活動狀態的鏈接數*256+當前處於非活動狀態的鏈接數）/權重
3，最短的指望的延遲（Shortest Expected Delay Scheduling SED）
    最短時間望延遲，是對wlc算法的一種改進，不查看非狀態鏈接數，並且在計算overhead時要把當前的活動狀態鏈接數加一。
例：overhead=（（當前活動狀態的鏈接數+1）*256）/權重
4，最少隊列調度（Never Queue Scheduling NQ）
    最少隊列調度不查看非活動鏈接數，只查看當前的活動狀態，保證主機不會閒置；無需隊列。若是有臺realserver的鏈接數＝0就直接分配過去，不須要在進行sed運算。
5，基於局部性的最少連接（Locality-Based Least Connections Scheduling）
    基於局部性的最少連接算法和dh類似，是動態的算法，考慮後臺的實際狀況進行輪調，支持權重，在wlc的基礎上；目前主要用於Cache集羣系統，由於在Cache集羣中客戶請求報文的目標IP地址是變化的。這裏假設任何後端服務器均可以處理任一請求，算法的設計目標是在服務器的負載基本平衡狀況下，將相同目標IP地址的請求調度到同一臺服務器，來提升各臺服務器的訪問局部性和主存Cache命中率，從而整個集羣系統的處理能力。LBLC調度算法先根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於其一半的工做負載，則用「最少連接」的原則選出一個可用的服務器，將請求發送到該服務器。
6，帶複製的基於局部性最少連接（Locality-Based Least Connections with Replication Scheduling）
    帶複製的基於局部性最少連接也是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。它與LBLC算法的不一樣之處是它要維護從一個目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。對於一個「熱門」站點的服務請求，一臺Cache 服務器可能會忙不過來處理這些請求。這時，LBLC調度算法會從全部的Cache服務器中按「最小鏈接」原則選出一臺Cache服務器，映射該「熱門」站點到這臺Cache服務器，很快這臺Cache服務器也會超載，就會重複上述過程選出新的Cache服務器。這樣，可能會致使該「熱門」站點的映像會出如今全部的Cache服務器上，下降了Cache服務器的使用效率。LBLCR調度算法將「熱門」站點映射到一組Cache服務器（服務器集合），當該「熱門」站點的請求負載增長時，會增長集合裏的Cache服務器，來處理不斷增加的負載；當該「熱門」站點的請求負載下降時，會減小集合裏的Cache服務器數目。這樣，該「熱門」站點的映像不太可能出如今全部的Cache服務器上，從而提供Cache集羣系統的使用效率。LBLCR算法先根據請求的目標IP地址找出該目標IP地址對應的服務器組；按「最小鏈接」原則從該服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載；則按「最小鏈接」原則從整個集羣中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以下降複製的程度。服務器