簡介：
linux虛拟伺服器(linux virtual server.
lvs),是一個由章文松開發的自由軟體.利用kvs可以實作高可用的、可伸縮縮的web, mail, cache和medial等網絡股務..井在此基
礎上開發支援龐大使用者數的，可伸縮的，高可用的電子商務應用。lvs1998年發展到現在，已經變得比較成熟，目前廣泛應用在各種網絡服務和電了商務應用
中.
lvs具有很好的伸縮縮性、可靠性和管埋性，通過lvs要實作的最終目标是：利用linux
作業系統和lvs叢集軟體實作一個高可用、高性能，低成本的伺服器應用叢集。
lvs叢集的組成
利用lvs架設的伺服器群系統由3個部分組成：最前端的是負栽均衡層（這裡用
lo ad balancer表示），中間是伺服器叢集層(用server array表示).
lvs體系結構如下圖所示：
下面對lvs的各個組成部分進行詳細介紹
負 栽均衡層：位于整個叢集系統的最前端，由一台或多台負栽排程器（dircctm
server)組成.lvs核心子產品ipvs就安裝在director
server上，而director的主要作用類似于一個路由器，它含有為完成lvs功能所設定的路由表，通過這些路由表把使用者的請求分發給伺服器群組層
的應用伺服器(real server)。同時，在director server上還要安裝隊real
server的監控子產品ldirectord，此子產品用于監測各個real server 服務的健康狀況。在real server
不可同時可以講其從lvs路由表中剔除，在恢複時重新加入。
伺服器群組層：由一組實際運作應用服務的機器組成，real
server可以是web伺服器、mail伺服器、ftp伺服器、dns伺服器、視頰伺服器中的一個或多個，每個real
server之間通過高速的lan或分布在各地的wan相連接配接:實際的應用中， director server也可以同時兼任real
server的角色
共字存儲層是為所有real
server提供共亨存儲空問和内容一緻性的存儲區域，一般由磁盤陣列裝置組成。為了提俱内容的一緻性，一般可以通過nfs網絡義件系統共
亨資料，但是nfs在繁忙的業務系統中，性能并不是很好，此時可以采用叢集檔案 系統，例如red
hat的gfs檔案系統，oracle提供的os2檔案系統等。
從整個lvs結構可以看出，director
server是整個lvs的核心。目前，用幹director server 的作業系統隻有linux和freebsd, linux
2.6核心完全内置了lvs的各個子產品，不用任何 設定就可以支援lvs功能。
對丁 real.server,幾乎所有的系統平台，如 linux、..
windows、solaris、aix、bsd 系列等都能很好地支援它
lvs叢集的特點
1. ip
負載均衡與負載排程
1負栽均衡技術有很多實作方案，有基于dns.域名輪流解析的方法，有基于用戶端排程通路的方法，還有基于應用層系統負栽的排程方法，還有基于p位址的排程方法。在這些負栽
排程算法中，執行效率最卨的是ip負栽均衡技術。
lvs的ip負栽均衡技術是通過ipvs子產品來實作的。ipvs是lvs叢集系統的核心軟體，
它的主要作用是:安裝在director server上，同時在director server ..上虛拟出一個ip位址，
使用者必須通過這個虛拟的ip位址通路伺服器，這個虛拟ip —般稱為lvs的vip,即virtual ip
通路的請求首先經過vip到達負栽排程器，然後由負栽排程器從real server清單中選取
一個服務節點響應使用者的請求。
在使用者的清求到達負栽排程器後，排程器如何将請求發送到提供服務的real server節 點，而real
server節點如何傳回資料給使用者，是ipvs實作的重點技術。ipvs實作負栽均 衡的方式有4種.分别是nat|full
nat、tun和dr。下面進行詳細介紹。
ipvs/nat
：即 virtual server via network address
translation,也就是網絡位址翻譯技術實作虛拟伺服器。當使用者請求到達排程器時，排程器将請求封包的目标位址（即 虛拟ip位址）改寫成標明的real
server位址，同時将封包的目标端口也改成標明的 real server的相應端口，最後将封包請求發送到標明的real
server。在伺服器端得到資料後，real
server将資料傳回給使用者時，需要再次經過負栽排程器将封包的源位址和源端口改成虛拟ip位址和相應端口,然後把資料發送給使用者，完成整個負栽排程過
程。可以看出，在nat方式下，使用者請求和響應封包都必須經過director server位址重寫， 當使用者請求越來越多時，排程器的處理能力将成為瓶頸.
如下圖所示：ipvs/nat 架構圖
nat：多目标的dnat
特性：
rs應該使用私有位址；
rs的網關必須指向dip；
rip和dip必須在同一網段内；
請求和響應的封包都得經過director；（在高負載應用場景中，director很可能成為系統性能瓶頸）
支援端口映射；
rs可以使用任意支援叢集服務的os(如windows)
适用場景：
非高并發請求場景，10個rs以内；可隐藏内部的dip和rip位址；
結構圖:
lvs/tun
：即virtual server via ip
tunneling,也就是通過ip隧道技術實作虛拟伺服器。這種方式的連接配接排程度和管理與vs/nat方式一樣，隻是封包轉發方法不同。在
vs/tun方式中，排程器采用ip隧道技術将使用者清求轉發到某個real server,而這 個real server
将直接響應使用者的請求，不再經過前端排程器。此外，對real server 的地域位置沒有要求，可以和director
server位于同一個網段，也可以在獨立的一個 網絡中。是以，在tun方式中，排程器将隻處理使用者的封包請求，進而使叢集系統
的吞吐量大大提高。如下圖所示vs/tun 架構圖：
tun：ip隧道，即含有多個ip報頭
rip、dip、vip都得是公網位址；
rs的網關不會指向也不可能指向dip；
請求封包經過director，但響應封包一定不經過director；
不支援端口映射；
rs的作業系統必須得支援隧道功能，即部署ipip子產品
跨網際網路的請求轉發
結構圖：
fullnat是一種新的轉發模式
– 主要思想：引入local
address（内網ip位址），cip-vip轉
換為lip->rip，而
lip和rip均為idc内網ip，可以跨vlan通
訊；fullnat：nat模型的改進版
實作rs間跨vlan通信，是nat模式的改進版；
預設核心不支援，需重新編譯核心，才能使用；
内網伺服器跨vlan的負載分擔
lvs/dr：
即virtual server via direct routing,也就是用直接路由技術實作虛拟伺服器。
這種方式的連按排程和管理與前兩種一樣，但它的封包轉發方法又有所不同，vs/dr 通過改寫請求封包的mac位址，将請求發送到real server,而real
server将響應直接傳回給客戶.免去了vs/tun中的ip隧道開銷，這種方式是3種負莪排程方式中 性能最好的，但是要求director
server與real server必須由一塊網卡連在同一實體網段上。
如下圖所示：vs/dr 架構圖
dr：direct
routing
需解決的關鍵問題：
讓前端路由将請求發往vip時，隻能是director上的vip進行響應；實作方式是修改rs上的linux核心參數，将rs上的vip配置為lo接口的别名，并限制linux僅對對應接口的arp請求做響應
rs可以使用私有位址，但也可以使用公網位址，此時可以直接通過網際網路連入rs以實作配置，監控等；
rs的網關一定不能指向dip；
rs和director要在同一實體網絡(即不能由路由器分隔)
請求封包經過director，但響應封包一定不進過director；
rs可以使用大多數的作業系統
因為響應封包不經過director，極大的減輕了director的負載壓力，故director可以支援更大的并發通路，一般rs在100台以内；
lvs-dr配置架構根據其vip與rip是否在同一個網段内又分為兩種模型:
lvs排程算法
(2)負我排程算法
靜态方法：僅根據算法本身進行排程
動态方法：根據算法及rs目前的負載情況
前 面介紹過，負載排程器是根據各個伺服器的負栽情況，動态地選擇一台real server響
應使用者請求。那麼動态選擇是如何實作呢？其實就是通過這裡要說的負栽排程算法。根據不同的網絡眼務需求和眼務器配ipvs實作t8種負栽排程算法。這裡詳
細講述最常用的4 種排程算法。
1、 輪詢（round robin, rr),權重輪詢(weighted round robin,
wrr)——新的連接配接請求被輪流配置設定至各realserver；算法的優點是其簡潔性，它無需記錄目前所有連接配接的狀态，是以它是一種無狀态排程。輪叫排程
算法假設所有伺服器處理性能均相同，不管伺服器的目前連接配接數和響應速度。該算法相對簡單，不适用于伺服器組中處理性能不一的情況，而且當請求服務時間變化
比較大時，輪叫排程算法容易導緻伺服器間的負載不平衡。
2、 最少連接配接(least connected, lc)， 權重最少連接配接(weighted least connection,
wlc)——新的連接配接請求将被配置設定至目前連接配接數最少的realserver；最小連接配接排程是一種動态排程算法，它通過伺服器目前所活躍的連接配接數來估計服務
器的負載情況。排程器需要記錄各個伺服器已建立連接配接的數目，當一個請求被排程到某台伺服器，其連接配接數加1；當連接配接中止或逾時，其連接配接數減一。
3、 基于局部性的最少連結排程（locality-based least connections
scheduling，lblc）——針對請求封包的目标ip位址的負載均衡排程，目前主要用于cache叢集系統，因為在cache叢集中客戶請求封包
的目标ip位址是變化的。這裡假設任何後端伺服器都可以處理任一請求，算法的設計目标是在伺服器的負載基本平衡情況下，将相同目标ip位址的請求排程到同
一台伺服器，來提高各台伺服器的通路局部性和主存cache命中率，進而整個叢集系統的處理能力。lblc排程算法先根據請求的目标ip位址找出該目标
ip位址最近使用的伺服器，若該伺服器是可用的且沒有超載，将請求發送到該伺服器；若伺服器不存在，或者該伺服器超載且有伺服器處于其一半的工作負載，則
用“最少連結”的原則選出一個可用的伺服器，将請求發送到該伺服器。
4、 帶複制的基于局部性最少連結排程（locality-based least connections with
replication
scheduling，lblcr）——也是針對目标ip位址的負載均衡，目前主要用于cache叢集系統。它與lblc算法的不同之處是它要維護從一個
目标ip位址到一組伺服器的映射，而 lblc算法維護從一個目标ip位址到一台伺服器的映射。對于一個“熱門”站點的服務請求，一台cache
伺服器可能會忙不過來處理這些請求。這時，lblc排程算法會從所有的cache伺服器中按“最小連接配接”原則選出一台cache伺服器，映射該“熱門”站
點到這台cache伺服器，很快這台cache伺服器也會超載，就會重複上述過程選出新的cache伺服器。這樣，可能會導緻該“熱門”站點的映像會出現
在所有的cache伺服器上，降低了cache伺服器的使用效率。lblcr排程算法将“熱門”站點映射到一組cache伺服器（伺服器集合），當該“熱
門”站點的請求負載增加時，會增加集合裡的cache伺服器，來處理不斷增長的負載；當該“熱門”站點的請求負載降低時，會減少集合裡的cache伺服器
數目。這樣，該“熱門”站點的映像不太可能出現在所有的cache伺服器上，進而提供cache叢集系統的使用效率。lblcr算法先根據請求的目标ip
位址找出該目标ip位址對應的伺服器組；按“最小連接配接”原則從該伺服器組中選出一台伺服器，若伺服器沒有超載，将請求發送到該伺服器；若伺服器超載；則按
“最小連接配接”原則從整個叢集中選出一台伺服器，将該伺服器加入到伺服器組中，将請求發送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，将最忙的服
務器從伺服器組中删除，以降低複制的程度。
5、 目标位址散列排程（destination
hashing，dh）算法也是針對目标ip位址的負載均衡，但它是一種靜态映射算法，通過一個散列（hash）函數将一個目标ip位址映射到一台服務
器。目标位址散列排程算法先根據請求的目标ip位址，作為散列鍵（hash
key）從靜态配置設定的散清單找出對應的伺服器，若該伺服器是可用的且未超載，将請求發送到該伺服器，否則傳回空。
6、 源位址散列排程（source
hashing，sh）算法正好與目标位址散列排程算法相反，它根據請求的源ip位址，作為散列鍵（hash
key）從靜态配置設定的散清單找出對應的伺服器，若該伺服器是可用的且未超載，将請求發送到該伺服器，否則傳回空。它采用的散列函數與目标位址散列排程算法
的相同。除了将請求的目标ip位址換成請求的源ip位址外，它的算法流程與目标位址散列排程算法的基本相似。在實際應用中，源位址散列排程和目标位址散列
排程可以結合使用在防火牆叢集中，它們可以保證整個系統的唯一出入口。
7、權重最少連接配接排程（weighted least connections)。
“加
權最少連接配接排程”是“最少連接配接排程”的超集。每個服務節點可以用相應的權值表示其處理能力，而系統管理者可以動态地設定相應的權值，預設權值為1。權重最 小連接配接調
度在分新連接配接請求時盡可能使服務節點的已建立連接配接數和其權值成正比。算法： overhead=active*256+inactive/weight
overhead最小值勝出；
8、sed：shorttest expect delay 最小期望延遲(改進的wlc)
算法：overhead=(active+1)*256/weight，案例：假如dfg三台機器分别權重123，連接配接數也分别是123.那麼如果使用wlc算法的話一個新請求進入時它可能會分給dfg中的任意一個。使用sed算法後會進行這樣一個運算：
d(1+1)/1
f(1+2)/2
g(1+3)/3
9、nq：nerver queue
增強改進的sed算法.如果有台real
server的連接配接數=0直接配置設定,不需要再進行sed運算
2.高可用性
lvs是一個基于核心級别的應用軟體，是以具有很髙的處理性能。由lvs建構的負載
均衡叢集系統具有優秀的處理能力，每個服務節點的故障不會影響整個系統的正常使用，又能夠實作負載的合理均衡，使應用具有超高負荷的服務能力，可支援上百
萬個并發連接配接請 求。如配置百兆網卡，采用vs/tun或vs/dr排程技術，整個叢集系統的吞吐量可高達 1
gbit/s；又如配置千兆網卡，系統的最大吞吐量可接近10gbit/s。
3.高可靠性
lvs負載均衡叢集軟體已經在
企業和學校中得到了很好的普及，國内外很多大型的、關鍵性的web站點也都采用了 lvs叢集軟體，是以它的可靠性在實踐中得到了很好印證。有
很多由lvs構成的負載均衡系統，運作很長時間，從未進行過重新啟動。這些都說明了 lvs 的髙穩定性和高可靠性。
4、配置lvs
1、定義在director上進行dispatching的服務(service)，以及哪此伺服器(server)用來提供此服務；
2、為每台同時提供某一種服務的伺服器定義其權重（即概據伺服器性能确定的其承擔負載的能力）；
注：權重用整數來表示，有時候也可以将其設定為atomic_t；其有效表示值範圍為24bit整數空間，即（2^24-1）；
是以，ipvsadm指令的主要作用表現在以下方面：
1、添加服務（通過設定其權重>0）；
2、關閉服務（通過設定其權重>0）；此應用場景中，已經連接配接的使用者将可以繼續使用此服務，直到其退出或逾時；新的連接配接請求将被拒絕；
3、儲存ipvs設定，通過使用“ipvsadm-sav
> ipvsadm.sav”指令實作；
4、恢複ipvs設定，通過使用“ipvsadm-sav <
ipvsadm.sav”指令實作；
5、顯示ip_vs的版本号，下面的指令顯示ipvs的hash表的大小為4k；
#
ipvsadm
ip virtual server version 1.2.1
(size=4096)
6、顯示ipvsadm的版本号
# ipvsadm --version
ipvsadm
v1.24 2003/06/07 (compiled with popt and ipvs
v1.2.0)
二、ipvsadm使用中應注意的問題
默
認情況下，ipvsadm在輸出主機資訊時使用其主機名而非ip位址，是以，director需要使用名稱解析服務。如果沒有設定名稱解析服務、服務不可
用或設定錯誤，ipvsadm将會一直等到名稱解析逾時後才傳回。當然，ipvsadm需要解析的名稱僅限于realserver，考慮到dns提供名稱
解析服務效率不高的情況，建議将所有realserver的名稱解析通過/etc/hosts檔案來實作；
三、排程算法
director在接收到來自于client的請求時，會基于"schedule"從realserver中選擇一個響應給client。ipvs支援以下排程算法：
四、關于lvs追蹤标記fwmark：
如果lvs放置于多防火牆的網絡中，并且每個防火牆都用到了狀态追蹤的機制，那麼在回應一個針對于lvs的連接配接請求時必須經過此請求連接配接進來時的防火牆，否則，這個響應的資料包将會被丢棄。
常用指令：
檢視lvs上目前的所有連接配接
# ipvsadm -lcn
或者
#cat
/proc/net/ip_vs_conn
檢視虛拟服務和realserver上目前的連接配接數、資料包數和位元組數的統計值，則可以使用下面的指令實作：
#
ipvsadm -l --stats
檢視包傳遞速率的近似精确值，可以使用下面的指令：
# ipvsadm -l
--rate
vs/nat
lvs-
nat基于cisco的localdirector。vs/nat不需要在realserver上做任何設定，其隻要能提供一個tcp/ip的協定棧即
可，甚至其無論基于什麼os。基于vs/nat，所有的入站資料包均由director進行目标位址轉換後轉發至内部的
realserver，realserver響應的資料包再由director轉換源位址後發回用戶端。
vs/nat模式不能與netfilter相容，是以，不能将vs/nat模式的director運作在netfilter的保護範圍之中。現在已經有更新檔可以解決此問題，但尚未被整合進ip_vs
code。
設定vs/nat模式的lvs(這裡以web服務為例)
director:
real
server：
route add default gw 192.168.10.10 注釋：在real
server
上網關一定要指向director伺服器的dip，不然使用者請求的資料封包，在lvs/nat模型中将無法發送出去.
arp問題：
在如上圖的vs/dr或vs/tun
應用的一種模型中（所有機器都在同一個實體網絡），所有機器（包括director和realserver）都使用了一個額外的ip位址，即vip。當一
個用戶端向vip發出一個連接配接請求時，此請求必須要連接配接至director的vip，而不能是realserver的。因為，lvs的主要目标就是要
director負責排程這些連接配接請求至realserver的。
是以，在client發出至vip的連接配接請求後，隻能由director将其
mac位址響應給用戶端（也可能是直接與director連接配接的路由裝置），而director則會相應的更新其ipvsadm
table以追蹤此連接配接，而後将其轉發至後端的realserver之一。
如果client在請求建立至vip的連接配接時由某realserver
響應了其請求，則client會在其mac
table中建立起一個vip至realserver的對就關系，并以至進行後面的通信。此時，在client看來隻有一個realserver而無法意
識到其它伺服器的存在。
為了解決此問題，可以通過在路由器上設定其轉發規則來實作。當然，如果沒有權限通路路由器并做出相應的設定，則隻能通過傳統的本地方式來解決此問題了。這些方法包括：
1、禁止realserver響應對vip的arp請求；
2、在realserver上隐藏vip，以使得它們無法獲知網絡上的arp請求；
3、基于“透明代理（transparent
proxy）”或者“fwmark （firewall mark）”；
4、禁止arp請求發往realservers；
傳
統認為，解決arp問題可以基于網絡接口，也可以基于主機來實作。linux采用了基于主機的方式，因為其可以在大多場景中工作良好，但lvs卻并不屬于
這些場景之一，是以，過去實作此功能相當麻煩。現在可以通過設定arp_ignore和arp_announce，這變得相對簡單的多了。
linux
2.2和2.4（2.4.26之前的版本）的核心解決“arp問題”的方法各不相同，且比較麻煩。幸運的是，2.4.26和2.6的核心中引入了兩個新的
調整arp棧的标志（device
flags）：arp_announce和arp_ignore。基于此，在dr/tun的環境中，所有ipvs相關的設定均可使用
arp_announce=2和arp_ignore=1/2/3來解決“arp問題”了。
arp_annouce：define different restriction levels
for announcing the local source ip address from ip packets in arp requests sent
on interface；
0 - (default) use any local address, configured
on any interface.
1 - try to avoid local addresses that are not
in the target‘s subnet for this interface.
2 - always use the
best local address for this target.
arp_ignore: define different modes
for sending replies in response to received arp requests that resolve local
target ip address.
0 - (default): reply for any local target ip
address, configured on any interface.
1 - reply only if the
target ip address is local address configured on the incoming interface.
2 - reply only if the target ip address is local address configured
on the incoming interface and both with the sender‘s ip address are part from
same subnet on this interface.
3 - do not reply for local
address configured with scope host, only resolutions for golbal and link
addresses are replied.
4-7 - reserved
8 - do
not reply for all local addresses
在realservers上，vip配置在本地回環接口lo上。如果回應給client的資料包路由到了eth0接口上，則arp通告或請應該通過eth0實作，是以，需要在sysctl.conf檔案中定義如下配置：
以上選項需要在啟用vip之前進行，否則，則需要在drector上清空arp表才能正常使用lvs。
到
達director的資料包首先會經過prerouting，而後經過路由發現其目标位址為本地某接口的位址，是以，接着就會将資料包發往input(local_in
hook)。此時，正在運作核心中的ipvs（始終監控着local_in
hook）程序會發現此資料包請求的是一個叢集服務，因為其目标位址是vip。于是，此資料包的本來到達本機(director)目标行程被改變為經由
postrouting
hook發往realserver。這種改變資料包正常行程的過程是根據ipvs表(由管理者通過ipvsadm定義)來實作的。
如果有
多台realserver，在某些應用場景中，director還需要基于“連接配接追蹤”實作将由同一個客戶機的請求始終發往其第一次被配置設定至的
realserver，以保證其請求的完整性等。其連接配接追蹤的功能由hash table實作。hash
table的大小等屬性可通過下面的指令檢視：
為了保證其時效性，hash
table中“連接配接追蹤”資訊被定義了“生存時間”。lvs為記錄“連接配接逾時”定義了三個計時器：
1、空閑tcp會話；
2、用戶端正常斷開連接配接後的tcp會話；
3、無連接配接的udp資料包（記錄其兩次發送資料包的時間間隔）；
上面三個計時器的預設值可以由類似下面的指令修改，其後面的值依次對應于上述的三個計時器：
資料包在由direcotr發往
realserver時，隻有目标mac位址發生了改變(變成了realserver的mac位址)。realserver在接收到資料包後會根據本地路
由表将資料包路由至本地回環裝置，接着，監聽于本地回環裝置vip上的服務則對進來的資料庫進行相應的處理，而後将處理結果回應至rip，但資料包的原地
址依然是vip。
ipvs的持久連接配接：
無論基于什麼樣的算法，隻要期望源于同一個用戶端的請求都由同一台realserver響應時，就需要用到持久連接配接。比如，某一使用者連續打開了三個telnet連接配接請求時，根據rr算法，其請求很可能會被配置設定至不同的realserver，這通常不符合使用要求。
2、ipvs/dr
ip配置設定
<code>vip=192.168.0.210</code>
<code>rip1=192.168.0.221</code>
<code>rip2=192.168.0.222</code>
1、下載下傳安裝ipvsadm
2、編寫并運作腳本（lvs伺服器的腳本）
3、給腳本權重限，并執行
4、配置後端的web伺服器腳本
5、給腳本權重限，并執行
ipvsadm 的用法和格式如下：
叢集相關的指令參數：
rs相關的指令參數：
lvs的持久連接配接：
持久連接配接即是不考慮lvs的轉發方法，確定所有來自同一個使用者的連接配接轉發到同一個realserver上
lvs持久連接配接适用于大部分排程算法。當某一種請求需要定向到一個real server
時，就要用到持久連接配接
一般應用到：ssl（http.https等），ftp。。
-p //表示此連接配接為持久連接配接
n
//表示維持此持久連接配接的時間。預設6分鐘。當超過這個時間後，如果網頁還沒有關掉，仍處于激活狀态，重新複位時間為2分鐘。
持久連接配接的類型：
1.pcc(persistent client
connector,持久使用者連接配接)同一個使用者所有的請求在逾時範圍之内都被定位到同一個realserver上，這個時候在指定端口的時候使用的是0端口，就是所有的請求都轉發出去。
2.ppc(persistent port connector)使用者的所有請求在逾時範圍内按照端口定位到不同的rs上。
3.防火牆标記：把相關聯的端口在防火牆上打上同樣的标記，使用者在通路兩個相關聯的服務的時候，就會定位到同一個realserver上。
4.ftp
connection：由于ftp使用的是兩個端口号，是以需要單獨列出來。
a.pcc執行個體：
directory上的配置：
realserver1上的配置：
realserver2上的配置：
在浏覽其中輸入然後重新整理頁面，可以看到頁面一直不變,然後我們再使用ssh登入到192.168.1.10，使用ifconfig檢視，和網頁所在的realserver同樣，實驗完成！
b.ppc就是根據服務的不同，定向到不同的realserver上，在directory上多寫幾個ipvsadm指向，注意端口要區分開來就行了
c.防火牆标記的持久連接配接
依然是上面的圖
兩個realserver配置不變
在directory上重新配置：
測試：
在浏覽其中輸入可以通路到網頁，但是如果使用ssh連接配接192.168.1.10的話，就隻能呗定向到192.168.1.12上也就是directory上，實驗完成
d.使用防火牆标記實作http&&https姻親關系：
依然使用上面的拓撲圖：
1.首先在rs上做證書
2.其他的配置和上面一樣，同樣realserver2上也采取同樣的配置，我這裡就不示範了
3.directory上的配置如下：
隻需要在iptables上多添加一條指令如下
測試：在浏覽器中輸入和發現通路的是同一個頁面，就證明成功啦！
因為lvs自身本沒有多後端real server
做健康狀态檢測的功能是以：
編寫健康狀态監測腳本：
lvs負載均衡器本身是沒有對後端伺服器做健康狀态監測的功能的；是以我們可以編寫一個小小的腳本來完成這個功能;
注釋：這些腳本的列子很粗糙，隻是讓你們了解整個過程是怎樣的；
健康狀态監測腳本執行個體：
![Java小案例——随機數猜測随機數猜測[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)