隨著互聯網的飛速發展，傳統的昂貴的大容量高性能服務器（F5 BIG-IP、Citrix NetScaler、A10）已經越來越應付不了日益增長的業務需求了，而高并發和負載均衡所帶來的高可靠/高可用/低成本卻完美的解決了傳統服務器面臨的一些問題。現在我們來簡單聊聊高并發和負載均衡。

在上一講中，我們弄清了訪問一次網頁時，里面所發生的的曲折動人的故事，那是我們一個客戶端再向百度的服務器發送請求，而實際情況是百度要面臨整個中國網民的訪問和請求，如果依然將所有的服務都部署在一臺服務器上，可想而知，那臺服務器將要面臨多大的壓力，要具備多么強大的性能和帶寬，由此我們引出高并發和負載均衡技術，并通過LVS來簡單了解下它的原理。

LVS是 Linux Virtual Server 的簡稱，也就是Linux虛擬服務器。這是一個由章文嵩博士發起的一個開源項目，它的官方網是 http://www.linuxvirtualserver.org 現在 LVS 已經是 Linux 內核標準的一部分。使用 LVS 可以達到的技術目標是：通過 LVS 達到的負載均衡技術和 Linux 操作系統實現一個高性能高可用的 Linux 服務器集群，它具有良好的可靠性、可擴展性和可操作性。從而以低廉的成本實現最優的性能。LVS 是一個實現負載均衡集群的開源軟件項目，LVS架構從邏輯上可分為調度層、Server集群層和共享存儲。

LVS包含幾個組成部分：

VIP：虛擬服務器地址

DIP：轉發的網絡地址

1.和RIP通信：ARP協議，獲取Real Server的RIP：MAC地址

2.轉發Client的數據包到RIP上（隱藏的VIP）

RIP：后端真實主機（后端服務器）

CIP：客戶端IP地址

1.LVS的基本工作原理：

簡單的說就是通過負載均衡器，接收海量的請求，然后根據后面的server端情況運行情況分發給不同的server進行處理，然后返回處理結果的過程。

2.下面我們具體說下LVS的三種具體負載模式：

2.1 LVS/NAT原理和特點：

(a). 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP

(b). PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈

(c). IPVS比對數據包請求的服務是否為集群服務，若是，修改數據包的目標IP地址為后端服務器IP，然后將數據包發至POSTROUTING鏈。 此時報文的源IP為CIP，目標IP為RIP

(d). POSTROUTING鏈通過選路，將數據包發送給Real Server

(e). Real Server比對發現目標為自己的IP，開始構建響應報文發回給Director Server。 此時報文的源IP為RIP，目標IP為CIP

(f). Director Server在響應客戶端前，此時會將源IP地址修改為自己的VIP地址，然后響應給客戶端。 此時報文的源IP為VIP，目標IP為CIP

LVS-NAT模型的特性

• RS應該使用私有地址，RS的網關必須指向DIP
• DIP和RIP必須在同一個網段內
• 請求和響應報文都需要經過Director Server，高負載場景中，Director Server易成為性能瓶頸
• 支持端口映射
• RS可以使用任意操作系統
• 缺陷：對Director Server壓力會比較大，請求和響應都需經過director server，試想，我們的所有數據的傳輸都要經過Director Server，如果產生高并發或者這中間的數據有視頻等一些大的文件類型，那么勢必會給Director Server非常大的壓力

所以這種方法，并不適合真正的高并發和大訪問量的企業，不過一般企業使用這個模式在企業內部使用以足夠解決很多問題。

由此引出了我們的第二種負載模式：

2.2 LVS-DR的原理和特點：

重將請求報文的目標MAC地址設定為挑選出的RS的MAC地址

(a) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP

(b) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈

(c) IPVS比對數據包請求的服務是否為集群服務，若是，將請求報文中的源MAC地址修改為DIP的MAC地址，將目標MAC地址修改RIP的MAC地址，然后將數據包發至POSTROUTING鏈。 此時的源IP和目的IP均未修改，僅修改了源MAC地址為DIP的MAC地址，目標MAC地址為RIP的MAC地址

(d) 由于DS和RS在同一個網絡中，所以是通過二層來傳輸。POSTROUTING鏈檢查目標MAC地址為RIP的MAC地址，那么此時數據包將會發至Real Server。

(e) RS發現請求報文的MAC地址是自己的MAC地址，就接收此報文。處理完成之后，將響應報文通過lo接口傳送給eth0網卡然后向外發出。 此時的源IP地址為VIP，目標IP為CIP

(f) 響應報文最終送達至客戶端

2. LVS-DR模型的特性

• 特點1：保證前端路由將目標地址為VIP報文統統發給Director Server，而不是RS
• RS可以使用私有地址；也可以是公網地址，如果使用公網地址，此時可以通過互聯網對RIP進行直接訪問
• RS跟Director Server必須在同一個物理網絡中
• 所有的請求報文經由Director Server，但響應報文必須不能進過Director Server
• 不支持地址轉換，也不支持端口映射
• RS可以是大多數常見的操作系統
• RS的網關絕不允許指向DIP(因為我們不允許他經過director)
• RS上的lo接口配置VIP的IP地址
• 缺陷：RS和DS必須在同一機房中（也就是必須在一個網段中）

3. 特點1的解決方案：

• 在前端路由器做靜態地址路由綁定，將對于VIP的地址僅路由到Director Server
• 存在問題：用戶未必有路由操作權限，因為有可能是運營商提供的，所以這個方法未必實用
• arptables：在arp的層次上實現在ARP解析時做防火墻規則，過濾RS響應ARP請求。這是由iptables提供的
• 修改RS上內核參數（arp_ignore和arp_announce）將RS上的VIP配置在lo接口的別名上，并限制其不能響應對VIP地址解析請求。

下面給出具體的配置方式：

配置拓撲：

?1，準備3臺虛擬機

?2，先配置3臺虛擬機的網絡：

–eth0，配置在一個網段

?DIP,RIP在一個網段

?3，配置lvs的VIP

–ifconfig eth0:0 192.168.9.100/24

–echo “1” > /proc/sys/net/ipv4/ip_forward

?4，調整RS的響應。通告級別（每一臺RS都配）：

–echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore

–echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce

–echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

–echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

?5，配置RS的VIP（每一臺RS都配）

–ifconfig lo:8 192.168.9.100 netmask 255.255.255.255

?6，啟動RS上的httpd

–yum install httpd -y

–/var/www/html

?vi index.html

?from ooxxip

–service httpd start

?客戶端驗證：RIP：80 能顯示

–VIP：80不能顯示

?7，LVS——ipvsadm

–yum install ipvsadm -y

–ipvsadm -A -t 192.168.9.100:80 -s rr

–ipvsadm -a -t 192.168.9.100:80 -r 192.168.9.12 -g

–ipvsadm -a -t 192.168.9.100:80 -r 192.168.9.13 -g

–ipvsadm -ln

–瀏覽器刷新: 訪問vip

–ipvsadm –lnc

–netstat -natp

說下實現吧，當客戶端向192.168.9.100發送請求時，LVS會先根據服務器使用情況，將請求分發給其后的Server（可能是node1節點也可能是node2節點），

命令ifconfig lo:8 192.168.9.100 netmask 255.255.255.255已將VIP配置為192.168.9.100

ipvsadm -a -t 192.168.9.100:80 -r 192.168.9.12 -g（將LVS與Server進行“綁定”）

如下圖：我的配置為192.168.131.100，兩個進行與運算結果仍然為192.168.131.100，所以

只能調用eth0,然后192.168.131.162與255.255.255.0與運算，結果為192.168.131.0，結果和從LVS返回結果一樣，所以就實現了從server直接將結果返回給客戶端的請求。（在剛開始工作時，這里也思考了很久，后期終于明白。。。。。。。）

下面說說異地部署（如果你的公司是一個面向全球建立數據中心的話）：

2.3 LVS-Tun的原理和特點：

在原有的IP報文外再次封裝多一層IP首部，內部IP首部(源地址為CIP，目標IIP為VIP)，外層IP首部(源地址為DIP，目標IP為RIP)

(a) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP 。

(b) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈

(c) IPVS比對數據包請求的服務是否為集群服務，若是，在請求報文的首部再次封裝一層IP報文，封裝源IP為為DIP，目標IP為RIP。然后發至POSTROUTING鏈。 此時源IP為DIP，目標IP為RIP

(d) POSTROUTING鏈根據最新封裝的IP報文，將數據包發至RS（因為在外層封裝多了一層IP首部，所以可以理解為此時通過隧道傳輸）。 此時源IP為DIP，目標IP為RIP

(e) RS接收到報文后發現是自己的IP地址，就將報文接收下來，拆除掉最外層的IP后，會發現里面還有一層IP首部，而且目標是自己的lo接口VIP，那么此時RS開始處理此請求，處理完成之后，通過lo接口送給eth0網卡，然后向外傳遞。 此時的源IP地址為VIP，目標IP為CIP

(f) 響應報文最終送達至客戶端

LVS-Tun模型特性

• RIP、VIP、DIP全是公網地址
• RS的網關不會也不可能指向DIP
• 所有的請求報文經由Director Server，但響應報文必須不能進過Director Server
• 不支持端口映射
• RS的系統必須支持隧道

其實企業中最常用的是 DR 實現方式，而 NAT 配置上比較簡單和方便，后邊實踐中會總結 DR 和 NAT 具體使用配置過程。

3.LVS結合keepalive

LVS可以實現負載均衡，但是不能夠進行健康檢查，比如一個rs出現故障，LVS 仍然會把請求轉發給故障的rs服務器，這樣就會導致請求的無效性。keepalive 軟件可以進行健康檢查，而且能同時實現 LVS 的高可用性，解決 LVS 單點故障的問題，其實 keepalive 就是為 LVS 而生的。

• Keepalived1 + lvs1(Director1)：192.168.0.48
• Keepalived2 + lvs2(Director2)：192.168.0.58
• Real server1：192.168.0.18
• Real server2：192.168.0.28
• IP: 192.168.0.38

Lvs + keepalived的2個節點安裝

#yum install ipvsadm keepalived -y

Real server + nginx服務的2個節點安裝

# yum install epel-release -y

# yum install nginx -y

設置配置腳本

Real server節點2臺配置腳本：

# vim /usr/local/sbin/lvs_dr_rs.sh

#! /bin/bash

vip=192.168.0.38

ifconfig lo:0 $vip broadcast $vip netmask 255.255.255.255 up

route add -host $vip lo:0

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

2節點rs 上分別執行腳本：

bash /usr/local/sbin/lvs_dr_rs.sh

keepalived節點配置(2節點)：

主節點( MASTER )配置文件

vim /etc/keepalived/keepalived.conf

vrrp_instance VI_1 {

state MASTER

interface eth0

virtual_router_id 51

priority 100

advert_int 1

authentication {

auth_type PASS

auth_pass 1111

}

virtual_ipaddress {

192.168.0.38

}

}

virtual_server 192.168.0.38 80 {

delay_loop 6

lb_algo rr

lb_kind DR

persistence_timeout 0

protocol TCP

real_server 192.168.0.18 80 {

weight 1

TCP_CHECK {

connect_timeout 10

nb_get_retry 3

delay_before_retry 3

connect_port 80

}

}

real_server 192.168.0.28 80 {

weight 1

TCP_CHECK {

connect_timeout 10

nb_get_retry 3

delay_before_retry 3

connect_port 80

}

}

}

從節點( BACKUP )配置文件

拷貝主節點的配置文件keepalived.conf，然后修改如下內容：

state MASTER -> state BACKUP

priority 100 -> priority 90

keepalived的2個節點執行如下命令，開啟轉發功能：

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

啟動keepalive

<strong>先主后從分別啟動keepalive</strong>

service keepalived start

驗證結果

實驗1

手動關閉192.168.0.18節點的nginx，service nginx stop 在客戶端上去測試訪問 http://192.168.0.38 結果正常，不會出現訪問18節點，一直訪問的是28節點的內容。

實驗2

手動重新開啟 192.168.0.18 節點的nginx， service nginx start 在客戶端上去測試訪問 http://192.168.0.38 結果正常，按照 rr 調度算法訪問18節點和28節點。

實驗3

測試 keepalived 的HA特性，首先在master上執行命令 ip addr ，可以看到38的vip在master節點上的；這時如果在master上執行 service keepalived stop 命令，這時vip已經不再master上，在slave節點上執行 ip addr 命令可以看到 vip 已經正確漂到slave節點，這時客戶端去訪問 http://192.168.0.38 訪問依然正常，驗證了 keepalived的HA特性。

總結

以上是生活随笔為你收集整理的net 模式中虚拟机连不上本机oracle_高并发与负载均衡（三种负载模式）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。