只在虛擬機局域網下進行過測試，在服務器上我個人理解應該是把VIP設置成調度器的公網IP這樣才能解析，就是不知道對不對，也沒幾臺服務器供我測試一下。。
VS/NAT： 網絡地址轉換模式， 進站/出站的數據流量經過分發器（調度器）
1、由於NAT模式下，進出數據都在調度器進行，因此支持後端真實服務器數量較少
2、調度（Dip）和Vip需要工作在不同的網絡中
3、所有的真實服務器的網關地址必須指向Dip
4、調度器需要雙網卡，啓用路由轉發功能
下面是虛擬機實驗步驟：
調度器：192.168.26.130
nginx1:192.168.26.129
nginx2:192.168.26.128
首先是調度器操作：
1.在網卡上添加一個IP
# ip addr add dev ens33 192.168.1.100/24（或添加一張物理網卡爲橋接模式）
2.開啓路由轉發
# vim /etc/sysctl.conf
net.ipv4.ip_forward = 1
# sysctl -p
臨時開啓
# echo 1 > /proc/sys/net/ipv4/ip_forward
3.安裝ipvsadm並定義分發策略
# yum -y install ipvsadm
# ipvsadm -C //清除所有規則
# ipvsadm -A -t 192.168.1.100:80 -s rr
-A 添加一個調度器
-s 指定調度算法 (rr是輪叫調度，調度算法的筆記在最後)
-a 向某個調度器添加一個真實服務器
-t TCP協議傳輸
-m 使用LVS-NAT模式
-r 真實服務器
# ipvsadm -a -t 192.168.1.100:80 -r 192.168.26.128 -m
# ipvsadm -a -t 192.168.1.100:80 -r 192.168.26.129 -m
然後是後方真實web服務器的配置，必須指定網關爲調度器的IP
1.安裝nginx
.....
2.添加網關
# route add default gw 192.168.26.130
如果沒有route命令就安裝一下
# yum install net-tools
做負載均衡兩臺配置肯定是一樣的了，我這裏隨便區分了下，然後使用和調度器VIP同一網段的客戶端訪問
# ipvsadm -L -n --stats
1. Conns (connections scheduled) 已經轉發過的連接數
2. InPkts (incoming packets) 入包個數
3. OutPkts (outgoing packets) 出包個數
4. InBytes (incoming bytes) 入流量（字節）
5. OutBytes (outgoing bytes) 出流量（字節)
以上爲LVS的NAT模式簡單測試。
VS/NAT模式的原理是：當調度器收到Client請求時，調度器將數據包的目標IP由VIP轉換爲選中的Real Server的RIP來實現分發，要求RS將網關指 向調度器的DIP。
特點是：配置簡單，所有的入站、出站數據包都經過分發器。當數據量比較大時，分發器可能會出現網絡瓶頸！因而支持的RS數量少。
VS/DR： 直接路由模式，只有進站的數據流量經過分發器
調度器和真實服務器必須在同一網段
VS/DR模式的原理是： 當一個client發送一個請求到VIP，調度器根據VIP，在後端真實服務器中選擇一臺Real-server，然後將client的請求包發給選擇的Real-server，最後選擇的Real-server把應答包直接傳給client。
特點：解決了lvs-NAT模式下調度器瓶頸問題。
以下爲實驗操作步驟：
調度器：192.168.26.130
nginx1:192.168.26.129
nginx2:192.168.26.128
兩臺RS服務器：
# ip addr add dev lo 192.168.26.123/32
//在lo接口上綁定VIP
# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
//non-arp：避免出現IP衝突
# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
//RS以適當IP傳輸數據（讓RS用VIP回覆數據）
因爲LVS和real server都配置了VIP，client或者網關設備都可能arp學到LVS和real server的mac，也就會發生IP衝突，且無法實現負載均衡功能。爲了避免這種情況發生，可通過內核參數arp_ignore和arp_announce的配置，只允許LVS應答VIP的arp請求，抑制real server應答VIP的arp請求和發送免費arp。（抑制ARP還可使用arptables）
nginx的配置過程就略過了，隨便改點加以區分就行
調度器操作：
# ip addr add dev lo 192.168.26.123/32
# yum -y install ipvsadm
# ipvsadm -C
# ipvsadm -A -t 192.168.26.123:80 -s rr
# ipvsadm -a -t 192.168.26.123:80 -r 192.168.26.129 -g
# ipvsadm -a -t 192.168.26.123:80 -r 192.168.26.128 -g
# ipvsadm -Ln
LVS調度算法：
調度算法用於決定LVS如何選擇後端的RealServer
1. 輪叫調度（Round Robin）(簡稱rr)
調度器通過“輪叫”調度算法將外部請求按順序輪流分配到集羣中的真實服務器上，它均等地對待每一臺服務器，而不管服務器上實際的連接數和系統負載。
2. 加權輪叫（Weighted Round Robin）（簡稱wrr)
調度器通過“加權輪叫”調度算法根據真實服務器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的服務器能處理更多的訪問流量。調度器可以自動問詢真實服務器的負載情況，並動態地調整其權值。
3. 最少鏈接（Least Connections）(LC)
調度器通過“最少連接”調度算法動態地將網絡請求調度到已建立的鏈接數最少的服務器上。如果集羣系統的真實服務器具有相近的系統性能，採用 “最小連接” 調度算法可以較好地均衡負載。
4.加權最少鏈接（Weighted Least Connections）(WLC)
在集羣系統中的服務器性能差異較大的情況下，調度器採用“加權最少鏈接”調度算法優化負載均衡性能，具有較高權值的服務器將承受較大比例的活動連接負
載。調度器可以自動問詢真實服務器的負載情況，並動態地調整其權值。
LVS的默認調度算法。
5. 基於局部性的最少鏈接（Locality-Based Least Connections）(LBLC)
“基於局部性的最少鏈接”調度算法是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。該算法根據請求的目標IP地址找出該目標IP地址最近使用的
服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於一半的工作負載，則用“最少鏈接”
的原則選出一個可用的服務器，將請求發送到該服務器。
6. 帶複製的基於局部性最少鏈接（Locality-Based Least Connections with Replication）(LBLCR)
“帶複製的基於局部性最少鏈接”調度算法也是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。它與LBLC算法的不同之處是它要維護從一個目標
IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。該算法根據請求的目標IP地址找出該目標IP地址對應的服務器組，按
“最小連接”原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載，則按“最小連接”原則從這個集羣中選出一臺
服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低復
制的程度。
7. 目標地址散列（Destination Hashing）(DH)
“目標地址散列”調度算法根據請求的目標IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
8. 源地址散列（Source Hashing）(SH)
“源地址散列”調度算法根據請求的源IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
9. 最短的期望的延遲（Shortest Expected Delay Scheduling SED）(SED)
基於wlc算法。這個必須舉例來說了
ABC三臺機器分別權重123 ，連接數也分別是123。那麼如果使用WLC算法的話一個新請求進入時它可能會分給ABC中的任意一個。使用sed算法後會進行這樣一個運算
A(1+1)/1
B(1+2)/2
C(1+3)/3
根據運算結果，把連接交給C。
10.最少隊列調度（Never Queue Scheduling NQ）(NQ)
無需隊列。如果有臺 realserver的連接數＝0就直接分配過去，不需要在進行sed運算