十五周二次课
18.6 負載均衡集群介紹
- 主流開源軟件LVS、keepalived、haproxy、nginx等
- 其中LVS屬于4層（網(wǎng)絡OSI 7層模型），nginx屬于7層，haproxy既可以認為是4層，也可以當做7層使用
- keepalived的負載均衡功能其實就是lvs
- lvs這種4層的負載均衡是可以分發(fā)TCP協(xié)議，web服務是80端口，除了分發(fā)80端口，還有其他的端口通信的，比如MySQL的負載均衡，就可以用LVS實現(xiàn)，而nginx僅僅支持http，https，mail，haproxy；haproxy也支持MySQL這種TCP負載均衡的
- 相比較來說，LVS這種4層的更穩(wěn)定，能承受更多的請求，承載的并發(fā)量更高，而nginx這種7層的更加靈活，能實現(xiàn)更多的個性化需求
18.7 LVS介紹
- LVS是由國人章文嵩開發(fā)
- 流行度不亞于apache的httpd，基于TCP/IP做的路由和轉(zhuǎn)發(fā)，穩(wěn)定性和效率很高
- LVS最新版本基于Linux內(nèi)核2.6，有好多年不更新了
- LVS有三種常見的模式：NAT、DR、IP Tunnel
- LVS架構(gòu)中有一個核心角色叫做分發(fā)器（Load balance），它用來分發(fā)用戶的請求，還有諸多處理用戶請求的服務器（Real Server，簡稱rs）
LVS NAT模式
- 借助iptables的nat表來實現(xiàn)
- 用戶的請求到分發(fā)器后，通過預設的iptables規(guī)則，把請求的數(shù)據(jù)包轉(zhuǎn)發(fā)到后端的rs上去
- rs需要設定網(wǎng)關(guān)為分發(fā)器的內(nèi)網(wǎng)ip
- 用戶請求的數(shù)據(jù)包和返回給用戶的數(shù)據(jù)包全部經(jīng)過分發(fā)器，所以分發(fā)器成為瓶頸
- 在nat模式中，只需要分發(fā)器有公網(wǎng)ip即可，所以比較節(jié)省公網(wǎng)ip資源
LVS IP Tunnel模式
- 這種模式，需要有一個公共的IP配置在分發(fā)器和所有rs上，我們把它叫做vip
- 客戶端請求的目標IP為vip，分發(fā)器接收到請求數(shù)據(jù)包后，會對數(shù)據(jù)包做一個加工，會把目標IP改為rs的IP，這樣數(shù)據(jù)包就到了rs上
- rs接收數(shù)據(jù)包后，會還原原始數(shù)據(jù)包，這樣目標IP為vip，因為所有rs上配置了這個vip，所以它會認為是它自己
LVS DR模式
- 這種模式，也需要有一個公共的IP配置在分發(fā)器和所有rs上，也就是vip
- 和IP Tunnel不同的是，它會把數(shù)據(jù)包的MAC地址修改為rs的MAC地址
- rs接收數(shù)據(jù)包后，會還原原始數(shù)據(jù)包，這樣目標IP為vip，因為所有rs上配置了這個vip，所以它會認為是它自己
LVS調(diào)度算法
- 輪詢 Round-Robin rr
- 加權(quán)輪詢 Weight Round-Robin wrr
- 最小連接 Least-Connection lc
- 加權(quán)最小連接 Weight Least-Connection wlc
- 基于局部性的最小連接 Locality-Based Least Connections lblc
- 帶復制的基于局部性最小連接 Locality-Based Least Connections with Replication lblcr
- 目標地址散列調(diào)度 Destination Hashing dh
- 源地址散列調(diào)度 Source Hashing sh
常用的算法是前四種
18.9/18.10 LVS NAT模式搭建
| 分發(fā)器，可以叫調(diào)度器（簡寫為dir） | 192.168.0.220 | 172.16.22.220 |
| rs1 | 192.168.0.221，網(wǎng)關(guān)192.168.0.220 | |
| rs2 | 192.168.0.222，網(wǎng)關(guān)192.168.0.220 |
開啟遠程ssh反向連接
目的是為了遠程管理rs1,rs2
dr操作：
vim /etc/ssh/sshd_config#取消注釋
GatewayPorts yes service sshd restartrs1,rs2操作：
ssh -ngfNTR 1122:192.168.0.221:22 root@172.16.22.220 -o ServerAliveInterval=300 ssh -ngfNTR 1222:192.168.0.222:22 root@172.16.22.220 -o ServerAliveInterval=300 [root@test221 ~]# w20:38:21 up 11 days, 18 min, 1 user, load average: 0.00, 0.01, 0.05 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root pts/1 gateway 12:07 5.00s 0.05s 0.05s -bash [root@test221 ~]# netstat -antp | grep sshd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 27731/sshd tcp 0 0 192.168.0.221:22 192.168.0.220:60408 ESTABLISHED 32072/sshd: root@pt tcp6 0 0 :::22 :::* LISTEN 27731/sshd [root@test222 ~]# w20:37:34 up 9 days, 23:42, 1 user, load average: 0.00, 0.01, 0.05 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root pts/2 gateway 12:18 6.00s 0.02s 0.02s -bash [root@test222 ~]# netstat -antp | grep sshd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1113/sshd tcp 0 0 192.168.0.222:22 192.168.0.220:52484 ESTABLISHED 32179/sshd: root@pt tcp6 0 0 :::22 :::* LISTEN 1113/sshd開啟防火墻nat轉(zhuǎn)發(fā)
dr:
[root@test220 ~]# firewall-cmd --permanent --direct --passthrough ipv4 -t nat POSTROUTING -o eth0 -j MASQUERADE -s 192.168.0.0/24 [root@test220 ~]# firewall-cmd --reload啟動網(wǎng)卡間核心轉(zhuǎn)發(fā)功能
[root@test220 ~]# sysctl -w net.ipv4.ip_forward=1net.ipv4.ip_forward = 1 [root@test220 ~]# cat /proc/sys/net/ipv4/ip_forward #驗證是否打開1安裝ipvsadm組件
yum install -y ipvsadmwlc算法：
#創(chuàng)建腳本，內(nèi)容如下：
[root@test220 ~]# cat /usr/local/sbin/lvs_nat.sh #!/bin/bash #director 服務器上開啟路由轉(zhuǎn)發(fā)功能，可省略 echo 1 > /proc/sys/net/ipv4/ip_forward #關(guān)閉icmp的重定向 echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects #注意區(qū)分網(wǎng)卡名字 echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects #director 設置nat防火墻，使用iptables時有效，使用firewall-cmd使用上面的#firewall-cmd腳本 iptables -t nat -F iptables -t nat -X iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE #director設置ipvsadm IPVSADM='/usr/sbin/ipvsadm' $IPVSADM -C $IPVSADM -A -t 172.16.22.220:80 -s wlc -p 3 $IPVSADM -a -t 172.16.22.220:80 -r 192.168.0.221:80 -m -w 1 $IPVSADM -a -t 172.16.22.220:80 -r 192.168.0.222:80 -m -w 1 $IPVSADM -L -n測試
使用curl -I http://172.16.22.220測試
rr算法
定義ipvsadm負載均衡集群規(guī)則，并查看
此處定義DIP是以-s指定為rr算法進行輪詢調(diào)度，-m指定模式為lvs-nat，配置命令如下：
wrr算法
[root@test220 ~]# cat !$ cat /usr/local/sbin/lvs_nat_wrr.sh IPVSADM='/usr/sbin/ipvsadm' $IPVSADM -C $IPVSADM -A -t 172.16.22.220:80 -s wrr $IPVSADM -a -t 172.16.22.220:80 -r 192.168.0.221:80 -m -w 1 $IPVSADM -a -t 172.16.22.220:80 -r 192.168.0.222:80 -m -w 3 $IPVSADM -L -n測試~ Aiker$ curl -I 172.16.22.220 HTTP/1.1 200 OK Server: nginx Date: Wed, 28 Mar 2018 13:34:47 GMT Content-Type: text/html Content-Length: 1326 Last-Modified: Wed, 26 Apr 2017 08:03:46 GMT Connection: keep-alive Vary: Accept-Encoding ETag: "59005462-52e" Accept-Ranges: bytes~ Aiker$ curl -I 172.16.22.220 HTTP/1.1 200 OK Server: nginx Date: Wed, 28 Mar 2018 13:34:48 GMT Content-Type: text/html Content-Length: 1326 Last-Modified: Wed, 26 Apr 2017 08:03:46 GMT Connection: keep-alive Vary: Accept-Encoding ETag: "59005462-52e" Accept-Ranges: bytes~ Aiker$ curl -I 172.16.22.220 HTTP/1.1 200 OK Server: nginx Date: Wed, 28 Mar 2018 13:34:50 GMT Content-Type: text/html Content-Length: 1326 Last-Modified: Wed, 26 Apr 2017 08:03:46 GMT Connection: keep-alive Vary: Accept-Encoding ETag: "59005462-52e" Accept-Ranges: bytes~ Aiker$ curl -I 172.16.22.220 HTTP/1.1 301 Moved Permanently Server: nginx Date: Wed, 28 Mar 2018 13:34:52 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive X-Powered-By: PHP/5.6.34 location: forum.php~ Aiker$ curl -I 172.16.22.220 HTTP/1.1 200 OK Server: nginx Date: Wed, 28 Mar 2018 13:35:04 GMT Content-Type: text/html Content-Length: 1326 Last-Modified: Wed, 26 Apr 2017 08:03:46 GMT Connection: keep-alive Vary: Accept-Encoding ETag: "59005462-52e" Accept-Ranges: bytes擴展
lvs 三種模式詳解
一、集群簡介
什么是集群
計算機集群簡稱集群是一種計算機系統(tǒng)，它通過一組松散集成的計算機軟件和/或硬件連接起來高度緊密地協(xié)作完成計算工作。在某種意義上，他們可以被看作是一臺計算機。集群系統(tǒng)中的單個計算機通常稱為節(jié)點，通常通過局域網(wǎng)連接，但也有其它的可能連接方式。集群計算機通常用來改進單個計算機的計算速度和/或可靠性。一般情況下集群計算機比單個計算機，比如工作站或超級計算機性能價格比要高得多。
集群就是一組獨立的計算機，通過網(wǎng)絡連接組合成一個組合來共同完一個任務
LVS在企業(yè)架構(gòu)中的位置：
以上的架構(gòu)只是眾多企業(yè)里面的一種而已。綠色的線就是用戶訪問請求的數(shù)據(jù)流向。用戶-->LVS負載均衡服務器--->apahce服務器--->mysql服務器&memcache服務器&共享存儲服務器。并且我們的mysql、共享存儲也能夠使用LVS再進行負載均衡。
---------------小結(jié)-------------------------
集群：就是一組相互獨立的計算機，通過高速的網(wǎng)絡組成一個計算機系統(tǒng)，每個集群節(jié)點都是運行其自己進程的一個獨立服務器。對網(wǎng)絡用戶來講，網(wǎng)站后端就是一個單一的系統(tǒng)，協(xié)同起來向用戶提供系統(tǒng)資源，系統(tǒng)服務。
為什么要使用集群
集群的特點
1）高性能performance。一些需要很強的運算處理能力比如天氣預報，核試驗等。這就不是幾臺計算機能夠搞定的。這需要上千臺一起來完成這個工作的。
2）價格有效性
通常一套系統(tǒng)集群架構(gòu)，只需要幾臺或數(shù)十臺服務器主機即可，與動則上百王的專用超級計算機具有更高的性價比。
3）可伸縮性
當服務器負載壓力增長的時候，系統(tǒng)能夠擴展來滿足需求，且不降低服務質(zhì)量。
4）高可用性
盡管部分硬件和軟件發(fā)生故障，整個系統(tǒng)的服務必須是7*24小時運行的。
集群的優(yōu)勢
1）透明性
如果一部分服務器宕機了業(yè)務不受影響，一般耦合度沒有那么高，依賴關(guān)系沒有那么高。比如NFS服務器宕機了其他就掛載不了了，這樣依賴性太強。
2）高性能
訪問量增加，能夠輕松擴展。
3）可管理性
整個系統(tǒng)可能在物理上很大，但很容易管理。
4）可編程性
在集群系統(tǒng)上，容易開發(fā)應用程序，門戶網(wǎng)站會要求這個。
集群分類及不同分類的特點
計算機集群架構(gòu)按照功能和結(jié)構(gòu)一般分成以下幾類：
1）負載均衡集群（Loadbalancingclusters）簡稱LBC
2）高可用性集群（High-availabilityclusters）簡稱HAC
3）高性能計算集群（High-perfomanceclusters）簡稱HPC
4）網(wǎng)格計算（Gridcomputing）
網(wǎng)絡上面一般認為是有三個，負載均衡和高可用集群式我們互聯(lián)網(wǎng)行業(yè)常用的集群架構(gòu)。
（1）負載均衡集群
負載均衡集群為企業(yè)提供了更為實用，性價比更高的系統(tǒng)架構(gòu)解決方案。負載均衡集群把很多客戶集中訪問的請求負載壓力可能盡可能平均的分攤到計算機集群中處理。客戶請求負載通常包括應用程度處理負載和網(wǎng)絡流量負載。這樣的系統(tǒng)非常適合向使用同一組應用程序為大量用戶提供服務。每個節(jié)點都可以承擔一定的訪問請求負載壓力，并且可以實現(xiàn)訪問請求在各節(jié)點之間動態(tài)分配，以實現(xiàn)負載均衡。
負載均衡運行時，一般通過一個或多個前端負載均衡器將客戶訪問請求分發(fā)到后端一組服務器上，從而達到整個系統(tǒng)的高性能和高可用性。這樣計算機集群有時也被稱為服務器群。一般高可用性集群和負載均衡集群會使用類似的技術(shù)，或同時具有高可用性與負載均衡的特點。
負載均衡集群的作用
1）分擔訪問流量（負載均衡）
2）保持業(yè)務的連續(xù)性（高可用）
（2）高可用性集群
一般是指當集群中的任意一個節(jié)點失效的情況下，節(jié)點上的所有任務自動轉(zhuǎn)移到其他正常的節(jié)點上，并且此過程不影響整個集群的運行，不影響業(yè)務的提供。
類似是集群中運行著兩個或兩個以上的一樣的節(jié)點，當某個主節(jié)點出現(xiàn)故障的時候，那么其他作為從 節(jié)點的節(jié)點就會接替主節(jié)點上面的任務。從節(jié)點可以接管主節(jié)點的資源（IP地址，架構(gòu)身份等），此時用戶不會發(fā)現(xiàn)提供服務的對象從主節(jié)點轉(zhuǎn)移到從節(jié)點。
高可用性集群的作用：當一個機器宕機另一臺進行接管。比較常用的高可用集群開源軟件有：keepalive，heardbeat。
（3）高性能計算集群
高性能計算集群采用將計算任務分配到集群的不同計算節(jié)點兒提高計算能力，因而主要應用在科學計算領(lǐng)域。比較流行的HPC采用Linux操作系統(tǒng)和其它一些免費軟件來完成并行運算。這一集群配置通常被稱為Beowulf集群。這類集群通常運行特定的程序以發(fā)揮HPCcluster的并行能力。這類程序一般應用特定的運行庫, 比如專為科學計算設計的MPI庫。
HPC集群特別適合于在計算中各計算節(jié)點之間發(fā)生大量數(shù)據(jù)通訊的計算作業(yè)，比如一個節(jié)點的中間結(jié)果或影響到其它節(jié)點計算結(jié)果的情況。
常用集群軟硬件
常用開源集群軟件有：lvs，keepalived，haproxy，nginx，apache，heartbeat
常用商業(yè)集群硬件有：F5,Netscaler，Radware，A10等
二、LVS負載均衡集群介紹
負載均衡集群的作用：提供一種廉價、有效、透明的方法，來擴展網(wǎng)絡設備和服務器的負載帶寬、增加吞吐量，加強網(wǎng)絡數(shù)據(jù)處理能力、提高網(wǎng)絡的靈活性和可用性。
1）把單臺計算機無法承受的大規(guī)模的并發(fā)訪問或數(shù)據(jù)流量分擔到多臺節(jié)點設備上分別處理，減少用戶等待響應的時間，提升用戶體驗。
2）單個重負載的運算分擔到多臺節(jié)點設備上做并行處理，每個節(jié)點設備處理結(jié)束后，將結(jié)果匯總，返回給用戶，系統(tǒng)處理能力得到大幅度提高。
3）7*24小時的服務保證，任意一個或多個設備節(jié)點設備宕機，不能影響到業(yè)務。在負載均衡集群中，所有計算機節(jié)點都應該提供相同的服務，集群負載均衡獲取所有對該服務的如站請求。
LVS介紹
LVS是linux virtual server的簡寫linux虛擬服務器，是一個虛擬的服務器集群系統(tǒng)，可以再unix/linux平臺下實現(xiàn)負載均衡集群功能。該項目在1998年5月由章文嵩博士組織成立。
以下是LVS官網(wǎng)提供的4篇文章：（非常詳細，我覺得有興趣還是看官方文檔比較正宗吧！！）
http://www.linuxvirtualserver.org/zh/lvs1.html
http://www.linuxvirtualserver.org/zh/lvs2.html
http://www.linuxvirtualserver.org/zh/lvs3.html
http://www.linuxvirtualserver.org/zh/lvs4.html
IPVS發(fā)展史
早在2.2內(nèi)核時，IPVS就已經(jīng)以內(nèi)核補丁的形式出現(xiàn)。
從2.4.23版本開始ipvs軟件就是合并到linux內(nèi)核的常用版本的內(nèi)核補丁的集合。
從2.4.24以后IPVS已經(jīng)成為linux官方標準內(nèi)核的一部分
從上圖可以看出lpvs是工作在內(nèi)核層，我們不能夠直接操作ipvs，vs負載均衡調(diào)度技術(shù)是在linux內(nèi)核中實現(xiàn)的。因此，被稱之為linux虛擬服務器。我們使用該軟件配置lvs的時候，不能直接配置內(nèi)核中的ipvs，而需要使用ipvs的管理工具ipvsadm進行管理。通過keepalived也可以管理LVS。
LVS體系結(jié)構(gòu)與工作原理簡單描述
LVS集群負載均衡器接受服務的所有入展客戶端的請求，然后根據(jù)調(diào)度算法決定哪個集群節(jié)點來處理回復客戶端的請求。
LVS虛擬服務器的體系如下圖所示，一組服務器通過高速的局域網(wǎng)或者地理分布的廣域網(wǎng)相互連接，在這組服務器之前有一個負載調(diào)度器（load balance）。負載調(diào)度器負責將客戶的請求調(diào)度到真實服務器上。這樣這組服務器集群的結(jié)構(gòu)對用戶來說就是透明的。客戶訪問集群系統(tǒng)就如只是訪問一臺高性能，高可用的服務器一樣。客戶程序不受服務器集群的影響，不做任何修改。
就比如說：我們?nèi)ワ埖瓿燥堻c菜，客戶只要跟服務員點菜就行。并不需要知道具體他們是怎么分配工作的，所以他們內(nèi)部對于我們來說是透明的。此時這個服務員就會按照一定的規(guī)則把他手上的活，分配到其他人員上去。這個服務員就是負載均衡器（LB）而后面這些真正做事的就是服務器集群。
底下是官網(wǎng)提供的結(jié)構(gòu)圖：
LVS的基本工作過程
客戶請發(fā)送向負載均衡服務器發(fā)送請求。負載均衡器接受客戶的請求，然后先是根據(jù)LVS的調(diào)度算法（8種）來決定要將這個請求發(fā)送給哪個節(jié)點服務器。然后依據(jù)自己的工作模式（3種）來看應該如何把這些客戶的請求如何發(fā)送給節(jié)點服務器，節(jié)點服務器又應該如何來把響應數(shù)據(jù)包發(fā)回給客戶端。
恩，那這樣我們就只要接下來搞懂LVS的3中工作模式，8種調(diào)度算法就可以了。
LVS的三種工作模式：
1）VS/NAT模式（Network address translation）
2）VS/TUN模式（tunneling）
3）DR模式（Direct routing）
1、NAT模式-網(wǎng)絡地址轉(zhuǎn)換
Virtualserver via Network address translation(VS/NAT)
這個是通過網(wǎng)絡地址轉(zhuǎn)換的方法來實現(xiàn)調(diào)度的。首先調(diào)度器(LB)接收到客戶的請求數(shù)據(jù)包時（請求的目的IP為VIP），根據(jù)調(diào)度算法決定將請求發(fā)送給哪個后端的真實服務器（RS）。然后調(diào)度就把客戶端發(fā)送的請求數(shù)據(jù)包的目標IP地址及端口改成后端真實服務器的IP地址（RIP）,這樣真實服務器（RS）就能夠接收到客戶的請求數(shù)據(jù)包了。真實服務器響應完請求后，查看默認路由（NAT模式下我們需要把RS的默認路由設置為LB服務器。）把響應后的數(shù)據(jù)包發(fā)送給LB,LB再接收到響應包后，把包的源地址改成虛擬地址（VIP）然后發(fā)送回給客戶端。
調(diào)度過程IP包詳細圖：
原理圖簡述：
1)客戶端請求數(shù)據(jù)，目標IP為VIP
2)請求數(shù)據(jù)到達LB服務器，LB根據(jù)調(diào)度算法將目的地址修改為RIP地址及對應端口（此RIP地址是根據(jù)調(diào)度算法得出的。）并在連接HASH表中記錄下這個連接。
3)數(shù)據(jù)包從LB服務器到達RS服務器webserver，然后webserver進行響應。Webserver的網(wǎng)關(guān)必須是LB，然后將數(shù)據(jù)返回給LB服務器。
4)收到RS的返回后的數(shù)據(jù)，根據(jù)連接HASH表修改源地址VIP&目標地址CIP，及對應端口80.然后數(shù)據(jù)就從LB出發(fā)到達客戶端。
5)客戶端收到的就只能看到VIP\DIP信息。
NAT模式優(yōu)缺點：
1、NAT技術(shù)將請求的報文和響應的報文都需要通過LB進行地址改寫，因此網(wǎng)站訪問量比較大的時候LB負載均衡調(diào)度器有比較大的瓶頸，一般要求最多之能10-20臺節(jié)點
2、只需要在LB上配置一個公網(wǎng)IP地址就可以了。
3、每臺內(nèi)部的節(jié)點服務器的網(wǎng)關(guān)地址必須是調(diào)度器LB的內(nèi)網(wǎng)地址。
4、NAT模式支持對IP地址和端口進行轉(zhuǎn)換。即用戶請求的端口和真實服務器的端口可以不一致。
2、TUN模式
virtual server via ip tunneling模式:采用NAT模式時，由于請求和響應的報文必須通過調(diào)度器地址重寫，當客戶請求越來越多時，調(diào)度器處理能力將成為瓶頸。為了解決這個問題，調(diào)度器把請求的報文通過IP隧道轉(zhuǎn)發(fā)到真實的服務器。真實的服務器將響應處理后的數(shù)據(jù)直接返回給客戶端。這樣調(diào)度器就只處理請求入站報文，由于一般網(wǎng)絡服務應答數(shù)據(jù)比請求報文大很多，采用VS/TUN模式后，集群系統(tǒng)的最大吞吐量可以提高10倍。
VS/TUN的工作流程圖如下所示，它和NAT模式不同的是，它在LB和RS之間的傳輸不用改寫IP地址。而是把客戶請求包封裝在一個IP tunnel里面，然后發(fā)送給RS節(jié)點服務器，節(jié)點服務器接收到之后解開IP tunnel后，進行響應處理。并且直接把包通過自己的外網(wǎng)地址發(fā)送給客戶不用經(jīng)過LB服務器。
Tunnel原理流程圖:
原理圖過程簡述：
1）客戶請求數(shù)據(jù)包，目標地址VIP發(fā)送到LB上。
2）LB接收到客戶請求包，進行IP Tunnel封裝。即在原有的包頭加上IP Tunnel的包頭。然后發(fā)送出去。
3）RS節(jié)點服務器根據(jù)IP Tunnel包頭信息（此時就又一種邏輯上的隱形隧道，只有LB和RS之間懂）收到請求包，然后解開IP Tunnel包頭信息，得到客戶的請求包并進行響應處理。
4）響應處理完畢之后，RS服務器使用自己的出公網(wǎng)的線路，將這個響應數(shù)據(jù)包發(fā)送給客戶端。源IP地址還是VIP地址。（RS節(jié)點服務器需要在本地回環(huán)接口配置VIP，后續(xù)會講）
3、DR模式（直接路由模式）
Virtual server via direct routing (vs/dr)
DR模式是通過改寫請求報文的目標MAC地址，將請求發(fā)給真實服務器的，而真實服務器響應后的處理結(jié)果直接返回給客戶端用戶。同TUN模式一樣，DR模式可以極大的提高集群系統(tǒng)的伸縮性。而且DR模式?jīng)]有IP隧道的開銷，對集群中的真實服務器也沒有必要必須支持IP隧道協(xié)議的要求。但是要求調(diào)度器LB與真實服務器RS都有一塊網(wǎng)卡連接到同一物理網(wǎng)段上，必須在同一個局域網(wǎng)環(huán)境。
DR模式是互聯(lián)網(wǎng)使用比較多的一種模式。
DR模式原理圖：
DR模式原理過程簡述：
VS/DR模式的工作流程圖如上圖所示，它的連接調(diào)度和管理與NAT和TUN中的一樣，它的報文轉(zhuǎn)發(fā)方法和前兩種不同。DR模式將報文直接路由給目標真實服務器。在DR模式中，調(diào)度器根據(jù)各個真實服務器的負載情況，連接數(shù)多少等，動態(tài)地選擇一臺服務器，不修改目標IP地址和目標端口，也不封裝IP報文，而是將請求報文的數(shù)據(jù)幀的目標MAC地址改為真實服務器的MAC地址。然后再將修改的數(shù)據(jù)幀在服務器組的局域網(wǎng)上發(fā)送。因為數(shù)據(jù)幀的MAC地址是真實服務器的MAC地址，并且又在同一個局域網(wǎng)。那么根據(jù)局域網(wǎng)的通訊原理，真實復位是一定能夠收到由LB發(fā)出的數(shù)據(jù)包。真實服務器接收到請求數(shù)據(jù)包的時候，解開IP包頭查看到的目標IP是VIP。_（此時只有自己的IP符合目標IP才會接收進來，所以我們需要在本地的回環(huán)借口上面配置VIP。另：由于網(wǎng)絡接口都會進行ARP廣播響應，但集群的其他機器都有這個VIP的lo接口，都響應就會沖突。所以我們需要把真實服務器的lo接口的ARP__響應關(guān)閉掉。）_然后真實服務器做成請求響應，之后根據(jù)自己的路由信息將這個響應數(shù)據(jù)包發(fā)送回給客戶，并且源IP地址還是VIP。
DR模式小結(jié)：
1、通過在調(diào)度器LB上修改數(shù)據(jù)包的目的MAC地址實現(xiàn)轉(zhuǎn)發(fā)。注意源地址仍然是CIP，目的地址仍然是VIP地址。
2、請求的報文經(jīng)過調(diào)度器，而RS響應處理后的報文無需經(jīng)過調(diào)度器LB，因此并發(fā)訪問量大時使用效率很高（和NAT模式比）
3、因為DR模式是通過MAC地址改寫機制實現(xiàn)轉(zhuǎn)發(fā)，因此所有RS節(jié)點和調(diào)度器LB只能在一個局域網(wǎng)里面
4、RS主機需要綁定VIP地址在LO接口上，并且需要配置ARP抑制。
5、RS節(jié)點的默認網(wǎng)關(guān)不需要配置成LB，而是直接配置為上級路由的網(wǎng)關(guān)，能讓RS直接出網(wǎng)就可以。
6、由于DR模式的調(diào)度器僅做MAC地址的改寫，所以調(diào)度器LB就不能改寫目標端口，那么RS服務器就得使用和VIP相同的端口提供服務。
官方三種負載均衡技術(shù)比較總結(jié)表：
工作模式
VS/NAT
VS/TUN
VS/DR
Real server
（節(jié)點服務器）
Config dr gw
Tunneling
Non-arp device/tie vip
Server Network
Private
LAN/WAN
LAN
Server number
（節(jié)點數(shù)量）
Low 10-20
High 100
High 100
Real server gateway
Load balance
Own router
Own router
優(yōu)點
地址和端口轉(zhuǎn)換
Wan環(huán)境加密數(shù)據(jù)
性能最高
缺點
效率低
需要隧道支持
不能跨域LAN
LVS調(diào)度算法
最好參考此文章：http://www.linuxvirtualserver.org/zh/lvs4.html
Lvs的調(diào)度算法決定了如何在集群節(jié)點之間分布工作負荷。當director調(diào)度器收到來自客戶端訪問VIP的上的集群服務的入站請求時，director調(diào)度器必須決定哪個集群節(jié)點應該處理請求。Director調(diào)度器用的調(diào)度方法基本分為兩類：
固定調(diào)度算法：rr，wrr，dh，sh
動態(tài)調(diào)度算法：wlc，lc，lblc，lblcr
算法
說明
rr
輪詢算法，它將請求依次分配給不同的rs節(jié)點，也就是RS節(jié)點中均攤分配。這種算法簡單，但只適合于RS節(jié)點處理性能差不多的情況
wrr
加權(quán)輪訓調(diào)度，它將依據(jù)不同RS的權(quán)值分配任務。權(quán)值較高的RS將優(yōu)先獲得任務，并且分配到的連接數(shù)將比權(quán)值低的RS更多。相同權(quán)值的RS得到相同數(shù)目的連接數(shù)。
Wlc
加權(quán)最小連接數(shù)調(diào)度，假設各臺RS的全職依次為Wi，當前tcp連接數(shù)依次為Ti，依次去Ti/Wi為最小的RS作為下一個分配的RS
Dh
目的地址哈希調(diào)度（destination hashing）以目的地址為關(guān)鍵字查找一個靜態(tài)hash表來獲得需要的RS
SH
源地址哈希調(diào)度（source hashing）以源地址為關(guān)鍵字查找一個靜態(tài)hash表來獲得需要的RS
Lc
最小連接數(shù)調(diào)度（least-connection）,IPVS表存儲了所有活動的連接。LB會比較將連接請求發(fā)送到當前連接最少的RS.
Lblc
基于地址的最小連接數(shù)調(diào)度（locality-based least-connection）：將來自同一個目的地址的請求分配給同一臺RS，此時這臺服務器是尚未滿負荷的。否則就將這個請求分配給連接數(shù)最小的RS，并以它作為下一次分配的首先考慮。
LVS調(diào)度算法的生產(chǎn)環(huán)境選型：
1、一般的網(wǎng)絡服務，如http，mail，mysql等常用的LVS調(diào)度算法為：
a.基本輪詢調(diào)度rr
b.加權(quán)最小連接調(diào)度wlc
c.加權(quán)輪詢調(diào)度wrc
2、基于局部性的最小連接lblc和帶復制的給予局部性最小連接lblcr主要適用于web cache和DB cache
3、源地址散列調(diào)度SH和目標地址散列調(diào)度DH可以結(jié)合使用在防火墻集群中，可以保證整個系統(tǒng)的出入口唯一。
實際適用中這些算法的適用范圍很多，工作中最好參考內(nèi)核中的連接調(diào)度算法的實現(xiàn)原理，然后根據(jù)具體的業(yè)務需求合理的選型。
-----------------后續(xù)自我小結(jié)--------------------------------------------------
基本上lvs的原理部分就到這里，個人還是覺得像要對LVS有一個比較全面的認識，還是需要去將官方文檔認真的看過一遍。主要部分還是在于3種工作方式和8種調(diào)度算法。以及實際工作種什么樣的生產(chǎn)環(huán)境適用哪種調(diào)度算法。
http://www.it165.net/admin/html/201401/2248.html
lvs幾種算法
LVS主要的調(diào)度算法
輪詢調(diào)度-加權(quán)輪詢調(diào)度-最小連接調(diào)度-加權(quán)最小連接調(diào)度-基于局部性的最少連接-
帶復制的基于局部性的最少連接-目標地址散列調(diào)度-源地址散列調(diào)度
1：輪詢算法(RR)就是按依次循環(huán)的方式將請求調(diào)度到不同的服務器上，該算法最大的特點就是實現(xiàn)簡單。輪詢算法假設所有的服務器處理請求的能力都是一樣的，調(diào)度器會將所有的請求平均分配給每個真實服務器
2：加權(quán)輪詢算法(WRR)主要是對輪詢算法的一種優(yōu)化與補充，LVS會考慮每臺服務器的性能，并給每臺服務器添加一個權(quán)值，如果服務器A的權(quán)值為1，服務器B的權(quán)值為2，則調(diào)度到服務器B的請求會是服務器A的兩倍。權(quán)值越高的服務器，處理的請求越多。
3：最小連接調(diào)度算法(LC)將把請求調(diào)度到連續(xù)數(shù)量最小的服務器上，
4：加權(quán)最小連接算法(WLC)則是給每臺服務器一個權(quán)值，調(diào)度器會盡可能保持服務器連接數(shù)量與權(quán)值之間的平衡
5：基于局部性的最少連接調(diào)度算法(lblc)是請求數(shù)據(jù)包的目標IP地址的一種調(diào)度算法，該算法先根據(jù)請求的目標IP地址尋找最近的該目標IP地址所有使用的服務器，如果這臺服務器依然可用，并且用能力處理該請求，調(diào)度器會盡量選擇相同的服務器，否則會繼續(xù)選擇其他可行的服務器。
6：帶復雜的基于局部性最少的連接算法(lblcr)激勵的不是一個目標IP與一臺服務器之間的連接記錄，他會維護一個目標IP到一組服務器之間的映射關(guān)系，防止單點服務器負責過高
7：目標地址散列調(diào)度算法(DH)也是根據(jù)目標IP地址通過散列函數(shù)將目標IP與服務器建立映射關(guān)系，出現(xiàn)服務器不可用或負載過高的情況下，發(fā)往該目標IP的請求會固定發(fā)給該服務器。
8：源地址散列調(diào)度算法(SH)與目標地址散列調(diào)度算法類似，但它是根據(jù)源地址散列算法進行靜態(tài)分配固定的服務器資源
http://www.aminglinux.com/bbs/thread-7407-1-1.html
關(guān)于arp_ignore和 arp_announce
先簡單的介紹下關(guān)于LVS負載均衡
LVS（Linux Virtual Server）Linux服務器集群系統(tǒng)
針對高可伸縮，高可用服務的需求，給予IP層和內(nèi)容請求分發(fā)的負載均衡調(diào)度解決方法，并在Linux的內(nèi)核中實現(xiàn)，將一組服務器構(gòu)成一個實現(xiàn)可伸縮，高可用網(wǎng)絡服務的虛擬服務器
負載均衡
1.大量的兵法訪問或數(shù)據(jù)流量分擔到多態(tài)節(jié)點設備分別處理，減少用戶的等待時間
2.單個重負載的運算分擔到多態(tài)節(jié)點設備上做并行處理，每個節(jié)點設備處理結(jié)束后，將結(jié)果匯總，返回給用戶
負載調(diào)度器
一組服務器通過高速的局域網(wǎng)或者地理分布的廣域網(wǎng)相互相連，在他們的前端有一個負載均衡調(diào)度器（Load Balancer），負載均衡調(diào)度器能無縫的將網(wǎng)絡請求調(diào)度到真實的服務器上，從而使得服務器集群的結(jié)構(gòu)對用戶是透明的，用戶通過訪問集群系統(tǒng)提供的網(wǎng)絡服務，就像訪問一臺高性能，高可用的服務器。
IP負載均衡技術(shù)（三種）
1.VS/NAT（網(wǎng)絡地址轉(zhuǎn)換）
通過網(wǎng)絡地址轉(zhuǎn)換，調(diào)度器重寫請求報文的目標地址，根據(jù)預設的調(diào)度算法，將請求分發(fā)給后端的真實服務器，真實服務器的響應報文通過調(diào)度器時，報文的源地址被重寫，再返回到客戶端，完成整個調(diào)度的過程
2.VS/TUN（IP隧道模式）
調(diào)度器將請求的報文通過IP隧道轉(zhuǎn)發(fā)至真實服務器，而真實的服務器直接將結(jié)果返回給用戶，調(diào)度器只處理請求報文，由于一般網(wǎng)路服務的應答大于請求，采用IP隧道模式，集群系統(tǒng)的最大吞吐量可以提高10倍。
3.VS/DR（直接路由）
通過改寫請求報文的MAC地址，將請求發(fā)送到真是服務器，真實服務器將響應直接返回給用戶，之際額路由模式可以極大的提高集群系統(tǒng)的伸縮性，這種方法沒有IP隧道的開銷，集群中真實的服務器也沒有必要必須支持IP隧道協(xié)議，只是需要調(diào)度器與真實服務器有一塊網(wǎng)卡連在同一物理網(wǎng)段上。
其中在這三種IP負載均衡的技術(shù)中，DR和TUN模式都需要在真實服務器上對arp_ignore和arp_announce參數(shù)進行配置，主要是實現(xiàn)禁止響應對VIP的ARP請求。
在lvs環(huán)境中，需要設定以下的參數(shù)
echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignoreecho "1" > /proc/sys/net/ipv4/conf/lo/arp_ignoreecho "2" > /proc/sys/net/ipv4/conf/lo/arp_announceecho "2" > /proc/sys/net/ipv4/conf/all/arp_announce先來看看關(guān)于arp_ignore和arp_announce的有關(guān)介紹
有關(guān)arp_ignore的相關(guān)介紹：
arp_ignore - INTEGER
Define different modes for sending replies in response to
received ARP requests that resolve local target IP addresses:
0 - (default): reply for any local target IP address, configured
on any interface
1 - reply only if the target IP address is local address
configured on the incoming interface
2 - reply only if the target IP address is local address
configured on the incoming interface and both with the
sender's IP address are part from same subnet on this interface
3 - do not reply for local addresses configured with scope host,
only resolutions for global and link addresses are replied
4-7 - reserved
8 - do not reply for all local addresses
arp_ignore:定義對目標地址為本地IP的ARP詢問不同的應答模式0
0 - (默認值): 回應任何網(wǎng)絡接口上對任何本地IP地址的arp查詢請求
1 - 只回答目標IP地址是來訪網(wǎng)絡接口本地地址的ARP查詢請求
2 -只回答目標IP地址是來訪網(wǎng)絡接口本地地址的ARP查詢請求,且來訪IP必須在該網(wǎng)絡接口的子網(wǎng)段內(nèi)
3 - 不回應該網(wǎng)絡界面的arp請求，而只對設置的唯一和連接地址做出回應
4-7 - 保留未使用
8 -不回應所有（本地地址）的arp查詢
有關(guān)arp_announce的相關(guān)介紹：
arp_announce - INTEGER
Define different restriction levels for announcing the local
source IP address from IP packets in ARP requests sent on
interface:
0 - (default) Use any local address, configured on any interface
1 - Try to avoid local addresses that are not in the target's
subnet for this interface. This mode is useful when target
hosts reachable via this interface require the source IP
address in ARP requests to be part of their logical network
configured on the receiving interface. When we generate the
request we will check all our subnets that include the
target IP and will preserve the source address if it is from
such subnet. If there is no such subnet we select source
address according to the rules for level 2.
2 - Always use the best local address for this target.
In this mode we ignore the source address in the IP packet
and try to select local address that we prefer for talks with
the target host. Such local address is selected by looking
for primary IP addresses on all our subnets on the outgoing
interface that include the target IP address. If no suitable
local address is found we select the first local address
we have on the outgoing interface or on all other interfaces,
with the hope we will receive reply for our request and
even sometimes no matter the source IP address we announce.
arp_announce:對網(wǎng)絡接口上，本地IP地址的發(fā)出的，ARP回應，作出相應級別的限制: 確定不同程度的限制,宣布對來自本地源IP地址發(fā)出Arp請求的接口
0 - (默認) 在任意網(wǎng)絡接口（eth0,eth1，lo）上的任何本地地址
1 -盡量避免不在該網(wǎng)絡接口子網(wǎng)段的本地地址做出arp回應. 當發(fā)起ARP請求的源IP地址是被設置應該經(jīng)由路由達到此網(wǎng)絡接口的時候很有用.此時會檢查來訪IP是否為所有接口上的子網(wǎng)段內(nèi)ip之一.如果改來訪IP不屬于各個網(wǎng)絡接口上的子網(wǎng)段內(nèi),那么將采用級別2的方式來進行處理.
2 - 對查詢目標使用最適當?shù)谋镜氐刂?在此模式下將忽略這個IP數(shù)據(jù)包的源地址并嘗試選擇與能與該地址通信的本地地址.首要是選擇所有的網(wǎng)絡接口的子網(wǎng)中外出訪問子網(wǎng)中包含該目標IP地址的本地地址. 如果沒有合適的地址被發(fā)現(xiàn),將選擇當前的發(fā)送網(wǎng)絡接口或其他的有可能接受到該ARP回應的網(wǎng)絡接口來進行發(fā)送.
關(guān)于對arp_announce 理解的一點補充
Assume that a linux box X has three interfaces - eth0, eth1 and eth2. Each interface has an IP address IP0,
IP1 and IP2. When a local application tries to send an IP packet with IP0 through the eth2. Unfortunately,
the target node’s mac address is not resolved. Thelinux box X will send the ARP request to know
the mac address of the target(or the gateway). In this case what is the IP source address of the
“ARP request message”? The IP0- the IP source address of the transmitting IP or IP2 - the outgoing
interface? Until now(actually just 3 hours before) ARP request uses the IP address assigned to
the outgoing interface(IP2 in the above example) However the linux’s behavior is a little bit
different. Actually the selection of source address in ARP request is totally configurable
bythe proc variable “arp_announce”
If we want to use the IP2 not the IP0 in the ARP request, we should change the value to 1 or 2.
The default value is 0 - allow IP0 is used for ARP request.
其實就是路由器的問題，因為路由器一般是動態(tài)學習ARP包的（一般動態(tài)配置DHCP的話），當內(nèi)網(wǎng)的機器要發(fā)送一個到外部的ip包，那么它就會請求 路由器的Mac地址，發(fā)送一個arp請求，這個arp請求里面包括了自己的ip地址和Mac地址，而linux默認是使用ip的源ip地址作為arp里面 的源ip地址，而不是使用發(fā)送設備上面的 ，這樣在lvs這樣的架構(gòu)下，所有發(fā)送包都是同一個VIP地址，那么arp請求就會包括VIP地址和設備 Mac，而路由器收到這個arp請求就會更新自己的arp緩存，這樣就會造成ip欺騙了，VIP被搶奪，所以就會有問題。
arp緩存為什么會更新了，什么時候會更新呢，為了減少arp請求的次數(shù)，當主機接收到詢問自己的arp請求的時候，就會把源ip和源Mac放入自 己的arp表里面，方便接下來的通訊。如果收到不是詢問自己的包（arp是廣播的，所有人都收到），就會丟掉，這樣不會造成arp表里面無用數(shù)據(jù)太多導致 有用的記錄被刪除。
在設置參數(shù)的時候?qū)rp_ignore 設置為1，意味著當別人的arp請求過來的時候，如果接收的設備上面沒有這個ip，就不做出響應，默認是0，只要這臺機器上面任何一個設備上面有這個ip，就響應arp請求，并發(fā)送mac地址
其它的相關(guān)資料：
http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disable_ARP]
http://itnihao.blog.51cto.com/1741976/752472
http://www.cnblogs.com/lgfeng/archive/2012/10/16/2726308.html
lvs原理相關(guān)的
LVS簡介
Internet的快速增長使多媒體網(wǎng)絡服務器面對的訪問數(shù)量快速增加，服務器需要具備提供大量并發(fā)訪問服務的能力，因此對于大負載的服務器來講， CPU、I/O處理能力很快會成為瓶頸。由于單臺服務器的性能總是有限的，簡單的提高硬件性能并不能真正解決這個問題。為此，必須采用多服務器和負載均衡技術(shù)才能滿足大量并發(fā)訪問的需要。Linux 虛擬服務器(Linux Virtual Servers,LVS) 使用負載均衡技術(shù)將多臺服務器組成一個虛擬服務器。它為適應快速增長的網(wǎng)絡訪問需求提供了一個負載能力易于擴展，而價格低廉的解決方案。
LVS結(jié)構(gòu)與工作原理
一.LVS的結(jié)構(gòu)
LVS由前端的負載均衡器(Load Balancer，LB)和后端的真實服務器(Real Server，RS)群組成。RS間可通過局域網(wǎng)或廣域網(wǎng)連接。LVS的這種結(jié)構(gòu)對用戶是透明的，用戶只能看見一臺作為LB的虛擬服務器(Virtual Server)，而看不到提供服務的RS群。當用戶的請求發(fā)往虛擬服務器，LB根據(jù)設定的包轉(zhuǎn)發(fā)策略和負載均衡調(diào)度算法將用戶請求轉(zhuǎn)發(fā)給RS。RS再將用戶請求結(jié)果返回給用戶。
二.LVS內(nèi)核模型
1.當客戶端的請求到達負載均衡器的內(nèi)核空間時，首先會到達PREROUTING鏈。
2.當內(nèi)核發(fā)現(xiàn)請求數(shù)據(jù)包的目的地址是本機時，將數(shù)據(jù)包送往INPUT鏈。
3.LVS由用戶空間的ipvsadm和內(nèi)核空間的IPVS組成，ipvsadm用來定義規(guī)則，IPVS利用ipvsadm定義的規(guī)則工作，IPVS工作在INPUT鏈上,當數(shù)據(jù)包到達INPUT鏈時，首先會被IPVS檢查，如果數(shù)據(jù)包里面的目的地址及端口沒有在規(guī)則里面，那么這條數(shù)據(jù)包將被放行至用戶空間。
4.如果數(shù)據(jù)包里面的目的地址及端口在規(guī)則里面，那么這條數(shù)據(jù)報文將被修改目的地址為事先定義好的后端服務器，并送往POSTROUTING鏈。
5.最后經(jīng)由POSTROUTING鏈發(fā)往后端服務器。
三.LVS的包轉(zhuǎn)發(fā)模型
1.NAT模型：
①.客戶端將請求發(fā)往前端的負載均衡器，請求報文源地址是CIP(客戶端IP),后面統(tǒng)稱為CIP)，目標地址為VIP(負載均衡器前端地址，后面統(tǒng)稱為VIP)。
②.負載均衡器收到報文后，發(fā)現(xiàn)請求的是在規(guī)則里面存在的地址，那么它將客戶端請求報文的目標地址改為了后端服務器的RIP地址并將報文根據(jù)算法發(fā)送出去。
③.報文送到Real Server后，由于報文的目標地址是自己，所以會響應該請求，并將響應報文返還給LVS。
④.然后lvs將此報文的源地址修改為本機并發(fā)送給客戶端。注意：在NAT模式中，Real Server的網(wǎng)關(guān)必須指向LVS，否則報文無法送達客戶端。
2.DR模型：
①.客戶端將請求發(fā)往前端的負載均衡器，請求報文源地址是CIP，目標地址為VIP。
②.負載均衡器收到報文后，發(fā)現(xiàn)請求的是在規(guī)則里面存在的地址，那么它將客戶端請求報文的源MAC地址改為自己DIP的MAC地址，目標MAC改為了RIP的MAC地址，并將此包發(fā)送給RS。
③.RS發(fā)現(xiàn)請求報文中的目的MAC是自己，就會將次報文接收下來，處理完請求報文后，將響應報文通過lo接口送給eth0網(wǎng)卡直接發(fā)送給客戶端。注意：需要設置lo接口的VIP不能響應本地網(wǎng)絡內(nèi)的arp請求。
3.TUN模型：
①.客戶端將請求發(fā)往前端的負載均衡器，請求報文源地址是CIP，目標地址為VIP。
②.負載均衡器收到報文后，發(fā)現(xiàn)請求的是在規(guī)則里面存在的地址，那么它將在客戶端請求報文的首部再封裝一層IP報文,將源地址改為DIP，目標地址改為RIP,并將此包發(fā)送給RS。
③.RS收到請求報文后，會首先拆開第一層封裝,然后發(fā)現(xiàn)里面還有一層IP首部的目標地址是自己lo接口上的VIP，所以會處理次請求報文，并將響應報文通過lo接口送給eth0網(wǎng)卡直接發(fā)送給客戶端。注意：需要設置lo接口的VIP不能在共網(wǎng)上出現(xiàn)。
四.LVS的調(diào)度算法
LVS的調(diào)度算法分為靜態(tài)與動態(tài)兩類。
1.靜態(tài)算法（4種）：只根據(jù)算法進行調(diào)度 而不考慮后端服務器的實際連接情況和負載情況
①.RR：輪叫調(diào)度（Round Robin）
調(diào)度器通過”輪叫”調(diào)度算法將外部請求按順序輪流分配到集群中的真實服務器上，它均等地對待每一臺服務器，而不管服務器上實際的連接數(shù)和系統(tǒng)負載｡
②.WRR：加權(quán)輪叫（Weight RR）
調(diào)度器通過“加權(quán)輪叫”調(diào)度算法根據(jù)真實服務器的不同處理能力來調(diào)度訪問請求。這樣可以保證處理能力強的服務器處理更多的訪問流量。調(diào)度器可以自動問詢真實服務器的負載情況,并動態(tài)地調(diào)整其權(quán)值。
③.DH：目標地址散列調(diào)度（Destination Hash ）
根據(jù)請求的目標IP地址，作為散列鍵(HashKey)從靜態(tài)分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發(fā)送到該服務器，否則返回空。
④.SH：源地址 hash（Source Hash）
源地址散列”調(diào)度算法根據(jù)請求的源IP地址，作為散列鍵(HashKey)從靜態(tài)分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發(fā)送到該服務器，否則返回空｡
2.動態(tài)算法（6種）：前端的調(diào)度器會根據(jù)后端真實服務器的實際連接情況來分配請求
①.LC：最少鏈接（Least Connections）
調(diào)度器通過”最少連接”調(diào)度算法動態(tài)地將網(wǎng)絡請求調(diào)度到已建立的鏈接數(shù)最少的服務器上。如果集群系統(tǒng)的真實服務器具有相近的系統(tǒng)性能，采用”最小連接”調(diào)度算法可以較好地均衡負載。
②.WLC：加權(quán)最少連接(默認采用的就是這種)（Weighted Least Connections）
在集群系統(tǒng)中的服務器性能差異較大的情況下，調(diào)度器采用“加權(quán)最少鏈接”調(diào)度算法優(yōu)化負載均衡性能，具有較高權(quán)值的服務器將承受較大比例的活動連接負載｡調(diào)度器可以自動問詢真實服務器的負載情況,并動態(tài)地調(diào)整其權(quán)值。
③.SED：最短延遲調(diào)度（Shortest Expected Delay ）
在WLC基礎上改進，Overhead = （ACTIVE+1）*256/加權(quán)，不再考慮非活動狀態(tài)，把當前處于活動狀態(tài)的數(shù)目+1來實現(xiàn)，數(shù)目最小的，接受下次請求，+1的目的是為了考慮加權(quán)的時候，非活動連接過多缺陷：當權(quán)限過大的時候，會倒置空閑服務器一直處于無連接狀態(tài)。
④.NQ永不排隊/最少隊列調(diào)度（Never Queue Scheduling NQ）
無需隊列。如果有臺 realserver的連接數(shù)＝0就直接分配過去，不需要再進行sed運算，保證不會有一個主機很空間。在SED基礎上無論+幾，第二次一定給下一個，保證不會有一個主機不會很空閑著，不考慮非活動連接，才用NQ，SED要考慮活動狀態(tài)連接，對于DNS的UDP不需要考慮非活動連接，而httpd的處于保持狀態(tài)的服務就需要考慮非活動連接給服務器的壓力。
⑤.LBLC：基于局部性的最少鏈接（locality-Based Least Connections）
基于局部性的最少鏈接”調(diào)度算法是針對目標IP地址的負載均衡，目前主要用于Cache集群系統(tǒng)｡該算法根據(jù)請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發(fā)送到該服務器;若服務器不存在，或者該服務器超載且有服務器處于一半的工作負載，則用“最少鏈接”的原則選出一個可用的服務器，將請求發(fā)送到該服務器｡
⑥. LBLCR：帶復制的基于局部性最少連接（Locality-Based Least Connections with Replication）
帶復制的基于局部性最少鏈接”調(diào)度算法也是針對目標IP地址的負載均衡，目前主要用于Cache集群系統(tǒng)｡它與LBLC算法的不同之處是它要維護從一個目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射｡該算法根據(jù)請求的目標IP地址找出該目標IP地址對應的服務器組，按”最小連接”原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發(fā)送到該服務器；若服務器超載，則按“最小連接”原則從這個集群中選出一臺服務器，將該服務器加入到服務器組中，將請求發(fā)送到該服務器｡同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低復制的程度。
http://blog.csdn.net/pi9nc/article/details/23380589
轉(zhuǎn)載于:https://blog.51cto.com/235571/2135276
總結(jié)
- 上一篇： 域用户和计算机上解锁用户的账户,AD域账
- 下一篇： 进程和线程的剖析