一. 叢集的概念

伺服器叢集簡稱叢集是一種伺服器系統，它通過一組鬆散整合的伺服器軟體和/或硬體連線起來高度緊密地協作完成計算工作。在某種意義上，他們可以被看作是一臺伺服器。
集群系統中的單個伺服器通常稱為節點，通常通過區域網連線，但也有其它的可能連線方式。叢集伺服器通常用來改進單個伺服器的計算速度和/或可靠性。一般情況下叢集
伺服器比單個伺服器，比如工作站或超級伺服器效能價格比要高得多。叢集就是一組獨立的伺服器，通過網路連線組合成一個組合來共同完一個任務。

說的直白點，叢集就是一組相互獨立的伺服器，通過高速的網路組成一個伺服器系統，每個叢集節點都是執行其自己程序的一個獨立伺服器。對網路使用者來講，網站後
端就是一個單一的系統，協同起來向用戶提供系統資源，系統服務。

二. 為什麼要使用叢集

1) 叢集的特點
-  高效能performance
一些需要很強的運算處理能力比如天氣預報，核試驗等。這就不是幾臺伺服器能夠搞定的。這需要上千臺一起來完成這個工作的。

-  價格有效性
通常一套系統叢集架構，只需要幾臺或數十臺伺服器主機即可，與動則上百萬的專用超級伺服器具有更高的價效比。

-  可伸縮性
當伺服器負載壓力增長的時候，系統能夠擴充套件來滿足需求，且不降低服務質量。

-  高可用性
儘管部分硬體和軟體發生故障，整個系統的服務必須是7*24小時執行的。

2) 叢集的優勢
-  透明性
如果一部分伺服器宕機了業務不受影響，一般耦合度沒有那麼高，依賴關係沒有那麼高。比如NFS伺服器宕機了其他就掛載不了了，這樣依賴性太強。

-  高效能
訪問量增加，能夠輕鬆擴充套件。

-  可管理性
整個系統可能在物理上很大，但很容易管理。

-  可程式設計性
在集群系統上，容易開發應用程式，入口網站會要求這個。

3) 叢集分類及不同分類的特點
計算機叢集架構按照功能和結構一般分成以下幾類：
-  負載均衡叢集（Loadbalancingclusters）簡稱LBC
-  高可用性叢集（High-availabilityclusters）簡稱HAC
-  高效能運算叢集（High-perfomanceclusters）簡稱HPC
-  網格計算（Gridcomputing）

就叢集分類而言, 網路上面一般認為是有三個，負載均衡和高可用叢集式我們網際網路行業常用的叢集架構。
1) 負載均衡叢集
負載均衡叢集為企業提供了更為實用，價效比更高的系統架構解決方案。負載均衡叢集把很多客戶集中訪問的請求負載壓力可能儘可能平均的分攤到計算機叢集中處理。
客戶請求負載通常包括應用程度處理負載和網路流量負載。這樣的系統非常適合向使用同一組應用程式為大量使用者提供服務。每個節點都可以承擔一定的訪問請求負載壓力，
並且可以實現訪問請求在各節點之間動態分配，以實現負載均衡。

負載均衡執行時，一般通過一個或多個前端負載均衡器將客戶訪問請求分發到後端一組伺服器上，從而達到整個系統的高效能和高可用性。這樣叢集有時也被稱為伺服器群。
一般高可用性叢集和負載均衡叢集會使用類似的技術，或同時具有高可用性與負載均衡的特點。

負載均衡叢集的作用：
a）分擔訪問流量（負載均衡）
b）保持業務的連續性（高可用）

2) 高可用性叢集
一般是指當叢集中的任意一個節點失效的情況下，節點上的所有任務自動轉移到其他正常的節點上，並且此過程不影響整個叢集的執行，不影響業務的提供。類似是叢集中執行著兩個或兩個以上的一樣的節點，當某個主節點出現故障的時候，那麼其他作為從 節點的節點就會接替主節點上面的任務。從節點可以接管主節點的資源（IP地址，架構身份等），此時使用者不會發現提供服務的物件從主節點轉移到從節點。
高可用性叢集的作用：當一臺機器宕機另一臺進行接管。比較常用的高可用叢集開源軟體有：keepalive，heardbeat。

3) 高效能運算叢集
高效能運算叢集採用將計算任務分配到叢集的不同計算節點兒提高計算能力，因而主要應用在科學計算領域。比較流行的HPC採用Linux作業系統和其它一些免費軟體來完成並行運算。這一叢集配置通常被稱為Beowulf叢集。這類叢集通常執行特定的程式以發揮HPCcluster的並行能力。這類程式一般應用特定的執行庫, 比如專為科學計算設計的MPI庫。HPC叢集特別適合於在計算中各計算節點之間發生大量資料通訊的計算作業，比如一個節點的中間結果或影響到其它節點計算結果的情況。

三. 負載均衡叢集介紹

負載均衡叢集是 Load Balance 叢集, 是一種將網路上的訪問流量分佈於各個節點，以降低伺服器壓力，更好的向客戶端提供服務的一種方式。
負載均衡叢集的作用：提供一種廉價、有效、透明的方法，來擴充套件網路裝置和伺服器的負載頻寬、增加吞吐量，加強網路資料處理能力、提高網路的靈活性和可用性。簡單來說,也就是:
1) 把單臺計算機無法承受的大規模的併發訪問或資料流量分擔到多臺節點裝置上分別處理，減少使用者等待響應的時間，提升使用者體驗。
2) 單個重負載的運算分擔到多臺節點裝置上做並行處理，每個節點裝置處理結束後，將結果彙總，返回給使用者，系統處理能力得到大幅度提高。
3) 7*24小時的服務保證，任意一個或多個裝置節點裝置宕機，不能影響到業務。在負載均衡叢集中，所有計算機節點都應該提供相同的服務，叢集負載均衡獲取所有對該服務的如站請求。

常用的負載均衡分為:
1) 開源軟體負載均衡:  Nginx, LVS, Haproxy  (Nginx和Haproxy通常做七層負載均衡, LVS做四層負載均衡. 但是Nginx也可以通過stream模組做四層負載均衡, Haproxy也可以做四層負載均衡 ) ;
2) 商業的硬體負載均衡: 裝置F5、Netscale ;

簡單理解一下軟體負載均衡:
1) 所謂分層的負載均衡，都是以網路的模型來說的。四層就是基於IP和埠的負載均衡，七層就是基於URL等應用資訊的負載均衡。所以簡單的說四層負載均衡就是通過IP和埠接收請求再分發至真實的伺服器，七層是通過URL或主機名接收請求，然後分發至真實的伺服器。
2) .而七層的實現也是在四層的基礎上是實現的，沒有四層就不可能有七層。在第七層上可以做許多事情，比如可以根據七層的瀏覽器類別區分是手機還是PC，將WEB伺服器分為2組，手機登陸專門的移動端網站。
3) 對客戶端來說，客戶端好像是訪問的同一臺主機。其實為了有更好的使用者體驗，從智慧DNS入手，根據客戶端IP來源將域名解析到距離客戶端最近的一臺伺服器或者訪問最快速的一臺伺服器，但這些內容客戶端都是感覺不到的，客戶端感覺到的只能是訪問網站很快。

四. LVS負載均衡叢集說明

1) LVS是什麼?
LVS是linux virtual server的簡寫linux虛擬伺服器，是一個虛擬的伺服器集群系統，可以在unix/linux平臺下實現負載均衡叢集功能。該專案在1998年5月由章文嵩博士組織成立。LVS是一種叢集(Cluster)技術，採用IP負載均衡技術和基於內容請求分發技術。排程器具有很好的吞吐率，將請求均衡地轉移到不同的伺服器上執行，且排程器自動遮蔽掉伺服器
的故障，從而將一組伺服器構成一個高效能的、高可用的虛擬伺服器。整個伺服器叢集的結構對客戶是透明的，而且無需修改客戶端和伺服器端的程式。

LVS叢集採用IP負載均衡技術和基於內容請求分發技術。排程器具有很好的吞吐率，將請求均衡地轉移到不同的伺服器上執行，且排程器自動遮蔽掉服 務器的故障，從而將一組伺服器構成一個高效能的、高可用的虛擬伺服器。整個伺服器叢集的結構對客戶是透明的，而且無需修改客戶端和伺服器端的程式。

LVS在設計時需要考慮系統的透明性、可伸縮性、高可用性和易管理性。一般來說，LVS叢集採用三層結構，其體系結構如圖所示：

負載均衡的原理很簡單，就是當客戶端發起請求時，請求直接發給Director Server（排程器），這時會根據設定的排程演算法，將請求按照演算法的規定智慧的分發到真正的後臺伺服器。以達到將壓力均攤。但是我們知道，http的連線時無狀態的，假設這樣一個場景，我登入某寶買東西，當我看上某款商品時，我將它加入購物車，但是我重新整理了一下頁面，這時由於負載均衡的原因，排程器又選了新的一臺伺服器為我提供服務，我剛才的購物車內容全都不見了，這樣就會有十分差的使用者體驗。所以就還需要一個儲存共享，這樣就保證了使用者請求的資料是一樣的。所以LVS負載均衡分為三層架構(也就是LVS負載均衡主要組成部分)：

第一層：負載排程器（load balancer/ Director），它是整個叢集的總代理，它在有兩個網絡卡，一個網卡面對訪問網站的客戶端，一個網��面對整個叢集的內部。負責將客戶端的請求傳送到一組伺服器上執行，而客戶也認為服務是來自這臺主的。舉個生動的例子，叢集是個公司，負載排程器就是在外接攬生意，將接攬到的生意分發給後臺的真正幹活的真正的主機們。當然需要將活按照一定的演算法分發下去，讓大家都公平的幹活。
第二層：伺服器池（server pool/ Realserver），是一組真正執行客戶請求的伺服器，可以當做WEB伺服器。就是上面例子中的小員工。  
第三層：共享儲存（shared storage），它為伺服器池提供一個共享的儲存區，這樣很容易使得伺服器池擁有相同的內容，提供相同的服務。一個公司得有一個後臺賬目吧，這才能協調。不然客戶把錢付給了A，而換B接待客戶，因為沒有相同的賬目。B說客戶沒付錢，那這樣就不是客戶體驗度的問題了。

2) LVS負載均衡叢集特點

2.1) IP負載均衡與負載排程演算法
IP負載均衡技術
負載均衡技術有很多實現方案，有基於DNS域名輪流解析的方法、有基於客戶端排程訪問的方法、有基於應用層系統負載的排程方法，還有基於IP地址的排程方法，在這些負載排程演算法中，執行效率最高的是IP負載均衡技術。

LVS的IP負載均衡技術是通過IPVS模組來實現的，IPVS是LVS集群系統的核心軟體，它的主要作用是：安裝在Director Server上，同時在Director Server上虛擬出一個IP地址，使用者必須通過這個虛擬的IP地址訪問服務。這個虛擬IP一般稱為LVS的VIP，即Virtual IP。訪問的請求首先經過VIP到達負載排程器，然後由負載排程器從Real Server列表中選取一個服務節點響應使用者的請求。當用戶的請求到達負載排程器後，排程器如何將請求傳送到提供服務的Real Server節點，而Real Server節點如何返回資料給使用者，是IPVS實現的重點技術，IPVS實現負載均衡機制有三種，分別是NAT、TUN和DR(下面會詳細介紹);

負載排程演算法
負載排程器是根據各個伺服器的負載情況，動態地選擇一臺Real Server響應使用者請求，那麼動態選擇是如何實現呢，其實也就是我們這裡要說的負載排程演算法，根據不同的網路服務需求和伺服器配置，IPVS實現瞭如下八種負載排程演算法：rr、wrr、Wlc、Dh、SH、Lc、Lblc(下面會詳細介紹);

2.2) 高可用性
LVS是一個基於核心級別的應用軟體，因此具有很高的處理效能，後端伺服器可執行任何支援TCP/IP的作業系統，包括Linux，各種Unix（如FreeBSD、Sun Solaris、HP Unix等），Mac/OS和Windows NT/2000等。負載排程器能夠支援絕大多數的TCP和UDP協議.

2.3) 效能
LVS伺服器集群系統具有良好的伸縮性，可支援幾百萬個併發連線。用LVS構架的負載均衡集群系統具有優秀的處理能力，每個服務節點的故障不會影響整個系統的正常使用，同時又實現負載的合理均衡，使應用具有超高負荷的服務能力，可支援上百萬個併發連線請求。如配置百兆網絡卡，採用VS/TUN或VS/DR排程技術，整個集群系統的吞吐量可高達1Gbits/s；如配置千兆網絡卡，則系統的最大吞吐量可接近10Gbits/s。

2.4）高可靠性
LVS負載均衡叢集軟體已經在企業、學校等行業得到了很好的普及應用，國內外很多大型的、關鍵性的web站點也都採用了LVS叢集軟體，所以它的可靠性在實踐中得到了很好的證實。有很多以LVS做的負載均衡系統，執行很長時間，從未做過重新啟動。這些都說明了LVS的高穩定性和高可靠性。

2.5) 適用環境
LVS對前端Director Server目前僅支援Linux和FreeBSD系統，但是支援大多數的TCP和UDP協議，支援TCP協議的應用有：HTTP，HTTPS ，FTP，SMTP，，POP3，IMAP4，PROXY，LDAP，SSMTP等等。支援UDP協議的應用有：DNS，NTP，ICP，視訊、音訊流播放協議等。LVS對Real Server的作業系統沒有任何限制，Real Server可執行在任何支援TCP/IP的作業系統上，包括Linux，各種Unix（如FreeBSD、Sun Solaris、HP Unix等），Mac/OS和Windows等。

2.6) 開源軟體（軟體許可證）
LVS叢集軟體是按GPL（GNU Public License）許可證發行的自由軟體，因此，使用者可以得到軟體的原始碼，並且可以根據自己的需要進行各種修改，但是修改必須是以GPL方式發行。

3) LVS體系結構

LVS叢集負載均衡器接受服務的所有入展客戶端的請求，然後根據排程演算法決定哪個叢集節點來處理回覆客戶端的請求。LVS虛擬伺服器的體系如下圖所示，一組伺服器通過高速的區域網或者地理分佈的廣域網相互連線，在這組伺服器之前有一個負載排程器（load balance）。負載排程器負責將客戶的請求排程到真實伺服器上。這樣這組伺服器叢集的結構對使用者來說就是透明的。客戶訪問集群系統就如只是訪問一臺高效能，高可用的伺服器一樣。客戶程式不受伺服器叢集的影響，不做任何修改。

就比如說：我們去飯店吃飯點菜，客戶只要跟服務員點菜就行。並不需要知道具體他們是怎麼分配工作的，所以他們內部對於我們來說是透明的。此時這個服務員就會按照一定的規則把他手上的活，分配到其他人員上去。這個服務員就是負載均衡器（LB）而後面這些真正做事的就是伺服器叢集。

LVS結構圖如下:

LVS基本工作過程

客戶請傳送向負載均衡伺服器傳送請求。負載均衡器接受客戶的請求，然後先是根據LVS的排程演算法（8種）來決定要將這個請求傳送給哪個節點伺服器。然後依據自己的工作模式（3種）來看應該如何把這些客戶的請求如何傳送給節點伺服器，節點伺服器又應該如何來把響應資料包發回給客戶端。

LVS組成

從上面可知, 核心支援的ipvs模組, 上圖中的rr，wrr，lc，wlc，lblc等等都是lvs中排程器的排程演算法，根據不同的排程演算法可以更好的分配服務，實現負載均衡。而ipvs(ip virtual server)：一段程式碼工作在核心空間，實現排程。

上圖是ipvsadm (即LVS客戶端管理工具), 主要負責為ipvs核心框架編寫規則，定義誰是叢集服務，而誰是後端真實的伺服器(Real Server)。 

4) LVS的實現原理

lvs的原理其實就是利用了Iptables的功能。瞭解防火牆的都知道四表五鏈。防火牆不僅僅有放火的功能還有轉發，地址偽裝，限流等等功能。

1) 首先，客戶端向排程器（Director Server）發起一個請求，排程器將這個請求傳送至核心
2) PREROUTING鏈首先會接收到使用者請求，判斷目標IP確定是本機IP，將資料包發往INPUT鏈。
3) 當請求達到INPUT鏈上，排程器判斷報文中的目標埠來確定這個訪問是不是要訪問叢集服務（因為還有可能只是ssh想單純的遠端登入主機這個主機），如果是訪問的叢集服務，那麼就會強制修改這個包的目標IP
4) POSTROUTING連結收資料包後發現目標IP地址剛好是自己的後端伺服器，那麼此時通過選路，將資料包最終傳送給後端的伺服器

5) LVS的工作原理

LVS 的工作模式分為4中分別是 NAT，DR，TUN，FULL-NAT。其中做個比較，由於工作原理的關係的，NAT的配置最為簡單，但是NAT對排程器的壓力太大了，導致其效率最低，DR和TUN的工作原理差不多，但是DR中，所有主機必須處於同一個物理環境中，而在TUN中，所有主機可以分佈在不同的位置，伺服器一個在紐約，一個在深圳。最多應用的是FULL-NAT。

其中的專業術語
DS：Director Server。指的是前端負載均衡器。
RS：Real Server。後端真實的工作伺服器。
VIP：向外部直接面向用戶請求，作為使用者請求的目標的IP地址。
DIP：Director Server IP，主要用於和內部主機通訊的IP地址。
RIP：Real Server IP，後端伺服器的IP地址。
CIP：Client IP，訪問客戶端的IP地址。

下面介紹LVS常用的三種負載均衡模式
1）NAT模式-網路地址轉換          Virtualserver via Network address translation(VS/NAT)
這個是通過網路地址轉換的方法來實現排程的。首先排程器(LB)接收到客戶的請求資料包時（請求的目的IP為VIP），根據排程演算法決定將請求傳送給哪個後端的真實伺服器（RS）。然後排程就把客戶端傳送的請求資料包的目標IP地址及埠改成後端真實伺服器的IP地址（RIP）,這樣真實伺服器（RS）就能夠接收到客戶的請求資料包了。真實伺服器響應完請求後，檢視預設路由（NAT模式下我們需要把RS的預設路由設定為LB伺服器。）把響應後的資料包傳送給LB,LB再接收到響應包後，把包的源地址改成虛擬地址（VIP）然後傳送回給客戶端。

VS/NAT是一種最簡單的方式，所有的RealServer只需要將自己的閘道器指向Director即可。客戶端可以是任意作業系統，但此方式下，一個Director能夠帶動的RealServer比較有限。在VS/NAT的方式下，Director也可以兼為一臺RealServer。VS/NAT的體系結構如圖所示。

NAT工作模式下，排程過程IP包詳細圖：

NAT模式的以上原理圖簡述：
1) 客戶端請求資料，目標IP為VIP
2) 請求資料到達LB伺服器，LB根據排程演算法將目的地址修改為RIP地址及對應埠（此RIP地址是根據排程演算法得出的。）並在連線HASH表中記錄下這個連線。
3) 資料包從LB伺服器到達RS伺服器webserver，然後webserver進行響應。Webserver的閘道器必須是LB，然後將資料返回給LB伺服器。
4) 收到RS的返回後的資料，根據連線HASH表修改源地址VIP&目標地址CIP，及對應埠80.然後資料就從LB出發到達客戶端。
5) 客戶端收到的就只能看到VIP\DIP資訊。

NAT模式優缺點：
1) NAT技術將請求的報文和響應的報文都需要通過LB進行地址改寫，因此網站訪問量比較大的時候LB負載均衡排程器有比較大的瓶頸，一般要求最多之能10-20臺節點。
2) 只需要在LB上配置一個公網IP地址就可以了。
3) 每臺內部的節點伺服器的閘道器地址必須是排程器LB的內網地址。
4) NAT模式支援對IP地址和埠進行轉換。即使用者請求的埠和真實伺服器的埠可以不一致。

再看下面的NAT模式圖

客戶發出請求，傳送請求給連結排程器的VIP，排程器將請求報文中的目標Ip地址改為RIP。這樣伺服器RealServer將請求的內容發給排程器，排程器再將報文中的源IP地址改為VIP;
1) 當用戶請求到達Director Server，此時請求的資料報文會先到核心空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP;
2) PREROUTING檢查發現數據包的目標IP是本機，將資料包送至INPUT鏈;
3) IPVS比對資料包請求的服務是否為叢集服務，若是，修改資料包的目標IP地址為後端伺服器IP，然後將資料包發至POSTROUTING鏈。 此時報文的源IP為CIP，目標IP為RIP
4) POSTROUTING鏈通過選路，將資料包傳送給Real Server;
5) Real Server比對發現目標為自己的IP，開始構建響應報文發回給Director Server。 此時報文的源IP為RIP，目標IP為CIP;
6) Director Server在響應客戶端前，此時會將源IP地址修改為自己的VIP地址，然後響應給客戶端。 此時報文的源IP為VIP，目標IP為CIP;

NAT模式特點和注意事項：
1) 很好配置，原理簡單易懂;
2) 由於排程器的工作量太大，很容易成為整個集群系統的瓶頸;
3) RS應該使用私有地址；
4) RS的閘道器的必須指向DIP；
5) RIP和DIP必須在同一網段內；
6) 請求和響應的報文都得經過Director；在高負載場景中，Director很可能成為系統性能瓶頸；
7) 支援埠對映；
8) RS可以使用任意支援叢集服務的OS；

2）TUN模式-IP隧道模式          Virtual Server via IP Tunneling(VS/TUN)
IP隧道(IP tunneling)是將一個IP報文封裝在另一個IP報文的技術，這可以使得目標為一個IP地址的資料報文能被封裝和轉發到另一個IP地址。IP隧道技術亦稱為IP封裝技術(IP encapsulation)。

IP隧道主要用於移動主機和虛擬私有網路(Virtual Private Network)，在其中隧道都是靜態建立的，隧道一端有一��IP地址，另一端也有唯一的IP地址。它的連線排程和管理與VS/NAT中的一樣，只是它的報文轉發方法不同。排程器根據各個伺服器的負載情況，動態地選擇一臺伺服器，將請求報文封裝在另一個IP報文中，再將封裝後的IP報文轉發給選出的伺服器; 伺服器收到報文後，先將報文解封獲得原來目標地址為 VIP 的報文，伺服器發現VIP地址被配置在本地的IP隧道裝置上，所以就處理這個請求，然後根據路由表將響應報文直接返回給客戶。

採用NAT模式時，由於請求和響應的報文必須通過排程器地址重寫，當客戶請求越來越多時，排程器處理能力將成為瓶頸。為了解決這個問題，排程器把請求的報文通過IP隧道轉發到真實的伺服器。真實的伺服器將響應處理後的資料直接返回給客戶端。這樣排程器就只處理請求入站報文，由於一般網路服務應答資料比請求報文大很多，採用VS/TUN模式後，集群系統的最大吞吐量可以提高10倍。

VS/TUN的工作原理流程圖如下所示，它和NAT模式不同的是，它在LB和RS之間的傳輸不用改寫IP地址。而是把客戶請求包封裝在一個IP tunnel裡面，然後傳送給RS節點伺服器，節點伺服器接收到之後解開IP tunnel後，進行響應處理。並且直接把包通過自己的外網地址傳送給客戶不用經過LB伺服器。

TUN模式下的以上原理圖過程簡述：
1）客戶請求資料包，目標地址VIP傳送到LB上;
2）LB接收到客戶請求包，進行IP Tunnel封裝。即在原有的包頭加上IP Tunnel的包頭。然後傳送出去;
3）RS節點機器根據IP Tunnel包頭資訊 (此時就又一種邏輯上的隱形隧道，只有LB和RS之間懂）收到請求包，然後解開IP Tunnel包頭資訊，得到客戶的請求包並進行響應處理。
4）響應處理完畢之後，RS伺服器使用自己的出公網的線路，將這個響應資料包傳送給客戶端。源IP地址還是VIP地址。（RS節點伺服器需要在本地迴環介面配置VIP);

其實TUN模式和下面的DR模式差不多，但是比DR多了一個隧道技術以支援realserver不在同一個物理環境中。就是realserver一個在北京，一個工作在上海。在原有的IP報文外再次封裝多一層IP首部，內部IP首部(源地址為CIP，目標IIP為VIP)，外層IP首部(源地址為DIP，目標IP為RIP.  再看下面的TUN模式圖:

1)  當用戶請求到達Director Server，此時請求的資料報文會先到核心空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP 。
2)  PREROUTING檢查發現數據包的目標IP是本機，將資料包送至INPUT鏈;
3)  IPVS比對資料包請求的服務是否為叢集服務，若是，在請求報文的首部再次封裝一層IP報文，封裝源IP為為DIP，目標IP為RIP。然後發至POSTROUTING鏈。 此時源IP為DIP，目標IP為RIP;
4)  POSTROUTING鏈根據最新封裝的IP報文，將資料包發至RS（因為在外層封裝多了一層IP首部，所以可以理解為此時通過隧道傳輸）。 此時源IP為DIP，目標IP為RIP;
5)  RS接收到報文後發現是自己的IP地址，就將報文接收下來，拆除掉最外層的IP後，會發現裡面還有一層IP首部，而且目標是自己的lo介面VIP，那麼此時RS開始處理此請求，處理完成之後，通過lo介面送給eth0網絡卡，然後向外傳遞。 此時的源IP地址為VIP，目標IP為CIP;
6)  響應報文最終送達至客戶端;

LVS-TUN (ip隧道) 模式特點和注意事項
1) RIP、VIP、DIP全是公網地址
2) RS的閘道器不會也不可能指向DIP
3) 不支援埠對映
4) RS的系統必須支援隧道

3）DR模式-直接路由模式          Virtual Server via Direct Routing(VS/DR)
DR模式也就是用直接路由技術實現虛擬伺服器。它的連線排程和管理與VS/NAT和VS/TUN中的一樣，但它的報文轉發方法又有不同，VS/DR通過改寫請求報文的MAC地址，將請求傳送到Real Server，而Real Server將響應直接返回給客戶，免去了VS/TUN中的IP隧道開銷。這種方式是三種負載排程機制中效能最高最好的，但是必須要求Director Server與Real Server都有一塊網絡卡連在同一物理網段上。

Director和RealServer必需在物理上有一個網絡卡通過不間斷的區域網相連。 RealServer上繫結的VIP配置在各自Non-ARP的網路裝置上(如lo或tunl),Director的VIP地址對外可見，而RealServer的VIP對外是不可見的。RealServer的地址即可以是內部地址，也可以是真實地址。

DR模式是通過改寫請求報文的目標MAC地址，將請求發給真實伺服器的，而真實伺服器響應後的處理結果直接返回給客戶端使用者。同TUN模式一樣，DR模式可以極大的提高集群系統的伸縮性。而且DR模式沒有IP隧道的開銷，對叢集中的真實伺服器也沒有必要必須支援IP隧道協議的要求。但是要求排程器LB與真實伺服器RS都有一塊網絡卡連線到同一物理網段上，必須在同一個區域網環境。

DR模式是網際網路使用比較多的一種模式，DR模式原理圖如下：

DR模式以上原理過程簡述：
VS/DR模式的工作流程圖如上圖所示，它的連線排程和管理與NAT和TUN中的一樣，它的報文轉發方法和前兩種不同。DR模式將報文直接路由給目標真實伺服器。在DR模式中，排程器根據各個真實伺服器的負載情況，連線數多少等，動態地選擇一臺伺服器，不修改目標IP地址和目標埠，也不封裝IP報文，而是將請求報文的資料幀的目標MAC地址改為真實伺服器的MAC地址。然後再將修改的資料幀在伺服器組的區域網上傳送。因為資料幀的MAC地址是真實伺服器的MAC地址，並且又在同一個區域網。那麼根據區域網的通訊原理，真實復位是一定能夠收到由LB發出的資料包。真實伺服器接收到請求資料包的時候，解開IP包頭檢視到的目標IP是VIP。（此時只有自己的IP符合目標IP才會接收進來，所以我們需要在本地的迴環藉口上面配置VIP。

另外: 由於網路介面都會進行ARP廣播響應，但叢集的其他機器都有這個VIP的lo介面，都響應就會衝突。所以我們需要把真實伺服器的lo介面的ARP響應關閉掉。）然後真實伺服器做成請求響應，之後根據自己的路由資訊將這個響應資料包傳送回給客戶，並且源IP地址還是VIP。

其實整個DR模式都是停留在第二層的資料鏈路層, 直接修改MAC。實現報文的轉發。再看下面的DR模式圖:

1)  當用戶請求到達Director Server，此時請求的資料報文會先到核心空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP;
2)  PREROUTING檢查發現數據包的目標IP是本機，將資料包送至INPUT鏈;
3)  IPVS比對資料包請求的服務是否為叢集服務，若是，將請求報文中的源MAC地址修改為DIP的MAC地址，將目標MAC地址修改RIP的MAC地址，然後將資料包發至POSTROUTING鏈。 此時的源IP和目的IP均未修改，僅修改了源MAC地址為DIP的MAC地址，目標MAC地址為RIP的MAC地址;
4)  由於DS和RS在同一個網路中，所以是通過二層來傳輸。POSTROUTING鏈檢查目標MAC地址為RIP的MAC地址，那麼此時資料包將會發至Real Server;
5)  響應報文最終送達至客戶端;

LVS-DR模式特點和注意事項
1) 在前端路由器做靜態地址路由繫結，將對於VIP的地址僅路由到Director Server
2) arptables：在arp的層次上實現在ARP解析時做防火牆規則，過濾RS響應ARP請求。修改RS上核心引數（arp_ignore和arp_announce）將RS上的VIP配置在網絡卡介面的別名上，並限制其不能響應對VIP地址解析請求。
3) RS可以使用私有地址；但也可以使用公網地址，此時可以直接通過網際網路連入RS以實現配置、監控等；
4) RS的閘道器一定不能指向DIP；
5) RS跟Dirctory要在同一物理網路內（不能由路由器分隔）；
6) 請求報文經過Directory，但響應報文一定不經過Director
7) 不支援埠對映；
8) RS可以使用大多數的作業系統；

DR模式小結：
1）通過在排程器LB上修改資料包的目的MAC地址實現轉發。注意源地址仍然是CIP，目的地址仍然是VIP地址。
2）請求的報文經過排程器，而RS響應處理後的報文無需經過排程器LB，因此併發訪問量大時使用效率很高（和NAT模式比）
3）因為DR模式是通過MAC地址改寫機制實現轉發，因此所有RS節點和排程器LB只能在一個局域網裡面
4）RS主機需要繫結VIP地址在LO介面上（防止IP衝突），並且需要配置ARP機制。
5）RS節點的預設閘道器不需要配置成LB，而是直接配置為上級路由的閘道器，能讓RS直接出網就可以。
6）由於DR模式的排程器僅做MAC地址的改寫，所以排程器LB就不能改寫目標埠，那麼RS伺服器就得使用和VIP相同的埠提供服務。

三種負載均衡方式簡單比較：

1）NAT模式-網路地址轉換
VS/NAT 的優點是伺服器可以執行任何支援TCP/IP的作業系統，它只需要一個IP地址配置在排程器上，伺服器組可以用私有的IP地址。缺點是它的伸縮能力有限，當伺服器結點數目升到20時，排程器本身有可能成為系統的新瓶頸，因為在VS/NAT中請求和響應報文都需要通過負載排程器。如果負載排程器成為系統新的瓶頸，可以有三種方法解決這個問題：混合方法、VS/TUN和 VS/DR。在DNS混合集群系統中，有若干個VS/NAT負排程器，每個負載排程器帶自己的伺服器叢集，同時這些負載排程器又通過RR-DNS組成簡單的域名。但VS/TUN和VS/DR是提高系統吞吐量的更好方法。對於那些將IP地址或者埠號在報文資料中傳送的網路服務，需要編寫相應的應用模組來轉換報文資料中的IP地址或者埠號。這會帶來實現的工作量，同時應用模組檢查報文的開銷會降低系統的吞吐率。

2）TUN模式-IP隧道模式
在TUN 的集群系統中，負載排程器只將請求排程到不同的後端伺服器，後端伺服器將應答的資料直接返回給使用者。這樣負載排程器就可以處理大量的請求，它甚至可以排程百臺以上的伺服器(同等規模的伺服器)，而它不會成為系統的瓶頸。即使負載排程器只有100Mbps的全雙工網絡卡，整個系統的最大吞吐量可超過 1Gbps。所以，VS/TUN可以極大地增加負載排程器排程的伺服器數量。VS/TUN排程器可以排程上百臺伺服器，而它本身不會成為系統的瓶頸，可以用來構建高效能的超級伺服器。VS/TUN技術對伺服器有要求，即所有的伺服器必須支援"IP Tunneling"或者"IP Encapsulation"協議。目前，VS/TUN的後端伺服器主要執行Linux作業系統，我們沒對其他作業系統進行測試。因為"IP Tunneling"正成為各個作業系統的標準協議，所以VS/TUN應該會適用執行其他作業系統的後端伺服器。

3）DR模式
跟VS/TUN方法一樣，VS/DR排程器只處理客戶到伺服器端的連線，響應資料可以直接從獨立的網路路由返回給客戶。這可以極大地提高LVS集群系統的伸縮性。跟VS/TUN相比，這種方法沒有IP隧道的開銷，但是要求負載排程器與實際伺服器都有一塊網絡卡連在同一物理網段上，伺服器網路裝置(或者裝置別名)不作ARP響應，或者能將報文重定向(Redirect)到本地的Socket埠上。

6) LVS負載均衡排程演算法

VS的排程演算法決定了如何在叢集節點之間分佈工作負荷。當director排程器收到來自客戶端訪問VIP的上的叢集服務的入站請求時，director排程器必須決定哪個叢集節點應該
處理請求。

Director排程器用的排程方法基本分為兩類 (如下所列, LVS總共有10種排程算法, 常用的也就四種排程演算法, 下面會說到):
靜態排程演算法：rr，wrr，dh，sh
動態排程演算法：wlc，lc，lblc，lblcr, sed, nq

靜態排程 (也就是固定排程演算法)的4種演算法:
rr（輪詢）
輪詢排程：這種是最簡單的排程演算法，就是將請求A一個，B一個，A一個，B一個 ...... 迴圈的發。就算A主機掛掉了，排程器還是會將請求傳送到A。十分均衡。

wrr（權重, 即加權輪詢）
加權輪詢排程：這種演算法是在rr基礎上實現的，只不過加了權重，權重範圍為1-100，假設A的伺服器效能好，就給A的權重設定的高一點，設為2，而B主機是1。這樣就實現A二個，B一個，A二個，B一個 ...... 迴圈的發。這樣照顧到了伺服器效能。

sh（源地址雜湊）
源地址雜湊：主要是實現將此前的session（會話）繫結。將此前客戶的源地址作為雜湊鍵，從靜態的散列表中找出對應的伺服器，只要目標伺服器是沒有超負荷的就將請求傳送過去。就是說某客戶訪問過A,現在這個客戶又來了，所以客戶請求會被髮送到服務過他的A主機。

dh（目的地址雜湊）
目的地址雜湊：以目的地址為關鍵字查詢一個靜態hash表來獲得需要的RS。以目標地址為標準挑選。 功能是和sh近似的，但應用場景不同; 舉個dh排程演算法的例子：假設1號客戶訪問了web叢集的一個動態頁面，排程器將請求轉發個A伺服器，A伺服器的PHP將這個動態請求運行了一遍，生成了快取並回應1號客戶。這下2號客戶也訪問了這個動態頁面，排程器應該將請求發給A。畢竟A已經跑過這段程式了，有快取，對吧。所以這既是dh演算法）

動態排程演算法，動態演算法與靜態演算法最大的區別就是動態演算法考慮了伺服器的壓力。
活動連結（active）：客戶與伺服器建立連線並且有資料傳送
非活動連結（inactive）：只是建立連線，沒有資料傳送，沒有斷開連線

動態排程的6種演算法
lc（最少連結）
最少連線排程：這種演算法是看A，和B的主機誰的連線少，請求就發給誰。
簡單演算法：active*256+inactive  （誰小發給誰）

wlc（加權最少連結）LVS的理想演算法
加權最少連結：這種演算法就是比lc多了一個加權。
簡單演算法：( active*256+inactive )/weight    (誰小就發給誰)

sed（最短期望延遲）
基於wlc演算法，假設A，B的權重分別是1，2 。而A的連結數為1，B的連結數為2 。這樣的話，用wlc演算法得出的結果一樣，而明顯B的權重大，B的能力較強。用sed演算法的話，就可以避免wlc出現的問題。
簡單演算法：（active+1)*256/weight （活動的連線數+1）*256/除以權重  誰小發給誰
A：（1+1）/1
B：（2+1）/2  （B小，交給B）

nq（不用排隊）
基於sed演算法：在sed的基礎上，若誰的連結數為0，直接將請求傳送給它!

LBLC（基於區域性性的最少連線）類似於dh，目標地址hash
這個演算法主要用於Cache集群系統，因為Cache叢集的中客戶請求報文的目標IP地址的變化，將相同的目標URL地址請求排程到同一臺伺服器，來提高伺服器的訪問的區域性性和Cache命中率。從而調整整個叢集的系統處理能力。但是，如果realserver的負載處於一半負載，就用最少連結演算法，將請求傳送給活動連結少的主機。

LBLCR（帶複製的基於區域性性的最少連結）
該演算法首先是基於最少連結的，當一個新請求收到後，一定會將請求發給最少連線的那臺主機的。但這樣又破壞了cache命中率。但這個演算法中，叢集服務是cache共享的，假設A的PHP跑了一遍，得到快取。但其他realserver可以去A那裡拿快取，這是種快取複製機制。

負載排程器是根據各個伺服器的負載情況，動態地選擇一臺Real Server響應使用者請求，那麼動態選擇是如何實現呢，其實也就是這裡要說的負載排程演算法，根據不同的網路服務需求和伺服器配置，IPVS實現瞭如上的十種負載排程演算法，下面詳細講述LVS最常用的四種排程演算法：
-  輪叫排程（Round Robin）
"輪叫"排程也叫1:1排程，排程器通過"輪叫"排程演算法將外部使用者請求按順序1:1的分配到叢集中的每個Real Server上，這種演算法平等地對待每一臺Real Server，而不管伺服器
上實際的負載狀況和連線狀態。

-  加權輪叫排程（Weighted Round Robin）
"加權輪叫"排程演算法是根據Real Server的不同處理能力來排程訪問請求。可以對每臺Real Server設定不同的排程權值，對於效能相對較好的Real Server可以設定較高的權值，而對於處理能力較弱的Real Server，可以設定較低的權值，這樣保證了處理能力強的伺服器處理更多的訪問流量。充分合理的利用了伺服器資源。同時，排程器還可以自動查詢Real Server的負載情況，並動態地調整其權值。

-  最少連結排程（Least Connections）
"最少連線"排程演算法動態地將網路請求排程到已建立的連結數最少的伺服器上。如果集群系統的真實伺服器具有相近的系統性能，採用"最小連線"排程演算法可以較好地均衡負載。

-  加權最少連結排程（Weighted Least Connections）
"加權最少連結排程"是"最少連線排程"的超集，每個服務節點可以用相應的權值表示其處理能力，而系統管理員可以動態的設定相應的權值，預設權值為1，加權最小連線排程在分配新連線請求時儘可能使服務節點的已建立連線數和其權值成正比。

LVS排程演算法的生產環境選型：
1）一般的網路服務，如http，nginx，mysql等常用的LVS排程演算法為：
a. 基本輪詢排程rr
b. 加權最小連線排程wlc
c. 加權輪詢排程wrc

2）基於區域性性的最小連線lblc和帶複製的給予區域性性最小連線lblcr主要適用於web cache和DB cache;

3）源地址雜湊排程SH和目標地址雜湊排程DH可以結合使用在防火牆叢集中，可以保證整個系統的出入口唯一;

其實對於LVS的理解，主要部分還是在於3種工作方式和8種排程演算法，實際這些演算法的適用範圍很多，工作中最好參考核心中的連線排程演算法的實現原理，然後根據具體的業務需求合理的選型。 

LVS的 Session持久機制
1）session繫結：始終將同一個請求者的連線定向至同一個rs（第一次請求時仍由排程方法選擇）；沒有容錯能力，有損均衡效果；
2）session複製：在rs之間同步session，因此，每個RS持叢集中所有的session；對於大規模叢集環境不適用；
3）session共享或伺服器機制：利用單獨部署的伺服器來統一管理session；

LVS使用中特別需要注意事項：
1) 關於時間同步：各節點間的時間偏差不大於1s，建議使用統一的ntp伺服器進行更新時間；
2) DR模型中的VIP的MAC廣播問題：
在DR模型中，由於每個節點均要配置VIP，因此存在VIP的MAC廣播問題，在現在的linux核心中，都提供了相應kernel 引數對MAC廣播進行管理，具體如下：
      arp_ignore: 定義接收到ARP請求時的響應級別；
          0：只要本地配置的有相應地址，就給予響應；
          1：僅在請求的目標地址配置在到達的介面上的時候，才給予響應；DR模型使用

     arp_announce：定義將自己地址向外通告時的通告級別；
         0：將本地任何介面上的任何地址向外通告；
         1：試圖僅向目標網路通告與其網路匹配的地址；
         2：僅向與本地介面上地址匹配的網路進行通告；DR模型使用

五. LVS安裝和簡單管理 (ipvsadm)
LVS全稱為Linux Virtual Server，工作在ISO模型中的第四層，由於其工作在第四層，因此與iptables類似，必須工作在核心空間上。因此lvs與iptables一樣，是直接工作在核心中的，叫ipvs，主流linux發行版預設都已經集成了ipvs，因此使用者只需安裝一個管理工具ipvsadm即可, ipvsadm是LVS在應用層的管理命令，可以通過這個命令去管理LVS的配置。

1) 安裝LVS

先安裝依賴
[[email protected] ~]# yum install -y libnl* popt*
 
檢視是否載入lvs模組
[[email protected] ~]# modprobe -l |grep ipvs
kernel/net/netfilter/ipvs/ip_vs.ko
kernel/net/netfilter/ipvs/ip_vs_rr.ko
kernel/net/netfilter/ipvs/ip_vs_wrr.ko
kernel/net/netfilter/ipvs/ip_vs_lc.ko
kernel/net/netfilter/ipvs/ip_vs_wlc.ko
kernel/net/netfilter/ipvs/ip_vs_lblc.ko
kernel/net/netfilter/ipvs/ip_vs_lblcr.ko
kernel/net/netfilter/ipvs/ip_vs_dh.ko
kernel/net/netfilter/ipvs/ip_vs_sh.ko
kernel/net/netfilter/ipvs/ip_vs_sed.ko
kernel/net/netfilter/ipvs/ip_vs_nq.ko
kernel/net/netfilter/ipvs/ip_vs_ftp.ko
kernel/net/netfilter/ipvs/ip_vs_pe_sip.ko
 
下載並安裝LVS
[[email protected] ~]# cd /usr/local/src/
[[email protected] src]# unlink /usr/src/linux
[[email protected] src]# ln -s /usr/src/kernels/2.6.32-431.5.1.el6.x86_64/ /usr/src/linux
[[email protected] src]# wget http://www.linuxvirtualserver.org/software/kernel-2.6/ipvsadm-1.26.tar.gz
[[email protected] src]# tar -zvxf ipvsadm-1.26.tar.gz
[[email protected] src]# cd ipvsadm-1.26
[[email protected] ipvsadm-1.26]# make && make install
 
LVS安裝完成，檢視LVS叢集
[[email protected] ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port          Forward Weight ActiveConn InActConn 

2) ipvsadm基本命令說明

1) ipvsadm的基本用法：
# ipvsadm COMMAND [protocol] service address
              [scheduling-method] [persistence options]
 
# ipvsadm command [protocol] service address
              server-address [packet-forwarding-method] [weight options]
 
第一條命令用於向LVS系統中新增一個用於負載均衡的virtual server（VS）；
第二條命令用來修改已經存在的VS的配置，service address用來指定涉及的虛擬服務即虛擬地址，server-address指定涉及的真實地址。
 
 
2) ipvsadm的幫助資訊
[[email protected] ~]# ipvsadm --help
ipvsadm v1.26 2008/5/15 (compiled with popt and IPVS v1.2.1)
Usage:
  ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]] [-M netmask] [--pe persistence_engine]
  ipvsadm -D -t|u|f service-address
  ipvsadm -C
  ipvsadm -R
  ipvsadm -S [-n]
  ipvsadm -a|e -t|u|f service-address -r server-address [options]
  ipvsadm -d -t|u|f service-address -r server-address
  ipvsadm -L|l [options]
  ipvsadm -Z [-t|u|f service-address]
  ipvsadm --set tcp tcpfin udp
  ipvsadm --start-daemon state [--mcast-interface interface] [--syncid sid]
  ipvsadm --stop-daemon state
  ipvsadm -h
 
Commands:
Either long or short options are allowed.
  --add-service    -A        add virtual service with options
  --edit-service    -E        edit virtual service with options
  --delete-service  -D        delete virtual service
  --clear          -C        clear the whole table
  --restore        -R        restore rules from stdin
  --save            -S        save rules to stdout
  --add-server      -a        add real server with options
  --edit-server    -e        edit real server with options
  --delete-server  -d        delete real server
  --list            -L|-l    list the table
  --zero            -Z        zero counters in a service or all services
  --set tcp tcpfin udp        set connection timeout values
  --start-daemon              start connection sync daemon
  --stop-daemon              stop connection sync daemon
  --help            -h        display this help message
 
Options:
  --tcp-service  -t service-address  service-address is host[:port]
  --udp-service  -u service-address  service-address is host[:port]
  --fwmark-service  -f fwmark        fwmark is an integer greater than zero
  --ipv6        -6                  fwmark entry uses IPv6
  --scheduler    -s scheduler        one of rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq,
                                      the default scheduler is wlc.
  --pe            engine              alternate persistence engine may be sip,
                                      not set by default.
  --persistent  -p [timeout]        persistent service
  --netmask      -M netmask          persistent granularity mask
  --real-server  -r server-address    server-address is host (and port)
  --gatewaying  -g                  gatewaying (direct routing) (default)
  --ipip        -i                  ipip encapsulation (tunneling)
  --masquerading -m                  masquerading (NAT)
  --weight      -w weight            capacity of real server
  --u-threshold  -x uthreshold        upper threshold of connections
  --l-threshold  -y lthreshold        lower threshold of connections
  --mcast-interface interface        multicast interface for connection sync
  --syncid sid                        syncid for connection sync (default=255)
  --connection  -c                  output of current IPVS connections
  --timeout                          output of timeout (tcp tcpfin udp)
  --daemon                            output of daemon information
  --stats                            output of statistics information
  --rate                              output of rate information
  --exact                            expand numbers (display exact values)
  --thresholds                        output of thresholds information
  --persistent-conn                  output of persistent connection info
  --nosort                            disable sorting output of service/server entries
  --sort                              does nothing, for backwards compatibility
  --ops          -o                  one-packet scheduling
  --numeric      -n                  numeric output of addresses and ports
 
 
命令：
-A, --add-service： 新增一個叢集服務. 即為ipvs虛擬伺服器新增一個虛擬服務，也就是新增一個需要被負載均衡的虛擬地址。虛擬地址需要是ip地址，埠號，協議的形式。
-E, --edit-service： 修改一個虛擬服務。
-D, --delete-service： 刪除一個虛擬服務。即刪除指定的叢集服務;
-C, --clear： 清除所有虛擬服務。
-R, --restore： 從標準輸入獲取ipvsadm命令。一般結合下邊的-S使用。
-S, --save： 從標準輸出輸出虛擬伺服器的規則。可以將虛擬伺服器的規則儲存，在以後通過-R直接讀入，以實現自動化配置。
-a, --add-server： 為虛擬服務新增一個real server（RS）
-e, --edit-server： 修改RS
-d, --delete-server： 刪除
-L, -l, --list： 列出虛擬服務表中的所有虛擬服務。可以指定地址。新增-c顯示連線表。
-Z, --zero： 將所有資料相關的記錄清零。這些記錄一般用於排程策略。
--set tcp tcpfin udp： 修改協議的超時時間。
--start-daemon state： 設定虛擬伺服器的備伺服器，用來實現主備伺服器冗餘。（注：該功能只支援ipv4）
--stop-daemon： 停止備伺服器。
-h, --help： 幫助。
 
引數：
以下引數可以接在上邊的命令後邊。
-t, --tcp-service service-address： 指定虛擬服務為tcp服務。service-address要是host[:port]的形式。埠是0表示任意埠。如果需要將埠設定為0，還需要加上-p選項（持久連線）。
-u, --udp-service service-address： 使用udp服務，其他同上。
-f, --fwmark-service integer： 用firewall mark取代虛擬地址來指定要被負載均衡的資料包，可以通過這個命令實現把不同地址、埠的虛擬地址整合成一個虛擬服務，可以讓虛擬伺服器同時截獲處理去往多個不同地址的資料包。fwmark可以通過iptables命令指定。如果用在ipv6需要加上-6。
-s, --scheduler scheduling-method： 指定排程演算法,預設是wlc。排程演算法可以指定以下8種：rr（輪詢），wrr（權重），lc（最後連線），wlc（權重），lblc（本地最後連線），lblcr（帶複製的本地最後連線），dh（目的地址雜湊），sh（源地址雜湊），sed（最小期望延遲），nq（永不排隊）
-p, --persistent [timeout]： 設定持久連線，這個模式可以使來自客戶的多個請求被送到同一個真實伺服器，通常用於ftp或者ssl中。
-M, --netmask netmask： 指定客戶地址的子網掩碼。用於將同屬一個子網的客戶的請求轉發到相同伺服器。
-r, --real-server server-address： 為虛擬服務指定資料可以轉發到的真實伺服器的地址。可以新增埠號。如果沒有指定埠號，則等效於使用虛擬地址的埠號。
[packet-forwarding-method]： 此選項指定某個真實伺服器所使用的資料轉發模式。需要對每個真實伺服器分別指定模式。
-g, --gatewaying： 使用閘道器（即直接路由），此模式是預設模式。
-i, --ipip： 使用ipip隧道模式。
-m, --masquerading： 使用NAT模式。
-w, --weight weight: 設定權重。權重是0~65535的整數。如果將某個真實伺服器的權重設定為0，那麼它不會收到新的連線，但是已有連線還會繼續維持（這點和直接把某個真實伺服器刪除時不同的）。
-x, --u-threshold uthreshold： 設定一個伺服器可以維持的連線上限。0~65535。設定為0表示沒有上限。
-y, --l-threshold lthreshold： 設定一個伺服器的連線下限。當伺服器的連線數低於此值的時候伺服器才可以重新接收連線。如果此值未設定，則當伺服器的連線數連續三次低於uthreshold時伺服器才可以接收到新的連線。（PS：筆者以為此設定可能是為了防止伺服器在能否接收連線這兩個狀態上頻繁變換）
--mcast-interface interface： 指定使用備伺服器時候的廣播介面。
--syncid syncid：指定syncid， 同樣用於主備伺服器的同步。
 
以下選項用於list命令：
-c, --connection： 列出當前的IPVS連線。
--timeout： 列出超時
--daemon：
--stats： 狀態資訊
--rate： 傳輸速率
--thresholds： 列出閾值
--persistent-conn： 堅持連線
--sor： 把列表排序。
--nosort： 不排序
-n, --numeric： 不對ip地址進行dns查詢
--exact： 單位
-6： 如果fwmark用的是ipv6地址需要指定此選項。   
   
 
=========其他注意事項=========
如果使用IPv6地址，需要在地址兩端加上"[]"。例如：ipvsadm -A -t [2001:db8::80]:80 -s rr
可以通過設定以下虛擬檔案的值來防禦DoS攻擊：
/proc/sys/net/ipv4/vs/drop_entry
/proc/sys/net/ipv4/vs/drop_packet
/proc/sys/net/ipv4/vs/secure_tcp

3) ipvsadm 舉例說明

一. LVS叢集服務管理類舉例
1) 新增：-A
# ipvsadm -A -t|u|f service-address [-s scheduler]
 
舉例1: 新增叢集
[[email protected] ~]# ipvsadm -A -t 172.16.60.111:80 -s wlc
 
2) 修改：-E
# ipvsadm -E -t|u|f service-address [-s scheduler]
 
舉例2: 修改叢集 (修改叢集的排程演算法)
[[email protected] ~]# ipvsadm -E -t 172.16.60.111:80 -s wrr
 
3) 刪除：-D
# ipvsadm -D -t|u|f service-address
 
舉例3: 刪除叢集
[[email protected] ~]# ipvsadm -D -t 172.16.60.111:80
 
 
二. 管理LVS叢集中的RealServer舉例
1) 新增RS : -a
# ipvsadm -a -t|u|f service-address -r server-address [-g|i|m] [-w weight]
 
舉例1: 往VIP資源為172.16.60.111的叢集服務裡新增兩個realserver
[[email protected] ~]# ipvsadm -a -t 172.16.60.111:80 -r 172.16.60.120 –g -w 5
[[email protected] ~]# ipvsadm -a -t 172.16.60.111:80 -r 172.16.60.130 –g -w 10
 
2) 修改RS : -e
# ipvsadm -e -t|u|f service-address -r server-address [-g|i|m] [-w weight]
 
舉例2: 修改172.16.60.111叢集服務裡172.16.60.120這個realserver的權重為3
[[email protected] ~]# ipvsadm -e -t 172.16.60.111:80 -r 172.16.60.120 –g -w 3
 
3) 刪除RS : -d
# ipvsadm -d -t|u|f service-address -r server-address
 
舉例3: 刪除172.16.60.111叢集服務裡172.16.60.120這