前面我們創建了 Pool，VIP 並添加了 Member。今天將創建 Monitor，然后測試 LBaaS 是否能夠正常工作。
創建 Monitor
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”。
測試 LBaaS
經過上面的設置，我們創建了包含 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 的內部實現和工作機制。
