我对我的网站的故障转移高可用性有一个想法，但我不确定这本身是好是坏还是一场灾难。
我的主服务器托管一个 ASP.net 网站，该网站使用另一台服务器上的 SQL 服务器数据库。
两台服务器都运行镜像 raid 驱动器、两张网卡、两台交换机等。提供商保证 99.999% 的正常运行时间，但确实出现了问题，他们花了将近一天的时间才解决。
我更关心诸如域名/dns 问题之类的问题，这些问题超出了我们的直接控制范围，可能需要 6-24 小时才能传播。
或者就此而言，大规模的灾难可能会摧毁我们的主要数据中心、电力线、网络连接基础设施、域名劫持以及食人亡灵的崛起；）等等。
所以我的想法如下：在另一个国家的另一个提供商处托管第二个域名。将域名命名为与主站点名称类似的名称。
为网站配备一台服务器，为 SQL db 配备一台服务器，托管在该二级提供商。Web 服务器的设置和配置与主网站完全相同。
我的主 SQL 服务器每 5 分钟镜像一次（使用高性能镜像）到辅助提供商的辅助服务器。
假设由于某些重大而严重的事件发生，导致主站点无法访问。
将 DNS 更改为指向备份域，并在 Twitter、Facebook 等平台上发布消息，让需要我的网站的任何人都可以使用 www.backupdomain.com，直到 DNS 更新在整个网络上传播。
这有效吗？有没有更好的选择来处理这样的问题？
我所做的大部分研究都指向故障转移群集、负载平衡、重复硬件、镜像等，我确实意识到这些会使本地托管变得冗余，但我该如何处理更大范围的中断。
预算也有限，所以我们无法花费数百万美元购买超级 Google 永不死机系统。但如果能处理非常严重的中断并且停机时间仅为 30 分钟到 1 小时，那就完美了。
欢迎提示、建议和链接。
答案1
您所描述的选项并不坏——事实上它们是好的，而且您正在考虑这一点，这说明您很优秀。
您当然可以实现上面描述的内容，或者使用云提供商作为（便宜得多的）备份站点，就像下面 ksm 建议的那样，但我首先要解决一些更基本的问题。
以下是我的工作粗略顺序：
确保您的托管服务提供商
至少拥有充足的冗余电源、管道和冷却系统。确保您的环境设计良好。
确保您的环境具有冗余性（所有关键组件的本地镜像、HA/故障转移）。
如果您的提供商很好，您的设计很好，并且一切都是冗余的，可以处理至少一个组件故障，那么您已经处理了大部分中断。您可能还赋予了自己执行以下任务的能力：并发维护如果你的#2 设计很好。确保你有备份。确保你可以恢复它们并恢复正常工作的系统。
测试数字 3 和 4（像混沌猴子一样思考并模拟失败）
1-4 已完成并扎实，现在考虑如何将其复制到远程位置，以防流星撞击提供商的建筑物。
如果上述 2-4 完成良好，这一部分应该有明显的、相对简单的实施路径。使用第 6 点中实现的方法对故障转移/恢复进行彻底测试。VMWare
实验室在这里非常有用。
请注意，我没有讲到细节——您的环境将决定您如何执行上述每个步骤。
答案2
你为什么不直接在 AWS 上获取一个实例？在E2C，在那里托管您的应用程序，然后让他们担心正常运行时间。
为了更加确定，您可以在不同的地区拥有两个实例（第二个实例可能作为热备份）：一个在其美国 DC 上，另一个在其亚洲 DC 上。