haproxy

12.1　高性能負載均衡軟件HAProxy介紹

隨著互聯網業務的迅猛發展，大型電商平臺和門戶網站對系統的可用性和可靠性要求越來越高，高可用集群、負載均衡集群成為一種熱門的系統架構解決方案。在眾多的負載均衡集群解決方案中，有基于硬件的負載均衡設備，例如F5、Big-IP等，也有基于軟件的負載均衡產品，例如HAProxy、LVS、Nginx等。在軟件的負載均衡產品中，又分為兩種實現方式，分別是基于操作系統的軟負載實現和基于第三方應用的軟負載實現。LVS就是基于Linux操作系統實現的一種軟負載均衡，而HAProxy就是基于第三應用實現的軟負載均衡。本章將詳細介紹HAProxy這種基于第三方應用實現的負載均衡技術。

12.1.1　HAProxy簡介

HAProxy是一個開源的、高性能的、基于TCP（第四層）和HTTP（第七層）應用的負載均衡軟件，借助HAProxy可以快速、可靠地提供基于TCP和HTTP應用的負載均衡解決方案。HAProxy作為一個專業的負載均衡軟件，它的顯著優點如下：

·可靠性和穩定性非常好，可以與硬件級的F5負載均衡設備相媲美。

·最高可以同時維護40000～50000個并發連接，單位時間內處理的最大請求數為20000個，最大數據處理能力可達10Gbps。作為軟件級別的負載均衡來說，HAProxy的性能強大可見一斑。

·支持多于8種負載均衡算法，同時也支持session保持。

·支持虛擬主機功能，這樣實現Web負載均衡更加靈活。

·從HAProxy1.3版本后開始支持連接拒絕、全透明代理等功能，這些功能是其他負載均衡器所不具備的。

·HAProxy擁有一個功能強大的服務器狀態監控頁面，通過此頁面可以實時了解系統的運行狀況。

·HAProxy擁有功能強大的ACL支持，能給使用帶來很大方便。

HAProxy是借助于操作系統的技術特性來實現性能最大化的，因此，在使用HAProxy時，對操作系統進行性能調優是非常重要的。在業業務系統方面，HAProxy非常適用于那些并發量特別大且需要持久連接或四層和七層處理機制的Web系統，例如門戶網站或電商網站等。另外。HAProxy也可用于MySQL數據庫（讀操作）的負載均衡。

12.1.2　四層和七層負載均衡的區別

在12.1節中提到了HAProxy是一個四層和七層負載均衡器。下面簡單介紹下四層和七層的概念與區別。

所謂的四層就是ISO參考模型中的第四層。四層負載均衡器也稱為四層交換機，它主要是通過分析IP層及TCP/UDP層的流量實現的基于“IP+端口”的負載均衡。常見的基于四層的負載均衡器有LVS、F5等。

以常見的TCP應用為例，負載均衡器在接收到第一個來自客戶端的SYN請求時，會通過設定的負載均衡算法選擇一臺最佳的后端服務器，同時將報文中目標IP地址修改為后端服務器IP，然后直接轉發給該后端服務器，這樣一個負載均衡請求就完成了。從這個過程來看，一個TCP連接是客戶端和服務器直接建立的，而負載均衡器只不過完成了一個類似路由器的轉發動作。在某些負載均衡策略中，為保證后端服務器返回的報文可以正確傳遞給負載均衡器，在轉發報文的同時可能還會對報文原來的源地址進行修改。整個過程如圖12-1所示。

圖12-1　四層負載均衡器轉發原理

同理，七層負載均衡器也稱為七層交換機，位于ISO的最高層，即應用層，此時負載均衡器支持多種應用協議，常見的有HTTP、FTP、SMTP等。七層負載均衡器可以根據報文內容，再配合負載均衡算法來選擇后端服務器，因此也稱為“內容交換器”。比如，對于Web服務器的負載均衡，七層負載均衡器不但可以根據“IP+端口”的方式進行負載分流，還可以根據網站的URL、訪問域名、瀏覽器類別、語言等決定負載均衡的策略。例如，有兩臺Web服務器分別對應中英文兩個網站，兩個域名分別是A、B，要實現訪問A域名時進入中文網站，訪問B域名時進入英文網站，這在四層負載均衡器中幾乎是無法實現的，而七層負載均衡器可以根據客戶端訪問域名的不同選擇對應的網頁進行負載均衡處理。常見的七層負載均衡器有HAProxy、Nginx等。
這里仍以常見的TCP應用為例，由于負載均衡器要獲取到報文的內容，因此只能先代替后端服務器和客戶端建立連接，接著，才能收到客戶端發送過來的報文內容，然后再根據該報文中特定字段加上負載均衡器中設置的負載均衡器算法來決定最終選擇的內部服務器?？v觀整個過程，七層負載均衡器在這種情況下類似于一個代理服務器。整個過程如圖12-2所示。

圖12-2　七層負載均衡器代理實現原理

對比四層負載均衡器和七層負載均衡器運行的整個過程，可以看出，在七層負載均衡模式下，負載均衡器與客戶端及后端的服務器會分別建立一次TCP連接，而在四層負載均衡模式下，僅建立一次TCP連接。由此可知，七層負載均衡對負載均衡設備的要求更高，而七層負載均衡的處理能力也必然低于四層模式的負載均衡。

12.1.3　HAProxy與LVS的異同

通過上面兩小節的介紹，讀者應該基本清楚了HAProxy負載均衡與LVS負載均衡的優缺點和異同了。
下面就這兩種負載均衡軟件的異同做一個簡單總結。

1）兩者都是軟件負載均衡產品，但是LVS是基于Linux操作系統實現的一種軟負載均衡，而HAProxy是基于第三應用實現的軟負載均衡。

2）LVS是基于四層的IP負載均衡技術，而HAProxy是基于四層和七層技術、可提供TCP和HTTP應用的負載均衡綜合解決方案。

3）LVS工作在ISO模型的第四層，因此其狀態監測功能單一，而HAProxy在狀態監測方面功能強大，可支持端口、URL、腳本等多種狀態檢測方式。

4）雖然HAProxy功能強大，但是它的整體處理性能低于四層負載均衡模式的LVS，而LVS擁有接近硬件設備的網絡吞吐和連接負載能力。綜上所述，HAProxy和LVS各有優缺點，沒有好壞之分，要選擇哪個作為負載均衡器，要以實際的應用環境來決定。

12.2　HAProxy基礎配置與應用實例

HAProxy的安裝非常簡單，但是在配置方面稍微復雜了些。雖然官方給出的配置文檔多達百頁，但是HAProxy的配置并非這么復雜，因為HAProxy常用的配置選項是非常少的。只要掌握了常用的配置選項，基本就能玩轉HAProxy了，因此在下面的介紹中主要講解HAProxy中常用的選項。

12.2.1　快速安裝HAProxy集群軟件

可以在HAProxy的官網http://haproxy.1wt.eu/下載HAProxy的源碼包，這里以操作系統CentOS 6.3版本為例，下載的HAProxy是當前的穩定版本haproxy-1.4.24.tar.gz，安裝過程如下：

[root@haproxy-server app]# tar zcvf haproxy-1.4.24.tar.gz

[root@haproxy-server app]#cd haproxy-1.4.24 

[root@haproxy-server haproxy-1.4.24]#make TARGET=linux26 PREFIX=/usr/local/haproxy 

[root@haproxy-server haproxy-1.4.24]#make install PREFIX=/usr/local/haproxy 　　　# 將HAProxy 安裝到/usr/local/haproxy 下 

[root@haproxy-server haproxy-1.4.24]#mkdir /usr/local/haproxy/conf 　　　# HAProxy 默認不創建配置文件目錄，這里是創建HAProxy 配置文件目錄 
[root@haproxy-server haproxy-1.4.24]# cp examples/haproxy.cfg /usr/local/haproxy/conf 　　　# HAProxy 安裝完成后，默認安裝目錄中沒有配置文件，這里是將源碼包里面的示例配置文件復制到配置文件目錄

這樣，HAProxy就安裝完成了。

12.2.2　HAProxy基礎配置文件詳解

1.配置文件概述

根據功能和用途，HAProxy配置文件主要由5個部分組成，但有些部分并不是必需的，可以根據需要選擇相應的部分進行配置。

（1）global部分

用來設定全局配置參數，屬于進程級的配置，通常和操作系統配置有關。

（2）defaults部分

默認參數的配置部分。在此部分設置的參數值，默認會自動引用到下面的frontend、backend和listen部分中，因此，如果某些參數屬于公用的配置，只需在defaults部分添加一次即可。而如果在frontend、backend和listen部分中也配置了與defaults部分一樣的參數，那么defaults部分參數對應的值自動被覆蓋。

（3）frontend部分

此部分用于設置接收用戶請求的前端虛擬節點。frontend是在HAProxy 1.3版本之后才引入的一個組件，同時引入的還有backend組件。通過引入這些組件，在很大程度上簡化了HAProxy配置文件的復雜性。frontend可以根據ACL規則直接指定要使用的后端backend。

（4）backend部分

此部分用于設置集群后端服務集群的配置，也就是用來添加一組真實服務器，以處理前端用戶的請求。添加的真實服務器類似于LVS中的real server節點。

（5）listen部分

此部分是frontend部分和backend部分的結合體。在HAProxy 1.3版本之前，HAProxy的所有配置選項都在這個部分中設置。為了保持兼容性，HAProxy新的版本仍然保留了listen組件的配置方式。目前在HAProxy中，兩種配置方式任選其一即可。
2.HAProxy配置文件詳解

根據上面介紹的5個部分對HAProxy的配置文件進行講解。

（1）global部分配置示例如下：

global 
? log 127.0.0.1 local0 info 
? maxconn 4096 
? user nobody
? group nobody 
? daemon 
? nbproc 1 
? pidfile /usr/local/haproxy/logs/haproxy.pid

上述代碼中每個選項的含義如下。

·log：全局的日志配置，local0是日志設備，info表示日志級別。其中日志級別有err、warning、info、debug4種可選。這個配置表示使用127.0.0.1上的rsyslog服務中的local0日志設備，記錄日志等級為info。

·maxconn：設定每個HAProxy進程可接受的最大并發連接數，此選項等同于Linux命令行選項“ulimit -n”?！ser/group：設置運行HAProxy進程的用戶和組，也可使用用戶和組的uid和gid值來替代。

·daemon：設置HAProxy進程進入后臺運行。這是推薦的運行模式。

·nbproc：設置HAProxy啟動時可創建的進程數，此參數要求將HAProxy運行模式設置為daemon，默認只啟動一個進程。根據使用經驗，該值的設置應該小于服務器的CPU核數。創建多個進程，能夠減少每個進程的任務隊列，但是過多的進程可能會導致進程崩潰。

·pidfile：指定HAProxy進程的pid文件。啟動進程的用戶必須有訪問此文件的權限。

（2）defaults部分配置示例如下：

defaults 
? mode http 
? retries 3
? timeout connect 10s
? timeout client 20s 
? timeout server 30s
? timeout check 5s

上述代碼中每個選項的含義如下。

·mode：設置HAProxy實例默認的運行模式，有tcp、http、health三個可選值。
在此模式下，客戶端和服務器端之間將建立一個全雙工的連接，不會對七層報文做任何類型的檢查，默認為tcp模式，經常用于SSL、SSH、SMTP等應用。

·http模式：在此模式下，客戶端請求在轉發至后端服務器之前將會被深度分析，所有不與RFC格式兼容的請求都會被拒絕。

·health模式：目前此模式基本已經廢棄，不再多說。

·retries：設置連接后端服務器的失敗重試次數，如果連接失敗的次數超過這里設置的值，HAProxy會將對應的后端服務器標記為不可用。此參數也可在后面部分進行設置。

·timeout connect：設置成功連接到一臺服務器的最長等待時間，默認單位是毫秒，但也可以使用其他的時間單位后綴。

·timeout client：設置連接客戶端發送數據時最長等待時間，默認單位是毫秒，也可以使用其他的時間單位后綴?！imeout server：設置服務器端回應客戶端數據發送的最長等待時間，默認單位是毫秒，也可以使用其他的時間單位后綴。

·timeout check：設置對后端服務器的檢測超時時間，默認單位是毫秒，也可以使用其他的時間單位后綴。

（3）frontend部分

這是HAProxy配置文件的第三部分——frontend部分的配置，配置示例如下：

frontend 
? www bind *:80 
? mode http
  option httplog 
? option forwardfor
? option httpclose
? log global 
  default_backend htmpool

這部分通過frontend關鍵字定義了一個名為“www”的前端虛擬節點，上述代碼中每個選項的含義如下。

·bind：此選項只能在frontend和listen部分進行定義，用于定義一個或幾個監聽的套接字。bind的使用格式為： bind [<address>:<port_range>] interface <interface>其可以為主機名或IP地址，如果將其設置為“*”或“0.0.0.0”，將監聽當前系統的所有IPv4地址。port_range可以是一個特定的TCP端口，也可是一個端口范圍，小于1024的端口需要有特定權限的用戶才能使用。interface為可選選項，用來指定網絡接口的名稱，只能在Linux系統上使用。

·option httplog：在默認情況下，HAProxy日志是不記錄HTTP請求的，這樣很不方便HAProxy問題的排查與監控。通過此選項可以啟用日志記錄HTTP請求。

·option forwardfor：如果后端服務器需要獲得客戶端的真實IP，就需要配置此參數。由于HAProxy工作于反向代理模式，因此發往后端真實服務器的請求中的客戶端IP均為HAProxy主機的IP，而非真正訪問客戶端的地址，這就導致真實服務器端無法記錄客戶端真正請求來源的IP，而X-Forwarded-For則可用于解決此問題。通過使用forwardfor選項，HAProxy就可以向每個發往后端真實服務器的請求添加X-Forwarded-For記錄，這樣后端真實服務器日志可以通過“X-Forwarded-For”信息來記錄客戶端來源IP。

·option httpclose：此選項表示在客戶端和服務器端完成一次連接請求后，HAProxy將主動關閉此TCP連接。這是對性能非常有幫助的一個參數。

·log global：表示使用全局的日志配置，這里的global表示引用在HAProxy配置文件global部分中定義的log選項配置格式。

·default_backend：指定默認的后端服務器池，也就是指定一組后端真實服務器，而這些真實服務器組將在backend段進行定義。這里的htmpool就是一個后端服務器組。

（4）backend部分

接著介紹的是HAProxy配置文件的第四部分——backend部分的配置，配置示例如下：

backend htmpool
  mode http 
  option redispatch 
  option abortonclose
  balance roundrobin 
  cookie SERVERID 
  option httpchk GET /index.php 
  server web1 10.200.34.181:80 cookie server1 weight 6 check inter 2000 rise 2 fall 3 
  server web2 10.200.34.182:8080 cookie server2 weight 6 check inter 2000 rise 2 fall 3

這個部分通過backend關鍵字定義了一個名為htmpool的后端真實服務器組。上述代碼中每個選項的含義如下。

·option redispatch：此參數用于cookie保持的環境中。在默認情況下，HAProxy會將其請求的后端服務器的serverID插入cookie中，以保證會話的session持久性。而如果后端的服務器出現故障，客戶端的cookie是不會刷新的，這就會出現問題。此時，如果設置此參數，就會將客戶的請求強制定向到另外一臺健康的后端服務器上，以保證服務正常?！ption abortonclose：如果設置了此參數，可以在服務器負載很高的情況下，自動結束當前隊列中處理時間比較長的連接。·balance：此關鍵字用來定義負載均衡算法。目前HAProxy支持多種負載均衡算法，常用的有如下幾種：·roundrobin：是基于權重進行輪叫調度的算法，在服務器的性能分布比較均勻時，這是一種最公平、最合理的算法。此算法使用頻繁。

·static-rr：也是基于權重進行輪叫的調度算法，不過此算法為靜態方法，在運行時調整其服務器權重不會生效?！ource：是基于請求源IP的算法。此算法先對請求的源IP進行hash運算，然后將結果與后端服務器的權重總數相除后轉發至某臺匹配的后端服務器。這種方式可以使同一個客戶端IP的請求始終被轉發到某特定的后端服務器。·leastconn：此算法會將新的連接請求轉發到具有最少連接數目的后端服務器。在會話時間較長的場景中推薦使用此算法，例如數據庫負載均衡等。此算法不適合會話較短的環境中，例如基于HTTP的應用。·uri：此算法會對部分或整個URI進行hash運算，再經過與服務器的總權重相除，最后轉發到某臺匹配的后端服務器上?！ri_param：此算法會根據URL路徑中的參數進行轉發，這樣可保證在后端真實服務器數量不變時，同一個用戶的請求始終分發到同一臺機器上。

·hdr（<name>）：此算法根據http頭進行轉發，如果指定的http頭名稱不存在，則使用roundrobin算法進行策略轉發。

·cookie：表示允許向cookie插入SERVERID，每臺服務器的SERVERID可在下面的server關鍵字中使用cookie關鍵字定義。

·option httpchk：此選項表示啟用HTTP的服務狀態檢測功能。HAProxy作為一個專業的負載均衡器，它支持對backend部分指定的后端服務節點的健康檢查，以保證在后端backend中某個節點不能服務時，把從frotend端進來的客戶端請求分配至backend中其他健康節點上，從而保證整體服務的可用性。

option httpchk的用法如下： option httpchk <method> <uri> <version> 其中，各個參數的含義如下：

·method：表示HTTP請求的方式，常用的有OPTIONS、GET、HEAD幾種方式。一般的健康檢查可以采用HEAD方式進行，而不是采用GET方式，這是因為HEAD方式沒有數據返回，僅檢查Response的HEAD是不是狀態碼200。因此，相對于GET，HEAD方式更快、更簡單。

·uri：表示要檢測的URL地址，通過執行此URL，可以獲取后端服務器的運行狀態。在正常情況下將返回狀態碼200，返回其他狀態碼均為異常狀態。

·version：指定心跳檢測時的HTTP的版本號。

·server：這個關鍵字用來定義多臺后端真實服務器，不能用于defaults和frontend部分。使用格式為： server <name> <address>[:port] [param*] 其中，每個參數含義如下：

·<name>：為后端真實服務器指定一個內部名稱，隨便定義一個即可。

·<address>：后端真實服務器的IP地址或主機名。

·<port>：指定連接請求發往真實服務器時的目標端口。在未設定時，將使用客戶端請求時的同一端口。

·[param*]：為后端服務器設定的一系列參數，可用參數非常多，這里僅介紹常用的一些參數：

·check：表示啟用對此后端服務器執行健康狀態檢查。

·inter：設置健康狀態檢查的時間間隔，單位為毫秒。

·rise：設置從故障狀態轉換至正常狀態需要成功檢查的次數，例如，“rise 2”表示2次檢查正確就認為此服務器可用?！all：設置后端服務器從正常狀態轉換為不可用狀態需要檢查的次數，例如，“fall 3”表示3次檢查失敗就認為此服務器不可用。

·cookie：為指定的后端服務器設定cookie值，此處指定的值將在請求入站時被檢查，第一次為此值挑選的后端服務器將在后續的請求中一直被選中，其目的在于實現持久連接的功能。上面的“cookie server1”表示web1的serverid為server1。同理，“cookie server2”表示web2的serverid為server2。

·weight：設置后端真實服務器的權重，默認為1，最大值為256。設置為0表示不參與負載均衡。

·backup：設置后端真實服務器的備份服務器，僅僅在后端所有真實服務器均不可用的情況下才啟用。

（5）listen部分

HAProxy配置文件的第五部分——listen部分的配置，配置示例如下：
listen admin_stats 
  bind 0.0.0.0:9188 
  mode http 
  log 127.0.0.1 local0 err 
  stats refresh 30s 
  stats uri /haproxy-status
  stats realm welcome login\ Haproxy
  stats auth admin:admin~!@ 
  stats hide-version 
  stats admin if TRUE

這個部分通過listen關鍵字定義了一個名為“admin_stats”的實例，其實就是定義了一個HAProxy的監控頁面，每個選項的含義如下：·stats refresh：設置HAProxy監控統計頁面自動刷新的時間。

·stats uri：設置HAProxy監控統計頁面的URL路徑，可隨意指定。例如，指定“stats uri/haproxy-status”，就可以通過http://IP:9188/haproxy-status查看。

·stats realm：設置登錄HAProxy統計頁面時密碼框上的文本提示信息。

·stats auth：設置登錄HAProxy統計頁面的用戶名和密碼。用戶名和密碼通過冒號分割?？蔀楸O控頁面設置多個用戶名和密碼，每行一個。

·stats hide-version：用來隱藏統計頁面上HAProxy的版本信息。

·stats admin if TRUE：通過設置此選項，可以在監控頁面上手工啟用或禁用后端真實服務器，僅在haproxy1.4.9以后版本有效。至此，完整的一個HAProxy配置文件介紹完畢了。當然，這里介紹的僅僅是最常用的一些配置參數，要深入了解HAProxy的功能，可參閱官方文檔。

12.2.3　HAProxy的日志配置策略

默認情況下，HAProxy為了節省讀寫I/O所消耗的性能，沒有自動配置日志輸出功能，但是為了維護和調試方便，日志的輸出還是很有必要的，下面就簡單介紹下如何配置HAProxy的日志輸出功能。

由于這里使用的環境為CentOS6.3系統版本，因此系統默認的日志管理方式不再是syslog，而是rsyslog管理系統日志，rsyslog可以實現UDP日志接收、將日志寫入文件、將日志寫入數據庫等功能。那么首先檢測下rsyslog軟件包是否已經安裝到系統中，操作過程如下：

[root@haproxy-server ~]# rpm -q rsyslog rsyslog-5.8.10-8.el6.x86_64

如果已經安裝了rsyslog軟件包，接著需要修改rsyslog的配置文件，在/etc/rsyslog.d/目錄下創建haproxy.conf文件，內容如下：

 $ModLoad imudp
 $UDPServerRun 514 
 local3.* /usr/local/haproxy/logs/haproxy.log 
 local0.* /usr/local/haproxy/logs/haproxy.log

這里定義了兩種日志類型，并指定了日志的輸出路徑，其中：

第一行的“imudp”是模塊名，支持UDP協議。

第二行表示允許514端口接收使用UDP和TCP協議轉發過來的日志，而rsyslog在默認情況下，正是在514端口監聽UDP。其實也可以將上面haproxy.conf文件的內容直接寫到/etc/rsyslog.conf文件中。

然后，還需要修改/etc/sysconfig/rsyslog文件，修改為如下內容：

SYSLOGD_OPTIONS=”-c 2 -r -m 0″ ? ? ? ? ?? 其中，“-r”表示接收遠程日志。最后重啟rsyslog服務即可完成配置： [root@haproxy-server ~]# service rsyslog restart

要實現將HAProxy日志寫入指定的文件中，還需要在haproxy.cfg中配置對應的日志選項，這部分內容已經在上節中進行了詳細介紹，這里不再說明。

12.2.4　通過HAProxy的ACL規則實現智能負載均衡

由于HAProxy可以工作在七層模型下，因此，要實現HAProxy的強大功能，一定要使用強大靈活的ACL規則，通過ACL規則可以實現基于HAProxy的智能負載均衡系統。HAProxy通過ACL規則完成兩種主要的功能，分別是：

1）通過設置的ACL規則檢查客戶端請求是否合法。如果符合ACL規則要求，那么將放行；如果不符合規則，則直接中斷請求。

2）符合ACL規則要求的請求將被提交到后端的backend服務器集群，進而實現基于ACL規則的負載均衡。HAProxy中的ACL規則經常使用在frontend段中，使用方法如下：

acl 自定義的acl 名稱 acl 方法 -i [ 匹配的路徑或文件] 其中：

·acl：是一個關鍵字，表示定義ACL規則的開始。后面需要跟上自定義的ACL名稱。

·acl方法：這個字段用來定義實現ACL的方法，HAProxy定義了很多ACL方法，經常使用的方法有hdr_reg（host）、hdr_dom（host）、hdr_beg（host）、url_sub、url_dir、path_beg、path_end等。

·-i：表示不區分大小寫，后面需要跟上匹配的路徑或文件或正則表達式。與ACL規則一起使用的HAProxy參數還有use_backend，use_backend后面需要跟上一個backend實例名，表示在滿足ACL規則后去請求哪個backend實例，與use_backend對應的還有default_backend參數，它表示在沒有滿足ACL條件的時候默認使用哪個后端backend。下面列舉幾個常見的ACL規則例子：

acl www_policy  hdr_reg(host)  -i  ^(www.z.cn|z.cn) 
acl bbs_policy  hdr_dom(host)  -i  bbs.z.cn
acl url_policy  url_sub       -i          buy_sid=
use_backend  server_www       if         www_policy 
use_backend  server_app     if        url_policy 
use_backend  server_bbs     if          bbs_policy 
default_backend  server_cache

這里僅僅列出了HAProxy配置文件中ACL規則的配置部分，其他選項并未列出。

這些例子定義了www_policy、bbs_policy、url_policy三個ACL規則，第一條規則表示如果客戶端以www.z.cn或z.cn開頭的域名發送請求時，則此規則返回true，同理第二條規則表示如果客戶端通過bbs.z.cn域名發送請求時，則此規則返回true，而第三條規則表示如果客戶端在請求的URL中包含“buy_sid=”字符串時，則此規則返回true。

第四、第五、第六條規則定義了當www_policy、bbs_policy、url_policy三個ACL規則返回true時要調度到哪個后端backend，例如，當用戶的請求滿足www_policy規則時，那么HAProxy會將用戶的請求直接發往名為server_www的后端backend，其他以此類推。而當用戶的請求不滿足任何一個ACL規則時，HAProxy就會把請求發往由default_backend選項指定的server_cache這個后端backend。

再看下面這個例子：

acl url_static  path_end .gif .png .jpg .css .js 
acl host_www        hdr_beg(host) -i www 
acl host_static   hdr_beg(host) -i img. video. download. ftp. 
use_backend static    if host_static || host_www url_static 
use_backend www         if host_www 
default_backend            server_cache

與上面的例子類似，本例中也定義了url_static、host_www和host_static三個ACL規則，其中，第一條規則通過path_end參數定義了如果客戶端在請求的URL中以.gif、.png、.jpg、.css或.js結尾時返回true，第二條規則通過hdr_beg（host）參數定義了如果客戶端以www開頭的域名發送請求時則返回true，同理，第三條規則也是通過hdr_beg（host）參數定義了如果客戶端以img.、video.、download.或ftp.開頭的域名發送請求時則返回true。

第四、第五條規則定義了當滿足ACL規則后要調度到哪個后端backend，例如，當用戶的請求同時滿足host_static規則與url_static規則，或同時滿足host_www和url_static規則時，那么會將用戶請求直接發往名為static的后端backend，如果用戶請求滿足host_www規則，那么請求將被調度到名為www的后端backend，如果不滿足所有規則，那么將用戶請求默認調度到名為server_cache的這個后端backend。

12.3基于虛擬主機的HAProxy負載均衡系統配置實例

前面的兩節詳細介紹了HAProxy的安裝、配置以及ACL規則的使用，要熟練掌握HAProxy的使用，必須進行實戰性操作，那么本節將通過一個具體的實例詳細講解和演示HAProxy下虛擬主機的實現過程以及HAProxy是如何實現負載均衡和故障轉移的。

12.3.1　通過HAProxy的ACL規則配置虛擬主機

下面將通過HAProxy的ACL功能配置一套基于虛擬主機的負載均衡系統，這里的操作系統環境為CentOS release 6.3，HAProxy版本為haproxy-1.4.24，要實現的功能如圖12-3所示。

圖12-3　基于虛擬主機的HAPro y應用實例本實例

有一個電商網站服務器群、一個論壇服務器群、一個博客服務器群和默認服務器群，4個服務器群都由多臺服務器組成，而4個服務器群又組成了一個應用服務器群組，在每個服務器群的前端有一個基于HAProxy的負載均衡調度器，整個應用架構要實現的功能為：當客戶端通過域名www.tb.com或tb.com訪問時，HAProxy將請求提交到電商網站服務器群，進而實現電商網站的負載均衡；當客戶端通過域名bbs.tb.com訪問時就將請求調度到論壇服務器群，實現論壇的負載均衡；當客戶端通過blog.tb.com訪問時則將請求調度到博客服務器群中，實現博客的負載均衡；如果客戶端通過除上面三種方式外的任意方式請求服務時，就將請求調度到缺省服務器群。

要實現上述功能，如果使用四層的LVS負載均衡器，則需要一個代理服務器配合LVS負載均衡器才能實現，而通過HAProxy實現時，僅需要一個HAProxy負載調度器再結合ACL規則即可輕松實現。

1.配置HAProxy

HAProxy的安裝非常簡單，前面已經做過介紹，這里直接進入HAProxy的配置過程，配置好的文件內容如下：

 global 

  log 127.0.0.1 local0 info 
  maxconn 4096 
  user nobody 
  group nobody 
  daemon
  nbproc 1 
  pidfile /usr/local/haproxy/logs/haproxy.pid 

defaults 

mode http 
retries 3 
timeout connect 5s
timeout client 30s 
timeout server 30s 
timeout check 2s l
isten admin_stats 
bind 0.0.0.0:19088 
mode http 
log 127.0.0.1 local0 err 
stats refresh 30s 
stats uri /haproxy-status 
stats realm welcome login\ Haproxy 
stats auth admin:xxxxxx 
stats auth admin1:xxxxxx 
stats hide-version 
stats admin if TRUE 

frontend www

bind *:80 
mode http 
option httplog 
option forwardfor
log global
acl host_www hdr_reg(host) -i ^(www.tb.com|tb.com) 
acl host_bbs hdr_dom(host) -i bbs.tb.com 
acl host_blog hdr_beg(host) -i blog.
use_backend server_www if host_www 
use_backend server_bbs if host_bbs 
use_backend server_blog if host_blog 
default_backend server_default 

backend server_default

 mode http 
option redispatch 
option abortonclose 
balance roundrobin 
cookie SERVERID 
option httpchk GET /check_status.html 
server default1 192.168.88.90:8000 cookie default1 weight 3 check inter 2000 rise 2 fall 3 
server default2 192.168.88.91:8000 cookie default2 weight 3 check inter 2000 rise 2 fall 3 

backend server_www

 mode http 
option redispatch 
option abortonclose
balance source 
cookie SERVERID 
option httpchk GET /check_status.jsp 
server www1 192.168.88.80:80 cookie www1 weight 6 check inter 2000 rise 2 fall 3 
server www2 192.168.88.81:80 cookie www2 weight 6 check inter 2000 rise fall 3 
server www3 192.168.88.82:80 cookie www3 weight 6 check inter 2000 rise 2 fall 3 

backend server_bbs 

mode http 
option redispatch
option abortonclose 
balance source 
cookie SERVERID 
option httpchk GET /check_status.php 
server bbs1 192.168.88.83:8080 cookie bbs1 weight 8 check inter 2000 rise 2 fall 3 
server bbs2 192.168.88.84:8090 cookie bbs2 weight 8 check inter 2000 rise 2 fall 3 

backend server_blog 

mode http 
option redispatch 
option abortonclose 
balance roundrobin
cookie SERVERID 
option httpchk GET /check_blog.php 
server blog1 192.168.88.85:80 cookie blog1 weight 5 check inter 2000 rise 2 fall 3 
server blog2 192.168.88.86:80 cookie blog2 weight 5 check inter 2000 rise 2 fall 3

關于HAProxy配置文件中每個選項的含義，前面已經做過詳細介紹，這里重點看一下frontend部分中關于ACL配置部分的內容，這個是實現虛擬主機的核心配置部分。另外，這個配置文件定義了server_www、server_bbs、server_blog、server_default4個backend，分別對應上面的4個服務器群，對于server_www群和server_bbs群，采用了基于請求源IP的負載均衡算法，其他兩個群均采用基于權重進行輪叫調度的算法。這也是根據Web應用的特點而定的。每個backend中都定義了httpchk的檢測方式，因此要保證這里指定的URL頁面是可訪問到的。

為了驗證負載均衡的功能，這里需要將后端真實服務器做一個訪問標記，這個架構一共加入了9臺后端真實服務器，共分為四組，這里將server_www的三臺后端服務器默認的Web頁面設置如下：

 [root@www1 app]# echo "This is www1 192.168.88.80" >/var/www/html/index.html 

[root@www2 app]# echo "This is www2 192.168.88.81" >/var/www/html/index.html 

[root@www3 app]# echo "This is www3 192.168.88.82" >/var/www/html/index.html

同理，將server_bbs的兩臺后端服務器默認的Web頁面設置如下：

 [root@bbs1 app]# echo "This is bbs1 192.168.88.83" >/var/www/html/index.html

[root@bbs1 app]# echo “This is bbs2 192.168.88.84" >/var/www/html/index.html

接著，將server_blog的兩臺后端服務器默認的Web頁面設置如下：

[root@blog1 app]# echo "This is blog1 192.168.88.85" >/var/www/html/index.html

 [root@blog2 app]# echo "This is blog2 192.168.88.86" >/var/www/html/index.html

最后，將server_default的兩臺后端服務器默認的Web頁面設置如下：

 [root@default1 app]# echo "This is default1 192.168.88.90" >/var/www/html/index.html 

[root@default2 app]# echo "This is default2 192.168.88.91" >/var/www/html/index.html

這樣就為接下來的測試做好了準備。

2.啟動HAProxy

HAProxy安裝完成后，會在安裝根目錄的sbin目錄下生成一個可執行的二進制文件haproxy，對HAProxy的啟動、關閉、重啟等維護操作都是通過這個二進制文件實現的，執行“haproxy -h”命令即可得到此文件的用法。

haproxy [-f < 配置文件>] [ -vdVD ] [-n 最大并發連接總數] [-N 默認的連接數]

haproxy常用的參數以及含義如表12-1所示。

表12-1　haproxy常用參數及含義

介紹完HAProxy常用的參數后，下面開始啟動HAProxy，操作如下：

[root@haproxy-server haproxy]# /usr/local/haproxy/sbin/haproxy -f \ > /usr/local/haproxy/conf/haproxy.cfg

如果要關閉HAProxy，執行如下命令即可：

[root@haproxy-server haproxy]# killall -9 haproxy

如果要平滑重啟HAProxy，可執行如下命令：

[root@haproxy-server haproxy]# /usr/local/haproxy/sbin/haproxy -f \ > /usr/local/haproxy/conf/haproxy.cfg -st `cat /usr/local/haproxy/logs/haproxy.pid`

有時候為了管理和維護方便，也可以把HAProxy的啟動與關閉寫成一個獨立的腳本

12.3.2　測試HAProxy實現虛擬主機和負載均衡功能

首先通過不同IP的客戶端以www.tb.com或者tb.com域名訪問網站，如果HAProxy運行正常，并且ACL規則設置正確，server_www的三臺后端服務器默認的Web頁面信息將會依次出現，這說明HAProxy對電商網站實現了負載均衡，同時，不會出現其他后端服務器的默認Web頁面信息，說明ACL規則生效，實現虛擬主機功能。
同理，當通過不同IP的客戶端以bbs.tb.com訪問網站時，server_bbs的兩臺后端服務器默認的Web頁面信息將輪換出現。這表示實現了論壇的負載均衡功能，同時，不會出現其他后端服務器的默認Web頁面信息，說明ACL規則生效，實現虛擬主機功能。

用同樣的方法可以驗證blog.tb.com是否實現了虛擬主機功能以及負載均衡功能。最后，當通過HAProxy服務器的IP或者其他方式訪問時，訪問請求將被調度到server_default指定的兩臺后端真實服務器上。

12.3.3　測試HAProxy的故障轉移功能

測試HAProxy的故障轉移功能也非常簡單，這里假定將server_www組的一臺后端服務器192.168.88.82的httpd服務停止，那么當通過www.tb.com或者tb.com域名訪問網站時，這個失效的節點將不會被訪問到，因為當httpd服務被停止后，HAProxy通過httpchk方式將立刻檢測到此節點無法返回數據，從而屏蔽此節點對外提供服務的功能，這樣就實現了故障轉移功能。通過類似的方法可以測試其他節點的應用。

12.3.4　使用HAProxy的Web監控平臺

雖然HAProxy實現了服務的故障轉移功能，但是在主機或者服務出現故障的時候，并不能發出通知告知運維人員，這對于及時性要求很高的業務系統來說，是非常不便的。不過，HAProxy似乎也考慮到了這一點，在新的版本中HAProxy推出了一個基于Web的監控平臺，通過這個平臺可以查看此集群系統所有后端服務器的運行狀態，在后端服務或服務器出現故障時，監控頁面會通過不同的顏色來展示故障信息，這在很大程度上解決了后端服務器故障報警的問題，運維人員可通過監控這個頁面來第一時間發現節點故障，進而修復故障，如圖12-4所示。

圖12-4　HAProxy的Web監控頁面

在這個監控頁面中，詳細記錄了HAProxy中配置的frontend、backend等信息。在backend中有各臺后端真實服務器的運行狀態，正常情況下，所有后端服務器都以淺綠色展示，當某臺后端服務器出現故障時，將以深橙色顯示。其實每種顏色代表什么狀態，在上面這個圖中都有詳細說明。

在這個監控頁面中，還可以執行關閉自動刷新、隱藏故障狀態的節點、手動刷新、導出數據為CSV文件等各種操作。在新版的HAProxy中，又增加了對backend后端節點的管理功能，例如，可以在Web頁面下執行Disable、Enable、Soft Stop、Soft Start等對后端節點的管理操作。這個功能在后端節點升級、故障維護時非常有用。