1 學習目標
掌握什么是負載均衡及負載均衡的作用和意義。
了解lvs負載均衡的三種模式。
了解lvs-DR負載均衡部署方法。
掌握nginx實現負載均衡的方法。
掌握lvs+nginx負載均衡拓撲結構。
2 負載均衡方案
2.1 什么是負載均衡
一台普通服務器的處理能力是有限的，假如能達到每秒幾萬個到幾十萬個請求，但卻無法在一秒鍾內處理上百萬個甚至更多的請求。但若能將多台這樣的服務器組成一個系統，並通過軟件技術將所有請求平均分配給所有服務器，那么這個系統就完全擁有每秒鍾處理幾百萬個甚至更多請求的能力。這就是負載均衡最初的基本設計思想。
負載均衡是由多台服務器以對稱的方式組成一個服務器集合，每台服務器都具有等價的地位，都可以單獨對外提供服務而無須其他服務器的輔助。通過某種負載分擔技術，將外部發送來的請求按照某種策略分配到服務器集合的某一台服務器上，而接收到請求的服務器獨立地回應客戶的請求。負載均衡解決了大量並發訪問服務問題，其目的就是用最少的投資獲得接近於大型主機的性能。
2.2 相關技術
2.2.1 基於DNS的負載均衡
DNS（Domain Name System，域名系統），因特網上作為域名和IP地址相互映射的一個分布式數據庫，能夠使用戶更方便的訪問互聯網，而不用去記住能夠被機器直接讀取的IP數串。通過主機名，最終得到該主機名對應的IP地址的過程叫做域名解析（或主機名解析）。DNS協議運行在UDP協議之上，使用端口號53。
DNS負載均衡技術是最早的負載均衡解決方案，它是通過DNS服務中的隨機名字解析來實現的，在DNS服務器中，可以為多個不同的地址配置同一個名字，而最終查詢這個名字的客戶機將在解析這個名字時得到其中的一個地址。因此，對於同一個名字，不同的客戶機會得到不同的地址，它們也就訪問不同地址上的Web服務器，從而達到負載均衡的目的。
如下圖：
優點：實現簡單、實施容易、成本低、適用於大多數TCP/IP應用；
缺點：
1、 負載分配不均勻，DNS服務器將Http請求平均地分配到后台的Web服務器上，而不考慮每個Web服務器當前的負載情況；如果后台的Web服務器的配置和處理能力不同，最慢的Web服務器將成為系統的瓶頸，處理能力強的服務器不能充分發揮作用；
2、可靠性低，如果后台的某台Web服務器出現故障，DNS服務器仍然會把DNS請求分配到這台故障服務器上，導致不能響應客戶端。
3、變更生效時間長，如果更改NDS有可能造成相當一部分客戶不能享受Web服務，並且由於DNS緩存的原因，所造成的后果要持續相當長一段時間(一般DNS的刷新周期約為24小時)。
2.2.2 基於四層交換技術的負載均衡
基於四層交換技術的負載均衡是通過報文中的目標地址和端口，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器與請求客戶端建立TCP連接，然后發送Client請求的數據。
如下圖：
client發送請求至4層負載均衡器，4層負載均衡器根據負載策略把client發送的報文目標地址(原來是負載均衡設備的IP地址)修改為后端服務器（可以是web服務器、郵件服務等）IP地址，這樣client就可以直接跟后端服務器建立TCP連接並發送數據。
具有代表意義的產品：LVS（開源軟件），F5（硬件）
優點：性能高、支持各種網絡協議
缺點：對網絡依賴較大，負載智能化方面沒有7層負載好（比如不支持對url個性化負載），F5硬件性能很高但成本也高需要人民幣幾十萬，對於小公司就望而卻步了。
2.2.3 基於七層交換技術的負載均衡
基於七層交換技術的負載均衡也稱內容交換，也就是主要通過報文中的真正有意義的應用層內容，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的服務器。
如下圖：
七層負載均衡服務器起了一個代理服務器的作用，client要訪問webserver要先與七層負載設備進行三次握手后建立TCP連接，把要訪問的報文信息發送給七層負載均衡；然后七層負載均衡再根據設置的均衡規則選擇特定的webserver，然后通過三次握手與此台webserver建立TCP連接，然后webserver把需要的數據發送給七層負載均衡設備，負載均衡設備再把數據發送給client。
具有代表意義的產品：nginx（軟件）、apache（軟件）
優點：對網絡依賴少，負載智能方案多（比如可根據不同的url進行負載）
缺點：網絡協議有限，nginx和apache支持http負載，性能沒有4層負載高
2.3 確定使用四層+七層負載結合方案
四層負載使用lvs軟件或F5硬件實現。
七層負載使用nginx實現。
如下圖是lvs+nginx的拓撲結構：
2.4 nginx集群背景
在keepalived+nginx的主備容災高可用的架構中，nginx是作為外部訪問系統的唯一入口，理論上一台nginx的最大並發量可以高達50000，但是當並發量更大的時候，keepalived+nginx的高可用機制是沒辦法滿足需求的，因為keepalived+nginx的架構中確確實實是一台nginx在工作，只有當master宕機或異常時候，備份機才會上位。那么如何解決更大的高並發問題呢，也許會問能不能搭建nginx集群，直接對外提供訪問？
很顯然這是欠妥當的，因為當nginx作為外部的唯一訪問入口，沒辦法直接以集群的形式對外提供服務，沒有那么多的公網ip資源可用，既太浪費也不友好。但是在內網環境下，是可以用nginx集群（nginx橫向擴展服務集合）的，當然總得有一個對外入口，所以需要在nginx集群之上，在加一層負載均衡器，作為系統的唯一入口。
3 lvs實現四層負載DR模式(了解)
3.1 什么是lvs
LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集群系統。本項目在1998年5月由章文嵩博士成立，是中國國內最早出現的自由軟件項目之一。
3.2 lvs實現負載的三種方式
運行 lPVS軟件的服務器，在整個負載均衡集群中承擔一調度角色 軟件的服務器，（即 向真實服務器分配從客戶端過來的請求。LVS中的調度方法有三種 ：NAT（Network Address Translation網絡地址轉換）、TUN（tunnel 隧道）、DR（direct route 直接路由）
3.2.1 LVS-DR 模式
請求由LVS接受，由真實提供服務的服務器(RealServer, RS)直接返回給用戶，返回的時候不經過LVS。
DR模式下需要LVS服務器和RS綁定同一個VIP， 一個請求過來時，LVS只需要將網絡幀的MAC地址修改為某一台RS的MAC，該包就會被轉發到相應的RS處理，注意此時的源IP和目標IP都沒變，RS收到LVS轉發來的包，發現MAC是自己的，發現IP也是自己的，於是這個包被合法地接受，而當RS返回響應時，只要直接向源IP(即用戶的IP)返回即可，不再經過LVS。
DR模式下，lvs接收請求輸入，將請求轉發給RS，由RS輸出響應給用戶，性能非常高。
它的不足之處是要求負載均衡器與RS在一個物理段上。
3.2.2 LVS-NAT模式
NAT(Network Address Translation)是一種外網和內網地址映射的技術。NAT模式下，LVS需要作為RS的網關，當網絡包到達LVS時，LVS做目標地址轉換(DNAT)，將目標IP改為RS的IP。RS接收到包以后，處理完，返回響應時，源IP是RS IP，目標IP是客戶端的IP，這時RS的包通過網關(LVS)中轉，LVS會做源地址轉換(SNAT)，將包的源地址改為VIP，對於客戶端只知道是LVS直接返回給它的。
NAT模式請求和響應都需要經過lvs，性能沒有DR模式好。
3.2.3 LVS-TUN模式
TUN模式是通過ip隧道技術減輕lvs調度服務器的壓力，許多Internet服務（例如WEB服務器）的請求包很短小，而應答包通常很大，負載均衡器只負責將請求包分發給物理服務器，而物理服務器將應答包直接發給用戶。所以，負載均衡器能處理很巨大的請求量。相比NAT性能要高的多，比DR模式的優點是不限制負載均衡器與RS在一個物理段上。但是它的不足需要所有的服務器（lvs、RS）支持"IP Tunneling"(IP Encapsulation)協議。
3.3 lvs-DR環境
vip：192.168.101.100
lvs-director：192.168.101.8
nginx1：192.168.101.3
nginx2：192.168.101.4
3.4 lvs調度服務器Director安裝
3.4.1 安裝lvs
在192.168.101.8上安裝lvs
centos6.5自帶lvs，檢查linux內核是否集成lvs模塊：
modprobe -l | grep ipvs
3.4.2 安裝lvs的管理工具ipvsadm
- 安裝依賴
yum install -y gcc gcc-c++ makepcre pcre-devel kernel-devel openssl-devel libnl-devel popt*
- 安裝ipvsadm
將ipvsadm-1.26.tar.gz拷貝至/usr/local/下
cd /usr/local tar -zxvf ipvsadm-1.26.tar.gz cd ipvsadm-1.26 make make install
校驗是否安裝成功：
3.5 真實服務器Real Server安裝
在192.168.101.3和192.168.101.4上安裝nginx。
3.5.1 nginx配置文件
創建nginx-lvs.conf，http內容如下：
http { include mime.types; default_type application/octet-stream; sendfile on; server { listen 80; server_name localhost; location / { root html; index index.html index.htm; } }
3.6 Director Server配置
3.6.1 在eth0上綁定虛擬ip
ifconfig eth0:0 192.168.101.100 broadcast 192.168.101.100 netmask 255.255.255.255 up
此處在eth0設備上綁定了一個虛擬設備eth0:0，同時設置了一個虛擬IP是192.168.101.100，然后指定廣播地址也為192.168.101.100，需要特別注意的是，虛擬ip地址的廣播地址是它本身，子網掩碼是255.255.255.255。
3.6.2 添加路由規則
route add -host 192.168.101.100 dev eth0:0
3.6.3 啟用系統的包轉發功能
echo "1" >/proc/sys/net/ipv4/ip_forward
參數值為1時啟用ip轉發，為0時禁止ip轉發。
3.6.4 清除原有轉發規則
ipvsadm --clear
3.6.5 添加虛擬IP規則
ipvsadm -A -t 192.168.101.100:80 -s rr
-s rr表示采用輪詢策略。
:80表示負載轉發的端口是80
3.6.6 在虛擬IP中添加服務規則
ipvsadm -a -t 192.168.101.100:80 -r 192.168.101.3:80 -g ipvsadm -a -t 192.168.101.100:80 -r 192.168.101.4:80 -g
在新加虛擬IP記錄中添加兩條新的Real Server記錄，-g表示指定LVS 的工作模式為直接路由模式。
lvs進行負載轉發需要保證lvs負載的端口要和nginx服務的端口的一致，這里都為80。
3.6.7 重啟lvs
ipvsadm
3.7 Real Server配置
在lvs的DR和TUn模式下，用戶的訪問請求到達真實服務器后，是直接返回給用戶的，而不再經過前端的Director Server，因此，就需要在每個Real server節點上增加虛擬的VIP地址，這樣數據才能直接返回給用戶。
3.7.1 在回環設備上綁定了一個虛擬IP地址
ifconfig lo:0 192.168.101.100 broadcast 192.168.101.100 netmask 255.255.255.255 up /sbin/route add -host 192.168.101.100 dev lo:0
3.7.2 關閉arp解析
arp_announce ：定義不同級別：當ARP請求通過某個端口進來是否利用這個接口來回應。
0 -利用本地的任何地址，不管配置在哪個接口上去響應ARP請求；
1 - 避免使用另外一個接口上的mac地址去響應ARP請求；
2 - 盡可能使用能夠匹配到ARP請求的最佳地址。
arp_ignore：當ARP請求發過來后發現自己正是請求的地址是否響應；
0 - 利用本地的任何地址，不管配置在哪個接口上去響應ARP請求；
1 - 哪個接口上接受ARP請求，就從哪個端口上回應。
echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce sysctl -p #使用修改生效
sysctl -p #使用修改生效
3.8 測試
3.8.1 預期目標
由於lvs設置為rr輪詢策略，當訪問虛IP http://192.168.101.100，每次刷新請求通過lvs負載到不同的服務器。
3.8.2 注意事項
1、測試時需要在nginx的http中設置keepalive_timeout 0; 取消使用http持久連接模式，保證每次客戶端發起請求都需要向服務端建立連接，這樣做是為了每次刷新頁面都要經過lvs負載轉發。
2、lvs進行負載轉發需要保證lvs負載的端口要和nginx服務的端口的一致，這里都為80。
keepalive_timeout說明：
在nginx中keepalive_timeout的默認值是75秒，默認使用http持久連接模式，可使客戶端到服務器端的連接持續有效，當出現對服務器的后繼請求時，可避免建立或重新建立連接。生產環境建議keepalive_timeout不要設置為0。
3.8.3 測試過程
修改192.168.101.3和192.168.101.4下html目錄中index.html的內容使之個性化。
第一次請求：http://192.168.101.100
刷新，相當於第二次請求：
依次交替測試，發現每次請求被負載到不同的nginx上。
任意停止掉一個nginx，請求http://192.168.101.100繼續可以瀏覽，由於lvs采用輪詢策略如果其中一個nginx請求不可到達則去請求另外的nginx。
3.9 腳本封裝
為了方便配置啟動lvs將上邊Director Server和Real Server的配置過程封裝在shell腳本中。
3.9.1 Director Server配置
在/etc/init.d下創建lvsdr，內容如下：
#!/bin/sh # 定義虛擬ip VIP=192.168.101.100 #虛擬 ip根據需求修改 # 定義realserver,並已空格分開，根據需求修改 RIPS="192.168.101.3 192.168.101.4" # 定義提供服務的端口 SERVICE=80 # 調用init.d腳本的標准庫 . /etc/rc.d/init.d/functions case $1 in start) echo "Start LVS of DR Mode" # 開啟ip轉發 echo "1" > /proc/sys/net/ipv4/ip_forward # 綁定虛擬ip ifconfig eth0:0 $VIP broadcast $VIP netmask 255.255.255.255 up route add -host $VIP dev eth0:0 # 清除lvs規則 ipvsadm -C # 添加一條虛擬服務器記錄 # -p指定一定的時間內將相同的客戶端分配到同一台后端服務器 # 用於解決session的問題,測試時或有別的解決方案時建議去掉 ipvsadm -A -t $VIP:$SERVICE -s rr # 添加真實服務器記錄 for RIP in $RIPS do echo $RIP:$SERVICE; ipvsadm -a -t $VIP:$SERVICE -r $RIP:$SERVICE -g done # 設置tcp tcpfin udp的超時連接值 ipvsadm --set 30 120 300 ipvsadm ;; stop) echo "Stop LVS DR" ifconfig eth0:0 down ipvsadm -C ;; *) echo "Usage:$0 {start ¦ stop}" exit 1 esac
修改腳本權限：chmod +x /etc/init.d/lvsdr
啟動Director server：service lvsdr start
停止Director server：service lvsdr stop
3.9.2 Real Server配置
在/etc/init.d下創建lvsdr，內容如下：
#!/bin/sh VIP=192.168.101.100 #虛擬ip，根據需求修改 . /etc/rc.d/init.d/functions case $1 in start) echo "lo:0 port starting" # 為了相應lvs調度器轉發過來的包,需在本地lo接口上綁定vip ifconfig lo:0 $VIP broadcast $VIP netmask 255.255.255.255 up # 限制arp請求 echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore echo "2" > /proc/sys/net/ipv4/conf/all/arp_announce ;; stop) echo "lo:0 port closing" ifconfig lo:0 down echo "0" > /proc/sys/net/ipv4/conf/lo/arp_ignore echo "0" > /proc/sys/net/ipv4/conf/lo/arp_announce echo "0" > /proc/sys/net/ipv4/conf/all/arp_ignore echo "0" > /proc/sys/net/ipv4/conf/all/arp_announce ;; *) echo "Usage: $0 {start ¦ stop}" exit 1 esac
修改腳本權限：chmod +x /etc/init.d/lvsdr
啟動real server：service lvsdr start
停止real server：service lvsdr stop
4 nginx實現七層負載
參考nginx教案。
5 lvs四層+nginx七層負載均衡
5.1 需求
lvs采用DR模式基本上沒有性能瓶頸，用戶請求輸入至lvs經過負載轉發到后台服務上，通過后台服務輸出響應給用戶。nginx的負載性能遠沒有lvs好，lvs四層+nginx七層負載的好處是最前端是lvs接收請求進行負載轉發，由多個nginx共同完成七層負載，這樣nginx的負載性能就可以線性擴展。
5.2 准備環境
vip：192.168.101.100
lvs-director：192.168.101.8
nginx1：192.168.101.3 安裝nginx
nginx2：192.168.101.4 安裝nginx
tomcat1：192.168.101.5 安裝tomcat
tomcat2：192.168.101.6 安裝tomcat
5.3 配置
5.3.1 Director Server配置
vip：192.168.101.100
lvs-director：192.168.101.8
參考lvs四層負載DR模式進行配置
5.3.2 Real Server配置
nginx1：192.168.101.3 安裝nginx
nginx2：192.168.101.4 安裝nginx
參考lvs四層負載DR模式進行配置，需要修改nginx的配置文件使每個nginx對兩個tomcat進行負載，如下：
http { include mime.types; default_type application/octet-stream; sendfile on; upstream tomcat_server_pool{ server 192.168.101.5:8080 weight=10; server 192.168.101.6:8080 weight=10; } server { listen 80; server_name localhost; location / { proxy_pass http://tomcat_server_pool; index index.jsp index.html index.htm; } } }
5.4 測試
請求http://192.168.101.100，lvs負載到不同的nginx上，如果停止任意一台nginx或停止任意一台tomcat不影響訪問。
6 lvs高可用(了解)
6.1 什么是高可用
lvs作為負載均衡器，所有請求都先到達lvs，可見lvs處於非常重要的位置，如果lvs服務器宕機后端web服務將無法提供服務，影響嚴重。
為了屏蔽負載均衡服務器的宕機，需要建立一個備份機。主服務器和備份機上都運行高可用（High Availability）監控程序，通過傳送諸如“I am alive”這樣的信息來監控對方的運行狀況。當備份機不能在一定的時間內收到這樣的信息時，它就接管主服務器的服務IP並繼續提供負載均衡服務；當備份管理器又從主管理器收到“I am alive”這樣的信息時，它就釋放服務IP地址，這樣的主服務器就開始再次提供負載均衡服務。
6.2 keepalived+lvs實現主備
6.2.1 什么是keepalived
keepalived是集群管理中保證集群高可用的一個服務軟件，用來防止單點故障。
Keepalived的作用是檢測web服務器的狀態，如果有一台web服務器死機，或工作出現故障，Keepalived將檢測到，並將有故障的web服務器從系統中剔除，當web服務器工作正常后Keepalived自動將web服務器加入到服務器群中，這些工作全部自動完成，不需要人工干涉，需要人工做的只是修復故障的web服務器。
6.2.2 keepalived工作原理
keepalived是以VRRP協議為實現基礎的，VRRP全稱Virtual Router Redundancy Protocol，即虛擬路由冗余協議。
虛擬路由冗余協議，可以認為是實現路由器高可用的協議，即將N台提供相同功能的路由器組成一個路由器組，這個組里面有一個master和多個backup，master上面有一個對外提供服務的vip（該路由器所在局域網內其他機器的默認路由為該vip），master會發組播，當backup收不到VRRP包時就認為master宕掉了，這時就需要根據VRRP的優先級來選舉一個backup當master。這樣的話就可以保證路由器的高可用了。
keepalived主要有三個模塊，分別是core、check和VRRP。core模塊為keepalived的核心，負責主進程的啟動、維護以及全局配置文件的加載和解析。check負責健康檢查，包括常見的各種檢查方式。VRRP模塊是來實現VRRP協議的。
詳細參考：Keepalived權威指南中文.pdf
6.2.3 keepalived+lvs實現主備過程
6.2.3.1 初始狀態
6.2.3.2 主機宕機
6.2.3.3 主機恢復
6.2.4 准備環境
vip：192.168.101.100
lvs-director：192.168.101.8 主lvs
lvs-director：192.168.101.9 備lvs
nginx1：192.168.101.3 安裝nginx
nginx2：192.168.101.4 安裝nginx
tomcat1：192.168.101.5 安裝tomcat
tomcat2：192.168.101.6 安裝tomcat
6.2.5 安裝keepalived
分別在主備lvs上安裝keepalived，參考“安裝手冊”進行安裝：
6.2.6 配置keepalived
6.2.6.1 主lvs
修改主lvs下/etc/keepalived/keepalived.conf文件
! Configuration File for keepalived global_defs { notification_email { #xxxx@itcast.com # 發生故障時發送的郵箱 } #notification_email_from xxxx@itcast.com # 使用哪個郵箱發送 #smtp_server xxx.com # 發件服務器 smtp_connect_timeout 30 router_id LVS_DEVEL } vrrp_instance VI_1 { state MASTER # 標示為主lvs interface eth0 # HA檢測端口 virtual_router_id 51 # 主備的virtual_router_id 必須相同 priority 100 # 優先級,備lvs要比主lvs稍小 advert_int 1 # VRRP Multicast 廣播周期秒數 authentication { # 定義認證 auth_type PASS # 認證方式為口令認證 auth_pass 1111 # 定義口令 } virtual_ipaddress { # 定義vip 192.168.101.100 # 多個vip可換行添加 } } virtual_server 192.168.101.100 80 { delay_loop 6 # 每隔6秒查看realserver狀態 lb_algo wlc # 調度算法為加權最小連接數 lb_kind DR # lvs工作模式為DR(直接路由)模式 nat_mask 255.255.255.0 persistence_timeout 50 # 同一IP 的連接50秒內被分配到同一台realserver(測試時建議改為0) protocol TCP # 用TCP監測realserver的狀態 real_server 192.168.101.3 80 { # 定義realserver weight 3 # 定義權重 TCP_CHECK { # 注意TCP_CHECK和{之間的空格,如果沒有的話只會添加第一個realserver connect_timeout 3 # 三秒無響應超時 nb_get_retry 3 delay_before_retry 3 connect_port 80 } } real_server 192.168.101.4 80 { weight 3 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 connect_port 80 } } }
6.2.6.2 備lvs
修改備lvs下/etc/keepalived/keepalived.conf文件
配置備lvs時需要注意：需要修改state為BACKUP , priority比MASTER低，virtual_router_id和master的值一致
! Configuration File for keepalived global_defs { notification_email { #xxxx@itcast.com # 發生故障時發送的郵箱 } #notification_email_from xxxx@itcast.com # 使用哪個郵箱發送 #smtp_server xxx.com # 發件服務器 smtp_connect_timeout 30 router_id LVS_DEVEL } vrrp_instance VI_1 { state BACKUP # 標示為備lvs interface eth0 # HA檢測端口 virtual_router_id 51 # 主備的virtual_router_id 必須相同 priority 99 # 優先級,備lvs要比主lvs稍小 advert_int 1 # VRRP Multicast 廣播周期秒數 authentication { # 定義認證 auth_type PASS # 認證方式為口令認證 auth_pass 1111 # 定義口令 } virtual_ipaddress { # 定義vip 192.168.101.100 # 多個vip可換行添加 } } virtual_server 192.168.101.100 80 { delay_loop 6 # 每隔6秒查看realserver狀態 lb_algo wlc # 調度算法為加權最小連接數 lb_kind DR # lvs工作模式為DR(直接路由)模式 nat_mask 255.255.255.0 persistence_timeout 50 # 同一IP 的連接50秒內被分配到同一台realserver(測試時建議改為0) protocol TCP # 用TCP監測realserver的狀態 real_server 192.168.101.3 80 { # 定義realserver weight 3 # 定義權重 TCP_CHECK { # 注意TCP_CHECK和{之間的空格,如果沒有的話只會添加第一個realserver connect_timeout 3 # 三秒無響應超時 nb_get_retry 3 delay_before_retry 3 connect_port 80 } } real_server 192.168.101.4 80 { weight 3 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 connect_port 80 } } }
6.2.7 測試
6.2.7.1 啟動
- director Server啟動：
注意：使用keepalived就不用手動配置啟動lvs，在主、備lvs上啟動keepalived即可。
主備lvs（192.168.101.8、192.168.101.9）都啟動keepalived。
service keepalived start
- real server啟動：
192.168.101.3、192.168.101.4啟動nginx和lvs的realserver配置
cd /usr/local/nginx/sbin ./nginx -c /usr/local/nginx/conf/nginx-lvs.conf
啟動lvs的realserver配置：
service lvsdr start
注意：real server的lvs配置需要使用lvsdr腳本。
- tomcat 啟動
略
6.2.7.2 初始狀態
查看主lvs的eth0設置：
vip綁定在主lvs的eth0上。
查詢lvs狀態：
查看備lvs的eth0設置：
vip沒有綁定在備lvs的eth0上。
訪問http://192.168.101.100，可以正常負載。
6.2.7.3 主機宕機
將主lvs的keepalived停止或將主lvs關機(相當於模擬宕機)，查看主lvs的eth0：
eth0沒有綁定vip
查看備lvs的eth0：
vip已經漂移到備lvs。
訪問http://192.168.101.100，可以正常負載。
6.2.7.4 主機恢復
將主lvs的keepalived啟動。
查看主lvs的eth0：
查看備lvs的eth0：
vip漂移到主lvs。
查看備lvs的eth0：
eth0沒有綁定vip
訪問http://192.168.101.100，可以正常負載。
6.3 keepalived+lvs實現雙主
上邊主備方案是當前只有一台lvs工作，這造成資源浪費，可以采用雙主結構，讓兩台lvs當前都進行工作，采用dns輪詢方式，當用戶訪問域名通過dns輪詢每台lvs，雙主結構需要兩個vip，這兩個vip要綁定域名。
同樣，在每台lvs上安裝keepalived軟件，當keepalived檢測到其中一個lvs宕機則將宕機的vip漂移到活動lvs上，當lvs恢復則vip又重新漂移回來。
6.3.1.1 初始狀態
每台lvs綁定一個vip，共兩個vip，DNS設置域名對應這兩個vip，通過DNS輪詢每次解析到不同的vip上即解析到不同的lvs上。
6.3.1.2 其中一個主機宕機
其中一個主機宕機，每台lvs上安裝的keepalived程序會檢測到對方宕機，將宕機一方的vip漂移至活動的lvs服務器上，這樣DNS輪詢全部到一台lvs繼續對外提供服務。
6.3.1.3 主機恢復
當主機恢復又回到初始狀態，每個vip綁定在不同的lvs上。
6.4 lvs擴展的思考
前端使用1到2台lvs作為負載基本可以滿足中小型網站的並發要求，當lvs的負載成為瓶頸此時就需要對lvs進行優化、擴展。
- 方案1：LVS-ospf集群
OSPF(Open Shortest Path First開放式最短路徑優先）是一個內部網關協議(Interior Gateway Protocol，簡稱IGP），用於在單一自治系統（autonomous system,AS）內決策路由。
LVS（DR）通過ospfd，做lvs集群，實現一個VIP，多台LVS同時工作提供服務，這種方案需要依賴三層交換機設備實現。
用戶請求（VIP：42.xx.xx.100）到達三層交換機之后，通過對原地址、端口和目的地址、端口的hash，將鏈接分配到集群中的某一台LVS上，LVS通過內網（10.101.10.x）向后端轉發請求，后端再將數據返回給用戶。
LVS-ospf集群模式的最大優勢就在於：
1.LVS調度機自由伸縮，橫向線性擴展（最大8台，受限於三層設備允許的等價路由數目maximum load-balancing）；
2.LVS機器同時工作，不存在備機，提高利用率；
3.做到了真正的高可用，某台LVS機器宕機后，不會影響服務
- 方案2：DNS輪詢
上面講的是一組雙主結構，可以采用多組雙主結構達到橫向擴展lvs的目的，此方案需要每台lvs都綁定一個vip（公網ip），DNS設置域名輪詢多個vip，如下圖：
- 方案3：使用硬件負載均衡設置
如果資金允許可以購買硬件設置來完成負載均衡，性能不錯的有F5、Array等都可以滿足超高並發的要求。