模式和限制
DR
RealServer感知客戶端真實ip，和LVS有相同的VIP（loopback上配置VIP），直接返回響應給客戶端，性能最好。
限制：RS必須和LVS在同一個子網中，不能跨vlan，因為必須二層可達。
NAT
RS感知客戶端ip，與LVS沒有相同的VIP，需要經過LVS代理才能將響應發給客戶端。
限制：LVS必須做為RS的網關，確保RS的響應包能夠經過LVS，然后LVS才能將源地址改為VIP，客戶端從而能夠接收。即，LVS和RS在同一個子網中。
DR和NAT模式下，LVS和RS都必須在同一個vlan中。
FULLNAT
RS不知道客戶端ip（阿里通過修改內核協議棧，使用TOA方式（將客戶端ip放到tcp的option中）將客戶端ip傳到RS，從而讓RS能夠獲得客戶端ip），與LVS沒有相同的VIP，需要經過LVS代理才能將響應發給客戶端。
限制：FULLNAT模式下，不要求RS和LVS在同一個vlan中。因為lvs與RS之間的通信只要3層可達即可，中間可以經過3層路由。
lvs和RS都要使用非主線的linux內核。
存在的問題
1，性能
單機lvs：
? ? ? ? ? LVS是基于內核netfilter開發的一個應用程序，而netfilter是運行在內核協議棧的一個鉤子框架。這就意味著當數據包到達LVS時，已經經過了一段很長的協議棧處理，但是這段處理對于LVS來說都不是必需的（只需要轉發包即可，無需解析整個協議），這也造成了一部分不必要的性能損耗。
? ? ? ? ? ?中斷是影響LVS性能最重要的一個因素。在單核cpu上，假如我們一秒需要處理600萬的數據包，每6個數據包產生一個硬件中斷的話，那一秒就會產生100萬個硬件中斷，每一次產生硬件中斷都會打斷正在進行密集計算的負載均衡程序，中間產生大量的cache miss，對性能的影響異常大。多核cpu上，需要將處理網卡中斷程序和負載均衡程序綁定到不同的核上。
使用主備模式的lvs集群：支持流量有限，容易成為瓶頸。
2，可用性
lvs通常使用keepalived來實現主備模式容災，有以下缺點：
a、主備模式利用率低。一個集群同時只有一半的服務器在工作，另外一半的機器處于冷備狀態，主節點不可用之后的切換速度相對較慢。
b、keepalived依賴的VRRP協議存在腦裂(split-brain)的風險，需引入第三方仲裁節點，在金融領域、跨園區容災領域備受挑戰。
lvs的進化
1，性能
性能上面，并沒有明顯的優化空間
2，可用性
采用lvs集群，加入以下可用性配置：
a，ospf+ecmp模式，核心交換機進入的數據均勻分布到各個lvs節點
b，lvs節點間必須定期進行session同步，解決節點上下線時會話遷移保持可用
