正文共：2263 字，预估阅读时间：6 分钟
RFC1794：DNS Support for Load Balancing，April 1995br
本备忘录的状态
本备忘录为 Internet 社区提供信息。本备忘录未指定任何类型的 Internet 标准。本备忘录的分发不受限制。
1、 简介
本 RFC 旨在首先记录对 IETF DNS 工作组的尝试，讨论其他可能的替代方案来为 DNS 提供/模拟负载均衡支持，并为提供 DNS 支持以平衡多种类型的负载提供最终、灵活的解决方案。
2、 历史
这件事的历史可能可以追溯到我自己的时代之前——所以毫无疑问，这里有一些漏洞。希望他们可以由其他作者填写。
原来; “负载均衡”旨在允许域名系统 (Domain Name System，DNS) [1] 代理支持机器的“集群”（源自 VMS 使用）的概念——所有机器在功能上相似或相同，但它没有选择哪台机器并不特别重要——只要处理的负载合理地分布在一系列实际不同的主机上。大约在 1986 年，许多不同的方案开始作为对伯克利互联网名称域服务器 (Berkeley Internet Name Domain，BIND) 分发的黑客攻击而浮出水面。其中分布最广的可能是 Bryan Beecher 的“Shuffle Address”（SA）修改，或者可能是 Marshall Rose 的“Round Robin”代码。
然而，SA 记录对地址资源记录进行了循环排序，并且在目标机器上的特定负载方面没有做太多事情。TGV 的 Matt Madison 实施了一些更改，这些更改使用 VMS 工具来检查系统负载，并按照负载最小到最大的顺序返回 A RR。
SA 的问题在于负载实际上并不是一个因素，而 TGV 依靠 VMS 特定的设施来订购记录。SA RR 需要更改 DNS 规范（文件语法和记录处理）。这些都被视为缺点，而不是一般的解决方案。
大多数 Internet 都在等待 IETF 批准的模拟“集群”的方法。
通过几次 IETF DNS 工作组会议（由 Epilogue 的 Rob Austein 主持），大家一致同意必须满足一些标准：
A) 向后兼容现有的 DNS RFC。
B) 信息频繁更新。
C) 应发送多个地址。
D) 必须适当地与其他 RR 交互。
E) 必须能够表示多种类型的“负载”
F) 必须快。
(A) 将确保已安装的 BIND 和其他 DNS 实施基础将继续正常运行和互操作。
(B) 将允许非常快的更新时间——以实现实时数据的建模。五分钟被认为是一个正常的间隔，尽管可以想象每六十秒变化一次。
(C) 将涵盖主机地址被宣传为最佳的可能性，但机器在 RR 的 TTL 内的时间段内崩溃。第二优先的地址将被公布在第二位，第三最优先的地址将被公布在第三位，依此类推。这将允许在机器故障期间进行合理的恢复。
(D) 将确保正确处理所有辅助信息——例如 MX、RP 和 TXT 信息，以及反向查找信息。需要确保诸如邮件处理之类的过程继续以一种不出所料和可预测的方式工作。
(E) 将确保每个成员都希望的灵活性。 DNS 工作组的各个成员希望能够代表广泛的“负载”。一些“负载”相当不拘一格 - 例如 RTT 对主机的地址排序，有些是实用的 - 例如在一系列主机之间平均平衡 CPU 负载。所有这些都代表了他们自己的上下文中的有效关注点，并且为每个单独的 RR 类型的想法是不可想象的（主要是；它会违反目标 A）。
(F) 需要保证的几件事。主要是计算信息以排序寻址信息的时间不超过分发信息的 TTL - 即 TTL 为 5 分钟的元素不需要 6 分钟来计算。相似地;在 DNS RFC 中似乎有一个相当明确的目标，即客户端不应一直等待——无论发生任何其他处理的状态如何，请求处理都应继续进行。
3、 可能的替代方案
在与 DNS 工作组和负载均衡委员会的各种讨论中，有人指出，没有任何现有的解决方案能够适当地处理所有愿望。DNS 的主要成功之一是它的灵活性——人们认为这需要在所有方面都得到保留。人们认为，也许不仅地址信息需要快速更改，其他记录也可能需要快速更改（至少不能排除这一点——谁知道未来会出现什么技术）。
许多人最关心的是与旧的 DNS 实现交互的能力。DNS 现在已广泛实施，对协议关键部分的更改可能会造成多年的破坏。通过与 Jon Postel 和 Dave Crocker（区域主管）的交谈，很快就发现对协议的修改将被模糊地看待。
4、 灵活的模式
在数小时的讨论中，根据 Rob Austein 的建议，可以在不更改协议的情况下实施更改；如果区域转移行为可以被微妙地改变，那么区域转移过程可以适应各种RR信息的变化。需要的是一个更智能的程序来进行区域传输。根据这一点，对 BIND 进行了更改，以允许程序规范为特定区域进行区域传输。
没有规定辅助服务器必须以任何特定方式从其主服务器接收更新 - 只是它需要定期检查，并在进行更改时获取新的区域副本。可以想象，区域传输代理可以从任意数量的来源（例如，负载均衡守护程序、循环排序器）获取信息，并将信息返回给域名服务器以进行分发。
其次，但可能更微妙的是，出现了一个问题，即主域名服务器不使用区域传输，而只使用辅助域名服务器。为了澄清这一点，必须处理“快速”或“不稳定”分区的概念。在易失性环境中（地址或其他RR顺序快速变化），区域的刷新率必须设置得非常低修改dns有什么用，分发的RRs的TTL也必须非常低。当订购RRs的条件每分钟发生变化时，以一小时的TTL发送信息是没有用的。信息的刷新率和TTL之间必须有相对密切的关系。当然，在刷新率非常低的情况下，主服务器和辅助服务器之间的区域传输必须频繁发生。考虑到主域名服务器和辅助域名服务器在拓扑和地理位置上应该相距很远，迁移如此多的数据通常被视为是禁止的。而且主服务器和辅助服务器之间的传播时间越长，环境变化的窗口就越大，从而使辅助服务器的信息无效。一般认为，将不稳定的信息传递给二级系统是相当无用的——如果二级系统需要准确的信息，那么他们应该自己计算，而不是通过区域传输获得。这避免了二级数据库与一级数据库失去联系的问题（但仍然可以访问易失性域的目标），但二级数据库的信息越来越陈旧。
基本上需要的是一个辅助（没有主）系统，它可以为自己计算RR数据的必要顺序（这也避免了不同版本的域服务器以不同的预测方式对RR信息进行预测性排序的问题）。对于易失性区域，没有主DNS代理，而是一系列自主的辅助代理。当然，每个自主二级代理都能够计算挥发性RRs本身的顺序或内容。
5、 实施
在 Masataka Ohta（东京工业大学）的帮助下，我们对 BIND 进行了修改，以允许为特定域指定区域传输程序（区域传输代理）：
transferbr
目前我们定义了一个单独的子域，其中定义了一些主机 - 所有的易失性信息。该区域的刷新率为 300，指示的最小 TTL 为 300。配置文件表示为“volatile.hosts”。每 300 秒运行一个程序“doAxfer”来进行区域传输。程序“doAxfer”读取文件“volatile.hosts.template”和文件“volatile.hosts.list”。volatile.hosts.list 中指定的地址会随机旋转多次，然后（按顺序）代入 volatile.hosts.template 以生成文件 volatile.hosts。程序“doAxfer”然后以值 1 退出 - 向域名服务器指示区域传输成功修改dns有什么用，并且应该读入文件，并分发信息。这导致主机具有多个地址，并且地址每五分钟（300 秒）随机分配一次。
在这项工作中，两个错误继续困扰着我们。BIND 目前认为任何低于 300 秒的 TTL 都是“不合理的”，并代之以 300 的值。这极大地妨碍了易失区的功能。在所有情况中最快的情况下 - 0 TTL - 信息将被使用一次，然后被丢弃。大概每 5 秒计算一次新的 RR 信息，发出的 RR 的 TTL 为 0。必须考虑到区域速度的一个限制将是机器快速计算新信息的能力足够的。
另一个影响这一点的错误是，与 TTL 一样，BIND 认为 15 分钟以下的任何区域刷新率同样不合理。显然 15 分钟的区域刷新率对于此类应用程序是不可接受的。
作为一种变通方法，当前代码将这些相同的硬编码值设置为 60 秒。60 秒仍然足够大，可以避免与小计时器值相关的任何残留错误，但也足够短以允许使用快速子区域。
此版本的 BIND 目前在罗格斯大学内发布，在“快速”和正常区域运行。
6、 性能
虽然快速区域的性能并不十分出色，但它并不比 BIND 引起的正常 CPU 负载高多少。测试是在用作普通工作站的 Sun Sparc-2 上进行的，但没有解析器在使用域名服务器 - 本质上，域名服务器是空闲的。对于没有快速子区域的配置，BIND 在 24 小时内累积了 11 个 CPU 秒。对于具有一个快速区域、六个地址记录并每 300 秒（5 分钟）刷新一次的配置，BIND 累积了 1 分 4 秒的 CPU 时间。对于相同的先前配置，但每 60 秒刷新一次，BIND 累积了 5 分 38 秒的 CPU 时间。
毫不奇怪，服务机器上的 CPU 负载与刷新时间的频率成线性关系。60 秒刷新配置使用的 CPU 时间大约是 300 秒刷新配置的五倍。可以很容易地推断出总体 CPU 利用率与区域数量和刷新周期的频率呈线性关系。所有这一切都基于始终指示需要进行区域更新的 shell 脚本，更智能的程序应该意识到何时不需要对 RR 进行重新排序，并避免这种周期性的区域重新加载。
7、 致谢
本文档中的大部分想法都是来自许多人的对话和建议的结果 - 包括但不限于 Robert Austein、Stuart Vance、Masataka Ohta、Marshall Rose 和 IETF DNS 工作组的成员。
8、 参考文献
RFC1794：DNS Support for Load Balancing，April 1995
9、 安全考虑
本备忘录不讨论安全问题。
长按二维码
版权声明
本文仅代表作者观点。
本文系作者授权发表，未经许可，不得转载。
发表评论