designate-bind: 可配置的服务 IP¶

原始 LP bug： https://bugs.launchpad.net/charm-designate-bind/+bug/1804057

Bootstack 团队描述的问题是，当 designate-bind [1] 单元重新部署时，它们有可能收到一个新的 IP 地址。如果之前的 IP 地址在基础设施的其他非 Juju 部分被用来引用 designate 提供的 DNS 服务（例如，如果这些 IP 地址被用于上游 DNS 服务器的区域委派，或者被用于转发/防火墙规则），这将是一个问题。建议的解决方案是允许配置静态 IP 地址，即使在重新部署后也能在单元上保留这些地址。

问题描述¶

单元 IP 地址更改的可能性要求每次部署都需要跟踪所有通过 IP 地址引用 designate-bind 单元的外部系统，并在单元重新部署时手动更改这些引用。这些手动操作容易出错，并且会引入更新过程中的延迟，例如，SOA DNS 记录的传播需要时间，具体取决于其超时值。

提议的变更¶

该解决方案的核心应该是在 designate-bind charm 中添加一个新的配置选项，允许指定来自未受 DHCP 控制的保留池的静态 IP 地址。此配置选项将称为 service-ips，它将包含一个逗号分隔的 IP 地址列表，这些地址可以静态配置在 designate-bind 单元面向的“DNS 前端”接口上，除了通常由 DHCP 分配的地址之外。

在原始 Launchpad issue 和评论中提出了两种替代解决方案。一种解决方案是让 designate-bind charm 自己处理地址分配和分发，另一种建议的解决方案是基于使用 hacluster subordinate charm [2]，该 charm 将把服务 IP 作为资源进行管理。

基于 hacluster 的解决方案具有一定的优势，因此将其列为主要提出的解决方案。

基于 hacluster 的解决方案¶

此解决方案建议使用 hacluster subordinate charm。service-ips 将通过 juju config 在 designate-bind charm 上配置，但 designate-bind 不负责管理这些 IP。相反，与 charm-hacluster 的关系将被用来在 pacemaker [3] 中为每个服务 IP 创建一个集群资源。这些资源可以配置为协同定位规则，例如，如果存在没有分配服务 IP 的其他主机，则它们永远不会被放置在同一主机上。可以通过为资源指定负协同定位分数来实现这一点 [6]（有关分数计算，请参见 [7]）。

服务 IP 集群资源的另一个限制可能是 designate-bind 单元上的实际网络配置。服务 IP 必须位于单元上配置的网络内，并且多个单元不一定需要在同一网络上。集群资源约束“location” [9] 可用于配置集群资源以优先选择或避免某些主机。

以牺牲 designate-bind 单元的负载（通过运行 charm-hacluster）为代价，该解决方案相当优雅，并将大部分逻辑和责任从 charm 的代码中移除。另一个好处是，即使在降级状态下，当某些单元关闭时，所有服务 IP 仍然可以正常工作，因为 hacluster charm 会将它们移动到正在运行的单元。

备选方案¶

此替代解决方案将在 designate-bind charm 内部管理所有内容，而无需添加新的依赖项。

由于 designate-bind 单元支持 HA 部署，并且通常以对的形式部署（例如，ns1.example.org、ns2.example.org），我们需要管理单元将如何从 service-ips 列表中选择 IP。此责任可以由 leader 单元处理。当 leader 单元上线时，它可以从列表中选择第一个 IP 地址并将其标记为“已用”。然后，当其他单元加入集群时，leader 会为它们选择服务 IP，将其标记为已用，并通过关系数据共享。leader 单元中选择 service-ips 中 IP 地址的回调函数应实现某种形式的锁，以防止两个单元同时加入集群关系时发生冲突。leader 单元应使用 leader-set [8] 来存储有关“已用”IP 地址的信息，以确保在 leader 单元更改的情况下保留此信息。

可以使用 netplan 在每个 designate-bind 单元上配置额外的 IP 地址，netplan 支持在启用 DHCP 的接口上定义静态 IP。这可以通过在接口对象中添加一个 addresses 字段来完成，同时保留 dhcp4: True 选项 [4]。

如果从集群中删除 designate-bind 单元，leader 单元应将先前分配的 IP 地址返回到可用服务 IP 池。

如果加入 designate-bind 集群的单元数量超过可用的服务 IP 地址数量，则没有服务 IP 的单元应进入阻止状态，并显示适当的消息。

如果修改 service-ips 选项，并且新的 IP 地址数量少于当前部署的 designate-bind 单元数量，leader 应重新分配可用的 IP 地址，并且没有 IP 地址的单元应进入阻止状态，并显示适当的消息。

如果 service-ips 选项从具有值更改为空值，leader 应触发所有 designate-bind 单元上的重新配置，这将删除先前静态配置的 IP 地址。如果由于缺乏可用的服务 IP 而被阻止的单元存在，则应将它们恢复到活动状态。

如果根本未设置 service-ips 选项，leader 单元不应执行任何特殊操作。

可选：除了配置更改之外，还可以实现一个确认 juju 操作，该操作将应用“service-ips”配置值。如果没有该操作，将不会对实时配置进行任何更改。这样做的原因是，它将作为用户确认更改是预期的，并且可以防止对“service-ips”配置进行不必要的更改以及可能的停机。此操作的另一个好处是，它可以一次应用于一个单元，因此如果配置有问题，它不会同时影响整个集群，而只会影响一个单元。

实现¶

负责人¶

主要负责人: martin-kalcok <martin.kalcok@canonical.com>

Gerrit Topic¶

对于与此规范相关的所有补丁，请使用 Gerrit 主题“<topic_name>”。

git-review -t designate-bind-serivce-ips

工作项¶

添加配置选项 service-ips
处理 service-ips 配置更改事件的处理器，该处理器在 designate-bind 单元上配置适当的 IP 地址

仓库¶

工作将在主 designate bind 存储库中进行

https://opendev.org/openstack/charm-designate-bind

文档¶

待更新

安全性¶

无

测试¶

需要单元和功能测试来验证此新功能。

依赖项¶

无

designate-bind: 可配置的服务 IP