作为项目的一部分，系统需要尽可能接近99.999％的正常运行时间（系统涉及医疗保健）。 我正在研究的解决scheme涉及具有多个站点，这些站点又具有自己的负载均衡器和多个内部服务器，以及与每个其他站点同步的自己的复制数据库。 所有这一切都面临着一个基于DNS的故障切换系统，如果网站出现故障（或者手动停机维护），则会redirectstream量。
然而，我正在努力的是如何DNS方面的function，而不会阻止单点故障。 我已经看到了浮动IP（performance出这种故障点）的说法，各种pipe理服务（如DNSMadeEasy）（它们不提供在免费试用期间全面testing它们的故障转移过程的能力，所以我无法validation它是否对于这个项目是否适用）以及更多，而且一直在玩弄简单的解决scheme，例如为一个域名分配多个Alogging（由于不同浏览器如何与这样的设置进行交互，我知道这个logging差得很远） 。
对于一个更强大的基于DNS的方法，你是否简单地为域上的每个位置规定一个名称服务器，在每个位置运行一个名称服务器，并且在另一个站点检测到失败时定期更新每个名称服务器的独立logging（使用在每个名称服务器上运行的脚本检查所有其他网站）？ 如果是这样，是不是仍然存在与定期更改的Alogging（浏览器没有更新到新logging，或忽略非常低的TTL）相同的问题？
以下是我对系统工作的理解。
我一直在阅读这个主题已经有好几天了（包括很多Q＆A在这里），但是我觉得我错过了一个基本的难题。
提前致谢！
基于DNS更新信息的故障转移系统对于五个九的可用性是不够的。
通常可以依赖的最低DNS TTL是300秒。 一年的0.001％是315秒。 因此，一个基于DNS的系统每年最多可以有一次故障切换，然后再打破五个九。 无论您如何构build您的DNS基础架构，都无所谓，因为这是基于DNS客户端的一般行为的限制，您无法更改。
我build议你开始考虑通过任播或类似的东西（不是我的专业领域，所以我不能在那里提供详细的build议）在IP地址级别build立韧性。 当然，你仍然需要一个很好的DNS基础设施，但是基本上静态的DNS数据只要从一个有信誉的DNS服务提供商那里购买标准服务就足够了。