掌握什麼是負載均衡及負載均衡的做用和意義。html
瞭解lvs負載均衡的三種模式。前端
瞭解lvs-DR負載均衡部署方法。linux
掌握nginx實現負載均衡的方法。nginx
掌握lvs+nginx負載均衡拓撲結構。c++
一臺普通服務器的處理能力是有限的,假如能達到每秒幾萬個到幾十萬個請求,但卻沒法在一秒鐘內處理上百萬個甚至更多的請求。但若能將多臺這樣的服務器組成一個系統,並經過軟件技術將全部請求平均分配給全部服務器,那麼這個系統就徹底擁有每秒鐘處理幾百萬個甚至更多請求的能力。這就是負載均衡最初的基本設計思想。web
負載均衡是由多臺服務器以對稱的方式組成一個服務器集合,每臺服務器都具備等價的地位,均可以單獨對外提供服務而無須其餘服務器的輔助。經過某種負載分擔技術,將外部發送來的請求按照某種策略分配到服務器集合的某一臺服務器上,而接收到請求的服務器獨立地迴應客戶的請求。負載均衡解決了大量併發訪問服務問題,其目的就是用最少的投資得到接近於大型主機的性能。 算法
DNS(Domain Name System,域名系統),因特網上做爲域名和IP地址相互映射的一個分佈式數據庫,可以使用戶更方便的訪問互聯網,而不用去記住可以被機器直接讀取的IP數串。經過主機名,最終獲得該主機名對應的IP地址的過程叫作域名解析(或主機名解析)。DNS協議運行在UDP協議之上,使用端口號53。shell
DNS負載均衡技術是最先的負載均衡解決方案,它是經過DNS服務中的隨機名字解析來實現的,在DNS服務器中,能夠爲多個不一樣的地址配置同一個名字,而最終查詢這個名字的客戶機將在解析這個名字時獲得其中的一個地址。所以,對於同一個名字,不一樣的客戶機會獲得不一樣的地址,它們也就訪問不一樣地址上的Web服務器,從而達到負載均衡的目的。數據庫
以下圖:apache
優勢:實現簡單、實施容易、成本低、適用於大多數TCP/IP應用;
缺點:
一、 負載分配不均勻,DNS服務器將Http請求平均地分配到後臺的Web服務器上,而不考慮每一個Web服務器當前的負載狀況;若是後臺的Web服務器的配置和處理能力不一樣,最慢的Web服務器將成爲系統的瓶頸,處理能力強的服務器不能充分發揮做用;
二、可靠性低,若是後臺的某臺Web服務器出現故障,DNS服務器仍然會把DNS請求分配到這臺故障服務器上,致使不能響應客戶端。
三、變動生效時間長,若是更改NDS有可能形成至關一部分客戶不能享受Web服務,而且因爲DNS緩存的緣由,所形成的後果要持續至關長一段時間(通常DNS的刷新週期約爲24小時)。
基於四層交換技術的負載均衡是經過報文中的目標地址和端口,再加上負載均衡設備設置的服務器選擇方式,決定最終選擇的內部服務器與請求客戶端創建TCP鏈接,而後發送Client請求的數據。
以下圖:
client發送請求至4層負載均衡器,4層負載均衡器根據負載策略把client發送的報文目標地址(原來是負載均衡設備的IP地址)修改成後端服務器(能夠是web服務器、郵件服務等)IP地址,這樣client就能夠直接跟後端服務器創建TCP鏈接併發送數據。
具備表明意義的產品:LVS(開源軟件),F5(硬件)
優勢:性能高、支持各類網絡協議
缺點:對網絡依賴較大,負載智能化方面沒有7層負載好(好比不支持對url個性化負載),F5硬件性能很高但成本也高須要人民幣幾十萬,對於小公司就望而卻步了。
基於七層交換技術的負載均衡也稱內容交換,也就是主要經過報文中的真正有意義的應用層內容,再加上負載均衡設備設置的服務器選擇方式,決定最終選擇的服務器。
以下圖:
七層負載均衡服務器起了一個代理服務器的做用,client要訪問webserver要先與七層負載設備進行三次握手後創建TCP鏈接,把要訪問的報文信息發送給七層負載均衡;而後七層負載均衡再根據設置的均衡規則選擇特定的webserver,而後經過三次握手與此臺webserver創建TCP鏈接,而後webserver把須要的數據發送給七層負載均衡設備,負載均衡設備再把數據發送給client。
具備表明意義的產品:nginx(軟件)、apache(軟件)
優勢:對網絡依賴少,負載智能方案多(好比可根據不一樣的url進行負載)
缺點:網絡協議有限,nginx和apache支持http負載,性能沒有4層負載高
四層負載使用lvs軟件或F5硬件實現。
七層負載使用nginx實現。
以下圖是lvs+nginx的拓撲結構:
在keepalived+nginx的主備容災高可用的架構中,nginx是做爲外部訪問系統的惟一入口,理論上一臺nginx的最大併發量能夠高達50000,可是當併發量更大的時候,keepalived+nginx的高可用機制是沒辦法知足需求的,由於keepalived+nginx的架構中確確實實是一臺nginx在工做,只有當master宕機或異常時候,備份機纔會上位。那麼如何解決更大的高併發問題呢,也許會問能不能搭建nginx集羣,直接對外提供訪問?
很顯然這是欠穩當的,由於當nginx做爲外部的惟一訪問入口,沒辦法直接以集羣的形式對外提供服務,沒有那麼多的公網ip資源可用,既太浪費也不友好。可是在內網環境下,是能夠用nginx集羣(nginx橫向擴展服務集合)的,固然總得有一個對外入口,因此須要在nginx集羣之上,在加一層負載均衡器,做爲系統的惟一入口。
LVS是Linux Virtual Server的簡寫,意即Linux虛擬服務器,是一個虛擬的服務器集羣系統。本項目在1998年5月由章文嵩博士成立,是中國國內最先出現的自由軟件項目之一。
運行 lPVS軟件的服務器,在整個負載均衡集羣中承擔一調度角色 軟件的服務器,(即 向真實服務器分配從客戶端過來的請求。LVS中的調度方法有三種 :NAT(Network Address Translation網絡地址轉換)、TUN(tunnel 隧道)、DR(direct route 直接路由)
請求由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在一個物理段上。
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模式好。
TUN模式是經過ip隧道技術減輕lvs調度服務器的壓力,許多Internet服務(例如WEB服務器)的請求包很短小,而應答包一般很大,負載均衡器只負責將請求包分發給物理服務器,而物理服務器將應答包直接發給用戶。因此,負載均衡器能處理很巨大的請求量。相比NAT性能要高的多,比DR模式的優勢是不限制負載均衡器與RS在一個物理段上。可是它的不足須要全部的服務器(lvs、RS)支持"IP Tunneling"(IP Encapsulation)協議。
vip:192.168.101.100
lvs-director:192.168.101.8
nginx1:192.168.101.3
nginx2:192.168.101.4
在192.168.101.8上安裝lvs
centos6.5自帶lvs,檢查linux內核是否集成lvs模塊:
modprobe -l | grep ipvs
yum install -y gcc gcc-c++ makepcre pcre-devel kernel-devel openssl-devel libnl-devel popt*
將ipvsadm-1.26.tar.gz拷貝至/usr/local/下
cd /usr/local tar -zxvf ipvsadm-1.26.tar.gz cd ipvsadm-1.26 make make install
校驗是否安裝成功:
在192.168.101.3和192.168.101.4上安裝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; } }
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。
route add -host 192.168.101.100 dev eth0:0
echo "1" >/proc/sys/net/ipv4/ip_forward
參數值爲1時啓用ip轉發,爲0時禁止ip轉發。
ipvsadm --clear
ipvsadm -A -t 192.168.101.100:80 -s rr
-s rr表示採用輪詢策略。
:80表示負載轉發的端口是80
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。
ipvsadm
在lvs的DR和TUn模式下,用戶的訪問請求到達真實服務器後,是直接返回給用戶的,而再也不通過前端的Director Server,所以,就須要在每一個Real server節點上增長虛擬的VIP地址,這樣數據才能直接返回給用戶。
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
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 #使用修改生效
因爲lvs設置爲rr輪詢策略,當訪問虛IP http://192.168.101.100,每次刷新請求經過lvs負載到不一樣的服務器。
一、測試時須要在nginx的http中設置keepalive_timeout 0; 取消使用http持久鏈接模式,保證每次客戶端發起請求都須要向服務端創建鏈接,這樣作是爲了每次刷新頁面都要通過lvs負載轉發。
二、lvs進行負載轉發須要保證lvs負載的端口要和nginx服務的端口的一致,這裏都爲80。
keepalive_timeout說明:
在nginx中keepalive_timeout的默認值是75秒,默認使用http持久鏈接模式,可以使客戶端到服務器端的鏈接持續有效,當出現對服務器的後繼請求時,可避免創建或從新創建鏈接。生產環境建議keepalive_timeout不要設置爲0。
修改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。
爲了方便配置啓動lvs將上邊Director Server和Real Server的配置過程封裝在shell腳本中。
在/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
在/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
參考nginx教案。
lvs採用DR模式基本上沒有性能瓶頸,用戶請求輸入至lvs通過負載轉發到後臺服務上,經過後臺服務輸出響應給用戶。nginx的負載性能遠沒有lvs好,lvs四層+nginx七層負載的好處是最前端是lvs接收請求進行負載轉發,由多個nginx共同完成七層負載,這樣nginx的負載性能就能夠線性擴展。
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
vip:192.168.101.100
lvs-director:192.168.101.8
參考lvs四層負載DR模式進行配置
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; } } }
請求http://192.168.101.100,lvs負載到不一樣的nginx上,若是中止任意一臺nginx或中止任意一臺tomcat不影響訪問。
lvs做爲負載均衡器,全部請求都先到達lvs,可見lvs處於很是重要的位置,若是lvs服務器宕機後端web服務將沒法提供服務,影響嚴重。
爲了屏蔽負載均衡服務器的宕機,須要創建一個備份機。主服務器和備份機上都運行高可用(High Availability)監控程序,經過傳送諸如「I am alive」這樣的信息來監控對方的運行情況。當備份機不能在必定的時間內收到這樣的信息時,它就接管主服務器的服務IP並繼續提供負載均衡服務;當備份管理器又從主管理器收到「I am alive」這樣的信息時,它就釋放服務IP地址,這樣的主服務器就開始再次提供負載均衡服務。
keepalived是集羣管理中保證集羣高可用的一個服務軟件,用來防止單點故障。
Keepalived的做用是檢測web服務器的狀態,若是有一臺web服務器死機,或工做出現故障,Keepalived將檢測到,並將有故障的web服務器從系統中剔除,當web服務器工做正常後Keepalived自動將web服務器加入到服務器羣中,這些工做所有自動完成,不須要人工干涉,須要人工作的只是修復故障的web服務器。
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
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
分別在主備lvs上安裝keepalived,參考「安裝手冊」進行安裝:
修改主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 } } }
修改備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 } } }
注意:使用keepalived就不用手動配置啓動lvs,在主、備lvs上啓動keepalived便可。
主備lvs(192.168.101.八、192.168.101.9)都啓動keepalived。
service keepalived start
192.168.101.三、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腳本。
略
查看主lvs的eth0設置:
vip綁定在主lvs的eth0上。
查詢lvs狀態:
查看備lvs的eth0設置:
vip沒有綁定在備lvs的eth0上。
訪問http://192.168.101.100,能夠正常負載。
將主lvs的keepalived中止或將主lvs關機(至關於模擬宕機),查看主lvs的eth0:
eth0沒有綁定vip
查看備lvs的eth0:
vip已經漂移到備lvs。
訪問http://192.168.101.100,能夠正常負載。
將主lvs的keepalived啓動。
查看主lvs的eth0:
查看備lvs的eth0:
vip漂移到主lvs。
查看備lvs的eth0:
eth0沒有綁定vip
訪問http://192.168.101.100,能夠正常負載。
上邊主備方案是當前只有一臺lvs工做,這形成資源浪費,能夠採用雙主結構,讓兩臺lvs當前都進行工做,採用dns輪詢方式,當用戶訪問域名經過dns輪詢每臺lvs,雙主結構須要兩個vip,這兩個vip要綁定域名。
一樣,在每臺lvs上安裝keepalived軟件,當keepalived檢測到其中一個lvs宕機則將宕機的vip漂移到活動lvs上,當lvs恢復則vip又從新漂移回來。
每臺lvs綁定一個vip,共兩個vip,DNS設置域名對應這兩個vip,經過DNS輪詢每次解析到不一樣的vip上即解析到不一樣的lvs上。
其中一個主機宕機,每臺lvs上安裝的keepalived程序會檢測到對方宕機,將宕機一方的vip漂移至活動的lvs服務器上,這樣DNS輪詢所有到一臺lvs繼續對外提供服務。
當主機恢復又回到初始狀態,每一個vip綁定在不一樣的lvs上。
前端使用1到2臺lvs做爲負載基本能夠知足中小型網站的併發要求,當lvs的負載成爲瓶頸此時就須要對lvs進行優化、擴展。
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機器宕機後,不會影響服務
上面講的是一組雙主結構,能夠採用多組雙主結構達到橫向擴展lvs的目的,此方案須要每臺lvs都綁定一個vip(公網ip),DNS設置域名輪詢多個vip,以下圖:
若是資金容許能夠購買硬件設置來完成負載均衡,性能不錯的有F五、Array等均可以知足超高併發的要求。