1. 程式人生 > >HAProxy動靜分離和會話粘性例項

HAProxy動靜分離和會話粘性例項

HAProxy簡介及常用配置檔案詳解見:http://blog.51cto.com/holmes975/2333207

一、HAProxy的動靜分離實現例項
HAProxy動靜分離和會話粘性例項

我們通過CentOS7.5中的HAProxy實現負載均衡排程功能,將使用者發來的請求進行動態靜態分離並將請求傳送到後端不同的伺服器上。三臺後端伺服器CentOS7.5A、CentOS7.5B、CentOS7.5C上分別開啟httpd或nginx服務提供可訪問的web端。(haproxy本身是不提供可訪問的web頁面)

CentOS7.5----HAProxy配置檔案:
HAProxy動靜分離和會話粘性例項
我定義了一個叫做main的frontend,監聽所有IP的80埠,下面寫了兩條ACL規則,將PATH部分以/static /images /javascript /stylesheets開頭的和PATH部分以.jpg .jpeg .gif .png .css .js .txt .html .htm結尾的(-i 不區分大小寫的意思)定義到一個叫url_static的規則裡。
use_backend static if url_static
default_backend app


如果符合url_static規則就將訪問請求傳送到叫做static的後端伺服器上,預設的後端伺服器使用叫做app。
下面分別定義了兩個後端伺服器static和app。
static:輪詢演算法呼叫伺服器(一個一個的按順序的呼叫所定義的伺服器),排程到179.5.99.15:80.
app:使用預設輪詢方式排程兩臺後端伺服器app1和app2。

下面進行測試:
向CentOS7.5C靜態伺服器httpd下建立一個名為index.html內容為7.5A的檔案。
HAProxy動靜分離和會話粘性例項
向CentOS7.5A動態伺服器httpd下建立一個名為sessiontest.php內容為php測試指令碼的檔案。
HAProxy動靜分離和會話粘性例項
向CentOS7.5B動態伺服器nginx下新增相同檔案。

訪問測試:
HAProxy動靜分離和會話粘性例項
可見由.html結尾的檔案被分配到7.5C伺服器上。
HAProxy動靜分離和會話粘性例項
HAProxy動靜分離和會話粘性例項
而不符合該ACL規則的其他訪問被分配到7.5A和7.5B上。證明試驗成功,實現了最基本的動靜分離,如有特殊情況可自行修改ACL規則實現需要的動靜分離。

二、利用cookie實現會話粘性
簡單解釋會話粘性就是指在執行某種操作時需要與一臺後端伺服器實現一段時間的定向連線。
根據上面動靜分離實驗我們對7.5A和7.5B進行實驗。

listen stats #關聯前端和後端定義一個完整的代理
mode http #設定代理協議
bind 0.0.0.0:8080 #繫結相應的埠
stats enable #開啟Haproxy統計狀態
stats refresh 30s #統計頁面自動重新整理時間間隔
stats uri /admin?stats #訪問的url
stats realm "welcome to check haproxy stats !" #統計頁面認證時提示內容資訊
stats auth admin:123456 #設定登入使用者和密碼
stats admin if TRUE #如果認證通過,則就可以開啟stats


以上程式碼在haproxy的配置檔案中(我的是/etc/haproxy/haproxy.cfg),作用是對後端伺服器的健康狀態檢測。一會檢驗試驗是否成功我們會用到。

HAProxy動靜分離和會話粘性例項
上圖為加入cookie保持的配置檔案,詳細含義見http://blog.51cto.com/holmes975/2333207
演算法我是用leastconn,此演算法針對會話保持更為有效,具體含義見上篇部落格。
下面我們重啟haproxy服務進行測試,測試在訪問動態資源時是否為我們分配到同一臺伺服器而不是每臺伺服器為我們響應一次。
]# systemctl reload haproxy
HAProxy動靜分離和會話粘性例項
無論我們怎麼重新整理都不會被分配到7.5B上,說明我們的會話粘性起了作用。為證明7.5B伺服器並沒有被關閉我們使用上面程式碼提到的狀態檢測頁面;
HAProxy動靜分離和會話粘性例項
可以看到我們的app1和app2都在執行狀態下,重新整理後還是保持在7.5A也就是app1的伺服器上,證明我們試驗成功。(static也就是靜態伺服器不用了,所以剛剛我就將它關掉了,可見down掉的伺服器呈紅色)