基于Nginx負載均衡的動態改進算法

張宇星，馬明棟，王得玉

(1.南京郵電大學 通信與信息工程學院，江蘇 南京 210003；2.南京郵電大學 地理與生物信息學院，江蘇 南京 210003)

0 引 言

隨著互聯網的快速發展，PC端、移動端的逐漸興起，早期的單臺服務器已經難以處理用戶多樣化的并發請求。通過服務器集群的負載均衡技術能有效地分散單臺服務器的訪問壓力，還能有效避免當一臺Web服務器發生故障或遭到攻擊無法對外提供服務時，整個服務無法進行的狀況[1]。當集群中的Web服務器宕機時，通過負載均衡技術可以將訪問流量轉移給集群中其他的服務器。負載均衡技術通過均衡后端服務器的壓力，高效利用所有的后端服務器，提高整個服務器集群的性能。負載均衡的實現主要包括硬件和軟件兩個方面[2]。與基于硬件的負載均衡設備相比，基于軟件的負載均衡不需要獨立的機器設備，通過在服務器上安裝和配置軟件來實現負載均衡，配置靈活，可擴展性強，成本也較低[3]。LVS和Nginx是比較常見的基于軟件的負載均衡，LVS工作在網絡的第四層，作為請求的轉發，沒有流量，而Nginx工作在網絡的第七層，可以高效地處理HTTP應用，可使用的場合也多于LVS，因此文中將主要研究Nginx的負載均衡。

Nginx是由俄羅斯人開發的一款開源Web服務器軟件，占用資源低，處理請求快，模塊化設計，可擴展性好，配置靈活，采用異步、非阻塞、事件驅動的方式處理請求，并發量高，具有反向代理和緩存服務功能[4-5]。在實際中應用非常廣泛，目前國內的很多企業也都采用Nginx作為負載均衡和反向代理的Web服務器[6]。

負載均衡算法對Nginx負載均衡技術起著關鍵作用，文中通過研究Nginx自帶的負載均衡算法，提出一種動態的改進算法，以有效提高服務器集群的性能。

1 Nginx體系架構

Nginx服務器啟動后，產生一個Master進程，由Master進程產生多個Worker進程。Master進程負責管理多個Worker進程，而Worker進程則負責接收并處理客戶端的請求[7]。Nginx的主要配置文件nginx.conf在編譯安裝好的nginx/conf目錄下可以找到，打開文件可以觀察到其大致結構，如圖1所示。在文件中配置worker進程數、連接數等參數可以達到Nginx性能調優的效果。其中全局塊主要是配置Nginx的用戶組，工作進程數，進程pid的存放路徑等。events塊主要配置工作進程的最大連接數。http全局塊主要配置sendfile和超時信息以及文件的引入等。server塊和location塊主要配置主機的服務信息等。

圖1 nginx.conf配置文件結構

Nginx負載均衡的實現就是源于Nginx高效的反向代理服務[8]。反向代理服務的對象是服務器端，客戶端并不知道實際處理請求的機器是哪一臺。反向代理服務器收到來自客戶端的請求，將請求轉發給后端服務器處理。外部客戶不能直接訪問真實的服務器,即使遭到惡意攻擊，也能保證后端服務器的安全[9]。Nginx的反向代理服務由proxy_pass URL來配置，反向代理配置如下：

upstream mynginx{

server 192.168.168.161;

server 192.168.168.163;

}

server {

listen 80;

server_name localhost 192.168.168.162;

resolver8.8.8.8;

location / {

proxy_pass http://mynginx;

include proxy_params;

}

}

當客戶端的請求發送過來時，Nginx利用proxy_pass指令進行代理轉發，然后在upstream模塊中根據負載均衡算法將請求分配給后端服務器[10]。

Nginx服務器接收客戶端的請求時，并不會立即轉發給上游的Web服務器，而是如圖2所示，在Nginx反向代理服務器上設置緩存，以鍵值對的形式存儲在內存或者硬盤中，獲得完整的HTTP請求包后再將完整的請求發給上游服務器[11]。并且對于一些靜態資源，Nginx通過使用proxy_cache將用戶的請求緩存到本地一個目錄。當下一次有相同請求轉到代理服務器時，會先查看本地緩存，如果找到了該請求則直接返回給客戶端，如果本地緩存中沒有找到，再將請求轉發到后端Web服務器，減少了Nginx與后端Web服務器的連接次數，加快了響應速度，提高了Nginx處理性能[12]。

圖2 Nginx反向代理模型

2 算法改進設計

常見的負載均衡算法主要有加權輪詢、最小連接數、ip_hash、url_hash和fair算法[13]。加權輪詢算法按照預先分配的權重輪流分發給各個服務器節點，沒有考慮服務器的連接數和實時負載。ip_hash和url_hash針對Http應用本身來做分流策略，將客戶端請求按ip或url的哈希結果分配[14]。可以避免用戶每次訪問的服務器不同，使得session落在不同的服務器上，造成用戶端cookie驗證失敗等問題，但是容易導致某臺服務器節點的壓力變得非常大而其他節點卻空閑的不均衡現象。最小連接數和fair算法考慮的指標也過于單一，因此算法的均衡效果也不是很明顯[15]。

文中在Nginx的官網下載nginx-1.14.2版本的源碼，在源碼的src/http目錄下可以找到默認的加權輪詢算法ngx_http_upstream_round_robin.c文件。文件中的ngx_http_upstream_get_peer函數計算每一個后端服務器的權值，在函數中定義指針*peer和*best,通過for循環遍歷后端服務器。再通過best指針選取權值最大的服務器，將 best指針作為ngx_http_upstream_get_peer函數的返回值。函數中權值的部分計算代碼如下：

peer->current_weight+=peer->effective_weight;

total+=peer->effective_weight;

if(peer->effective_weightweight) {

peer->effective_weight++;

}

if(best==NULL||peer->current_weight>best->current_weight) {

best=peer;

p=i;

}

文中提出的動態改進算法是在加權輪詢算法的基礎上通過動態收集實時負載和硬件利用率，建立數學模型，得出動態反饋的負載均衡算法。

首先用Si表示服務器集群中的每個節點，Ci表示每個服務器節點的性能，服務器節點的默認權值為：

(1)

用Uc(i)，Um(i)，Ud(i)和Ub(i)分別表示周期T內單個節點的CPU、內存、磁盤IO和網絡帶寬的占用率，不同指標對服務器性能影響不同，Kc,Km,Kd,Kb分別表示CPU、內存、磁盤IO和網絡帶寬對服務器的影響因子[16]，并且Kc+Km+Kd+Kb=1。每個節點性能的實時負載比重WN(i)為：

WN(i)=

(2)

在最小連接數算法中，當有請求分發過來時，連接數加1，當請求處理完成時，連接數減1。文中提出的動態改進算法也將考慮每個節點的實時連接數Ni={N1,N2,…,Nn}，每個節點的連接數占比為：

(3)

當服務器節點負載較重時，請求的響應時間就比較長，所以響應時延也是衡量服務器節點實時負載的一個重要因素。然后考慮請求的響應時間，在Nginx的日志文件中提取每個節點服務器在周期T內的最近一次請求時間，Ti={T1,T2,…,Tn}，后端服務器集群最近一次的響應平均時間為：

(4)

服務器節點的響應時間比重為：

Wt(i)=Ti/Avg(T)

(5)

綜合節點的實時性能，連接數和響應時間建立數學模型：

Wi=(1-WN(i))*Wd(i)+(1-Wc(i))*

Wd(i)+(1-Wt(i))*Wd(i)

(6)

將三個因素的權值動態相加得到實時的權值，即每個服務器節點的權值計算如下：

Wi=(3-WN(i)-Wc(i)-Wt(i))*Wd(i)

(7)

將計算所得結果與ngx_http_upstream_get_peer函數中的effective_weight結合，通過best指針返回權值最大的服務器節點。

3 實驗環境搭建與測試

實驗在虛擬機中搭建了五臺服務器，一臺作為客戶端測試連接，一臺作為反向代理服務器，其余三臺作為后端服務器。在后端服務器中搭建Nginx+php環境來實現動態的網站運行環境。Nginx通過fastcgi接口來實現與php文件的交互。在server模塊的location配置中引入一個index.php動態資源文件，放置在location中的root目錄下，location的配置如下：

location ～ .php$ {

root html;

fastcgi_index index.php;

fastcgi_pass 127.0.0.1:9000;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

include fastcgi_params;

}

實驗環境搭建好后使用Httperf和Autobench來進行性能測試，Httperf可以根據每一次不同的測試要求產生不同的工作負載，而Autobench是一款基于Httperf開發的perf 腳本工具，可以根據參數設置自動進行并發測試，并將結果保存在.tsv文件中[17-18]。在客戶端中鍵入如下命令進行測試：

autobench --single_host --host1 192.168.168.162 --port1 80 --uri1 /index.php --quiet --low_rate 20 --high_rate 200 --rate_step 20 --num_call 10 --num_conn 500 --timeout 5 --file results.tsv

實驗中分別對默認輪詢算法、最小連接數算法以及文中提出的動態反饋算法進行測試，將得到的三個results.tsv文件進行整理，得到的統計數據如表1和表2所示。

表1 三種算法的響應時間

表2 三種算法的實際并發連接數

從表中數據可以看出，當并發量較低時，三種算法的響應時間相差不大，但當并發量達到600以上時，三種算法的響應時間都迅速增大，并且最小連接數算法的響應時間要小于默認輪詢算法，而文中提出的動態反饋算法響應時間則要優于其他兩種。Autobench測試時設置了timeout為5秒，超時5秒的連接都會當作請求失敗的連接。從表2中也可以看出，當并發數大于1 200時，實際處理的連接數都出現了不同程度的下降，但從整體來看，文中提出的動態算法成功處理的連接數要高于其他兩種算法。

4 結束語

服務器集群技術和負載均衡技術能有效減輕Web并發請求所帶來的后端服務器的壓力。而負載均衡算法又對負載均衡技術有著重要的影響。文中所提出的負載均衡優化算法不用每次都去實時地更新權值，而是在周期T之后重新收集負載信息，計算權值，分配權值，減少了每次都去重新計算、分配權值帶來的不必要的消耗。通過實驗數據對比，驗證了優化后的算法對負載均衡的性能有一定的提升。同時，在研究過程中，該算法也存在不足之處，對于時間周期T的取值，周期太長不能有效反映當前服務器節點的性能，周期太短頻繁取值造成性能下降，對于這兩方面的平衡還有待進一步的研究。