隨著網絡流量的增加,服務器開始面臨繁重負載,這時就需要搭配一套HTTP負載均衡系統了,那麼Linux下該如何配置HTTP負載均衡系統呢?隨小編一起來學習一下吧。
如今對基於互聯網的應用和服務的要求越來越大,這給廣大的IT管理員施加了越來越大的壓力。面對突如其來的流量猛增、自生的流量增加或者是內部挑戰(比如硬件故障和緊急維護),不管怎樣,你的互聯網應用都必須保持隨時可用。連現代化的開發運營和持續交付做法也會危及互聯網服務的可靠性和一貫表現。
無法預測或缺乏一貫的表現是你所無法承受的。那麼,我們如何能消除這些缺點呢?在大多數情況下,一套合適的負載均衡解決方案有望滿足這個要求。今天我將為各位介紹如何使用HAProxy搭建一套HTTP負載均衡系統。
HTTP負載均衡簡介
HTTP負載均衡是一種網絡解決方案,負責在托管相同應用內容的幾台服務器之間分配進入的HTTP或HTTPS流量。由於在多台可用服務器之間均衡了應用請求,負載均衡系統就能防止任何應用服務器變成單一故障點,因而提高了整體的應用可用性和響應能力。它還讓你可以隨著不斷變化的工作負載,輕松地縮小/擴大部署的應用系統的規模,只需添加或刪除額外的應用服務器。
哪裡使用負載均衡、何時使用?
由於負載均衡系統改進了服務器的利用率,最大限度地提高了可用性,只要你的服務器開始面臨繁重負載,或者正為一個較龐大的項目規劃架構,就應該使用它。事先規劃好負載均衡系統的用途是個好習慣。那樣,未來你需要擴展環境規模時,它會證明其用途。
HAProxy是什麼東東?
HAProxy是一種流行的開源負載均衡和代理系統,面向GNU/Linux平台上的TCP/HTTP服務器。HAProxy采用了單一線程的事件驅動型架構而設計,它能夠輕松地處理10G網卡線路速度,現廣泛應用於許多生產環境中。其功能特性包括:自動檢查健康狀況、可定制的負載均衡算法、支持HTTPS/SSL以及會話速率限制等。
我們在本教程中要達到什麼樣的目的?
在本教程中,我們將逐步介紹為HTTP網站服務器配置基於HAProxy的負載均衡系統這個過程。
前提條件
你至少需要一台(最好是兩台)網站服務器來證實所搭建負載均衡系統的功能。我們假設,後端HTTP網站服務器已經搭建並運行起來。
將HAProxy安裝到Linux上
就大多數發行版而言,我們可以使用你所用發行版的軟件包管理器來安裝HAProxy。
將HAProxy安裝到Debian上
在Debian中,我們需要為Wheezy添加向後移植功能。為此,請在/etc/apt/sources.list.d中創建一個名為“backports.list”的新文件,其內容如下:
deb http://cdn.debian.net/debian wheezybackports main
更新你的軟件庫數據,並安裝HAProxy。
# apt get update # apt get install haproxy
將HAProxy安裝到Ubuntu上
# apt get install haproxy
將HAProxy安裝到CentOS和RHEL上
# yum install haproxy
配置HAProxy
在本教程中,我們假設有兩台HTTP網站服務器已搭建並運行起來,其IP地址分別為192.168.100.2和192.168.100.3。我們還假設,負載均衡系統將在IP地址為192.168.100.4的那台服務器處進行配置。
為了讓HAProxy發揮功用,你需要更改/etc/haproxy/haproxy.cfg中的幾個項目。這些變更在本章節中予以描述。萬一某個配置對不同的GNU/Linux發行版而言有所不同,會在相應段落中加以注明。
1. 配置日志功能
你首先要做的工作之一就是,為你的HAProxy建立合適的日志功能,這對將來進行調試大有用處。日志配置內容位於/etc/haproxy/haproxy.cfg的global部分。下面這些是針對特定發行版的指令,用於為HAProxy配置日志。
CentOS或RHEL:
要想在CentOS/RHEL上啟用日志功能,把:
log 127.0.0.1 local2
換成:
log 127.0.0.1 local0
下一步,在/var/log中為HAProxy創建單獨的日志文件。為此,我們需要改動當前的rsyslog配置。為了讓配置簡單而清楚,我們將在/etc/rsyslog.d/中創建一個名為haproxy.conf的新文件,其內容如下。
$ModLoad imudp $UDPServerRun 514 $template Haproxy,“%msg%\n” local0.=info /var/log/haproxy.log;Haproxy local0.notice /var/log/haproxystatus.log;Haproxy local0.* ~
該配置將把基於$template的所有HAProxy消息隔離到/var/log中的日志文件。現在,重啟rsyslog,讓變更內容生效。
# service rsyslog restart
Debian或Ubuntu:
要想在Debian或Ubuntu上為HAProxy啟用日志功能,把:
log /dev/log local0 log /dev/log local1 notice
換成:
log 127.0.0.1 local0
下一步,為HAProxy配置單獨的日志文件,編輯/etc/rsyslog.d/中一個名為haproxy.conf的文件(或者Debian中的49-haproxy.conf),其內容如下。
$ModLoad imudp $UDPServerRun 514 $template Haproxy,“%msg%\n” local0.=info /var/log/haproxy.log;Haproxy local0.notice /var/log/haproxystatus.log;Haproxy local0.* ~
該配置將把基於$template的所有HAProxy消息隔離到/var/log中的日志文件。現在,重啟rsyslog,讓變更內容生效。
# service rsyslog restart
2. 設置默認值
下一步是為HAProxy設置默認變量。找到/etc/haproxy/haproxy.cfg中的defaults部分,把它換成下列配置。
log global mode http option httplog option dontlognull retries 3 option redispatch maxconn 20000 contimeout 5000 clitimeout 50000 srvtimeout 50000
上述配置推薦HTTP負載均衡器使用,但可能不是最適合你環境的解決方案。如果那樣,請參閱HAProxy參考手冊頁,進行適當的改動和調整。
3. 網站服務器集群的配置
網站服務器集群(Webfarm)的配置定義了可用的HTTP服務器集群。我們所建負載均衡系統的大部分設置都將放在這裡。現在,我們將創建一些基本的配置,我們的節點將在這裡加以定義。把從frontend部分到文件末尾的所有配置換成下列代碼:
listen webfarm *:80 mode http stats enable stats uri /haproxy?stats stats realm Haproxy\ Statistics stats auth haproxy:stats balance roundrobin cookie LBN insert indirect nocache option httpclose option forwardfor server web01 192.168.100.2:80 cookie node1 check server web02 192.168.100.3:80 cookie node2 check
“listen webfarm *:80”這一行定義了我們的負載均衡系統將偵聽哪些接口。出於本教程的需要,我將該值設為“*”,這讓負載均衡系統偵聽我們的所有接口。在實際場景下,這可能不合意,應該換成可從互聯網來訪問的某個接口。
stats enable stats uri /haproxy?stats stats realm Haproxy\ Statistics stats auth haproxy:stats
上述設置聲明,可以在http://《load-balancer-IP》/haproxy?stats處訪問負載均衡系統的統計數字。這種訪問由簡單的HTTP驗證以及登錄名“haproxy”和密碼“stats”來確保安全。這些設置應該換成你自己的登錄信息。如果你不想讓這些統計數字被人看到,那麼可以完全禁用它們。
上一頁12下一頁共2頁
下面是HAProxy統計數字的一個例子。
“balance roundrobin”這一行定義了我們將使用哪種類型的負載均衡。在本教程中,我們將使用簡單的輪叫調度算法,這對HTTP負載均衡來說完全綽綽有余。HAProxy還提供了其他類型的負載均衡:
•leastconn:連接數最少的服務器優先接收連接。
•source:對源IP地址進行哈希處理,用運行中服務器的總權重除以哈希值,即可決定哪台服務器將接收請求。
•uri:URI的左邊部分(問號前面)經哈希處理,用運行中服務器的總權重除以哈希值。所得結果決定哪台服務器將接收請求。
•url_param:變量中指定的URL參數將在每個HTTP GET請求的查詢串中進行查詢。你基本上可以將使用蓄意制作的URL(crafted URL)的請求鎖定於特定的負載均衡節點。
•hdr(name):HTTP頭《name》 將在每個HTTP請求中進行查詢,被定向到特定節點。
“cookie LBN in