天啊，距離小編將HA羣集已經有一個多月啦，還記得小編在HA羣集最後提出的一個小問題麼，沒有企業會拿HA來做一些普通業務的，HA一般都是來做一些關鍵性業務的，那麼在這篇博客中小編就來講講LB羣集（負載均衡羣集）的原理以及實現啦
一、負載均衡羣集總體架構
使用負載均衡羣集能實現綜合業務的海量併發，在負載均衡架構中，Director（dispatcher）負責接收客戶端請求，並將請求按照某種算法分發到後臺真正提供服務的服務器上。按照層次來劃分，有四層交換和七層交換。爲了實現這種技術可以基於硬件來實現，常用的有F5（四層交換），也可以基於軟件來實現ipvs（四層交換）、squid（七層交換）、nginx（七層交換）
二、使用LVS（Linux Virtual Server）來實現負載均衡
在linux的2.4之後的內核中有一種實現數據包請求處理的模塊叫ipvs，並且提供了的相關客戶端軟件ipvsadm來實現規則的定義以完成對請求數據包的處理，小編的內核是2.6.18，看看它的內核配置文件可以發現IPVS的
LVS的整體架構如圖2-1所示：
圖2-1
VIP(Virtual IP)：Director對外呈現的IP地址，用戶可以通過VIP來獲取相關服務；
DIP(Director's IP)：Director用來和Real Server通信的IP；
RIP(Real IP)：Real Server的IP；
三、LVS的模型分類
根據Director和後端服務器的通信方式，LVS大致可分爲三類：Network Address Translation（LVS-NAT）、Director routing （LVS-DR ）、IP tunneling (LVS-TUN )，小編就每一種分類做一下簡要說明
1、Virtual Server via Network Address Translation（LVS-NAT）
通過網絡地址轉換，Director重寫請求報文的目標地址，根據預設的調度算法，將請求分派給後端的Real Server；Real Server的響應報文通過Director時，報文的源地址被重寫，再返回給客戶，完成整個負載調度過程。可以想象一下，所有的數據請求都經過Director，那實現Director的服務器壓力三大啦；
2、Virtual Server via Direct Routing（LVS-DR）
爲了解決LVS-NAT的的問題，便產生了LVS-DR，外界用戶發送每次發送數據請求的時候是要經過Director的，Director通過一定得調度算法選擇Real Server並將收到的客戶端請求報文的目標MAC改寫成爲被選Real Server的MAC地址，而Real Server將響應客戶端的時候並不經過Director了。
3、Virtual Server via IP Tunneling（LVS-TUN）
Director把請求報文通過IP隧道轉發至Real Server，而Real Server將響應直接返回給客戶，所以Director只處理請求報文。由於一般網絡服務應答比請求報文大許多，採用 LVS-TUN技術後，集羣系統的最大吞吐量可以提高10倍。
四、Director採用的調度算法
Director支持的調度算法可以直接從內核配置文件中看到的，如圖4-1所示：
圖4-1
當然這九種調度算法又可以分爲兩大類，分別是靜態調度和動態調度啦，小編這裏做一下解釋：
1、固定調度算法
按照某種既定的算法，不考慮實時的連接數予以分配：
A、Round-robin（RR）輪循：將外部請求按順序輪流分配到集羣中的Real Server， 它均等地對待每一臺服務器，而不管服務器上實際的連接數和系統負載；
B、Weighted round-robin（WRR）加權輪詢：給每臺Real Server分配一個權值，權值越大，分到的請求數越多；
C、Destination hashing （DH）目標散列：根據請求的目標IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。來自於同一個IP地址的請求都被重定向到同一臺Real Server上，保證目標地址不變；
D、Source hashing（SH）源地址散列：根據請求的源IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。Director必須確保響應的數據包必須通過請求數據包所經過的路由器或者防火牆，保證源地址不變。
2、動態調度算法
通過檢查服務器上當前連接的活動狀態來重新決定下一步調度方式該如何實現：
A、Lease Connection （LC） 最少連接：哪一個Real Server上的連接數少就將下一個連接請求定向到那臺Real Server上去。算法實現：連接數=活動連接數*256+非活動連接數；
B、Weight Least-Connection（WLC） 加權最少連接：在最少連接的基礎上給每臺Real Server分配一個權重。算法實現：連接數=（活動連接數*256+非活動連接數）÷權重，是一種比較理想的算法；
C、Shortest Expected Delay (SED) 最短期望延遲：不再考慮非活動連接數，算法實現：連接數=(活動連接數+1) *256 ÷權重；
D、Never Queue (NQ) 永不排隊算法：對SED的改進，當新請求過來的時候不僅要取決於SED算法所得到的值，還要取決於Real Server上是否有活動連接；
E、Locality-Based Least-Connection (LBLC) 基於本地狀態的最少連接：在DH算法的基礎上還要考慮服務器上的活動連接數；
F、Locality-Based Least-Connection with Replication Scheduling (LBLCR) 帶複製的基於本地的最少連接：是LBLC算法的改進。
五、LVS-NAT
目標地址轉換，即所有客戶端的請求都被Director根據訪問請求和算法被定向到後臺的Real Server 上，後臺的Real Server迴應客戶端的數據包也要經過Director返回給客戶端，地址轉換過程如圖5-1所示：
圖5-1
LVS-NAT特性：
1、Director和Real Server必須在同一個網段中；
2、一般情況下，RIP是私有地址，只用於集羣內部節點間通信；
3、Director 會響應所有的請求在客戶端和Real Server之間，所承擔的負載較大；
4、所有的Real IP 網關必須指向DIP以響應客戶端請求；
5、Director可以重映射網絡端口，即前端使用標準端口，後端使用非標準端口；
6、後臺的Real Server可以使用任何操作系統；
7、Director可能會成爲系統瓶頸。
LVS-NAT集羣的設計及實現
拓撲如圖5-2所示：
圖5-2
Director ： VIP 192.168.0.80
DIP 192.168.110.254
Real Server 1： RIP 192.168.10.2 網關指向：192.168.110.254
提供Web服務，測試頁內容爲 Web1
Real Server 2： RIP 192.168.10.3 網關指向：192.168.110.254
提供Web服務，測試頁內容爲 Web2
Client： 192.168.0.1 客戶端
Real Server 1：
# ifconfig eth0 192.168.110.2 //爲eth0 設置IP地址；
# route add default gw 192.168.110.254 //添加網關；
Real Server 2：
# ifconfig eth0 192.168.110.3 //同上；
# route add default gw 192.168.110.254 //同上；
Director：
# ifconfig eth1 192.168.110.254 //爲Director 設置DIP；
# echo 1 > /proc/sys/net/ipv4/ip_forward //開啓內核路由功能；
# vim /etc/sysctl.conf //修改內核參數，確保永久有效；
net.ipv4.ip_forward = 1
# sysctl -p //查看內核參數；
net.ipv4.ip_forward = 1
準備工作已經配置完畢，開始LVS-NAT的配置：
# yum install ipvsadm -y //安裝ipvsadm工具；
# ipvsadm -A -t 192.168.0.80:80 -s rr //定義服務，設定算法
爲服務添加Real Server並設置權重：
# ipvsadm -a -t 192.168.0.80:80 -r 192.168.110.2 -m -w 5
# ipvsadm -a -t 192.168.0.80:80 -r 192.168.110.3 -m -w 2
# ipvsadm -Ln //查看服務狀態；
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.80:80 rr
-> 192.168.110.3:80 Masq 5 0 11
-> 192.168.110.2:80 Masq 2 0 12
此時，我們使用物理機訪問http：192.168.0.80就會發現頁面出現交替變化的情況，這是由RR算法的特性決定的。我們改變爲WRR算法試試：
# ipvsadm -E -t 192.168.0.80:80 -s wrr //改爲WRR調度算法；
# ipvsadm -Ln
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.80:80 wrr
-> 192.168.110.3:80 Masq 5 0 50
-> 192.168.110.2:80 Masq 2 0 21
改變爲LBLC算法：
# ipvsadm -E -t 192.168.0.80:80 -s lblc
# ipvsadm -Ln
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.80:80 lblc
-> 192.168.110.3:80 Masq 5 0 100
-> 192.168.110.2:80 Masq 2 0 35
此時會發現無論客戶端怎麼刷新，訪問頁面都不會改變，這是由LBLC調度算法所決定的。
六、LVS-DR
直接路由就是客戶端請求經過Director分發給Real Server後，Real Server直接回應客戶端。如圖6-1所示，數據包地址轉換過程：
圖6-1
LVS-DR特性：
1、Real Server 上必須配置VIP且需要隱藏起來，只有在響應客戶端請求時才使用VIP作爲源地址，除此之外並不使用此VIP；
2、集羣節點和Director必須在同一個網絡中；
3、RIP不要求爲私有地址；
4、Director僅處理所有進來的請求；
5、Real Server 不能以DIP作爲網關，而是以公網上的某臺路由器作爲網關；
6、Director 不能再使用端口重映射；
7、大多數操作系統可以被用來作爲Real Server，windows除外；
8、LVS-DR模式可以處理比LVS-NAT更多的請求。
LVS-DR爲實際生產環境中最常用的一種方式，因爲RIP 爲公網地址，管理員可以遠程連接Real Server來查看工作狀態；當Director 當掉，可以通過修改DNS記錄將A記錄指向RIP 繼續向外提供服務。
Director分發到Real Server的過程中，數據包的源地址和目標地址都沒有發生改變，Director僅僅是將目標mac地址轉換成某臺Real Server的mac地址，源mac地址改爲Director內網網卡的mac地址。這裏，我們要解決的兩個技術難題：
1、Real Server要避免迴應客戶端發來的對VIP的arp地址解析請求；
解決方法：
修改內核的兩個參數：arp_announce, arp_ignore；
arp_announce ：定義不同級別：當ARP請求通過某個端口進來是否利用這個接口來回應；
0 默認級別，利用本地的任何地址，不管配置在哪個接口上去響應ARP請求；
1 避免使用另外一個接口上的mac地址去響應ARP請求；
2 儘可能使用能夠匹配到ARP請求的最佳地址。
arp_ignore：當ARP請求發過來後發現自己正是請求的地址是否響應；
0 默認級別，利用本地的任何地址，不管配置在哪個接口上去響應ARP請求；
1 哪個接口上接受ARP請求，就從哪個端口上回應。
Red Hat系統提供了arptables工具，利用arp防火牆也可以實現。
2、當Real Server內網網卡響應客戶端請求時，要以VIP作爲源地址，不能以RIP作爲源地址。
解決方法:添加一條路由
route add -host 192.168.110.1 dev lo:0
使客戶端訪問VIP，就讓VIP來響應客戶端。這樣避免了使用RIP作爲源地址。
圖6-2
Director ： eth0:0 VIP 192.168.110.1
eth0 DIP 192.168.110.254
Real Server 1： eth0 RIP 192.168. 110.2
lo:0 VIP 192.168. 110.1
提供Web服務，測試頁內容爲 Web1
Real Server 2： eth0 RIP 192.168.110.3
lo:0 VIP 192.168.110.1
提供Web服務，測試頁內容爲 Web2
Client：192.168.110.2 客戶端
Real Server 1:
# vim /etc/sysctl.conf //修改內核參數，避免迴應客戶端發來的對VIP的arp地址解析請求；
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_announce = 2
# sysctl -p //顯示內核參數；
# ifconfig eth0 192.168.110.2/24 //設置IP地址RIP；
# ifconfig lo:0 192.168.110.1 broadcast 192.168.110.1 netmask 255.255.255.255 // 設置VIP；
# route add -host 192.168.110.1 dev lo:0 //添加路由；
Real Server 2網卡eth0的地址爲192.168.110.3，服務的設置方法同Real Server 1一致。
Director:
# ifconfig eth0 192.168.110.254/24 //設置DIP；
# ifconfig eth0:0 192.168.110.1 broadcast 192.168.110.1 netmask 255.255.255.255 //設置VIP；
# route add -host 192.168.110.1 dev eth0:0 // 添加路由；
# echo 1 > /proc/sys/net/ipv4/ip_forward //開啓內核路由功能；
# ipvsadm -C //清空規則；
# ipvsadm -A -t 192.168.110.1:80 -s wlc //添加服務，設定調度算法；
添加Real Server：
# ipvsadm -a -t 192.168.110.1:80 -r 192.168.110.2 -g -w 5
# ipvsadm -a -t 192.168.110.1:80 -r 192.168.110.3 -g -w 8
使用物理機瀏覽器訪問http://192.168.110.1，查看服務狀態，就可以看到兩臺Real Server的非活動連接數之比近似於5:8，這是由分配的權重所決定的。
# ipvsadm -Ln //查看服務狀態；
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.110.1:80 wlc
-> 192.168.110.3:80 Route 8 0 18
-> 192.168.110.2:80 Route 5 0 11
七、LVS-TUN
如圖7-1所示，LVS-TUN模式與LVS-DR的網絡結構一樣，但Director和Real Server可以在不同的網絡當中。數據包從Director到Real Server過程中是基於隧道來傳輸，在數據包外層額外封裝了S:DIP D:RIP 的地址。
圖7-1
LVS-TUN特性：
1、Director和Real Server 不需要在同一個物理網絡中；
2、RIP一定不能是私有地址；
3、Director只負責處理進來的數據包；
4、Real Server直接將數據包返回給客戶端，所以Real Server默認網關不能是DIP，必須是公網上某個路由器的地址；
5、Director不能做端口重映射；
6、只有支持隧道協議的操作系統才能作爲Real Server。
儘管我們選擇了LVS的分發方法，但是大多時候我們要保證返回給客戶端的所有響應請求必須來自於同一臺Real Server，這裏我們就要用到LVS Persistence（持久性）。當使用SSL會話的時候，我們常常期望只交換一次密鑰就可以建立永久連接，因此，LVS持久性在SSL會話中經常被用到。
使用LVS持久性的時候，Director在內部使用一個連接根據記錄稱之爲“持久連接模板”來確保所有來自同一個客戶端的請求被分發到同一臺Real Server上。
LVS 持久性類型分爲PCC、PPC、PNMP、混合類型：
1、Persistent client connections
來自同一客戶端所有服務的請求都被重定向到同一臺Real Server上，以IP地址爲準。PCC是一個虛擬服務沒有端口號（或者端口號爲0），以"-p" 來標識服務。
缺點是定向所有服務，期望訪問不同的Real Server無法實現。
假設一個用戶在訪問購物網站時同時使用HTTP（80）和HTTPS（443）兩種協議，就需要這樣定義：
ipvsadm -A -t 192.168.110.1:0 -s rr -p
ipvsadm -a -t 192.168.110.1:0 -r 192.168.110.2 -m
ipvsadm -a -t 192.168.110.1:0 -r 192.168.110.3 -m
2、Persistent port connections
來自同一服務的請求都被重定向到同一臺Real Server上，以端口號爲準。例如：client---->LVS(80,22)---->RS1
client---->LVS(23)---->RS2
缺陷：期望訪問不同的端口到同一臺RS上，無法實現。
3、Persistent Netfilter Marked Packet persistence
根據iptables 的規則，將對於某類服務/幾個不同端口的訪問定義爲一類。具體過程是先對某一特定類型的數據包打上標記，然後再將基於某一類標記的服務送到後臺的Real Server上去，後臺的Real Server 並不識別這些標記。
由於LVS-DR模型作了網卡別名，所以並不適合PNMP，因此PNMP只能用在LVS-NAT模式下：
# iptables -t mangle -A PREROUTING -i eth0 -d 192.168.110.1 -p tcp --dport 80 -j MARK --set-mark 2
# ipvsadm -A -f 2 -s wlc -p 3600
# ipvsadm -a -f 2 -r 192.168.110.2 -m -w 2
# ipvsadm -a -f 2 -r 192.168.110.3 -m -w 5
服務狀態
# ipvsadm -Ln
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
FWM 2 wlc persistent 3600
-> 192.168.110.3:0 Masq 5 0 70
-> 192.168.110.2:0 Masq 2 0 0
來自同一客戶端的訪問請求都被分發到192.168.110.3這臺Real Server上去了。
將持久和防火牆標記結合起來就能夠實現端口姻親功能，只要是來自某一客戶端的對某一特定服務（需要不同的端口）的訪問都定義到同一臺Real Server上去。
假設這樣一種場景：一個用戶在訪問購物網站時同時使用HTTP（80）和HTTPS（443）兩種協議，我們需要將其定義到同一臺Real Server上，而其他的服務不受限制，可以這樣來實現：
這裏會用到根CA，讀者如果不清楚的話可以看看小編原來的博客
Real Server 1：
# cd /etc/pki/tls/certs/
# make httpd.pem //做一個自簽名證書，內容如8-1示：
圖 8-1
# mv httpd.pem /etc/httpd/ //將證書存放在httpd目錄下；
# yum install mod_ssl -y //爲Web服務添加openssl功能；
# cd conf.d/
# vim ssl.conf
SSLCertificateFile /etc/httpd/httpd.pem // 指定證書位置；
SSLCertificateKeyFile /etc/httpd/httpd.pem //指定密鑰位置；
重啓httpd 服務。
# vim /etc/hosts //修改IP地址到主機名的映射；
192.168.110.2 web1.a.com web1
Real Server 2 證書的配置過程同Real Server 1過程一樣，在此不再贅述，證書內容如圖8-2所示：
# make -C /etc/pki/tls/certs httpd.pem
圖 8-2
# vim /etc/hosts // 修改IP地址到主機名稱的映射；
192.168.110.3 web2.a.com web2
Director：
爲客戶端對http（80）服務、https（443）服務的訪問打上標記5：
# iptables -t mangle -A PREROUTING -d 192.168.110.1 -p tcp --dport 80 -j MARK --set-mark 5
# iptables -t mangle -A PREROUTING -d 192.168.110.1 -p tcp --dport 443 -j MARK --set-mark 5
# ipvsadm -A -f 5 -s wlc -p //定義服務；
# ipvsadm -a -f 5 -r 192.168.10.2 -m -w 2 //添加Real Server；
# ipvsadm -a -f 5 -r 192.168.10.3 -m -w 5 // 添加Real Server；
# ipvsadm -Ln
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
FWM 5 wlc persistent 3600
-> 192.168.110.3:0 Masq 5 0 23
-> 192.168.110.2:0 Masq 2 0 0
使用Windows客戶端訪問的時候要修改C:\WINDOWS\system32\drivers\etc\hosts 文件，添加兩條名稱解析記錄：
192.168.110.1 web1.a.com
192.168.110.1 web2.a.com
使其能夠解析192.168.0.127所對應的主機名。
此時客戶端無論是 訪問192.168.110.1的http服務還是https 服務都會被定義到同一臺Real Server上去。
4、FTP Connections
衆所周知FTP在被動模式下，所使用的數據傳輸的端口不是固定的，這就使我們在定義持久性時無法爲其打上標籤。此時我們可以指定一個範圍，將範圍內的端口打上標記，然後使VSFTPD在被動模式下不再使用隨機端口，而是使用範圍內的隨機端口，從而實現FTP的負載均衡。具體實現如下：
修改vsftpd的主配置文件定義在被動模式下使用的端口的範圍：
vim /etc/vsftpd.conf:
pasv_min_port=10000
pasv_max_port=20000
必須保證在LVS-NAT集羣模式下，服務端返回給客戶端的數據包的源地址爲VIP，而不是Real Server 的RIP,在vsftpd的主配置文件中添加一行：
vim /etc/vsftpd.conf
pasv_address=VIP
在Director上使用iptables定義端口：
iptables -t mangle -A PREROUTING -p tcp -d VIP --dport 21 -j MARK --set-mark 21
iptables -t mangle -A PREROUTING -p tcp -d VIP --dport 10000:20000 -j MARK --set-mark 21
好嘞，LB的東東小編算是給講完啦，不知讀者你收到多少啦，LB羣集能很好的實現各種應用的負載均衡啦，非常的實用，可是讀者還要考慮一個問題，萬一前端的Director死掉啦咋辦啦，還記得HA吧，呵呵，把HA羣集的關鍵業務設置成處理Director，不就解決了麼，這就是HA+LB的羣集架構啦，讀者可以去自己動手先做一做，小編會在之後的博客中附上HA+LB+NAS的實現啦，敬請關注哈