![了解基于 DNS 的故障转移系统的名称服务器方面](https://linux22.com/image/702898/%E4%BA%86%E8%A7%A3%E5%9F%BA%E4%BA%8E%20DNS%20%E7%9A%84%E6%95%85%E9%9A%9C%E8%BD%AC%E7%A7%BB%E7%B3%BB%E7%BB%9F%E7%9A%84%E5%90%8D%E7%A7%B0%E6%9C%8D%E5%8A%A1%E5%99%A8%E6%96%B9%E9%9D%A2.png)
作为我参与的一个项目的一部分,系统需要尽可能接近 99.999% 的正常运行时间(该系统涉及医疗保健)。我正在研究的解决方案涉及多个站点,这些站点又有自己的负载平衡器和多个内部服务器,以及自己的复制数据库,该数据库与其他每个站点同步。所有这些的前面是一个基于 DNS 的故障转移系统,如果某个站点发生故障(或手动关闭以进行维护),该系统会重定向流量。
然而,我所苦苦挣扎的是 DNS 方面如何在不防止单点故障的情况下发挥作用。我见过关于浮动 IP(代表故障点)的讨论,各种托管服务,如 DNSMadeEasy(在免费试用期间不提供全面测试其故障转移过程的能力,因此我无法验证它是否适合该项目)等等,并且一直在尝试一些简单的解决方案,例如为域名分配多个 A 记录(我知道这远远不够,因为不同的浏览器与这种设置的交互方式存在差异)。
对于更强大的基于 DNS 的方法,您是否只是为域上的每个位置规定一个名称服务器,在每个位置运行一个名称服务器,并在检测到另一个站点发生故障时定期更新每个名称服务器的独立记录(使用在每个名称服务器上运行的脚本检查所有其他站点)?如果是这样,是否仍然存在与定期更改的 A 记录相同的问题(浏览器不更新到新记录,或忽略非常低的 TTL)?
我已经阅读这个主题好几天了(包括这里的许多问答),但感觉我错过了这个难题的一个基本部分。
提前致谢!
答案1
基于更新 DNS 信息的故障转移系统不足以实现 99.999% 的可用性。
一般情况下可以信赖的最低 DNS TTL 是 300 秒。一年的 0.001% 是 315 秒。因此,基于 DNS 的系统每年最多可以发生一次故障转移,否则将超过 5 个 9。DNS 基础设施的构建程度并不重要,因为这是基于 DNS 客户端的一般行为的限制,您无法更改。
我建议您开始考虑在 IP 地址级别构建弹性,通过任播或类似方法(这不是我的专业领域,因此我无法提供详细建议)。当然,您仍然需要一个良好的 DNS 基础设施,但对于大部分静态 DNS 数据,只需从信誉良好的 DNS 服务提供商处购买标准服务就足够了。