如何創建Pool及添加VIP

這篇文章給大家介紹如何創建Pool及添加VIP，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

今天我們實現如下 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 方式：

SOURCE_IP
這種方式與前面 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

這里還有三種 Session Persistence

因為兩者都涉及到如何選擇 pool member，所以很容易混淆。 它們之間的最大區別在于選擇 pool member 的階段不同：

1. Load Balance Method 是為新連接選擇 member 的方法

2. 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及添加VIP就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。