建立 Pool & VIP - 天天5分鐘玩轉 OpenStack（122）

上節完成了 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 方式：

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

前面咱們介紹了三種 Load Balance Method：

這裏還有三種 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 建立完畢，下一節咱們向 Pool 添加 Member。