LVS三種負載均衡詳解及實作

轉自http://www.cnblogs.com/MacoLee/p/5856858.html

本文排版有問題，請前往原位址檢視

LVS安裝使用詳解

LVS是Linux Virtual Server的簡稱，也就是Linux虛拟伺服器, 是一個由章文嵩博士發起的自由軟體項目，它的官方站點是www.linuxvirtualserver.org。

現在LVS已經是Linux标準核心的一部分，在Linux2.4核心以前，使用LVS時必須要重新編譯核心以支援LVS功能子產品，但是從Linux2.4核心以後，已經完全内置了LVS的各個功能子產品，無需給核心打任何更新檔，可以直接使用LVS提供的各種功能。

LVS主要用于伺服器叢集的負載均衡。其優點有：

linux核心2.4版本以上的基本都支援LVS，要使用lvs，隻需要再安裝一個lvs的管理工具：ipvsadm

其實LVS的本身跟iptables很相似,而且連指令的使用格式都很相似,其實LVS是根據iptables的架構開發的,那麼LVS的本身分成了兩個部分：

ipvsadm元件定義規則的格式：

ipvsadm指令方法

lvs排程算法（不區分大小寫）可以分為兩大類：

lvs排程算法

LVS三種工作模式：NAT（位址轉換）、DR（直接路由）、TUN（隧道）

NAT模型其實就是通過網絡位址轉換來實作負載均衡的。下面是它的流程：

LVS-NAT的性能瓶頸：

在LVS/NAT的叢集系統中，請求和響應的資料封包都需要通過負載排程器(Director)，當真實伺服器(RealServer)的數目在10台和20台之間時，負載排程器(Director)将成為整個叢集系統的新瓶頸。

大多數Internet服務都有這樣的特點：請求封包較短而響應封包往往包含大量的資料。如果能将請求和響應分開處理，即在負載排程器(Director)中隻負責排程請求而響應直接(RealServer)傳回給客戶，将極大地提高整個叢集系統的吞吐量。

在RealServer上部署httpd服務并測試

realserver部署

在Director上部署ipvs服務并測試

添加叢集服務

測試通路http頁面

測試

更改LVS的排程算法并壓力測試，檢視結果

lvs排程算法壓力測試

永久儲存LVS規則并恢複

ipvsadm儲存規則

模拟清空ipvsadm規則來恢複

ipvsadm恢複規則

LVS-NAT服務控制腳本部署在Director上

lvs-nat-director.sh

分享LVS-NAT一鍵安裝腳本

lvs-nat-install.sh

上面說了NAT模型的實作方式,那麼NAT模型有個缺陷,因為進出的每個資料包都要經過Director Server,當叢集系統負載過大的時候Director Server将會成為整個叢集系統的瓶頸,

那麼DR模型就避免了這樣的情況發生,DR模型在隻有請求的時候才會經過Director Server, 回應的資料包由Real Server 直接響應使用者不需要經過Director Server,其實三種模型中最常用的也就是DR模型了。

下面是它的工作流程：

編輯DR有三種方式（目的是讓使用者請求的資料都通過Director Server）

第一種方式：在路由器上明顯說明vip對應的位址一定是Director上的MAC，隻要綁定，以後再跟vip通信也不用再請求了，這個綁定是靜态的，是以它也不會失效，也不會再次發起請求，但是有個前提，我們的路由裝置必須有操作權限能夠綁定MAC位址，萬一這個路由器是運作商操作的，我們沒法操作怎麼辦？第一種方式固然很簡便，但未必可行。

第二種方式：在給别主機上（例如：紅帽）它們引進的有一種程式arptables,它有點類似于iptables,它肯定是基于arp或基于MAC做通路控制的，很顯然我們隻需要在每一個real server上定義arptables規則，如果使用者arp廣播請求的目标位址是本機的vip則不予相應，或者說相應的封包不讓出去，很顯然網關（gateway）是接受不到的，也就是director相應的封包才能到達gateway，這個也行。第二種方式我們可以基于arptables。

第三種方式：在相對較新的版本中新增了兩個核心參數(kernelparameter)，第一個是arp_ignore定義接受到ARP請求時的相應級别;第二個是arp_announce定義将自己位址向外通告是的通告級别。【提示：很顯然我們現在的系統一般在核心中都是支援這些參數的，我們用參數的方式進行調整更具有樸實性，它還不依賴于額外的條件，像arptables,也不依賴外在路由配置的設定，反而通常我們使用的是第三種配置】

arp_ignore:定義接受到ARP請求時的相應級别

arp_announce：定義将自己位址向外通告是的通告級别;

在Real Server1 和Real Server2上做以下配置

realserver配置

在Director Server上做以下配置

director配置

Director腳本

Direcotor.sh

RealServer腳本

RealServer.sh

TUN的工作機制跟DR一樣，隻不過在轉發的時候，它需要重新包裝IP封包。這裡的real server（圖中為RIP）離得都比較遠。

使用者請求以後，到director上的VIP上，它跟DR模型一樣，每個realserver上既有RIP又有VIP，Director就挑選一個real server進行響應，但director和real server并不在同一個網絡上，這時候就用到隧道了，Director進行轉發的時候，一定要記得CIP和VIP不能動。

我們轉發是這樣的，讓它的CIP和VIP不動，在它上面再加一個IP首部，再加的IP首部源位址是DIP，目标位址的RIP的IP位址。收到封包的RIP，拆掉封包以後發現了裡面還有一個封裝，它就知道了，這就是隧道。

其實資料轉發原理和DR是一樣的，不過這個我個人認為主要是位于不同位置（不同機房）；LB是通過隧道進行了資訊傳輸，雖然增加了負載，可是因為地理位置不同的優勢，還是可以參考的一種方案；

在LVS模型中，director不負責檢查RS的健康狀況，這就使得當有的RS出故障了，director還會将服務請求派發至此伺服器，這種情況對使用者、企業都是很不爽的，哪個使用者倒黴說不定就遇到類似了。

為了讓Director更人性化、可靠還要給director提供健康檢查功能；如何實作？Director沒有自帶檢查工具，隻有手動編寫腳本給director實作健康狀态檢查功能！