Keepalived+lvs 搭建高可用負載均衡

時間 2019-11-17

標籤 keepalived+lvs keepalived lvs 搭建可用負載均衡欄目負載均衡简体版

原文原文鏈接

本站點中止更新，請訪問:blog.coocap.comhtml

不瞭解負載均衡高可用的童鞋，強烈建議先看keepalived+nginx高可用負載均衡：java

傳送門（求粉）：http://www.cnblogs.com/mrlinfeng/p/6146866.htmlnode

lvs不過多介紹，能看到這裏的應該都瞭解了。linux

先介紹環境和各個服務器角色：

這裏統一使用的是linux centOS6.5 32位系統，內核版本：2.6.32-431.el6.i686
lvs服務器稱爲DirectorServer，簡稱DS，主機爲DS-Master，ip爲192.168.200.129，備機爲DS-Slave，ip爲192.168.200.130

後端真實服務器稱爲RealServer，簡稱RS，各有一臺tomcat web服務器,ip爲192.168.200.128,192.168.200.131

虛擬IP（Virtual IP 簡稱VIP）爲192.168.200.88nginx

最終架構圖：
web

ok，如今開始幹活。算法

搭建RS環境

這個太簡單，沒壓力，搞兩個linux虛擬機嘛，而後裝java嘛，而後上傳tomcat解壓嘛，搞一個web項目jsp頁面嘛，發佈訪問以下便可：apache

固然，還有一個131的同樣，不說了後端

搭建DS環境

首先兩臺DS須要安裝LVS，包括兩部分，IPVS模塊和IPVSadm管理模塊。
IPVS模塊在linux內核2.6及以上已經有了不須要安裝，查看linux內核版本的命令是：uname -atomcat

若是你的linux版本在2.6以上，那麼是已經安裝IPVS的，若是不是2.6版本以上的，那就本身安裝吧，固然建議是安裝更新的linux了，由於我不知道怎麼安裝IPVS模塊。。。。。

經過這個命令能夠查看IPVS是否安裝：modprobe -l | grep ipvs

如圖，說明是有IPVS模塊的
安裝IPVSadm管理模塊，使用yum命令：yum -y install ipvsadm

安裝完後使用--help命令檢查是否安裝成功：ipvsadm --help

出現以下圖一大波的各類用法及說明安裝成功
安裝完lvs以後，兩臺DS安裝keepalived（這個在文章開頭傳送門處的教程中有詳細keepalived安裝方法）

下載如下兩個rpm包，區分32位64位，64位的去下載64位的包

keepalived-1.2.13-5.el6_6.i686.rpm

openssl-1.0.1e-30.el6.8.i686.rpm

注意：openssl包要求必須是openssl-1.0.1e或以上才行

將rpm包上傳到兩臺DS，進入上傳的目錄，而後運行如下命令安裝

rpm –Uvh --nodeps ./openssl-1.0.1e-30.el6.8.i686.rpm

rpm –Uvh --nodeps ./keepalived-1.2.13-5.el6_6.i686.rpm

安裝完畢，在/etc/keepalived/目錄下有個文件 keepalived.conf便是本臺服務器keepalived的核心配置文件了：
配置keepalived

這裏須要配置DS-Master的keepalived.conf和DS-Slave的keepalived.conf

編輯器裏很差貼配置文件，在keepalived配置文件夾中有兩個配置並有說明。

截個圖吧:

這是DS-Master配置（看配置說明）：

這是DS-Slave配置，基本同樣，紅色圈出部分不同：
配置完成keepalived以後檢查：

啓動兩臺keepalived，啓動keepalived服務命令：keepalived service start

查看綁定虛擬IP：ip addr

如圖所示，主機eth0網卡綁定VIP192.168.200.88，此時備機沒有綁定，假設主機中止keepalived，那麼備機就會立刻綁定VIP，自行驗證便可

至此，咱們keepalived搭建完成，DS環境搭建完畢。

配置RS

在兩臺RS上選擇一個目錄（我是在/sbin/），建立腳本realserver.sh以下（兩臺同樣），注意紅色圈出處修改成本身的VIP：

固然，建立完後記得給執行權限：chmod a+x /sbin/realserver.sh

而後，運行兩臺RS的tomcat，而且執行兩臺RS的realserver.sh腳本:/sbin/realserver.sh start

如今訪問VIP便可訪問到項目了。

測試

高可用的測試

中止DS-Master即主機lvs的keepalived服務，能夠看到VIP會綁定在備機上，而後啓動主機keepalived服務，VIP又會綁回到主機上，這個測試簡單，本身測一下便可。
負載均衡測試

玩過nginx的都知道，若是是使用其默認的輪詢機制的話，刷新一下頁面，就會變換一下被輪詢的RS服務器，即刷新頁面會在128和131之間來回切換，可是lvs不會，他會在必定時間內進行切換。這裏我也是鬱悶了好久。一開始我覺得是配置文件中persistence_timeout這個參數的緣由，固然這裏設置的話確實會影響，他會保證在必定時間內同一IP的鏈接被分配到同一臺RS上，可是我註釋以後仍是在必定時間內在一臺服務器上。這多是lvs本身的機制吧，也沒有找到緣由。

這裏測試負載均衡的話我是用了一個測試工具：apache-jmeter

運行bin目錄下的jmeter.bat，而後簡述一下測試過程，我也是現學了一下，模擬測試一下web訪問。

jmeter界面以下，新建一個線程組

而後線程數輸入個100，循環次數輸入個100，這應該是模擬100併發訪問，且永遠循環一直訪問（固然tomcat會受不了內存溢出的，這裏是爲了說明lvs能把全部請求都輪詢到兩個tomcat上，因此請無視，或者能夠線程數爲100，循環次數爲2，請求間隔設置長一點時間如100進行觀察）

而後新建HTTP請求

界面按以下填寫

而後，運行，啓動

這時再看lvs負載狀況，在DS主機上使用命令：ipvsadm -l --stats

獲得以下所示圖

此時VIP88負載RS128和131，能夠看到訪問數是同樣的都是343

DS備機上查看結果爲

由於沒有通過備機lvs進行負載，因此沒有鏈接數都爲0

主機再次查看

屢次查看會發如今這兩臺RS之間的訪問數要麼相同，要麼相差1，這是符合RR輪詢算法的，負載均衡並無問題。

這時咱們再把主機keepalived停掉，那麼備機lvs會接管，頁面上仍然能夠訪問虛擬IP到兩個RS服務器。主機停掉以後，ipvsadm -l --stats查看發現鏈接數再也不增長，而此時備機使用該命令查看發現由0開始進行負載，說明lvs服務器切換成功，一段時間後再把主機keepalived重啓，發現備機鏈接數不動了，而主機又開始增長。。。

說明這個高可用與負載均衡搭建沒有問題。

lvs負載均衡算法和機制補充（網上資料）

這塊很核心，建議多學習一下

輪詢算法

1.輪詢調度

調度器經過外部請求的順序輪流的分配到集羣中的真實服務器上，對每臺服務器都是均等的。可是這樣調度器不會考慮服務器上實際的鏈接數和系統負載，致使服務器處理請求慢，系統負載增大。

2.加權輪叫

調度器經過一個算法根據真實服務器的不一樣處理能力來分配訪問請求，這樣能夠保證服務器的處理能力。

3.最少鏈接

調度器將訪問請求自動的分配到已創建鏈接最少的服務器上，若是在集羣中每臺服務器的性能差很少的話，則這種算法能夠較好的均衡負載。

4.加權最少鏈接

主要用於集羣中服務器性能差別大的狀況下，調度器能夠優化負載性能，具備較高權值的服務器能夠將承受較大的活動鏈接。

5.基於局部性的最少鏈接

主要是針對目標IP地址的負載均衡，將請求的目標IP地址找到離其最近的服務器進行使用，若是服務器不存在或者滿載的話，就會繼續尋找下一個服務器。

6.帶複製的基於局部性的最少鏈接

主要是針對目標IP地址的負載均衡，根據請求的目標IP地址找出該地址所對應的服務器，若是服務器不存在或者滿載的話，就會繼續尋找下一個服務器。當服務器有一段時間沒有被修改，則會從最忙的服務器組中刪除。

7.目標地址散列

根據請求的目標IP地址從靜態分配的散列表中超出對應的服務器，若是找到可用的服務器且沒有滿載，則返回空。

8.源地址散列

根據請求的源IP地址從靜態分配的散列表中超出對應的服務器，若是找到可用的服務器且沒有滿載，則返回空。

簡單介紹一下，超詳細介紹看這裏：
http://www.linuxvirtualserver.org/zh/lvs4.html

lvs工做機制

1.DR機制

<網上找的圖，懶得畫了>

請求由 LVS 接受，由真實提供服務的服務器（RealServer, RS）直接返回給用戶，返回的時候不通過 LVS。
DR 模式下須要 LVS 和綁定同一個 VIP（RS 經過將 VIP 綁定在 loopback 實現）。
一個請求過來時，LVS 只須要將網絡幀的 MAC 地址修改成某一臺 RS 的 MAC，該包就會被轉發到相應的 RS 處理，注意此時的源 IP 和目標 IP 都沒變，LVS 只是作了一下移花接木。
RS 收到 LVS 轉發來的包，鏈路層發現 MAC 是本身的，到上面的網絡層，發現 IP 也是本身的，因而這個包被合法地接受，RS 感知不到前面有 LVS 的存在。
而當 RS 返回響應時，只要直接向源 IP（即用戶的 IP）返回便可，再也不通過 LVS。
DR 模式是性能最好的一種模式。但因其是修改MAC的，因此沒法作端口映射，因此這裏在配置keepalived時VIP端口與RS端口必須一致（這裏搞死我了，一開始端口不同，老出不來）

2.NAT機制

NAT（Network Address Translation）是一種外網和內網地址映射的技術。
NAT 模式下，網絡報的進出都要通過 LVS 的處理。LVS 須要做爲 RS 的網關。
當包到達 LVS 時，LVS 作目標地址轉換（DNAT），將目標 IP 改成 RS 的 IP。RS 接收到包之後，彷彿是客戶端直接發給它的同樣。
RS 處理完，返回響應時，源 IP 是 RS IP，目標 IP 是客戶端的 IP。
這時 RS 的包經過網關（LVS）中轉，LVS 會作源地址轉換（SNAT），將包的源地址改成 VIP，這樣，這個包對客戶端看起來就彷彿是 LVS 直接返回給它的。客戶端沒法感知到後端 RS 的存在。

3.FULL-NAT機制

不管是 DR 仍是 NAT 模式，不可避免的都有一個問題：LVS 和 RS 必須在同一個 VLAN 下，不然 LVS 沒法做爲 RS 的網關。
這引起的兩個問題是：
一、同一個 VLAN 的限制致使運維不方便，跨 VLAN 的 RS 沒法接入。
二、LVS 的水平擴展受到制約。當 RS 水平擴容時，總有一天其上的單點 LVS 會成爲瓶頸。
Full-NAT 由此而生，解決的是 LVS 和 RS 跨 VLAN 的問題，而跨 VLAN 問題解決後，LVS 和 RS 再也不存在 VLAN 上的從屬關係，能夠作到多個 LVS 對應多個 RS，解決水平擴容的問題。
Full-NAT 相比 NAT 的主要改進是，在 SNAT/DNAT 的基礎上，加上另外一種轉換，轉換過程以下：

在包從 LVS 轉到 RS 的過程當中，源地址從客戶端 IP 被替換成了 LVS 的內網 IP。
內網 IP 之間能夠經過多個交換機跨 VLAN 通訊。
當 RS 處理完接受到的包，返回時，會將這個包返回給 LVS 的內網 IP，這一步也不受限於 VLAN。
LVS 收到包後，在 NAT 模式修改源地址的基礎上，再把 RS 發來的包中的目標地址從 LVS 內網 IP 改成客戶端的 IP。
Full-NAT 主要的思想是把網關和其下機器的通訊，改成了普通的網絡通訊，從而解決了跨 VLAN 的問題。採用這種方式，LVS 和 RS 的部署在 VLAN 上將再也不有任何限制，大大提升了運維部署的便利性。

4.TUN機制

採用NAT模式時，因爲請求和響應的報文必須經過調度器地址重寫，當客戶請求愈來愈多時，調度器處理能力將成爲瓶頸。爲了解決這個問題，調度器把請求的報文經過IP隧道轉發到真實的服務器。真實的服務器將響應處理後的數據直接返回給客戶端。這樣調度器就只處理請求入站報文，因爲通常網絡服務應答數據比請求報文大不少，採用VS/TUN模式後，集羣系統的最大吞吐量能夠提升10倍。

VS/TUN的工做流程圖以下所示，它和NAT模式不一樣的是，它在LB和RS之間的傳輸不用改寫IP地址。而是把客戶請求包封裝在一個IP tunnel裏面，而後發送給RS節點服務器，節點服務器接收到以後解開IP tunnel後，進行響應處理。而且直接把包經過本身的外網地址發送給客戶不用通過LB服務器。

原理圖過程簡述：

客戶請求數據包，目標地址VIP發送到LB上。
LB接收到客戶請求包，進行IP Tunnel封裝。即在原有的包頭加上IP Tunnel的包頭。而後發送出去。
RS節點服務器根據IP Tunnel包頭信息（此時就又一種邏輯上的隱形隧道，只有LB和RS之間懂）收到請求包，而後解開IP Tunnel包頭信息，獲得客戶的請求包並進行響應處理。
響應處理完畢以後，RS服務器使用本身的出公網的線路，將這個響應數據包發送給客戶端。

lvs與nginx比較

這一塊建議看一下，網上查詢便可。

四層與七層負載均衡

四層負載均衡：

經過報文中的目標地址和端口，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器與請求客戶端創建TCP鏈接，而後發送Client請求的數據。

七層負載均衡：

也稱內容交換，也就是主要經過報文中的真正有意義的應用層內容，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的服務器。

由上圖可知：
在四層負載設備中，把client發送的報文目標地址(原來是負載均衡設備的IP地址)，根據均衡設備設置（lvs的不一樣負載均衡機制）的選擇web服務器的規則選擇對應的web服務器IP地址，這樣client就能夠直接跟此服務器創建TCP鏈接併發送數據。

七層負載均衡服務器起了一個代理服務器的做用，咱們知道創建一次TCP鏈接要三次握手；而client要訪問webserver要先與七層負載設備進行三次握手後創建TCP鏈接，把要訪問的報文信息發送給七層負載均衡；而後七層負載均衡再根據設置的均衡規則選擇特定的webserver，而後經過三次握手與此臺webserver創建TCP鏈接，而後webserver把須要的數據發送給七層負載均衡設備，負載均衡設備再把數據發送給client；因此，七層負載均衡設備起到了代理服務器的做用。

本站點中止更新，請訪問:blog.coocap.com