上節完成了 LBaaS 配置，今天我們開始實作如下 LBaaS 環境。
環境描述如下：
1. 建立一個 Pool “web servers”。
2. 兩個 pool member “WEB1” 和 “WEB2”，均為運作 Ubuntu cloud image 的 instance。
3. load balancer VIP 與 floating IP 關聯。
4. 位于外網的 client 通過 floating IP 外網通路 web server
我們從第一步開始。
建立 Pool
點選菜單 Project -> Network -> Load Balancers，點選 Pools 标簽頁中的 “Add Pool” 按鈕。
顯示 Pool 建立頁面。
将 Pool 命名為“web servers”。
Provider 選擇預設的 “haproxy”。
Subnet 選擇 “172.16.100.0/24”。
Protocol 選擇 “HTTP”。
Load Balancing Method 選擇 “ROUND_ROBIN”。
點選 “Add” 按鈕，“web servers” 建立成功。
這裡對 Pool 的幾個屬性進行一下說明。
LBaaS 支援如下幾種 Protocol:
因為我們用 web server 做實驗，是以這裡需要選擇 “HTTP”
LBaaS 支援多種 load balance method:
ROUND_ROUBIN
如果采用 round robin 算法，load balancer 按固定的順序從 pool 中選擇 member 相應 client 的連接配接請求。 這種方法的不足是缺乏機制檢查 member 是否負載過重。 有可能出現某些 member 由于處理能力弱而不得不繼續處理新連接配接的情況。 如果所有 pool member 具有相同處理能力、記憶體容量，并且每個連接配接持續的時間大緻相同，這種情況非常适合 round robin，每個 member 的負載會很均衡。
LEAST_CONNECTIONS
如果采用 least connections 算法，load balancer 會挑選目前連接配接數最少的 pool member。 這是一種動态的算法，需要實時監控每個 member 的連接配接數量和狀态。 計算能力強的 member 能夠更快的處理連接配接進而會配置設定到更多的新連接配接。
SOURCE_IP
如果采用 source IP 算法，具有相同 source IP 的連接配接會被分發到同一個 pool member。 source IP 算法對于像購物車這種需要儲存狀态的應用特别有用，因為我們希望用同一 server 來處理某個 client 連續的線上購物操作。
在我們的實驗中選擇的是 ROUND_ROUBIN 算法。
為 Pool 添加 VIP
現在 Pool 已經就緒，接下需要為其設定 VIP。 在 “web servers” 的操作清單中點選 “Add VIP”。
VIP 命名為 “VIP for web servers”。
VIP Subnet 選擇 “172.16.100.0/24”，與 pool 一緻。
指定 VIP 為 172.16.100.11，如果不指定，系統會自動從 subnet 中配置設定。
指定 HTTP 端口 80。
Session Persistence 選擇 “SOURCE IP”。
可以通過 Connection Limit 限制連接配接的數量，如果不指定則為不加限制。
點選 “Add”，VIP 建立成功。
通常我們希望讓同一個 server 來處理某個 client 的連續請求。 否則 client 可能會由于丢失 session 而不得不重新登入。
這個特性就是 Session Persistence。 VIP 支援如下幾種 Session Persistence 方式：
這種方式與前面 load balance 的 SOURCE_IP 效果一樣。 初始連接配接建立後，後續來自相同 source IP 的 client 請求會發送給同一個 member。 當大量 client 通過同一個代理伺服器通路 VIP 時（比如在公司和學校上網），SOURCE_IP 方式會造成 member 負載不均。
HTTP_COOKIE
HTTP_COOKIE 的工作方式如下： 當 client 第一次連接配接到 VIP 時，HAProxy 從 pool 中挑選出一個 member。 當此 member 響應請求時，HAProxy 會在應答封包中注入命名為 “SRV” 的 cookie，這個 cookie 包含了該 member 的唯一辨別。 client 的後續請求都會包含這個 “SRV” cookie。 HAProxy 會分析 cookie 的内容，并将請求轉發給同一個 member。
HTTP_COOKIE 優于 SOURCE_IP，因為它不依賴 client 的 IP。
APP_COOKIE
app cookie 依賴于伺服器端應用定義的 cookie。 比如 app 可以通過在 session 中建立 cookie 來區分不同的 client。
HAProxy 會檢視封包中的 app cookie，確定将包含 app cookie 的請求發送到同一個 member。
如果沒有 cookie（新連接配接或者伺服器應用不建立 cookie），HAProxy 會采用 ROUND_ROUBIN 算法配置設定 member。
前面我們介紹了三種 Load Balance Method：
這裡還有三種 Session Persistence：
因為兩者都涉及到如何選擇 pool member，是以很容易混淆。 它們之間的最大差別在于選擇 pool member 的階段不同：
Load Balance Method 是為新連接配接選擇 member 的方法
Session Persistence 是為同一個 client 的後續連接配接選擇 member 的方法
例如這裡我們的設定為：
Load Balance Method -- ROUND_ROUBIN
Session Persistence -- SOURCE_IP
當 client A 向 VIP 發送第一個請求時，HAProxy 通過 ROUND_ROUBIN 選擇 member1。對于 client A 後續的請求，HAProxy 則會應用 SOURCE_IP 機制，仍然選擇 member1 來處理請求。
Pool 建立完畢，下一節我們向 Pool 添加 Member。