首先我們要了解LVS的工作機制:
LVS裏Director本身不響應請求，只是接受轉發請求到後方，Realservers纔是後臺真正響應請求。
LVS 工作原理基本類似DNAT，又不完全相像，它是一種四層交換，默認情況下來通過用戶請求的的地址和端口，來判斷用戶的請求，從而轉發到後臺真正提供服務的主機，而判斷這種請求的是通過套接字來實現，所以四層就可以實現。而且這個轉發的過程對用戶而言是透明的（簡單的講，就是用戶訪問的是DR的IP，而DR轉發給RSS，而用戶不知道這個過程）
LVS的工作模式:
1.DNAT
2.直接路由
3.隧道
提供的優點：
1.高併發
2.高冗餘
3.適用性，擴展服務器，縮減服務器，方便服務器擴展和收縮
LVS 的IP地址類型
1.VIP:虛擬IP地址，並不提供服務，而是將用戶的請求轉發到後方
2 RIP:真正IP地址，客戶端真正提供服務的IP地址
3.DIP:調度IP地址，通常是和RIP相連的LVS的IP地址
4.CIP:客戶端IP地址，用戶請求時，用戶的IP
流程：如下圖
===============================分 割 線==============================
LVS集羣的類型：
1.LVS-NAT DNAT
2.LVS-DR 直接路由
3.LVS-TUN 隧道
下面我們詳細說明這三種類型：
LVS-NAT模型原理
用戶的請求和響應都需要經過Director
源地址，目標地址都需要經過轉換，而目標地址轉換是透明的
這種架構的擴展有限調度器，Director將處理所有的請求，壓力比較大，擴展到10個結點就不行了
要求：
1.集羣節點必須在同一個物理網絡中，同一個子網或者VLAN
2.DIP和RIP只能在同一個網絡（子網）中，不能跨越網段
3.RIP地址通常是私有地址
4.所有的RIP，必須以DIP爲網關（地址轉換）
5.NAT的地址可以做端口轉換（比如80--à8080）
6.任何操作系統都可以做RIP
7.Director有可能成爲整個系統的瓶頸
數據傳輸：
通過二層（數據鏈路層）轉發（ARP）將DR的MAC地址轉換成RIP的MAC地址（不是轉變，而是轉發），這樣就實現了數據的傳輸，在RSS響應後，再將RSS的MAC地址轉換成RIP的MAC地址。
===============================分 割 線==============================
LVS-DR模型原理
用戶的請求必須經過Director，而realserver在響應的使用直接返回請求（圖有問題，有可能設的網關不同，還存在一臺路由器）
需要配置iptables規則，拒絕響應MAC地址轉換，或者通過修改LINUX內核響應
優點：由於它比NAT少了一個地址轉換，響應速度更快
特點
1.必須處於同一個物理網絡中（連在同一個交換機上）
2.RIP可以使用公網地址（建議使用）
3.Director只轉發請求，而realserver直接響應請求而不轉發
4.集羣節點的網關，不能指向DIP
5.不能做端口轉換（不支持）
6.絕大多數的操作系統都可以實現realserver,而realserver需要同一個網卡配置多個Ip地址
7.DR模式的Director比NAT模式能夠帶動更多的節點
數據傳輸：
解決數據進入：
爲了避免RS直接響應，給服務器的lo:0設置VIP地址，給本地網卡設置成CIP，這樣RS就不會直接響應了，隱藏了RS
解決數據出去：
而默認情況下，Linux設置數據包從哪塊網卡出去，源地址設爲該網卡地址，通過添加一條特殊路由信息，如果目標地址是lo的VIP地址，那麼出去的時候源地址設置爲lo的地址。
路由信息的原理：
添加一條主機路由，將VIP的地址自己設置成一個網段,既子網掩碼爲255.255.255.255，這樣VIP出去的時候沒有比VIP更優的了，就成爲最佳IP
在互聯網上性能最佳的就是DR應用，但是有一個缺點，必須要求主機間距離比較近（比如一個機房），如果發生天災人禍，集羣就完了，所以我們爲了實現異地分佈，要採用隧道比如***
===============================分 割 線==============================
LVS-TUN模型原理：
虛擬隧道實現：
1.專線（加密）
2.二層：在MAC之外再加一層MAC
3.三層：源IP目標IP之外再加一層IP
隧道目的: 隱藏意圖，通過轉換來（ip套ip）隱藏目的
特徵：
1.集羣節點和Director不必在同一個網絡
2.RIP必須使用公網地址
3.Director只需要處理進來的請求，不需要處理出去的請求
4.響應的請求一定不能經過Direcor.
5.Directory不支持端口映射
6.只能使用那些支持IP 隧道協議的操作系統做realserver
優點：LVS-TUN可以實現基於網絡的集羣，這樣就脫離了LVS-DR的realserver之間的距離限制。
===============================分 割 線==============================
LVS的負載均衡要依賴算法（Scheduling methods :調度方法）來實現，根據特點它們分爲如下兩類：
1.fiexd scheduling 靜態（固定）
2.dnamic scheduling 動態
FIEXD SCHEDULING靜態算法
特點：不考慮後端realserver的連接狀態，而動態的要考慮後端的鏈接數爲標準
1. Round-robin (RR) 輪詢
既第一次訪問A，第二次訪問B,第三次再訪問A…..循環下去
2. Weighted Round-Robin WRR
加強論調：提高後臺服務器的響應能力
根據後方服務器的響應能力，來定義權重，根據權重來轉發請求，權重大的優先訪問
3.Destination hashing DH
目的：實現針對目標地址的請求做固定轉發
將來自同一個用戶的特定請求轉發到固定的指定的主機（比如提供web服務），以提高緩存（網頁文件緩存）利用率（命中率）。
4.Souce hashing SH
目的：將來自同一個用戶的地址，始終轉發到router或者firewall
應用場景：
將用戶的請求按照平均指定到不同的防火牆，實現平均內網負載，通過特定防火牆（網關）出去（上網）
靜態算法的缺陷：不考慮後臺real-server的負載,連接狀態
動態算法：Dynamic Scheduling Mehtod
這裏有兩個概念：
活動連接：後臺real-server當前處於活動狀態（active）和ESTABLISHED state（想關聯）的連接，像ssh，或者telnet會一直處於活動狀態。
非活動連接：非活動的狀態（inactive）或者非FIN的數據包,比如httpd(未開啓keepalive), 而httpd除非啓用keepalive, 發送完成後直接斷開，處於inactive的狀態
相關動態算法 ：
1. LC least-connection 最少連接
LC同時檢查一臺主機上的活動連接數和非活動連接數，連接數最少（活動狀態的連接數少）的將會接受下一個連接請求。
LC同時考察活動連接和非活動連接，它用活動連接*256+非活動連接作爲 overhead 通過overhead誰的小，轉發給誰
但是非活動鏈接也會影響連接，當活動連接的比數比較大的時候，會影響結果
2.WLC Weighted Least-Connection 加權最少連接數
加權按照機器的性能劃分。Overhead/加權請求要轉發給小得那個
加權算法，是集羣應用上的最好的算法之一，比較公平
2. SED Shortest Expected Delay 最短延遲
在WLC基礎上改進
Overhead = （ACTIVE+1）*256/加權
不再考慮非活動狀態，把當前處於活動狀態的數目+1來實現，數目最小的，接受下次請求
+1的目的是爲了考慮加權的時候，非活動連接過多
缺陷：當權限過大的時候，會倒置空閒服務器一直處於無連接狀態
3.NQ算法永不排隊
保證不會有一個主機很空間。在SED基礎上無論+幾，第二次一定給下一個，保證不會有一個主機不會很空閒
不考慮非活動連接，才用NQ，SED要考慮活動狀態連接
對於DNS的UDP不需要考慮非活動連接，而httpd的處於保持狀態的服務就需要考慮非活動連接給服務器的壓力
4.LBLC 基於本地的最少連接算法
和DH的區別：考慮後臺的負載能力和連接情況
支持權重，它在WLC基礎上改進
5.LBLCR 基於本地的帶複製的最少連接數
是對LBLC的一個改進，能夠在LBLC的基礎上實現負載均衡
判斷後端，到底誰的連接少，當A的連接很多，而B的很空閒，會將A的部分連接分配到B上（打破原有規則，避免大範圍的不公平）
項目實踐：配置LVS Director（WEB LVS）的HA集羣，要求：
1、DR模型；
2、能監控後臺RealServer的健康狀態；
實現原理：
1）使用LVS-DR模型構建集羣實現負載均衡
2）使用heartbeat構建雙Director組成HA集羣，提高Director的高可用性
3）利用腳本實現檢測後臺realserver健康狀態，當一臺服務器發生故障時，自動將其從集羣裏刪除，待恢復後，再加入集羣中
4）虛擬IP ：172.16.14.1爲兩臺DR想爭奪的資源，通過IP的論調來實現HA
主機名規劃： 兩臺DR ：DR1，DR2
每臺DR配置兩塊網卡，一塊用來連接“提供服務”，一塊用來連接“心跳信息”
實現雙director組成HA步驟：
1. 配置網卡IP地址信息,都是設置爲靜態地址
DR1上：
2.安裝ipvsadm，heartbeat v2 並配置須實現下載好所需軟件包到一個文件夾裏：
heartbeat-2.1.4-9.el5.i386.rpm heartbeat-pils-2.1.4-10.el5.i386.rpm
heartbeat-devel-2.1.4-9.el5.i386.rpm heartbeat-stonith-2.1.4-10.el5.i386.rpm
heartbeat-gui-2.1.4-9.el5.i386.rpm libnet-1.1.4-3.el5.i386.rpm
DR1 DR2上：
yum localinstall -y -nogpgcheck *.rpm
yum install ipvsadm -y
我們需要手動拷貝heartbeat的配置文件到/etc/ha.d下
cd /etc/ha.d
cd /usr/share/doc/heartbeat-2.1.4/
cp ha.cf haresources authkeys /etc/ha.d
修改主機名稱：
hostname node1.a.org
vim /etc/hosts # 添加下面兩行
172.16.14.11 node1.a.org node1
172.16.14.12 node2.a.org node2
vim /etc/sysconfig/network #修改network值於主機名對應
HOSTNAME=node1.a.org
配置三個配置文件
cd /etc/ha.d #添加下面的內容
vim ha.cf
node node1.a.org #節點名稱，注意要在/etc/hosts裏面定義主機名和這個一致
node node2.a.org
bcast eth1 #心跳信息傳播網卡
logfile /var/log/ha-log #打開日誌文件
vim haresources #配置虛擬IP資源
# HA開啓時分配給DR1 自動配置爲eth0:0 172.16.14.1/172.16.14.1 並且開啓ipvsadm
node1.a.org 172.16.14.1/16/eth0/172.16.14.1 ipvsadm
編輯 authkeys
vim authkeys # 定義心跳傳送加密方式和密鑰
auth 2
2 sha1 13db1dff9f50c88841f4199457b11091
# 編輯完後要將該文件改爲400 或600否則無法啓動
chmod 400 authkeys
生成ssh密鑰，複製到DR2主機
# 創建key文件
ssh-keygen -t rsa
# 複製到node2上
ssh-copy-id -i .ssh/id_rsa.pub root@node2
以上步驟在DR2上也執行一次，注意IP的變化
3.配置ipvsadm
[root@node1 ha.d]# ipvsadm -A -t 172.16.14.1:80
[root@node1 ha.d]# ipvsadm -a -t 172.16.14.1:80 -r 172.16.14.21
[root@node1 ha.d]# ipvsadm -a -t 172.16.14.1:80 -r 172.16.14.22
[root@node1 ha.d]# ipvsadm -a -t 172.16.14.1:80 -r 172.16.14.23
# 將配置好的表保存在/etc/sysconfig/ipvsadm 這樣可以使用ipvsadm腳本來實現DR的控制
ipvsadm -S > /etc/sysconfig/ipvsadm
同樣的操作，在DR2上進行一次
4.編寫監控腳本,用於監控後臺RSS的狀態
# 將該腳本的路徑添加到ipvsadm的啓動腳本里
vim /etc/init.d/ipvsadm
# 在start的最後一行添加
/root/.testrss.sh &
# 在stop的最後一行添加
killall testrss.sh
拷貝兩個腳本到DR2上
[root@node1 ha.d]# cd /etc/init.d/
[root@node1 init.d]# scp /root/.testrss.sh ipvsadm node2:/etc/init.d/
這樣就實現了HA的兩個DR節點在搶奪資源的時候，開啓ipvsadm服務的同時，啓動監控腳本，項目目標達成。
現在我們通過heartbeat的一個插件ldriector來實現項目功能。
項目實踐：配置LVS Director（WEB LVS）的HA集羣，要求：
1、DR模型；
2、能監控後臺RealServer的健康狀態；
相關網卡配置見上篇文章，這裏只說明ldrictor的使用。
1安裝
需要準備的軟件包（已經安裝過heartbeat v2）：
perl-MaliTools heartbeat-ldirectored
將其放在一個文件夾
yum --nogpgcheck localinstall *.rpm
2.複製ld的配置文件到/etc/ha.d
[root@node1 /]# cd /usr/share/doc/heartbeat-ldirectord-2.1.4/
[root@node1 heartbeat-ldirectord-2.1.4]# ls
COPYING ldirectord.cf README
[root@node1 heartbeat-ldirectord-2.1.4]# cp ldirectord.cf /etc/ha.d/
[root@node1 heartbeat-ldirectord-2.1.4]# cd /etc/ha.d/
[root@node1 ha.d]# ls
authkeys harc ldirectord.cf README.config shellfuncs
ha.cf haresources rc.d resource.d
只需要把LVS需要定義的集羣定義到/etc/ha.d/ldirector.cf，不需要ipvsadm來實現
3.修改 ldirector
vim ldirector.cf
# 修改配置文件,只啓用如下內容
checktimeout=10
# ldirectord等待Realserver健康檢查完成的時間，單位爲秒；
# 任何原因的檢查錯誤或超過此時間限制，ldirector將會將此Realserver從IPVS表中移除；
checkinterval=2
autoreload=yes
# 此項用來定義ldirectord是否定期每隔一段時間檢查此配置文件是否發生改變並自動重新加載此文件；
logfile="/var/log/ldirectord.log"
# 定義日誌文件存放位置；
quiescent=yes
# 當某臺Realserver出現異常，此項可將其設置爲靜默狀態（即其權重爲“0”）從而不再響應客戶端的訪問請求；
virtual=172.16.14.1:80
# 此項用來定義LVS服務及其使用的VIP和PORT
real=172.16.14.21:80 gate 1
real=172.16.14.22:80 gate 2
real=172.16.14.23:80 gate 3
fallback=127.0.0.1:80 gate
# 當IPVS表沒有任何可用的Realserver時，此“地址：端口”作爲最後響應的服務；
# 一般指向127.0.0.1，並可以通過一個包含錯誤信息的頁面通知用戶服務發生了異常；
service=http
# 定義基於什麼服務來測試Realserver；
request="index.html"
receive="Test Page"
scheduler=wlc
protocol=tcp
# 定義此虛擬服務用到的協議；
checktype=negotiate
# ldirectord進程用於監控Realserver的方法；{negotiate|connect|A number|off}
checkport=80
在haresource裏添加如下行，以啓用ldriector
vim haresorce
node1.a.org 172.16.14.1/32/eth0/172.16.14.1 ldirectord::ldirectord.cf
拷貝這兩個文件到node2上
scp haresources ldirectord.cf node2:/etc/ha.d
啓用服務
/etc/init.d/heartbeat start
ssh node2 -- '/etc/init.d/heartbeat start'
至此，ldirector配置完成，我只做相關測試而沒有配置後臺的三個RSS，來看一下效果
由於後臺三個RSS就沒有開啓（相當於當機），ldirictor默認將他們的權重都設爲0既不生效，而把本地的80開啓，這個外界訪問時，將看到一個提示界面(可以自己定義一些內容，比如網站維護中等)