Neutron/LBaaS/LoadbalancerInstance

目前对象图的根是一个池。当我们迁移到 m:n vip-pool 关系时，维护和验证此类配置将变得更加复杂。负载均衡器实例用作配置图的封装，简化了诸如绑定、验证、从服务器获取、REST 调用分派等任务
Loadbalancer 可以用于将配置绑定到提供程序、设备、代理（主机）、路由器

API 变更

将引入新的资源 Loadbalancer，其属性反映相应的模型（如下所示）。
Loadbalancer 将支持完整的操作集：创建、更新、删除。
VIP、Pool、Member、HealthmonitorAssociation 将获得 loadbalancer_id 属性，该属性仅可为 Pool 提供（在 POST 请求中）。
对于 VIP、Member 和 HealthmonitorAssociation，loadbalancer_id 将从相关的 Pool 对象中推断出来。

Cli 工作流示例
示例 1

lb-balancer-create --name name

lb-pool-create [--loadbalancer_id id] [usual parameters]

lb-vip-create --pool-id id

lb-balancer-show balancer_id
returns object:
---------------------------------
balancer_id id

pools: [list of pools]

vips: [list of vips]

---------------------------------

示例 2（隐式创建负载均衡器）
lb-pool-create [常规参数]
lb-vip-create --pool-id id

lb-pool-show pool_id
返回 loadbalancer_id 以及其他属性
lb-balancer-show loadbalancer_id 返回为池创建的默认负载均衡器对象

换句话说，API 与现有 API 兼容，但未来允许为同一个负载均衡器指定多个 vip 或池。

数据模型变更

添加 Loadbalancer 实例是朝着将 vip-pool 关系从 1:1 更改为 m:n 的一步，但首先我们将仅将 Loadbalancer 资源引入 API 并对其他对象进行相应的更改。

Loadbalancer object:
 * id - uuid, string(36)
 * tenant_id - String(255)
 * Name - String(255)

对 VIP、Pool、Member 对象提出的更改是向每个对象添加 loadbalancer_id。
即使 member 与相关的池相关联，而池又与 balancer 相关联，但在处理 member 时保存数据库查询可能是有道理的，因此这种数据复制可能是合理的。
对于 VIP 也是如此。当前可以通过池访问 loadbalancer_id，但迁移到 m:n 关系将使该过程复杂化。

换句话说，REST 调用分派（例如，选择适当的驱动程序来处理对象）将通过 Loadbalancer 对象而不是通过池来处理。

数据库迁移

除了 VIP、Pool、Member 模型的简单迁移之外，还应为每个现有池创建 Loadbalancer 对象，并将相应的对象链接到此实例。

实施计划

neutron-server 变更

- lbaas 扩展变更
- 数据库模型和逻辑变更
- 插件变更（通过负载均衡器而不是池进行分派）

python-neutronclient
horizon

Neutron/LBaaS/LoadbalancerInstance

目录

描述

原理

API 变更

数据模型变更

数据库迁移

实施计划