文/鄒艷玲 宋曉輝 常征

為提高高校數(shù)據(jù)中心Web應(yīng)用的性能和安全性，提出了一種基于NGINX技術(shù)的綜合管理體系架構(gòu)。該結(jié)構(gòu)聚合訪問者請求轉(zhuǎn)發(fā)到真實(shí)服務(wù)器，針對不同HTTP應(yīng)用部署了智能DNS、策略路由等分流策略，使用靜態(tài)資源緩存技術(shù)提升了訪問速度，整合了各運(yùn)營商資源達(dá)到“互聯(lián)互通”。同時(shí)，使用事件驅(qū)動的方式處理請求，轉(zhuǎn)發(fā)經(jīng)過適當(dāng)過濾的Web訪問，增加WAF模塊實(shí)現(xiàn)了對應(yīng)用服務(wù)器更全面的Web安全防護(hù)。通過UPSTREAM管理模塊構(gòu)建管理體系，為安全應(yīng)急響應(yīng)提供了快速處置接口。現(xiàn)網(wǎng)運(yùn)行實(shí)踐表明，與傳統(tǒng)的Web應(yīng)用架構(gòu)相比，所提架構(gòu)穩(wěn)定，安全性高，并通過“無狀態(tài)”降低了整體管理成本。

高校數(shù)據(jù)中心承載了學(xué)校大量信息系統(tǒng)，面對師生和公眾提供各項(xiàng)服務(wù)，是非常重要的信息化基礎(chǔ)設(shè)施。隨著信息化工作不斷推進(jìn)，數(shù)據(jù)中心承載的信息系統(tǒng)越來越多，學(xué)校各項(xiàng)業(yè)務(wù)和用戶對信息系統(tǒng)的依賴不斷增強(qiáng)，對數(shù)據(jù)中心的各項(xiàng)要求也越來越高:首先，基于訪問質(zhì)量要求；其次，基于網(wǎng)絡(luò)和信息安全要求。綜合上述管理和技術(shù)要求，本文嘗試了以NGINX為核心，構(gòu)建校級Web應(yīng)用管理體系。NGINX是一款輕量級的Web服務(wù)器/反向代理服務(wù)器及電子郵件(IMAP/POP3)代理服務(wù)器，并在一個(gè)BSD-like協(xié)議下發(fā)行。其特點(diǎn)是占有內(nèi)存少，并發(fā)能力強(qiáng)。在學(xué)校數(shù)據(jù)中心部署后，實(shí)現(xiàn)了對校內(nèi)Web應(yīng)用的加速、管理等多種功能，并在一定程度上提高了校園網(wǎng)內(nèi)Web站點(diǎn)的應(yīng)用安全。

系統(tǒng)架構(gòu)

數(shù)據(jù)中心傳統(tǒng)的系統(tǒng)架構(gòu)通常利用防火墻做目標(biāo)地址轉(zhuǎn)換（DNAT）或者在Web服務(wù)器上設(shè)置各互聯(lián)網(wǎng)服務(wù)提供商（ISP）的公網(wǎng)地址。配置更新時(shí)需要手動修改防火墻或服務(wù)器設(shè)置，顯然，這兩種方式管理相對復(fù)雜，缺少靈活性。因此，可以把各個(gè)ISP的IP資源放到NGINX服務(wù)器群上，實(shí)現(xiàn)全校所有Web系統(tǒng)共享共用。本文提出了集中統(tǒng)一的架構(gòu)模式，如圖1所示，因?qū)W校由兩個(gè)校區(qū)組成，拓?fù)渲性O(shè)備分成了兩組，數(shù)據(jù)中心（IDC）核心1和2在同一校區(qū)，IDC核心3在另一校區(qū)。兩校區(qū)間通過多個(gè)MPLS VPN（基于MPLS技術(shù)的虛擬局域網(wǎng)）連接將雙方的ISP資源對接到三個(gè)IDC核心設(shè)備上。IDC核心包括了防火墻（FW）、入侵防御系統(tǒng)（IPS）和負(fù)載均衡（LB）等常見業(yè)務(wù)插卡。雖然，NGINX集群在網(wǎng)絡(luò)連接上和普通Web服務(wù)器位置相似,但Web流量實(shí)際上經(jīng)過了NGINX集群轉(zhuǎn)發(fā)。

架構(gòu)通過“無狀態(tài)”來降低管理成本。所謂“無狀態(tài)”，是指每一臺服務(wù)器的作用對等，相應(yīng)的軟件和配置一致?？梢栽诤诵腘GINX層實(shí)現(xiàn)流量分組（如內(nèi)外網(wǎng)隔離、爬蟲和非爬蟲流量隔離）、緩存靜態(tài)文件、請求頭過濾、故障切換（機(jī)房故障切換到其他機(jī)房）、流量控制、防火墻（FW）等一些通用型功能，支持水平擴(kuò)容。調(diào)整服務(wù)器時(shí)，不需要針對不同服務(wù)器的“個(gè)性”化需求做配置，實(shí)現(xiàn)數(shù)據(jù)中心整體管理成本最低。

圖1 基于NGINX技術(shù)的綜合管理體系架構(gòu)

提高Web訪問質(zhì)量

除了網(wǎng)站和信息系統(tǒng)自身響應(yīng)速度，網(wǎng)絡(luò)速度對訪問質(zhì)量影響也很大，特別是互聯(lián)網(wǎng)帶寬和時(shí)延。當(dāng)前高校數(shù)據(jù)中心一般使用校園出口資源作為校外用戶訪問入口，通常配備一條或數(shù)條運(yùn)營商鏈路。由于客觀存在的運(yùn)營商互聯(lián)互通問題，往往單一運(yùn)營商鏈路無法提供理想的校外訪問效果，需要綜合、合理利用多運(yùn)營商鏈路。

策略路由、源線路進(jìn)和源線路出

在操作系統(tǒng)層面設(shè)置合適的策略路由，使來自特定運(yùn)營商鏈路的訪問請求，回應(yīng)報(bào)文從原鏈路返回。本文使用Linux操作系統(tǒng)作為配置案例【1】，首先創(chuàng)建兩個(gè)默認(rèn)路由表T1和T2，令第一塊網(wǎng)卡的名為$IF1，第二塊網(wǎng)卡名為$IF2；然后，設(shè)置網(wǎng)卡1和網(wǎng)卡2的IP地址分別為ISP分配的IP地址$IP1和$IP2，設(shè)置ISP1和ISP2的網(wǎng)關(guān)地址分別為$P1和$P2，網(wǎng)絡(luò)地址分別為$P1_NET和$P2_NET。配置如下：

隨后，設(shè)置缺省路由和路由規(guī)則，即選擇用什么路由表進(jìn)行路由轉(zhuǎn)發(fā)。需要確認(rèn)當(dāng)數(shù)據(jù)從一個(gè)給定接口路由出數(shù)據(jù)包時(shí)，是否已經(jīng)有了相應(yīng)的源地址，這就要求保證如果知道相應(yīng)的源地址，就能夠把數(shù)據(jù)包從相應(yīng)的網(wǎng)卡路由出去。以下命令保證所有的回應(yīng)數(shù)據(jù)按用戶訪問地址源線路進(jìn)和源線路出：

對高校而言，ISP分配給高校的IP地址資源有限，或多或少存在地址短缺的現(xiàn)狀。通過本方案，可以節(jié)約IP地址資源，減少應(yīng)用服務(wù)器管理配置。

域名解析采用“智能DNS”，將用戶訪問引導(dǎo)到最優(yōu)的資源上

根據(jù)訪問者來源，將訪問請求解析到合適的運(yùn)營商鏈路上?？筛鶕?jù)資源狀況，選擇商業(yè)產(chǎn)品或者使用BIND view功能【2】。BIND配置示例如下：

acl "CERNET" {

//https://www.nic.edu.cn/RS/ipstat/

//region=BJ

162.105/16; 166.111/16; 202.4.128/19;

}

此配置中，以CERNET為例定義了ISP IP地址段的訪問控制策略（ACL），來自這個(gè)IP范圍的用戶請求解析域名時(shí)，會從特定的數(shù)據(jù)庫查詢解析IP地址并回復(fù)給用戶，實(shí)現(xiàn)按照用戶來源優(yōu)化使用ISP鏈路資源的功能。其他ISP的訪問控制也可以參照此建立視圖保證用戶的高速訪問。

NGINX 體系集中訪問者請求，轉(zhuǎn)發(fā)到真實(shí)服務(wù)器

NGINX配置示例【3】如下：

此配置中，UPSTREAM為提供服務(wù)的原始服務(wù)器（上游服務(wù)器）。

利用Memcache緩存靜態(tài)資源

Memcache是分布式內(nèi)存高速緩存，內(nèi)置于NGINX中，適合混存網(wǎng)頁靜態(tài)對象，可以降低原始Web服務(wù)器因IO瓶頸造成的性能問題。配置示例【4】如下：

配置中把所有請求URI的訪問用Memcached模塊進(jìn)行內(nèi)容讀取，同時(shí)使用請求URI作為Memcached的key。當(dāng)緩存沒有命中或者出錯(cuò)時(shí)，調(diào)用@fallback進(jìn)行處理（比如訪問實(shí)際的應(yīng)用并重新寫入緩存）。

NGINGX默認(rèn)將資源緩存到硬盤。當(dāng)無法從原始服務(wù)器獲取最新的內(nèi)容時(shí)，NGINX可以分發(fā)緩存中已有的內(nèi)容。避免了因關(guān)聯(lián)緩存內(nèi)容的原始服務(wù)器宕機(jī)或者繁忙時(shí)，返回客戶端錯(cuò)誤信息，而可以發(fā)送其內(nèi)存中已有的文件。考慮到訪問量大后的文件系統(tǒng)承載能力問題，本文架構(gòu)中使用Memcache緩存到內(nèi)存，通過配置UPSTREAM支持訪問多個(gè)Memcached服務(wù)節(jié)點(diǎn)。同時(shí)，設(shè)置緩存過期時(shí)間，并在緩存內(nèi)容前添加瀏覽器緩存相關(guān)的響應(yīng)頭，將將頁面緩存在瀏覽器中，從而不必每次訪問都請求服務(wù)器。

安全管理

屏蔽對真實(shí)服務(wù)器的直接訪問，轉(zhuǎn)發(fā)經(jīng)過適當(dāng)過濾的Web訪問。由于NGINX對Web的轉(zhuǎn)發(fā)工作于應(yīng)用層，NGINX可以設(shè)置一些轉(zhuǎn)發(fā)規(guī)則來屏蔽對敏感信息的訪問，有利于提高Web整體安全性。

NGINX設(shè)置轉(zhuǎn)發(fā)過濾規(guī)則

由于個(gè)別系統(tǒng)管理員的疏忽，可能會把本該限定在校內(nèi)訪問的資源（如后臺管理、數(shù)據(jù)備份等）暴露在互聯(lián)網(wǎng)上，增加了安全隱患。在NGINX下，可以設(shè)置全局或針對特定Web系統(tǒng)的過濾規(guī)則來降低安全風(fēng)險(xiǎn)。配置示例【5】如下：

此配置中，屏蔽了對admin目錄和rar、zip后綴文件的訪問。

可增加WAF模塊提供更全面的Web安全防護(hù)功能

傳統(tǒng)的防火墻工作在網(wǎng)絡(luò)層，這種方式對于Web應(yīng)用沒有任何的防護(hù)。IDS/IPS作為防火墻的有利補(bǔ)充，加強(qiáng)了Web的安全防御能力。但是，IDS/IPS需要預(yù)先構(gòu)造攻擊特征庫來匹配網(wǎng)絡(luò)數(shù)據(jù)，技術(shù)本身存在一定的局限性。

與傳統(tǒng)防火墻及IDS/IPS不同，Web應(yīng)用防火墻（Web Application Firewall，WAF）工作在應(yīng)用層，一般位于Web應(yīng)用服務(wù)器前，可以從行為來分析應(yīng)用層的流量以發(fā)現(xiàn)安全威脅，幫助減少由于開發(fā)人員的疏漏造成的常見攻擊問題。將發(fā)現(xiàn)的漏洞作為自定義規(guī)則嵌入WAF中，能夠減輕目前Web漏洞解決的滯后性問題。如果暫時(shí)沒有配備商業(yè)WAF系統(tǒng)，可以選用NGINX兼容的WAF軟件，進(jìn)一步增強(qiáng)Web安全防護(hù)能力。常見的有NAXS、ModSecurity等。

HTTPS卸載

HTTPS對Web應(yīng)用安全非常重要，越來越多的高校Web業(yè)務(wù)會使用HTTPS證書。與其把證書分散部署在各服務(wù)器相比，集中式的Web管理體系配合通配符型的證書更經(jīng)濟(jì)，管理更方便，同時(shí)降低了證書泄漏的風(fēng)險(xiǎn)，保證了安全性。

遺留Web系統(tǒng)啟用HTTPS協(xié)議時(shí)，往往會遇到網(wǎng)頁鏈接混亂問題，使用NGINX可以靈活的替換網(wǎng)頁內(nèi)容，也可以用rewrite解決這個(gè)問題。配置示例【6】如下：

在此配置中，NGINX對特定的連接進(jìn)行了全文查找并替換，可以在不修改原始網(wǎng)站或系統(tǒng)代碼的情況下，引導(dǎo)用戶使用HTTPS協(xié)議訪問系統(tǒng)，提高信息安全性。

Web管理和安全應(yīng)急響應(yīng)

應(yīng)對網(wǎng)站、Web應(yīng)用管理需求和安全事件應(yīng)急響應(yīng)時(shí)，使用NGINX作為應(yīng)用層代理，存在一個(gè)真實(shí)服務(wù)器與域名之間的管理問題。通常使用多個(gè)DNS系統(tǒng)來解決，但管理工作量較大，靈活性較差。通過借助合適的NGINX第三方模塊，可以簡化管理工作，提供更高的靈活性。

UPSTREAM的動態(tài)管理

通過UPSTREAM動態(tài)管理模塊提供的API接口構(gòu)建管理體系，利用管理平臺來管理Web系統(tǒng)域名與真實(shí)服務(wù)器（上游服務(wù)器）的對應(yīng)關(guān)系。下面以ngx_http_dyups_module為例【7-8】:

ngx_http_dyups_module提供的API接口為REST類型，REST API主要目的在于為App后臺提供后臺管理入口，可實(shí)現(xiàn)簡單的數(shù)據(jù)管理、單發(fā)/群發(fā)消息，開發(fā)者可以在控制臺上進(jìn)行簡單的數(shù)據(jù)管理、查看及測試。為了安全性，REST API僅提供HTTPS接口。添加UPSTREAM示例如下：

為安全應(yīng)急響應(yīng)提供快速處置接口

利用API接口，可以在發(fā)生安全事件時(shí)及時(shí)響應(yīng)，將出現(xiàn)問題的網(wǎng)站實(shí)時(shí)重定向到特定的頁面，盡可能降低影響。為自動化運(yùn)維和值班提供可靠的工具。

為開發(fā)環(huán)境、測試環(huán)境和生產(chǎn)環(huán)境提供快速切換

規(guī)范化的開發(fā)一般要區(qū)分開發(fā)環(huán)境和生產(chǎn)環(huán)境，甚至有些還需要測試環(huán)境。利用集中的Web管理體系，可以方便地切換上游開發(fā)、測試和生產(chǎn)服務(wù)器，對用戶的干擾較小。

屏蔽非授權(quán)域名使用校內(nèi)服務(wù)器資源

NGINX工作于應(yīng)用層，可以設(shè)置允許訪問的域名，避免非授權(quán)域名使用校內(nèi)IDC資源提供服務(wù)。

全面收集Web訪問日志

使用集中的Web管理體系，可以匯集所有的Web訪問日志，為“大數(shù)據(jù)”應(yīng)用提供素材，為網(wǎng)站日常維護(hù)提供依據(jù)。

運(yùn)行效果

根據(jù)業(yè)務(wù)類別和優(yōu)先級別，我們在校園網(wǎng)數(shù)據(jù)中心部署了兩套NGINX服務(wù)器集群，節(jié)點(diǎn)1負(fù)責(zé)學(xué)校主頁訪問控制，節(jié)點(diǎn)2則承載了200多個(gè)校內(nèi)院系和部門主頁的集中訪問。2017年7月最新數(shù)據(jù)統(tǒng)計(jì)顯示，節(jié)點(diǎn)1和節(jié)點(diǎn)2日頁面流量（Page View，PV）峰值均達(dá)百萬級，節(jié)點(diǎn)1為110萬，節(jié)點(diǎn)2為150萬，系統(tǒng)承載性能可靠。目前的方案從數(shù)據(jù)中心管理中遇到的實(shí)際問題出發(fā)，解決了校園網(wǎng)公網(wǎng)IP資源緊張，大量應(yīng)用系統(tǒng)配置繁瑣，開發(fā)完成后維護(hù)跟不上等狀況；對于一些核心的業(yè)務(wù)系統(tǒng)如教務(wù)管理系統(tǒng)，可能出現(xiàn)密集訪問高峰期，如集中選課、集中評教等，可以通過配置NGINX的負(fù)載均衡模塊來平衡流量。

[1] Bert Hubert. A very hands-on approach to iproute2, traffic shaping and a bit of netfilter. Linux Advanced Routing & Traffic Control HOWTO. 2002.From http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html

[2] Internet Systems Consortium, Inc. ("ISC"). BIND 9 Configuration Reference. BIND 9 Administrator Reference Manual. From https://ftp.isc.org/isc/bind9/cur/9.11/doc/arm/Bv9ARM.ch06.html

[3] NGINX documentation. Module ngx_http_proxy_module. 2017.From http://nginx.org/en/docs/http/ngx_http_proxy_module.html

[4] NGINX documentation. Module ngx_http_memcached_module. 2017.From http://nginx.org/en/docs/http/ngx_http_memcached_module.html

[5] NGINX documentation. Module ngx_http_access_module. 2017.From http://nginx.org/en/docs/http/ngx_http_access_module.html

[6] Igor Sysoev. NGINX documentation. configuring_https_servers. 2017.From http://nginx.org/en/docs/http/configuring_https_servers.html

[7] Update upstreams' config by restful interface. 2017.From https://github.com/yzprofile/ngx_http_dyups_module

[8] Stephen Corona, NGINX a practical guide to high performance, O’Reilly, 2017.