個人的理解，以一種通俗易懂的方式講述出來，如果有哪些地方說的不正確的話，希望大家留言指出來。筆者會非是常的感謝！

Cluster服務器集群，直接理解為一些單一的服務器的集合通過某種方式組合起來，為客戶端提供服務。重要的是在外部看來它們僅僅是一個系統。

關于為什么要建立服務集群這個問題，這里可以用時下最火的淘寶交易平臺為例，淘寶網8月份的商品成交總額是1.2億人名幣，會員數量達到220萬，網頁瀏覽量為5000萬，這個還是2004年公布的保守數據，現在那就不好說了是吧，就說當是的這個網頁瀏覽量說5000萬的瀏覽量，如果是由單一的服務器提供服務，就是這個服務器的性能再好，面對如此高的訪問量，在響應客戶端的時候，你能想象嗎？這么多的請求都要讓它自己來處理，用不了多久，服務器就會累趴下吧！它一旦趴下（down機）你能想象嗎？元方你怎么看？

綜上總結服務器面臨三個問題：

　　　　　　　　　　1、 并發請求數量大，這就要求服務器容量要足夠大

　　　　　　　　　　2、 在線訪問量大，要求服務器不能中斷

　　　　　　　　　　3、 總體的訪問量龐大，禪理性能要足夠的強

?

面對這些問題我們以往采取的方式是Scale up:(向上擴展),即是將當前使用的服務器，用比它性能更好的服務器替換掉（新機替換掉老機）。服務器單一管理起來非常方便，但是,要知道換上的新機比老機提升了的性能和在這個新機上的花銷可不是成比增長的，并且還會造成對老機的浪費。所以就有了Scale out(向外擴展)即是以增加機器的方式來提升服務器的性能，這其實就是Cluster“集群”。

針對以上的三個問題，按服務集群的功能能將其分為三個類別： 1、負載均衡集群（LB,load Balance Cluster） 2、高可用集群（HA,High Available Cluster） 3、高性能集群（HP，High Performance Cluster） 負載均衡集群在Linux中的軟件實現方式：LVS 高可用集群在Linux中的軟件實現方式:heartbeat corosync 高性能集群在Linux中的軟件實現方式：hadoop 首先我們來說說下先負載均衡集群，通過硬件實現的方式，在硬件技術上傳到常用到的調度器有F5的BIG IP可處理的并發請求數量高達1000萬，IBM的A10并發請求數量可達600萬，Citrix，Netscaler可處理并發請求數量為500萬，都可以滿足我們的需求，但是都太貴了，而我們的軟件實現方式很好的彌補了這個缺憾哈！而其中最具代表性之一的解決方案即是淘寶的章文嵩博士創立的LVS。 -----------------------------------LVS框架圖-------------------------------------------

LVS（Linux Vitual Server）---虛擬服務器，在工作當中它是作為一個前段的Director（調度器）工作的，Director它本身不提供任何的服務，只是將接收到的請求轉發給后端的Real Seerver處理，然后在響應給客戶端。所以我們也稱LVS為“4 layer switch/route"。LVS本身的兩個基本的組件就是：ipvs和ipvsadm。而ipvs是一個工作在內核當中的,它其實就是相當于做成了netfilter框架的一個模塊。就像netfilter當中有filter表、net表、mangle表，而你現在又加入了Ipvs表，主要是用于讓定義好的規則生效，ipvsadm是工作在用戶空間，用來定義LVS的轉發規則。LVS是工作在INPUT鏈上的。 -------------------------------------轉發過程圖----------------------------------------

Director（調度器）即是負載均衡器，一個合格的Director要滿足以下的要求。 1、考慮服務器負載能力通過某種調度方法，調度后端服務器。 2、考慮后端服務器是否正常工作，這也是需要一種機制來完成，我們稱其為后端主機健康狀態測。 3、考慮Director本身如果出故障，整個服務癱瘓的問題。這里不得不用到高可用集群。即在添加一個Director. 4、為多臺的Real Server提供一個共享存儲。說到共享存儲就不得不說到DAS、NAS、SAN。 DAS：直接輔加存儲，即直接連接到主機總線上的存儲設備。優點在于存儲容量擴展方便，實施起來很簡單，但是這種方式太過于限制，它必須要和服務器在同一個機架上。 NAS：網絡輔加存儲，雙方共享文件服務器，只要連接到NAS上就可以實現共享存儲。并且Real Server同時寫入的時候不會崩潰，因為它是文件系統級別的，但是DNS最多只能同時為十臺服務器提供共享存儲。 SAN：存儲區域網絡， FC SAN光驅動 IP SAN（SSISC） 每個Real Sever都有RIP VIP? 每個Drector都有DIP VIP LVS有三種轉發模型：NAT模型 DR模型 TUN模型,其中DR模型應用最廣。 NAT模型：網絡地址轉換模型， NAT模型的特點： 1、Diretor和Real Server(RS)必須在同一個子網中。 2、RIP通常使用私有地址，僅限于本地通信 3、Director工作在Clients和RS中間，負責處理進出的全部報文 4、RS網關要指向DIP 5、可以實現端口轉換（映射） 6、RS可以是任何操作系統 7、Director可能成為性能瓶頸，所以不適用于教大規模的負載均衡場景 DR模型：直接路由模型 DR模型的特點： 1、RS跟Director必須在同一物理網上（即中間不能隔路由設備）。 2、RIP可以使用公網地址 3、Director僅處理請求報文 4、RS的網關不能指向DIP 5、不能使用端口映射 6、大多數操作系統可以用于RS 7、一般DR模型的Director能處理比NAT模型多的多的請求 DR模型詳解： CIP向VIP發出請求，CIP經由路由設備，到達局域網，它的目的是想和Director的VIP通信，但是它不知道VIP的MAC，在局域網內部通訊看的是MAC地址，所以它要發廣播，所有收到廣播包的都會回應此廣播，此時就會產生問題了，RS1、RS2也會回應因為他們也有同樣的VIP啊，那交換機怎么知道，哪個是Director的MAC呢？所以我們這里必須要控制RS1和RS2不回應此廣播包，這就不得不提到兩個內核參數，arp_ignor和arp_annouce，在RS1和RS2上均對這兩個參數給與定義，則RS1和RS2就不會回應由交換發出的這個找VIP的對應的MAC的廣播包了。此時數據包就可以到達Director了，Director通過某種調度方法計算發現RS1符合這個要求，所以它要把這個請求包交給RS1來處理，但是它也不知道RS1的MAC啊，所以它也要發起廣播消息，此時Director發起的廣播是在其內部發起的,每個RS的這個私有的地址都是不一樣的。所以當RS1收到這個廣播的時候發現時找它的，它就會回應，則此時Director就得到了RS1的MAC，它將請求報文的目標MAC地址換成RS1的MAC地址，然后在將這個請求包返回給交換機，此時交換機就認為這個請求是發給RS1的，它就會將其發給RS1,RS1收到請求包，直接用自己的VIP給予回應，不再經由Director.所以這就需要在RS1中定義一條路由"route add -host VIP dev lo:0"明確告知RS1，只要是請求VIP的，我就用lo:0這個上面的VIP來給予回應。 注意：1、RS和DR都是單網卡的哦，每個RS的VIP是設置在lo:0上的，這個lo:0是虛擬的哈。DR的VIP是在eth0:0上面配置的。 2、由DR發出的廣播包不被RS屏蔽掉的原因是因為它是廣播的RIP這是他們的私有網絡的地址，剛剛設置的參數arp_ignor和arp_annouce,只是針對VIP的哈

TUN模型：隧道模型 TUN模型的特點 1、RS跟Director不必在同一個物理網絡中 2、RIP一定不能使用私有地址 3、多數情況下Director僅處理請求報文 4、正常情況下響應報文不能經過Director 5、不能使用端口映射 6、僅允許支持隧道協議的操作系統用于RS ___________________________________________________________________ LVS的十種調度方法，分為靜態和動態兩類。 靜態四種；僅根據算法本身調度，不關心RS上當前的連接狀態。 1、RR 根據規則依次論調,不考慮RS的性能。輪到誰就轉發給誰。 2、WRR 加權輪詢，加入了weight（權重），可以根據RS的性能為其設置權重值，權重越大功能越強，但是不能發硬當前的服務器的運行的情況。 3、DH 目標地址hash，適用于前段是一個drector后端是幾個緩存服務器，當客戶端第一次訪問到的是RS1的時候，DH這種算法保證，在客戶端刷新后還是訪問的是RS1。 4、SH 源地址hash，用于保證響應的報文和請求的報文是同一個路徑。 動態六種：要將RS得連接狀態計入調度考量標準。 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，所以此時就需要把客戶端第一次請求的資源復制下來。（特殊情況） 活動鏈接active和非活動鏈接inactive小解： 這里以http為例，http本身是一種無狀態的鏈接，當客戶端請求訪問的時候，有個等待響應過程，這個時段可以稱其為活動鏈接active狀態.當服務器端給與響應后，請求因為keepalive而并未斷開，則此段時間的狀態就是非活動鏈接狀態。 無連接狀態即是無追蹤 cookie即是個標識用于追蹤用戶訪問過哪個資源，追蹤用戶的身份，這種單一的cookie是不安全的 session結合cookie或者url完成用戶跟蹤，客戶端的cookie只需要保留session id敏感信息保留在服務器端. 持久連接是靠director上的持久模板來完成的，模板上的條目用hash保存. 防火墻標記服務，將兩種服務標記成一種服務，用mangle給某數據報文一個標記MARK，但是不具有永久性，所以需要使用持久連接 LVS中的持久連接類型： PCC 來自同一個用戶端的所有的集群服務請求通通轉發給后端的某個特定的Real Server PPC 將某客戶端的特定的服務請求通過某種算法，轉發給后端的某個特定的Real Server PFWM 將兩種服務綁定，即這兩種服務都是通過后端所指定的某個Real Sever響應即是將多個PPC和并起來，但是并未達到PCC標準 -p定義持久連接超時時間的，默認是5分鐘 ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]] [-O] [-M netmask] ipvsadm -Ln --persistent-conn這是用于查看長連接的超時時常的 【管理集群服務】 1、增加集群服務 ipvsadm -A|E -t|u|f service-address [-s scheduler] -s sheduler 指定調度方法，如果不指定的話默認是WLC -t|u|f 分別表示tcp|udp|firemark 2、刪除集群服務 ipvsadm -D -t|u|f ?service-address 【管理集群服務中的RS】? 1、增加集群服務的RS ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m]? [-w weight]? a|e 其中a表示的是增加 e表示修改 [-g|i|m] -g表示DR模型(gatewaying) -i表示的TUN隧道模型（ipip） m表示的是nat模型(masquerading) ，如果默認不指定的話是DR模型. 2、刪除集群服務當中的RS ipvsadm -d -t|u|f service-address -r server-address 【查看服務信息（規則）】 ipvsadm -L|l -n 不進行反解 -c 查看連接個數 --stats 查看統計總數 --rate 查看連接速率 ipbsadm -Z 清空計數器 【清空所有定義的規則】 ipvsadm -C 【保存集群服務的規則】 ipvsadm -R = ipvsadm-restore ipvsadm -S = ipvsadm-save service ipvsadm save 高可用集群（High Availabitity Cluster） 高可用集群的軟件實現方式是：heartbeat corosycn 在SAN共享存儲中用到了HA Cluster,HA的實現即是相當于做一個冗余 高可用集群通常會采用可用性來衡量基實際效果。計算機系統的可用性是通過平均無故障時間(MTTF)及平均維修時間(MTTR)來度量。

?

轉載于:https://www.cnblogs.com/deamon/archive/2012/11/27/2791507.html

總結

以上是生活随笔為你收集整理的集群服务负载均衡------LVS的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。