負載均衡（Load Balance）叢集提供了一種廉價、有效、透明的方法，來擴充網絡裝置和伺服器的負載、帶寬、增加吞吐量、加強網絡資料處理能力、提高網絡的靈活性和可用性。
ü 單台計算機無法承受大規模的并發通路或資料流量了，此時需要搭建負載均衡叢集把流量分攤到多台節點裝置上分别處理，即減少使用者等待響應的時間又提升了使用者體驗；
ü 7*24小時的服務保證，任意一個或多個有限後端節點裝置當機，不能影響整個業務的運作。
n 工作在網絡模型的7層，可以針對http應用做一些分流的政策，比如針對域名、目錄結構，Nginx單憑這點可利用的場合就遠多于LVS了。
n 最新版本的Nginx也支援4層TCP負載，曾經這是LVS比Nginx好的地方。
n Nginx對網絡穩定性的依賴非常小，理論上能ping通就就能進行負載功能，這個也是它的優勢之一，相反LVS對網絡穩定性依賴比較大。
n Nginx安裝和配置比較簡單，測試起來比較友善，它基本能把錯誤用日志列印出來。LVS的配置、測試就要花比較長的時間了，LVS對網絡依賴比較大。
那為什麼要用lvs呢？
ü 簡單一句話，當并發超過了Nginx上限，就可以使用LVS了。
ü 日1000-2000W PV或并發請求1萬以下都可以考慮用Nginx。
ü 大型門戶網站，電商網站需要用到LVS。
LVS是Linux Virtual Server的簡寫，意即Linux虛拟伺服器，是一個虛拟的伺服器叢集系統，可以在UNIX/LINUX平台下實作負載均衡叢集功能。該項目在1998年5月由章文嵩博士組織成立，是中國國内最早出現的自由軟體項目之一。
LVS官網：http://www.linuxvirtualserver.org/index.html
相關中文資料
早在2.2核心時， IPVS就已經以核心更新檔的形式出現。
從2.4.23版本開始，IPVS軟體就合并到Linux核心的常用版本的核心更新檔的集合。
從2.4.24以後IPVS已經成為Linux官方标準核心的一部分。
ü LVS無需安裝
ü 安裝的是管理工具，第一種叫ipvsadm，第二種叫keepalive
ü ipvsadm是通過指令行管理，而keepalive讀取配置檔案管理
ü 後面我們會用Shell腳本實作keepalive的功能
主機名
IP位址
軟體
系統版本
lb03
10.0.0.15
lvs keepalived
CentOS Linux release 7.4.1708
lb04
10.0.0.16
web03
10.0.0.18
tomcat
web04
10.0.0.17
主機說明
web環境說明
安裝管理工具
檢視目前LVS狀态，順便激活LVS核心子產品。
檢視系統的LVS子產品。
配置LVS負載均衡服務（在lb03操作）
步驟1：在eth0網卡綁定VIP位址（ip）
步驟2：清除目前所有LVS規則（-C）
步驟3：設定tcp、tcpfin、udp連結逾時時間（--set）
步驟4：添加虛拟服務（-A），-t指定虛拟服務的IP端口，-s 指定排程算法 排程算法見man ipvsadm， rr wrr 權重輪詢 -p 指定逾時時間
步驟5：将虛拟服務關聯到真實服務上（-a） -r指定真實服務的IP端口 -g LVS的模式 DR模式 -w 指定權重
步驟6：檢視配置結果（-ln）
指令集：
檢查結果：
ipvsadm參數說明：(更多參照 man ipvsadm)
參數
(短格式)
(長格式)
參數說明
-A
--add-service
在核心的虛拟伺服器表中添加一條新的虛拟伺服器記錄。也就是增加一台新的虛拟伺服器。
-E
--edit-service
編輯核心虛拟伺服器表中的一條虛拟伺服器記錄。
-D
--delete-service
删除核心虛拟伺服器表中的一條虛拟伺服器記錄。
-C
--clear
清除核心虛拟伺服器表中的所有記錄。
-R
--restore
恢複虛拟伺服器規則
-S
--save
儲存虛拟伺服器規則，輸出為-R 選項可讀的格式
-a
--add-server
在核心虛拟伺服器表的一條記錄裡添加一條新的真實伺服器記錄。也就是在一個虛拟伺服器中增加一台新的真實伺服器
-e
--edit-server
編輯一條虛拟伺服器記錄中的某條真實伺服器記錄
-d
--delete-server
删除一條虛拟伺服器記錄中的某條真實伺服器記錄
-L|-l
--list
顯示核心虛拟伺服器表
-Z
--zero
虛拟服務表計數器清零（清空目前的連接配接數量等）
-
--set tcp tcpfin udp
設定連接配接逾時值
--start-daemon
啟動同步守護程序。他後面可以是master 或backup，用來說明LVS Router 是master 或是backup。在這個功能上也可以采用keepalived 的VRRP 功能。
--stop-daemon
停止同步守護程序
-h
--help
顯示幫助資訊
-t
--tcp-service service-address [vip:port] or [real-server-ip:port]
說明虛拟伺服器提供的是tcp 的服務
-u
--udp-service service-address [vip:port] or [real-server-ip:port]
說明虛拟伺服器提供的是udp 的服務
-f
--fwmark-service fwmark
說明是經過iptables 标記過的服務類型。
-s
--scheduler scheduler
使用的排程算法，有這樣幾個選項
rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq
預設的排程算法是： wlc
-p
--persistent [timeout]
持久穩固的服務。這個選項的意思是來自同一個客戶的多次請求，将被同一台真實的伺服器處理。timeout 的預設值為300秒。
-M
--netmask netmask
persistent granularity mask
-r
--real-server server-address
真實的伺服器[Real-Server:port]
-g
--gatewaying
指定LVS 的工作模式為直接路由模式（也是LVS 預設的模式）
-i
--ipip
指定LVS 的工作模式為隧道模式
-m
--masquerading
指定LVS 的工作模式為NAT 模式
-w
--weight weight
真實伺服器的權值
--mcast-interface
interface 指定多點傳播的同步接口
-c
--connection
顯示LVS 目前的連接配接 如：ipvsadm -L -c
--timeout
顯示tcp tcpfin udp 的timeout 值 如：ipvsadm -L --timeout
--daemon
顯示同步守護程序狀态
--stats
顯示統計資訊
--rate
顯示速率資訊
--sort
對虛拟伺服器和真實伺服器排序輸出
--numeric -n
輸出IP 位址和端口的數字形式
步驟1：在lo網卡綁定VIP位址（ip）
步驟2：修改核心參數抑制ARP響應
至此LVS叢集配置完畢！
浏覽器通路：
指令行測試：
抓包檢視結果：
arp解析檢視：
術語說明：
DR模式是通過改寫請求封包的目标MAC位址，将請求發給真實伺服器的，而真實伺服器将響應後的處理結果直接傳回給用戶端使用者。
DR技術可極大地提高叢集系統的伸縮性。但要求排程器LB與真實伺服器RS都有一塊實體網卡連在同一實體網段上，即必須在同一區域網路環境。
DR直接路由模式說明：
DR的實作原理和資料包的改變
既然要讓RS能夠處理目标位址為vip的IP包，首先必須要讓RS能接收到這個包。
在lo上配置vip能夠完成接收包并将結果傳回client。
不可以，将VIP設定在eth0網卡上,會影響RS的arp請求,造成整體LVS叢集arp緩存表紊亂，以至于整個負載均衡叢集都不能正常工作。
① arp協定說明
ARP協定,全稱"Address Resolution Protocol",中文名是位址解析協定，使用ARP協定可實作通過IP位址獲得對應主機的實體位址(MAC位址)。
ARP協定要求通信的主機雙方必須在同一個實體網段（即區域網路環境）！
為了提高IP轉換MAC的效率，系統會将解析結果儲存下來，這個結果叫做ARP緩存。
ARP快取記錄是把雙刃劍
a) 主機有了arp緩存表，可以加快ARP的解析速度，減少區域網路内廣播風暴。因為arp是發廣播解析的，頻繁的解析也是消耗帶寬的，尤其是機器多的時候。
b) 正是有了arp緩存表，給惡意黑客帶來了攻擊伺服器主機的風險，這個就是arp欺騙攻擊。
c) 切換路由器，負載均衡器等裝置時，可能會導緻短時網絡中斷。因為所有的用戶端ARP快取記錄沒有更新
②伺服器切換ARP問題
當叢集中一台提供服務的lb01機器當機後，然後VIP會轉移到備機lb02上，但是用戶端的ARP快取記錄的位址解析還是當機的lb01的MAC位址。進而導緻，即使在lb02上添加VIP，也會發生用戶端無法通路的情況。
解決辦法是：當lb01當機，VIP位址遷移到lb02時，需要通過arping指令通知所有網絡内機器更新本地的ARP快取記錄，進而使得客戶機通路時重新廣播擷取MAC位址。
這個是自己開發伺服器高可用腳本及所有高可用軟體必須考慮到的問題。
ARP廣播進行新的位址解析
測試指令
windows檢視arp -a
③arp_announce和arp_ignore詳解
lvs在DR模式下需要關閉arp功能
arp_announce
對網絡接口上，本地IP位址的發出的，ARP回應，作出相應級别的限制:
确定不同程度的限制,宣布對來自本地源IP位址發出Arp請求的接口
數值
含義
0(預設)
在任意網絡接口（eth0,eth1，lo）上的任何本地位址
1
盡量避免不在該網絡接口子網段的本地位址做出arp回應. 當發起ARP請求的源IP位址 是被設定應該經由路由達到此網絡接口的時候很有用.此時會檢查來訪IP是否為所有接口 上的子網段内ip之一.如果改來訪IP不屬于各個網絡接口上的子網段内,那麼将采用級别2的方式來進行處理.
2
對查詢目标使用最适當的本地位址.在此模式下将忽略這個IP資料包的源位址并嘗試 選擇與能與該位址通信的本地位址.首要是選擇所有的網絡接口的子網中外出通路子網中 包含該目标IP位址的本地位址. 如果沒有合适的位址被發現,将選擇目前的發送網絡接口 或其他的有可能接受到該ARP回應的網絡接口來進行發送.
arp_ignore定義
對目标地定義對目标位址為本地IP的ARP詢問不同的應答模式0
0(預設值)
回應任何網絡接口上對任何本地IP位址的arp查詢請求
隻回答目标IP位址是來訪網絡接口本地位址的ARP查詢請求
隻回答目标IP位址是來訪網絡接口本地位址的ARP查詢請求,且來訪IP必須在該網絡接口的子網段内
3
不回應該網絡界面的arp請求，而隻對設定的唯一和連接配接位址做出回應
4-7
保留未使用
8
不回應所有（本地位址）的arp查詢
抑制RS端arp前的廣播情況
抑制RS端arp後廣播情況
通過網絡位址轉換，排程器LB重寫請求封包的目标位址，根據預設的排程算法，将請求分派給後端的真實伺服器，真實伺服器的響應封包處理之後，傳回時必須要通過排程器，經過排程器時封包的源位址被重寫，再傳回給客戶，完成整個負載排程過程。
收費站模式---來去都要經過LB負載均衡器。
NAT方式的實作原理和資料包的改變
LVS-NAT模型的特性
l RS應該使用私有位址，RS的網關必須指向DIP
l DIP和RIP必須在同一個網段内
l 請求和響應封包都需要經過Director Server，高負載場景中，Director Server易成為性能瓶頸
l 支援端口映射
l RS可以使用任意作業系統
l 缺陷：對Director Server壓力會比較大，請求和響應都需經過director server
采用NAT技術時，由于請求和響應的封包都必須經過排程器位址重寫，當客戶請求越來越多時，排程器的處理能力将成為瓶頸，為了解決這個問題，排程器把請求的封包通過IP隧道(相當于ipip或ipsec )轉發至真實伺服器，而真實伺服器将響應處理後直接傳回給用戶端使用者，這樣排程器就隻處理請求的入站封包。由于一般網絡服務應答資料比請求封包大很多，采用 VS/TUN技術後，叢集系統的最大吞吐量可以提高10倍。
VS/TUN工作流程,它的連接配接排程和管理與VS/NAT中的一樣，隻是它的封包轉發方法不同。排程器根據各個伺服器的負載情況，連接配接數多少，動态地選擇一台伺服器，将原請求的封包封裝在另一個IP封包中，再将封裝後的IP封包轉發給選出的真實伺服器；真實伺服器收到封包後，先将收到的封包解封獲得原來目标位址為VIP位址的封包, 伺服器發現VIP位址被配置在本地的IP隧道裝置上(此處要人為配置)，是以就處理這個請求，然後根據路由表将響應封包直接傳回給客戶。
TUN原理和資料包的改變
LVS-Tun模型特性
l RIP、VIP、DIP全是公網位址
l RS的網關不會也不可能指向DIP
l 所有的請求封包經由Director Server，但響應封包必須不能進過Director Server
l 不支援端口映射
l RS的系統必須支援隧道
LVS的DR和NAT模式要求RS和LVS在同一個vlan中，導緻部署成本過高；TUNNEL模式雖然可以跨vlan，但RealServer上需要部署ipip隧道子產品等，網絡拓撲上需要連通外網，較複雜，不易運維。
為了解決上述問題，開發出FULLNAT，該模式和NAT模式的差別是：資料包進入時，除了做DNAT，還做SNAT（使用者ip->内網ip），進而實作LVS-RealServer間可以跨vlan通訊，RealServer隻需要連接配接到内網。
類比地鐵站多個閘機。
a) 輪詢（Round Robin）RR
排程器通過"輪叫"排程算法将外部請求按順序輪流配置設定到叢集中的真實伺服器上，它均等地對待每一台伺服器，而不管伺服器上實際的連接配接數和系統負載。
b) 權重輪叫（Weighted Round Robin）WRR
排程器通過"權重輪叫"排程算法根據真實伺服器的不同處理能力來排程通路請求。這樣可以保證處理能力強的伺服器處理更多的通路流量。排程器可以自動問詢真實伺服器的負載情況，并動态地調整其權值。
c) 最少連結（Least Connections） LC
排程器通過"最少連接配接"排程算法動态地将網絡請求排程到已建立的連結數最少的伺服器上。如果叢集系統的真實伺服器具有相近的系統性能，采用"最小連接配接"排程算法可以較好地均衡負載。
d) 權重最少連結（Weighted Least Connections） Wlc
在叢集系統中的伺服器性能差異較大的情況下，排程器采用"權重最少連結"排程算法優化負載均衡性能，具有較高權值的伺服器将承受較大比例的活動連接配接負載。排程器可以自動問詢真實伺服器的負載情況，并動态地調整其權值。
e) 基于局部性的最少連結（Locality-Based Least Connections） Lblc
"基于局部性的最少連結" 排程算法是針對目标IP位址的負載均衡，目前主要用于Cache叢集系統。該算法根據請求的目标IP位址找出該目标IP位址最近使用的伺服器，若該伺服器 是可用的且沒有超載，将請求發送到該伺服器；若伺服器不存在，或者該伺服器超載且有伺服器處于一半的工作負載，則用"最少連結"的原則選出一個可用的服務 器，将請求發送到該伺服器。
f) 帶複制的基于局部性最少連結（Locality-Based Least Connections with Replication）
"帶複制的基于局部性最少連結"排程算法也是針對目标IP位址的負載均衡，目前主要用于Cache叢集系統。它與LBLC算法的不同之處是它要維護從一個 目标IP位址到一組伺服器的映射，而LBLC算法維護從一個目标IP位址到一台伺服器的映射。該算法根據請求的目标IP位址找出該目标IP位址對應的服務 器組，按"最小連接配接"原則從伺服器組中選出一台伺服器，若伺服器沒有超載，将請求發送到該伺服器，若伺服器超載；則按"最小連接配接"原則從這個叢集中選出一 台伺服器，将該伺服器加入到伺服器組中，将請求發送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，将最忙的伺服器從伺服器組中删除，以降低複制的 程度。
g) 目标位址散列（Destination Hashing） Dh
"目标位址散列"排程算法根據請求的目标IP位址，作為散列鍵（Hash Key）從靜态配置設定的散清單找出對應的伺服器，若該伺服器是可用的且未超載，将請求發送到該伺服器，否則傳回空。
h) 源位址散列（Source Hashing）SH
"源位址散列"排程算法根據請求的源IP位址，作為散列鍵（Hash Key）從靜态配置設定的散清單找出對應的伺服器，若該伺服器是可用的且未超載，将請求發送到該伺服器，否則傳回空。
1. 添加VIP
2. 添加LVS配置
3. 高可用（VIP漂移）
4. web伺服器健康檢查
# 檢查軟體是否安裝
lb03上keepalied配置檔案
lb03 /etc/keepalived/keepalived.conf
lb04的Keepalied配置檔案
lb04 /etc/keepalived/keepalived.conf
keepalived persistence_timeout參數意義 LVS Persistence 參數的作用
http://blog.csdn.net/nimasike/article/details/53911363
注意：web伺服器上的配置為臨時生效，可以将其寫入rc.local檔案，注意檔案的執行權限。
使用curl指令進行測試
至此keepalived+lvs配置完畢
Ø 開發類似keepalived的腳本，早期的辦法，現在不推薦使用。
Ø heartbeat+lvs+ldirectord腳本配置方案，複雜不易控制，不推薦使用
Ø RedHat工具piranha，一個web界面配置LVS。
Ø LVS-DR+keepalived方案，老師推薦最優方案，簡單、易用、高效。
本文出自“慘綠少年”，歡迎轉載，轉載請注明出處！http://blog.znix.top