雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
這篇文章我們主要把思想講清楚，具體的LVS的搭建流程，我們在後面的文章中會講。
LVS簡介
什麼是LVS？
LVS是Linux Virtual Server的簡寫，意即Linux虛拟伺服器，是一個虛拟的伺服器叢集系統。本項目在1998年5月由章文嵩博士成立，是中國國内最早出現的自由軟體項目之一。目前LVS已經被內建到Linux核心子產品中。
LVS能做什麼？
LVS主要用于多伺服器的負載均衡。
它工作在網絡層，可以實作高性能，高可用的伺服器叢集技術。
它廉價，可把許多低性能的伺服器組合在一起形成一個超級伺服器。
它易用，配置非常簡單，且有多種負載均衡的方法。
它穩定可靠，即使在叢集的伺服器中某台伺服器無法正常工作，也不影響整體效果。
可擴充性也非常好。
性能幾乎可以和F5相媲美（個人意見）。
LVS的負載均衡結構圖
LVS的負載均衡結構圖，大概的使用場景是這樣的，關于高可用的地方，我們後面會進行介紹，别着急哦！
LVS的核心元件和專業術語
核心元件
LVS的管理工具和核心子產品 Ipvsadm/IPVS：
- Ipvsadm：用于空間的指令行工具，用于管理叢集服務及叢集服務上的RS等
- IPVS：工作于核心上的程式，可根據使用者定義的叢集實作請求轉發
專業術語
- VS：Virtual Server，虛拟服務
- Director：負載均衡器，圖1的LVS排程器
- Balancer：分發器，圖1的LVS排程器
- RS：Real Server，後端請求處理伺服器，圖1的Web服務
- CIP：Client IP，用戶端IP
- VIP：Director Virtural IP，負載均衡虛拟IP，應該出現在圖1的LVS排程器上
- DIP：Director IP負載均衡器IP
- RIP：Real Server IP，後端請求處理伺服器IP
LVS的常用幾種模式
LVS的DR模式（最常用）
LVS的DR模式最最穩定，是使用最多的一種模式。
什麼是ARP廣播？
在了解LVS的DR模式之前，我們需要先了解一下ARP廣播，要不然我在講後面内容的時候會用到這個，已經是大佬的同學跳過吧，小白請認真讀完。
ARP廣播：根據IP位址找MAC位址。
主機A的IP位址為192.168.1.1，MAC位址為0A-11-22-33-44-01；
主機B的IP位址為192.168.1.2，MAC位址為0A-11-22-33-44-02；
當主機A要與主機B通信時：
第1步：根據主機A上的路由表内容，IP确定用于通路主機B的轉發IP位址是192.168.1.2。然後A主機在自己的本地ARP緩存中檢查主機B的比對MAC位址。
第2步：如果主機A在ARP緩存中沒有找到映射，它将詢問192.168.1.2的硬體位址，進而将ARP請求幀廣播到本地網絡上的所有主機。源主機A的IP位址和MAC位址都包括在ARP請求中。本地網絡上的每台主機都接收到ARP請求并且檢查是否與自己的IP位址比對。如果主機發現請求的IP位址與自己的IP位址不比對，它将丢棄ARP請求。
第3步：主機B确定ARP請求中的IP位址與自己的IP位址比對，則将主機A的IP位址和MAC位址映射添加到本地ARP緩存中。
第4步：主機B将包含其MAC位址的ARP回複消息直接發送回主機A。
第5步：當主機A收到從主機B發來的ARP回複消息時，會用主機B的IP和MAC位址映射更新ARP緩存。本機緩存是有生存期的，生存期結束後，将再次重複上面的過程。主機B的MAC位址一旦确定，主機A就能向主機B發送IP通信了。
LVS的DR模式的請求流程圖
申明：首先我們先來申明一下, 舉個例子：我們在請求一個域名如：
https://www.naixuejiaoyu.com/,我們首先會通路的是DNS，DNS會根據我們的域名給我們解析VIP位址（一般情況是一個VIP，也有一種情況是一個域名對應對個VIP或者IP），我們為了簡單，下圖就是畫的一般情況。
注意：前提是我們的VIP位址都是配置在LO上的。
提問一：三個VIP，為什麼DNS會把請求打到LVS上，而沒有打到RS上呢？
帶着這個問題我們來思考，可能才更好的幫助我們來了解LVS的DR模式，要解決這個問題，我們就需要提到我們剛開始提到的ARP請求了，我們需要在LVS，RS1，RS2上都需要綁定三個VIP，但是需要在RS1和RS2上需要額外的做一些工作，那就是禁止ARP請求。
我們在RS上需要執行以下的操作，更改Linux的核心參數，如下：
為了幫助大家更好的了解三個VIP之間的關系，我們舉個例子來說：LVS伺服器是正常的，當DNS在請求的時候會解析出來VIP的位址，但是并不知道，具體的MAC位址是哪一個，那LVS伺服器會通過ARP請求，告知别人自己的MAC位址，别人就緩存下來了，反之，我們的RS是禁止ARP請求的，其實他就是一個啞巴，讓他不能說話的，别人就不知道他的MAC位址，即使他有VIP位址，是以DNS隻會把請求轉發到LVS上，而不能轉發到RS上。
既然RS禁止了ARP請求，那LVS如何把請求轉發給RS呢？
解決了上面的問題，那新的問題又來了，既然我們說RS禁止了ARP請求，那LVS是如何把請求轉發給RS的呢？其實我告訴你，是通過修改MAC位址，進行轉發的，這個是DR模式的核心，那LVS又是如何知道RS的MAC位址呢，其實是通過ARP請求獲知的，那有些人就會問我，你這個不是自相沖突嗎？别擔心，接着看。
首先我們看一下，我們的VIP都是綁定在lo上的，我們要了解上面我提出的這個問題，就要深入的了解一下Linux核心參數的配置資訊了。
有關arp_ignore的相關介紹：
看不懂沒關系，既然要解決，我們肯定是要深入剖析的，下面我們來簡單的翻譯一下：
arp_ignore：定義對目标位址為本地IP的ARP詢問不同的應答模式
0 - （預設值）：回應任何網絡接口上對任何本地IP位址的ARP查詢請求
1 - 隻回答目标IP位址是來訪網絡接口本地位址的ARP查詢請求
2 -隻回答目标IP位址是來訪網絡接口本地位址的ARP查詢請求，且來訪IP必須在該網絡接口的子網段内
3 - 不回應該網絡界面的ARP請求，而隻對設定的唯一和連接配接位址做出回應
4-7 - 保留未使用
8 -不回應所有（本地位址）的ARP查詢
好了我們設定的arp_ignore核心參數是1，就是隻回答目标IP位址是來訪網絡接口本地位址的ARP查詢請求，即：隻回答本地網卡eth0上的ARP請求。
我們就拿上面的圖舉例：
- LVS伺服器：
DIP：綁定的網卡eth0：192.168.1.110
VIP：綁定的網卡是lo:0：192.168.147.150
- RS伺服器：
RIP：綁定的網卡是eth0：192.168.1.111
VIP：綁定的網卡lo:0：192.168.147.150
其實用戶端在發送ARP請求的時候，詢問的是VIP的MAC位址，LVS伺服器進行了正确的ARP請求回應，而當循環RS伺服器的MAC位址的時候，這個時候，我們網卡的IP位址是：192.168.1.111/112，RS是做過閹割的，是以不給與回應。
當LVS伺服器發起ARP請求的時候，循環192.168.1.111或者192.168.1.112的MAC位址，這個時候，RS本地的網卡位址，就是LVS需要通路的IP位址，就進行ARP請求的回應，所有LVS伺服器就緩存了RS伺服器的MAC位址。
上面的問題是不是都迎刃而解了，快來給我瘋狂打call吧！
**RS是如何做到，直接傳回給用戶端的呢？
**
這個問題太好，我們一般接收的請求，應該都是哪裡來，哪裡回，那RS是如何做到直接傳回個用戶端的呢？
好的，既然我們前面提到了在RS上進行設計Linux核心參數的更改，分别是arp_ignore和arp_announce兩個核心參數，既然arp_ignore是禁止ARP請求的，我們上面已經介紹過了，arp_announce核心參數是做什麼的呢？我們下面就來講解一下這個參數的作用吧。
既然存在，那就是有意義的，arp_announce這個核心參數，其實就是讓RS可直接傳回給用戶端。
有關arp_announce的相關介紹：
arp_announce：對網絡接口上，本地IP位址的發出的，ARP回應，作出相應級别的限制，确定不同程度的限制，宣布對來自本地源IP位址發出ARP請求的接口。
0 - （預設）在任意網絡接口（eth0，eth1，lo）上的任何本地位址
1 - 盡量避免不在該網絡接口子網段的本地位址做出ARP回應。當發起ARP請求的源IP位址是被設定應該經由路由達到此網絡接口的時候很有用，此時會檢查來訪IP是否為所有接口上的子網段内IP之一，如果該來訪IP不屬于各個網絡接口上的子網段内，那麼将采用級别2的方式來進行處理。
2 - 對查詢目标使用最适當的本地位址，在此模式下将忽略這個IP資料包的源位址并嘗試選擇與能與該位址通信的本地位址。首要是選擇所有的網絡接口的子網中外出通路子網中包含該目标IP位址的本地位址，如果沒有合适的位址被發現，将選擇目前的發送網絡接口或其他的有可能接受到該ARP回應的網絡接口來進行發送。
其實我們RS可以直接傳回給用戶端，就是arp_announce設定為2起到的作用，他會自主的選擇一個位址，即VIP位址，傳回給我們的用戶端，其實就是利用了一個欺騙的技術，讓用戶端不會把我們傳回的請求丢棄掉，讓他以為RS傳回的請求是正常的。
LVS的DR模式請求IP位址追蹤
Client在發起請求之前，會發一個ARP廣播的包，在網絡中找“誰是VIP”，由于所有的伺服器，LVS和RES都有VIP，為了讓Client的請求送到LVS上，是以必須讓RS不能響應Client發出的ARP請求，（這也是為什麼要禁止RES上ARP的請求和響應）下面就是LVS轉發的事情了：
Client向目标VIP發送請求，LVS接收；此時IP包和資料資訊如下：
LVS根據負載均衡的算法，選擇一台RS，然後把RS1的MAC位址作為目的MAC位址，發送到區域網路中。
是的，你沒有看錯，src_ip位址和dst_ip是不發生變化的，我們前面說到，DR模式是通過修改MAC位址進行轉發的，IP位址的請求是不發生變化的，這個和後面的NAT模式有很大的差別。
RS1在區域網路中收到這個請求以後，發現目的IP和本地比對，于是進行處理，處理完成以後，直接把源IP和目的IP直接對調，然後經過網關直接傳回給使用者。
在RS上，是可以直接傳回給用戶端的。
LVS的NAT模式
LVS的NAT模式，類似于iptables的DNAT，但是支援多目标的轉發。
注意：自己在本機做實驗的時候，用戶端不能和RS在同一網段，不然直接響應，不走網關。
優點
- 配置簡單，通用性強
- 支援映射（NAT映射表）
- RIP可以是私網IP，用于LVS與RS之間通訊
缺點
- LVS和RS必須在一個VLAN中（RS将LVS配置為網關，如果不在一個子網回包會經過路由器網關直接路由走，LVS沒機會修改資料包）
- 進出流量都需要LVS進行處理，LVS容易成為叢集瓶頸
- 需要将LVS配置為RS的網關
LVS的NAT模式的請求流程圖
LVS的NAT模式請求流程圖
1.用戶端發起請求到LVS機器上。
2.LVS伺服器根據LVS的算法，轉發給RS伺服器（改變目的IP為RS1或者RS2），并記錄連接配接資訊，隻改變目的IP，源IP不變。
3.RS收到request請求包之後，發現目的IP是自己的IP處理請求，然後走網關，經過LVS，RS設定的官網為LVS的eth0。
4.LVS收到reply包後，修改reply包的源IP位址為VIP，發給用戶端。
5.用戶端接收到請求，校驗IP請求的包是否符合要求，符合則接收，不符合就丢棄。
抓包分析包請求流程
1、用戶端發起請求：
在LVS伺服器上，eth0網卡抓取的包如下：
2、LVS處理請求：
在LVS伺服器上抓包，在eth0網卡抓包。
3、LVS的eth0作為RS的網關位址，需要經過LVS周轉。
4、傳回用戶端
包經過eth0傳回VIP伺服器，然後經過VIP傳回給用戶端，源IP改成VIP，目的IP不變。
LVS的TUN模式（隧道模式）不常用
什麼是IP隧道技術？
簡單來說IP隧道技術就是将 【IP資料包】 的上面再封裝一層【IP資料包】， 然後路由器根據最外層的IP位址路由到目的地伺服器，目的地伺服器拆掉最外層的IP資料包，拿到裡面的IP資料包進行處理。
原理
使用者請求負載均衡伺服器，當IP資料包到達負載均衡伺服器後，根據算法選擇一台真實的伺服器，然後通過IP隧道技術将資料包原封不動再次封裝，并發送給真實伺服器，當這個資料包到達真實伺服器以後，真實伺服器進行拆包（拆掉第一層的IP包）拿到裡面的IP資料包進行處理，然後将結果直接傳回給用戶端。
Tunnel原理流程圖
LVS的FullNat模式
FullNat模式聽名字也是NAT模式的一種，那Full是什麼意思呢？就是全部的NAT模式，NAT模式中，我們是需要設定RS的網關位址為LVS的内網伺服器位址，那FullNat模式，就是我們最通常容易了解的類型，我們通過下面的圖來了解吧，主要是就包的請求位址改變有不同。
NAT模式：
FullNat：
LVS負載均衡排程算法
根據前面的介紹，我們了解了LVS的三種工作模式，但不管實際環境中采用的是哪種模式，排程算法進行排程的政策與算法都是LVS的核心技術，LVS在核心中主要實作了一下十種排程算法。
- 輪詢排程
輪詢排程（Round Robin，簡稱'RR'）算法就是按依次循環的方式将請求排程到不同的伺服器上，該算法最大的特點就是實作簡單。輪詢算法假設所有的伺服器處理請求的能力都一樣的，排程器會将所有的請求平均配置設定給每個真實伺服器。
- 權重輪詢排程
權重輪詢（Weight Round Robin，簡稱'WRR'）算法主要是對輪詢算法的一種優化與補充，LVS會考慮每台伺服器的性能，并給每台伺服器添加一個權值，如果伺服器A的權值為1，伺服器B的權值為2，則排程器排程到伺服器B的請求會是伺服器A的兩倍。權值越高的伺服器，處理的請求越多。
- 最小連接配接排程
最小連接配接排程（Least Connections，簡稱'LC'）算法是把新的連接配接請求配置設定到目前連接配接數最小的伺服器。最小連接配接排程是一種動态的排程算法，它通過伺服器目前活躍的連接配接數來估計伺服器的情況。排程器需要記錄各個伺服器已建立連接配接的數目，當一個請求被排程到某台伺服器，其連接配接數加1；當連接配接中斷或者逾時，其連接配接數減1。（叢集系統的真實伺服器具有相近的系統性能，采用最小連接配接排程算法可以比較好地均衡負載。)
- 權重最小連接配接排程
權重最少連接配接（Weight Least Connections，簡稱'WLC'）算法是最小連接配接排程的超集，各個伺服器相應的權值表示其處理性能。伺服器的預設權值為1，系統管理者可以動态地設定伺服器的權值。權重最小連接配接排程在排程新連接配接時盡可能使伺服器的已建立連接配接數和其權值成比例。排程器可以自動問詢真實伺服器的負載情況，并動态地調整其權值。
- 基于局部的最少連接配接
基于局部的最少連接配接排程（Locality-Based Least Connections，簡稱'LBLC'）算法是針對請求封包的目标IP位址的 負載均衡排程，目前主要用于Cache叢集系統，因為在Cache叢集客戶請求封包的目标IP位址是變化的。這裡假設任何後端伺服器都可以處理任一請求，算法的設計目标是在伺服器的負載基本平衡情況下，将相同目标IP位址的請求排程到同一台伺服器，來提高各台伺服器的通路局部性和Cache命中率，進而提升整個叢集系統的處理能力。LBLC排程算法先根據請求的目标IP位址找出該目标IP位址最近使用的伺服器，若該伺服器是可用的且沒有超載，将請求發送到該伺服器；若伺服器不存在，或者該伺服器超載且有伺服器處于一半的工作負載，則使用'最少連接配接'的原則選出一個可用的伺服器，将請求發送到伺服器。
- 帶複制的基于局部性的最少連接配接
帶複制的基于局部性的最少連接配接（Locality-Based Least Connections with Replication，簡稱'LBLCR'）算法也是針對目标IP位址的負載均衡，目前主要用于Cache叢集系統，它與LBLC算法不同之處是它要維護從一個目标IP位址到一組伺服器的映射，而LBLC算法維護從一個目标IP位址到一台伺服器的映射。按'最小連接配接'原則從該伺服器組中選出一一台伺服器，若伺服器沒有超載，将請求發送到該伺服器；若伺服器超載，則按'最小連接配接'原則從整個叢集中選出一台伺服器，将該伺服器加入到這個伺服器組中，将請求發送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，将最忙的伺服器從伺服器組中删除，以降低複制的程度。
- 目标位址散列排程
目标位址散列排程（Destination Hashing，簡稱'DH'）算法先根據請求的目标IP位址，作為散列鍵（Hash Key）從靜态配置設定的散清單找出對應的伺服器，若該伺服器是可用的且并未超載，将請求發送到該伺服器，否則傳回空。
- 源位址散列排程U
源位址散列排程（Source Hashing，簡稱'SH'）算法先根據請求的源IP位址，作為散列鍵（Hash Key）從靜态配置設定的散清單找出對應的伺服器，若該伺服器是可用的且并未超載，将請求發送到該伺服器，否則傳回空。它采用的散列函數與目标位址散列排程算法的相同，它的算法流程與目标位址散列排程算法的基本相似。
- 最短的期望的延遲
最短的期望的延遲排程（Shortest Expected Delay，簡稱'SED'）算法基于WLC算法。舉個例子吧，ABC三台伺服器的權重分别為1、2、3 。那麼如果使用WLC算法的話一個新請求進入時它可能會分給ABC中的任意一個。使用SED算法後會進行一個運算
A：（1+1）/1=2，B：（1+2）/2=3/2，C：（1+3）/3=4/3，就把請求交給得出運算結果最小的伺服器。
- 最少隊列排程
最少隊列排程（Never Queue，簡稱'NQ'）算法，無需隊列。如果有realserver的連接配接數等于0就直接配置設定過去，不需要在進行SED運算。
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/live立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-04-19
本文作者：淩晶
本文來自：“
dockone”，了解相關資訊可以關注“dockone”