一、集羣cluster
當後端服務器承受不住訪問的壓力，提高服務器性能的解決方案會極大增加成本時，人們提出了橫向擴展的解決方案。增加一臺或幾臺服務器，提供相同的服務，通過前段分發器將訪問量均勻的分配到後臺服務器上。這種多臺服務器組成的數組集合就叫做集羣。
集羣按功能劃分有三種模型：
負載均衡集羣 LB（loadBalance）
高可用性集羣 HA（High Availability）
高性能集羣 HP（High Performance）
二、負載均衡集羣
根據某種算法將負載壓力合理的分配到集羣中的每一臺計算機上，以減輕主服務器的壓力。
負載均衡實現的方式一般有三種：
通過DNS輪詢進行負載均衡
通過反向代理進行負載均衡
通過網絡地址轉換（NAT）進行負載均衡
下面我要說的linux virtual server就是通過NAT技術進行負載均衡的
三、Linux Virtual Server （linux虛擬服務）
負載均衡的實現可以使用硬件如著名的F5設備，也可以使用軟件如：LVS、NGINX反向代理，畢竟硬件是要花錢的，軟件是開源免費的，你懂的。
lvs是國內章文嵩教授牽頭開發的開源項目，現在已經被收到linux2.6以上的內核版本中，不需要對系統打補丁就可以輕鬆實現。lvs工作於IOS七層模型的傳輸層，通過對TCP、UDP、SCTP、IPsec ESP、AH這些工作在四層的協議的支持，根據目標地址和端口做出轉發與否的決策，根據調度算法做出轉發至哪一個端口的決策。
LVS將其控制程序ipvs嵌套至傳輸層數據流的Input鉤子函數上，ipvs將發送至本控制器主機（director）上的數據流在input鏈上進行截流，通過對數據報文的分析根據自身的算法將數據流轉發至後臺真正提供服務的主機（Real Server）上，達到根據後端服務器負載能力均衡分配處理任務的效果。
lvs中的術語：
ClientIP：CIP------------------------客戶端ip
Dirvector Virtual IP：VIP------------控制器上對外開放的ip
Dirvector IP：DIP--------------------控制器上連接後臺服務器的ip
Realserver IP：RIP-------------------後臺服務器的ip
Director-----------------------------控制器或調度器
Real Server--------------------------後臺提供服務的主機
四、LVS的四種類型
1、NAT(net adress translation)
類似於DNAT，但支持多目標轉發。通過修改請求報文的目標地址爲根據調度算法所挑選出的某RS的RIP來進行轉發；
架構特性：
（1）RS應該使用私有地址，即RIP應該爲私有地址：各RS的網關必須指向DIP；
（2）請求和響應報文都經由director轉發：高負載場景中，dircetor可能成爲瓶頸；
（3）支持端口映射；
（4）RS可以使用任意OS；
（5）RS的RIP必須與director的DIP在同一網絡；
2、DR(direct route)
director在實現轉發時不修改請求的ip首部，而是通過直接封裝MAC首部完成轉發：目標MAC是Dircetor根據調度算法挑選出某RS的MAC地址，此類型中，RS也有同Director一樣的VIP。
架構特點：
（1）通過靜態綁定或內核參數修改或arptables規則實現只有Director上的VIP響應服務請求，RS上的VIP拒絕響應服務請求；
（2）RS上的RIP可以是私有地址，也可以是公網地址；
（3）請求報文必須經過Director調度，響應報文直接由RS通過VIP返回給用戶；
（4）各RIP必須與DIP在同一網絡中；
（5）不支持端口映射；
（6）RS可以使用大多數的OS；
（7）RS的網關一定不能指向Director；
3、TUN(Tunnel transmission)
隧道傳輸ipip：不修改請求報文ip首部，而是通過ip隧道機制在原有的ip報文之外在封裝ip首部，經由互聯網把請求報文交給選定的rs；
架構特性:
（1）RIP,DIP,VIP都是公網地址；
（2）RS的網關不能，也不可能指向DIP；
（3）請求報文由Director分發，但響應報文直接由RS響應給Client；
（4）不支持端口映射；
（5）RS的OS必須得支持IP隧道，現在只有linux系統支持，windows，bsfdb等不支持；
4、FullNat（雙向轉換）
通過請求報文的源地址爲DIP，目標爲RIP來實現轉發：對於響應報文而言，修改源地址爲VIP，目標地址爲CIP來實現轉發：
架構特點：這是一種對nat模型的改進，是一個擴展，使得RS與Director可以處於不同網絡。
（1）RIP，DIP可以使用私有地址；
（2）RIP和DIP可以不再同一個網絡中，且RIP的網關未必需要指向DIP；
（3）支持端口映射；
（4）RS的OS可以使用任意類型；
（5）請求報文經由Director，響應報文也經由Director；
五、LVS的十種調度算法
四種靜態算法，不考慮後端服務器實際負載情況：
1、RR
根據規則依次論調,不考慮RS的性能。輪到誰就轉發給誰。
2、WRR
加權輪詢，加入了weight（權重），可以根據RS的性能爲其設置權重值，權重越大功能越強，但是不能發硬當前的服務器的運行的情況。
3、DH
目標地址hash，適用於前段是一個drector後端是幾個緩存服務器，當客戶端第一次訪問到的是RS1的時候，DH這種算法保證，在客戶端刷新後還是訪問的是RS1。
4、SH
源地址hash，用於保證響應的報文和請求的報文是同一個路徑。
六種動態算法，考慮後端服務器當前負載後再進行分配：
1、LC
least connection，當一個用戶請求過來的時候，就計算下哪臺RS的鏈接誰最小，那麼這臺RS就獲得了下次響應客戶端請求的機會，計算的方法Overhead=active*256+inactive,如果兩者的結果是相同的則從LVS中的規則依次往下選擇RS。這種算法也是不考慮服務器的性能的。
2、WLC
這個就是加了權重的LC，考慮了RS的性能，即是性能好的就給的權重值大一些，不好的給的權重值小一些。缺點就是如果Overhead相同，則會按規則表中的順序，由上而下選擇RS，Overhead=(active*256+inactive)/weight
3、SED
就是對WLC的情況的補充，Overhead=(active+1)*256/weight，加一，就是爲了讓其能夠比較出大小。
4、NQ
never queue 基本和SED相同，避免了SED當中的性能差的服務器長時間被空閒的弊端，它是第一個請求給性能好的服務器，第二個請求一定是給的空閒服務器不論它的性能的好與壞。以後還是會把請求給性能好的服務器
5、LBLC
它就是動態DH和LC的組合，適用於cache羣，對於從來沒有來過的那些新的請求會分給當前連接數較少的那臺服務器。
6、LBLCR
帶有複製功能的LBLC，它的適用場景這裏舉例說明一下，比如說現在又RS1和RS2,第一次訪問RS1的5個請求第二次又來了，理所應到Director將會將其交給RS1，而此時在RS2是非常閒的，所以此時最好的處理方法就是可以將後來的這5個請求分別交給RS1和RS2，所以此時就需要把客戶端第一次請求的資源複製下來。（特殊情況）
六、ipvsadm使用說明
1、編譯安裝或yum源安裝
下載：http://www.linuxvirtualserver.org/software/
注意對應自己的內核版本
ipvsadm-1.24.tar.gz
tar zxvf ipvsadm-1.24.tar.gz
cd ipvsadm-1.24
make
make install
2、添加一個集羣服務director
ipvsadm -A|E -t|u|f service-address [-s scheduler]
-A:添加
-E：修改
-t：tcp
-u：udp
-f：打防火牆標記的tcp或udp
-D：刪除
-s：指定調度算法
3、給一個集羣服務添加一條RS規則
ipvsadm -a|e -t|u|f service-address -r server-adddress [-g|-i|-m] [-w wegiht]
-a:添加
-e：修改
-d：刪除
-g：dr模式直接路由gatway
-i：ipip，tun隧道
-m：NAT模式，地址轉換
# ipvsadm -D -t 172.16.13.10:80
# ipvsadm -d -t 172.16.13.10:80 -r 192.168.13.13:8080
# ipvsadm -C //清空所有羣集服務的定義
4、 查看規則：
ipvsadm -L -n -c --stats
-c:列出當前所有的connection
--stats：列出統計數據
--rate：速率數據
5、保存規則：default save to /etc/sysconfig/ipvsadm
# service ipvsadm save
# ipvsadm -S >/path/to/file
# ipvsadm-save >/path/to/file
6、重載規則：
# service ipvsadm restart
# ipvsadm -R < /path/from/file
# ipvsadm-restore < /path/from/file
7、清空所有已匹配的計數器
ipvsadm -Z [-t|u|f service-address]
文章出自http://wuhf2015.blog.51cto.com/8213008/1654648