LVS負載均衡羣集（三種工做模式原理詳解）

時間 2020-02-26

標籤 lvs 負載均衡羣集三種模式原理詳解欄目負載均衡简体版

原文原文鏈接

LVS負載均衡羣集（三種工做模式原理詳解）

1、前言

在互聯網應用中，隨着站點對硬件性能、響應速度、服務穩定性、數據可靠性等要求愈來愈高，單臺服務器力不從心。因此咱們須要經過一些方法來解決這樣的瓶頸。前端

最簡單的方法就是使用價格昂貴的大、小型的主機；但這樣在大多數企業中顯然是不可取或者說不現實的。那麼咱們就須要經過多個普通服務器構建服務器羣集。算法

2、相關概念概述

2.1何爲LVS？

LVS——Linux Virtual Server，即Linux虛擬服務器（虛擬主機、共享主機），虛擬主機在這裏就再也不贅述了，相信你們都明白。數據庫

而LVS是一個虛擬的服務器集羣系統，其實現的是一個高性能、高可用的服務器。目前LVS已經被集成到Linux內核模塊中。後端

2.2LVS的構成

①從物理層面上講，LVS的主要組成：安全

負載調度器(load balancer/ Director)，它是整個集羣對外面的前端機，負責將客戶的請求發送到一組服務器上執行，而客戶認爲服務是來自一個IP地址(咱們可稱之爲虛擬IP地址)上的。
服務器池(server pool/ Realserver)，是一組真正執行客戶請求的服務器，執行的服務通常有WEB、MAIL、FTP和DNS等。
共享存儲(shared storage)，它爲服務器池提供一個共享的存儲區，這樣很容易使得服務器池擁有相同的內容，提供相同的服務

以下圖所示：服務器

補充：通常爲了實現高可用會使用兩臺以上的調度服務器，做爲備份，提升安全性。（後面的實驗部署DR模式+keepalive會使用兩臺負載調度服務器）網絡

②從軟件層面上講，LVS 由2部分程序組成，包括 ipvs 和 ipvsadm。架構

1.ipvs(ip virtual server)：工做在內核空間的一段代碼，叫ipvs，是真正生效實現調度的代碼。併發

2.ipvsadm：另一段是工做在用戶空間，叫ipvsadm，負責爲ipvs內核框架編寫規則，定義誰是集羣服務，而誰是後端真實的服務器(Real Server)，而後由內核代碼實現真正的調度算法及功能。負載均衡

2.3何爲羣集？

羣集，或者說集羣，英文是cluster，由多臺主機構成，可是對外只表現爲一個總體（同一服務），客戶端是沒法察覺到究竟有多少臺服務器，而且對本身訪問的是哪一臺真實服務器一無所知。

根據針對目標差別，可將羣集分爲負載均衡羣集、高可用羣集（HA）、高性能運算羣集三類。下文會逐一介紹。

2.4如何理解負載均衡？

負載均衡——load balance，顧名思義，就服務器方面而言，能夠理解爲多個服務器上所承載的「壓力」相對平衡，這裏的「壓力」指的是服務器上所須要響應的各類資源請求或者服務，而且是相對平衡的，畢竟服務器的性能等諸多方面都未必一致。

簡單舉個例子來講明一下負載均衡的含義，若是說你須要打一桶水，你能夠選擇用一隻手拎着，可是可能會比較累，若是你用雙手拎着兩個桶來裝與之等量且平均分配的水，就比較輕鬆了。

其實負載均衡本質上就是這樣的原理，將任務相對平均分配給多個服務器處理，這樣既能夠減輕一臺服務器的壓力，也能提升響應與處理的速度。

2.5羣集的類型

2.5.1負載均衡羣集

負載均衡+羣集，能夠提升應用系統的響應能力、處理更多訪問請求、減小延遲，從而得到高併發、高負載的總體性能。

固然，負載均衡的處理並非簡單的平均分配，而是依賴於實際狀況下的調度分流算法。而算法就涉及開發人員的思想和生產環境的實際狀況了。

2.5.2高可用羣集

提升應用系統的可靠性、減小主斷時間，確保服務的連續性，達到高可用的容錯效果。

HA（high availability）的工做方式包括雙工和主從兩種模式。這就涉及到「去中心化」和「中心化」思想，而上一篇文章所介紹的MHA就是典型的master高可用羣集的架構模式，只不過咱們使用的是MySQL數據庫，從而搭成該高可用的架構。

2.5.3高性能運算羣集

高性能運算羣集——High Performance Computer Cluster，提升應用系統的CPU運算速度、擴展硬件資源和分析能力，得到至關於大型、超級計算機的高性能運算能力。

高性能運算羣集的高性能依賴於「分佈式運算」、「並行計算」，經過專用硬件和軟件將多個服務器的CPU、內存等資源整合在一塊兒，實現只有大型計算機具有的計算能力。

負載均衡羣集是目前企業用的最多的羣集類型，羣集的負載調度技術有三種工做模式：地址轉換——NAT、IP隧道——ip Tunnel、直接路由——Directing Route。

下面咱們來逐一介紹一下這三種模式。

3、負載均衡羣集工做模式

3.1NAT模式

地址轉換——Network Address Translation。咱們結合下圖分析該模式：

根據上圖結構咱們暫時不考慮共享存儲，（下篇文章會將該模式的架構流程以及配置過程詳細給出，使用NFS做爲共享存儲）

咱們首先來看實線部分，也就是client端請求服務的部分。

1.客戶端進行請求服務器，對於客戶而言，直接訪問的目標IP地址不多是下面的三臺或多臺真實服務器（Real Server），而是LVS負載調度服務器（固然，該服務器也能夠是一個真實服務器（至關於身兼數職），看本身的想法和需求）。通常而言咱們在負載調度器上是將其充當爲一個網關的功能，因此它有（至少有）兩個網卡，而且網段不一樣。在這臺服務器上咱們須要進行NAT地址轉換，通常是經過ip地址映射的方法，來實現數據請求和數據響應的功能。固然這須要咱們理解NAT的原理和設置方法。

2.請求到達負載調度服務器，進行相關處理將數據按照設置的調度算法進行任務分配；

3.響應該調度算法的真實服務器將開始執行本身的任務而且返回相關數據，而全部的真實服務器的網關都指向負載調度器，依據NAT原理進行ip地址映射，將數據從外網口發送給客戶端。

整個過程當中客戶端對真實服務器的內部結構是不清楚的，事實上也無需瞭解。

該模式的最爲典型的特色就是：

數據的請求和數據的返回都須要通過負載調度服務器（load balancer/Director）

那麼這在高負載的應用場景中，該模式中的負載調度服務器就成爲服務性能的瓶頸。出現這樣的狀況則必然有對應解決的方法。下面咱們將介紹其餘兩種模式——TUN模式和DR模式。

3.2TUN模式

該模式爲IP Tunnel模式，簡稱TUN模式，採用開放式的網絡結構。負載調度器僅做爲客戶機的訪問入口，各節點經過各自的Internet鏈接直接回應客戶機，而再也不通過負載調度器。

服務器節點分散在互聯網中的不一樣位置，具備獨立的公網ip地址，經過專用IP隧道與負載調度器相互通訊。

以下圖所示：

IP隧道原理的核心思想就是：基於將一個IP報文封裝在另外一個IP報文的技術，從而使得目標爲一個IP地址的數據報文能被封裝和轉發到另外一個IP地址。

於是，IP隧道技術亦稱爲IP封裝技術(IP encapsulation)。IP隧道主要用於移動主機和虛擬私有網絡(Virtual Private Network)，在其中隧道都是靜態創建的，隧道一端有一個IP地址，另外一端也有惟一的IP地址。

調度器根據服務器的負載狀況，動態地選擇一臺服務器，將請求報文封裝在另外一個IP報文中，再將封裝後的IP報文轉發給選出的服務器;服務器收到報文後，先將報文解封得到原來目標地址爲 VIP 的報文，服務器發現VIP地址被配置在本地的IP隧道設備上，因此就處理這個請求，而後根據路由表將響應報文直接返回給客戶。

該模式的典型特色：

除了負載調度服務器是公網IP地址，後端服務器和其網關也都是公網IP地址

而這樣形成的結果就是，不論從安全性方面考慮，仍是從購買地址和管理的成本方面考慮，這種模式都是很是不可取的。因此，DR模式就應運而生了。