Keepalived+HAProxy 搭建高可用負載均衡

1. 概述

軟件負載均衡技術(shù)是指可以為多個后端服務(wù)器節(jié)點提供前端IP流量分發(fā)調(diào)度服務(wù)的軟件技術(shù)。Keepalived和HAProxy是眾多軟負載技術(shù)中的兩種，其中Keepalived既可以實現(xiàn)負載均衡也可以實現(xiàn)高可用，而HAProxy則更加專注于提供高性能TCP和HTTP反向代理和負載均衡能力。

1.1 Keepalived

Keepalived工作在OSI模型中的四層傳輸層。最初它是為了管理并監(jiān)控Linux虛擬服務(wù)器（LVS）集群中各服務(wù)節(jié)點的狀態(tài)，后來又加入了路由冗余協(xié)議（VRRP）來實現(xiàn)高可用功能，所以Keepalived除了可以管理配置LVS外，還可以作為Nginx、HAProxy等的高可用解決方案。

Keepalived同時運行于主服務(wù)器（Master）和備服務(wù)器（Backup）之上，所有的服務(wù)器上運行的Keepalived之間通過VRRP交互，VRRP設(shè)計目的是為了解決靜態(tài)路由單點故障問題，保證個別節(jié)點宕機時，整個網(wǎng)絡(luò)可以不間斷的運行。

Keepalived不但可以實現(xiàn)主備服務(wù)器的高可用性，同時還可以管理LVS實現(xiàn)后端服務(wù)器的負載均衡并進行后端服務(wù)器節(jié)點的健康檢查。它啟動核心進程時讀取keepalived.conf配置文件。在主服務(wù)器上keepalived進程按照配置文件配置的負載均衡策略開啟LVS轉(zhuǎn)發(fā)并對后端服務(wù)進行健康檢查。利用VRRP協(xié)議主服務(wù)器周期性的發(fā)送廣播至備服務(wù)器，備服務(wù)器將會判斷主器服務(wù)器的狀態(tài)，如果在配置的同步超時時間內(nèi)主服務(wù)器節(jié)點未能發(fā)出廣播，那么keepalived將啟動高可用切換機制選出新的主服務(wù)器。切換過程中，原有主服務(wù)器上的虛擬地址（VIP）及負載能力將由新的主服務(wù)器來接替承載。

1.2 HAProxy

HAProxy 是一款TCP/HTTP 反向代理負載均衡服務(wù)器軟件，可工作在OSI模型中的四層傳輸層以及七層應(yīng)用層。HAProxy特別適用于那些負載壓力大的web站點，這些站點通常需要會話保持或七層處理。HAProxy運行在時下的服務(wù)器上，可以支持數(shù)以萬計的并發(fā)連接。并且它的運行模式使得它可以很簡單安全地整合進現(xiàn)有的系統(tǒng)架構(gòu)中，同時可以保護web服務(wù)器不被暴露到網(wǎng)絡(luò)上。HAproxy允許用戶定義多組服務(wù)代理，代理由前端和后端組成，前端定義了服務(wù)監(jiān)聽的IP及端口，后端則定義了一組服務(wù)器及負載均衡的算法。通過服務(wù)代理將流量由前端負載均衡至后端服務(wù)器節(jié)點上。

1.3 Keepalived和HAProxy組合

由于HAProxy會存在單點故障問題，可以由Keepalived來為HAProxy提供高可用服務(wù)，而HAProxy提供四層或七層高性能負載均衡及反向代理服務(wù)，兩者共同實現(xiàn)高可用負載均衡，結(jié)構(gòu)如圖1所示。

圖1 Keepalived+HAProxy

2. Keepalived功能及安裝配置

2.1 核心功能

1．管理LVS負載均衡軟件

Keepalived最初是專為解決LVS的問題而誕生的。因此，Keepalived和LVS可緊密結(jié)合。

2．實現(xiàn)對LVS集群節(jié)點健康檢查

當LVS集群中某個節(jié)點服務(wù)器發(fā)生故障時，Keepalived服務(wù)會自動將失效的節(jié)點從正常隊列中剔除，并將請求調(diào)度到別的正常的節(jié)點服務(wù)器上，從而保證用戶訪問不受影響。當故障節(jié)點被修復后，Keepalived服務(wù)又會自動切換回來。

3．網(wǎng)絡(luò)服務(wù)高可用功能

Keepalived可以實現(xiàn)任意兩臺主機之間，如Master服務(wù)器和Backup服務(wù)器間的故障轉(zhuǎn)移和自動切換。假設(shè)某個服務(wù)是不能停機的，如LVS負載均衡、Nginx反向代理服務(wù)器等，可以利用Keepalived保證其高可用性。

2.2 高可用原理

Keepalived高可用服務(wù)的故障切換轉(zhuǎn)移是通過VRRP機制來實現(xiàn)的。在Keepalived服務(wù)正常運行時，Master節(jié)點會不斷向Backup節(jié)點發(fā)送（多播方式）心跳信息，用以通知Master節(jié)點的存活狀態(tài)。當Master節(jié)點發(fā)生故障時，就無法發(fā)送心跳信息，Backup節(jié)點也就無法檢測到來自Master的心跳信息，于是調(diào)用自身的接管程序，接管Master的資源和服務(wù)。當Master恢復時，Backup又會釋放Master故障時自身接管的資源和服務(wù)，恢復到原來的備用角色。無論Master如何切換，對外都應(yīng)該提供相同的服務(wù)IP地址，該IP也稱作虛擬地址VIP?？蛻舳瞬⒉恍枰騇aster的改變而修改自己的配置，對他們來說這種切換是透明的。

路由冗余協(xié)議VRRP（Virtual Router Redundancy Protocol）早期是用來解決交換機、路由器等設(shè)備單點故障。VRRP通過競選機制來實現(xiàn)虛擬路由器的功能，所有的協(xié)議報文都是通過IP多播（Multicast）包形式來發(fā)送。在一組VRRP路由器集群中，有多臺物理路由器，但并不是同時工作，而是由一臺Master路由器負責路由工作，其他都是Backup，Master有一些特權(quán)，比如擁有VIP地址等，擁有系統(tǒng)資源的Master負責轉(zhuǎn)發(fā)發(fā)送給網(wǎng)關(guān)地址的包和響應(yīng)ARP請求。只有Master路由器會一直發(fā)送心跳信息，此時Backup不會搶占Master。當Master不可用時，Backup就收不到來自Master的心跳信息，此時多臺Backup中優(yōu)先級最高的路由器會搶占為Master，這種搶占非?？焖?，以保證服務(wù)的連續(xù)性。

2.3 安裝與配置

由于本文引用的技術(shù)構(gòu)架中Keepalived將僅為HAProxy提供高可用服務(wù)，所以管理配置LVS負載均衡及節(jié)點健康檢查功能將不準備展開篇幅，僅對高可用功能進行介紹演示。

2.3.1 安裝

Keepalived支持源碼安裝，同時也可以通過不同操作系統(tǒng)安裝工具進行安裝，本文以CentOS的yum工具為例進行安裝介紹。此時應(yīng)該準備兩臺服務(wù)器分別作為Master節(jié)點和Backup節(jié)點，分別在兩臺服務(wù)器上執(zhí)行以下命令進行安裝。

yum install -y keepalived

2.3.2 高可用配置

yum安裝后，Keepalived將生成配置文件：/etc/keepalived/keepalived.conf，可利用文本編輯器進行配置修改。

vi /etc/keepalived/keepalived.conf

配置文件中主要由全局段、VRRP實例段、腳本段組成。

1．全局段定義（global_defs）

全局段定義允許用戶設(shè)置全局相關(guān)信息，例如通知信息、關(guān)鍵參數(shù)配置等，該段配置在Master節(jié)點和Backup節(jié)點上應(yīng)當一致。

global_defs {   notification_email {     [email protected]     }   notification_email_from  [email protected]     smtp_server  127.0.0.1     smtp_connect_timeout  60     vrrp_mcast_group4  224.0.0.18}

notification_email定義報警郵件地址，當服務(wù)切換時發(fā)送報警郵件。notification_email_from定義發(fā)件人信息，smtp_server和smtp_connect_timeout分別定義了SMTP服務(wù)器及相應(yīng)的連接超時時間，vrrp_mcast_group4為VRRP IPv4多播地址，默認為224.0.0.18，如果同一局域網(wǎng)內(nèi)有多組Keepalived時需要指定不同多播地址。

2．VRRP實例段定義（vrrp_instance）

這部分主要用來定義具體服務(wù)的實例配置，包括Keepalived主備狀態(tài)、接口、優(yōu)先級、認證方式和VIP信息等,每個VRRP實例可以認為是Keepalived服務(wù)的一個實例或作為一個業(yè)務(wù)服務(wù)，在一組Keepalived服務(wù)配置中，VRRP實例可以有多個。

注意，存在于Master節(jié)點中的VRRP實例配置在Backup節(jié)點中也要有一致的配置（除了節(jié)點角色、優(yōu)先級不同），這樣才能實現(xiàn)故障切換轉(zhuǎn)移。

vrrp_instance R1{state  MASTER  interface  eth0  virtual_router_id  50priority  100      advert_int  1    authentication {        auth_type PASS        auth_pass passwd    }    virtual_ipaddress {        10.230.137.100}    track_script {        chk_haproxy    }nopreemptpreempt_delay 2}

vrrp_instance配置段定義了一個VRRP實例并設(shè)定實例名稱；

state設(shè)定初始VRRP實例角色，配置先要為該實例所在的Keepalived服務(wù)器設(shè)定其角色，在Master服務(wù)器上設(shè)置為“MASTER”，在Backup服務(wù)器上則設(shè)置為“BACKUP”；

priority優(yōu)先級設(shè)定，范圍1-254，數(shù)字越大，表示實例優(yōu)先級越高，在同一個VRRP實例里，Master節(jié)點優(yōu)先級要高于Backup節(jié)點；

virtual_router_id虛擬路由ID標識，范圍0-255，Master和Backup節(jié)點配置中相同VRRP實例的虛擬路由ID標識必須一致，否則將出現(xiàn)腦裂問題；

advert_int用來同步通知間隔，Master節(jié)點和Backup節(jié)點之間通信檢查的時間間隔，單位是秒。

角色相關(guān)信息設(shè)定完畢后就要開始配置VIP并綁定至指定的網(wǎng)絡(luò)接口上，在virtual_ipaddress中配置VIP，可以配置多個VIP，VIP將綁定至interface參數(shù)配置的網(wǎng)絡(luò)接口上。

authentication認證配置段作用于同一個VRRP實例的MASTER和BACKUP之前的通信，具體的配置內(nèi)容有auth_type認證類型，auth_pass認證密碼，認證類型有PASS(Simple Passwd)和AH(IPSEC)，官方推薦PASS，驗證密碼為明文方式，最多8位。同一個VRRP實例的MASTER和BACKUP使用相同的密碼才能正常通信。

當添加nopreemp關(guān)鍵字時表示設(shè)置高可用模式為非搶占模式，如果去掉此關(guān)鍵字則為默認的搶占模式。搶占模式是指當高優(yōu)先級節(jié)點恢復后會搶占低優(yōu)先級節(jié)點成為MASTER，非搶占模式允許低優(yōu)先級節(jié)點繼續(xù)擔任MASTER，preempt_delay用來設(shè)置搶占延遲，單位秒，范圍0~1000，發(fā)現(xiàn)低優(yōu)先級MASTER后多少秒開始搶占。

track_script配置段是用于調(diào)用指定腳本，腳本相關(guān)配置請參考下一節(jié)。

3．腳本段定義（vrrp_script）

默認情況下，Keepalived僅僅在節(jié)點宕機或Keepalived進程停掉的時候才會啟動切換機制。但在實際工作中，有業(yè)務(wù)服務(wù)停止而Keepalived服務(wù)還存在的情況，這就會導致用戶訪問的VIP無法找到對應(yīng)的服務(wù)，這時可以利用Keepalived觸發(fā)預(yù)制的監(jiān)測腳本，實現(xiàn)VIP漂移來繼續(xù)提供服務(wù)。

vrrp_script chk_haproxy {script  "killall -0 haproxy" interval  2    weight  -2fall  3rise  1}

vrrp_script配置段定義一段腳本配置并設(shè)定腳本段名稱。script用雙引號設(shè)置引用的shell語句或者shell腳本，通過該語句或腳本執(zhí)行結(jié)果來判斷是否觸發(fā)指定動作，成功的結(jié)果不會觸發(fā)動作，執(zhí)行失敗會觸發(fā)動作。interval設(shè)置監(jiān)控間隔時間，單位為秒，weight設(shè)置當監(jiān)控腳本執(zhí)行結(jié)果為失敗時觸發(fā)priority值調(diào)整，正數(shù)為增加優(yōu)先級，負數(shù)為降低優(yōu)先級，范圍-255~255，fall設(shè)置認定結(jié)果為失敗時的執(zhí)行失敗次數(shù)，rise設(shè)置判定結(jié)果為成功時的執(zhí)行成功次數(shù)。

2.3.3 啟動

Keepalived配置完成后，在Master節(jié)點和Backup節(jié)點上使用以下命令開啟Keepalived服務(wù)。

systemctl start keepalived

如果需要設(shè)置開機啟動，則執(zhí)行以下命令。

systemctl enable keepalived

3. HAProxy功能及安裝配置

3.1 核心功能

1．負載均衡、會話保持

在多個服務(wù)器間實現(xiàn)四層或七層負載均衡，支持多種負載均衡算法，并且根據(jù)Hash或者cookies方式實現(xiàn)會話保持。

2．健康檢查

支持TCP、HTTP兩種后端服務(wù)器健康檢查模式。

3．統(tǒng)計監(jiān)控

接受訪問特定端口實現(xiàn)服務(wù)監(jiān)控，并提供帶有用戶認證機制的服務(wù)狀態(tài)報告頁面。

4．SSL卸載

可以解析HTTPS報文并將請求解密為HTTP向后端服務(wù)器傳輸。

5．其他功能

在HTTP請求或響應(yīng)報文中添加、修改、刪除首部信息；HTTP請求重寫與重定向；根據(jù)訪問控制路由或阻斷請求。

3.2 負載均衡調(diào)度算法

HAProxy負載均衡調(diào)度算法可以在HAProxy配置文件中設(shè)定。支持配置多組后端服務(wù)組，每個組可以分別指定一種調(diào)度算法。以下是HAProxy支持的幾種調(diào)度算法。

1．輪詢

帶有權(quán)重的輪詢調(diào)度算法。支持權(quán)重的運行時調(diào)整，支持慢啟動（在剛啟動時緩慢接收大量請求），僅支持最大4095個后端活動主機。

2．靜態(tài)輪詢

靜態(tài)輪詢算法，不支持權(quán)重的運行時調(diào)整及慢啟動，但后端主機數(shù)量無限制。

3．最少連接

帶權(quán)重的最少連接調(diào)度算法，將訪問請求動態(tài)調(diào)度至連接數(shù)較少的后端服務(wù)節(jié)點上。

4．源地址哈希

該算法保證在后端服務(wù)器組沒有減少或增加的情況下，能將來自同一客戶端IP的請求分配至同一個服務(wù)端，該算法適合在無法使用cookie插入的四層模式下使用。

5．URI哈希

該算法保證訪問同一URI請求分配至同一服務(wù)端，適用于后端為緩存服務(wù)器的情況，以提高緩存命中率。

6．URL參數(shù)哈希

該算法對請求URL中的指定的參數(shù)的值作哈希計算。該算法適用于有用戶識別參數(shù)的URL ，例如保證同一用戶ID的請求分配至同一服務(wù)節(jié)點。如果指定的參數(shù)沒有值，則降級至輪詢調(diào)度算法。

7．HTTP 首部哈希

該算法將HTTP首部中指定的字段取出做哈希計算。如果HTTP首部字段缺失，則降級至輪詢調(diào)度算法。

3.3 安裝與配置

3.3.1 安裝

HAProxy支持源碼安裝，同時也可以通過不同操作系統(tǒng)安裝工具進行安裝，本文以CentOS的yum工具為例進行安裝介紹，分別在兩臺已安裝并配置好kkeepalived的服務(wù)器上執(zhí)行以下命令進行安裝。

yum install -y haproxy

3.3.2 基本配置

yum安裝后，HAProxy將生成配置文件：/etc/haproxy/haproxy.cfg，利用文本編輯器進行配置修改。

vi /etc/haproxy/haproxy.cfg

1．全局段定義（global）

全局參數(shù)配置將配置于所有HAProxy服務(wù)器上。

global                               log  /dev/log local0 info             chroot    /var/lib/haproxypidfile    /var/run/haproxy.pidmaxconn     4000user      haproxy                      group     haproxy                        daemon       

log設(shè)置全局日志配置，語法為log <address> <facility> <msglevel>，上例中指定使用本機上的syslog服務(wù)中的local0日志設(shè)備，記錄日志等級為info的日志。chroot設(shè)置HAProxy工作目錄，pidfile設(shè)置HAProxy的pid文件位置，maxconn設(shè)置每個HAProxy進程可用的最大連接數(shù)，user及group設(shè)置HAProxy進程所屬的用戶及用戶組，daemon關(guān)鍵字表示以守護進程方式運行haproxy。

2．默認段定義（defaults）

默認段的作用是為后續(xù)前端代理及后端代理設(shè)置默認值。

defaultsmode      http    log        globaloption      httplogoption      dontlognull      option      http-server-close      option forwardfor   except 127.0.0.0/8     option     redispatch      retries     3 timeout http-request        10s  timeout queue             1mtimeout connect           10s timeout client             1m timeout server             1mtimeout http-keep-alive      10stimeout check             10s

Docker+K8s+Jenkins 主流技術(shù)全解視頻資料【干貨免費分享】

mode表示HAProxy的工作模式，設(shè)置tcp時為4層模式，設(shè)置http時為7層模式。log設(shè)置日志輸出方式，配置為global表示將采用全局段log的配置。

option httplog關(guān)鍵字表示記錄HTTP詳細日志，包括HTTP請求、session狀態(tài)、連接數(shù)等。

option dontlognull關(guān)鍵字表示日志中將不會記錄空連接。所謂空連接就是在上游的負載均衡器或者監(jiān)控系統(tǒng)為了探測該服務(wù)是否存活可用時，需要定期的連接或者獲取某一固定的組件或頁面，或者探測掃描端口是否在監(jiān)聽或開放等動作被稱為空連接，官方文檔中標注，如果該服務(wù)上游沒有其他的負載均衡器的話，建議不要設(shè)置該參數(shù)，因為設(shè)置后互聯(lián)網(wǎng)上的惡意掃描或其他動作就不會被記錄下來。

option http-server-close關(guān)鍵字表示每次請求完畢后主動關(guān)閉HTTP通道。

option forwardfor關(guān)鍵字表示應(yīng)用程序想記錄發(fā)起請求的客戶端的IP地址，需要在HAProxy上配置此選項，這樣HAProxy會把客戶端的IP信息發(fā)送給服務(wù)器，在HTTP請求中添加"X-Forwarded-For"字段啟用 X-Forwarded-For，在requests頭部插入客戶端IP發(fā)送給后端的server，使后端server獲取到客戶端的真實IP。

option redispatch關(guān)鍵字表示當使用了cookie時，HAProxy將會將其請求的后端服務(wù)器信息插入到cookie中，以保證會話的持久性，如果后端的服務(wù)器服務(wù)不可用，但客戶端的cookie是不會刷新的，設(shè)置此參數(shù)會將客戶的請求強制定向到另外一個后端服務(wù)器上，以保證服務(wù)的正常。

retries定義連接后端服務(wù)器的失敗重連次數(shù)，連接失敗次數(shù)超過此值后將會將對應(yīng)后端服務(wù)器標記為不可用。

timeout為前綴的關(guān)鍵字指定了一些關(guān)于請求、連接、響應(yīng)的最大超時時間，單位默認為毫秒，也可以加入后綴s(秒)，m(分鐘)，h(小時)，d(天)來指定。http-request設(shè)置HTTP請求超時時長，queue設(shè)置一個請求在隊列里的超時時間，connect設(shè)置最大與服務(wù)端建立連接的時長，client設(shè)置客戶端最大非活動時長，server設(shè)置服務(wù)端最大非活動時長，http-keep-alive設(shè)置最大等待新請求的空閑時長，check設(shè)置檢測超時時長。

3．前端代理定義（frontend）

前端代理配置定義一個服務(wù)監(jiān)聽，用于接收用戶請求并將請求轉(zhuǎn)發(fā)給后端代理，可以定義多個前端代理。

frontend  mainmode  httpbind  :80                          default_backend  nginx

frontend前端代理配置段定義一組前端服務(wù)并啟動服務(wù)監(jiān)聽，同時設(shè)置代理名稱。mode設(shè)置工作模式，如果此參數(shù)未被設(shè)定則引用默認配置段配置的模式。bind設(shè)置監(jiān)聽地址及端口，地址為空或者表示綁定至所有服務(wù)器的網(wǎng)絡(luò)接口。default_backend指定默認后端代理進行流量轉(zhuǎn)發(fā)。

4．后端代理定義（backend）

用于接收前端代理請求并根據(jù)設(shè)置的負載均衡策略將流量轉(zhuǎn)發(fā)至指定后端并對后端執(zhí)行健康檢查，一個前端可以指向多個后端；同時一個后端可以被多個調(diào)用。

backend  nginxmode    httpbalance   roundrobinserver   web1 host1:80 check inter 3s rise 1 fall 2server   web2 host2:80 check

backend后端代理配置段定義一組后端服務(wù)器，同時設(shè)置代理名稱。mode設(shè)置工作模式如果此參數(shù)未被設(shè)定則引用默認配置段的模式。balance設(shè)置后端負載均衡轉(zhuǎn)發(fā)策略，策略取值請參考表1。

表1 balance取值

server配置了相應(yīng)的后端服務(wù)集群地址，是真實的服務(wù)器，一個backend對應(yīng)一個或者多個實體服務(wù)器。配置依次為節(jié)點名稱、節(jié)點IP和端口、啟用四層健康檢查，在上述示例中web1服務(wù)器還設(shè)定了檢查的相關(guān)參數(shù)表示每3秒(inter)檢查一次，執(zhí)行兩次(fall)失敗認為故障，執(zhí)行一次(rise)成功即為服務(wù)可用。

3.3.3 啟動

HAProxy配置完成后，使用以下命令開啟HAProxy服務(wù)。

systemctl start haproxy

如果需要設(shè)置開機啟動，則執(zhí)行以下命令。

systemctl enable haproxy

修改配置文件后可以通過刷新配置的方式熱加載配置。

systemctl reload haproxy

3.3.4 會話保持

HAProxy在會話保持功能上可以分為四層會話保持和七層會話保持。四層會話保持是基于源地址的會話保持，是指HAProxy在負載均衡時根據(jù)訪問請求的源地址作為判斷關(guān)聯(lián)會話的依據(jù)，對于同一IP地址的所有訪問請求在作負載均衡時均會被保持到后端的同一臺服務(wù)器上。七層會話保持是基于cookie的會話保持，當客戶端HTTP請求進入HAProxy時，根據(jù)負載均衡策略選擇后端的一臺服務(wù)器，后端服務(wù)器將HTTP響應(yīng)返回HAProxy，此時HAproxy會插入該服務(wù)器的cookie并將插入cookie的HTTP響應(yīng)返回至客戶端，當該客戶端再次發(fā)出請求時，帶有上次插入cookie的HTTP請求進入HAProxy，HAProxy解析出cookie中服務(wù)器信息并將請求發(fā)送至相同的后端服務(wù)器。

四層會話保持的配置方式實際只需要將配置文件中后端代理段的負載均衡策略設(shè)置為基于源地址哈希并將工作模式設(shè)置為tcp即可，配置文件如下。

backend  nginxmode    tcpbalance  source    server   web1 10.230.150.68:80 check cookie web1server   web3 10.230.150.70:80 check cookie web3 

七層會話保持配置方式則需要在配置文件后端代理段中設(shè)置cookie并確保工作模式為http，配置文件如下。

backend  nginx    mode    http    balance  roundrobin    cookie  WEBSRV insert indirect nocache    server   web1 10.230.150.68:80 check cookie web1    server   web3 10.230.150.70:80 check cookie web3

以上配置文件中的cookie設(shè)置了以WEBSRV為名稱的cookie，然后在server配置中分別定義了不同的cookie值，通過瀏覽器訪問HAProxy前端代理地址可以看到該cookie，利用該cookie實現(xiàn)會話保持，如圖2所示。

圖2 cookie信息

3.3.5 SSL卸載

利用HAProxy可以實現(xiàn)SSL卸載功能，從而使客戶端到HAProxy的訪問采用SSL封裝后的HTTPS，而HAProxy至后端服務(wù)器之間的通信則采用HTTP（圖3），從而消除服務(wù)器端的SSL加密運算開銷。

圖3 SSL卸載

實現(xiàn)SSL卸載需要在配置文件全局定義段加入SSL參數(shù)調(diào)整，以及在前端代理段加入SSL配置，涉及的配置如下。

global    maxconn     20000    log         127.0.0.1 local0 info    chroot      /var/lib/haproxy    pidfile     /var/run/haproxy.pid    user        haproxy    group       haproxy    daemon    tune.ssl.default-dh-param 2048stats socket /var/lib/haproxy/stats frontend main    bind :80    bind :443 ssl crt /etc/ssl/certs/web.pem    redirect scheme https if !{ ssl_fc }    default_backend nginx

全局段配置中增加了SSL參數(shù)tune.ssl.default-dh-param，設(shè)置值為2048，表示使用2048bit加密，和SSL秘鑰加密位數(shù)保持一致。

前端代理配置bind加入443端口、SSL支持并綁定指定證書，證書文件內(nèi)容為網(wǎng)站的證書和私鑰通過命令（cat web.crt web.key | tee web.pem）拼接合成。配置段中還加入了HTTP到HTTPS的自動跳轉(zhuǎn)功能（redirect scheme https if !{ ssl_fc }），在瀏覽器中輸入域名或者IP地址，無需指定協(xié)議類型，如果導入根證書后的瀏覽器顯示的狀態(tài)是安全的則表示配置成功（圖4）。

圖4 開啟HTTPS

3.3.6 流量路由

HAProxy可以為數(shù)據(jù)庫、郵件、頁面等服務(wù)提供四層負載均衡機制，也可以從HTTP請求報文中提取指定數(shù)據(jù)并通過特定的訪問控制列表（ACL）提供基于七層的流量轉(zhuǎn)發(fā)機制。

1．基于URL路徑轉(zhuǎn)發(fā)。HAProxy可以根據(jù)請求的URL路徑做路由，通過配置不同的路徑將不同的URL路徑分發(fā)至不同的后端服務(wù)器，在以下的例子中我們在兩個頁面服務(wù)器上分別配置了兩個測試頁面test1.html、test2.html，頁面內(nèi)容簡單標識了所在服務(wù)器的信息，并利用轉(zhuǎn)發(fā)機制實現(xiàn)基于URL的路徑分發(fā)，涉及的相關(guān)配置如下。

frontend mainbind :80bind :443 ssl crt /etc/ssl/certs/web.pemredirect scheme https if !{ ssl_fc }    acl is_test1  path_beg  /test1    acl is_test2  path_beg  /test2    use_backend test1  if  is_test1    use_backend test2  if  is_test2    default_backend nginx
backend nginx    balance roundrobin    server  web1 10.230.150.68:80 check
backend test1    balance roundrobin    server  web2 10.230.150.69:80 check
backend test2    balance roundrobin    server  web3 10.230.150.70:80 check

前端代理配置段中加入acl配置，設(shè)置的路由規(guī)則為匹配路徑的前綴（path_beg）test1及test2，并配置use_backend參數(shù)將指定acl作用于指定后端服務(wù)器，is_test1規(guī)則匹配后路由至test1，is_test2規(guī)則匹配后路由至test2。

定義兩組后端代理配置，分別配置test1及test2后端代理，指向相應(yīng)的頁面服務(wù)器。通過訪問不同的路徑HAProxy可以正確路由轉(zhuǎn)發(fā)到指定后端頁面服務(wù)器，沒有命中acl的請求將轉(zhuǎn)發(fā)至默認后端服務(wù)器，如圖5所示。

圖5 URL路徑轉(zhuǎn)發(fā)

2．基于HTTP首部信息轉(zhuǎn)發(fā)。HAProxy可以根據(jù)HTTP首部信息來執(zhí)行路由分發(fā)操作，例如通過首部信息中的User-Agent來判斷請求方的設(shè)備類型是iPhone還是Android，以此作為依據(jù)進行路由分發(fā)至不同的后端服務(wù)器上，或者通過首部信息中的Host字段實現(xiàn)以域名為依據(jù)進行路由分發(fā)。以Host為例，涉及的相關(guān)配置如下。

frontend main    bind :80    bind :443 ssl crt /etc/ssl/certs/web.pem    redirect scheme https if !{ ssl_fc }    acl  is_test1  hdr_beg(host)  www.test1.com    acl  is_test2  hdr_beg(host)  www.test2.com    use_backend test1  if  is_test1    use_backend test2  if  is_test2    default_backend nginx backend nginx    balance roundrobin    cookie WEBSRV insert indirect nocache    server   web1 10.230.150.68:80 check cookie web1 backend test1    balance roundrobin    server   web2 10.230.150.69:80 check backend test2    balance roundrobin    server   web2 10.230.150.70:80 check

前端代理配置段中加入acl配置，通過hdr_beg(host)關(guān)鍵字設(shè)置的路由規(guī)則匹配HTTP首部信息中Host前綴www.test1.com及www.test2.com，并配置use_backend參數(shù)將指定acl作用于指定后端服務(wù)器，is_test1規(guī)則匹配后路由至test1，is_test2規(guī)則匹配后路由至test2。

定義兩組后端代理配置，分別配置test1及test2后端代理，指向相應(yīng)的頁面服務(wù)器。通過不同的域名訪問可以正確路由轉(zhuǎn)發(fā)到指定后端頁面服務(wù)器，沒有命中acl的請求將轉(zhuǎn)發(fā)至默認后端服務(wù)器，如圖6所示。
 

圖6 域名轉(zhuǎn)發(fā)

4. 總結(jié)

負載均衡可以由專業(yè)硬件設(shè)備提供，由服務(wù)器集群服務(wù)節(jié)點之上架設(shè)專業(yè)負載均衡器來完成集群節(jié)點的負載均衡工作。硬件負載均衡優(yōu)勢明顯，設(shè)備獨立于操作系統(tǒng)、強大的性能、豐富的功能、多樣化的負載均衡策略、智能化流量管理，由專業(yè)維護團隊提供維護，缺點是價格昂貴、配置復雜，部署難度大時間長，不適于中小規(guī)模的網(wǎng)絡(luò)服務(wù)。

軟負載則在一臺或多臺服務(wù)器操作系統(tǒng)之上安裝附加軟件來實現(xiàn)負載均衡。采用軟負載方案后系統(tǒng)構(gòu)架內(nèi)無需額外部署專用于負載均衡的硬件設(shè)備以降低成本，同時能夠更好地根據(jù)系統(tǒng)與應(yīng)用的狀態(tài)來分配負載，無縫的嵌入系統(tǒng)架構(gòu)中，也可以根據(jù)實際需求靈活擴展，互聯(lián)網(wǎng)公司大多都有自己的軟負載方案。相比硬件負載來說軟件負載具有配置簡單、快速部署、使用靈活、成本低廉、高性價比等諸多優(yōu)勢。

在建設(shè)某銀行應(yīng)用基礎(chǔ)云PaaS平臺的實踐中，采用Keepalived+HAproxy組合搭建了高可用軟負載方案，為平臺內(nèi)多組控制節(jié)點、多組工作節(jié)點、以及雙副本鏡像倉庫提供服務(wù)接口聚合負載和高可用性保障。首先，平臺的業(yè)務(wù)流量入口指向Keepalived高可用VIP地址，經(jīng)過Haproxy負載調(diào)度至后端工作節(jié)點中，這樣一旦其中任意一個負載均衡節(jié)點或者后端工作節(jié)點宕機，高可用VIP地址和剩余存活的后端工作節(jié)點仍可對外提供服務(wù)。其次，隨著后期業(yè)務(wù)流量的上升，后端工作節(jié)點出現(xiàn)負載壓力時，可以根據(jù)實際需要靈活配置Haproxy，擴展后端工作節(jié)點數(shù)量，降低整體工作節(jié)點負載壓力。從現(xiàn)有的實踐經(jīng)驗來看，該軟負載方案具備了良好的穩(wěn)定性、靈活性和可擴展性。

- END -
 推薦閱讀 









Go+Vue DevOps 從入門到項目實戰(zhàn)
網(wǎng)絡(luò)丟包，網(wǎng)絡(luò)延遲？這款神器幫你搞定所有！
頂級 DevOps 工具鏈大盤點
某外企從 0 建設(shè) SRE 運維體系經(jīng)驗分享
Nginx+Redis：高性能緩存利器
主流監(jiān)控系統(tǒng) Prometheus 學習指南
基于 eBPF 的 Kubernetes 問題排查全景圖發(fā)布
一文掌握 Ansible 自動化運維
Linux的10個最危險命令
Kubernetes網(wǎng)絡(luò)難懂？可能是沒看到這篇文章
24 個 Docker 常見問題處理技巧
Shell分析日志文件，全面解鎖新姿勢！
這篇文章帶你全面掌握 Nginx ！
一文搞懂 Kubernetes 網(wǎng)絡(luò)通信原理
SRE本質(zhì)就是一個懂運維的資深開發(fā)
搭建一套完整的企業(yè)級 K8s 集群（kubeadm方式）


點亮，服務(wù)器三年不宕機