LVS：Linux Virtual Server
所謂虛擬的服務就是，當客戶端請求服務時，將服務在前端調度器上，通過一定方式負載到後端多臺服務器上，但對於客戶端來說是不可見的，像在訪問同一臺服務器一樣，這就是虛擬的意思
原理
ipvs：使用LVS服務時，在linux內核當中的一個過濾框架，作用在Input鏈上，通過解析用戶請求的ip和端口號，判斷是否是集羣服務（若較老的版本內核中沒有內置則需自行編譯安裝）
當用戶請求到達，進入調度器內核空間，由於請求的是本地地址，轉發到Input鏈，通過請求的ip和端口，判斷請求的服務是否是集羣服務，若不是則根據端口號進入用戶空間訪問本地服務，是的話將請求報文在Input鏈上進行處理，轉發到FORWARD鏈，最後到達POSTROUTING鏈，轉發到相應的後端服務節點
所以LVS和iptables不能同時使用
ipvsadm：是LVS在用戶空間對集羣服務進行管理的工具
調度算法實現負載
Scheduler Method（調度方法）：當客戶端請求到達時，調度器以什麼標準選擇後端較爲合適的服務器節點進行請求分發
兩種類型調度
靜態調度：不考慮後臺服務器的連接負載情況
rr（Round Robin ）：輪詢
wrr：weight 加權輪詢，在輪詢之前，計算各服務器權重的比例，再進行調度
sh：source hash 源地址哈希：記錄客戶端的哈希和對應服務器，下次來自同一主機的請求將根據之前的記錄，分配相同的服務器節點處理
cookie和session：客戶端第一次發起訪問時，服務端發送cookie給客戶端，客戶端保存cookie，之後每次請求都會附加cookie信息，服務端以此對客戶端進行標識，並在服務器端的內存內部保存有用戶瀏覽的記錄、url等信息，這就是session
session share：服務集羣后端服務節點間session 共享（通過網絡，或同步到共享存儲當中），這樣的話客戶端的瀏覽記錄等信息就實現了共享，即使客戶請求被分配到不同的節點，即使服務器節點故障，瀏覽信息是同步的。若是session shared，則不需要這種調度算法，當服務器發生故障，session share也是很好的預防措施
dh：destination hash 目標地址哈希（針對緩存服務器，第一次請求獲得的緩存可能其他的緩存服務器沒有緩存，請求同樣的內容時，分配到相同的緩存服務器，無需再次緩存）
動態調度
lc：最少連接
比較後端realserver的 active*256+inactive，挑選值小的發送請求
wlc：加權最少連接（lpvs默認）
比較後端realserver的 （active*256+inactive）/ 權重，挑選值小的發送請求
sed：shortest expect delay 最短期望延遲
（active+1）*256/ weight
nq：never queue 永不排隊
在sed基礎上第一次無論如何每臺服務器都發送一次請求
LBLC：Locality-Based lc 基於本地最少連接
考慮 cache 連接數，但相同的請求儘可能發送給同一個緩存服務器，相當於動態的 dh
LBLCR：LBLC with Replication Scheduling 帶緩存複製功能
LBLC會考慮最小連接數，但還是會對相同用戶請求分發到相同後端緩存服務器，而LBLCR直接對後端的緩存服務器動態調度，並且緩存共享（指部分共享，當請求的緩存服務器沒有緩存時，而另外的服務器有，則同步請求的緩存內容）
LVS三種模式：
NAT：地址轉換
DR：直接路由
TUN：隧道模型
NAT模型
實現原理：客戶端發起請求，請求到達Director負載均衡器後，根據調度算法，選擇適當的後端服務節點進行請求分發，Director再利用返回結果對客戶端做出響應，實現負載均衡
規則：
集羣節點跟director必須在同個網絡中
RIP通常是私有地址，僅用於集羣節點間通信
director處於client和Realserver之間，負責處理進出的所有通信
realserver必須將網關指向DIP
以下爲一個簡單的實驗和注意的點
1：地址規劃
2：安裝ipvsadm
3：查看是否支持ipvs內核功能
4：注意Director和Realserver間的時間同步
5：注意ipvsadm和iptables的使用不可以共存，因爲使用的都是netfilter框架的過濾機制
6：地址配置：
Direct兩個網卡分別面向內網和外部網絡，虛擬機模式下，內部網絡應使用host-only模式
Realserver網關因指向Direct的內網地址
7：開始配置lvs（使用rr輪詢調度）
-t使用tcp協議的集羣，-s指定調度算法，-r指定realserver，-m指定爲nat模型
8：查看配置
9：測試
RS1網頁內容爲：This is Realserver1
RS2網頁內容爲：This is Realserver2
從結果看出已實現輪詢調度功能
若外部主機測試不成功，可能是網卡轉發功能沒有啓動
10：查看連接狀態
11：修改調度算法爲（wrr加權輪詢，並驗證）
效果
DR模型
首先，DR模型相對於NAT模型的好處在於Director只接收請求並轉發給 Real server，不響應請求，大大增強性能
實現原理：Director和Realserver都配有VIP地址和自身的網卡地址，客戶端發起請求，ip報頭的源目地址爲CIP和VIP，Direct接收到報文後，發現請求的是集羣服務，將不改變ip以上的報文數據，源目地址還是CIP和VIP，直接將MAC地址改爲Direct MAC和RS MAC，將報文轉發給Realserver，Realserver收到報文後，接收請求，生成響應報文，並直接做出響應
流程：
爲了實現以上的解決方案，需要解決以下兩個問題
1：Director和Realserver都配有VIP地址，若同個網絡中有很多個相同的ip地址，將會造成ARP混亂，而我們只需要通告Director的VIP即可
利用arp的通告響應級別機制
arp_announce
級別0：默認級別，本地任何接口地址全部通告
級別1：儘可能不通告和對方網絡地址不相同的地址
級別2：不通告和對方網絡地址不相同的地址，如：本地的eth0和lo口配的是不同的地址，lo口的地址將不會通告到eth0接口連接的網絡中
arp_ignore
級別0：默認級別，本地有的，都給予響應
級別1：只有在請求的地址配置在請求到達的接口上時纔給予響應
可以將VIP設置在Realserver的Lookback口，不做通告和響應
同時Director的VIP可設置在eth0:0上，正常的回覆arp請求
或者若對出口路由有控制權的時候，對於VIP直接指靜態路由到Director即可
2：Realserver收到報文後，做出響應，此時源目ip爲VIP和CIP，報文如何到達Client
一般情況下，CIP爲公網ip，是網絡上客戶端的ip，VIP也爲公網ip，當RIP和VIP不在同一個網段中時，爲了讓響應報文正常發送，須將Realserver的網關指向出口設備（可能是運營商設備），RIP可以是私網地址，也可以是公網地址
規則
各集羣節點和director必須在同一個物理網絡中
RIP可以使用公網地址，實現便捷的網絡管理
director只接收請求，通過real直接響應客戶請求
不支持端口映射
要求能隱藏 vip 的操作系統作爲realserver
能比nat模型支持更多的節點
實驗（利用內部網絡做簡單模擬，出口路由設備非運營商設備的情況下）
實驗規劃：
1：按照規劃先配好地址，實驗環境下地址都應爲橋接模式
2：Realserver應先配置arp的響應級別再配置Lo口的VIP地址，還要設置
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
ifconfig lo:0 192.168.199.133 netmask 255.255.255.255 broadcast 192.168.199.133 up #廣播地址爲VIP地址，指網絡中只有本身一個地址
route add -host 192.168.199.133 dev lo:0 #默認路由表示在當請求的是192.168.199.133這個VIP地址時，進行響應時應該通過lo:0出去，即響應時的ip爲VIP而不是eth0的ip
3：在Director上的配置
ifconfig eth0:0 192.168.199.133 netmask 255.255.255.255 broadcast 192.168.199.133 up
router add -host 192.168.199.133 dev lo:0
