如何創(chuàng)建Pool及添加VIP

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

今天我們實現(xiàn)如下 LBaaS 環(huán)境。

環(huán)境描述如下：
1. 創(chuàng)建一個 Pool “web servers”。
2. 兩個 pool member “WEB1” 和 “WEB2”，均為運行 Ubuntu cloud image 的 instance。
3. load balancer VIP 與 floating IP 關(guān)聯(lián)。
4. 位于外網(wǎng)的 client 通過 floating IP 外網(wǎng)訪問 web server。

我們從第一步開始。

創(chuàng)建 Pool

點擊菜單 Project -> Network -> Load Balancers，點擊 Pools 標簽頁中的 “Add Pool” 按鈕。

顯示 Pool 創(chuàng)建頁面。

將 Pool 命名為“web servers”。
Provider 選擇默認的 “haproxy”。
Subnet 選擇 “172.16.100.0/24”。
Protocol 選擇 “HTTP”。
Load Balancing Method 選擇 “ROUND_ROBIN”。

點擊 “Add” 按鈕，“web servers” 創(chuàng)建成功。

這里對 Pool 的幾個屬性進行一下說明。

LBaaS 支持如下幾種 Protocol:

因為我們用 web server 做實驗，所以這里需要選擇 “HTTP”

LBaaS 支持多種 load balance method

ROUND_ROUBIN
如果采用 round robin 算法，load balancer 按固定的順序從 pool 中選擇 member 相應(yīng) client 的連接請求。 這種方法的不足是缺乏機制檢查 member 是否負載過重。 有可能出現(xiàn)某些 member 由于處理能力弱而不得不繼續(xù)處理新連接的情況。 如果所有 pool member 具有相同處理能力、內(nèi)存容量，并且每個連接持續(xù)的時間大致相同，這種情況非常適合 round robin，每個 member 的負載會很均衡。

LEAST_CONNECTIONS
如果采用 least connections 算法，load balancer 會挑選當前連接數(shù)最少的 pool  member。 這是一種動態(tài)的算法，需要實時監(jiān)控每個 member 的連接數(shù)量和狀態(tài)。 計算能力強的 member 能夠更快的處理連接進而會分配到更多的新連接。

SOURCE_IP
如果采用 source IP 算法，具有相同 source IP 的連接會被分發(fā)到同一個 pool member。 source IP 算法對于像購物車這種需要保存狀態(tài)的應(yīng)用特別有用，因為我們希望用同一 server 來處理某個 client 連續(xù)的在線購物操作。

在我們的實驗中選擇的是 ROUND_ROUBIN 算法。

為 Pool 添加 VIP

現(xiàn)在 Pool 已經(jīng)就緒，接下需要為其設(shè)置 VIP。 在 “web servers” 的操作列表中點擊 “Add VIP”。

VIP 命名為 “VIP for web servers”。

VIP Subnet 選擇 “172.16.100.0/24”，與 pool 一致。
指定 VIP 為 172.16.100.11，如果不指定，系統(tǒng)會自動從 subnet 中分配。
指定 HTTP 端口 80。
Session Persistence 選擇 “SOURCE IP”。
可以通過 Connection Limit 限制連接的數(shù)量，如果不指定則為不加限制。

點擊 “Add”，VIP 創(chuàng)建成功。

通常我們希望讓同一個 server 來處理某個 client 的連續(xù)請求。 否則 client 可能會由于丟失 session 而不得不重新登錄。

這個特性就是 Session Persistence。 VIP 支持如下幾種 Session Persistence 方式：

SOURCE_IP
這種方式與前面 load balance 的 SOURCE_IP 效果一樣。 初始連接建立后，后續(xù)來自相同 source IP 的 client 請求會發(fā)送給同一個 member。 當大量 client 通過同一個代理服務(wù)器訪問 VIP 時（比如在公司和學(xué)校上網(wǎng)），SOURCE_IP 方式會造成 member 負載不均。

HTTP_COOKIE

HTTP_COOKIE 的工作方式如下： 當 client 第一次連接到 VIP 時，HAProxy 從 pool 中挑選出一個 member。 當此 member 響應(yīng)請求時，HAProxy 會在應(yīng)答報文中注入命名為 “SRV” 的 cookie，這個 cookie 包含了該 member 的唯一標識。 client 的后續(xù)請求都會包含這個 “SRV” cookie。 HAProxy 會分析 cookie 的內(nèi)容，并將請求轉(zhuǎn)發(fā)給同一個 member。

HTTP_COOKIE 優(yōu)于 SOURCE_IP，因為它不依賴 client 的 IP。

APP_COOKIE
app cookie 依賴于服務(wù)器端應(yīng)用定義的 cookie。 比如 app 可以通過在 session 中創(chuàng)建 cookie 來區(qū)分不同的 client。
HAProxy 會查看報文中的 app cookie，確保將包含 app cookie 的請求發(fā)送到同一個 member。
如果沒有 cookie（新連接或者服務(wù)器應(yīng)用不創(chuàng)建 cookie），HAProxy 會采用 ROUND_ROUBIN 算法分配 member。

比較 Load Balance Method 和 Session Persistence

這里還有三種 Session Persistence

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

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

2. Session Persistence 是為同一個 client 的后續(xù)連接選擇 member 的方法

例如這里我們的設(shè)置為：
Load Balance Method -- ROUND_ROUBIN
Session Persistence -- SOURCE_IP

當 client A 向 VIP 發(fā)送第一個請求時，HAProxy 通過 ROUND_ROUBIN 選擇 member1。對于 client A 后續(xù)的請求，HAProxy 則會應(yīng)用 SOURCE_IP 機制，仍然選擇 member1 來處理請求。

關(guān)于如何創(chuàng)建Pool及添加VIP就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。