Haproxy和Nginx負載均衡測試效果對比記錄


 

為了對比Hproxy和Nginx負載均衡的效果,分別在測試機上(以下實驗都是在單機上測試的,即負載機器和后端機器都在一台機器上)做了這兩個負載均衡環境,並各自抓包分析。
下面說下這兩種負載均衡環境下抓包分析后的結果:

1)Haproxy負載均衡環境下的實驗記錄。后端有一台機器掛掉后,如果還沒達到探測的時間點時,請求還會往掛掉的這台機器轉發,請求會丟失。
Haproxy負載均衡的實驗記錄如下:
1--先看下Haproxy的配置。
配置inter 20000為20s檢測一次,這個是為了更明顯的抓下HAProxy的負載均衡探測機制。
[root@wangshibo ~]# cat /usr/local/haproxy/conf/haproxy.cfg

........
listen test9090
bind 127.0.0.1:9090
mode tcp
server localhost90 127.0.0.1:90 check inter 20000
server localhost91 127.0.0.1:91 check inter 20000

2--后端機器的Nginx的配置
[root@wangshibo ~]# cat /usr/local/nginx/conf/vhost/test.conf

server {
    listen  90;
    listen  91;
    location /{
      root /var/www/html;
    }
}

先在/var/www/html里創建一個首頁index.html文件
[root@wangshibo ~]# echo "this is test" > /var/www/html/index.html
然后測試訪問,並在機器上開兩個窗口看下抓包是否均衡正常,兩個窗口運行的命令分別如下:
[root@wangshibo ~]# curl 127.0.0.1:9090
[root@wangshibo ~]# tcpdump -i lo -nn 'port 90'
[root@wangshibo ~]# tcpdump -i lo -nn 'port 91'

上面抓包的截圖證明Nginx監聽的90和91端口都有在監聽。使用抓包來檢測比看日志來更細點,所以還是用抓包來分析了。

3--抓包查看HAProxy的健康檢測機制
因為前面haproxy里配置了inter 20000,也就是告訴HAProxy 20s檢測一次,抓包查看也是20s檢查一下。
注意:這個檢測是在客戶端無任務請求的時候進行探測的,也就是處理請求跟探測是分開的。

4--模擬線上故障,Nginx掛掉91端口
把listen 91這個Nginx的配置去除,然后reload nginx,會發現前端的請求如果分發到91端口的話,就會掛掉,經抓包發現HAProxy需要探測三次才會把故障的給切下線。我們配置的是20s探測一次,也是最長可能得探測60s才能把故障的切除掉。如果這60s內有1w請求的話,那就會丟掉5k個。如果用在線上的話,探測機制肯定不會是20s一次,一般最多3s會切換掉。

2)Nginx負載均衡環境下的實驗記錄

1--Nginx的反向代理負載均衡配置,如下:
[root@wangshibo ~]# cat /usr/local/nginx/conf/vhost/LB.conf

upstream backend {   
    server 127.0.0.1:90 weight=1 max_fails=3 fail_timeout=30;
    server 127.0.0.1:91 weight=5 max_fails=3 fail_timeout=30;        
    }

server {
     listen 9090;
     location / {
     proxy_pass http://backend;
     }        
    }

前端還是使用9090來監聽,把請求轉發到90和91端口。
2--后端Nginx配置如下。可在/var/www/html/建個index.html進行測試
[root@wangshibo ~]# cat /usr/local/nginx/conf/vhost/test.conf

server {
    listen  90;
    listen  91;
    location /{
      root /var/www/html;
    }
}

在/var/www/html里創建一個首頁index.html文件
[root@wangshibo ~]# echo "this is test2" > /var/www/html/index.html

3--抓包查看Nginx反向代理負載均衡的健康檢測機制。抓包同樣會發生90和91的包都有過來。
抓包會發現Nginx在沒有請求的時候,90和91端口上沒有任務的請求。也就是在沒有請求的時候,是不會對后端的代理服務器進行檢測的。

4--模擬線上故障,Nginx掛掉91端口
把listen 91這個Nginx的配置去除,然后reload一下,發現前端的訪問沒有任務影響。抓包如下,請求有打包91,但由於91沒請求到數據。Nginx的均衡還會再次去90上取數據。也就是說,Nginx如果后端掛掉91端口的話,對前端的請求沒有任務影響,只要並發支撐得住的話。

由上面的實驗可知:
1)HAProxy對於后端服務器一直在做健康檢測(就算請求沒過來的時候也會做健康檢查):
后端機器故障發生在請求還沒到來的時候,haproxy會將這台故障機切掉,但如果后端機器故障發生在請求到達期間,那么前端訪問會有異常。也就是說HAProxy會把請求轉到后端的這台故障機上,並經過多次探測后才會把這台機器切掉,並把請求發給其他正常的后端機,這勢必會造成一小段時間內前端訪問失敗。
2)Nginx對於后端的服務器沒有一直在做健康檢測:
后端機器發生故障,在請求過來的時候,分發還是會正常進行分發,只是請求不到數據的時候,它會再轉向好的后端機器進行請求,直到請求正常為止。也就是說Nginx請求轉到后端一台不成功的機器的話,還會再轉向另外一台服務器,這對前端訪問沒有什么影響。
3)因此,如果有用HAProxy做為前端負載均衡的話 ,如果后端服務器要維護,在高並發的情況,肯定是會影響用戶的。但如果是Nginx做為前端負載均衡的話,只要並發撐得住,后端切掉幾台不會影響到用戶。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM