haproxy+keepalived實現高可用負載均衡

https://www.cnblogs.com/daixiang/p/5575477.html

一、haproxy介紹：

　　HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支持虛擬主機。HAProxy特別適用於那些負載特大的web站點，這些站點通常又需要會話保持或七層處理。HAProxy運行在時下的硬件上，完全可以支持數以萬計的並發連接。並且它的運行模式使得它可以很簡單安全的整合進您當前的架構中， 同時可以保護你的web服務器不被暴露到網絡上。HAProxy實現了一種事件驅動、單一進程模型，此模型支持非常大的並發連接數。多進程或多線程模型受內存限制 、系統調度器限制以及無處不在的鎖限制，很少能處理數千並發連接。事件驅動模型因為在有更好的資源和時間管理的用戶端(User-Space) 實現所有這些任務，所以沒有這些問題。此模型的弊端是，在多核系統上，這些程序通常擴展性較差。這就是為什么他們必須進行優化以 使每個CPU時間片(Cycle)做更多的工作。

　　在linux內核版本為2.6或打了epoll補丁的linux2.4上運行haproxy能獲得其最好的性能。

 

二、keepalived介紹：　　

　　keepalived理論工作原理

　　　　　　keepalived可提供vrrp以及health-check功能，可以只用它提供雙機浮動的vip（vrrp虛擬路由功能），這樣可以簡單實現一個雙機熱備高可用功能。

　　　　　　keepalived是一個類似於layer3, 4 & 5交換機制的軟件，也就是我們平時說的第3層、第4層和第5層交換。Keepalived的作用是檢測web 服務器的狀態。 Layer3,4&5工作在IP/TCP協議棧的IP層，TCP層，及應用層,原理分別如下：

　　　　　　Layer3：Keepalived使用Layer3的方式工作式時，Keepalived會定期向服務器群中的服務器 發送一個ICMP的數據包（既我們平時用的Ping程序）,如果發現某台服務的IP地址沒有激活，Keepalived便報告這台服務器失效，並將它從服務器群中剔除，這種情況的典型例子是某台服務器被非法關機。Layer3的方式是以服務器的IP地址是否有效作為服務器工作正常與否的標准。在本文中將采用這種方式。

 

　　　　　　Layer4:如果您理解了Layer3的方式，Layer4就容易了。Layer4主要以TCP端口的狀態來決定服務器工作正常與否。如web server的服務端口一般是80，如果Keepalived檢測到80端口沒有啟動，則Keepalived將把這台服務器從服務器群中剔除。

 

　　　　　　Layer5：Layer5就是工作在具體的應用層了，比Layer3,Layer4要復雜一點，在網絡上占用的帶寬也要大一些。Keepalived將根據用戶的設定檢查服務器程序的運行是否正常，如果與用戶的設定不相符，則Keepalived將把服務器從服務器群中剔除。

 

    　　　　 vip即虛擬ip，是附在主機網卡上的，即對主機網卡進行虛擬，此IP仍然是占用了此網段的某個IP。

 

　　keepalived的用途：

　　　　　　Keepalived是一個基於VRRP協議來實現的WEB 服務高可用方案，可以利用其來避免單點故障。一個WEB服務至少會有2台服務器運行Keepalived，一台為主服務器（MASTER），一台為備份服務器（BACKUP），但是對外表現為一個虛擬IP，主服務器會發送特定的消息給備份服務器，當備份服務器收不到這個消息的時候，即主服務器宕機的時候，備份服務器就會接管虛擬IP，繼續提供服務，從而保證了高可用性。

　　　　　　在lvs+keepalived高可用負載均衡架構中，lvs本身不支持對后端real server進行健康狀態檢測，而keepalived的誕生不僅能是lvs均衡器實現了高可用，而且還能對lvs后端的real server進行健康狀態檢測。如果有一台web服務器死機，或工作出現故障，Keepalived將檢測到，並將有故障的web服務器從系統中剔除，當web服務器工作正常后Keepalived自動將web服務器加入到服務器群中，這些工作全部自動完成，不需要人工干涉，需要人工做的只是修復故障的web服務器。

 

 

 

 

 

配置過程：

在配置之前，先將HA中個節點進行時間同步，主機名之間相互解析，以及配置雙機互信。

在haproxy1.daixiang.com上配置：

1 2 3 4 5 6

[root@haproxy1 ~] # vim /etc/hosts      172.16.0.1 haproxy1.daixiang.com haproxy1      172.16.0.2 haproxy2.daixiang.com haproxy2<br> [root@haproxy1 ~] # ssh-keygen -t rsa -P '' [root@haproxy1 ~] # ssh-copy-id haproxy2 [root@haproxy1 ~] # ntpdate s2c.time.edu.cn

在haproxy2.daixiang.com上配置：

1 2 3 4 5 6 7

[root@haproxy2 ~] # vim /etc/hosts      172.16.0.1 haproxy1.daixiang.com haproxy1      172.16.0.2 haproxy2.daixiang.com haproxy2   [root@haproxy2 ~] # ssh-keygen -t rsa -P '' [root@haproxy2 ~] # ssh-copy-id haproxy1 [root@haproxy2 ~] # ntpdate s2c.time.edu.cn

 

安裝haproxy和keepalived：

　　在haproxy1和haproxy2節點上進行同樣的操作：

1 2 3

[root@haproxy1 ~] # yum install keepalived haproxy -y [root@haproxy1 ~] # cd /etc/keepalived/ [root@haproxy1 keepalived] # cp keepalived.conf{,.bak}

 

配置keepalived：雙主模型

 

　 將此配置文件同步到另一個haproxy2.daixiang.com上：

1	[root@haproxy1 keepalived] # scp keepalived.conf haproxy2:/etc/keepalived/

　 在haproxy2.daixiang.com上修改keepalived.conf配置文件：

 

　 重啟keepalived：

1 2	[root@haproxy1 keepalived] # service keepalived restart [root@haproxy1 keepalived] # ssh haproxy2 'service keepalived restart'

 

 

配置haproxy：

先將原始配置文件進行備份：

1 2 3 4

[root@haproxy1 ~] # cd /etc/haproxy/ [root@haproxy1 haproxy] # cp haproxy.cfg{,.bak}   ##節點2也進行同樣的操作

編輯其配置文件修改其內容如下：

+ View Code

將此配置文件同步當另一個haproxy節點上去：　

1	[root@haproxy1 haproxy] # scp haproxy.cfg haproxy2:/etc/haproxy/

重啟haproxy服務：

1 2	[root@haproxy1 haproxy] # service haproxy restart [root@haproxy1 haproxy] # ssh haproxy2 'service haproxy restart'

 

查看這兩個節點獲取ip的情況：

haproxy1.daixiang.com:

 

haproxy2.daixiang.com:

 

 

在后端的real server提供測試頁面，測試的結果如下:

請求以.html結尾的文件，haproxy將請求代理至后端static組中的server處理：

請求以.php結尾的文件，haproxy將請求代理至后端dynamic組中server處理：

 

注意：本文在haproxy.cfg的配置文件中，將dynamic組中的server配置了基於cookie的session綁定，所以，用同一瀏覽器看不出負載均衡的效果來。換個瀏覽器再訪問一次或者清空瀏覽器的cookie記錄就能顯示效果，如下圖。

 

haproxy的統計頁面輸出效果：