高可用負載均衡集羣之 HAProxy 部署

時間 2019-11-08

標籤可用負載均衡集羣 haproxy 部署欄目負載均衡简体版

原文原文鏈接

1、HAProxy 簡介html

一、HAProxy 是開源、免費、快速而且可靠的一種解決方案，他能夠運行在大部分主流的 Linux 服務器上。git

二、HAProxy 適用於負載那些特大的 WEB 站點，而這些站點一般又須要會話保持或者進行七層處理。github

三、HAProxy 是可以提供高可用性、負載均衡以及基於 L4（TCP）和 L7（HTTP）的應用的代理。web

四、HAProxy 功能豐富，且性能穩定。正則表達式

2、影響 HAProxy 負載均衡器的性能因素算法

一、Session 會話率：即每秒產生的會話數，這個因素取決於客戶端的訪問量，所以，訪問量越大，Session 會話率越大，負載均衡壓力就越大。vim

二、Session concurrency 併發會話數：即併發會話數越多，服務器處理的會話時間就越長，客戶端表現出來的訪問就會越慢。後端

三、Date rate 數據速率：它以 MB/s 或者 Mbps 來衡量，其數據量越大，併發會話數就會增長，併發會話數越多、數據速率越高，所要求使用的內存就越多。瀏覽器

所以，這三個因素，在高併發負載均衡中，可能會成爲 HAProxy 的性能瓶頸。緩存

3、HAProxy 負載均衡器的核心功能和關鍵特性

一、HAProxy 的核心功能

    負載均衡：HAProxy 的負載均衡有兩種模式，分別爲 L4（TCP）和 L7（HTTP），這兩種負載均衡均支持如下負載均衡調度算法：

              roundrobin：動態輪詢算法

              rr：輪詢算法

              static-rr：靜態輪詢算法

              lc：最少鏈接

              IP Hash：IP 地址散列（包括源地址和目標地址）

              URL_PARAM Hash：對用戶請求的 uri 僅 params 部分中的參數的值做hash計算

              HTTP_HEADER Hash：對用戶請求的 uri 的 http 頭部信息做hash計算

    這裏僅列舉經常使用的這些算法，固然還有其餘算法，都不經常使用。

    健康檢查：其實健康檢查能夠算做 HAProxy 的一種工做模式，不過這種工做模式，如今幾乎不多用到，因此，健康檢查，通常是作爲 L4（TCP）和 L7（HTTP）的狀態檢查。

    會話保持：對於未實現會話共享的應用集羣，可經過 Insert Cookie/Rewrite Cookie/Prefix Cookie，以及上述的多種Hash方式實現會話保持。

    解析 SSL：HAProxy 能夠解析 HTTPS 協議，而且可以將客戶端 HTTPS 請求解密爲 HTTP 後向後端傳輸。

    HTTP 請求重寫和重定向：HAProxy 可使用正則表達式將 HTTP 請求重寫和重定向。

    監控與統計：HAProxy 提供了基於 WEB 界面的統計信息頁面，在該頁面可以展現應用服務器的健康狀態和數據流量。作爲運維，咱們能夠基於此頁面來開發監控程序以監控 HAProxy 的狀態。

二、HAProxy 的關鍵特性

    關於 HAProxy 的特性，其實和 HTTP 協議的特性是是息息相關的。

    a、HTTP 事務模型：

          - HTTP 協議是事務驅動的

          - 每一個請求（Request）僅能對應一個響應（Response）

          - HTTP 經常使用連接模式

                     HTTP close：每一個 Request 產生且僅產生一個 Response，客戶端發送請求時，將創建一個從客戶端到服務端的 TCP 鏈接，客戶端發送的每個 Request 都通過此鏈接傳送給服務端，而後服務端發出 Response 報文。隨後這個 TCP 鏈接將關閉，下一個 Request 將從新打開一個 tcp鏈接進行傳送。

                     Keep-alive：Http close 模式下，TCP 連接會隨着 Response 的關閉而關閉，所以，頻繁的連接和關閉會形成資源和時間的大量消耗。爲了不這種狀況，在服務器端發送 Response 時給出 content-length 的標記，讓客戶端知道還有多少內容沒有接收到，沒有接收完則tcp鏈接不關閉。這種模式咱們稱爲「Keep-alive」。

                     Pipelining：這種模式可以提高 Http close ,不過它任然使用 keep-alive 模式。可是在使用這種模式時，客戶端不須要等待收到服務端的 Response 後才發送後續的 Request 請求。所以，這種模式在請求含有大量圖片的頁面時頗有用，因此可以很好的提升性能。

           HAProxy 支持的 5 種鏈接模式：

           一、keep alive：分析並處理全部的 Request 和 Response（默認），當後端爲靜態或緩存服務器建議使用此模式。

           二、tunnel：僅分析處理第一個 Request 和 Response，剩餘全部內容不進行任何分析直接轉發。較早的版本使用，如今已基本不用。

           三、passive close：在請求和響應首部加上 "connection:close" 標記的 tunnel ，在處理完第一個 Request 和 Response 後嘗試關閉兩端鏈接。

           四、server close：處理完第一個 Response 後關閉和 Server 端的鏈接，但和客戶端的鏈接仍然保持，當後端爲動態應用程序服務器組建議使用此模式。

           五、forced close：傳輸完一個response後客戶端和服務端都關閉鏈接。

b、HAProxy 使用單線程，可以減小上下文切換時對資源的消耗。

c、HAProxy 可以最大化的利用系統自己的特性，是的系統在處理請求時能發揮出最高的性能。

4、HAProxy 安裝和配置

服務器地址分配

一、HAProxy 的安裝

在這裏，咱們採用 yum 源安裝：

[root@haproxy ~]# yum -y install haproxy

二、HAProxy的配置：

a、日誌配置

對於 HAProxy 的日誌配置，咱們這裏須要介紹下系統日誌的構成。對於系統日誌，主要有兩部分構成，即

Faciliti.priority，這種構成至關於服務.優先級

Facility 能夠是這些關鍵字：auth, authpriv, cron, daemon, kern, lpr, mail, mark, news, security, syslog, user, uucp 以及 local0 到 local7。local0 到 local7 是預留出來的接口，給第三方應用調用。

priority可使用的關鍵字：debug, info, notice, warning, warn, err, error, crit, alert, emerg, panic 。debug 是最不嚴重的級別，panic 是最嚴重的級別。若是日誌級別優先級是 info，表示比 info 嚴重的日誌都須要記錄。

而對於關鍵字的獲取，咱們能夠在 rsyslog.conf 中得到，使用命令 man 5 rsyslog.conf ，一直往下找 SELECTORS（選擇器）。

b、配置本機接收經過網絡發來的日誌，即日誌服務器的配置：

[root@haproxy ~]# vim /etc/rsyslog.conf

取消上圖中紅框內內容的註釋便可，圖中已取消。

重啓 rsyslog 服務

[root@haproxy ~]# systemctl restart rsyslog

c、HAProxy 的配置文件解釋

HAProxy 的配置文件位於 /etc/haproxy/ 目錄下，如圖：

如圖，HAProxy 的配置文件分爲 5 部分：global、defaults、frontend、backend static、backend app

可是在實際配置過程當中，咱們可將後面三部分簡化爲 listen。所以，咱們在這裏對 global、defaults 部分的配置字段作一一解釋，以下表：

d、HAProxy 配置文件修改

通常狀況下，第一部分 global 和第二部分 defaults 不用修改，保持默認便可，所以，咱們這裏主要進行第三部分 listen 的修改。

咱們將

行下的部分所有刪除，而後添加 listen 部分：

listen stats #這裏的 stats 能夠自定義

         bind 0.0.0.0:1050 #監聽端口，可自定義

         stats refresh 30s #統計頁面自動刷新時間

         stats uri /monitor #統計頁面 url

         stats realm Haproxy Monitor #統計頁面密碼框提示文本

         stats auth admin:admin #統計頁面用戶名和密碼

         stats hide-version #隱藏統計界面上的 HAProxy 的版本信息

listen myweb 0.0.0.0:80 #能夠自定義命名，網址+ip+端口

         cookie SERVERID rewrite

         balance roundrobin #動態輪詢調度算法

         server web1 172.16.0.3:80 cookie application1instances1 check inter 2000 rise 2 fall 5

         server web2 172.16.0.4:80 cookie application1instances2 check inter 2000 rise 2 fall 5 #表示後端服務器 web1 和 web2 ，IP 地址分別爲 172.16.0.3 和 172.16.0.4，經過寫cookie信息設置狀態，application，應用，instances，實例，check對服務器作健康檢查，inter 2000毫秒，若是連續兩次檢查都是成功的（rise 2）則說明服務器是好的，若是連續五次檢查都是失敗的（fall 5）則說明服務器是壞的。

如圖：

保存並退出，啓動或重啓（以前有啓動過） HAProxy 服務。

[root@haproxy ~]# systemctl start haproxy

或

[root@haproxy ~]# systemctl restart haproxy

e、驗證

首先，咱們驗證站點訪問，在瀏覽器中輸入http://192.168.20.140/，結果如圖：

其次，咱們驗證監控站點，在瀏覽器中輸入http://192.168.20.140:1050/monitor，如圖：

會要咱們輸入用戶名和密碼，就是咱們在配置文件中設置的 admin

登錄以後，界面以下：

如圖，在左邊紅框內，主要展現一些 HAProxy 服務器的狀態，包括啓動時間、PID號等等，而右邊紅框內主要展現顏色標誌，具體的顏色變化會展現在下邊的 web一、web2 的行，須要注意的時，4個顏色的變化，以下圖：

表示服務在線正常

      表示服務在線，可是已經 down 掉

   表示服務已經 down 掉，可是正在恢復中

     表示服務已經所有 down 掉，沒法提供服務

以上配置是 HAProxy 的 L7（HTTP）負載均衡配置。下面咱們看下 L4（TCP）負載均衡配置

5、HAProxy 的 L4 （TCP）配置

其實 HAProxy 的 L4（TCP）配置和 L7（HTTP）配置是差很少的，只須要更改以下三個地方

一、將配置文件中 mode http 修改成 mode tcp ，表示開啓 TCP 模式

二、將配置文件中 option httplog 修改成 option tcplog ，表示開啓 tcplog

三、將 balance roundeobin 修改成 balance source，表示基於客戶端的 IP 會話保持。

而其餘部分暫時能夠不用修改，在使用過程當中，咱們能夠根據實際數據進行更改。

6、日誌查看

前面咱們配置了 HAProxy 的日誌，它的日誌會記錄在系統的 messages 日誌裏面，如今咱們來看一下，日誌的內容

當咱們訪問站點時，日誌會在 messages 中刷新，如上圖，主要會記錄後端服務器的訪問狀況以及當會話閒置時 HAProxy 的狀態日誌，固然，咱們只是配置僅限有日誌，並未配置其餘類型的日誌進行記錄，因此這裏只會顯示這麼多。

到此爲止，咱們的 HAProxy 部署配置已結束，若是想了解更多相關的只是，請參閱官方文檔。官方文檔