LVS作爲構建集羣的一種負載均衡器，由章文嵩先生編寫，是當今世界上公認的最強的負載均衡器；負載均衡器主要適用於主機之間的資源分配太過緊張，系統性能過低，使用負載均衡器可以有效的讓多臺主機一起分擔訪問資源的壓力，由LVS調度器分配由客戶端請求的資源到後端的真實服務器，而將資源交由哪一臺服務器操作則是由調度器通過特定的算法去實現的；
集羣的構建是爲了去解決某一特定問題而逐步構建起來的網絡架構，也許一開始集羣只有一臺主機作爲http服務器，一臺作爲動態資源訪問的php-fpm服務器，一臺作爲數據庫存儲的服務器，當網站資源訪問量大了之後，單一的php-fpm服務器無法有效的提供服務時就需要增加php-fpm的服務器，事實上一般公司都不止一臺的php-fpm服務器進行動態資源管理，而當多臺php-fpm服務器存在時，客戶端訪問資源時，假如客戶只是將資源進行了收藏，而這條記錄保存在第一臺php-fpm的服務器上，當客戶第二次重新訪問的時候，怎麼讓客戶基於第一臺php-fpm服務器進行後續的訪問呢？畢竟如果訪問的是其他的服務器就沒有之前客戶所收藏的記錄了；解決訪問記錄的方式有很多種常見的有會話粘性，會話複製等，但這類型的方式有其侷限性，當所訪問的php-fpm服務器出現問題的話，數據記錄就會消失，所以最好的辦法就是指定一個session server，這個會話服務器也是需要冗餘備份的，至於他與另一臺備份的會話服務器之間是共享的還是複製的，則是視情況而定了；支持後端真實服務器的mysql server和前端的http服務器也是需要冗餘備份的，至於設置幾臺也是視情況而定的了；畢竟不能讓其因爲當機的原因不能正常工作；而當http服務器擴展爲多臺的情況下，客戶端如何去考慮兩臺以上的http服務器，客戶端去訪問哪一臺http服務器？不可能讓客戶端記錄多個域名分別訪問的，這個時候調度器的概念就出來了，通過調度器的調度算法去訪問後端的真實服務器；LVS的工作方式是四層路由的模式，去尋找指定的路徑，根據指定的IP和端口去將數據報文調度轉發至後端的某個Real Server上；至於選擇哪個真實服務器，則根據調度算法的不同來看；
同iptables/netfilter一樣，設置LVS的集羣服務也分爲ipvsadm/ipvs，ipvsadm作爲用戶空間的命令行工具，用於管理集羣服務，而ipvs則作爲內核空間的netfilter的INPUT鉤子之上的框架，可以接收來自ipvsadm的管理命令；
LVS集羣中的專業術語：
CIP：客戶端IP地址；
AIP：虛擬服務器對外提供服務的IP地址；
DIP：虛擬服務對真實服務器提供服務的IP地址；
RIP：真實服務器的IP地址；
使用LVS的一般通信過程：客戶端以CIP作爲源地址向虛擬服務器VIP發送此次請求；使用DIP發送至後方的真實服務器的RIP；
CIP-->VIP-->DIP-->RIP
1.當用戶向調度器發出請求報文，調度器會將請求報文發往內核空間；
2.請求報文會首先通過PREROUTING鏈驗證目的IP是否是VIP，若是則放入請求報文；
3.請求報文通過INPUT鏈進行驗證，因爲ipvs是工作在INPUT鏈上，與INPUT鏈上的集羣服務進行驗證，如果通過驗證，則強行更改目的IP地址VIP，將其更改爲RIP，併發送給POSTROUTING；
4.POSTROUTING接收到報文後查看目的IP地址，知道是自己的後端的服務器IP地址，則發往指定的RIP；
LVS的集羣類型及其優缺點：
lv-nat集羣：
通過網絡地址轉換的方式實現虛擬服務器；隨着IPv4的IP地址的日益緊張很多企業的網絡都採用內部網絡的方式構建集羣；lv-nat的架構模式是客戶端通過訪問調度器，請求報文的源IP地址爲CIP，目標IP地址爲VIP，通過調度器的INPUT鏈中的調度算法指定目標RIP，進行目標IP地址的轉換，如DNAT，去訪問後端的服務器，調度器會在Hash中記錄這個連接，當這個連接再次訪問時，會從Hash中選定原連接訪問的服務器及其IP地址；後端服務器構建響應報文，源IP地址爲RIP，目的IP地址爲CIP，通過指定的網關DIP進入調度器，並在調度器中轉換源IP地址，將RIP換成客戶端的CIP，發送給客戶端；
在lv-nat中需要注意的是：
1.DIP與RIP需要在同一個網段中；
2.RIP的網關要指向DIP；
3.調度器的系統必須是Linux系統；
4.調度器容易成爲性能瓶頸；
lv-tun集羣：
通過IP隧道實現虛擬服務器；其中隧道都是靜態建立的，隧道一端有一個IP地址，另一端也有唯一的IP地址。客戶端發出的請求報文源IP爲CIP，目的IP爲VIP，在經過調度器後，添加了一個報文首部源IP爲DIP，目的IP爲RIP將要重新封裝的報文發往使用調度算法挑選出來的後端RS上；RIP在構建響應報文之後直接發給目標客戶端；lv-tun集羣，其響應報文直接發給目標主機，不通過調度器，有效的節省了調度器的資源，負載調度器就可以處理大量的請求，如lv-nat模式那般的話調度器大概能處理十臺真實服務器，而在lv-tun中就可以處理上百臺服務器，系統吞吐量大大增加；lv-tun這種模式，而CIP,VIP,DI
P,RIP都應該是公有的IP地址；其不支持端口重定向，在RS真實服務器上，需要有RIP以及VIP的存在；
lv-dr集羣：
通過直接路由實現的虛擬服務器；這裏的直接路由意味着，只有請求報文通過調度器調度轉發到真實服務器，而響應報文可以直接通過路由器轉發給客戶端；lv-dr集羣，調度器與真實服務器都連接在同一個交換機上，這時調度器的VIP與DIP就必須在同一個端口上；DIP與RIP在同一個網段上；客戶端訪問VIP，通過一層層路由轉發，到達指定調度器，這時，需要注意的是客戶端訪問調度器，再由調度器轉發給真實服務器的整個過程其請求報文的源IP，目標IP都沒有被轉換，一直都是CIP與VIP，在客戶端訪問調度器的過程中變化的只有MAC地址，到達調度器時，請求報文的源MAC地址爲交換機的MAC地址，目標MAC地址爲調度器的MAC地址；這樣的話，當請求報文到達調度器要進行轉發的時候，其目標IP地址是如何定位的？這個時候我們只有RS的MAC地址，並沒有其對應的目標IP地址RIP，轉發自然失敗，這個時候就需要我們設置真實服務器，在真實服務器的環回端口lo處設置VIP，這樣就有了對應的目標IP地址，但這樣有一個問題就是當請求報文發到交換機時，因爲真實服務器也擁有VIP地址，所以交換機也會將請求報文轉發給真實服務器的RIP端口，因爲Linux的特殊情況，所以環回接口的VIP也會對這個請求作出響應；在這個時候我們就要啓用內核中的兩個參數了，一個是arp_announce,用於在新添加的真實服務器對網絡的應答，添加服務器時，服務器會將自己所有信息通告給網絡，讓所有服務器記錄，做自我介紹，下次找他就很方便了，而arp_announce就是讓這個應答過程隱藏起來，限制所有加入網絡中的主機發送聲明；而arp_ignore則是用於在訪問的目的IP地址不是本接口的地址時，不對該請求響應，忽略；這個時候請求報文便可以正常處理，而響應報文則需要先通過環回接口，設置一條不管什麼請求都需要經過環回接口的路由，這個時候響應報文的源IP地址爲VIP，再通過直接路由轉發給客戶端，同lv-tun一般，不通過調度器轉發響應報文，大大提高了調度器的吞吐量；
LVS的調度算法：
靜態調度算法：只根據調度算法本身指定真實服務器，不根據真實服務器的情況調度
RR：輪詢，第一次的請求給第一臺RS，第二個請求給第二臺RS，因爲每臺RS處理的資源的量不一樣，有些時間長，有些時間短，這就可能造成有些RS越來越繁忙，有些RS越來越空閒；
WRR：加權輪詢，主要根據權重判斷服務器的狀態，多的少給，少的多給；但還是輪詢，只是特例而已；
SH：源地址哈希，調度器將來自於同一個IP地址的請求始終發往後端第一次被挑中的RS；從而實現會話綁定；
DH：目的地址哈希，發往同一個目標地址的請求，始終發往後端第一次被挑中的RS，一般用於正向代理服務器集羣；因爲代理服務器中有服務器內容的緩存，訪問速度加快；
動態調度算法：根據後端服務器的狀態而做出的相應的變換；Overhead表示後端服務器的負載；根據後端服務器當前的活動連接和非活動連接數來實現請求的調度；
LC：最少連接數；根據後端服務器每個服務器的連接數多少進行判斷，越少的則分配更多的資源；有兩種連接方式，活動連接activeconnections與非活動連接inactiveconnections
LC的負載計算：overhead=（activeconnections*256+inactiveconnection）
注意：第一次調度時，因爲各個RS上沒有任何連接，所以按照在ipvsadm中配置的順序自上而下進行分配；
WLC：最少連接數，但也根據權重判斷；因爲每臺服務器的性能不同權重也就不同；
WLC計算方式：Overhead=（activeconnection*256+inactiveconnections）/weight
權重越大說明解決問題的能力越強，負載就越低，這樣就可以分配更多的資源進行處理；
注意：第一次調度時，因爲各個RS上沒有任何連接，所以按照在ipvsadm中配置的順序自上而下進行分配；權重在第一次調度時不發揮作用；
SED：最短期望延遲；
SED計算方式：Overhead=（activeconnections*256+1）/weight
SED可以在第一次調度時就分配1個連接，從而根據權重得出的負載大小來分配資源；但SED請求存在的缺陷是可能會一直將請求分配給權重大的那個服務器，而其他服務器則處於空閒狀態；
NQ：改進版的SED算法，首次調度時根據後端RS的權重，每臺服務器分配一個連接；不讓任何一個服務器空閒，很好的解決了SED的缺陷；每臺服務器至少一個連接；然後再按照SED算法調度；必然會保證後端每臺RS至少有一個活動連接；
LBLC：Locality Based Least Connections，基於本地的最少連接，動態的DH算法；
LBLCR：LBLC with Replication，帶有複製功能的LBLC；把所有後端服務器的內容互相複製，保證每臺服務器中的內容一樣；