LVS (一) 原理

LVS原理概述

負載均衡就是，在多個提供相同服務主機的前段，增長一個分發器，根據用戶請求，而後根據某種方式或者策略，將用戶請求分發到提供服務的主機上。同時負載均衡應用還應該提供對後其後端服務健康檢查的功能。

如何轉發取決於調度算法，有2種算法一個是RR一個是WRR。用戶看到的是負載均衡的地址，通常還會對負載均衡作高可用，這樣才能保證業務的持續性。
負載均衡有2大類：

• 硬件：F5的BIG IP；Citrx的Netcaler
• 軟件:
• 四層負載均衡（LVS）：TCP/IP層，相似一個路由設備，根據用戶請求的套接字（三層IP）和四層的端口協議類型，將請求分發至後端主機。LVS的發明者是中國人。
• 七層負載均衡（Nginx和Haproxy）：Nginx主要是對HTTP、SMTP、POP3和IMAP協議作負載均衡，是一個7層代理，只負責解析有限的7層協議；Haproxy主要是對HTTP作負載均衡，另外還能夠對常見的TCP/IP層應用作負載均衡，好比MYSQL，還有SMTP。

四層和七層的有什麼區別？

通常七層的負載均衡叫作代理或者叫反向代理。四層和七層的主要區別在於四層只解析到TCP/IP層，它不在解析更高層，說白了就是再也不繼續拆包，因此四層的比七層的性能更好，可是缺點是沒有高級特性，網康設備就是工做在七層的，因此它能夠有不少高級功能，好比查看用戶訪問了那些網站，其實就是對HTTP請求作的解析。對負載均衡設備來講，工做在七層的能夠根據用戶請求的URL來作負載均衡。並且七層負載均衡通常都是針對特定一種或者幾種（不會是全部，也就是針對某一個方面）作解析，同時它還支持對解析出來的東西作一些修改而後在向後端分配。不過相對來說七層的性能比四層的略低（在相同硬件配置和相同請求量的前提下），不過在生產環境中七層的更能貼近實際需求，因此在選擇使用哪一種負載均衡的時候要根據業務特性和需求來進行判斷。

LVS能夠解析三層和四層請求，只要是TCP/IP協議均可以解析，假設一個WEB服務器集羣，使用默認80端口，其中一臺主機是172.16.100.1，若是負載均衡器收到一塊兒請求，那麼它就會把請求轉發到該主機上，這個過程有點相似於NAT，可是還不一樣，由於它能夠向後轉發到多臺主機上。

DNAT的工做過程：

用戶請求IP：PORT地址A（這個地址是路由器的地址），路由器收到這個地址後會查看本身的過濾表，若是找到匹配的配置項，就會修改數據包的目標地址爲後端主機的真實地址，而後把數據包放到轉發隊列，而後進行轉發。若是發現沒有匹配項，則認爲這個請求是請求給路由器本身的，由於請求帶有端口號，路由器會檢查本身是否開啓了對應端口的進程，若是有就說明是訪問該進程的，若是沒有就會給請求發起方報錯。

LVS其實也是借鑑了DNAT的工做方式，LVS工做在Linux的內核空間上。可是不一樣的是LVS收到請求會直接修改請求的數據包中的目標地，而後進行轉發。

在Iptables中，ipbables只是用來寫規則的，真正執行的是netfilter；在LVS中也是相似的結構，ipvsadmin是管理工具（工做在用戶空間的工具），ipvs是執行的且工做在內核中。Ipvs是工做在input鏈上（Input鏈是Iptables所用的到的Linux內核框架的一部分），一旦用戶請求到了input鏈，就會被IPVS捕獲，而後IPVS就會去檢查數據包，若是它發現請求是一個集羣服務就會修改數據包，而後轉發。若是IPVS發現這個請求不是對集羣服務的請求，就會把這個請求轉發到用戶空間（Linux系統的用戶空間）。這一點和iptables有點不太同樣，因此iptables和LVS不能同時在一臺Linux主機上使用。因此LVS中的IPVS必須工做在內核中。因此基於IP和端口的轉發就是四層轉發。

一個負載均衡調度器能夠爲多個集羣服務提供服務，功能上能夠，可是出於性能考慮通常不會這麼作，因此一個負載均衡調度器只會爲一個集羣服務提供服務。

LVS的服務器有2個網卡，對外接收請求的網卡的IP叫作VIP，也就是虛擬IP，其實也是真實的IP地址，至少這樣稱呼，相對於內部真正的應用服務器而言；對內的網卡的IP叫作DIP，也就是轉發IP；而真實的應用服務器網卡的IP叫作RIP。用戶電腦的IP叫作CIP。

LVS的三種類型

LVS-NAT模式

對於這種類型，負載均衡調度器須要有2個網絡接口，一個面對互聯網，一個面對內網，也就是上面的圖形。屬於串聯模式。至關於在LVS後面組成一個私有網絡。
實現原理就是把用戶的請求的地址修改成後端真是服務器的IP地址來而後進行轉發。工做機制和DNAT同樣。

源地址是CIP，目標地址是VIP，而後修改數據包，挑選一個後端服務器，而後就把數據包轉發到該後端服務器，這時候數據包的源IP是CIP，目標IP則是某一臺主機的RIP。
當主機返回信息的時候，轉發器會在作一次轉發，修改數據包。

在這種模式下對於用戶請求的進出都要通過轉發器，因此轉發器的壓力相對較大。在這種模式下後端應用最多10個，但通常都會少於10個。

基本法則：

• 轉發器、應用服務器都要在同一子網中（轉發器的DIP和應用服務器組成一個私有網絡）
• 應用服務器的網關要指向DIP
• RIP一般都是私有地址，並且僅能夠和DIP通信
• 轉發器能夠實現端口映射，例如80轉換到8080
• 應用服務器能夠是任何操做系統
• 單一轉發器可能成爲整個集羣的瓶頸尤爲是在大規模場景下

通常企業不使用NAT模型，哪怕應用服務器比較少。

缺陷：轉發器和應用服務器必須在同一子網中

LVS-DR 直接路由模式

LVS服務器和應用服務器都是單網卡，LVS和應用服務器並聯在交換機上。

在這個模型上就是請求進來被髮送到LVS上，LVS的內核空間的IPVS截取，而後分析，若是是訪問集羣服務，就轉發到被LVS選中的應用服務器上，應用服務器處理完成後，直接返回數據給客戶端，而再也不通過LVS，這樣就減小了LVS的工做負擔，同時應用服務器也不用和LVS組成一個私有網絡。

這裏就有一個問題，咱們知道轉發器在會把數據包中的目標IP更換爲RIP進行轉發，那麼應用服務器處理完成後返回結果，返回數據包的源IP會是RIP，目標IP則是CIP，這時就不對了，由於請求進來的時候目標IP是LVS上的VIP。因此爲了解決這個問題，LVS和全部應用服務器上都配置了VIP。

那麼這裏就又有一個問題，若是都配置相同的VIP，那麼就會衝突，並且路由器也不知道該發給誰，因此這裏就用到了網卡別名。在LVS上它其實配置了VIP和DIP，雖然只有一個網卡，VIP配置在網卡上，DIP配置在網卡別名上。在應用服務器上，RIP是不一樣的這個是確定的，VIP是同樣的，這個VIP也是配置在網卡別名上並且是隱藏的，它不用來接收任何請求，接收數據仍是RIP來完成，這個VIP只有在應用服務器響應請求的時候把它做爲源地址時使用，固然實際使用的網卡開始那個配置了RIP的網卡，在通信層面上VIP不起做用，它只是做爲數據包的源地址使用。

不過須要注意的是，在DR模式中，轉發器會修改請求的數據包的地址，可是修改不是把VIP替換成RIP，而是修改了地址（源MAC和目標MAC）。由於從路由器進來之後，會把報文封裝成幀，會加入源MAC和目標MAC，路由器的內網口會把源MAC地址寫成本身的內網口MAC，目標寫成LVS物理網卡的MAC地址，而後LVS收到之後會修改幀裏面的目標MAC地址（原來爲LVS網卡的MAC地址）爲被挑選的應用服務器的MAC地址，修改源MAC地址（原來路由器內網口的MAC地址）爲本身網卡的MAC地址，而不是修改目標IP地址。

當應用服務器收到數據包之後，拆掉MAC地址，看到的數據包的源IP是CIP也就是客戶端的IP，而目標IP就是VIP，並且應用服務器上經過網卡別名已經設置了VIP，因此它會認爲這就是個本身的。處理完請求後須要返回數據，由於客戶端是請求的VIP，因此應用服務器就用VIP來封裝數據包，這樣就直接響應出去了，而不須要再通過LVS。
這樣的話就LVS的性能就會有很大提升，由於請求數據包都很小，響應報文都比較大。

說明：不管是不是DR模式，來自網絡層的IP報文都最終都會被封裝成幀。因此路由器接收到IP數據包以後會先到到數據鏈路層後通過LLC子層和MAC子層進行協議頭封裝，最終造成以太網MAC幀，送達到主機。

基本法則：

• 集羣節點和轉發器必須在同一物理網絡內，由於它使用MAC地址轉發
• RIP的地址可使用公網IP
• 轉發器僅處理入棧請求，響應報文由應用服務器之間發往客戶端
• 集羣節點不能使用DIP做爲網關
• 這種模式下轉發器不支持端口映射
• 大多數操做系統均可以是應用服務器，由於應用服務器須要隱藏VIP
• DR模式性能強，能夠處理比NAT模式更多的主機

缺陷：全部應用服務器都暴露在公網，就算它用私有地址，可是也要保障它能夠和互聯網直接通信，不然它響應的報文沒法到達客戶端。

LVS-TUN 隧道模式

DR模式下集羣節點要在同一物理網絡內，那有一種場景若是要實現異地容災，兩個機房在不一樣城市甚至是不一樣國家，那怎麼辦？這就用到隧道模式。

在隧道模式下LVS即不替換VIP也不修改MAC地址，而是經過在數據報文外層再套一層報文來封裝。

由於客戶端請求發過來的時候源IP是CIP，目標IP是VIP，因此LVS要轉發到其餘地區的應用服務器上這隻能在三層協議上進行也就是IP報文，若是你替換了VIP，那麼應用服務器響應客戶端的時候就有問題，因此就會在原有的IP報文上在套一層來封裝，把LVS的DIP做爲源IP，而應用服務器的RIP做爲目標IP，而後進行轉發。當應用服務器收到數據包之後，拆開第一層，而後發現裏面的數據包有CIP和VIP，應用服務器上也有VIP（跟DR模式同樣使用網卡別名而後隱藏），就會認爲是發給本身的，而後作出處理最後響應請求，同時封裝響應請求的時候目標是CIP，源IP則使用VIP地址。

在這種模式下LVS和應用服務器要支持隧道機制。

基本法則：

• 集羣節點能夠跨越互聯網部署
• 應用服務器的RIP必須是公網地址（可路由的）
• 轉發器僅處理入棧請求
• 響應報文直接發送給客戶端不通過LVS，也就是說應用服務器的網關指向公網網關
• 支持隧道功能的操做系統才能夠成爲應用服務器
• 不支持端口映射

LVS-FULLNAT 模式

Linux內核發展到2.6.32之後才引入的一種類型，這個類型必需要打補丁才能使用。不過如今大多使用CentOS 7因此無需補丁。

這個模型是採用NAT基礎可是解決了應用服務器和調度器能夠在不一樣子網中。由於是NAT模型因此應用服務器就不會暴露在互聯網上，同時也實現了應用服務器能夠跨網段部署。

所謂FULLNAT就是把數據包的源地址和目標地址都作修改，入棧的時候把CIP
+VIP的數據包修改成DIP+RIP的數據包，這樣就能夠發送到應用服務器上，當應用服務器響應請求的時候，一樣適用DIP+RIP的數據包，這樣就保障確定會發到LVS主機上，而後調度器再次修改數據包的源地址和目標地址，改爲CIP+VIP而後發送給客戶端。

LVS的調度算法

調度算法就是從LVS的後端應用服務器中挑選一個進行轉發。調度算法有10種，那麼10種又分紅2大類，靜態方法和動態方法。

靜態方法：

只根據算法自己進行調度和分配請求，這種方法中RR和WRR有缺陷就是用戶會話沒法保持，好比在電商網站上，用戶第一次的請求被轉發到了A服務器，用戶第二次的操做請求被轉發到了B服務器，因此這就形成了用戶第一次會話請求數據丟失。因此要想解決就只能使用Session複製或者創建單獨的服務器。

• RR，也就是輪詢一個挨一個的逐個轉發，這種方法不考慮服務器自己的硬件性能。
• WRR，加權輪詢，也就是給每一個服務器設置權重，權重高的多分配。
• SH：源地址哈希，這個方法主要是增長了實現Session綁定功能，只要來源於同一個IP的就定向到相同的應用服務器。可是它反均衡，就是會把同一IP地址出口的全部請求都轉發到同一服務器，好比通常公司出口IP是一個，几几百人都用這一個公網IP上網。由於LVS是工做在四層的，因此它也只能根據IP來識別會話。沒法像F5那樣七層設備根據COOKIE來識別，COOKIE對於每個計算機來講都是惟一，即便你們都用同一公網IP上網。
• DH：目標地址哈希，這個應用場景很少，它主要的做用就是保證在LVS前面有多臺防火牆的時候，用戶請求從哪一個防火牆進來最後響應也從哪一個防火牆出去。

動態方法：

根據算法和應用服務器的負載狀況綜合分析來以爲轉發到哪一個應用服務器。

• LC（Least Connection）：最少連接數方法。也就是哪一個服務器的鏈接數少就給哪一個的，可是在TCP中，鏈接有2種狀態，一個是正在傳送數據的叫作活動鏈接、另一個是沒有傳輸數據可是鏈接沒有斷叫作非活動鏈接，這兩種鏈接所須要的資源是不一樣的，顯然活動鏈接須要服務器的資源多，而非活動鏈接僅須要維持一個與服務器的會話就行。因此這種方法是考慮應用服務器的負載（活動鏈接數*256+非活動鏈接），這個計算結果數小的勝出，若是結果都同樣就輪詢。不過這種方法是不考慮權重的，其基本方法仍是輪詢，只是增長了一個計算負載的前置條件。
• WLC（Weighted LC）:加權最少鏈接算法，這個算法跟LC大致同樣只是考慮了權重而不簡單的輪詢，（活動鏈接數*256+非活動鏈接）/權重，數最小的勝出，若是都同樣仍是輪詢。
• SED（Shorting expect delay）：最少指望延遲，它是一種改進型的WLC，爲了不鏈接少的時候正好挑選了最差性能的服務器，（活動鏈接數+1）*256/權重。
• NQ（Nerver Queue）：永不排隊，第一次根據權重輪詢一遍，以後根據SED算法來分配。
• LBLC（Locality-based least connection）：基於本地的最少鏈接，至關於DH+LC算法，主要用於後端的應用服務器是緩存服務器的時候，來提升緩存命中率，不過不多用這種算法。
• LBLCR（Rerplicated and Locality-based least connection）：帶複製的基於本地最少鏈接，主要用於後端的應用服務器是緩存服務器的時候。來提升緩存命中率，不過不多用這種算法。

補充知識：

Session會話保存的方法有三種：

• Session綁定：將同一請求者的鏈接始終保持鏈接在同一服務器上，這種方式沒有容錯能力，若是用戶請求的會話在A服務器上，那麼A服務器一旦故障，那麼用戶請求會話的數據就丟失了。另外還有一個缺陷是反均衡，也就是一旦綁定該用戶的會話請求都會到這個服務器上，不管這個服務器是否繁忙，在大規模環境中，這種方法也不適用。
• Session複製：在全部應用服務器上創建Session集羣，基於單播、多播或者廣播的方式實現Session傳遞，讓每一個應用服務器都擁有一份相同的完整會話數據，在大規模集羣環境中，這種方式不適用。
• 創建單獨的Session服務器，全部應用服務器都共享該會話服務器，並且該服務器也要實現高可用，不然會有單點故障。

LVS的缺陷是：它不會考慮應用服務器的健康情況，若是應用服務器故障它也會選擇。