本作品采用知识共享署名 3.0 非移植许可协议授权。 http://creativecommons.org/licenses/by/3.0/legalcode
批量区域更新节流¶
https://blueprints.launchpad.net/designate/+spec/notify-throttling
实现一种机制，以节流在大量区域同时更新时 NOTIFY 事务的传递。
问题描述¶
如果在短时间内更新大量区域，这将产生大量的 NOTIFY 事务，无延迟地发送到名称服务器，导致大量传入的 AXFR 请求。这可能会对 MiniDNS 和存储层在 CPU、I/O 或网络带宽方面造成瓶颈影响。
一个典型的触发器是在包含许多区域的池中更新 NS 记录。
解析器执行的自主区域刷新也可能触发类似的 AXFR 爆发。这可能发生在最近启动的解析器上，其中刷新计时器可以在许多区域之间共享相同的值。
提议的变更¶
实现一种机制，用于对 notify 事务进行排队和延迟传递，并具有可配置的节流速度。
此外，通过随机化刷新间隔来实现区域刷新请求的交错。
API 变更¶
在 Admin API 中将标记为延迟 notify 的区域数量作为“/reports/counts/zones_pending_notify”公开。
Central 变更¶
实现对新数据库列“pending_notify”的支持，并在每次更新池 NS 记录时将其设置为 True。
Storage 变更¶
在 Zones 上添加一个新的布尔数据库列“pending_notify”。实现一个迁移脚本将该列添加到现有数据库，默认值为 False。将来，该列可能会默认设置为 True。
其他变更¶
在区域管理器中实现一个任务，以定期获取需要接收 Notify 的区域集合，从上次更新时间最旧的区域开始。任务频率和最大集合大小可以配置为节流传出的 Notify。区域管理器在完成操作后将重置“pending_notify”标志。
替代方案¶
N/A
实现¶
节流队列被实现为新的数据库列，包含一个布尔标志。请参阅中央更改和存储更改。
此外，新区域将使用介于最小值和最大值之间的均匀随机刷新时间创建。
设计考虑¶
节流队列可以实现于数据库之外：- 无需创建额外的数据库列 - 无增加数据库 I/O
我们建议使用数据库的原因如下：- 区域管理器是处理延迟 Notify 的最佳候选者。目前，没有办法通过数据库将区域列表发送到区域管理器 - 队列可以支持池 NS 记录更新以外的其他更改的延迟 Notify - 能够监控队列大小和 ETA，以告知用户并用于调试 - 持久的队列可以承受区域管理器未处理的异常或重启 - 增加的数据库负载与现有流量相比可以忽略不计
风险分析¶
区域管理器未能运行 Notify 传递任务。名称服务器最终会刷新区域。影响：更新传播缓慢。缓解措施：通过 Admin API 和日志向用户公开通知队列长度。
一个大的通知队列需要相当长的时间才能处理。影响：可能阻止更紧急的更改快速传递。缓解措施：鼓励用户配置节流参数；提供合理默认值。实施通知优先级概念似乎没有必要。
负责人¶
- 主要负责人
Federico Ceratto https://launchpad.net/~federico-ceratto
里程碑¶
- 完成目标里程碑
Liberty-3
工作项¶
实现刷新时间交错
实现 Notify 节流
将节流参数添加到配置文件
记录节流机制
编写单元和功能测试
在 devstack 上测试节流和交错
依赖项¶
N/A
