LVS介紹及工作原理
1. LVS 介紹
? ?LVS,Linux Virtual Server 的簡寫，意即 Linux 虛擬服務器，是一個虛擬的服務器集群系統，可以在 UNIX/Linux 平臺下實現負載均衡集群功能。
? ?文章：LVS項目介紹
? ? ? ?LVS集群體系結構
? ? ? ?LVS集群的IP負載均衡技術
? ? ? ?LVS集群中的負載調度
? ?早在 Linux 內核 2.2 時，IPVS 就已經以內核補丁的形式出現。從 2.4.23 版本開始時，IPVS 軟件就是合并到 Linux 內核的常用版本的內核補丁的集合。從 2.4.24 以后已經成為 Linux 官方標準內核的一部分。
? ?從上圖可以看出，LVS 負載均衡調度技術是在 Linux 內核中實現的，因此被稱為 Linux 虛擬服務器。我們使用該軟件配置 LVS 時候，不能直接配置內核中的 IPVS，而需要使用 IPVS 的管理工具 IPVSADM 進行管理，當然也可以用 Keepalived 軟件管理。
2. LVS 體系結構與工作原理
? ?LVS 集群負載均衡器接收服務的所有入棧客戶端計算機請求，并根據調度算法決定哪個集群節點應該處理回復請求。負載均衡器（簡稱 LB）。
? ?LVS 虛擬服務器的體系結構如下所示，一組服務器通過高速的局域網或者地理分布的廣域網相互連接，在它們的前段有一個負載調度器（Load Banlancer）。負載均衡調度器能無縫地將網絡請求調度到真實服務器上，從而使得服務器集群的結構對客戶是透明的，客戶訪問集群系統提供的網絡服務就像訪問一臺高性能，高可用的服務器一樣。客戶程序不受服務器集群的影響不需做任何修改。系統的伸縮性通過在服務集群中透明地加入和刪除一個節點來達到，通過檢測節點或服務進程故障和正確地重置系統達到高可用性。由于負載調度技術是在 Linux 內核中實現的，稱為 Linux 虛擬服務器。
LVS工作模式與原理
1. LVS 相關術語命名約定
名稱 | 縮寫 | 說明 |
虛擬 IP 地址 | VIP | VIP 為 Director 用于向客戶端計算機提供服務的 IP 地址。以別名存在或輔助 IP 形式存在 如：www.etiantian.org?域名就要解析到 VIP 上提供服務 問：為什么不把 VIP 像DIP一樣綁定在網卡上呢? 答：因為如果綁定在網卡上，那么當有主從 Director 時，就會發生沖突。 |
真實 IP 地址 | RIP | 在集群下面節點上使用的 IP 地址 |
Director 的 IP 地址 | DIP | Director 用于連接內外網絡的 IP 地址，物理網卡上的 IP 地址 |
客戶端主機 IP 地址 | CIP | 客戶端用戶計算機請求集群服務器的 IP 地址，改地址用作發送給集群的請求的源 IP 地址 |
? ?LVS 集群內部的節點稱為真實服務器（Real Server）,也叫集群節點。請求集群服務的計算機稱為客戶端計算機。
2. LVS 三種工作模式與原理
IP虛擬服務器軟件 IPVS
? ?在調度器的實現技術中，IP 負載均衡技術是效率最高的。在已有的 IP 負載均衡技術中有通過網絡地址轉換將一組服務器構成一個高性能、高可用的虛擬服務器，我們稱為?VS/NAT?技術（Virtual Server via Network Address Translation）。大多數商業化的 IP 負載均衡調度器產品都使用 NAT 方法。
? ?在分析 VS/NAT 的缺點和網絡服務的非對稱性的基礎上，我們提出通過 IP 隧道實現虛擬服務器的方法?VS/TUN?和通過直接路由實現虛擬服務器的方法?VS/DR，他們可以極大地提高系統的伸縮性。所以 IPVS 實現了這三種 IP 負載均衡技術，大致原理如下：
NAT模式—網絡地址轉換
? ?Virtual Server via Network Address Translation（VS/NAT）
? ?通過網絡地址轉換，調度器 LB 重寫請求報文的目標地址，根據預設的調度算法，將請求分配給后端的真實服務器；真實服務器的響應報文處理之后，返回時必須要通過調度器時，經過調度器時報文的原地址被重寫，再返回給客戶，完成整個調度過程。
? ?過程：客戶端主機請求是攜帶著報文（CIP:VIP 80）,請求到達 LB 之后，LB 將其轉換為（CIP:RIP1 9000）,然后該請求會到達 RIP1 進行處理，處理完畢之后返回報文（RIP:CIP）,由于 RIP1 找不到 CIP 便會通過網關出去（RIP 應該設置網關為 DIP）,這樣報文到達網關（DIP）之后，調度器再進行改寫為（VIP:CIP 80）,然后將數據包發給 CIP，這樣 CIP 接收到的報文就是（VIP:CIP）。
? ?總結：
????1.NAT 技術獎請求的報文和響應的報文通過調度器地址重寫然后再轉發給內部的服務器，報文返回時再改寫原來的地址。
? ? ?2.主需要在調度器 LB 上配置 WAN 公網 IP 即可，調度器也要有私網 LAN IP 和節點內部通信。內部節點配置 LAN IP。
? ? ?3.每臺內部 RS 節點的網關，要配成 LB 的 LAN 內物理網卡地址，這樣才能確保數據返回仍然經過 LB。
? ? ?4.由于請求與回傳數據都經過負載均衡器，因此訪問量大時有瓶頸。
? ? ?5.支持對 IP 及端口進行轉換，即 10.0.0.1:80 可以轉換到 10.0.0.2:8080
TUN模式-隧道模式
? ?采用 NAT 技術時，由于請求和響應報文都必須經過調度器地址重寫，當客戶請求越來越多時，調度器處理能力將成為瓶頸。為了解決此事，調度器把請求報文通過 IP 隧道轉發至真實服務器，而真實服務器將服務器響應處理后直接返回給客戶，這樣調度器只處理請求入站報文，由于一般網絡服務應答數據比請求報文大很多，采用 VS/TUN 技術后，集群系統最大吞吐量可以提高 10 倍。
? ?VS/TUN 工作流程如下圖：它的連接調度和管理與 VS/NAT 中的一樣，只是它的報文轉發方法不同。調度器根據各個服務器的負載情況，動態地選擇一臺服務器，調度器將原請求報文封裝在另一個 IP 報文中，再將封裝后的 IP 報文轉發給選定的真實服務器；真實服務器收到報文后，先將收到的報文解封獲得原來目標地址為 VIP 的報文，服務器發現 VIP 地址被配置在本地的 IP 隧道設備上，所以就處理這個請求，然后根據路由表將相應報文直接返回給客戶。（這種模式數據包封裝了一個 IP 報文到達真實服務器上之后解包發現 VIP 地址不是本身的，會不接受此報文，所以這種模式的每個真實服務器必須在 lo 網卡上配置VIP地址，這樣才能讓解開后的報文發現 VIP 地址在本地有，才能接受并處理）。
? ?問題：
? ?1.當用戶通過互聯網請求負載均衡器的時候，目標地址是 VIP，通過路由器到達負載均衡集群網絡中，當到達網絡中之后，由于要和局域網主機進行通信，但又沒有調度器的 MAC 地址，那么就會發 ARP 廣播，廣播到達局域網各個主機之后就有可能真實服務器和調度器都應答。
? ?答：讓所有真實服務器的網卡抑制 arp，讓所有真實服務器不要響應目標地址是 vip 的請求，只讓 vip 去響應。?
? ?2.為什么要在 lo 網卡上綁定 vip 而不再其它網卡上綁定呢?
? ?答：防止局域網 IP 地址沖突，lo 是一個屬于本地的網卡，在 lo 上綁定在局域網中不會沖突。
? ?總結：
????1.負載均衡器通過把請求的報文通過 IP 隧道的方式把請求的報文不經過源目的地址的改寫，而是直接封裝成另外的 IP 報文
? ? ?2.由于真實服務器處理請求后直接響應給客戶端，因此真實服務器最好有一個外網 IP 地址，效率更高。如果是內網也能出去，但是勢必會經過一個 NAT 映射，NAT 服務器又可能成為瓶頸，因為所有服務器都走 NAT 服務器。
? ? ?3.由于調度器只處理入站請求的報文，因此集群系統的吞吐量可以提高 10 倍，但隧道模式會封裝報文再傳輸也會帶來一定的系統開銷。TUN 模式適合 LAN/WAN。
? ? ?4.TUN 模式的 LAN 環境不如 DR 模式效率高，有的系統還要考慮 IP 隧道的支持問題。
? ? ?5.所有的真實服務器還要綁定 VIP，抑制 ARP 等，配置復雜
? ? ?6.LAN 環境一般多采用 DR 模式，WAN 環境可以用 TUN 模式，但是當前在 WAN 環境下，更多的被 DNS+haproxy/nginx等取代
DR模式—直接路由模式
? ?Virtual Server via Direct Routing
? ?VS/DR 模式通過改寫請求報文的目標 MAC 地址，將請求發送到真實服務器，而真實服務器將相應后的處理結果直接返回給可以。同 VS/TUN 技術一樣，VS/DR 技術可以極大地提高集群系統的伸縮性。而且，這種方法沒有 IP 隧道開銷，對集群中的真實服務器也沒有必須支持 IP 隧道協議的要求，但是要求調度器與真實服務器都有一塊網卡連在同一物理網段上，即必須在同一個局域網環境。
? ?VS/DR 的工作流程如圖，它的連接調度和管理與 VS/NAT 和 VS/TUN 中的一樣，它的報文轉發方式又有不同，將報文直接路由給目標服務器。在 VS/DR 中，調度器根據各個服務器的負載情況，連接數多少等，動態地選擇一臺服務器，不修改目的IP地址和目的端口，也不封裝 IP 報文，而是將請求的數據幀的 MAC 地址改為選出服務器的 MAC 地址，再將修改后的數據幀在于服務器組的局域網中發送。因為數據幀的 MAC 地址是選出的服務器，所以服務器肯定可以收到這個數據幀，從中可以獲得該 IP 報文。當真實服務器發現報文的目標地址不在本地網絡設備時，就會拒絕處理，所以需要在本地綁定 VIP 地址，真實服務器處理這個報文，然后根據路由表將響應報文直接返回給客戶。
???總結：
????1.通過在 LB 上修改數據包的目的 MAC 地址實現轉發。注意，源地址仍然是 VIP 地址。
? ? ?2.由于只有請求的報文經過調度器，而處理后響應的報文無需經過調度器，因此訪問量大時使用效果特別好。（和 NAT 比）
? ? ?3.因 DR 模式是通過 MAC 地址改寫的機制實現的轉發，因此所有節點和 LB 只能在一個局域網 LAN 中。（小缺點）
? ? ?4.需要注意 RS 節點的 VIP 的綁定（lo:vip1,lo:vip2...）和 ARP 抑制問題。
? ? ?5.強調下：RS 節點的默認網卡不需要是 LB 的 DIP，直接是 IDC 公網機房分配的上級路由器的 IP.（RS 帶有外網地址情況）
? ? ?6.由于 DR 模式僅進行了 MAC 地址的改寫，因此調度器 LB 無法改變請求的報文的目的端口（和 NAT 要區別）
? ? ?7.調度器 LB 支持幾乎所有 Unix，Linux 系統，目前無 Windows 版，但是 RS 節點可以是 Windows (LVS NAT)
? ? ?8.效率高但是配置比較麻煩。訪問量不是特別大的公司可用 haproxy/nginx 取代之。日：2000W PV 下都可用 haproxy+nginx
? ? ?9.直接對外的訪問業務，例如 web 服務做 RS 節點，最好用公網 IP 地址。不直接對外的業務，如 Mysql，存儲用內網IP地址
VS/NAT | VS/TUN | VS/DR | |
Real Server | config dr gw | Tunneling | Non-arp device/tie vip |
Server Network | private | LAN/WAN | LAN |
Server Number | 10~20（low） | 100（high） | 100（high） |
Real Server Gateway | load balancer | own router | own router |
| 優點 | 地址和端口轉換 | WAN環境，加密數據 | 性能最高 |
缺點 | 效率低 | 系統需要支持隧道協議 | 不能跨出 LAN |
3. LVS 調度算法
? LVS 的調度算法決定了如何在集群節點之間分布工作符合。當 Director 調度器收到來自客戶端計算機訪問它的 VIP 上的集群服務的入站請求時，Director 必須決定哪個集群節點應該處理請求。Director 可用于做出該決定的調度方法分成兩個基本類別：
? 固定調度方法：rr、wrr、dh、sh
? 動態調度算法：wlc、lc、lblc、lblcr、sed、nq
算法 | 說明 |
rr | 輪詢調度（Round-Robin），將請求一次分配不同的 RS，也就是 RS 中均攤請求。這種算法簡單，但是只適合于 RS 處理性能相差不大的情況 |
wrr | 加權輪詢調度（Weighted Round-Robin），它將依據不同 RS 的權值分配任務。權值越高的 RS 將優先獲得任務，并且分配到連接數將比權值低的 RS 更多。相同權值的 RS 得到相同數目的連接數。 |
lc | 最小連接數調度（Least-Connection），IPVS 表存儲了所有的活動的鏈接。把新的連接請求發送到當前連接數最小的 RS |
wlc | 加權最小連接數調度（Weighted Least-Connection），假設各臺 RS 的權值依次為Wi（i=1..n），當前的 TCP 連接數依次為 Ti（i=1..n）依次選取 Ti/Wi 為最小的 RS 作為下一個分配的 RS |
lblc | 基于地址的最小連接數調度（Locality-Based Least-Connection），將來自同一目的地址的請求分配給同一臺 RS 節點，如果這臺服務器尚未滿負荷，則分配連接數 |
生成環境 LVS 調度算法選型
? 1.一般的網絡服務，如 http、mail、mysql 等，常用調度算法：rr、wlc、wrr
? 2.web cache 和 db cache：基于局部性的最少鏈接 lblc、帶復制的基于局部性最少鏈接 lblcr
? 3.防火墻集群：源地址散列調度 sh 和 目標地址散列調度 dh，可以保證整個系統的唯一出入口。
? 4.處理時間相對較長的網絡服務：最短預期延時調度 sed 和不排隊調度 nq
? 實際使用中，這些算法的使用范圍不限于這些。最好參考內核中的調度算法的實現原理，根據具體的業務需求合理的選型。
常見 LVS 負載均衡高可用解決方案：
? 1.通過自己開發腳本解決：比較笨重，不推薦
? 2.heartbeat + lvs + ldirectord 配置：比較復雜，不易控制，很少使用
? 3.Piranha，Redhat 的一款基于 Web 的配置軟件：可以省去手工配置繁瑣工作，但是出問題不知道原理，不推薦
?4.Keepalived+LVS：極力推薦的最優方案，簡單、易用、高效
轉載于:https://blog.51cto.com/pkbai/1874247
)
