高可用反向代理服務體系應用與優化

文/陳國良 巫園芬

在高校，信息化和數字化早已滲透到學校教學、科研、管理等各方面，數字化校園成為學校教學和科研的有力支持。基本上每個二級單位都建設了數個信息系統，如果為眾多信息系統提供互聯網服務對高校網絡中心而言將是巨大的挑戰。

高校通常自建校園網及IDC，所有校內的信息系統都運行在IDC 中。在單一互聯網出口的網絡架構中，由于路由簡單，問題的焦點落于IP 地址匱乏上；在多個互聯網出口的網絡架構中，除匱乏的IP 地址，還將存在復雜路由、源進源出、智能DNS 等問題。

復雜路由和源進源出可通過路由設備解決，智能DNS 則可通過配置view zone 解決多運營商互聯網出口用戶訪問優化問題，但匱乏的IP 地址致使無法為每個信息系統配備公網IP，虛擬主機、反向代理技術可以較好地解決IP 地址匱乏問題。

技術架構

主機技術

信息系統提供互聯網服務無非為實例主機或虛擬主機。實例主機即每個信息系統對應一個公網IP，對于IPv4 地址已經分配完畢但仍未過渡到IPv6 網絡期間，顯然會占用過多的IPv4 地址。在多出口校園網環境中非主要出口所分配到的IPv4 地址通常只有64 個甚至更少。實例主機方式顯然不適合。

暨南大學

虛擬主機的技術實現則有兩種方式。第一，使用同一IP 地址但不同端口，由此，每個IP 地址可以支持超過6 萬個虛擬主機即運行超過6 萬個信息系統。在數量上確實能滿足為高校信息系統提供互聯網服務，但信息系統的承載是http 或https 協議，這兩者都有其默認服務端口80 和443。使用同一IP 地址但不同端口做虛擬主機服務意味著需要改變服務端口，即用戶訪問該信息系統時需要在域名或IP 地址后面加上端口號以便映射到相應的信息系統，大大降低了用戶友好度。

第二，使用同一IP 地址同一端口，根據不同主機名即域名來區分信息系統。如此，每個IP 地址可以支持趨近無限個信息系統，且用戶只需輸入域名作為信息系統的識別即可訪問到相應的信息系統，大大提高了用戶友好度。

中間件技術

采用主機名虛擬主機方式可實現區分無限個信息系統，但一臺物理主機的性能終歸是有限的，而且信息系統的編程語言不一、技術架構參差不齊，亦不可能運行在同一臺服務器中。因此，中間件和負載均衡是不得不考慮的問題。

業界解決此類問題的方案不少，考慮到在實際的網絡環境中，部分二級單位的服務器并非統一托管到網絡中心機房，因此選用反向代理的方案。

對用戶而言，反向代理服務器就是信息系統，用戶訪問反向代理服務器，反向代理服務器接收到用戶的請求，接著向真實服務器請求相應的數據，收到真實服務器返回的數據后再將數據返回給用戶。反向代理服務器終止了用戶的TCP 連接，所以用戶不必與真實服務器跟帖可達，用戶只需能訪問反向代理服務器即可，代理服務器可以通過私有網絡向真實服務器請求數據。此架構可節省公網IP 地址，保護真實服務器不受互聯網攻擊，信息系統數量不受服務器性能限制，優點顯著，如圖1 所示。

在反向代理軟件的選擇上，主要考慮三款主流的開源軟件，Squid、Varnish 和Nginx。

圖1 反向代理原理

Squid，有一定歷史的反向代理軟件，其功能有傳統代理、身份驗證、URL 過濾、連接管理等。目前廣泛應用于各CDN 上做反向緩存代理服務器。

Varnish 則較為年輕，設計簡單，數據主要緩存在內存上，響應更快，更符合目前高速交付的需求，但重啟后數據將消失，更適合做網絡加速用途。

Nginx 具有高并發的優點，支持http、https、pop、smtp、imap 等多種協議，廣泛應用于各大型網站中。

近年來，信息安全事件頻出，隨著信息安全形勢日益嚴峻，全網使用ssl 安全連接被提上了日程，全網使用https 協議也即將實現，支持反向代理部署的全網https 協議方案必然要求反向代理軟件支持SNI，SNI 即服務器名稱指示（Server Name Indication），是TLS 協議的擴展，用于指示和哪些主機名服務端來握手連接。這使得一臺服務器上相同的IP 地址和端口允許使用多張證書，從而允許多個安全的站點（https 站點）在相同的IP 地址上，不需要使用相同的SSL 證書。這相當于允許虛擬主機用于https。Nginx 較其他軟件更好地支持SNI，能夠更好地滿足需求。

負載均衡

Nginx 除了能實現反向代理功能外，其實還是一款優質的負載均衡軟件，它可以做應用層的負載均衡，支持熱備、輪詢等模式并可靈活配置真實服務器檢活機制。然而僅使用Nginx 來實現負載均衡容易出現單點故障，同時單臺服務器性能有限，無法很好支持逐年增長的龐大數量的信息系統。

LVS+HA+Ldirectord 可以很好地解決單點故障，從網絡層進行負載均衡，具體功能實現如下：

LVS 提供虛擬IP 接收業務請求，并將請求按設定算法調度到真實服務器，工作在OSI 四層以下，通過IP、端口處理業務流量。

HA 是雙機高可用，即協商兩臺服務器，在其中一臺服務器上運行LVS，若該服務器出現故障無法運行LVS 則會切換到另一臺服務器運行LVS，實現虛擬IP 高可用。

Ldirectord 主要用于檢測后端服務器的服務狀態，一旦檢測到后端服務器下線，則把該服務器從LVS 服務器列表中剔除，避免LVS 把用戶請求轉發到故障服務器中。

如圖2 所示，用戶請求www、news、net 等站點，LVS 將用戶請求調度到各反向代理服務器，反向代理服務器再根據用戶請求連接到真實服務器。

圖2 反向代理負載均衡原理

顯而易見，信息系統服務器將存在單點故障風險，部分重點服務器無法得到保障。在此情況下，Nginx 的應用負載均衡則可以很好地補充反向代理對真實服務器的負載均衡，實現反向代理負載均衡體系的高可用，如圖3 所示。

應用與優化

LVS 部署與優化

1.安裝

采用內核版本為2.6.x 的Linux 操作系統，以更好地支持LVS。采用源碼方式安裝ipvsadm-1.26、Heartbeat-3、ClusterLabsresource-agents 和Reusable-Cluster-Components-glue。

圖3 高可用反向代理負載均衡原理

2.配置

ha.cf 指定雙機均衡對端，關鍵配置如下：

ucast eth0 192.168.0.121

auto_failback off

node lvsweb48a lvsweb48b

authkeys 配置使用md5 加密驗證方法：

auth 3

3 md5 lvsweb48

haresources 配置運行的資源：

lvsweb48b lvsadm ldirectord

ldirectord.cf 關鍵配置：

virtual=192.168.0.48:80

real=192.168.0.106:80 gate

……

fallback=192.168.0.100:80

service=http

scheduler=lc

lvsadm 配置LVS 初始運行：

#!/bin/bash

RWEBCACHE11=192.168.0.102

……

VWEBCACHE1=192.168.0.48

ogateway=192.168.0.123

……

VHWaddr0=00:CA:74:00:30:00

……

VIPaddr0=192.168.0.48

RIPaddr0=192.168.0.122

# 以下為優化內容一

/sbin/ifconfig eth0 down

/sbin/ifconfig eth0 hw ether $VHWaddr0

/sbin/ifconfig eth0 up

/sbin/ifconfig eth1 down

/sbin/ifconfig eth1 hw ether $VHWaddr1

/sbin/ifconfig eth1 up

……

# 以下為優化內容二

ping -c 3 -i 1 $ogateway

ping -c 3 -i 1 $igateway

ping -c 3 -i 1 $vogateway1

ping -c 3 -i 1 $vogateway2

#以下省略正常配置

#Clear IPVS table

#Set LVS

#Run LVS

3. 優化

上述LVS+HA+Ldirectord 體系配置是經優化后的最終配置，主要體現在：

（1）自編程初始配置，其中將VIP 的MAC 地址統一為雙機一致，即LVS 雙機進行故障切換時，保持網關設備的arp 表不變，將切換控制在2～3 個ping 包內。若不對此進行優化，剛故障切換時網絡中斷時間更長，或者需要網關設備調整arp 老化時間，從而影響設備性能。

（2）切換時增加ping 網關等操作，進一步提升網絡自愈能力。

（3）使用雙網卡路由配置可自由區分內外網流量。

4.增強自愈能力

通過配置監控腳本，實現雙活、雙宕機等異常情況的自愈。主要原理為通過ping 測LVS 真實IP 與虛擬IP 監控LVS 是否存活，如雙宕機則相繼重啟服務器。設置監控網卡，LVS 生效與失效會改變監控網卡的MAC，通過ping 測監控網卡，分析MAC是生效前或后的值即可判斷LVS 是否存在雙活異常，如是則相繼重啟服務器。腳本關鍵內容如下：

system ("ping -c 4 $virtual_ip > $status_file") &&

printf "Can not run ping command! ";

open(pid_f,$status_file) || die ("Could not open file");

while ($line=){

chomp $line;

$cmd_line = $line;

if ( index($cmd_line,$cmd_v) > 0 ) {

$run_v=0;

}

}

close(pid_f);

……

if ( $run_v > 0 ) {

system ("echo $time restart no service>> $fail_

log");

system ("init 6 ") && die "Can not run SH! ";

}

elsif ( $arp_r == $arp_l ) {

system ("echo $time restart both service>> $fail_

log");

system ("init 6 ") && die "Can not run SH! ";

}

exit;

效果較顯著，能確保LVS 正常服務，見

日志記錄：

201905132015 restart both service

201905190533 restart no service

201905200533 restart both service

……

格式為“日期 操作 原因”，其中“both service”為雙活異常，“no service”為宕服務異常。從日志可看出監控腳本可有效維持LVS 正常服務。

Nginx 部署與優化

1.安裝

采用Freebsd 操作系統，源碼方式安裝nginx-1.10.2。

2.配置

配置nginx.conf 實現反向代理功能，關鍵配置如下：

server {

listen 80;

server_name ＊.test.edu.cn;

location / {

proxy_pass http://$host;

proxy_set_header Host $host;

proxy_redirect off;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_

x_forwarded_for;

proxy_buffering off;

}

}

server {

listen 443 ssl;

server_name ＊.test.edu.cn;

ssl_certificate test.edu.cn.crt;

ssl_certificate_key test.edu.cn.key;

ssl_session_cache shared:SSL:1m;

ssl_session_timeout 5m;

ssl_ciphers HIGH:!aNULL:!MD5;

ssl_prefer_server_ciphers on;

location / {

proxy_pass http://$host;

proxy_set_header Host $host;

proxy_redirect off;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_

x_forwarded_for;

proxy_buffering off;

}

}

}

include upstream.conf;

include server80.conf;

include server443.conf;

3.優化

上述配置為Nginx 的主配置，做了幾點優化，主要體現在：

（1）優化日志記錄格式，既考慮到更詳盡地記錄訪問日志，又兼顧安全部門溯源的需要。詳盡的日志記錄，可以通過分析各響應時間，得出不同站點不同節點的訪問時延，進一步有針對性地優化。

（2）主配置與站點個性化配置分離，以便更好地管理，站點個性化配置通過include 方式加載。

（3）對部分重要信息系統需要應用層負載均衡的，通過“include upstream.conf;”，設置upstream 服務器即可實現。

經實驗驗證并在生產環境穩定運行數年，高可用反向代理體系運行情況良好。實現了校園網的信息系統統一向各互聯網出口提供服務，解決了校園網信息系統數量多而各互聯網出口IP 不足的問題，減輕了網絡管理員的管理工作。通過優化，極大提升了反向代理體系的高可用性。

隨著信息技術的發展，信息系統基礎重點從簡單提供服務到規范代碼編寫、從簡單網絡連通到網絡安全、從信息發布到信息安全轉變，反向代理體系從提供服務的角度解決了高可用，但無法阻擋惡意攻擊、無法很好地解決安全問題，這需要進一步的研究與探索。