OpenStack Endpoint Load Balancer¶

为了能够在相同的广播域内安装高度可用的配置，从而启用单个云的 Openstack 服务。

问题描述¶

作为云管理员，我希望简化我的部署，这样我就不必为每个 OpenStack API 服务管理一个 corosync 和 pacemaker。
作为云架构师，我正在设计一个新云，所有服务都将位于单个广播域中。我认为没有必要使用新的中央负载均衡器，并且希望继续让每个服务管理自己的 VIP。
作为云架构师，我希望将我的控制平面跨 N 个机架进行冗余部署。每个机架位于自己的广播域中。我不希望云的用户需要了解此拓扑。我希望在 Keystone 中注册的端点无论机架级别故障如何都能工作。我正在使用网络空间来隔离云中的流量，并且 OpenStack 负载均衡器可以访问所有空间，因此我只需要一个负载均衡器集来进行部署。
作为云架构师，我希望将我的控制平面跨 N 个机架进行冗余部署。每个机架位于自己的广播域中。我不希望云的用户需要了解此拓扑。我希望在 Keystone 中注册的端点无论机架级别故障如何都能工作。我正在使用网络空间来隔离云中的流量。我希望隔离扩展到负载均衡器，因此将需要每个网络空间一组负载均衡器。
作为云架构师，我正在设计一个新的内部云，并且对 IPv6 不感兴趣，我希望部署一个纯 IPv4 解决方案。
作为云架构师，我正在设计一个新的云。我了解到自 IETF 为我们带来 IPv6 以来已经过去了 18 年，并且可能现在是时候在云中启用 IPv6 了。我很高兴在需要时拥有一些 IPv4，并且正在寻找部署双栈 IPv4 和 IPv6 的方案。
作为云架构师，我正在设计一个新的云。我了解到自 IETF 为我们带来 IPv6 以来已经过去了 18 年，并且希望再也看不到 IPv4 地址了。我正在寻找部署一个纯 IPv6 云的方案。
作为云架构师，我希望将 DNS HA 与 OpenStack 负载均衡器结合使用，以便负载均衡器单元可以分布在每个网络空间内的不同子网中。
作为云管理员，我希望 OpenStack 负载均衡器负责 HA，因此将以主动/被动部署方式进行部署。在这种配置中，我需要使用 VIP 作为负载均衡器。
作为云架构师，我有一个现有的硬件负载均衡器想要使用。我不想用每个 API 服务后端的地址来更新它。相反，我希望 OpenStack 负载均衡器以主动/主动配置，并让硬件负载均衡器管理 OpenStack 负载均衡器服务中 haproxy 实例之间的流量。在这种配置中，我不需要使用 VIP 作为负载均衡器。我的硬件负载均衡器使用 vip(s)，这些 vip(s)需要作为 Keystone 中服务的端点进行注册。
作为云管理员，haproxy 统计信息对我来说非常有趣，我希望汇总所有 haproxy 实例的统计信息。
作为云管理员，我希望 haproxy 能够对后端执行健康检查，从而比简单的开放端口检查更确凿地断言服务的健康状况。
作为云管理员，我希望能够随着云的发展配置最大连接数和超时时间。
作为 OpenStack 负载均衡器后服务的 charm 作者，我希望能够告诉负载均衡器排出到特定单元的连接并将其退出服务。这将允许该单元进入维护模式。

提议的变更¶

新接口：openstack-api-endpoints¶

此接口允许托管 API 端点的后端 charm 向 OpenStack 负载均衡器告知它正在托管哪些服务，以及后端单元上应该将前端 API 请求发送到哪个 IP 地址和端口。它还允许后端 charm 告知负载均衡器应该为每个服务使用哪个前端端口。

示例 - neutron-api（每个单元一个 API 端点）

endpoints:
  - service-type: network
    frontend-port: 9696
    backend-port: 9689
    backend-ip: 10.10.10.1
    check-type: http

示例 - nova-cloud-controller（每个单元多个 API 端点）

endpoints:
  - service-type: nova
    frontend-port: 8774
    backend-port: 8764
    backend-ip: 10.10.10.2
    check-type: http
  - service-type: nova-placement
    frontend-port: 8778
    backend-port: 8768
    backend-ip: 10.10.10.2
    check-type: http

OpenStack 负载均衡器应用程序的单个实例将仅服务于一种 OpenStack API 端点类型（公共、管理或内部）。该 charm 将使用前端接口的网络空间绑定来确定后端 API 服务应该用于云端点目录注册的 IP 或 VIP（如果以 HA 配置部署）。

在处理完所有后端单元的请求后，负载均衡器现在需要告知后端应用程序用于侦听每个端点服务类型连接的外部 IP。

endpoints:
  - service-type: nova
    frontend-ip: 98.34.12.1
    frontend-port: 8774
  - service-type: nova-placement
    frontend-ip: 98.34.12.1
    frontend-port: 8778

后端服务现在更新 Keystone 注册表中的端点，以指向负载均衡器返回的 IP。

此接口由每个后端 API charm 提供，并通过 OpenStack 负载均衡器 charm 的后端接口进行消费。每个后端 charm 将提供三种类型的此接口。

provides:
  public-backend:
    interface: openstack-api-endpoints
  admin-backend:
    interface: openstack-api-endpoints
  internal-backend:
    interface: openstack-api-endpoints

采用这种方法意味着后端 charm 可以继续作为某些端点类型的入口点/负载均衡器，并将其他入口点的负载均衡推送到 OpenStack 负载均衡器 charm（或多个实例）。

Keystone 端点计算代码的更新¶

当前，以下竞争选项用于计算应该在 Keystone 中注册哪个 EP

os-*-network 设置 do resolve_address 旧方法
dnsha 使用 dnsha
os-*-hostname 设置使用 hostname
juju 网络空间绑定通过 extra-bindings
通过配置选项优先使用 ipv6
存在到 openstack 负载均衡器的 {public,internal,admin}-backend 关系

OpenStack 负载均衡器 charm¶

新 charm - OpenStack 负载均衡器 - 及其相应的测试和 QA CI/设置。

备选方案¶

扩展现有的 HAProxy charm。
使用 DNS HA。

实现¶

负责人¶

主要负责人: 未知

Gerrit Topic¶

使用 Gerrit 主题“osbalancer”用于与此规范相关的所有补丁。

git-review -t osbalancer

工作项¶

提供 OpenStack 负载均衡器 Charm¶

编写 LB <-> 后端的草稿接口
编写 Keystone 端点注册代码的单元测试
编写 Keystone 端点注册代码

Mojo 规范部署和测试 Mistral¶

编写 Mojo 规范以在 HA 配置中部署 LB

仓库¶

将需要一个新的 git 存储库用于 Mistral charm

https://git.openstack.org/openstack/charm-openstack-loadbalancer

文档¶

OpenStack 负载均衡器 charm 应该包含一个 README，其中包含有关部署 charm 的说明。一篇博文是可选的，但会是一个有用的补充。

安全性¶

没有额外的安全问题。

测试¶

代码更改将由单元测试覆盖；功能测试将使用 Amulet、Bundle tester 和 Mojo 规范的组合进行。

依赖项¶

无

OpenStack 端点负载均衡器