高性能Linux服務器第11章構建高可用的LVS負載均衡集羣

時間 2019-11-29

標籤高性能 linux 服務器構建可用 lvs 負載均衡集羣欄目 Linux 简体版

原文原文鏈接

高性能Linux服務器第11章構建高可用的LVS負載均衡集羣css

libnet軟件包《-依賴-heartbeat（包含ldirectord插件（須要perl-MailTools的rpm包））

ldirectord插件-》調用ipvsadm命令html

本章主要介紹高可用LVS負載均衡集羣系統的搭建，首先介紹LVS的組成和特色，然
後介紹高可用LVS集羣系統的拓撲結構，接着經過3個實例詳細介紹如何經過heartbeat、
Keepalived及piranha來構建高可用LVS集羣，最後，總結經過這3種方式構建高可用LVS
集羣的優缺點。本章實踐性強，實例都是真實環境的模擬。學完本章，讀者可以對LVS集羣
有更深的理解和認識。前端

11.1 LVS集羣的組成與特色
Linux虛擬服務器(Linux Virtual Server，LVS)．是一個由章文嵩開發的一款自由軟件。利用LVS能夠實現高可用的、可伸縮的Web、Mail、Cache和Media等網絡服務。node

並在此基礎上開發支持龐大用戶數的、可伸縮的、高可用的電子商務應用。LVS自1998年發展到如今，已經變得比較成熟，目前普遍應用在各類網絡服務和電子商務應用中。
LVS具備很好的可伸縮性、可靠性和可管理性，經過LVS要實現的最終目標是：利用
Linux操做系統和LVS集羣軟件實現一個高可用、高性能、低成本的服務器應用集羣。python

11.1.1 LVS集羣的組成
利用LVS架設的服務器集羣系統由3個部分組成：最前端的是負載均衡層（這裏用Load Balancer表示），中間是服務器羣組層（用Server Array表示），底端是數據共享存儲層（用Shared Storage表示）。linux

在用戶看來，整個LVS集羣系統的全部內部應用結構都是透明的，最終用戶只是在使用一個虛擬服務器提供的高性能服務。
LVS體系結構如圖11-1所示。
下面對LVS的各個組成部分進行詳細介紹。
負載均衡層：位於整個集羣系統的最前端，由一臺或多臺負載調度器( Director Server)
組成。LVS核心模板IPVS就安裝在Director Server上，而Director的主要做用相似於
一個路由器，它含有爲完成LVS功能所設定的路由表，經過這些路由表把用戶的請求
分發給服務器羣組層的應用服務器( Real Server)。同時，在Director Server上還要安裝
對Real Server的監控模塊Ldirectord，此模塊用於監測各個Real Server服務的健康狀
況。在Real Server不可用時能夠將其從LVS路由表中剔除，在恢復時從新加入。web

服務器羣組層：由一組實際運行應用服務的機器組成，Rcal Server能夠是Web服務
器、Mail服務器、FTP服務器、DNS服務器、視頻服務器中的一個或多個，每一個Real
Server之間經過高速的LAN或分佈在各地的WAN相鏈接。在實際的應用中，Director
Server也能夠同時兼任Real Server的角色。
共享存儲層：是爲全部Real Server提供共享存儲空間和內容一致性的存儲區域，一
般由磁盤陣列設備組成。爲了提供內容的一致性，通常能夠經過NFS網絡文件系統共
享數據，可是NFS在繁忙的業務系統中，性能並非很好，此時能夠採用集羣文件系
統，例如Red Hat的GFS文件系統，Oracle提供的OCFS2文件系統等。
從整個LVS結構能夠看出，Director Server是整個LVS的核心。目前，用於Directar Server
的操做系統只有Linux和FreeBSD，Linux 2.6內核徹底內置了LVS的各個模塊，不用任何設置就能夠支持LVS功能。
對於Real Server，幾乎全部的系統平臺，如Linux、Windows、Solaris、AIX、BSD系列等都能很好地支持它。正則表達式

11 .1.2 LVS集羣的特色
1.IP負載均衡與負載調度算法
(1) IP負載均衡技術
負載均衡技術有不少實現方案，有基於DNS域名輪流解析的方法，有基於客戶端調度訪問的方法，有基於應用層系統負載的調度方法，還有基於IP地址的調度方法。算法

在這些負載調度算法中，執行效率最高的是IP負載均衡技術。
LVS的IP負載均衡技術是經過IPVS模塊來實現的。IPVS是LVS集羣系統的核心軟件，它的主要做用是：安裝在Director Server上，同時在Director Server上虛擬出一個IP地址，用戶必須經過這個虛擬的IP地址訪問服務器。windows

這個虛擬IP -般稱爲LVS的VIP，即Virtual IP。訪問的請求首先通過VIP到達負載調度器，而後由負載調度器從Real Server列表中選取一個服務節點響應用戶的請求。
在用戶的請求到達負載調度器後，調度器如何將請求發送到提供服務的Real Server節點，而Real Server節點如何返回數據給用戶，是IPVS實現的重點技術。

IPVS實現負載均衡的方式有3種，分別是NAT、TUN和DR。下面進行詳細介紹。
VS/NAT：即Virtual Server via Network Addrcss Translation，也就是網絡地址翻譯技術實
現虛擬服務器。當用戶請求到達調度器時，調度器將請求報文的目棕地址（即虛擬IP
地址）改寫成選定的Real Server地址，同時將報文的目標端口也改爲選定的Real Server
的相應端口，最後將報文請求發送到選定的Real Server。在服務器端獲得數據後，Real
Server將數據返回給用戶時，須要再次通過負載調度器將報文的源地址和源端口改爲
虛擬IP地址和相應端口，而後把數據發送給用戶，完成整個負載調度過程。
能夠看出，在NAT方式下，用戶請求和響應報文都必須通過Director Server地址重寫，
當用戶請求愈來愈多時，調度器的處理能力將成爲瓶頸。
VS/TUN：即Virtual Server via IP Tunneling，也就是經過IP隧道技術實現虛擬服務器。
這種方式的鏈接調度和管理與VS/NAT方式同樣，只是報文轉發方法不一樣。在VS/TUN
方式中，調度器採用IP隧道技術將用戶請求轉發到某個Real Server，而這個Real Server
將直接響應用戶的請求，再也不通過前端調度器。此外，對Real Server的地域位置沒
有要求，能夠和Director Server位於同一個網段，也能夠在獨立的一個網絡中。所以，
在TUN方式中，調度器將只處理用戶的報文諳求，從而使集羣系統的吞吐量大大提升。
VS/DR:即Virtual Server via Direct Routing，也就是用直接路由技術實現虛擬服務器。這
種方式的鏈接調度和管理與前兩種同樣，但它的報文轉發方法又有所不一樣，VS/DR
經過改寫請求報文的MAC地址，將請求發送到Real Server．而Real Server將響應直
接返回給客戶，免去了VS/TUN中的IP隧道開銷。這種方式是3種負載調度方式中性
能最好的，可是要求Director Server與Real Server必須由一塊網卡連在同一物理網段上（二層網絡）。
(2)負載調度算法
前面介紹過，負載調度器是根據各個服務器的負載狀況，動態地選擇一臺Real Serve響應用戶請求。那麼動態選擇是如何實現呢？其實就是經過這裏要說的負載調度算法。

根據不一樣的網絡服務需求和服務器配置，IPVS實現了8種負載調度算法。這裏詳細講述最經常使用的4
種調度算法。
□輪叫調度( Round Robin)。
「輪叫」調度也叫1:1調度，調度器經過「輪叫」調度算法將外部用戶請求按順序1：1地分配到集羣中每一個Real Server上。這種算法平等地對待每一臺Real Server，而無論服務器上實際的負載情況和鏈接狀態。
□加權輪叫調度（Wcighted Round Robin）。
「加權輪叫」調度算法根據Real Server的不一樣處理能力來調度訪問請求。能夠對每臺Real Server設置不一樣的調度權值，對性能相對較好的Real Server能夠設置較高的權值，

而對處理能力較弱的Real Server，能夠設置較低的權值。這樣保證了處理能力強的服務器處理更
多的訪問流量，充分合理地利用了服務器資源。同時，調度器還能夠自動查詢Real Server的負載狀況，並動態地調整其權值。
□最少鏈接調度( Least Connections)。
「最少鏈接」調度算法動態地將網絡請求調度到已創建的鏈接數最少的服務器上。若是集羣系統的真實服務器具備相近的系繞性能，採用「最小鏈接」調度算法能夠較好地均衡負載。
□加權最少鏈接調度( Weighted Least Connections)。
「加權最少鏈接調度」是「最少鏈接調度」的超集。每一個服務節點能夠用相應的權值表
示其處理能力，而系統管理員能夠動態地設置相應的權值，默認權值爲1。加權最小鏈接調
度在分配新鏈接請求時儘量使服務節點的已創建鏈接數和其權值成正比。
其餘4種調度算法分別爲：基於局部性的最少鏈接（Locality-Based Least Connections）、
帶複製的基於局部性最少鏈接（Locality-Based Least Connections with Replication）、目標地
址散列( Destination Hashing)和源地址散列(Source Hashing)。若是想深刻了解這4種調度策略，能夠登陸LVS中文站點zh.linuxvinualserver.org，查閱更詳細的信息。

2．高可用性
LVS是一個基於內核級別的應用軟件，所以具備很高的處理性能。由LVS構建的負載均衡集羣系統具備優秀的處理能力，每一個服務節點的故障不會影響整個系統的正常使用，又可以實現負載的合理均衡，

使應用具備超離負荷的服務能力，可支持上百萬個併發鏈接請求。如配置百兆網卡，採用VS/TUN或VS/DR調度技術，整個集羣系統的吞吐量可高達1Gbit/s:又如配置千兆網卡，系統的最大吞吐量可接近10Gbit/s。
3．高可靠性
LVS負載均衡集羣軟件已經在企業和學校中獲得了很好的普及，國內外不少大型的、關鍵性的Web站點也都採用了LVS集羣軟件，因此它的可靠性在實踐中獲得了很好印證。

有不少由LVS構成的負載均衡系統，運行很長時間，從未進行太重新啓動。這些都說明了LVS的高穩定性和高可靠性。
4．適用環境
目前LVS僅支持Linux和FreeBSD系統做爲前端Director Server．可是支持大多數的TCP和UDP協議。支持TCP協議的應用有：HTTP、HTTPS、FTP、SMTP、POP三、IMAP四、PROXY、LDAP和SSMTP等；

支持UDP協議的應用有：DNS、NTP、ICP、視頻和音頻流播放協議等。
LVS對Real Server的操做系統沒有任何限制，Real Server可運行在任何支持TCP/IP的操做系統上，包括Linux，各類UNIX（如FreeBSD、Sun Solaris、HP Unix等），Mac OS和Window等。
5．開源軟件
LVS集羣軟件是按GPL (GNU Public License)許可證發行的自由軟件，所以，使用者能夠獲得軟件的源代碼，而且能夠根據本身的須要進行各類修改，可是修改必須以GPL方式發行。

11.1.3 LVS集羣系統的優缺點
LVS是一款自由軟件，任何人均可以避免費獲取並使用它，並且Linux也是一個開源操做系統，這兩者的組合大大節約了企業的應用成本。同時LVS具備高穩定性和高可靠性，在高
併發和高吞吐量下，其有高負荷處理能力，當某個服務節點出現故障時，並不影響整個系統
服務的正常運行。這些優勢使LVS已經普遍應用在企業、教育行業以及不少知名網站。
細心的讀者可能已經發現了，LVS在具備上述優勢的同時，還存在一個致命的缺點，從
圖11-1能夠清楚地看出，全部的用戶請求都通過Director Server將任務分發到各個服務器節
點，那麼，當只有一臺Director Server時，將會出現單點故障點，若是這個Director Server出現故障，整個LVS系統將陷入癱瘓狀態。
雖然Director Server僅完成用戶請求的分發處理，負載並非很大，可是對於一個健壯
的集羣系統來講，單點故障是絕對不容許的。要避免這種單點故障，最實用、最簡單的辦法
就是對Director Server進行高可用集羣，常見的方案就是爲Director Server作一個雙機熱備：
正常狀態下主Director Server工做，備用Director Server監控主Director Server的狀態，當主Director Scrver出現異常或者故障時，備用Director Server立刻接過主Director Server的工做，負責對用戶請求進行分發處理。

這樣就避免了一臺Director Server的單點故障問題，保證了負載均衡端持續地提供服務。

11.2高可用LVS負載均衡集羣體系結構
單一的Director Server可能會形成整個LVS集羣系統的單點故障，爲了解決這個問題，就須要保證Director Server的高可用性，最經常使用的方法就是在負載均衡層構建Director Server雙機熱備系統。
高可用的LVS負載均衡集羣體系結構如圖11-2所示。

從圖11-2能夠看出，整個體系結構仍然分爲三層，在HA負載均衡層由主、備兩臺Director Server構成雙機熱備系統，雙機之間經過心跳線鏈接。

在正常狀態下主Director Server使用虛擬IP接收用戶請求，並根據設定好的策略和算法將請求分發給各個服務節點，備用Director Server負責監控主Director Server的運行狀態。

當主Director Server發生異常或出現故障時，備用Director Server負責接管主Director Server的虛擬IP和服務並繼續接收用戶請求和分發處理。經過這種相互監控策略，任意一方主機出故障時，

另外一方都可以將IP和服務接管，這就保證了負載均衡層業務請求的不間斷運行。
服務器羣組層和共享存儲層實現的功能與圖11-1徹底相同，再也不講述。

11.3 高可用性軟件Heartbeat與Keepalived

11.3.1 開源HA軟件Heartbeat的介紹
heartbeat是Linux-HA頊目中的一個組件，也是目前開源HA項目中最成功的一個例子，它提供了全部HA軟件須要的基本功能，好比心跳檢測和資源接管，監測集羣中的系統服務，在羣集的節點間轉移共享IP地址的全部者等。

自1999年開始到如今，heartbeat在行業內獲得了普遍應用，也發行了不少的版本。能夠從Linux-HA的官方網站www.linux-ha.org下載到heartbeat的最新版本。

11.3.2安裝heartbeat
這裏下載的軟件包是heartbeat-2.1.3.tar.gz，可經過源碼進行安裝。
同時還須要安裝一個Iibnet工具包。libnet是一個高層次的API工具，能夠從http://sourceforge.net/projects/libnet-dev/下載到，這裏下載的是libnet-1.1.4.tar.gz。
heartbeat的安裝很是簡單，基本操做步驟以下：
(1)安裝libnet。

[root@ DRI -] #tar -zxvf  libnet-1.1.4.tar.gz
[root@ DRl -] #cd libnet-1.1.4
[root@ DRI -/libnet] #./configure
[root@ DRl -/libnet] #make
[root@ DRI -/libnet] #make install

(2)安裝 heartbeat。

[root@ DRI -] #tar -zxvf  heartbeat-2.1.3.tar.gz
[root@ DRI -] #cd  heartbeat-2.1.3
[root@ DRI -/heartbeat-2.1.3]#./ConfigureMe  configure\
>- - disable-swig --diaable - snmp- subagent
[root@ DRI -/heartbeat-2.1.3] #make
[root@ DRI -/heartbeat-2.1.3]#make  inatall
[root@ DRI -/heartbeat-2.1.3]#cp doc/ha.cf doc/haresources doc/authkeys  /etc/ha.d/
[root@ DRI -/heartbeat-2.1.3]#cp  ldirectord/ldirectord.cf   /etc/ha.d/
[root@ DRI -/heartbeat-2.1.3]#groupadd  -g 694  haclient
[root@ DRI -/heartbeat-2.1.3]#useradd  -u 694 -g haclient hacluster

heartbeat的安裝包中包含了一個ldirectord插件，這個插件之後會用到。在heartbeat安裝完畢後，此插件默認已經安裝。可是爲了保證ldirectord可用，還須要一個perl-MaiITools
的rpm包，這個rpm從系統盤中找到後安裝便可。

11.3.3 開源HA軟件Keepalived的介紹
Keepalived起初是爲LVS設計的，專門用來監控集羣系統中各個服務節點的狀態。它根據Iayer3，4&5交換機制檢測每一個服務節點的狀態，若是某個服務節點出現異常，或工做出
現故障，Keepalived將檢測到，並將出現故障的服務節點從集羣系統中剔除，而當故障節點
恢復正常後，Keepalived又能夠自動將此服務節點從新加入到服務器集羣中。這些工做所有
自動完成，不須要人工干涉，須要人工完成的只是修復出現故障的服務節點。
Keepalived後來又加入了VRRP的功能。VRRP是Virtual Router Redundancy Protocol(虛擬路由器冗餘協議）的縮寫，它的做用是解決靜態路由出現的單點故障問題，它可以保證網絡不間斷地、穩定地運行。

綜上所述，Keepalived 一方面具備服務器運行檢測功能，另外一方面也具備HA cluster功能。所以經過Keepalived能夠搭建一個高可用的LVS負載均衡集羣系統。

11 .3.4 安裝Keepalived
Keepalived的官方網址是http://www.keepalived.org，能夠在這裏下載到各類版本的Keepalived，這裏下載的是keepalived-1.1.19.tar.gz。安裝步驟以下：

[root@DRl -] #tar  -zxvf  keepalived-1.1.19.tar.gz
[root@DRl -] #cd  keepalived-1.1.19
[root@DRl  keepalived - 1.1.19] # ./configure - - aysconf=/etc  \
> --with- kernel-dir=/usr/src/kernela/2.6.18-8.el5-i686
[root@DRl  keepalived-1.1.19]#make
[root@DRl  keepalived-1.1.19]#make  install
[root@DRl  keepalived-1.1.19]#ln -s /usr/local/sbin/keepalived    /sbin/

在編譯選項中，「-sysconf」指定了Keepalived配置文件的安裝路徑，即路徑爲/etc/Keepalived/Keepalived.conf。「-with-kernel-dir」是個很重要的參數，但這個參數並非要把Keepalived編譯進內核，

而是指定使用內核源碼中的頭文件，即include目錄。只有使用LVS時，才須要用到此參數，其餘時候是不須要的。
安裝完成，執行以下操做：

[root@drl  -] # keepalived --help
Keepalived  v1. 1. 19 (05/05, 2010)
Usage :
  keepalived
  keepalived -n
  keepalived -f  keepalived. conf
  keepalived -d
  keepalived -h
  keepalived -v
Commands :
Either long or short options are allowed.
  keepalived --vrrp            -P   Only run with VRRP subsystem.
  keepalived --check           -C   Only run with Health-checker subsyatem.
  keepalived -dont-release-vrrp  -V  Dcnt remove VRRP VIPs & VROUTEs on daemon atcp.
  keepalived -dont-release-ipva  -I   Dont remove IPVS topology on daemon stop.
  keepalived -dont-fork        -n   Dont fork the daemon process.
  keepalived -use-file          -f   Use the specified configuration file.
                          Def ault  is  /etc/keepalived/keepalived . conf .
  keepalived --dump-conf      -d   Dump the cortiguration data.
  keepalived --log-console      -l   Log mesaage to local console.
  keepalived  - -log-detail     -D  Detailed  log  messages .
  keepalived  - -log- facility    -s  0-7  Set  syslog  facility  to  LOG_LOCAL [0-7] .
       ( default=LOG_DAEMON)
  keepalived --help           -h  Display this short inlined help screen.
  keepalived --version         -v  Display the version number
  keepalived --pid            -p  pidfile
  keepalived --checkers_pid    -c  checkers pidfile
  keepalived --vrrp_pid        -r  vrrp pidfile

這裏列出了Keepalived的各類用法，同時也代表Keepalived已安裝成功。

11.4安裝LVS軟件
LVS是經過IPVS模塊來實現的。IPVS是LVS集羣系統的核心軟件，主要用於完成用戶的請求到達負載調度器後，如何將請求發送到每一個Real Server節點、Real Server節點如何返回數據給用戶等。

11 .4.1 配置與檢查安裝環境
這裏設定，操做系統採用CentOS 5.4，該版本內核默認支持LVS功能。爲了方便編譯
安裝IPVS管理軟件，在安裝操做系統時，建議選擇以下這些安裝包：
□桌面環境：xwindows system、GNOME desktop environment。
□開發工具：development tools、x sofiware development、gnome software、development、
kde sottware development。
系統安裝完畢後，能夠經過以下命令檢查kemel是否已經支持LVS的IPVS模塊。

[root@DRl -] #modprobe  -l |grep  ipvs
/lib/modules/2.6.18-164.11.1.e15PAE/kernel/net/ipv4/ipVB/ip_vs.ko
/lib/modules/2.6.18-164.11.1.e15PAE/kernel/net/ipv4/ipVB/ip_vs_dh.ko
/lib/modules/2.6.18-164.11.1.e15PAE/kernel/net/ipv4/ipVB/ip_vs_f tp.ko
/lib/modules/2.6.18-164.11.1.e15PAE/kernel/net/ipv4/ipVB/ip_vs_lblc.ka
/lib/modules/2.6.18-164.11.1.e15PAE/kernel/net/ipv4/ipVB/ip_vs_lblcr.ko
/lib/modules/2.6.18-164.11.1.e15PAE/kernel/net/ipv4/ipVB/ip_vs_vs_lc.ko
/lib/modules/2.6.18-164.11.1.e15PAE/kernel/net/ipv4/ipVB/ip_vs_nq.ko
/lib/modules/2.6.18-164.11.1.e15PAE/kernel/net/ipv4/ipVB/ip_vs_rr.ko

若是有相似上面的輸出，代表系統內核默認支持IPVS模塊。接下來就能夠安裝IPVS
管理軟件了。

11.4.2 在Director Server上安裝IPVS管理軟件
IPVS提供的軟件包有源碼方式的也有rpm方式的，這裏介紹如何經過源碼方式安裝IPVS。

首先從http://www.linuxvilrualserver.org/sofiware/ipvs.html下載對應版本的ipvs源碼，因爲這裏採用的操做系統爲CentOS 5.4舨本，所以，下載對應的ipvsadm-l .24版本，接着進行安裝。

[root@DRI-]#tar  zxvf  ipvsadm-1.24.tar.gz
[root@DRI-]#cd ipvsadm-1.24
[root@DRI-]#make
[root@DRI-]#make  install

注意，在執行make時可能會出現相似以下的錯誤編譯信息：
libipvs.h: 14:23: error: net/ip_vs .h: No such file or directory
這是因爲編譯程序找不到對應內核形成的。按照以下操做就能夠正常編譯：

[root@ DRl-]# In -s/usr/src/kernels/2.6.18-164.e15-i686  /usr/src/linux

也能夠經過yum方式在線安裝：

[root@ DRI-}#yum install  ipvsadm

而後執行：

[root@ DRl-]# ipvsadm --help

若是看到幫助提示，代表IPVS已經成功安裝。

11.5搭建高可用LVS集羣
LVS集羣有DR、TUN、NAT三種配置模式，能夠對www服務、FTP服務、MAIL服務等進行負載均衡。下面經過3個實例詳細講述如何搭建www服務的離可用LVS集羣系統,以及基於DR模式的LVS集羣配置。

在進行實例介紹以前進行約定：操做系統採用CentOS 5.4，地址規劃如表11-1所示。

表11-1地址規劃狀況

節點類型	IP地址規劃	主機名	類型
主Director Server	eth0:192.168.12.130	DR1	Pnblic IP
	eth1:10.10.10.1	priv1	private IP
	eth0:0:192.168.12.200	無	Virtual IP
備用Director Server	eth0:192.168.12.131	DR2	Public IP
備用Director Server	eth1:10.10.10.2	priv1	private IP
Real server 1	eth0:192.168.12.132	rs1	Public IP
Real server 1	lo:0:192.168.12.200	無	Virtual IP
Real server 2	eth0:192.168.12.133	rs2	Public IP
Real server 2	lo:0:192.168.12.200	無	Virtual IP

整個高可用LVS集羣系統的拓撲結構如圖11-3所示。

11.5.1 經過heartbeat搭建LVS高可用性集羣

1．配置LVS集羣
配置LVS的方法有不少，能夠經過LVS提供的ipvsadm命令進行配置，也能夠經過第三方插件或工具來進行配置，例如經過Ldirectord來配置LVS．或者經過Rcdhat提供的界面工具piranha來配置等。

這裏選擇經過Ldirectord來配置LVS。
(1)經過Ldirectord在主、備Director Server上配置LVS
Ldirectord是heartbeat的一個插件，在安裝heartbeat時，默認已經安裝了此插件。Ldirectord主要用於監控集羣系統中每一個服務節點的運行狀態，當某個節點的服務出現異常或主機出現故障時，

將此節點從集羣系統中剔除，而且在節點恢復正常後，從新將此節點加入集羣系統。
除了監控服務節點外，Ldirectord的另外一個功能是配置LVS，只需設置好Ldirectord的配置文件，啓動服務便可，Ldirectord會自動調用ipvsadm命令建立LVS路由表信息。

Ldirectord配置文件的默認路徑爲/etc/ha.d/ldirectord.cf。這裏詳細介紹一下這個文件中每一個選項的含義。
下面是須要配置的選項。
checktimeout=20   #斷定Real Server出錯的時間間隔
Checkinterval=10   #指定Ldirectord在兩次檢查之同的間隔時間
Fallback=127.0.0.1:80 #當全部的Real Server節點不能工做時，Web服務重定向的地址
autoreload=yes #是否自動重載配置文件，選yea時，配置文件發生變化，自動載入配置信息
logfile=」/var/log/ldirectord. Log」
           #設定Ldirectord日誌輸出文件路徑
quiescent（靜止的）=no #當選擇no時，若是一個節點在checktimeout設置的時問週期內沒有響應，
       #ldirectord將會從LVS的硌由表中直接移除Real Server．此時，將中斷
       #現有的客戶端鏈接，並使LVS丟掉全部的鏈接跟蹤記錄和持續鏈接模扳；
       #若是選擇yea，當某個Real Server失效時．Ldirectord將失效節點的
       #權值設置爲0，新的鏈接將不能到達，可是並不會從LVS路由表中清除此
       #節點，同時，鏈接跟蹤記錄和程序鏈接模板仍然保留莊Director上
注意，以上幾行爲ldirectord．cf文件的全局設置，它們能夠應用到多個虛擬主機。下面是每一個虛擬主機的配置。
Virtual=192.168.12.200:80 #指定虛擬的IP地址和端口號，注意，在virtual這行後面的行
                       #必須縮進4個空格或以一個tab字符進行標記
real=192.168.12.132:80 gate #指定Real Server服務器地址和端口，同時設定LVS工做模式,
                   #用gate表示DR模式，ipip表示TUNL模式，masq表示NAT模式
real=192.168.60.133:80 gate
fallback=127.0.0.1:80 gate
Service=http             #指定服務的類型，這裏是對HTTP服務進行負載均衡
Request=」index .html」   # Ldirectord將根據指定的Real Senrer地址，結合該選項給
               #出的請求頁面，發送訪問請求，檢童Real Server上的服務是
               #否正常運行，必須確保這裏給出的頁面地址是可訪問的，否則
               #Ldirectord會誤認爲此節點已經失效，發生錯誤監控現象
receive=」Test Page 「    #指定請求和應答字串，也就是index．html的內容
scheduler=rr          #指定調度算法，這裏是rr（輪詢）算法
protocol=tcp          #指定協議的類型，LVS支持TCP和UDP協議
checktype=negotiate    #指定Ldirectord的檢測類型，checktype能夠是connect、
               # external、negotiate、off、on、ping和checktimeout
               #這幾個，默認爲negatiate，經過頁面交互未判斷服務器節點
               #是否正常
sheckport=80          #指定監控的端口號
virtualhost=www. Ixdba.net #虛擬服務囂的名稱，可任意指定
配置完畢後就能夠執行以下命令啓動或關閉Ldirectord服務：

/etc/init.d/ldirectord {start |stop}

(2) Real server的配置
在LVS的DR和TUN模式下，用戶的訪問請求到達Real Server後，是直接返回給用戶的，再也不通過前端的Director Server，所以，須要在每一個Real server節點上增長虛擬的VIP地址，這樣數據才能直接返回給用戶。

增長VIP地址的操做能夠經過建立腳本的方式來實現。建立文件/etc/init.d/lvsrs，腳本內容以下：

[root@rsl -] #more /etc/init.d/lvsra
# !/bin/baah
#description : Start Real Server
VIP=192.168.12.200
. /etc/rc.d/ini.d/functions
case "$1」 in
start)
echo " Start  LVS of  Real Server 「
/sbin/ifconfig lo:0 $VIP broadcaat $VIP netmask 255.255.255.255 up
echo 「1」 >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo 「2」 >/proc/sys/net/ipv4/conf/lo/arp_announce
echo 「1」 >/proc/sys/net/ipv4/conf/all/arp_ignore
echo 「2」 >/proc/sya/net/ipv4/conf/all/arp_announce
;;
stop)
/sbin/ifconfig lo : 0  down
echo」 close LVS Director aerver」
echo 「0」 >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo 「0」 >/proc/sys/net/ipv4/conf/lo/arp_announce
echo 「0」 >/proc/sys/net/ipv4/conf/all/arp_ignore
echo 「0」 >/proc/sys/net/ipv4/conf/all/arp_announce
;;
*)
echo "Usage: $O {start|stop} 「
exit 1
esac

而後修改lvsrs使其具備可執行權限。

[root@rsl -] #chomd  755  /etc/init.d/lvsrs

最後，能夠經過下面的命令啓動或關閉lvsrs：

service  lvsrs   { start | stop }

2.在主、備Director Server上配置heartbeat
在搭建Director Server的雙機熱備系統以前，首先須要在兩臺主機上安裝heartbeat軟件。heartbeat的安裝已經在前面介紹過，這裏再也不講述，直接進入heartbeat的配置。
(1)配置heartbeat的主配置文件(/etc/ha.d/ha.cf)
下面對ha．cf文件的每一個選項進行詳細介紹。
#debugfile /var/ log/ha - debug
logfile /var/log/ha- log    #指定heartbeat酌日誌存放位置
#crm yes               #是否開啓ClusterReaourceManager（集羣資源管理）功能
bcast ethl            #指定心跳使用以太網廣播方式，而且在ethl接口上進行廣播
logfacility loca10
keepalive 2      #指定心跳間隔時間爲2秒（即每2秒在eth1上發送一次廣播）
deadtime 30     #若是指定各用節點在30秒內沒有收到主節點的心跳信號，則
           #當即接管主節點的服務資源
warntime 10    #指定心跳延遲的時聞爲10秒。當10秒內備用機不能接收到主節點的
          #心跳信號時，就會在日誌中寫入一個警告信息，但此時不會切換服務
initdead 120    #在某些系統上，系統啓動或重啓以後須要通過一段時間網絡才能
          #正常工做，該選項用於設置這種狀況產生的時間間隔，取值至少爲
          #deadtime的兩倍
udpport 694   #設置廣播通訊使用的端口，694爲默認使用的端口號
baud 19200    #設置串行通訊的比特率
serial /dev/ttyS0 #選擇串行通訊設套，用於雙機使用串口線鏈接的狀況。若是雙機
           #經過以太網鏈接，則應該關閉該選項
#ucaat eth0 192.168.1.2 #採用網卡eth0的UDP單播來組織心跳，後面跟的IP地址應爲
               #雙機中對方的IP地址
#mcast eth0 225.0.0.1 6941 0 #採用網卡eth0的UDP多播來組織心跳，通常在備用機不止
                   #一臺時使用，bcast、ucast和mcast分別表明廣播、單播和
                   #多播，是組織心跳的3種方式，任選其一便可
auto_failback on    #用來定義當主節點恢復後，是否將服務自動切回，heartbeat的兩
           #臺主機分別爲主節點和備用節點。主節點在正常狀況下佔用資源
           #並運行全部的服務，遇叫故障時把資源交給備用節點並由備用
           #節點運行服務。在將該選項爲on的狀況下，一旦主節點恢復運行，
           #則自動獲取資源並取代備用節點；若是該選項設置爲off，那麼，
           #主節點恢復後，將變爲備用節點，而原來的備用節點成爲主節點
#stonith baytech/etc/ha. d/conf/stonith. baytech
       #stanith的主要做用是使出現問題的節點從集羣環境中脫離，進而釋放集羣
       #資源，避免兩個節點爭用—個資源的狀況發生，保證共享數據的安全性和完整性
#watchdog /dev/watchdog #該選項是是可選配置，經過heartbeat來監控系統的運行狀態。使用該
          #特性，須要在內核中載入「softdog」內核模塊，用來生成實際的設備
          #文件，若是系統中沒有這個內核模塊，就須要指定此模塊，從新編譯內核。
          #編譯完成後輸入「insmod softdog」加載該模塊，而後輸入「grep
          # misc /proc/devices」（應爲10），輸入「cat /proc/miac |
          # grep watchdog」（應爲130），最後，生成設備文件「mknod/dev/
          #watchdog c 10 130」便可使用此功能
node DR1      #主節點主機名，能夠經過命令「uanme -n」查看
node DR2      #備用節點主機名
ping 192.168.12.1 #選擇ping的節點，ping節點選擇得越好，HA集羣就越強壯。能夠選擇
              #固定的路由器做爲ping節點，可是最好不要選擇集羣中的成員做爲ping
              #節點，ping節點使用來測試網絡鏈接
ping node 192 . 168 . 12 . 188 192. 168. 12. 100
              #指定ping node。ping node並非雙機中的兩個節點，僅僅用來測試
              #網絡的連通性
respawn hacluster /usr/lib/heartbeat/ipfail    #respawn   inittab文件自動重啓殺不死
       #該選項是可選配置，列出與heartbeat 一塊兒啓動和關閉的進程，該進程
       #通常是和heartbeat集成的插件，這些進程遇到故障能夠白動從新啓動。
       #最經常使用的進程是ipfail，此進程用於檢測和處理網絡故障，須要配合ping
       #語句指定的ping node未檢測網絡的連通性。其中hacluster表示啓動
       #ipfail進程的身份
(2)配置heartbeat的資源文件(/etc/ha.d/haresources)
haresources文件用於指定雙機系統的主節點、集羣IP、子網掩碼、廣播地址以及啓動的服務等集羣資源。文件每一行能夠包含一個或鄉個資源腳本名，資源腳本名之間用空格隔開，參數之間使用兩個冒號隔開。
DRl IPaddr：：192. 168. 12. 200/24/etho ldirectord #設置 DRI爲主節點，集羣服務器
                                          #的IP地址爲192 .168 .12. 200，
                                          #netmask爲255.255.255.0,
                                          #同時指定此IP使用的網絡接口爲
                                          #eth0, heartbeat託管的服務
                                          #爲ldirectord
注意，這裏的Ldirectord對應的文件爲/etc/init.d/ldirectord，即Ldirectord服務的啓動文件，也就是將Ldirectord的啓動與關閉交給heartbeat來管理。

另外，LVS主節點和備份節點中的資源文件haresources要徹底一致，當指定DRI是主節點後，另外一個節點DR2就是備份
節點。
(3)配置heartbeat的認證文件（etc/ha.d/authkeys)
authkeys文件用於設定hcartbeat的認證方式，該文件中有3種可用的認證方式：crc、
shal和md5，這裏使用crc認證方式。設置以下：

auth 1
1 crc
#2 ahal ahal_any_password
#3 md5 md5_any_pa8aword

須要說明的一點是，不管「auth」後面指定的是什麼數字，在下一行必須做爲關鍵字再
次出現，例如指定了"auth 6」，下面必定要有一行「6認證類型」。
最後確保這個文件的權限是600（即-rw-----）。

3．啓動heartbeat+LVS集羣系統
(1)啓動heartbeat服務
全部配置完成後，就能夠在主、備Director Server上啓動heartbeat服務了。能夠經過以下方式管理heartbeat服務：

[root@DRl-] #/etc/init.d/heartbeat\
>{start|stop|atatus|reatart| reload|force - reload}

因爲heartbeat託管了主、備Dircctor Server上的Ldirectord服務，所以只需在主、備兩
臺機器上啓動heartbeat服務便可，這樣Ldirectord服務就在主機上啓動起來了。
(2)啓動Real Server節點服務
分別在兩個Rcal Servcr節點上執行以下腳本：

[root@rsl～]#/etc/init.d/lvsrs start

至此，經過heartbeat構建的高可用LVS集羣系統已經配置完成並運行起來了。

11.5.2 經過Keepalived搭建LVS高可用性集羣系統
1．配置Keepalived
Keepalived的配置很是簡單，僅須要一個配置文件便可完成對HA cluster和LVS服務節點監控。Kcepalived的安裝已經在前面介紹過，在經過Keepalived搭建高可用的LVS集羣實
例中，主、備Director Server都須要安裝Keepalived軟件，安裝成功後，默認的配置文件路
徑爲/etc/Keepalived/Keepalived.conf。一個完整的keepalived配置文件由3個部分組成，分別是全局定義部分、vrrp實例定義部分以及虛擬服務器定義部分。下面詳細介紹這個配置文
件中每一個選項的詳細含義和用法。

http://www.ituring.com.cn/article/179808
http://www.cnblogs.com/quiet/archive/2012/03/19/2406606.html
keepalived採用關鍵字分層的方式來組織配置文件，在上面摘取的配置文件片斷中，共有4層關鍵字，位於第零層的關鍵字有：global_defs, vrrp_instance, vritual_server等，位於第一層的關鍵字有：notification_email, state, delay_loop, real_server等，位於第二層的關鍵字有weight, SSL_GET, 位於第三層的關鍵字有url等，位於第四層的關鍵字有path, digest等。若把位於同一層的關鍵字組織成一個列表(或者叫向量vector)，則該列表具備這樣的特性：它的每個元素都是一個關鍵字，而該關鍵字可能指向下一層的關鍵字列表，如此反覆。
keepalived的配置文件還支持include的用法，能夠在當前配置文件中用include newconf的方式包含下一個配置文件，且下一個配置文件裏面也能夠用include包含下下一個配置文件。並且一個配置文件裏面也能夠用多個include語句包含多個配置文件進行。此外， keepalived還支持在傳遞配置文件名字時，採用包含正則表達式的記法，如：你能夠傳遞一個」*.conf」做爲配置文件的名字，對應的是解析當前目錄下全部以.conf結尾的文件。
如上所述， keepalived在配置文件解析方面擁有很是靈活的方式，採用關鍵字分層（每層的關鍵字數量不限，且關鍵字的層次也不限制）的方法進行組織一個配置文件，且支持include語句和正則表達式記法的配置文件名，要怎麼設計才能夠實現這樣的功能？ keepalived是用C語言實現的，不像python等擁有不少封裝好的庫可使用。具體的解析過程在接下來的文章裏面會進行具體地分析。

#全局定義部分
! Configuration File for keepalived 
global_defs{
#notification_email {
#    dba.gao@gmail.com  #設置報警郵件地址，能夠設置多個，每行一個。注意，若是要開啓郵件報警，須要開啓本機的sendmail服務
#    ixdba@163．com
#}
#  Notification_email_from Alexandre.Cassen@firewall.loc  #設置郵件的發送地址
#  smtp_server  192 .168.200.1    #設置smtp server地址
#  smtp_connect_timeout 30   #設置鏈接smtp server的超時時間
Router_id LVS_DEVEL  #表示運行Keepalived服務器的一個標識,負載均衡器標識，同一網段內，能夠相同。發郵件時顯示在郵件主題中的信息
}

#vrrp 實例定義部分
vrrp_instance VI-1  {   #定義vrrp實例
state MASTER      #指定Keepalived的角色，MASTER表示此主機是主服務器，BACKUP表示此主機是備用服務器
interface eth0    #指定HA監測網絡的接口,LVS監控的網絡接口
Virtual_router_id 51  #虛擬路由標識，這個標識是一個數字，同一個vrrp實例使用惟一的標識，即同一個vrrp_instance下，MASTER和BACKUP必須是一致的
mcast_src_ip  192.168.0.211    #發送多播包的地址，若是不設置，默認使用綁定的網卡的primary IP。
priority 100     #定義優先級，數字越大，優先級越高。在一個vrrp_instance下，MASTER的優先級必須大於BACKUP的優先級
advert_int 1   #設定MASTER與BACKUP負載均衡器之間同步檢查的時間間隔，單位是秒
nopreempt   #設置不搶佔，注意這個設置只能設置在backup狀態主機上，並且這個主機的priority必須比另外的主機高
#reempt_delay   #搶佔延遲，默認5分鐘
Authentication {    #設定驗證類型和密碼
auth_type PASS    #設置驗證類型，主要有PASS和AH兩種
auth_pass 1111    #設置驗證密碼，在一個vrrp_instance下,MASTER與BACKUP必須使用相同的密碼才能正常通訊
}
virtual_ipaddress{  #設置虛擬IP地址，能夠設置多個虛擬IP地址，每行一個
192.168.12.200
#        192.168.1.9    //若是有多個，往下加就好了
#        192.168.1.7
}
}

#虛擬服務器定義部分
virtual_server  192.168.12.200  80 {  #設置虛擬服務囂，須要指定虛擬IP地址和服務端口，IP與端口之間用空格隔開
delay_loop 6    #設置運行狀況檢查時間，單位是秒
lb_algo rr       #設置負載調度算法，這裏設置爲rr．即輪詢算法      
lb_kind DR      #設置 LVS實現負載均衡的機制，有NAT、TUN和DR三個模式可選
Persistence_timeout 50  #會話保持時問，單位是秒，這個選項對動態
                 #網頁是很是有用的，爲集羣系統中的session共享
                #提供了一個很好的解決方案。有了這個會話保持功能，用戶的請求會被
                #一直分發到某個服務節點，直到超過這個會話的保持時間。須要注意的是，
                #這個會話保持時間是最大無響應超時時間，也就是說，用戶在操做動態頁
                #面時，若是在50秒內沒有執行任何操做，那麼接下來的操做會被分發到
                #另外的節點，可是若是用戶一直在操做動態頁面，則不受50秒的時間限制
protocol TCP    #指定轉發協議類型，有TCP和UDP兩種
Real_server  192.168.12.132  80 {  #配置服務節點1,須要指定real aerver的真實IP地址和端口，IP與端口之間用空格隔開
weight 3         #配置服務節點的權值，權值大小用數字表示，數字越大，權值越高，設置
            #權值的大小能夠爲不一樣性能的服務器分配不一樣的負載，能夠爲性能高的
            #服務器設置較高的權值，而爲性能較低的服務器設置相對較低的權值，
            #這樣才能合理地利用和分配系統資源
TCP_CHECK {       #Real_server的狀態檢測設置部分，單位是秒 ,經過tcpcheck判斷RealServer的健康狀態
    connect_timeout 5  #表示5秒無響應超時
    nb_get_retry 3    #表示重試次數
    delay_before_retry 3   #表示重試間隔
    connect_port 80        #檢測端口
    }
}
real_server  192.168.12.133  80 {  #配置服務節點2
weight 1
TCP_CHECK {
    connect_timeout 5
    nb_get_retry 3
    delay_before_retry 3
    connect_port 80       
    }
}

real_server 192.168.201.100 443 {    
    weight 1                       
    TCP_CHECK {
        connect_timeout 3
        nb_get_retry 3
        delay_before_retry 3
    }                                

    SSL_GET {
        url {
          path /
          digest ff20ad2481f97b1754ef3e12ecd3a9cc
        }
        url {
          path /mrtg/
          digest 9b3a0c85a887a256d6939da88aabd8cd
        }
        connect_timeout 3
        nb_get_retry 3
        delay_before_retry 3
    }
}

real_server 192.168.200.2 1358 {
    weight 1
    HTTP_GET {
        url {
          path /testurl/test.jsp
          digest 640205b7b0fc66c1ea91c463fac6334d
        }
        url {
          path /testurl2/test.jsp
          digest 640205b7b0fc66c1ea91c463fac6334d
        }
        url {
          path /testurl3/test.jsp
          digest 640205b7b0fc66c1ea91c463fac6334d
        }
        connect_timeout 3
        nb_get_retry 3
        delay_before_retry 3
    }
}

在配置Keepalived.conf時，須要特別注意配置文件的語法格式，由於Keepalived在啓動時並不檢測配置文件的正確性，即便沒有配置文件，Keepalived也照樣可以啓動，因此必定要保證配置文件正確。
在默認狀況下，Kecpalived在啓動時會查找/ctc/Keepalived/Keepalived.conf配置文件，若是配置文件放在了其餘路徑下，能夠經過「Keepalived-f」參數指定配置文件的路徑便可。
Keepalived.conf配置完畢後，將此文件複製到備用Dircctor Servcr對應的路徑下，而後進行如下兩個簡單的修改便可：
口將「state MASTER」更改成「state BACKUP」。
口將「priority 100」更改成一個較小的值，這裏改成「priority 80」。
2．配置Real server節點
與heartbeat+LVS相似，Keepalived+LVS也須要爲Rcal server節點配置相關的腳本，以達到與Director Server相互通訊的目的。腳本的內容已經在前面介紹過，這裏再也不講述。
3．啓動Keepalived+LVS集羣系統
在主、備Director Server上分別啓動Keepalived服務，能夠執行以下操做：

[ root@DRI ~] #/etc/ init . d/Keepalived      start

接着在兩個Real server上執行以下腳本：

[ root@rsl-l #/etc/init.d/lvars   start

至此，Keepalived+LVS高可用的LVS集羣系統已經運行起來了。

11.5.3經過piranha搭建LVS高可用性集羣
piranha是REDHAT提供的一個基於Web的LVS配置軟件，經過piranha能夠省去手工配置LVS的繁瑣工做。同時，piranha也能夠單獨提供集羣功能，例如，能夠經過piranha激活Dircctor Server的備用主機。

這裏利用piranha來配置Director Server的雙機熱備功能。
1．安裝與配置piranha
piranha工具的安裝很是簡單，下載piranha的rpm包，在主、備Director Server上進行
安裝便可。過程以下：

[rootaDRl~}#rpm -ivh  piranha-0.8.2-1 i386.rpm

也能夠經過yum命令直接在線安裝。過程以下：

[root@DR2  ] # yum install piranha

piranha妄裝完畢後，會產生/etc/sysconfig/ha/lvs.cf配置文件。默認此文件是空的，能夠
經過piranha提供的Web界面配置此文件，也能夠直接手動編輯此文件。編輯好的lvs.cf文
件內容大體以下。

[root@DRI -]# more  /etc/sysconfig/ha/ha.cf
Serial_no=18             #序號
primary =192.168.60.130  #指定主Director Server的真實IP地址
service - Ivs              #指定雙機的服務名
backup_active=1         #是否激活套用Directar Server.」0」表示不激活，「1一表示激活。
                  #這裏選擇激活
backup =192.168.12.131  #這裏指定備用Director Senrer的真實IP地址，若是沒有備用
                     #Director Server，能夠用「0.0.0.0」代替
heartbeat =1              #是否開啓心跳．1表示開啓，0表示不開啓
heartbeat_port -=539       #指定心跳的UDP通訊端口。
keepalive = 5              #心跳間隔時間，單位是秒
deadtime -=10            #若是主Director Server在deadtime{秒）後沒有響應，那麼備用
                    #Director Server就會接管主Director Server的服務
netvork =direct      #指定LVS的工做模式，direct表示DR模式，nat表示NAT模式，tunne1
               #表示TUN模式
debug_level = NONE  #定義debug調試信息級別
virtual  vvww. ixdba _ net {  #指定虛擬服務的名稱
active = 1    #是否激活此服務
address =192.168.12.200  eth0:0  #虛擬服務綁定IP及網絡設備名
port =80    #虛擬服務的端口
send=」GET/HTTP/1.0\r\n\r\n"  #向real 發送的驗證字符串
expect  =」HTTP 」   #服務器正常運行時應該返回的文本應答信息，用來判斷Real Server
              #是否工做正常
use_regex = 0       # expect選項中是否使用正則表達式，0表示不使用，1表示使用
Load_monitor = none  #LVS中的Director Server可以使用rup或ruptime來監視各個
               #Real Server的負載狀態。該選項有3個可選值，rup、ruptime和
               #none，若是選擇rup，每一個Real  Server就必須運行rstatd服務。
               #若是選擇了ruptime，每一個Real Server就必須運行rwhod服務
scheduler = rr        #指定LVS的調度算法
protocol = tcp        #虛擬服務使用的協議類型       
timeout =6       #Real Senrer失效後從LVS路由列表中移除失效Real Server所必須持續
            #的時同，以秒爲單位
reentry =15      #某個Real Server被移除後，從新加入LVS路由列表中必須持續的時間，
            #以秒爲單位
quiesce_server = 0   #若是此選項爲1，那麼當某個新的節點加入集羣時，最少鏈接數會被重設
              #爲零，所以LVS會發送大量請求到此服務節點，形成新的節點服務阻塞，
              #建議設置爲0
server RSl {         #指定Real Server服務名
address =192.168.12.132   #指定Real Server的IP地址
active =1          #是否激活此Real Senrer服務
weight =1        #指定此Real Senrer的權值，是整數值，權值是相對於全部Real Server
            #節點而言的，權值高的Real Server處理負載的性能相對較強
}
server RS2 {
address =192.168.12.133
active =1
weight =1
}
}

接着，還須要對兩個Real Server節點進行配置，也就是建立/etc/init.d/lvsrs腳本，這個
腳本在前面已經講述，這裏再也不介紹。

2．啓動經過piranha配置的LVS集羣系統
將編輯好的lvs.cf從Director Server的主節點複製到備用節點，而後在主、備節點上分
別啓動pulse服務，即啓動LVS服務。過程以下：

[root@DRl-]#service pulse start

接下來，還要在主、備節點上啓用系統的包轉發功能（其實只有在NAT模式下須要）。
命以下：

[rootODRl-]#echo  「1」>/proc/sys/net/ipv4/ip_forward

最後，在兩個Real server節點上執行lvsrs腳本。命令以下：

[root@rsl-]#/etc/init.d/lvsrs  start

到此爲止，利用piranba工具搭建的高可用LVS集羣系統已經運行起來了。

11.6測試高可用LVS負載均衡集羣系統
高可用的LVS負載均衡系統可以實現LVS的高可用性、負載均衡特性和故障自動切換特性，所以，對其進行的測試也針對這3個方面進行。這裏只對Keepalived+LVS實例進行測試,其餘實例也有相似的效果，不一一講述。

11 .6.1 高可用性功能測試
高可用性是經過LVS的兩個Director Server完成的。爲了模擬故障，先將主Director Server上面的Keepalived服務中止，而後觀察備用Director Server上Keepalived的運行日誌。信息以下：
May 4 16:50:04 DR2 Keepalived_vrrp: VRRP_lnatance (VI_l) Tranaition to MASTER STATE
May 4 16:50:05 DR2 Keepalived_vrrp: VRRP_Inatance(VI_l) Entering MASTER STATE
May 4 16:50:05 DR2 Keepalived_vrrp: VRRP Inatance (VI_l) setting protocol VIPs.
May 4 16:50:05 DR2 Keepalived_vrrp: VRRP_Inatance(VI_1) Sending gratuitous（無理由的） ARPs on
Eth0 for 192.168.12.200
May 4 16:50:05 DR2 Keepalived_vrrp: Netlink reflector reports IP 192.168.12.200
added
May 4 16:50:05 DR2 Keepalived_healthcheckers : Netlink reflector reports IP
192 . 168 .12 .200 added
May 4 16:50:05 DR2 avahi-daemon [2551] : Registering new address record for
192 . 168 . 12 . 200 on eth0.
May 4 16:50:10 DR2 Keepalived_vrrp: VRRP_Inatancece(VI_ l) Sending gratuitous ARPs on
eth0 for 192 . 168.12 . 200
從日誌中能夠看出，主機出現故障後，備用機馬上檢測到，此時備用機變爲MASTER
角色，而且接管了主機的虛擬IP資源，最後將虛擬IP綁定在eth0設備上。
按着，從新啓動主Director Server上的Keepalived服務，繼續觀察備用Dircctor Server
的日誌狀態。
May 4 16:51:30 DR2 Keepalived_vrrp:VRRP_lnstance(VI_I) Received higher prio advert
May 4 16:51:30 DR2 Keepalived_vrrp:VRRP_lnstance(VI_I) Entering BACKUP STATE
May 4 16:51:30 DR2 Keepalived_vrrp:VRRP_lnstance(VI_I) removing protocol VIPs.
May 4 16:51:30 DR2 Keepalived_vrrp:Netlink reflector reports IP 192.168.12.200
removed
May 4 16:51:30 DR2 Keepalived_healthcheckers: Netlink reflector reports IP
192 . 168 .12 . 200 removed
May4 16:51:30 DR2 avahi-daemon [2551]:Withdrawing address record for 192.168.12.200
on eth0.
從日誌可知，備用機在檢測到主機從新恢復正常後，從新返回BACKUP角色，而且釋
放了虛擬IP資源。

Linux就這個範兒第11章獨霸網絡的蜘蛛神功第11章

http://www.cnblogs.com/MYSQLZOUQI/p/5257200.html

Linux就這個範兒第15章七種武器

http://www.cnblogs.com/MYSQLZOUQI/p/5335649.html

控制操做方面，用戶空間是經過netlink下發控制命令的。例如NFC_CMD_START_POLL
和NFC_CMD_STOP_POLL是用來查詢目標的操做，而NFC_EVENT_TARGETS_FOUND事件用來返回查詢結果。有關netlink操做可參考代碼4：
代碼4：

Int nfcctl_init{struct nfcctl *ctx}
{
  Int id;
  Int rc;
  printdbg { " IN " } ;
  ctx->nlsk  =  nl_socket_alloc ( ) ;
  if  ( !ctx->nlsk)  {
      printdbg ( " Invalid  context " ) ;
      return -ENOMEM;
}
rc  =  genl_connect ( ctx->nlsk) ;
if (rc) {
  rc   =  -nlerr2syserr ( -rc) ;
      printdbg ( " Error  connecting  to  generic  netlink :   %s " , strerror ( -rc)} ;
  goto free_nlsk;
}
ctx- >nlf amily   =   genl_c trl_resolve ( ctx->nlsk,    NFC_GENL_NAME )  ;
if (ctx->nlfamily < 0) {
      rc   =   -nlerr2 syserr ( -ctx->nlfamily)  ;
      printdbg ( " Error  resolving  genl  NFC  family:   %s" ,   strerror (-rc)} ;
      goto free_nlsk;
}
id   =   get_multicast_id ( ctx ,  NFC_GENL_NAME ,
NFC_GENL_MCAST_EVENT_NAME);
If (id<=0) {
rc = id;
goto free_nlsk;
}
rc  =  nl_socket_add membership (ctx->nlsk,  id) ;
if (rc) {
  printdbg ( " Error  adding  nl  socket   to  membership " ) ;
  rc  =   -nlerr2syserr ( -rc ) ;
  goto free_nlsk
}
......

用戶空間和控制命令處理程序之間用的是netlink，在第15章「七種武器」中的「module
與用戶通訊：netlink方式」部分咱們作了分析與講解。最好的學習方法是貫徹理論與實踐相結合的科學發展觀，結合那節內容與這個NFC實例一塊兒看。

netlink方式
netlink經過爲內核模塊提供一組特殊的API，併爲用戶程序提供了一組標準的socket接口的方式，實現了一種全雙工的通訊鏈接。
相似於TCP/IP中使用AF_INET地址族同樣，netlink使用地址族AF_NETLINK。這種通訊機制相對於系統調用、ioctl以及/proc文件系統而言具備如下優勢：
(1) netlink使用標準的socket API，易用性好。用戶僅須要在flinux/netlink.h中增長一個新類型的netlink協議定義便可，
如#defrne NETLINK_MYTEST 17。而後，內核和用戶態應用就能夠當即經過socket API使用該netlink協議類型進行數據交換。但用其餘方法增長新的特性可不是一件容易的事情，
由於咱們要冒着污染內核代碼而且可能破壞系統穩定性的風險去完成這件事情。系統調用須要增長新的系統調用，ioctl則須要增長設備或文件，
那須要很多代碼，proc文件系統則須要在/proc下添加新的文件或目錄，那將使原本就混亂的/proc更加混亂。
(2) netlink是一種異步通訊機制，在內核與用戶態應用之間傳遞的消息保存在socket緩存隊列中，發送消息只是把消息保存在接收者的socket的接收隊列，
而不須要等待接收者收到消息，但系統調用與ioctl則是同步通訊機制，若是傳遞的數據太長，將影響調度粒度。
(3)使用netlink的內核部分能夠採用模塊的方式實現，使用netlink的應用部分和內核部分沒有編譯時依賴，
但系統調用就有依賴，並且新的系統調用的實現必須靜態地鏈接到內核中，它沒法在模塊中實現(動態庫方式實現)，使用新系統調用的應用在編譯時須要依賴內核。
(4) netlink支持多播，內核模塊或應用能夠把消息多播給一個netlink組，屬於該neilink組的任何內核模塊或應用都能接收到該消息，內核事件向用戶態的通知機制就使用了這一特性，任何對內核事件感興趣的應用都能收到該子系統發送的內核事件。
(5)內核可使用netlink首先發起會話，但系統調用和ioctl只能由用戶應用首先發起調用。
不只如此，對於我這種鍾愛BSD風格的開發者來說，使用這種socket API函數有一種親切感，相對於系統調用或者ioctl方式而言上手更快一些。

11.6.2負載均衡測試
這裏假定兩個Real Server節點上配置www服務的網頁文件的根目錄均爲/wcbdata/www目錄，而後分別執行以下操做：
在real serverl執行：
echo 「This is real serverl」 /webdata/www/index. html
在real server2執行：
echo "Thie is real server2」 /webdata/www/index.html
接着打開瀏覽器，訪問http://192.168.12.200這個地址，而後不斷刷新此頁面。若是
能分別看到「This is real serverl」和「This is real server2」就代表LVS已經在進行負載均衡了。

11.6.3故障切換測試
故障切換是測試在某個節點出現故障後，Keepalived監控模塊是否能及時發現，而後屏
蔽故障節點，同時將服務轉移到正常節點上執行。
這裏將real server 1節點服務停掉，假定這個節點出現故障，而後查看主、備機日誌信息。相關日誌以下：
May 4 17:01:51 DR1 Keepalived_healthcheckers: TCP connection to
[192. 168. 12. 132: 80] failed !!!
May4 17:01:51 DR1 Keepalived_healthcheckers: Removing service [192 .168 .12 .132: 80]
from VS[192. 168. 12 .200: 80]
May 4 17:01:51 DRl Keepalived_healthcheckers: Remote SMTP server [127.0.0.1:25]
connected．
May 4 17:02:02 DRI Keepalived_healthcheckers: SMTP alert successfully sent.
經過日誌能夠看出，Keepalived監控模塊檢測到192.168.12.132這臺主機出現故障後，將此節點從集羣系統中剔除掉了。
此時訪問http://192.168.12.200這個地址，應該只能看到「This is real server2」了。這是由於節點1出現故障，Keepalived監控模塊將節點l從集羣系統中剔除了。
下面從新啓動real server l節點的服務，能夠看到Keepalived日誌信息以下：
May 4 17:07:57 DR1 Keepalived_healthcheckers: TCP connection to
[192 168 .12 . 132 : 80] success.
May 4 17:07:57 DR1 Keepalived_healthcheckers: Adding service [192 . 168 . 12 .132 : 80]
to VS [192 168 12.200 : 80]
May4 17:07:57 DR1 Keepalived_healthcheckers: Remote SMTP server [127.0.0 .1:25]
connected .
May 4 17:07:57 DR1 Keepalived_healthcheckers:SMTP alert auccessfully sent .
從日誌可知，Keepajived監控模塊檢測到192.168.12.132這臺主機恢復正常後，又將此節點加入到集羣系統中。
此時再次訪問http://192.168.12.200這個地址，而後不斷刷新此頁面，應該又能分別看到「This is real serverl」和「This is real server2」頁面了，這說明在real server l節點恢復正常後，Keepalived監控模塊將此節點加入到集羣系統中。
11.7本章小結
這一章詳細講述了經過LVS+heartbeat+Ldirectord、LVS+Keepalived及piranha三種方式來配置高可用LVS集羣系統的過程。這三種方式各有優缺點，讀者能夠根據本身的須要選擇最適合本身的方式。

下面是對這三種方式的總結：
□LVS+heartbeat+Ldirectord方式：
優勢：安裝簡單，而且無需單獨爲ipvsadm編寫腳本。同時，Ldirectord支持端口和
頁面方式進行服務節點監控，配置靈活，能夠根據須要進行選擇。
缺點：配置比較複雜，須要對heartbeat和Ldirectord分別進行配置。
□LVS+Keepalived方式
優勢：安裝簡單、配置簡單，僅須要一個配置文件便可完成全部配量，同時無需單獨
爲ipvsadm編寫腳本。Keepalived對後端服務節點的檢測是基於底層網絡通訊協議的，
所以檢測效率很高，故障切換速度最快。
□piranha方式
優勢：安裝簡單，配置簡單，只需一個Ivs.cf文件便可完成全部配置，也無需爲
ipvsadm編寫腳本。
缺點：在HA cluster雙機切換過程當中，沒有主、備機之分，也就是說先啓動的是主機，
最後啓動的是備用機，而且沒有相似heartbet中的auto- failback功能。

cat /proc/devices
Character devices:
1 mem
4 /dev/vc/0
4 tty
4 ttyS
5 /dev/tty
5 /dev/console
5 /dev/ptmx
7 vcs
10 misc
13 input
14 sound
21 sg
29 fb
99 ppdev
116 alsa
128 ptm
136 pts
162 raw
180 usb
189 usb_device
202 cpu/msr
203 cpu/cpuid
249 hidraw
250 usbmon
251 bsg
252 pcmcia
253 watchdog
254 rtc

Block devices:
1 ramdisk
259 blkext
7 loop
8 sd
9 md
11 sr
65 sd
66 sd
67 sd
68 sd
69 sd
70 sd
71 sd
128 sd
129 sd
130 sd
131 sd
132 sd
133 sd
134 sd
135 sd
253 device-mapper
254 mdp
[root@steven ~]# cat /proc/misc
57 autofs
184 microcode
58 device-mapper
59 network_throughput
60 network_latency
61 cpu_dma_latency
62 crash
175 agpgart
144 nvram
228 hpet
231 snapshot
227 mcelog
63 vga_arbiter

負載均衡的發展歷程
http://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=403078442&idx=2&sn=bd31fddfccafde520a2fb0060e9b6522&scene=0#wechat_redirect
1996 F5成立
1998 LVS項目成立
2000 HAProxy項目成立
2004 NGINX推出公共版本
2004 F5推出TMOS平臺
2007 F5開始提供應用交付（ADC）產品
負載平衡､SSL卸載、壓縮優化、TCP鏈接優化

（一）LVS的痛點
LVS最經常使用的有NAT、DR以及新的FULL NAT模式。上圖比較了幾種常見轉發模式的優缺點。

咱們認爲LVS的每種模式都有其優勢和缺點，但最大的問題是其複雜性。相信不少朋友看到這三種方式的優缺點、還有F5的單臂模式、雙臂模式都會有云裏霧裏的感受。

（二）LVS集羣的痛點

雪上加霜的是我們還須要考慮LVS的性能擴展和容災方法，這使得整個方案更加的複雜。常見的有基於Keepalived的主備方式和ECMP兩種。
Keepalived 主備模式設備利用率低；不能橫向擴展；VRRP協議，有腦裂的風險。而ECMP的方式須要瞭解動態路由協議，LVS和交換機均須要較複雜配置；交換機的 HASH算法通常比較簡單，增長刪除節點會形成HASH重分佈，可能致使當前TCP鏈接所有中斷；部分交換機的ECMP在處理分片包時會有BUG。

基於DR轉發方式
LVS 支持四種轉發模式：NAT、DR、TUNNEL和FULLNAT(FULLNAT最近新加入的模式還爲合併到內核主線)，其實各有利弊。Vortex在設計之初就對四種模式作了評估，最後發如今虛擬化的環境下DR方式在各方面比較平衡，而且符合咱們追求極致性能的理念。DR方式最大的優勢是絕佳的性能，只有request須要負載均衡器處理，response能夠直接從後端服務器返回客戶機，不管是吞吐仍是延時都是最好的分發方式。其次，DR方式不像NAT模式須要複雜的路由設置，並且不像NAT模式當client和後端服務器處於同一個子網就沒法正常工做。DR的這個特性使他特別合適做爲內網負載均衡。此外，不像FULLNAT同樣須要先修改源IP再使用 TOA 傳遞源地址，還得在負載均衡器和後端服務器上都編譯非主線的Kernel Module，DR能夠KISS（Keep It Simple, Stupid）地將源地址傳遞給後端服務器。最後，虛擬化環境中已經採用Overlay虛擬網絡了，因此TUNNEL的方式變得徹底多餘。而DR方式最大的缺點：須要LB和後端服務器在同一個二層網絡，而這在UCloud的虛擬化網絡中徹底不是問題。主流的SDN方案追求的正是大二層帶來的無縫遷移體驗，且早已採用各類優化手段（例如ARP代理）來優化大二層虛擬網絡。