LVS類型的介紹,調度算法和不同類型的實現

LVS類型介紹,調度算法和不同類型的實現

LVS集羣的組成與特點

Linux虛擬服務器(Linux Virtual ServerLVS),是一個由章文嵩開發的一款自由軟件。利用LVS可以實現高可用的、可伸縮的WebMailCacheMedia等網絡服務,並在此基礎上開發支持龐大用戶數的、可伸縮的、高可用的電子商務應用。LVS1998年發展到現在,已經變得比較成熟,目前廣應用在各種網絡服務和電子商務應用中。LVS具有很好的可伸縮性、可靠性和可管理性,通過LVS要實現的最終目標是:利用Liunx操作系統和LVS集羣軟件可以實現一個高可用、高性能、低成本的服務器應用集羣。

LVS集羣的組成

    利用LVS架設的服務器集羣系統由3個部分組成:最前端的負載均衡(這裏用Load Balancer表示)中間是服務器組層(Server Array表示),底端是數據共享存儲層(用Shared Storage表示)。在用戶看來,整個LVS集羣系統的所有內部應用結構都是透明的,最終用戶只是在使用一個虛擬服務器提供的高性能服務。

LVS的各個組成部分進行詳細介紹。

負載均衡層:位於整個集羣系統的最前端,由一臺或多臺負載調度器(Director Server)組成,LVS核心模版IPVS就安裝在Director Server上,而Director的主要作用類似於一個路由器,它含有爲完成LVS功能所設定的路由表,通過這些路由表把用戶的請求分發給服務器羣組的應用服務器(Real Server)。同時在Director Server上還要安裝對Real Server的監控模塊Ldirectord,此模塊用於監測各個Real Server服務的健康狀況。在Real Server不可用時可以將其從LVS路由表剔除,在恢復時重新加入。

服務器羣組層:由一組實際運行應用服務的機器組成,Real Server可以是Web服務器、Mail服務器、DNS服務器、視頻服務器中的一個或多個,每個Real Server之間通過高速的LAN或分佈在各地的WAN相連接,在實際的應用中,Director Server也可以同時兼任Real Server的角色。 

共享存儲層:是爲了所有的Real Server提供共享存儲空間和內容一致性的存儲區域,一般由磁盤陣列設備組成,爲了提供內容的一致性,一般可以通過NFS網絡文件系統共享數據,但是NFS在繁忙的業務系統中,性能並不是很好,此時可採用集羣文件系統,例如Red Hat

GFS文件系統,Oracle提供的OCFS2文件系統等。

從整個LVS結構可以看出,Diredtor Server是整個LVS的核心,目前,用於Director Server的操作系統只有LinuxFreeBSDLinux2.6內核內置了LVS的各個模塊,不用任何設置就可以支持LVS功能。

對於Real Server,幾乎所有的系統平臺,如LinuxWindowsSolarisAIXBSD系統等都能很好的支持它。

LVS

工作在用戶空間的ipvsadm ,是一個命令行工具,用於管理集羣服務

工作在內核空間的ipvs:工作在netfilter中 INPUT鏈上,根據ipvsadm編寫的規則強行從INPUT鏈上將數據包轉發到後續的real Server

對應的IP

Client IP: CIP

Director Virutal IP: VIP

Director IP: DIP

Real Server IP: RIP

LVS集羣的特點:

1IP負載均衡與負載調度算法

1IP負載均衡技術

負載均衡技術有很多實現方案,有基於DNS域名輪流解析的方法,有基於客戶端調度訪問的方法,有基於應用層系統負載的調度方法,還有基於IP地址的調度方法,在這些負載調度算法中,執行效率最高的IP負載均衡技術。

LVSIP負載均衡技術是通過IPVS模塊來實現的,IPVSLVS集羣系統的核心軟件,它的主要作用是:安裝在Director Server上,同時在Director Server上虛擬出一個IP地址,用戶必須通過這個虛擬IP地址來服務器,這個虛擬IP一般稱爲LVSVIP,即Virtual IP,訪問的請求首先經過VIP到達負載調度器,然後由負載調度器從Real Server列表中選取一個服務器節點響應的請求。 

在用戶的請求到達負載調度器後,調度器如何將請求發送到提供服務的Real Server節點,而Real Server節點如何中返回數據給用戶,是IPVS實現的重點技術,IPVS實現負載均衡的方式有以下幾種,分別是NATDR TUNFULLNAT,下面進行詳細介紹。 

NAT:即 Network Address Translation,也就是網絡地址翻譯技術實現虛擬服務器,當用戶請求到達調度器時,調度器將請求的報文目標地址(即虛擬IP地址)改寫成選定的Real Server地址,同時將報文的目標端口也改寫成Real Server的相應端口,最後將報文請求發送到選定的Real Server。在服務器端得到數據後,Real Server將數據返回給用戶時,需要再次經過負載調度器,將報文件的源地址和源端口改成虛擬IP地址和相應端口,然後把數據發送給用戶,完成整個負載調度過程。

可以看出NAT方式下,用戶的請求和響應報文件都必須經過Director Server地址重寫,當用戶請求越來越多時,調度器的處理能爲將成爲瓶頸。

NAT:

1RSDIP應該使用私有地址,且RS的網關指向DIP

2)請求和響應報文都要經由Director轉發;在極高負載的場景中,Director可能成爲系統瓶頸。

3)支持端口映射

4RS可以使用任意的OS

5RSRIPDirectorDIP必須在同一IP網絡。

NAT實現模型如下:

wKiom1YdFGaB4UUhAAEjwV4BdCM592.jpg

DR:即 Director Routing,也就是用直接路由技術實現虛擬服務器,這種方式的連接調度與前兩種一樣,但它的報文轉發方法又有不同,VS/DR通過改寫請求報文件的目標MAC地址,將請求發送到Real Server,則Real Server將響應直接返回給客戶,要求Director ServerReal Server必須是一塊網卡連在同一個物理網段上。

DR: 

(1)保保證前端路由器將目標IPVIP的請求報文發送給director

解決方法:

靜態綁定

arpiptables

修改RS主機內核的參數(這樣RS只能使用Linux操作系統)

(2)RSRIP可以爲私有地址;但也可以使用公網地址

(3)RSDirector必須在同一個物理網絡中

(4)請求報文經由Director調度,但響應報文一定不能經由Director

(5)不支持端口映射

        (6)RS的網關不能指向DIP

DR的實現模型:

wKiom1YdFbaj2HNBAAESD_c0tmM667.jpg

DR實現過程:

1.在客戶端發送請求報文,源IPCIP,目標IPVIP,經過層層路由,最終到達本地路由,當報文到達路由器時,路由器查看目標IPVIP,就開始在本地發送arp廣播,來查詢本地VIPMAC地址。但是由於在同一物理網絡中,Real ServerDirector都一個VIP,所以爲了實現LVS的負載均衡就必須保證前端路由器將目標IPVIP的請求報文發送給director。實現方法有:

靜態綁定:就是在前端路由上進行arpMAC綁定,將Director上的VIP對應的MAC地址寫到前端路由上的路由表上。

使用arptablesarptables的用法和iptables類似,就是編寫對arp的限制規則。

修改RS主機的內核參數:

2.當數據報根據MAC地址到達Director調度器後,DR類型的LVS會修改請求報的目標MAC地址。源MAC地址爲DIR網卡對應的MAC地址,目標MAC地址爲Real Server上的RIP對應的MAC地址。

3.請求報文最終到達Real Server 上。在剛進入Real Server時經過數據報的拆解,發現數據包的IP地址爲VIP,就會將數據報文交給VIP ,經過VIP和端口對應的套接字,找到對應的程序,最終將數據報交給應用程序。

關鍵的一步來了,realserver怎麼將數據包回覆給客戶端?

1.當VIPRIPDIP位於同一網段中:

首先,在realserver上定義一條特殊路由,目標爲VIP的數據包都從loopback口發出去,於是源地址還是爲VIP,數據包的源和目的地址都沒有變化。但是由於限制了arp的廣播和應答方式,外界並不知道realserver上有VIP的存在,realserver也不知道VIP這個網段中的其它主機,所以數據包就卡在realserver這裏了。但是由於VIPRIP,DIP位於同一網絡中,數據包可以從Realserver直接發往它們的網關,於是路由器接收到數據包後就直接路由轉發給客戶了。

2.當VIPRIPDIP不在同一網段中

首先,在realserver上定義一條特殊路由,目標爲VIP的數據包都從loopback口發出去,於是源地址還是爲VIP,數據包的源和目的地址都沒有變化。但是由於限制了arp的廣播和應答方式,外界並不知道realserver上有VIP的存在,realserver也不知道VIP這個網段中的其它主機,所以數據包就卡在realserver這裏了。解決方法就是,在realserver上添加一條默認路由,不知道的包都發往上私網地址的網關,於是路由器接收到數據包後就直接路由轉發給客戶了,在這個拓撲圖中,路由器鏈接交換機的接口要有2個地址,一個是私網的網關地址,一個是公網的網關地址。

TUN:即IP Tunneling,也就是通過IP隧道技術實現虛擬服務器,這種方式的連接調度和管理與VS/NAT

方式一樣,只是報文轉發方法不同,在VS/TUN方式中,調度器採用IP隧道技術,將用戶請求轉發到某個Real Server,而這個RealServer將直接響應用戶的請求,不再經過請端調度度,此外,對Real Server的地域位置沒有要求,可以和Director Server位於同一網段,也可以獨立的一個網絡中,因此,在TUN方式中,調度器將只處理用戶的報文請求,從而使集羣系統的吞吐量大大提高。 

TUN:不修改請求報文的ip首部,而是通過在原有的ip首部(cip<-->vip)之外,再封裝一個ip首部(dip<-->rip)

TUN

集羣節點可以跨越Internet

RIP必須是公網地址;

director僅負責處理入站請求,響應報文則由realserver直接發往客戶端;

realserver網關不能指向director

只有支持隧道功能的OS才能用於realserver

不支持端口映射;

實現模型:

wKiom1YdFjmg1MnbAAF7dZwJ0As959.jpg

FULLNATdirector通過同時修改請求報文的目標地址和源地址進行轉發;

            (1) VIP是公網地址;RIPDIP是私網地址,二者無須在同一網絡中;

            (2) RS接收到的請求報文的源地址爲DIP,因此要響應給DIP

            (3) 請求報文和響應報文都必須經由Director; 

            (4) 支持端口映射機制;

            (5) RS可以使用任意OS

FullNat實現模型:

wKioL1YdFxzQ9prrAAGofsh-Lb0792.jpg

2)負載調度算法: 

前面介紹過,負載調度器是根據各個服務器的負載情況,動態地選擇一臺RealServer響應用戶請求,那麼動態選擇是如何實現的呢,其實就是通過這裏說的負載調度算法,根據不同的網絡服務需求和服務配置,IPVS實現了8種負載調度算法,這裏細述常用的4種調度算法。 

輪叫算法:(Round Robin) “輪叫”調度也叫11調度,調度器通過“輪叫”調度算法將外部用戶請求按順序號11地分配到集羣中每個Real Server上,這種算法平均地對待每一臺Real Server,而不管服務器上實際的負載狀況和連接狀態。 

加權輪叫調度(Weighted Round Robin) “加權輪叫“調度算法根據Real Server的不同處理能力來調度訪問請求,可以對每臺Real Server設置不同的調度權值,對性能相對較好的Real Server可以設置較高的權值,而對能力較弱的Real Server,可以設置較低的權值,這樣保證了處理能力強的服務器處理更多的訪關問流量,充分合理地利用了服務器資源,同時,調度器還可以自動查詢Real Server的負載情況,並動態地調整其權值。

最少連接調度(least Connection)“最少連接“調度算法動態將網絡請求調度到已建立的連接數最少的服務器,如果集羣系統的真實服務器具有相近的系統性能,採用“最少連接”調度算法可以較好地均衡負載。

活動連接數*256+inactive  誰小,挑誰。

 加權最少連接(Weighted Least Connections) “加權最少連接調度“是”最少連接調度的超集,每個服務節點可以用相應的權值表示其處理能力,而系統管理員可以動態地設置相應的權值,默認值爲1,加權最小連接調度在分配新連接請求時儘可能使服務節點的已建立連接數和其權值成正比。 

活動連接數*256+inactive  /WEITH

Shsource hashing(源地址散列)當一個客戶端發送請求時,Director Serve會把請求發送到real server上進行處理,並且會生成一張哈希表(源地址),來記錄此過程請求和應答的IP。當此客戶端在此請求時,Director server利用此調度算法把請求交給上次處理該請求的reals erver

Dh:distination hashing (目標地址散列)

Sed;最短期望延遲  (active+1)*256/weight

nq: never queue

LBLC: 基於本地的最少連接

LBLCR: 基於本地的帶複製功能的最少連接

默認方法:wlc

LVS集羣的優缺點

LVS是一款自由軟件,任何人都可以免費獲取並使用它,而且Linux也是一個開源操作系統,這二者的組合大大節約了企業的應用成本,同時LVS具有高穩定性和可靠性,在高併發高吞葉量下,具有高負荷處理能力,當某個服務節點出現故障時,並不影響整個系統服務在正常運行,這些優點使LVS已經廣泛在企業、教育行業以及很多知道名網站。 細心的訊都可能發現了,LVS具有上述優點的同時,還將存在一個致命的缺點,從上圖可以清楚的看出,所有的用戶請求都經過Director Server將任務分發到各個服務器節點,那麼,當只有一Direcotr Server時,將會出現單點故障點,如果這個Director Server出現故障時,整個LVS系統將陷入癱瘓狀態。

雖然Director Server僅完成用戶請求的分發處理,負載並不是很大,但是對於一個健狀的集羣系統來說,單點故障是絕對不允許的,要避免這種單點故障,最實用、最簡單的辦法就是對Director Server進行高可以集羣,最常見的方案就是爲Director Server做一個雙機熱備:正常狀態下主Director Server 工作,備用Director Server監控主Director Server的狀態,當主Director Server出現異常或者故障時,備用Director Server馬上接過主Director Server的工作,負責對用戶請求進行分發處理,這樣就避免了臺Director Server的單點故障問題,保證了負載均衡端持續地提供服務。

ipvsadm的用法:

ipvsadm的用法很簡單,類似於iptables的使用方法,在這簡單的介紹一下:

管理集羣服務

ipvsadm -A|E -t|u|f service-address [-s scheduler]

ipvsadm -D -t|u|f service-address

service-address:

tcp: -t ip:port

udp: -u ip:port

fwm: -f mark

-s scheculer:

默認爲wlc

管理集羣服務中的RS

ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m] [-w weight]

ipvsadm -d -t|u|f service-address -r server-address

server-address: 

    ip[:port]

lvs-type:

    -g: gateway, dr

    -i: ipip, tun

    -m: masquerade, nat

清空和查看:

ipvsadm -C

ipvsadm -L|l [options]

    -n: numeric,基於數字格式顯示地址和端口;

    -c: connection,顯示ipvs連接;

    --stats:統計數據

    --rate: 速率

    --exact: 精確值

保存和重載:

   ipvsadm -R

   ipvsadm -S [-n]

置零計數器:

   ipvsadm -Z [-t|u|f service-address]


LVS_NAT類型的實現:

實驗環境:(本實驗是基於對Web服務的負載均衡)

實驗拓撲圖:

wKioL1YdGI7xVgcHAAC4mKNz1nw123.jpg

搭建實驗環境:

        1.在CentOS6虛擬機上實現Director,其中VIPeth0172.16.99.1(橋接模式DIPeth1192.168.20.1(自定義模式)。在Director安裝ipvsadm命令工具。開啓路由轉發功能。

    wKiom1YdGN6TLT0xAABVMiRbr9E384.jpg

安裝ipvsadm ]# yum install ipvsadm

查看內核是否支持LVS

]# grep -i "IPVS" /boot/config-2.6.32-504.el6.x86_64 

# IPVS transport protocol load balancing support

# IPVS scheduler

# IPVS application helper

開啓路由轉發:

1.通過修改配置文件;(永久有效)

vim /etc/sysctl.conf

net.ipv4.ip_forward = 1

2.臨時配置:

    echo 1 > /proc/sys/net/ipv4/ip_forward

2.在兩臺CentOS6虛擬機上安裝web服務,充當Read Server。其中RS1RIP1eth0192.168.20.2(自定義)Gateway爲:192.168.20.1RS2RIP2eth0192.168.20.3(eth0)Gateway爲:192.168.20.1

RS1:

wKiom1YdGVHANX2IAADiYu9HyVk460.jpg

RS2:

wKioL1YdGYXB4UmGAADvJAB4u1o540.jpg

在搭建完實驗環境之後,就可以在Director上執行ipvsadm命令,添加ipvsadm規則,並在兩個RS上開啓Web服務,由於爲了顯示實驗效果,在兩個Web服務器上顯示的頁面內容是不相同的。

ipvsadm規則:

    wKiom1YdGgbjZRy-AADmapMv4QA455.jpg

開啓web服務,進行測試:

        wKioL1YdGnbD9oiEAAFQBVcF4tw590.jpg

        wKiom1YdGljAjj09AACfWasOCdo100.jpg

LVS_DR類型的實現:

lvs_dr類型的實現:VIP DIPRIP在同一網段內

實驗環境:

wKioL1YdJIfRJCd6AAENCZDu19g551.jpg

實驗環境搭建:

Real Server上的配置:

在配置VIP之前要保證前端路由器將目標IPVIP的請求報文發送給director

解決方法:

靜態綁定

arpiptables

修改RS主機內核的參數(這樣RS只能使用Linux操作系統)

linux主機中,IP地址不屬於網卡而是屬於內核,就是說無論一個linux主機有多少個IP地址,它在接入的各個網絡中都會公佈它擁有的所有地址,這就給ARP廣播的響應制造了困難,所以就需要修改內核參數來保證router發出ARP廣播時,DR會響應RS不予響應,這裏所說的內核參數分別爲:

#arp_announce:定義arp通知級別;

0:默認級別,在各個網絡中通告本機所含有的所有地址

1:儘量不在各個網絡中通告本機中含有的不屬於該網絡的地址

2:不在各個網絡中通告本機中含有的不屬於該網絡的地址

#arp_ignore:定義arp忽略arp請求或arp通告的級別;

0(默認值): 迴應任何網絡接口上對任何本地IP地址的arp查詢請求 

1:只回答目標IP地址是來訪網絡接口本地地址的ARP查詢請求 

2:只回答目標IP地址是來訪網絡接口本地地址的ARP查詢請求,且來訪IP必須在該網絡接口的子網段內 

3:不迴應該網絡界面的arp請求,而只對設置的唯一和連接地址做出迴應 

4-7:保留未使用 

8:不迴應所有(本地地址)的arp查詢

real server配置VIP之前先進行內核參數的修改,保證real server 中的VIP不給予ARP響應,也不讓其發送ARP請求廣播。

/proc/sysy/net/ipv4/conf目錄下有以下幾個目錄:all  default  eth0  lo

在每個目錄中都有:arp_ignore arp_announce這兩個文件。更改相對應的值:(修改完之後自己的真實機可能無法訪問realserver)

real server上進行更改:更改之後lo上在配置VIP

    ~]# sysctl -w net.ipv4.conf.eth0.arp_announce=2    
    ~]# sysctl -w net.ipv4.conf.eth0.arp_ignore=1
    ~]# sysctl -w net.ipv4.conf.all.arp_announce=2
    ~]# sysctl -w net.ipv4.conf.all.arp_ignore=1

配置VIP

ifconfig lo:0 172.16.99.20/32 broadcast 172.16.99.20 up

route add -host 172.16.99.20 dev lo:0

wKioL1YdJ5zi_sNCAADIdTUGrbM440.jpg

Director上進行設置:

VIP

    [root@www ~]# ifconfig eth0:0 172.16.99.20/32 broadcast 172.16.99.20 up    
    [root@www ~]# route add -host 172.16.99.20 dev eth0:0

配置好實驗環境之後,在Director上添加ipvsadm規則,在兩臺RS上開啓Web服務進行測試:

        ipvsadm -A -t 172.16.99.20:80 -s rr    
        ipvsadm -a -t 172.16.99.20:80 -r 172.16.99.2 -g
        ipvsadm -a -t 172.16.99.20:80 -r 172.16.99.3 -g

wKiom1YdJ9rhzNNsAAFAgSGntPE657.jpg

 

LVS_DR 的實現:VIPDIPRIP不在同一個網段內:

實驗環境:

wKioL1YdKCzBCytbAAFQqyhztzY292.jpg

實驗環境介紹:

在此實驗中使用了一臺轉發主機,充當路由。各個網段的設置如上圖,其中黑色尖頭表示客戶端的請求報文的流向,而綠色尖頭是響應客戶端請求的流向。

每臺RS中都要配置VIP地址,在lo中定義的VIP地址處封裝報文之後,再由RIP上的網卡接口出去,其中RIP的網關必須指向轉發主機的eth1上的IP

實驗總共準備了5臺虛擬機,其中客戶端Client是測試端,CIP的網關指向轉發主機的eth2上的IP

 

實驗配置:

1.轉發主機/轉發路由的網絡配置和路由:

開啓路由轉發功能:

echo 1 /proc/sys/net/ipv4/ip_forward

2.兩臺web服務器RS上的配置:

RS1上的配置:

a.配置RIP172.16.99.3,其中網關指向172.16.0.1

wKioL1YdKJyDy0idAAFCO3pU_mQ747.jpg

b.配置web服務器:爲了實驗結果加以區別,網頁內容不一樣。

網頁內容爲:

wKiom1YdKQ6T6DiDAABa_3hI86g618.jpg

c.配置VIP

編寫一腳本實現web服務器的VIP相關的設置:

    #!/bin/bash    
    echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce
    echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
    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
    sleep 3
    ifconfig lo:0 192.168.0.100 netmask 255.255.255.255  broadcast 192.168.0.100 up
    route add -host 192.168.0.100 dev lo:0

RS2上配置:

a.配置RIP2:172.16.99.4網關爲172.16.0.1

wKioL1YdKcKAlWc5AAFMT6Tin0M183.jpg

b.網頁內容:

wKioL1YdKx7DyETIAABPtjUgNVo037.jpg

c.配置VIP

wKiom1YdKxDDzX7XAAEH1q3iq-Y287.jpg

1.Director上配置:

配置VIP

wKiom1YdK3Cx9ga2AAEWahkVMNM981.jpg

編寫ipvsadm規則:

    # ipvsadm -A -t 192.168.0.100:80 -s wlc    
    #ipvsadm -a -t 192.168.0.100:80 -r 172.16.99.3 -g -w 2
    #ipvsadm -a -t 192.168.0.100:80 -r 172.16.99.4 -g -w 4

wKiom1YdK5_wOgEvAAHJou28xLg576.jpg

4、測試:

192.168.1.200上進行測試:

        wKioL1YdK-DDnGqYAAGrHL4AKnA188.jpg

        wKiom1YdK8jzeKX8AAM0gFcMSeo676.jpg



 





發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章