lvs負載調度演算法

『壹』 U8伺服器參數配置中負載均衡如何設置

網路的負載均衡是一種動態均衡技術，通過一些工具實時地分析數據包，掌握網路中的數據流量狀況，把任務合理均衡地分配出去。這種技術基於現有網路結構，提供了一種擴展伺服器帶寬和增加伺服器吞吐量的廉價有效的方法，加強了網路數據處理能力，提高了網路的靈活性和可用性。

『貳』 大家企業中lvs都是用什麼調度演算法

看原理，適用什麼場合吧。畢竟調度演算法有10種之多。一般是rr/wrr/wlc/lc什麼的。

『叄』 lvs負載均衡（簡介，三種工作模式，四種常用演算法）

一，lvs簡介

LVS是linux Virtual Server的簡稱，也就是Linux虛擬伺服器，是一個由章文嵩博士發起的自由軟體項目，官方站點是： http://www.linuxvirtualserver.org 。現在LVS已經是Linux標准內核的一部分，在Linux2.4內核以前，使用LVS時必須重新編譯內核以支持LVS功能模塊，但是從Linux2.4內核心之後，已經完全內置了LVS的各個功能模塊，無需給內核打任何補丁，可以直接使用LVS提供的各種功能。使用LVS技術要達到的目標是：通過LVS提供的負載均衡技術和Linux操作系統實現一個高性能，高可用的伺服器群集，它具有良好的可靠性、可擴展性和可操作性。從而以兄棚野低廉的成本實現最優的服務性能。

二，三種工作模式

1、基於NAT的LVS模式負載均衡

也就是網路地址翻譯技術實現虛擬伺服器，當用戶請求到達調度器時，調度器將請求報文的目標地址（即虛擬IP地址）改寫成選定的Real Server地址，同時報文的目標埠也改成選定的Real Server的相應埠，***將報文請求發送到選定的Real Server。在伺服器端得到數據後，Real Server返回數據給用戶時，需要再次經過負載調度器將報文的源地址和源埠改成虛擬IP地址和相應埠，然後把數據發送給用戶，完成整個負載調度過程。可以看出，在NAT方式下，用戶請求和響應報文都必須經過Director Server地址重寫，當用戶請求越來越多時，調度器的處理能力將稱為瓶頸。

2，基於TUN的LVS負載均衡

也就是IP隧道技術實現虛擬伺服器。它的連接調度和管理與VS/NAT方式一樣，只是它的報文轉發方法不同，VS/TUN方式中，調度器採用IP隧道技術將用戶請求轉發到某個Real Server，而這個Real Server將直接響應用戶的請求，不再經過前端調度器，此外，對Real Server的地域位置沒有要求，可以和Director Server位於同一個網段，也可以是獨立的一個網路。因此，在TUN方式中，調度器將只處理用戶的報文請求，集群系統的吞吐量大大提高。

用的很少，圖省略

3，基於DR的LVS負載均衡

也就是用直接路由技術實現虛擬伺服器。它的連接調度和管理與VS/NAT和VS/TUN中的一樣，但它的報文轉發方法又有不同，VS/DR通過改寫請求報文的MAC地址，將請求發送到Real Server，而Real Server將響應直接返回給客戶，免去了VS/TUN中的IP隧道開銷。這種方式是三種負載調度機制中性能最好的，但是必須要求Director Server與Real Server都有一塊網卡連在同一物理網段上。

三，LVS負載均衡調度演算法

上面我們談到，負載調度器是根據各 個伺服器的負載情況，動和或態地選擇一台Real Server響應用戶請求，那麼動態選擇是如何實現呢，其實也就是我們這里要說的負載調度演算法，根據不同的網路服務需求和伺服器配置，IPVS實現了如下 八種負載調度演算法，這里我們詳細講述最常用的四種調度演算法，剩餘的四種調度演算法請參考其它資料。

3.1  輪叫調度（Round Robin）

「輪叫」調度也叫1:1調度，調度器通過羨喊「輪叫」調度演算法將外部用戶請求按順序1:1的分配到集群中的每個Real Server上，這種演算法平等地對待每一台Real Server，而不管伺服器上實際的負載狀況和連接狀態。

3.2  加權輪叫調度（Weighted Round Robin）

「加 權輪叫」調度演算法是根據Real Server的不同處理能力來調度訪問請求。可以對每台Real Server設置不同的調度權值，對於性能相對較好的Real Server可以設置較高的權值，而對於處理能力較弱的Real Server，可以設置較低的權值，這樣保證了處理能力強的伺服器處理更多的訪問流量。充分合理的利用了伺服器資源。同時，調度器還可以自動查詢Real Server的負載情況，並動態地調整其權值。

3.3  最少鏈接調度（Least Connections）

「最少連接」調度演算法動態地將網路請求調度到已建立的鏈接數最少的伺服器上。如果集群系統的真實伺服器具有相近的系統性能，採用「最小連接」調度演算法可以較好地均衡負載。

3.4  加權最少鏈接調度（Weighted Least Connections）

「加權最少鏈接調度」是「最少連接調度」的超集，每個服務節點可以用相應的權值表示其處理能力，而系統管理員可以動態的設置相應的權值，預設權值為1，加權最小連接調度在分配新連接請求時盡可能使服務節點的已建立連接數和其權值成正比。

其它四種調度演算法分別為：基於局部性的最少鏈接（Locality-Based Least Connections）、帶復制的基於局部性最少鏈接（Locality-Based Least Connections with Replication）、目標地址散列（Destination Hashing）和源地址散列（Source Hashing），對於這四種調度演算法的含義，本文不再講述，如果想深入了解這其餘四種調度策略的話，可以登陸LVS中文站點 zh.linuxvirtualserver.org，查閱更詳細的信息。

『肆』 如何配置Web伺服器實現負載均衡

網路的負載均衡是一種動態均衡技術，通過一些工具實時地分析數據包，掌握網路中的數據流量狀況，把任務合理均衡地分配出去。這種技術基於現有網路結構，提供了一種擴展伺服器帶寬和增加伺服器吞吐量的廉價有效的方法，加強了網路數據處理能力，提高了網路的靈活性和可用性。

以四台伺服器為例實現負載均衡：

安裝配置LVS

1. 安裝前准備：

(1)首先說明，LVS並不要求集群中的伺服器規格劃一，相反，可以根據伺服器的不同配置和負載狀況，調整負載分配策略，充分利用集群環境中的每一台伺服器。如下表：

Srv Eth0 Eth0：0 Eth1 Eth1：0

vs1 10.0.0.1 10.0.0.2 192.168.10.1 192.168.10.254

vsbak 10.0.0.3 192.168.10.102

real1 192.168.10.100

real2 192.168.10.101

其中，10.0.0.2是允許用戶訪問的IP。

(2)這4台伺服器中，vs1作為虛擬伺服器(即負載平衡伺服器)，負責將用戶的訪問請求轉發到集群內部的real1，real2，然後由real1，real2分別處理。
Client為客戶端測試機器，可以為任意操作系統。

(3)所有OS為redhat6.2，其中vs1 和vsbak 的核心是2.2.19， 而且patch過ipvs的包， 所有real
server的Subnet mask 都是24位， vs1和vsbak 的10.0.0. 網段是24 位。

2.理解LVS中的相關術語

(1) ipvsadm ：ipvsadm是LVS的一個用戶界面。在負載均衡器上編譯、安裝ipvsadm。

(2) 調度演算法： LVS的負載均衡器有以下幾種調度規則：Round-robin，簡稱rr;weighted
Round-robin，簡稱wrr;每個新的連接被輪流指派到每個物理伺服器。Least-connected，簡稱lc;weighted
Least-connected，簡稱wlc，每個新的連接被分配到負擔最小的伺服器。

(3) Persistent client
connection，簡稱pcc，(持續的客戶端連接，內核2.2.10版以後才支持)。所有來自同一個IP的客戶端將一直連接到同一個物理伺服器。超時時間被設置為360秒。Pcc是為https和cookie服務設置的。在這處調度規則下，第一次連接後，所有以後來自相同客戶端的連接(包括來自其它埠)將會發送到相同的物理伺服器。但這也會帶來一個問題，因為大約有25%的Internet
可能具有相同的IP地址。

(4) Persistent port
connection調度演算法：在內核2.2.12版以後，pcc功能已從一個調度演算法(你可以選擇不同的調度演算法：rr、wrr、lc、wlc、pcc)演變成為了一個開關選項(你可以讓rr、
wrr、lc、wlc具備pcc的屬性)。在設置時，如果你沒有選擇調度演算法時，ipvsadm將默認為wlc演算法。 在Persistent port
connection(ppc)演算法下，連接的指派是基於埠的，例如，來自相同終端的80埠與443埠的請求，將被分配到不同的物理伺服器上。不幸的是，如果你需要在的網站上採用cookies時將出問題，因為http是使用80埠，然而cookies需要使用443埠，這種方法下，很可能會出現cookies不正常的情況。

(5)Load Node Feature of Linux Director：讓Load balancer 也可以處理users 請求。

(6)IPVS connection synchronization。

(7)ARP Problem of LVS/TUN and LVS/DR：這個問題只在LVS/DR，LVS/TUN 時存在。

3. 配置實例

(1) 需要的軟體包和包的安裝：

I. piranha-gui-0.4.12-2*.rpm (GUI介面cluster設定工具);

II. piranha-0.4.12-2*.rpm;

III. ipchains-1.3.9-6lp*.rpm (架設NAT)。

取得套件或mount到光碟，進入RPMS目錄進行安裝:

# rpm -Uvh piranha*

# rpm -Uvh ipchains*

(2) real server群：

真正提供服務的server(如web
server)，在NAT形式下是以內部虛擬網域的形式，設定如同一般虛擬網域中Client端使用網域：192.168.10.0/24
架設方式同一般使用虛擬IP之區域網絡。

a. 設網卡IP

real1 ：192.168.10.100/24

real2 ：192.168.10.101/24

b.每台server均將default gateway指向192.168.10.254。
192.168.10.254為該網域唯一對外之信道，設定在virtual server上，使該網域進出均需通過virtual server 。

c.每台server均開啟httpd功能供web server服務，可以在各real server上放置不同內容之網頁，可由瀏覽器觀察其對各real
server讀取網頁的情形。

d.每台server都開啟rstatd、sshd、rwalld、ruser、rsh、rsync，並且從Vserver上面拿到相同的lvs.conf文件。

(3) virtual server：

作用在導引封包的對外主機，專職負責封包的轉送，不提供服務，但因為在NAT型式下必須對進出封包進行改寫，所以負擔亦重。

a.IP設置：

對外eth0：IP：10.0.0.1 eth0：0 ：10.0.0.2

對內eth1：192.168.10.1 eth1：0 ：192.168.10.254

NAT形式下僅virtual server有真實IP，real server群則為透過virtual server.

b.設定NAT功能

# echo 1 >; /proc/sys/net/ipv4/ip_forward

# echo 1 >; /proc/sys/net/ipv4/ip_always_defrag

# ipchains -P forward MASQ

c.設定piranha 進入X-window中 (也可以直接編輯/etc/lvs.cf )

a).執行面板系統piranha

b).設定「整體配置」(Global Settings) 主LVS伺服器主機IP：10.0.0.2， 選定網路地址翻譯(預設) NAT路徑名稱：
192.168.10.254， NAT 路徑裝置： eth1：0

c).設定虛擬伺服器(Virtual Servers) 添加編輯虛擬伺服器部分：(Virtual
Server)名稱：(任意取名);應用：http;協議： tcp;連接：80;地址：10.0..0.2;裝置：eth0：0; 重入時間：180
(預設);服務延時：10 (預設);載入監控工具：ruptime (預設);調度策略：Weighted least-connections; 持續性：0
(預設); 持續性屏蔽： 255.255.255.255 (預設); 按下激活：實時伺服器部分：(Real Servers); 添加編輯：名字：(任意取名);
地址： 192.168.10.100; 權重：1 (預設) 按下激活

另一架real server同上，地址：192.168.10.101。

d). 控制/監控(Controls/Monitoring)
控制：piranha功能的激活與停止，上述內容設定完成後即可按開始鍵激活piranha.監控器：顯示ipvsadm設定之routing table內容
可立即更新或定時更新。

(4)備援主機的設定(HA)

單一virtual server的cluster架構virtual server 負擔較大，提供另一主機擔任備援，可避免virtual
server的故障而使對外服務工作終止;備份主機隨時處於預備狀態與virtual server相互偵測

a.備份主機：

eth0： IP 10.0.0.3

eth1： IP 192.168.10.102 同樣需安裝piranha，ipvsadm，ipchains等套件

b.開啟NAT功能(同上面所述)。

c.在virtual server(10.0.0.2)主機上設定。

a).執行piranha冗餘度 ;

b).按下「激活冗餘度」;

冗餘LVS伺服器IP： 10.0.0.3;HEARTBEAT間隔(秒數)： 2 (預設)

假定在…秒後進入DEAD狀態： 5 (預設);HEARTBEAT連接埠： 539 (預設)

c).按下「套用」;

d).至「控制/監控」頁，按下「在當前執行層添加PULSE DEAMON」 ，按下「開始」;

e).在監控器按下「自動更新」，這樣可由窗口中看到ipvsadm所設定的routing table，並且動態顯示real
server聯機情形，若real server故障，該主機亦會從監視窗口中消失。

d.激活備份主機之pulse daemon (執行# /etc/rc.d/init.d/pulse start)。

至此，HA功能已經激活，備份主機及virtual server由pulse daemon定時相互探詢，一但virtual
server故障，備份主機立刻激活代替;至virtual server 正常上線後隨即將工作交還virtual server。

LVS測試

經過了上面的配置步驟，現在可以測試LVS了，步驟如下：

1. 分別在vs1，real1，real2上運行/etc/lvs/rc.lvs_dr。注意，real1，real2上面的/etc/lvs
目錄是vs2輸出的。如果您的NFS配置沒有成功，也可以把vs1上/etc/lvs/rc.lvs_dr復制到real1，real2上，然後分別運行。確保real1，real2上面的apache已經啟動並且允許telnet。

2. 測試Telnet：從client運行telnet 10.0.0.2，
如果登錄後看到如下輸出就說明集群已經開始工作了：(假設以guest用戶身份登錄)

[guest@real1 guest]$——說明已經登錄到伺服器real1上。

再開啟一個telnet窗口，登錄後會發現系統提示變為：

[guest@real2 guest]$——說明已經登錄到伺服器real2上。

3. 測試http：從client運行iexplore http://10.0.0.2

因為在real1 和real2 上面的測試頁不同，所以登錄幾次之後，顯示出的頁面也會有所不同，這樣說明real server 已經在正常工作了。

『伍』 NAT原理總結

由於網路的飛速發展和網路應用的極速增多，致使IPv4可用地址空間逐漸枯竭。盡管IPv6可以在根本上解決地址枯竭問題，但IPv4發展到IPv6還需要一個過渡，而這便產生了NAT。

IP地址分為公網IP與私網IP。一般情況下，在互聯網中，公網IP可直接訪問，私網IP無法直接訪問。而NAT則是將私網IP地址轉換為公網IP地址（將IP報文頭部的私網IP地址改為可以提供訪問的公網IP地址），從而實現用戶上網功能或伺服器在互聯網上提供服務。NAT還可以使得一個公網IP代表多個不同的內網IP，這樣便節省了IP地址資源。

NAT分為靜態轉換、動態轉換、埠轉換

公司（有固定公網IP地址）上網訪問某網站簡易過程

實現SNAT和DNAT都需要開啟內核數據轉發功能

基於nat表的target，適用於固定的公網IP

SNAT選項：

語法：

範例：

nat表的target，適用於埠映射，即可重定向到本機，也可以支持重定向至不同主機的不同埠，但不支持多目標，即不支持負載均衡功能

DNAT選項：

DNAT語法：

範例：

CentOS 7、8

CentOS 6

iptables-restore選項

用規則文件保存各規則，開機時自動載入此規則文件中的規則

在/etc/rc.d/rc.local文件添加

範例: CentOS 7，8 使用 iptables-services

LVS由前端的負載均衡器(Load Balancer，LB)和後端的真實伺服器(Real Server，RS)群組成。RS間可通過區域網或廣域網連接。LVS的這種結構對用戶是透明的，用戶只能看見一台作為LB的虛擬伺服器(Virtual Server)，而看不到提供服務的RS群。當用戶的請求發往虛擬伺服器，LB根據設定的包轉發策略和負載均衡調度演算法將用戶請求轉發給RS。RS再將用戶請求結果返回給用戶。

1.當客戶端的請求到達負載均衡器的內核空間時，首先會到達PREROUTING鏈。

2.當內核發現請求數據包的目的地址是本機時，將數據包送往INPUT鏈。

3.LVS由用戶空間的ipvsadm和內核空間的IPVS組成，ipvsadm用來定義規則，IPVS利用ipvsadm定義的規則工作，IPVS工作在INPUT鏈上,當數據物絕包到達INPUT鏈時，首先會被IPVS檢查，如果數據包裡面的目的地址及埠沒有在規則裡面，那麼這條數據包將被放行至用戶空間。

4.如果數據包裡面的目的地址及埠在規則裡面，那麼這條數據報文將被修改目的地址侍猜為事先定義好的後端伺服器，並送往POSTROUTING鏈。

5.最後經由POSTROUTING鏈發往後端伺服器。

注意：在NAT模式中，Real Server的網關必須指向LVS，否則報文無法送達客戶端。

注意：需要設置lo介面的VIP不能響應本地網路內的arp請求。

①.客戶端將請求發往前端的負載均衡器，請求報文源地址是CIP，目標地址為VIP。

②.負載均衡器收到報文後，發現請求的是在規則裡面存在的地址，那麼它將在客戶罩談姿端請求報文的首部再封裝一層IP報文,將源地址改為DIP，目標地址改為RIP,並將此包發送給RS。

③.RS收到請求報文後，會首先拆開第一層封裝,然後發現裡面還有一層IP首部的目標地址是自己lo介面上的VIP，所以會處理次請求報文，並將響應報文通過lo介面送給eth0網卡直接發送給客戶端。

注意：需要設置lo介面的VIP不能在共網上出現。

LVS的調度演算法分為靜態與動態兩類。

『陸』 linux運維之LVS（一）

關於LVS負載均衡

一、什麼是負載均衡：

    負載均衡集群提供了一種廉價、有效、透明的方法，來擴展網路設備和

伺服器的負載、帶寬、增加吞吐量、加強網路數據處理能力，提高網路的靈活性

和可用性。

二、搭建負載均衡服務的需求：

1）把單台計算機無法承受的大規模的並發訪問或者數據流量分擔到多台節點設備上

分別處理，減少用戶等待響應的時間，提升用戶體驗。

2）單個重負載的運算分擔到多台節點設備上做並行處理，每個節點設備結束後，

將結果匯總，返回給用戶，系統處理能力得到大幅度提升。

3）7*24的服務保證，任意一個或多個有限節點設備宕機，要求不能影響業務。

三、LVS的介紹：

    LVS是Linux Virtual Server的簡寫，即Linux虛擬伺服器，是一個虛擬的伺服器

集群系統，可以在UNIX/LINUX平台下實現負載均衡集群功能。

    該項目是在1998年5月由章文嵩博士組織成立的，是中國國內最早出現的自由

軟體項目之一。

四、關於LVS的配置使用：

    LVS負載均衡調度技術是在Linux內核中實現的，因此，被稱為Linux

虛擬伺服器。我們使用該軟體配置LVS時候，不能直接配置內核中的ipvs，

而需要使用ipvs的管理工具ipvsadm進行管理，ipvs的管理工具ipvsadm管理ipvs。

五、LVS技術點小結：

1）真正實現負載均衡的工具是ipvs，工作在linux內核層面。

2）LVS自帶的ipvs管理工具是ipvsadm。

3）keepalived實現管理ipvs及對負載均衡器的高可用。

4）Red hat工具Piranha WEB管理實現調度的工具ipvs。

六、LVS體系結構與工作原理：

1）LVS集群負載均衡接收服務的所有入站客戶端計算機請求，並根據調度演算法決定哪個集群節點應該處理回復請求。

負載均衡（LB）有時也被稱為LVS Director(簡稱 Director).

2）LVS虛擬伺服器的體系結構如下圖，一組伺服器通過高速的區域網或者地理分布

的廣域網相互連接，在他們的前端有一個負載調度器（Load Balancer）。負載調度器能

無縫地將網路請求調度到真正的伺服器上，從而使得伺服器集群的結構對客戶是透明的，

客戶訪問集群系統提供的網路服務就像訪問一台高性能、高可用的伺服器一樣。客戶程序

不受伺服器集群的影響不需做任何修改。系統的伸縮性通過在服務集群中透明地加入和刪除

一個節點來達到，通過檢測節點或服務進程故障和正確的重置系統達到高可用性。由於我們的負載調度技術在

linux內核中實現的，我們稱之為linux虛擬伺服器（Linux Virtual Server）。

七、LVS社區提供了一個命名的約定：

名稱：                              縮寫         

虛擬IP地址（Virtual IP Address）    VIP

說明：VIP為Director用於向客戶端計算機提供服務的ip地址，

比如：www.etiantian.org 域名就解析到vip上提供服務。

-------------------------------------------------------------------------------

真實ip地址(Real Server ip Address)    縮寫：VIP

說明：在集群下面節點上使用的ip地址，物理ip地址。

-----------------------------------------------------------------------------------

Director的ip地址(Director ip Adress)  縮寫：DIP

說明：Director用於連接內外網路的ip地址，物理網卡上的IP地址，

是負載均衡上的ip。

-------------------------------------------------------------------------------------

客戶端主機IP地址(Client IP Address)  縮寫：CIP

說明：客戶端用戶計算機請求集群伺服器的IP地址，該地址用作發送

給集群的請求的源ip地址。

----------------------------------------------------------------

LVS集群內部的節點稱為真實伺服器(Real server)，也叫做集群節點。請求集群服務的

計算機稱為客戶端計算機。

與計算機通常在網上交換數據包的方式相同，客戶端計算機、Director

和真實伺服器使用IP地址彼此進行通信。

------------------------------------------------------------------------------------------

八、LVS集群的3種工作模式介紹與原理講解

1）IP虛擬服務軟體ipvs，在調度器的實現技術中，IP負載均衡技術是

效率最高的。在已用的ip負載均衡技術中有通過網路地址轉換

（Network Address Translation）將一組伺服器構成一個高性能的、高可用的虛擬伺服器，

我們稱之為VS、NAT技術（Virtual Server Network Adress Translation）。

2）在分析VS/NAT的缺點和網路服務的非對稱性的基礎上，我們提出通過IP隧道實現虛擬伺服器的

方法VS/TUN(Virtual Server via IP Tunneling)和通過直接路由實現虛擬服務

器的方法VS/DR(Virtual Server via Director Routing),它們可以極大地提高系統的伸縮性。

3）淘寶開源的模式FULLNAT。

LVS的四種工作模式：

    縮寫及全拼：

NAT(Network Adress Translation)、TUN(Tunneling)、

DR(Director Routing)、FULLNAT(FULL Network address Translation)

-------------------------------------------------------------------------------------------

九、什麼是ARP協議：

1) ARP協議：全稱"Address Resolution Protocol"，中文名地址解析協議，使用ARP協議可

實現通過IP地址獲得得對應主機的物理地址(MAC地址)。

  在TCP/IP的網路環境下，每個聯網的主機都會被分配一個32位的ip地址，

  這種互聯網地址是在網際范圍標識主機的一種邏輯地址。為了讓報文在

物理網路上傳輸，還必須要知道對方目的主機的物理地址(MAC)才行。這樣就存在把IP地址變成

物理地址的地址轉換的問題。

    在乙太網環境，為了正確地目的主機傳送報文，必須把目的主機的32位IP

地址轉換成為目的主機48位乙太網的地址(MAC地址)。這就需要在互聯層有一個服務或功能將

IP地址轉換為相應的物理地址(MAC地址)，這個服務或者功能就是ARP協議。

    所謂的「地址解析」，就是主機在發送幀之前將目標IP地址轉換成目標MAC地址的過程，

ARP協議的基本功能就是通過目標設備的ip地址，查詢目標設備的MAC地址，以保證主機

間互相通信的順利進行。

    ARP協議和DNS有點相像之處，不同點是：DNS是在域名和IP之間的解析，另外，ARP協議不需要

配置服務，而DNS要配置服務才行。

    ARP協議要求通信的主機雙方必須在同一個物理網段(即區域網)!

2)關於ARP的小結：

1.ARP全稱「Address Resolution Protocol」；

2.實現區域網內通過IP地址獲取主機的MAC地址；

3.MAC地址48位主機的物理地址，區域網內唯一；

4.ARP協議類似DNS服務，但不需要配置服務。

5.ARP協議是三層協議。

--------------------------------------------------------------------------------------------------------

十、ARP緩存表：

1）每台安裝有TCP/IP協議的電腦都會有一個ARP緩存表(windows 命令提示符里輸入arp -a即可)。

  表裡的ip地址與MAC地址是一一對應的。

arp常用命令:

    arp -a :查所有記錄

    arp -d ：清除

    arp -s ：綁定IP和MAC

2）ARP緩存表是把雙刃劍：

1.主機有了arp緩存表，可以加快ARP的解析速度，減少區域網內廣播風暴。

2.正是有了arp緩存表，給惡意黑客帶來了攻擊伺服器主機的風險，這個就是arp欺騙攻擊。

3.切換路由器，負載均衡器等設備時，可能會導致短時網路中斷。

3）為啥用ARP協議？

  OSI模型把網路工作分為七層，彼此不直接通信打交道，只通過介面。IP地址工作在第三層，

MAC地址工作在第二層。當協議在發送數據包時，需要先封裝第三層IP地址，第二層MAC地址的報頭，

但是協議只知道目的節點的ip地址，不知道目的節點的MAC地址，又不能跨第二、三層，所以得用ARP協議服務，

來幫助獲取目的節點的MAC地址。

4）ARP在生產環境產生的問題及解決辦法：

1.ARP病毒，ARP欺騙

2.高可用伺服器對之間切換時要考慮ARP緩存的問題。

3.路由器等設備無縫遷移時需要考慮ARP緩存的問題，例如：更換辦公室的路由器。

5）ARP欺騙原理：

  ARP攻擊就是通過偽造IP地址和MAC地址對實現ARP欺騙的，如果一台主機中了ARP病毒，

那麼它就能在網路中產生大量的ARP通信量，很快的進行廣播以至於使網路阻塞，攻擊者

只要持續不斷的發出偽造的ARP響應就能更改區域網中目標主機ARP緩存中的IP-MAC條目，

造成網路中斷或者中間人攻擊。

『柒』 基於lvs實現4層負載均衡

章文嵩：研發，原就職alibaba公司，目前就職滴滴；

lvs：2部分組成
ipvsadm：用戶空間的命令行工具；用於管理集群服務及集群服務上的RS；
ipvs：是內核中的框架；工作於內核上的netfilter的INPUT鉤子上的程序，可根據用戶定義的集群實現請求轉發；

注意：在lvs主機上，不允許在INPUT鏈上添加規則，一般不建議與ipvs一同使用filter規則；更不能使用nat規則，任何鏈接追蹤功能都不能開啟，鏈接會話表就限制了會話能力，否則，並發響應能力將大大受到限制；

支持基於TCP UDP SCTP AH EST AH_EST等協議及埠進行調度；

以下部分內容摘自於： https://www.jianshu.com/p/5184c6564ee2

多目標的DNAT；通過將請求報文中的目標地址和目標埠修改為挑選出的某RS的RIP和PORT實現轉發；

ipvs工作在INPUT鏈上，所以只有在INPUT鏈上才能判斷出集群服務，然後才能向後轉發，轉發時，基於某種調度演算法，ipvs自動從後端主機中挑選出一個來響應用戶請求，挑選出的主機IP會成為報文目標IP的修改對象；
定義負載均衡集群服務時，要定義集群服務，集群服務的真實主機；

上圖為lvs-nat的常見的使用場景，其工作流程如下：者態冊
1、客戶端的請求發往Director 的VIP。
2、Director發到客戶端請求報文後，將報文中的目標Ip修改為集群中的選定的RIP，目標埠80也修改成8080，然後將請求報文發往RS。
3、當RS收到請求報文後，在檢查報文的目標IP為自己的RIP後，會接受報文並進行處理響應。響應的源Ip為RIP，目標IP為CIP，埠不變。
4、Director收到RS的響應報文，修改響應報文的源IP為VIP，埠為80，然後轉發給客戶端。
5、客戶端接受響應報文，其源IP為VIP，埠為80，整個過程對於客戶端來說是透明無感知的。

通過修改請求報文的MAC地址，重新封裝一個MAC首部進行轉發；源MAC是DIP所在介面的MAC地址，目標MAC是挑選出的某RS的RIP所在介面的MAC地址；IP首部不會發生變化（依然是CIP<-->閉舉VIP）

lvs服務主機與後端伺服器主機接在同一交換機上，且每個後端主機都配有vip，為了避免地址沖突，把各後端主機配首宏置的vip進行隔離；

隔離的方法有3種

（1）確保前端路由器將目標IP為VIP的請求報文轉發往Director；

（2）RS的RIP可以使用私有地址，也可以使用公網地址；
（3）RS跟Director必須在同一物理網路（基於MAC地址轉發）；RS的網關必須不能指向DIP；
（4）請求報文必須由Directory調度，但響應報文必須不能經由Director；
（5）不支持埠映射；
（6）RS可以使用大多數的OS；一般都為Linux系統；

上圖為lvs-dr的常見的使用場景,其工作流程如下：
1、客戶端的請求會發往Director，此時，客戶端請求報文的源Ip為CIP，目標Ip為Director的VIP。
2、當Director接受到客戶端的請求報文後，Director會在請求報文外封裝一個MAC首部，其源MAC為Director介面的MAC地址，目標MAC為選定RS的MAC地址；
3、當RS收到Director轉發過來的請求報文後，檢查發現請求報文的目標Ip為本地環回介面上配置的VIP，因此會接受報文進行響應處理。另外由於對ARP響應規則做了修改，因此RS不會把響應報文響應給director ，而是響應給GW；
4、客戶端接收響應報文，完成通信。

請求報文源IP為cip，目標IP為vip，到達lvs服務進入INPUT鏈上，在整個ip報文外又加了一層ip首部，即IP報文傳輸IP報文所以叫IP隧道，此時外層源IP為dip，目標IP為某一個被挑選出來遠端的rip，遠端的服務主機收到報文經過不斷拆包後，將響應報文發給客戶端，構建響應報文的源IP為rip，目標IP為cip；

（1）RIP，DIP，VIP全得是公網地址；
（2）RS網關不能指向也不可能指向DIP；
（3）請求報文經由Director轉發，但響應報文將直接發往CIP；
（4）不支持埠映射；
（5）RS的OS必須支持隧道功能；

（1）VIP是公網地址，RIP和DIP一般是私網地址，且通常不再同一網路中，但需要經由路由器互通；
（2）RS收到的請求報文源IP為DIP，因此響應報文將直接響應給DIP；
（3）請求和響應報文都經由Director；
（4）支持埠映射；
（5）RS可以使用大多數的OS；

負載均衡集群中會話保持的方式
（1）原地址哈希；
（2）會話集群；
（3）會話伺服器；

如上圖所示：
1.客戶端的請求會發往Director，此時，客戶端請求報文的源IP為CIP，目標IP為Director的VIP
2.當Director收到客戶端的請求報文時，會將源IP修改為本機的DIP，同時將請求報文中的目標IP修改為後端某個RS的RIP，具體為哪個RS的RIP，取決於LVS使用的具體演算法
3.當RS收到對應的請求報文時，會發現報文的目標IP就是自己的RIP，於是就會接收報文並處理後進行響應。響應報文的源IP則為RIP，目標IP則為DIP
4.當Director收到對應的響應報文時，Director會將響應報文的源IP修改為VIP，目標IP修改為CIP，於是響應報文被發往客戶端。
5.客戶端則會收到響應報文，源IP為VIP，埠為80，而LVS相對於客戶端而言，轉換過程是透明的。

根據其調度時是否考慮後端主機的當前負載，可分為 靜態方法 和 動態方法 兩類

基於客戶端瘦cookie+伺服器端的session機制，在負載均衡時，同一用戶被調度不同後端伺服器時，為了保持會話連接功能不丟失；當第一次用戶請求時，通過調度機制給該用戶分配了一個負責響應後端伺服器，以後來自該用戶的請求就由這個伺服器負責響應了，而不再調度，這就叫 源地址哈希 ；

在調度器上有會話追蹤表，在這個會話追蹤模板中，把用戶的IP地址和挑選的後端伺服器對應的記錄下來，而且定義一個超時時長，在定義的時間內該條目不會刪除；所以，用戶請求到來時，先檢查這個表，把原IP當做k查找，因為哈希就是k/v數據，對應的v就是後端的真實伺服器；如果檢查有用戶的IP對應的記錄，則直接將請求報文發給記錄中對應的後端真實伺服器，而不通過調度；

缺陷 ：當記錄的真實伺服器掛了時，就沒有會話保持記錄了；當內網用戶同過同一IP地址訪問外網時，可能會把內網用戶的所有請求都發往會話記錄表上的真實伺服器，這樣負載均衡能力是受到損害的；

解決辦法

內網用戶請求的目標地址，在調度器上把目標地址綁定到一個代理緩存伺服器上，以後，任何用戶訪問的是該目標地址就發往綁定的代理伺服器，代理伺服器收到請求後，再發往後端伺服器主機，從而實現正向代理負載均衡的作用；

ipvs功能特別強大，一般網站用到的可能性比較小，但面試必會問到；
如果負載不是特別大，使用配置比較麻煩，維護成本較大；

ipvs/ipvsadm的關系相當於netfilter/iptables的關系；
真正提供lvs服務的是ipvs；

因為是根據請求的目標ip地址和目標埠（能識別協議）進行轉發；一個ipvs（Director）主機就可同時為多個集群提供服務進行調度；這就是四層交換的原因；只不過一個Director很有可能成為負載均衡的瓶頸；

注意：單個Director可同時為多個集群提供調度服務；

在centos 7系統上：
判斷內核是否支持ipvs：

判斷ipvsadm程序包是否安裝

ipvsadm -A|E -t|u|f service-address [-s scheler]
-A：增，添加
-E：修改

ipvsadm -D -t|u|f service-address
-D：刪除集群服務；

service-address：定義集群服務的地址
-t：tcp，把tcp埠定義成集群服務，vip:tcp_port；
-u：udp，把udp埠定義成集群服務，vip:udp_port；
-f：Firewalls mark防火牆標記，是一個數字；

-s scheler：定義集群服務的調度方法，默認為wlc加權最少連接；

ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m] [-w weight]
-a：增，添加RS；
-e：改，修改RS；

ipvsadm -d -t|u|f service-address
-d：刪除

-r server-address：向已存在的service-address（集群服務）添加RS的地址；
rip[:port] 埠省略時，表示不做埠映射，與請求服務的埠為同一埠；有些集群服務不支持埠映射，如lvs-dr，lvs-tun，只要響應報文不經過Director都不支持；

查看： ipvsadm -L|l [options]
-L，--list：列出集群服務；
-n, --numeric：數字格式顯示，不反解主機名到ip地址，服務到埠號；
--exact：精確顯示數值，不進行單位換算；
-c, --connection：顯示當前ipvs連接；可查看後端伺服器是否連接；
--stats：統計數據；
--rate：速率；

清空 ：clear
ipvsadm -C

保存和重載
保存：輸出重定向
ipvsadm -S > /PATH/TO/SOME_RULE_FILE
ipvsadm-save > /PATH/TO/SOME_RULE_FILE

重載：輸入重定向
ipvsadm -R < /PATH/TO/SOME_RULE_FILE
ipvsadm-restore < /PATH/TO/SOME_RULE_FILE

清空計數器：
ipvsadm -Z [-t|u|f service-address]

例如：

例如：

添加集群服務，vip為172.18.11.111提供web服務，指明調度方法為rr；不指明為默認wlc；

在集群服務中添加RS地址為192.168.255.2，類型為lvs-nat，權重為1此值無意義，因為前面已經指明使用rr調度演算法

再次添加一個RS

再次添加一個集群服務

在另一個集群服務上添加2個RS

修改集群服務的調度方法為wrr

注意：修改只能改屬性，不能改IP地址；只有刪除集群服務才能從新改IP地址；

修改RS的權重值為10

保存集群服務規則至指定路徑

查看保存的內容：

清空集群服務

重載集群服務配置文件

下次開機時會自動載入集群服務規則：
所以，可把規則保存在/etc/sysconfig/ipvsadm文件中；
[root@VM_0_2_centos ~]# ipvsadm-save > /etc/sysconfig/ipvsadm
一般手動保存後（確保保存無誤），下次開機時，會自動重載此文件；

需要開機自動有效：
[root@VM_0_2_centos ~]# systemctl enable ipvsadm.service

lvs-nat設計要點：
（1）DIP與RIP要在同一IP網路，RIP的網關要指向DIP；
（2）支持埠映射；
（3）是否用到共享存儲，取決於業務需要；

1、配置RS1

2、配置RS2

3、配置Director

打開網卡核心轉發功能；永久有效：

查看內核參數是否打開核心轉發功能

此時，在Director測試，訪問RS1、RS2；

添加ipvs集群：

在另一台虛擬機上測試，調度是否起作用：
測試主機為：172.18.11.111

修改Director上的調度方式為wrr

再到測試主機為：172.18.11.111，測試wrr的調度效果

經過多次請求測試後，有明顯wrr調度效果；
其RS伺服器響應權重比是1:2，即RS1響應1次後RS響應2次；

數據同步：rsync+inotify

響應報文不用經過Director，每個RS必須配置VIP，為了避免地址沖突，有3種方式：

在各主機（Director，RS）均需要配置VIP，因此，要解決地址的沖突的問題，目標是讓各RS上的VIP不可見，僅用接收目標地址為VIP的報文，同時可作為響應報文的源地址；
（1）在前端的網關介面上靜態綁定（vip+mac）；
缺陷：一旦Director掛了，基於高可用轉移另外節點上無法實現；而且，要在網關上有許可權操作；
（2）在各RS上使用arptables；添加規則，拒絕自己的VIP地址向外通告及響應arp解析地址的請求；
（3）在各RS上修改內核參數，來限制arp響應和通告；
注意：要將VIP配置在lo的別名上，不能配置在網卡的別名上；

在各RS上設置arp通告級別即修改兩個內核參數arp_ignore、arp_announce，因為地址是屬於內核的，所以在Linux主機默認的通告方式是所有本機的可用IP地址通告給每個介面；

arp_announce要限制通告級別，每一個網卡僅在把自己的網路地址向所在物理網路中通告，即各網卡間地址絕不交叉通告；arp_announce設置為2；

arp_ignore是限制響應別人arp請求的級別；默認響應請求是無論從哪個介面接收到arp請求，只要本機有這個地址都會響應；限制arp響應級別後可實現，從哪個網卡接收的arp請求，
必須與該介面屬於同一網路時才響應；arp_ignore`設置為1

lvs-dr設計要點：
（1）各主機一個介面即可，但需要在同一物理網路中；
（2）RIP的網關不能指向DIP，RIP和DIP通常應在同一網路，但此二者未必會與VIP在同一網路；
（3）各RS需要先設置內核參數，再設置VIP和路由；

搭建網路環境

1、配置Director

2、配置RS1

3、配置RS2

4、訪問測試

在RS2主機運行

在報文進入時，進行打標記，例如目標IP是VIP埠80，把這類報文分揀出來打標，標記一般為十六進制整數，例如標記1；在input鏈上定義集群服務時，就可判定如果防火牆標記為1，則為集群服務；把本來在input鏈上完成識別、定義集群服務分成了兩步，識別在prerouting做，定義在ipvs（inputing）上實現；

在mangle表上的prerouting鏈上，目標ip（VIP）為172.18.11.7，目標埠為80，打標記為1；

mark標記里包含了IP地址和埠；定義集群服務時使用mark即可；

打標記的方法：
iptables -t mangle -A PREROUTING -d $vip -p $protocol --dport $clusterserverport -j MARK --set-mark #
#：代表十六進制整數；

打標作用 ：提供輔助持久連接功能；在多個埠定義服務時，可把相關作為一個集群來調度；

配置RS1：

配置RS2：

在Director創建CA：

在RS1主機：

在CA服務上簽證並傳回給RS1：

在各RS主機重啟web服務並查看443埠是否監聽：

手動測試直接訪問RS的IP：

測試請求，OK可以響應頁面；-k表示可接受不受信任的頁面響應；

單機測試ok，下面綁定80和443服務，打標記：

『捌』 IPVS(LVS)負載均衡簡介及實驗測試

LVS是Linux Virtual Server的簡稱，也就是Linux虛擬伺服器, 是一個由章文嵩博士發起的自由軟體項目，現在已經是 Linux標准內核的一部分。LVS是一種叫基於TCP/IP的負載均衡技術，轉發效率極高，具有處理百萬計並發連接請求的能力。

LVS的IP負載均衡技術是通過IPVS模塊實現的。IPVS模塊是LVS集群的核心軟體模塊，它安裝在LVS集群作為負載均衡的主節點上，虛擬出一個IP地址和埠對外提供服務。用戶通過訪問這個虛擬服務（VS），然後訪問請求由負載均衡器（LB）調度到後端真實伺服器（RS）中，由RS實際處理用戶的請求給返回響應。

根據負載均衡器轉發客戶端請求以及RS返回響應機制的不同，將IPVS的轉發模式分為三種：VS/NAT，VS/DR，VS/TUN

DR模式下，客戶端的請求包到達負載均衡器的虛擬服務IP埠後，負載均衡器不會改寫請求包的IP和埠，但是會改寫請求包的MAC地址為後端RS的MAC地址，然後將數據包轉發；真實伺服器處理請求後，響應包直接回給客戶端，不再經過負載均衡器。所以DR模式的轉發效率是最高的，特別適合下行流量較大的業務場景，比如請求視頻等大文件。

DR模式的特點：

LB只是將數據包的MAC地址改寫為RS的MAC地址，然後轉發給相應的RS。

因為LB轉發時並不會改寫數據包的目的IP，所以RS收到的數據包的目的IP仍是LB的虛擬服務IP。為了保證RS能夠正確處理該數據包，而不是丟棄，必須在RS的環回網卡上綁定LB的虛擬服務IP。這樣RS會認為這個虛擬服務IP是自己的IP，自己是能夠處理這個數據包的。否則RS會直接丟棄該數據包！

因為LB不會改寫數據包的目的埠，所以RS服務的監聽埠必須和虛擬服務埠一致，否則RS會直接拒絕該數據包。

因為RS收到的請求數據包的源IP是客戶端的IP，所以理所當然RS的響應會直接回給客戶端，而不會再經過LB。這時候要求RS和客戶端之間的網路是可達的。

因為LB在轉發過程中需要改寫數據包的MAC為RS的MAC地址，所以要能夠查詢到RS的MAC。而要獲取到RS的MAC，則需要保證二者位於一個子網，否則LB只能獲取到RS網關的MAC地址。

NAT模式下，請求包和響應包都需要經過LB處理。當客戶端的請求到達虛擬服務後，LB會對請求包做目的地址轉換（DNAT），將請求包的目的IP改寫為RS的IP。當收到RS的響應後，LB會對響應包做源地址轉換（SNAT），將響應包的源IP改寫為LB的IP。

NAT模式的特點：

對於請求包，會進行DNAT；對於響應包，會進行SNAT。

雖然LB在轉發過程中做了NAT轉換，但是因為只是做了部分地址轉發，所以RS收到的請求包里是能看到客戶端IP的。

因為RS收到的請求包源IP是客戶端的IP，為了保證響應包在返回時能走到LB上面，所以需要將RS的默認網關地址配置為LB的虛擬服務IP地址。當然，如果客戶端的IP是固定的，也可以在RS上添加明細路由指向LB的虛擬服務IP，不用改默認網關。

因為需要將RS的默認網關配置為LB的虛擬服務IP地址，所以需要保證LB和RS位於同一子網。

又因為需要保證RS的響應包能走回到LB上，則客戶端不能和RS位於同一子網。否則RS直接就能獲取到客戶端的MAC，響應包就直接回給客戶端了，不會走網關，也就走不到LB上面了。這時候由於沒有LB做SNAT，客戶端收到的響應包源IP是RS的IP，而客戶端的請求包目的IP是LB的虛擬服務IP，這時候客戶端無法識別響應包，會直接丟棄。

IP隧道（IP tunneling）是將一個IP報文封裝在另一個IP報文的技術，這可以使得目標為一個IP地址的數據報文能被封裝和轉發到另一個IP地址。IP隧道技 術亦稱為IP封裝技術（IP encapsulation）。IP隧道主要用於移動主機和虛擬私有網路（Virtual Private Network），在其中隧道都是靜態建立的，隧道一端有一個IP地址，另一端也有唯一的IP地址。
利用IP隧道技術將請求報文封裝轉發給後端伺服器，響應報文能從後端伺服器直接返回給客戶。但在這里，後端伺服器有一組而非一個，所以我們不可 能靜態地建立一一對應的隧道，而是動態地選擇一台伺服器，將請求報文封裝和轉發給選出的伺服器。這樣，可以利用IP隧道的原理將一組伺服器上的網路服 務組成在一個IP地址上的虛擬網路服務。各個伺服器將VIP地址配置在自己的IP隧道設備上。
它的連接調度和管理與VS/NAT中的一樣，只是它的報文轉發方法不同。調度器根據各個伺服器的負載情況， 動態地選擇一台伺服器，將請求報文封裝在另一個IP報文中，再將封裝後的IP報文轉發給選出的伺服器；伺服器收到報文後，先將報文解封獲得原來目標地址為 VIP的報文，伺服器發現VIP地址被配置在本地的IP隧道設備上，所以就處理這個請求，然後根據路由表將響應報文直接返回給客戶。

輪叫調度（Round Robin Scheling）演算法就是以輪叫的方式依次將請求調度不同的伺服器，即每次調度執行i = (i + 1) mod n，並選出第i台伺服器。演算法的優點是其簡潔性，它無需記錄當前所有連接的狀態，所以它是一種無狀態調度。

LB會根據RS上配置的權重，將消息按權重比分發到不同的RS上。可以給性能更好的RS節點配置更高的權重，提升集群整體的性能。

最小連接調度（Least-Connection Scheling）演算法是把新的連接請求分配到當前連接數最小的伺服器。最小連接調度是一種動態調度演算法，它通過伺服器當前所活躍的連接數來估計服務 器的負載情況。調度器需要記錄各個伺服器已建立連接的數目，當一個請求被調度到某台伺服器，其連接數加1；當連接中止或超時，其連接數減一。

加權最小連接調度（Weighted Least-Connection Scheling）演算法是最小連接調度的超集，各個伺服器用相應的權值表示其處理性能。伺服器的預設權值為1，系統管理員可以動態地設置伺服器的權 值。加權最小連接調度在調度新連接時盡可能使伺服器的已建立連接數和其權值成比例。

基於局部性的最少鏈接調度（Locality-Based Least Connections Scheling，以下簡稱為LBLC）演算法是針對請求報文的目標IP地址的負載均衡調度，目前主要用於Cache集群系統，因為在Cache集群中 客戶請求報文的目標IP地址是變化的。這里假設任何後端伺服器都可以處理任一請求，演算法的設計目標是在伺服器的負載基本平衡情況下，將相同目標IP地址的 請求調度到同一台伺服器，來提高各台伺服器的訪問局部性和主存Cache命中率，從而整個集群系統的處理能力。

帶復制的基於局部性最少鏈接調度（Locality-Based Least Connections with Replication Scheling，以下簡稱為LBLCR）演算法也是針對目標IP地址的負載均衡，目前主要用於Cache集群系統。它與LBLC演算法的不同之處是它要 維護從一個目標IP地址到一組伺服器的映射，而LBLC演算法維護從一個目標IP地址到一台伺服器的映射。對於一個「熱門」站點的服務請求，一台Cache 伺服器可能會忙不過來處理這些請求。這時，LBLC調度演算法會從所有的Cache伺服器中按「最小連接」原則選出一台Cache伺服器，映射該「熱門」站 點到這台Cache伺服器，很快這台Cache伺服器也會超載，就會重復上述過程選出新的Cache伺服器。這樣，可能會導致該「熱門」站點的映像會出現 在所有的Cache伺服器上，降低了Cache伺服器的使用效率。LBLCR調度演算法將「熱門」站點映射到一組Cache伺服器（伺服器集合），當該「熱 門」站點的請求負載增加時，會增加集合里的Cache伺服器，來處理不斷增長的負載；當該「熱門」站點的請求負載降低時，會減少集合里的Cache伺服器 數目。這樣，該「熱門」站點的映像不太可能出現在所有的Cache伺服器上，從而提供Cache集群系統的使用效率。

目標地址散列調度（Destination Hashing Scheling）演算法也是針對目標IP地址的負載均衡，但它是一種靜態映射演算法，通過一個散列（Hash）函數將一個目標IP地址映射到一台伺服器。
目標地址散列調度演算法先根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。

源地址散列調度（Source Hashing Scheling）演算法正好與目標地址散列調度演算法相反，它根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。它採用的散列函數與目標地址散列調度演算法 的相同。它的演算法流程與目標地址散列調度演算法的基本相似，除了將請求的目標IP地址換成請求的源IP地址。

客戶端發送對VIP的請求，lvs負載到後端某一台server，後端server處理後，直接封包回送客戶端，源IP地址一定是lvs上面配的那個公網服務地址，也就後端server要配置這個ip，後端server收到的數據包是lvs沒有變動過的（IP：vip），多個server，接入互聯網的server持有相同的IP，是不允許的，因此，必須將後端server中的vip隱藏起來（對外隱藏，對自己可見）

VIP: 虛擬伺服器地址
DIP: 轉發的網路地址
1，和RIP通信：ARP協議，獲取Real Server的RIP：MAC地址；
2，轉發Client的數據包到RIP上，RIP上要求有VIP（對外隱藏VIP）；
RIP: 後端真實主機(後端伺服器)
CIP: 客戶端IP地址

對外隱藏，對內可見

kernel parameter:
目標mac地址為全F，交換機觸發廣播

arp_ignore: 定義接收到ARP請求時的響應級別；
0：只要本地配置的有相應地址，就給予響應；
1：僅在請求的目標(MAC)地址配置請求
到達的介面上的時候，才給予響應；

arp_announce：定義將自己地址向外通告時的通告級別；
0：將本地任何介面上的任何地址向外通告；
1：試圖僅向目標網路通告與其網路匹配的地址；
2：僅向與本地介面上地址匹配的網路進行通告；

lvs 主機：192.168.56.118

RIP主機：也就是需要負載的伺服器，192.168.56.101-103

LVS是Linux Virtual Server的簡寫，意即Linux虛擬伺服器，是一個虛擬的伺服器集群系統，後來將lvs嵌入到linux內核，叫做ipvs

ipvs參數

保存規則
-S

載入此前的規則：
-R

配置lvs的VIP

確保/proc/sys/net/ipv4/ip_forward 內容是1

調整RS的響應。通告級別（每一台RS都配）：

配置RS的VIP（每一台RS都配）

啟動RS上的httpd

編寫測試文件

啟動httpd

客戶端驗證：
RIP：80 能顯示
VIP：80不能顯示

負載伺服器安裝LVS管理工具—ipvsadm

瀏覽器刷新: 訪問vip：80

在DR模式中是所有服務機共享一個VIP，但是在IP隧道模式中，就相當於主代理機將包經過自己打包之後，將IP轉化成公網可傳遞的IP，並將消息經過自己又一次的打包，發送給真實伺服器，真實伺服器對這個請求作出響應，這樣就達到一個可以跨地區的傳輸。並且也避免了DR模式中代理機與真實服務機必須在同一區域網的不便。
說明：
1、當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。此時報文的源IP為CIP，目標IP為VIP 。
2、PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈
3、IPVS比對數據包請求的服務是否為集群服務，若是，在請求報文的首部再次封裝一層IP報文，封裝源IP為為DIP，目標IP為RIP。然後發至POSTROUTING鏈。此時源IP為DIP，目標IP為RIP
4、POSTROUTING鏈根據最新封裝的IP報文，將數據包發至RS（因為在外層封裝多了一層IP首部，所以可以理解為此時通過隧道傳輸）。此時源IP為DIP，目標IP為RIP
5、RS接收到報文後發現是自己的IP地址，就將報文接收下來，拆除掉最外層的IP後，會發現裡面還有一層IP首部，而且目標是自己的lo介面VIP，那麼此時RS開始處理此請求，處理完成之後，通過lo介面送給eth0網卡，然後向外傳遞。此時的源IP地址為VIP，目標IP為CIP

RIP、VIP、DIP全是公網地址
RS的網關不會也不可能指向DIP
所有的請求報文經由Director Server，但響應報文必須不能進過Director Server
不支持埠映射
RS的系統必須支持隧道

LVS伺服器：192.168.56.100
RS伺服器：192.168.56.101，192.168.56.102，192.168.56.103

4.4.5 ### 系統配置 vim /etc/sysctl.conf

4.5.5 ### 系統配置 vim /etc/sysctl.conf

『玖』 負載均衡——LVS DR模式

相比於nginx只能用於7層負載均衡，LVS就比較強大了，能在4層做負載均衡。而且性能和穩定性上LVS也比較占優，畢竟是合入內核模塊，不穩定肯定不行。

LVS通過工作於內核的ipvs模塊來實現功能，其主要工作於netfilter的INPUT鏈上。除此之外，還需要一個用戶態工具，ipvdadm，用於用戶負載集群定義和集群服務管理。

LVS DR模式的流程大概如下：

1、客戶端發送請求至VIP，也就是訪問服務，請求報文源地址是CIP，目標地址為VIP；

2、LVS調度器接收到請求，報文在PREROUTING鏈檢查，確定目的IP是本機，於是將報文發送至INPUT鏈，ipvs內核模塊確定請求的服務是我們配置的LVS集群服務，然後根據用戶設定的均衡策略選擇某台後端RS，並將目標MAC地址修改RIP的MAC地址。因為調度器和後端伺服器RS在同個網段，因此直接二層互通，將請求發給選擇的RS處理；

3、因為報文目的mac是本機，且RS上有配置VIP，因此RS能接收該報文。後端服務處理完請求後，將響應直接發往客戶端，此時源IP地址為VIP，目標IP為CIP。

如下，准備三台伺服器，

機器 作用

192.168.0.100 VIP，LVS調度器對外服務IP

192.168.0.200 RIP，後端web伺服器之一

192.168.0.300 RIP，後端web伺服器之二

上面我們說過lvs依賴於ipvs內核模塊，和ipvsadm用戶態工具。因為centos 7已經默認載入ipvs模塊，因此這一步我們不需要配置。我們只需要安裝ipvsadm工具即可，

yum install -y ipvsadm

然後在LVS調度器上配置VIP，這里我們採用虛擬網卡，當然也可以使用獨立網卡配置，

ifconfig eth0:0 192.168.0.100/24 up

接著配置LVS集群服務，

[root@CentOS-7-2 ~]# ipvsadm -C

[root@CentOS-7-2 ~]# ipvsadm -A -t 192.168.0.100:80 -s rr

[root@CentOS-7-2 ~]# ipvsadm -a -t 192.168.0.100:80 -r 192.168.0.200:80 -g

[root@CentOS-7-2 ~]# ipvsadm -a -t 192.168.0.100:80 -r 192.168.0.300:80 -g

其中，

第一條命令是清空所有規則；

第二條命令是定義LVS服務，並指定負責均衡策略為rr，即輪詢；

第三、四條命令各添加一台後端web伺服器，作為負載均衡節點，並指定為DR模式。

ipvsadm基本命令參數如下：

-A  指定添加的LVS負載均衡虛擬服務

-t  指定虛擬伺服器的IP地址和埠

-s  指定調度演算法，ss為輪詢，wrr為加權輪詢，dh為目標地址散列，sh為源地址散列，lc為最少鏈接等

-a  在對應的VIP下添加RS節點

-g  指定LVS的工作模式為DR模式

-l  指定LVS的工作模式為tunnel模式

-m  指定LVS的工作模式為NAT模式

添加完後端RS，我們可以查看此LVS對應的均衡規則，

[root@CentOS-7-2 ~]# ipvsadm -Ln

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Scheler Flags

  -> RemoteAddress:Port          Forward Weight ActiveConn InActConn

TCP  192.168.0.100:80 rr

  -> 192.168.0.200:80            Route  1      0          0       

  -> 192.168.0.300:80            Route  1      0          0

這里web伺服器使用nginx搭建，因此在兩台RS上安裝nginx，

yum install -y nginx

同時為了後面測試，我們修改web伺服器的index.html內容，

[root@192_168_0_200 ~]# cat /usr/share/nginx/html/index.html

This is 192.168.0.200

[root@192_168_0_300 ~]# cat /usr/share/nginx/html/index.html

This is 192.168.0.300

接著開始進行LVS相關配置，

首先將VIP配置在lo介面上，(注意掩碼要配置成32位，不然RS通信會出問題)

ifconfig lo:0 192.168.0.100/32 up

接著配置對應路由，

route add -host 192.168.0.100 dev lo

然後設置相關系統參數，

echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore

echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

其實嚴格意義上只要配置出口網卡的對應參數就可以了，配置all也只是為了保險而已，文章最後面會有說明。

使用curl命令對vip進行訪問，

[root@CentOS-7-3 /home]# curl  http://192.168.0.100:80

This is 192.168.0.200

[root@CentOS-7-3 /home]# curl  http://192.168.0.100:80

This is 192.168.0.300

[root@CentOS-7-3 /home]# curl  http://192.168.0.100:80

This is 192.168.0.200

[root@CentOS-7-3 /home]# curl  http://192.168.0.100:80

This is 192.168.0.300

可見結果符合我們設置的輪詢策略。

因為當調度器把請求轉發給對應RS時，並沒有修改報文目的IP，因此請求報文目的IP仍為VIP，所以如果RS沒有配置VIP，那麼報文到達RS後就會被丟棄。

arp_ignore=1:只響應目的IP地址為接收網卡上的本地地址的arp請求

因為我們在RS上都配置了VIP，因此此時是存在IP沖突的，當外部客戶端向VIP發起請求時，會先發送arp請求，此時調度器和RS都會響應這個請求。如果某個RS響應了這個請求，則之後該客戶端的請求就都發往該RS，並沒有經過LVS，因此也就沒有真正的負載均衡，LVS也就沒有存在的意義。因此我們需要設置RS不響應對VIP的arp請求，這樣外部客戶端的所有對VIP的arp請求才會都解析到調度器上，然後經由LVS的調度器發往各個RS。

系統默認arp_ignore=0，表示響應任意網卡上接收到的對本機IP地址的arp請求(包括環回網卡上的地址)，而不管該目的IP是否在接收網卡上。也就是說，如果機器上有兩個網卡設備A和B，即使在A網卡上收到對B IP的arp請求，也會回應。而arp_ignore設置成1，則不會對B IP的arp請求進行回應。由於lo肯定不會對外通信，所以如果只有一個對外網口，其實只要設置這個對外網口即可，不過為了保險，很多時候都對all也進行設置。

arp_announce=2:網卡在發送arp請求時使用出口網卡IP作為源IP

當RS處理完請求，想要將響應發回給客戶端，此時想要獲取目的IP對應的目的MAC地址，那麼就要發送arp請求。arp請求的目的IP就是想要獲取MAC地址的IP，那arp請求的源IP呢？自然而然想到的是響應報文的源IP地址，但也不是一定是這樣，arp請求的源IP是可以選擇的，而arp_announce的作用正是控制這個地址如何選擇。系統默認arp_announce=0，也就是源ip可以隨意選擇。這就會導致一個問題，如果發送arp請求時使用的是其他網口的IP，達到網路後，其他機器接收到這個請求就會更新這個IP的mac地址，而實際上並不該更新，因此為了避免arp表的混亂，我們需要將arp請求的源ip限制為出口網卡ip，因此需要設置arp_announce=2。

由上可知，只要RS上的VIP不響應arp請求就可以了，因此不一定要配置在lo上，也可以配置在其他網口。由於lo設備不會直接接收外部請求，因此只要設置機器上的出口網卡不響應非本網卡上的arp請求介面。但是如果VIP配置在其他網口上，除了上面的配置，還需要配置該網口不響應任何arp請求，也就是arp_ignore要設置為8。

這是由於lo設備的特殊性導致， 如果lo綁定192.168.0.200/24，則該設備會響應該網段所有IP(192.168.0.1~192.168.0.254) 的請求，而不是只響應192.168.0.200這一個地址。

根據DR模式的原理，調度器只修改請求報文的目的mac，也就是轉發是在二層進行，因此調度器和RS需要在同一個網段，從而ip_forward也不需要開啟。

『拾』 LVS四種工作模式原理

LVS 是 Linux Virtual Server ：Linux 虛擬伺服器；是一個虛擬的伺服器集群【多台機器 LB IP】。

負載調度器(load balancer) ：它是整個LVS 集群對外的前端機器，負責將client請前孫求發送到一組伺服器[多台LB IP]上執行，而client端認為是返回來一個同一個IP【通常把這個IP 稱為虛擬IP/VIP】
伺服器池(server pool) ：一組真正執行client 請求的伺服器，一般是我們的web伺服器；除了web，還有FTP，MAIL，DNS
共享存儲(shared stored) ：它為 server pool 提供了一個共享的存儲區，很容易讓伺服器池擁有相同的內容，提供相同的服務

常用術語

VS：Virtual Server #虛擬服務，一個抽象的服務，用於最開始接收 web 請求的服務
Director, Balancer #負載均衡器、分發器
RS：Real Server # 真正提供服務的伺服器
CIP: Client IP #用戶端IP，發起請求的客戶端 IP，一般是公網 IP
VIP：Director Virtual IP #負載均衡器虛擬IP
DIP：Director IP #負載均衡器IP
RIP：Real Server IP #真正提供 web 服務的伺服器的 IP

（1）直接路由模式（LVS-DR）
互聯網使用比較多的一種模式
DR模式是通過改寫請求報文的目標MAC地址，將請求發給真實伺服器的，而真實伺服器響應後的處理結果直接返回給客戶端用戶。同TUN模式一樣，DR模式可以極大的提高集群系統的伸縮性。而且DR模式沒有IP隧道的開銷，對集群中的真實伺服器也沒有必要必須支持IP隧道協議的要求。但是要求調度器LB與真實伺服器RS都有一塊網卡連接到同一物理網脊爛段上，必須在同一個區域網環境。

DR模式特點
優點：和TUN（隧道模式）一樣，負載均衡器也只是分發請求，應答包通過單獨的路由方法返回給客戶端。與VS-TUN相比，VS-DR這種實現方式不需要隧道結構，因此可以使用大多數操作系統做為物理伺服器。
缺點：（不能說缺點，只能說是不足）要求負載均衡器的網卡必須與物理網卡在一個物理段上。

（2）NAT模式（LVS-NAT）
NAT模式是通過網路地址轉換的方法來實現調度的。首先調度器(LB)接收到客戶的請求數據包時（請求的目的IP為VIP），根據調度演算法決定將請求發送給哪個後端的真實伺服器（RS）。然後調度就把客戶端發送的請求數據包的目標IP地址及埠改成後端真實伺服器的IP地址（RIP）,這樣真實伺服器（RS）就能夠接收到客戶的請求數據包了。真實伺服器響應完請求後，查看默認路由（NAT模式下我們需要把RS的默認路由設置為LB伺服器。）把響應後的數據包發送給LB,LB再接收到響應包後，把包的源慧野鏈地址改成虛擬地址（VIP）然後發送回給客戶端。

NAT模式特點：
1、NAT技術將請求的報文和響應的報文都需要通過LB進行地址改寫，因此網站訪問量比較大的時候LB負載均衡調度器有比較大的瓶頸，一般要求最多之能10-20台節點
2、只需要在LB上配置一個公網IP地址就可以了。
3、每台內部的節點伺服器的網關地址必須是調度器LB的內網地址。
4、NAT模式支持對IP地址和埠進行轉換。即用戶請求的埠和真實伺服器的埠可以不一致。

（3）Full NAT模式（LVS-FullNAT）
客戶端對VIP發起請求，Director接過請求發現是請求後端服務。Direcrot對請求報文做full-nat，把源ip改為Dip，把目標ip轉換為任意後端RS的rip，然後發往後端，rs接到請求後，進行響應，響應源ip為Rip，目標ip還是DIP，又內部路由路由到Director,Director接到響應報文，進行full-nat。將源地址為VIP，目標地址改為CIP
請求使用DNAT，響應使用SNAT

Full NAT模式特點：
FULL NAT 模式也不需要 LBIP 和realserver ip 在同一個網段；
full nat 跟nat 相比的優點是：保證RS回包一定能夠回到LVS；因為源地址就是LVS==> 不確定
full nat 因為要更新sorce ip 所以性能正常比nat 模式下降 10%

(4）IP隧道模式（LVS-Tunnel）
採用NAT模式時，由於請求和響應的報文必須通過調度器地址重寫，當客戶請求越來越多時，調度器處理能力將成為瓶頸。為了解決這個問題，調度器把請求的報文通過IP隧道轉發到真實的伺服器。真實的伺服器將響應處理後的數據直接返回給客戶端。這樣調度器就只處理請求入站報文，由於一般網路服務應答數據比請求報文大很多，採用VS/TUN模式後，集群系統的最大吞吐量可以提高10倍。
它和NAT模式不同的是，它在LB和RS之間的傳輸不用改寫IP地址。而是把客戶請求包封裝在一個IP tunnel裡面，然後發送給RS節點伺服器，節點伺服器接收到之後解開IP tunnel後，進行響應處理。並且直接把包通過自己的外網地址發送給客戶不用經過LB伺服器。

ip隧道模式特點：
負載均衡器只負責將請求包分發給後端節點伺服器，而RS將應答包直接發給用戶。所以，減少了負載均衡器的大量數據流動，負載均衡器不再是系統的瓶頸，就能處理很巨大的請求量，這種方式，一台負載均衡器能夠為很多RS進行分發。而且跑在公網上就能進行不同地域的分發。
隧道模式的RS節點需要合法IP，這種方式需要所有的伺服器支持」IP Tunneling」(IP Encapsulation)協議，伺服器可能只局限在部分Linux系統上。

四種模式性能比較：
因為DR模式 IP TUNELL 模式都是在package in 時經過LVS ，在package out是直接返回給client，所以二者的性能比NAT 模式高，但IP TUNNEL 因為是TUNNEL 模式比較復雜，其性能不如DR模式；
FULL NAT 模式因為不僅要更換 DST IP 還更換 SOURCE IP 所以性能比NAT 下降10%
4種模式的性能如下：DR ==> IP TUNNEL ==>NAT ==>FULL NAT