服務器向外部提供服務，當一臺服務器承受過多的壓力，那麼服務可能會產生服務不可用的情況，所以，我們應該讓一臺服務器承受的壓力在合理範圍內，如果一臺服務器無法滿足需求，那麼可以橫向擴展使用多臺服務器分攤這些壓力，這些服務器作爲一個整體對外提供服務，並且分攤壓力時，那麼我們可以稱這些服務器爲"負載均衡集羣"。
LVS 是 Linux Virtual Server 的簡稱，也就是 Linux 虛擬服務器。現在 LVS 已經是 Linux 標準內核的一部分，從 Linux2.4 內核以後，已經完全內置了 LVS 的各個功能模塊，無需給內核打任何補丁，可以直接使用 LVS 提供的各種功能。LVS在內核中名稱是ipvs，作爲netfilter的模塊存在，管理ipvs的工具爲ipvsadm。
LVS 是四層負載均衡，也就是說建立在 OSI 模型的第四層——傳輸層之上，傳輸層上有我們熟悉的 TCP/UDP，LVS 支持 TCP/UDP 的負載均衡。因爲 LVS 是四層負載均衡，因此它相對於其它高層負載均衡的解決辦法，比如 DNS 域名輪流解析、應用層負載的調度、客戶端的調度等，它的效率是非常高的。
爲方便後續探討，這裏先說明下幾個名詞
VS: Virtual Server，調度器，負責調度
RS: Real Server，負責真正提供服務，後端服務器
VIP: LVS服務器上的公網IP，即Virtual IP
DIP: LVS服務器上的內網IP，即Director IP
RIP: Real Server上的內網IP
CIP： 客戶端的IP
工作原理：
VS根據請求報文的目標IP和目標協議及端口將其調度轉發至某RS，根據調度算法來挑選RS。
LVS 的工作模式：
NAT :
SNAT: 修改源地址
DNAT: 修改目標地址
DR : 修改目標 MAC
TUN ： 在原請求IP報文之外新加一個IP首部
FULLNAT： 修改請求報文的源和目標IP
LVS的工作位置
流入數據包
LVS-NAT模式：
LVS-NAT報文中IP轉換過程
上圖所示：
1.客戶端的請求會發往LVS主機，此時，客戶端請求報文的源IP爲CIP，目標IP爲LVS的VIP
2.當LVS收到客戶端的請求報文時，會將請求報文中的目標IP修改爲後端某個RealServer的RIP，具體爲哪個RealServer的RIP，取決於LVS使用的具體算法
3.當RealServer收到對應的請求報文時，會發現報文的目標IP就是自己的RIP，於是就會接收報文並 處理後進行響應。響應報文的源IP則爲RIP，目標IP則爲CIP
4.當LVS收到對應的響應報文時，LVS會將響應報文的源IP修改爲VIP，目標IP不變爲CIP，於是響應報文被髮往客戶端。
5.客戶端則會收到響應報文，源IP爲VIP，端口爲80，而LVS相對於客戶端而言，轉換過程是透明的。
優點：集羣中的物理服務器可以使用任何支持TCP/IP操作系統，物理服務器可以分配Internet的保留 私有地址，只有負載均衡器需要一個合法的IP地址。
缺點：擴展性有限。當服務器節點（普通PC服務器）數量增長到20個或更多時,負載均衡器將成爲整個系統的瓶頸，因爲所有的請求包和應答包都需要經過負載均衡器再生。
LVS-NAT的建議：
（1）RIP和DIP建議在同一個IP網絡，且應使用私網地址；RS的網關要指向DIP(中間無其他設備)
（2）請求報文和響應報文都必須經由LVS轉發，LVS易於成爲系統瓶頸。但是也能滿足一般需求
（3）支持端口映射，可修改請求報文的目標PORT
（4）VS必須是Linux系統，RS可以是任意OS系統
LVS-DR模式：
LVS默認模式。直接路由，應用最廣泛,通過爲請求報文重新封裝一個MAC首部進行轉發。
DR 模式下需要 LVS 和 RS 集羣綁定同一個 VIP（RS 通過將 VIP 綁定在 loopback 實現），
請求報文由 LVS 接受，響應報文不經過 LVS，由RealServer(RS）直接返回給用戶。因此，DR 模式具有較好的性能，也是目前大型網站使用最廣泛的一種負載均衡手段。
源MAC是DIP所在的接口的MAC，
目標MAC是調度算法選出的RS的RIP所在接口的MAC地址；
源IP/端口，以及目標IP/端口均保持不變
LVS和各RS都配置有VIP
LVS-DR報文中IP和MAC轉換過程
上圖所示：
1.客戶端的請求會發往LVS主機，此時，客戶端請求報文的源IP爲CIP，目標IP爲LVS的VIP
2.當LVS收到客戶端的請求報文時，會將請求報文中的源MAC修改爲本機的DIP所在網卡的MAC,把目標MAC修改爲後端某個RealServer的RIP的MAC，具體爲哪個RealServer的RIP，取決於LVS使用的具體算法。其他不作修改。
3.當RealServer收到對應的請求報文時，因爲RealServer會在本機的LO上綁定了VIP的地址，並且會因爲在內核中修改了ARP相關參數從而在同一網絡中同時擁有了與LVS同樣的IP地址，因此在接收到請求報文時會發現報文的目標IP就是自己的VIP，於是就會接收報文並處理後不經過LVS進行響應。響應報文的源IP則爲VIP，目標IP則爲CIP，源MAC地址則爲RS發送數據包的MAC，目標MAC則爲最近的路由MAC。
4.客戶端則會收到響應報文，源IP爲VIP，端口爲80。而LVS相對於客戶端而言，轉換過程是透明的。
優點：負載均衡器也只是分發請求，應答包通過單獨的路由方法返回給客戶端。與LVS-TUN相比，LVS-DR這種實現方式不需要隧道結構，因此可以使用大多數操作系統做爲物理服務器。
缺點：要求負載均衡器的網卡必須與物理網卡在一個物理段上。
因爲VIP在同一網絡中同時存在，必須改變RealServer 對APR報文響應規則
方法1：在RS上使用arptables工具
# arptables -A IN -d $VIP -j DROP
# arptables -A OUT -s $VIP -j mangle --mangle-ip-s $RIP
方法2：在RS上修改內核參數以限制arp通告及應答級別 (推薦)
arp_announce = 2
arp_ignore = 1
LVS-DR的建議：
(1) RealServer的RIP建議使用私網地址。RIP與DIP在同一IP網絡；RIP的網關不能指向DIP，以確保響應報文 不會經過VS
(2) LVS和RS要在同一個物理網絡。不能跨地域物理網絡調度。
(3) 請求報文要經由VS，但響應報文不經由VS，而由RealServer直接發往Client
(4) 不支持端口映射（端口不能修改）
(5) RealServer可使用大多數OS系統
(6) VS可以只要一塊網卡，同時配置VIP和DIP，注意路由走向。
LVS-TUN模式：
轉發方式工作，不修改請求報文的IP首部，而在原IP報文之外再封裝一個IP首部（源IP是DIP，目標IP是RIP），將報文發往挑選出的目標RealServer；RealServer直接響應給客戶端（源IP是VIP，目標IP是CIP）
LVS-TUN報文中IP包頭轉換過程
上圖所示：
1.客戶端的請求會發往LVS主機，此時，客戶端請求報文的源IP爲CIP，目標IP爲LVS的VIP
2.當LVS收到客戶端的請求報文時，會在原請求報文基礎上再封裝一個新的IP包頭，源IP爲本機的DIP，目標IP爲後端某個RealServer的RIP，具體爲哪個RealServer的RIP，取決於LVS使用的具體算法。其他不作修改。
3.當RealServer收到對應的請求報文時，在接收到請求報文時會發現報文的目標IP就是自己的RIP，於是就會接收報文並處理後不經過LVS進行響應。響應報文的源IP則爲VIP，目標IP則爲CIP。
4.客戶端則會收到響應報文，源IP爲VIP，端口爲80。而LVS相對於客戶端而言，轉換過程是透明的。
優點：負載均衡器只負責將請求包分發給物理服務器，而物理服務器將應答包直接發給用戶。所以，負載均衡器能處理很巨大的請求量，這種方式，一臺負載均衡能爲超過100臺的物理服務器服務，負載均衡器不再是系統的瓶頸。
缺點：這種方式需要所有的服務器支持"IP Tunneling"(IP Encapsulation)協議。
LVS-TUN的建議：
(1) DIP, VIP, RIP都應該是公網地址(或具備跨網絡通訊支持)
(2) RS的網關不能指向DIP
(3) 請求報文要經由VS，但響應不能經由VS
(4) 不支持端口映射
(5) RealServer的OS須支持隧道功能。相對DR模式來講，具備跨地域物理網絡調度。
LVS-FULLNAT模式：
轉發工作。通過同時修改請求報文的源IP地址和目標IP地址進行轉發。
LVS-FULLNAT報文中IP包頭轉換過程
上圖所示：
1.客戶端的請求會發往LVS主機，此時，客戶端請求報文的源IP爲CIP，目標IP爲LVS的VIP
2.當LVS收到客戶端的請求報文時，會將源IP修改爲本機的DIP，同時將請求報文中的目標IP修改爲後端某個RealServer的RIP，具體爲哪個RealServer的RIP，取決於LVS使用的具體算法
3.當RealServer收到對應的請求報文時，會發現報文的目標IP就是自己的RIP，於是就會接收報文並 處理後進行響應。響應報文的源IP則爲RIP，目標IP則爲DIP
4.當LVS收到對應的響應報文時，LVS會將響應報文的源IP修改爲VIP，目標IP修改爲CIP，於是響應報文被髮往客戶端。
5.客戶端則會收到響應報文，源IP爲VIP，端口爲80，而LVS相對於客戶端而言，轉換過程是透明的。
LVS-FULLNAT的建議：
(1) VIP是公網地址，RIP和DIP是私網地址，且通常不在同一IP網絡；因此，RIP的網關一般不會 指向DIP
(2) RS收到的請求報文源地址是DIP，因此，只需響應給DIP；但VS還要將其發往Client
(3) 請求和響應報文都經由VS，LVS易於成爲系統瓶頸。但是也能滿足一般需求
(4) 支持端口映射
注意：此類型kernel默認不支持