2.1 Keepalived工作原理

keepalived：顧名思義是保持存活，常用來搭建裝置的高可用，防止業務核心裝置出現單點故障。keepalived基於VRRP協議來實現高可用，主要用作realserver的健康檢查以及負載均衡主機和backup主機之間的故障漂移。如果將TCP/IP劃分為5層，則Keepalived就是一個類似於3~5層 交換機制的軟體，具有3~5層交換功能，其主要作用是檢測web伺服器的狀態，如果某臺web伺服器故障，Keepalived將檢測到並將其從 系統中剔除，當該web伺服器工作正常後Keepalived自動將其加入到伺服器群中，這些工作全部自動完成，而不需要人工干預，只需要人工修復故障的web伺服器即可。

三層機理是傳送ICMP資料包即PING給某臺伺服器，如果不通，則認為其故障，並從伺服器群中剔除；四層機理是檢測TCP埠號狀態來判斷某臺伺服器是否故障，如果檢測埠存在異常，則從伺服器群中剔除；五層機理是根據使用者的設定檢查某個伺服器應用程式是否正常執行，如果不正常，則從伺服器群中剔除。

2.2 HAproxy工作原理

Haproxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支援虛擬主機，它是免費、快速並且可靠的一種解決方案，反向代理伺服器,支援雙機熱備支援虛擬主機,但其配置簡單,擁有非常不錯的伺服器健康檢查功能,當其代理的後端伺服器出現故障, HAProxy會自動將該伺服器摘除,故障恢復後再自動將該伺服器加入。

Keepalived

keepalived是什麼

keepalived是叢集管理中保證叢集高可用的一個服務軟體，其功能類似於 heartbeat，用來防止單點故障。

keepalived工作原理

keepalived是以VRRP協議為實現基礎的，VRRP全稱Virtual Router Redundancy Protocol，即 虛擬路由冗餘協議。

虛擬路由冗餘協議，可以認為是實現路由器高可用的協議，即將N臺提供相同功能的路由器組成一個路由器組，這個組裡面有一個master和多個backup，master上面有一個對外提供服務的vip（該路由器所在區域網內其他機器的預設路由為該vip），master會發組播，當backup收不到vrrp包時就認為master宕掉了，這時就需要根據 VRRP的優先順序來 選舉一個backup當master。這樣的話就可以保證路由器的高可用了。

keepalived主要有三個模組，分別是core、check和vrrp。core模組為keepalived的核心，負責主程式的啟動、維護以及全域性配置檔案的載入和解析。check負責健康檢查，包括常見的各種檢查方式。vrrp模組是來實現VRRP協議的。

keepalived的配置檔案

keepalived只有一個配置檔案keepalived.conf，裡面主要包括以下幾個配置區域，分別是global_defs、static_ipaddress、static_routes、vrrp_script、vrrp_instance和virtual_server。

global_defs區域

主要是配置故障發生時的通知物件以及機器標識

global_defs {
    notification_email {
        a@abc.com
        b@abc.com
        ...
    }
    notification_email_from alert@abc.com
    smtp_server smtp.abc.com
    smtp_connect_timeout 30
    enable_traps
    router_id host163
}

• notification_email 故障發生時給誰發郵件通知。

• notification_email_from 通知郵件從哪個地址發出。
• smpt_server 通知郵件的smtp地址。
• smtp_connect_timeout 連線smtp伺服器的超時時間。
• enable_traps 開啟SNMP陷阱（ Simple Network Management Protocol）。
• router_id 標識本節點的字條串，通常為hostname，但不一定非得是hostname。故障發生時，郵件通知會用到。

static_ipaddress和static_routes區域

static_ipaddress和static_routes區域配置的是是本節點的IP和路由資訊。如果你的機器上已經配置了IP和路由，那麼這兩個區域可以不用配置。其實，一般情況下你的機器都會有IP地址和路由資訊的，因此沒必要再在這兩個區域配置。

12345678910

static_ipaddress {10.210.214.163/24 brd 10.210.214.255 dev eth0...}static_routes {10.0.0.0/8 via 10.210.214.1 dev eth0...}

以上分別表示啟動/關閉keepalived時在本機執行的如下命令：

12345

# /sbin/ip addr add 10.210.214.163/24 brd 10.210.214.255 dev eth0# /sbin/ip route add 10.0.0.0/8 via 10.210.214.1 dev eth0# /sbin/ip addr del 10.210.214.163/24 brd 10.210.214.255 dev eth0# /sbin/ip route del 10.0.0.0/8 via 10.210.214.1 dev eth0

注意： 請忽略這兩個區域，因為我堅信你的機器肯定已經配置了IP和路由。

vrrp_script區域

用來做健康檢查的，當時檢查失敗時會將 vrrp_instance的 priority減少相應的值。

123456

vrrp_script chk_http_port {script "</dev/tcp/127.0.0.1/80"interval 1weight -10}

以上意思是如果 script中的指令執行失敗，那麼相應的 vrrp_instance的優先順序會減少10個點。

vrrp_instance和vrrp_sync_group區域

vrrp_instance用來定義對外提供服務的VIP區域及其相關屬性。

vrrp_rsync_group用來定義vrrp_intance組，使得這個組內成員動作一致。舉個例子來說明一下其功能：

兩個vrrp_instance同屬於一個vrrp_rsync_group，那麼其中一個vrrp_instance發生故障切換時，另一個vrrp_instance也會跟著切換（即使這個instance沒有發生故障）。

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657

vrrp_sync_group VG_1 {group {inside_network   # name of vrrp_instance (below)outside_network  # One for each moveable IP....}notify_master /path/to_master.shnotify_backup /path/to_backup.shnotify_fault "/path/fault.sh VG_1"notify /path/notify.shsmtp_alert}vrrp_instance VI_1 {state MASTERinterface eth0use_vmac <VMAC_INTERFACE>dont_track_primarytrack_interface {eth0eth1}mcast_src_ip <IPADDR>lvs_sync_daemon_interface eth1garp_master_delay 10virtual_router_id 1priority 100advert_int 1authentication {auth_type PASSauth_pass 12345678}virtual_ipaddress {10.210.214.253/24 brd 10.210.214.255 dev eth0192.168.1.11/24 brd 192.168.1.255 dev eth1}virtual_routes {172.16.0.0/12 via 10.210.214.1192.168.1.0/24 via 192.168.1.1 dev eth1default via 202.102.152.1}track_script {chk_http_port}nopreemptpreempt_delay 300debugnotify_master <STRING>|<QUOTED-STRING>notify_backup <STRING>|<QUOTED-STRING>notify_fault <STRING>|<QUOTED-STRING>notify <STRING>|<QUOTED-STRING>smtp_alert}

• notify_master/backup/fault 分別表示切換為主/備/出錯時所執行的指令碼。
• notify 表示任何一狀態切換時都會呼叫該指令碼，並且該指令碼在以上三個指令碼執行完成之後進行呼叫，keepalived會自動傳遞三個引數（ 1 = “ G R O U P " | " I N S T A N C E ” ， 1=“GROUP"|"INSTANCE”，2 = name of group or instance，$3 = target state of transition(MASTER/BACKUP/FAULT)）。
• smtp_alert 表示是否開啟郵件通知（用全域性區域的郵件設定來發通知）。
• state 可以是MASTER或BACKUP，不過當其他節點keepalived啟動時會將priority比較大的節點選舉為MASTER，因此該項其實沒有實質用途。
• interface 節點固有IP（非VIP）的網路卡，用來發VRRP包。
• use_vmac 是否使用VRRP的虛擬MAC地址。
• dont_track_primary 忽略VRRP網路卡錯誤。（預設未設定）
• track_interface 監控以下網路卡，如果任何一個不通就會切換到FALT狀態。（可選項）
• mcast_src_ip 修改vrrp組播包的源地址，預設源地址為master的IP。（由於是組播，因此即使修改了源地址，該master還是能收到回應的）
• lvs_sync_daemon_interface 繫結lvs syncd的網路卡。
• garp_master_delay 當切為主狀態後多久更新ARP快取，預設5秒。
• virtual_router_id 取值在0-255之間，用來區分多個instance的VRRP組播。

注意： 同一網段中virtual_router_id的值不能重複，否則會出錯，相關錯誤資訊如下。

Keepalived_vrrp[27120]: ip address associated with VRID not present in received packet :

one or more VIP associated with VRID mismatch actual MASTER advert

bogus VRRP packet received on eth1 !!!

receive an invalid ip number count associated with VRID!

VRRP_Instance(xxx) ignoring received advertisment...

可以用這條命令來檢視該網路中所存在的vrid： tcpdump -nn -i any net 224.0.0.0/8

• priority 用來選舉master的，要成為master，那麼這個選項的值 最好高於其他機器50個點，該項 取值範圍是1-255（在此範圍之外會被識別成預設值100）。
• advert_int 發VRRP包的時間間隔，即多久進行一次master選舉（可以認為是健康查檢時間間隔）。
• authentication 認證區域，認證型別有PASS和HA（IPSEC），推薦使用PASS（密碼只識別前8位）。
• virtual_ipaddress vip，不解釋了。
• virtual_routes 虛擬路由，當IP漂過來之後需要新增的路由資訊。
• virtual_ipaddress_excluded 傳送的VRRP包裡不包含的IP地址，為減少回應VRRP包的個數。在網路卡上繫結的IP地址比較多的時候用。
• nopreempt 允許一個priority比較低的節點作為master，即使有priority更高的節點啟動。

首先nopreemt必須在state為BACKUP的節點上才生效（因為是BACKUP節點決定是否來成為MASTER的），其次要實現類似於關閉auto failback的功能需要將所有節點的state都設定為BACKUP，或者將master節點的priority設定的比BACKUP低。我個人推薦使用將所有節點的state都設定成BACKUP並且都加上nopreempt選項，這樣就完成了關於autofailback功能，當想手動將某節點切換為MASTER時只需去掉該節點的nopreempt選項並且將priority改的比其他節點大，然後重新載入配置檔案即可（等MASTER切過來之後再將配置檔案改回去再reload一下）。

當使用 track_script時可以不用加 nopreempt，只需要加上 preempt_delay 5，這裡的間隔時間要大於 vrrp_script中定義的時長。

• preempt_delay master啟動多久之後進行接管資源（VIP/Route資訊等），並提是沒有 nopreempt選項。

上述的文字來自於 這裡，一般我們使用keepalived就是用上述的功能來監測服務，主從切換時自動地將vip進行漂移。

其實keepalived也可以用來作負載均衡，如下。

virtual_server_group和virtual_server區域

virtual_server_group一般在超大型的LVS中用到，一般LVS用不過這東西，因此不多說。

virtual_server IP Port {
    delay_loop <INT>
    lb_algo rr|wrr|lc|wlc|lblc|sh|dh
    lb_kind NAT|DR|TUN
    persistence_timeout <INT>
    persistence_granularity <NETMASK>
    protocol TCP
    ha_suspend
    virtualhost <STRING>
    alpha
    omega
    quorum <INT>
    hysteresis <INT>
    quorum_up <STRING>|<QUOTED-STRING>
    quorum_down <STRING>|<QUOTED-STRING>
    sorry_server <IPADDR> <PORT>
    real_server <IPADDR> <PORT> {
        weight <INT>
        inhibit_on_failure
        notify_up <STRING>|<QUOTED-STRING>
        notify_down <STRING>|<QUOTED-STRING>
        # HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK
        HTTP_GET|SSL_GET {
            url {
                path <STRING>
                # Digest computed with genhash
                digest <STRING>
                status_code <INT>
            }
            connect_port <PORT>
            connect_timeout <INT>
            nb_get_retry <INT>
            delay_before_retry <INT>
        }
    }
}

• delay_loop 延遲輪詢時間（單位秒）。

• lb_algo 後端除錯演算法（load balancing algorithm）。
• lb_kind LVS排程型別 NAT/ DR/ TUN。
• virtualhost 用來給HTTP_GET和SSL_GET配置請求header的。
• sorry_server 當所有real server宕掉時，sorry server頂替。
• real_server 真正提供服務的伺服器。
• weight 權重。
• notify_up/down 當real server宕掉或啟動時執行的指令碼。
• 健康檢查的方式，N多種方式。
• path 請求real serserver上的路徑。
• digest/status_code 分別表示用genhash算出的結果和http狀態碼。
• connect_port 健康檢查，如果埠通則認為伺服器正常。
• connect_timeout,nb_get_retry,delay_before_retry分別表示超時時長、重試次數，下次重試的時間延遲。

其他選項暫時不作說明。

keepalived主從切換

主從切換比較讓人蛋疼，需要將backup配置檔案的priority選項的值調整的比master高50個點，然後reload配置檔案就可以切換了。當時你也可以將master的keepalived停止，這樣也可以進行主從切換。

HAProxy

HAProxy是什麼

HAProxy是一個免費的負載均衡軟體，可以執行於大部分主流的Linux作業系統上。

HAProxy提供了L4(TCP)和L7(HTTP)兩種負載均衡能力，具備豐富的功能。HAProxy的社群非常活躍，版本更新快速（最新穩定版1.7.2於2017/01/13推出）。最關鍵的是，HAProxy具備媲美商用負載均衡器的效能和穩定性。

因為HAProxy的上述優點，它當前不僅僅是免費負載均衡軟體的首選，更幾乎成為了唯一選擇。

HAProxy的核心能力和關鍵特性

HAProxy的核心功能

• 負載均衡：L4和L7兩種模式，支援RR/靜態RR/LC/IP Hash/URI Hash/URL_PARAM Hash/HTTP_HEADER Hash等豐富的負載均衡演算法
• 健康檢查：支援TCP和HTTP兩種健康檢查模式
• 會話保持：對於未實現會話共享的應用叢集，可通過Insert Cookie/Rewrite Cookie/Prefix Cookie，以及上述的多種Hash方式實現會話保持
• SSL：HAProxy可以解析HTTPS協議，並能夠將請求解密為HTTP後向後端傳輸
• HTTP請求重寫與重定向
• 監控與統計：HAProxy提供了基於Web的統計資訊頁面，展現健康狀態和流量資料。基於此功能，使用者可以開發監控程式來監控HAProxy的狀態

從這個核心功能來看，haproxy實現的功能類似於nginx的L4、L7反向代理。

HAProxy的關鍵特性

效能

• 採用單執行緒、事件驅動、非阻塞模型，減少上下文切換的消耗，能在1ms內處理數百個請求。並且每個會話只佔用數KB的記憶體。
• 大量精細的效能優化，如O(1)複雜度的事件檢查器、延遲更新技術、Single-buffereing、Zero-copy forwarding等等，這些技術使得HAProxy在中等負載下只佔用極低的CPU資源。
• HAProxy大量利用作業系統本身的功能特性，使得其在處理請求時能發揮極高的效能，通常情況下，HAProxy自身只佔用15%的處理時間，剩餘的85%都是在系統核心層完成的。
• HAProxy作者在8年前（2009）年使用1.4版本進行了一次測試，單個HAProxy程式的處理能力突破了10萬請求/秒，並輕鬆佔滿了10Gbps的網路頻寬。

穩定性

作為建議以單程式模式執行的程式，HAProxy對穩定性的要求是十分嚴苛的。按照作者的說法，HAProxy在13年間從未出現過一個會導致其崩潰的BUG，HAProxy一旦成功啟動，除非作業系統或硬體故障，否則就不會崩潰（我覺得可能多少還是有誇大的成分）。

在上文中提到過，HAProxy的大部分工作都是在作業系統核心完成的，所以HAProxy的穩定性主要依賴於作業系統，作者建議使用2.6或3.x的Linux核心，對sysctls引數進行精細的優化，並且確保主機有足夠的記憶體。這樣HAProxy就能夠持續滿負載穩定執行數年之久。

HAProxy關鍵配置詳解

總覽

HAProxy的配置檔案共有5個域

• global：用於配置全域性引數
• default：用於配置所有frontend和backend的預設屬性
• frontend：用於配置前端服務（即HAProxy自身提供的服務）例項
• backend：用於配置後端服務（即HAProxy後面接的服務）例項組
• listen：frontend+backend的組合配置，可以理解成更簡潔的配置方法

global域的關鍵配置

• daemon：指定HAProxy以後臺模式執行，通常情況下都應該使用這一配置
• user [username] ：指定HAProxy程式所屬的使用者
• group [groupname] ：指定HAProxy程式所屬的使用者組
• log [address][device][maxlevel][minlevel]：日誌輸出配置，如log 127.0.0.1 local0 info warning，即向本機rsyslog或syslog的local0輸出info到warning級別的日誌。其中[minlevel]可以省略。HAProxy的日誌共有8個級別，從高到低為emerg/alert/crit/err/warning/notice/info/debug
• pidfile ：指定記錄HAProxy程式號的檔案絕對路徑。主要用於HAProxy程式的停止和重啟動作。
• maxconn ：HAProxy程式同時處理的連線數，當連線數達到這一數值時，HAProxy將停止接收連線請求

frontend域的關鍵配置

• acl [name][criterion] [flags][operator] [value]：定義一條ACL，ACL是根據資料包的指定屬性以指定表示式計算出的true/false值。如"acl url_ms1 path_beg -i /ms1/“定義了名為url_ms1的ACL，該ACL在請求uri以/ms1/開頭（忽略大小寫）時為true
• bind [ip]:[port]：frontend服務監聽的埠
• default_backend [name]：frontend對應的預設backend
• disabled：禁用此frontend
• http-request [operation][condition]：對所有到達此frontend的HTTP請求應用的策略，例如可以拒絕、要求認證、新增header、替換header、定義ACL等等。
• http-response [operation][condition]：對所有從此frontend返回的HTTP響應應用的策略，大體同上
• log：同global域的log配置，僅應用於此frontend。如果要沿用global域的log配置，則此處配置為log global
• maxconn：同global域的maxconn，僅應用於此frontend
• mode：此frontend的工作模式，主要有http和tcp兩種，對應L7和L4兩種負載均衡模式
• option forwardfor：在請求中新增X-Forwarded-For Header，記錄客戶端ip
• option http-keep-alive：以KeepAlive模式提供服務
• option httpclose：與http-keep-alive對應，關閉KeepAlive模式，如果HAProxy主要提供的是介面型別的服務，可以考慮採用httpclose模式，以節省連線數資源。但如果這樣做了，介面的呼叫端將不能使用HTTP連線池
• option httplog：開啟httplog，HAProxy將會以類似Apache HTTP或Nginx的格式來記錄請求日誌
• option tcplog：開啟tcplog，HAProxy將會在日誌中記錄資料包在傳輸層的更多屬性
• stats uri [uri]：在此frontend上開啟監控頁面，通過[uri]訪問
• stats refresh [time]：監控資料重新整理週期
• stats auth [user]:[password]：監控頁面的認證使用者名稱密碼
• timeout client [time]：指連線建立後，客戶端持續不傳送資料的超時時間
• timeout http-request [time]：指連線建立後，客戶端沒能傳送完整HTTP請求的超時時間，主要用於防止DoS類攻擊，即建立連線後，以非常緩慢的速度傳送請求包，導致HAProxy連線被長時間佔用
• use_backend [backend] if|unless [acl]：與ACL搭配使用，在滿足/不滿足ACL時轉發至指定的backend

backend域的關鍵配置

• acl：同frontend域
• balance [algorithm]：在此backend下所有server間的負載均衡演算法，常用的有roundrobin和source，完整的演算法說明見官方文件 configuration.html#4.2-balance
• cookie：在backend server間啟用基於cookie的會話保持策略，最常用的是insert方式，如cookie HA_STICKY_ms1 insert indirect nocache，指HAProxy將在響應中插入名為HA_STICKY_ms1的cookie，其值為對應的server定義中指定的值，並根據請求中此cookie的值決定轉發至哪個server。indirect代表如果請求中已經帶有合法的HA_STICK_ms1 cookie，則HAProxy不會在響應中再次插入此cookie，nocache則代表禁止鏈路上的所有閘道器和快取伺服器快取帶有Set-Cookie頭的響應。
• default-server：用於指定此backend下所有server的預設設定。具體見下面的server配置。
• disabled：禁用此backend
• http-request/http-response：同frontend域
• log：同frontend域
• mode：同frontend域
• option forwardfor：同frontend域
• option http-keep-alive：同frontend域
• option httpclose：同frontend域
• option httpchk [METHOD][URL] [VERSION]：定義以http方式進行的健康檢查策略。如option httpchk GET /healthCheck.html HTTP/1.1
• option httplog：同frontend域
• option tcplog：同frontend域
• server [name][ip]:[port][params]：定義backend中的一個後端server，[params]用於指定這個server的引數，常用的包括有：

check：指定此引數時，HAProxy將會對此server執行健康檢查，檢查方法在option httpchk中配置。同時還可以在check後指定inter, rise, fall三個引數，分別代表健康檢查的週期、連續幾次成功認為server UP，連續幾次失敗認為server DOWN，預設值是inter 2000ms rise 2 fall 3 cookie [value]：用於配合基於cookie的會話保持，如cookie ms1.srv1代表交由此server處理的請求會在響應中寫入值為ms1.srv1的cookie（具體的cookie名則在backend域中的cookie設定中指定） maxconn：指HAProxy最多同時向此server發起的連線數，當連線數到達maxconn後，向此server發起的新連線會進入等待佇列。預設為0，即無限 maxqueue：等待佇列的長度，當佇列已滿後，後續請求將會發至此backend下的其他server，預設為0，即無限 weight：server的權重，0-256，權重越大，分給這個server的請求就越多。weight為0的server將不會被分配任何新的連線。所有server預設weight為1

• timeout connect [time]：指HAProxy嘗試與backend server建立連線的超時時間
• timeout check [time]：預設情況下，健康檢查的連線+響應超時時間為server命令中指定的inter值，如果配置了timeout check，HAProxy會以inter作為健康檢查請求的連線超時時間，並以timeout check的值作為健康檢查請求的響應超時時間
• timeout server [time]：指backend server響應HAProxy請求的超時時間

default域

上文所屬的frontend和backend域關鍵配置中，除acl、bind、http-request、http-response、use_backend外，其餘的均可以配置在default域中。default域中配置了的專案，如果在frontend或backend域中沒有配置，將會使用default域中的配置。

listen域

listen域是frontend域和backend域的組合，frontend域和backend域中所有的配置都可以配置在listen域下

官方配置文件

HAProxy的配置項非常多，支援非常豐富的功能，上文只列出了作為L7負載均衡器使用HAProxy時的一些關鍵引數。完整的引數說明請參見官方文件  configuration.html

使用例項

使用HAProxy搭建L7負載均衡器

總體方案

本節中，我們將使用HAProxy搭建一個L7負載均衡器，應用如下功能

• 負載均衡

• 會話保持

• 健康檢查

• 根據URI字首向不同的後端叢集轉發

• 監控頁面

HAProxy配置檔案

global

    daemon

    maxconn 30000   #ulimit -n至少為60018

    user ha

    pidfile /home/ha/haproxy/conf/haproxy.pid

    log 127.0.0.1 local0 info

    log 127.0.0.1 local1 warning

defaults

    mode http

    log global

    option http-keep-alive   #使用keepAlive連線

    option forwardfor        #記錄客戶端IP在X-Forwarded-For頭域中

    option httplog           #開啟httplog，HAProxy會記錄更豐富的請求資訊

    timeout connect 5000ms

    timeout client 10000ms

    timeout server 50000ms

    timeout http-request 20000ms    #從連線建立開始到從客戶端讀取完整HTTP請求的超時時間，用於避免類DoS攻擊

    option httpchk GET /healthCheck.html    #定義預設的健康檢查策略

frontend http-in

    bind *:9001

    maxconn 30000                    #定義此埠上的maxconn

    acl url_ms1 path_beg -i /ms1/    #定義ACL，當uri以/ms1/開頭時，ACL[url_ms1]為true

    acl url_ms2 path_beg -i /ms2/    #同上，url_ms2

    use_backend ms1 if url_ms1       #當[url_ms1]為true時，定向到後端服務群ms1中

    use_backend ms2 if url_ms2       #當[url_ms2]為true時，定向到後端服務群ms2中

    default_backend default_servers  #其他情況時，定向到後端服務群default_servers中

backend ms1    #定義後端服務群ms1

    balance roundrobin    #使用RR負載均衡演算法

    cookie HA_STICKY_ms1 insert indirect nocache    #會話保持策略，insert名為"HA_STICKY_ms1"的cookie

    #定義後端server[ms1.srv1]，請求定向到該server時會在響應中寫入cookie值[ms1.srv1]

    #針對此server的maxconn設定為300

    #應用預設健康檢查策略，健康檢查間隔和超時時間為2000ms，兩次成功視為節點UP，三次失敗視為節點DOWN

    server ms1.srv1 192.168.8.111:8080 cookie ms1.srv1 maxconn 300 check inter 2000ms rise 2 fall 3

    #同上，inter 2000ms rise 2 fall 3是預設值，可以省略

    server ms1.srv2 192.168.8.112:8080 cookie ms1.srv2 maxconn 300 check

backend ms2    #定義後端服務群ms2

    balance roundrobin

    cookie HA_STICKY_ms2 insert indirect nocache

    server ms2.srv1 192.168.8.111:8081 cookie ms2.srv1 maxconn 300 check

    server ms2.srv2 192.168.8.112:8081 cookie ms2.srv2 maxconn 300 check

backend default_servers    #定義後端服務群default_servers

    balance roundrobin

    cookie HA_STICKY_def insert indirect nocache

    server def.srv1 192.168.8.111:8082 cookie def.srv1 maxconn 300 check

    server def.srv2 192.168.8.112:8082 cookie def.srv2 maxconn 300 check

listen stats    #定義監控頁面

    bind *:1080                   #繫結埠1080

    stats refresh 30s             #每30秒更新監控資料

    stats uri /stats              #訪問監控頁面的uri

    stats realm HAProxy\ Stats    #監控頁面的認證提示

    stats auth admin:admin        #監控頁面的使用者名稱和密碼

使用HAProxy搭建L4負載均衡器

HAProxy作為L4負載均衡器工作時，不會去解析任何與HTTP協議相關的內容，只在傳輸層對資料包進行處理。也就是說，以L4模式執行的HAProxy，無法實現根據URL向不同後端轉發、通過cookie實現會話保持等功能。

同時，在L4模式下工作的HAProxy也無法提供監控頁面。

但作為L4負載均衡器的HAProxy能夠提供更高的效能，適合於基於套接字的服務（如資料庫、訊息佇列、RPC、郵件服務、Redis等），或不需要邏輯規則判斷，並已實現了會話共享的HTTP服務。

HAProxy配置檔案

global

    daemon

    maxconn 30000   #ulimit -n至少為60018

    user ha

    pidfile /home/ha/haproxy/conf/haproxy.pid

    log 127.0.0.1 local0 info

    log 127.0.0.1 local1 warning

defaults

    mode tcp

    log global

    option tcplog            #開啟tcplog

    timeout connect 5000ms

    timeout client 10000ms

    timeout server 10000ms   #TCP模式下，應將timeout client和timeout server設定為一樣的值，以防止出現問題

    option httpchk GET /healthCheck.html    #定義預設的健康檢查策略

frontend http-in

    bind *:9002

    maxconn 30000                    #定義此埠上的maxconn

    default_backend default_servers  #請求定向至後端服務群default_servers

backend default_servers    #定義後端服務群default_servers

    balance source  #基於客戶端IP的會話保持

    server def.srv1 192.168.8.111:8082 maxconn 300 check

    server def.srv2 192.168.8.112:8082 maxconn 300 check

使用Keepalived實現HAProxy高可用

儘管HAProxy非常穩定，但仍然無法規避作業系統故障、主機硬體故障、網路故障甚至斷電帶來的風險。所以必須對HAProxy實施高可用方案。

下文將介紹利用Keepalived實現的HAProxy熱備方案。即兩臺主機上的兩個HAProxy例項同時線上，其中權重較高的例項為MASTER，MASTER出現問題時，另一臺例項自動接管所有流量。

原理

在兩臺HAProxy的主機上分別執行著一個Keepalived例項，這兩個Keepalived爭搶同一個虛IP地址，兩個HAProxy也嘗試去繫結這同一個虛IP地址上的埠。 顯然，同時只能有一個Keepalived搶到這個虛IP，搶到了這個虛IP的Keepalived主機上的HAProxy便是當前的MASTER。 Keepalived內部維護一個權重值，權重值最高的Keepalived例項能夠搶到虛IP。同時Keepalived會定期check本主機上的HAProxy狀態，狀態OK時權重值增加。

keepalived配置檔案

global_defs {

    router_id LVS_DEVEL  #虛擬路由名稱

}

#HAProxy健康檢查配置

vrrp_script chk_haproxy {

    script "killall -0 haproxy"  #使用killall -0檢查haproxy例項是否存在，效能高於ps命令

    interval 2   #指令碼執行週期

    weight 2   #每次檢查的加權權重值

}

#虛擬路由配置

vrrp_instance VI_1 {

    state MASTER           #本機例項狀態，MASTER/BACKUP，備機配置檔案中請寫BACKUP

    interface enp0s25      #本機網路卡名稱，使用ifconfig命令檢視

    virtual_router_id 51   #虛擬路由編號，主備機保持一致

    priority 101           #本機初始權重，備機請填寫小於主機的值（例如100）

    advert_int 1           #爭搶虛地址的週期，秒

    virtual_ipaddress {

        192.168.8.201      #虛地址IP，主備機保持一致

    }

    track_script {

        chk_haproxy        #對應的健康檢查配置

    }

}

參考

1. https://github.com/chenzhiwei/linux/tree/master/keepalived
2. https://www.jianshu.com/p/c9f6d55288c0
3. http://seanlook.com/2015/05/18/nginx-keepalived-ha/