4 domain-name-system failover redundancy
我正在构建一个网络应用程序，其中正常运行时间是关键。我知道 100% 正常运行时间是不现实的，但我想达到 5 个 9。我不确定实现这一目标的最谨慎方法。
我的初步计划是让 Web 应用程序在两个地理上独立的数据中心运行。“主”数据中心将包含主服务器，这将复制到其他地方未使用的“从”服务器。如果主数据中心发生停机，DNS 故障转移会将流量转移到“从”服务器。这种技术存在一些挑战，包括由于奇怪的 DNS 记录缓存等原因，一些用户在一段时间内无法访问该站点。
但是，我已经阅读了很多意见，指出 DNS 故障转移不是一个好的解决方案，您应该将所有内容都保存在一个数据中心并专注于那里的冗余。我看到的问题是，即使是好的数据中心似乎也有奇怪的网络问题，可能会导致足够的停机时间来打破五个 9 的预期。
我应该使用 DNS 故障转移选项吗？有更好的选择吗？
Mad*_*ter 13
我对客户的经验法则是：免费获得两个 9（即，无需在高可用性方面花费任何费用）。每增加 9 个，总成本就会增加一个数量级。
也就是说，只需将您的应用程序放在公司 Internet 连接上的半体面服务器上，您就可以获得 99% 的正常运行时间。为了改善这一点，您可以并置。您可以使用负载平衡和快速故障转移进行共存。您可以使用负载平衡、快速故障转移和冷备用 DR 站点进行共存。您可以与负载平衡、热备用站点、PI 地址空间并置，运行您自己的 ASN 并安排 BGP 对等互连，以确保您的地址空间始终可全局路由。您可以研究高可用性硬件，其中包括内存和 CPU 在内的一切都可以停顿和热插拔。如果您的应用程序支持它，您可以运行完全分布式托管，或外包给高度可用的内容供应网络。您可以而且将会需要五倍的员工来管理所有这一切 24*365，
你可以做很多聪明的事情。但这都是有代价的，而且其中大部分都要花费非常大的钱。
所以我真诚的建议是：计算出在公司办公室的单个服务器上托管应用程序的成本。如果你的雇主不愿意花一千倍的钱，那就忘了五九吧；这不现实。