建立 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。