基于NGINX的Web集中管理架構設計與實現

文/鄒艷玲 宋曉輝 常征

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

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

系統架構

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

架構通過“無狀態”來降低管理成本。所謂“無狀態”，是指每一臺服務器的作用對等，相應的軟件和配置一致。可以在核心NGINX層實現流量分組（如內外網隔離、爬蟲和非爬蟲流量隔離）、緩存靜態文件、請求頭過濾、故障切換（機房故障切換到其他機房）、流量控制、防火墻（FW）等一些通用型功能，支持水平擴容。調整服務器時，不需要針對不同服務器的“個性”化需求做配置，實現數據中心整體管理成本最低。

圖1 基于NGINX技術的綜合管理體系架構

提高Web訪問質量

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

策略路由、源線路進和源線路出

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

隨后，設置缺省路由和路由規則，即選擇用什么路由表進行路由轉發。需要確認當數據從一個給定接口路由出數據包時，是否已經有了相應的源地址，這就要求保證如果知道相應的源地址，就能夠把數據包從相應的網卡路由出去。以下命令保證所有的回應數據按用戶訪問地址源線路進和源線路出：

對高校而言，ISP分配給高校的IP地址資源有限，或多或少存在地址短缺的現狀。通過本方案，可以節約IP地址資源，減少應用服務器管理配置。

域名解析采用“智能DNS”，將用戶訪問引導到最優的資源上

根據訪問者來源，將訪問請求解析到合適的運營商鏈路上。可根據資源狀況，選擇商業產品或者使用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），來自這個IP范圍的用戶請求解析域名時，會從特定的數據庫查詢解析IP地址并回復給用戶，實現按照用戶來源優化使用ISP鏈路資源的功能。其他ISP的訪問控制也可以參照此建立視圖保證用戶的高速訪問。

NGINX 體系集中訪問者請求，轉發到真實服務器

NGINX配置示例【3】如下：

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

利用Memcache緩存靜態資源

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

配置中把所有請求URI的訪問用Memcached模塊進行內容讀取，同時使用請求URI作為Memcached的key。當緩存沒有命中或者出錯時，調用@fallback進行處理（比如訪問實際的應用并重新寫入緩存）。

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

安全管理

屏蔽對真實服務器的直接訪問，轉發經過適當過濾的Web訪問。由于NGINX對Web的轉發工作于應用層，NGINX可以設置一些轉發規則來屏蔽對敏感信息的訪問，有利于提高Web整體安全性。

NGINX設置轉發過濾規則

由于個別系統管理員的疏忽，可能會把本該限定在校內訪問的資源（如后臺管理、數據備份等）暴露在互聯網上，增加了安全隱患。在NGINX下，可以設置全局或針對特定Web系統的過濾規則來降低安全風險。配置示例【5】如下：

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

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

傳統的防火墻工作在網絡層，這種方式對于Web應用沒有任何的防護。IDS/IPS作為防火墻的有利補充，加強了Web的安全防御能力。但是，IDS/IPS需要預先構造攻擊特征庫來匹配網絡數據，技術本身存在一定的局限性。

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

HTTPS卸載

HTTPS對Web應用安全非常重要，越來越多的高校Web業務會使用HTTPS證書。與其把證書分散部署在各服務器相比，集中式的Web管理體系配合通配符型的證書更經濟，管理更方便，同時降低了證書泄漏的風險，保證了安全性。

遺留Web系統啟用HTTPS協議時，往往會遇到網頁鏈接混亂問題，使用NGINX可以靈活的替換網頁內容，也可以用rewrite解決這個問題。配置示例【6】如下：

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

Web管理和安全應急響應

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

UPSTREAM的動態管理

通過UPSTREAM動態管理模塊提供的API接口構建管理體系，利用管理平臺來管理Web系統域名與真實服務器（上游服務器）的對應關系。下面以ngx_http_dyups_module為例【7-8】:

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

為安全應急響應提供快速處置接口

利用API接口，可以在發生安全事件時及時響應，將出現問題的網站實時重定向到特定的頁面，盡可能降低影響。為自動化運維和值班提供可靠的工具。

為開發環境、測試環境和生產環境提供快速切換

規范化的開發一般要區分開發環境和生產環境，甚至有些還需要測試環境。利用集中的Web管理體系，可以方便地切換上游開發、測試和生產服務器，對用戶的干擾較小。

屏蔽非授權域名使用校內服務器資源

NGINX工作于應用層，可以設置允許訪問的域名，避免非授權域名使用校內IDC資源提供服務。

全面收集Web訪問日志

使用集中的Web管理體系，可以匯集所有的Web訪問日志，為“大數據”應用提供素材，為網站日常維護提供依據。

運行效果

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

[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.