建立 Monitor 并測試 - 每天5分鐘玩轉 OpenStack（124）建立 Monitor測試 LBaaS

前面我們建立了 Pool，VIP 并添加了 Member。今天将建立 Monitor，然後測試 LBaaS 是否能夠正常工作。

LBaaS 可以建立 monitor，用于監控 Pool Member 健康狀态。 如果某個 member 不能正常工作，monitor 會将其狀态設定為 down，進而避免将後續請求轉發給它。

下面我們為 Pool 添加一個 monitor。 在 Monitors 标簽頁中點選 “Add Monitor” 按鈕

Type 選擇 “HTTP”，含義是通過 HTTP 檢查 member 的健康狀态。 

Delay 設定為 “10”，含義是 10 秒檢查一次 member 的狀态。 

Timeout 設定為 “5”，含義是如果 member 在 5 秒内無法應答，則逾時。 

Max Reties 設定為 “3”，含義是如果嘗試 3 次都逾時或者失敗，則将 member 狀态設定為 down。

HTTP Method 設定為 “GET” 

URL 設定為 “/” 

Expected HTTP Status Codes 設定為 “200”

上面三項的含義是通過 HTTP GET 請求 member “/” URL，如果傳回碼為 200，則認為 member 狀态正常。

點選 “Add”，monitor 建立成功。

下面将建立的 monitor 添加到 pool 。 

在 “web servers” 的操作清單中點選 “Associate Monitor”

選擇我們剛剛建立的 monitor。

點選 “Associate”。

經過上面的設定，我們建立了包含 member “Web1” 和 “Web2” 的 Pool “web servers”，并添加了 monitor。 準備就緒，可以測試 load balancer 是否正常工作了。

首先在 Web1 和 Web2 中啟動 HTTP 服務，在 80 端口監聽

這裡我們使用 python 提供的 SimpleHTTPServer 子產品啟動了 HTTP 服務。 

web server 的 index.html 顯示目前通路的是哪個 member。

在 router 的 namespace 上多次執行 curl 172.16.100.11（VIP）

測試結果顯示每次通路的都是 Web2 這個 member。 

為什麼沒有通路到 Web1 呢？

還記得我們前面讨論的内容嗎： 

Load Balance Method -- ROUND_ROUBIN 

Session Persistence -- SOURCE_IP

在這種配置下，第一個 curl 請求 HAProxy 通過 ROUND_ROUBIN 選擇了 Web2。

而後續的請求，HAProxy 則會應用 SOURCE_IP 機制，仍然選擇 Web2。

下面我們修改一下配置。 在 “web servers” 的操作清單中點選 “Edit VIP”。

選擇 “No session persistence” 并儲存。

再進行 curl 測試。

可以看到已經在 “Web1” 和 “Web2” 之間 round robin 了。

下一節我們将分析 LBaaS 的内部實作和工作機制。

本文轉自CloudMan6 51CTO部落格，原文連結:http://blog.51cto.com/cloudman/1881787