我们有一个托管在内部 Windows VM 上的 Web 应用程序。我们公司在全国各地设有多个基地，每个基地都有自己的服务器机架，基地 LAN 在一个大型内联网中连接在一起。
目前，此应用程序托管在总部的服务器上，但今天停电了。电力公司几周前安排了停电，并通过从门下塞一张纸通知我们。但该国正处于 Covid19 封锁状态，因此 IT 承包商在停电开始前约一小时就知道了。我（此应用程序的首席开发人员）第一次听说这件事是在停电一小时后，当时 UPS 还剩一小时的运行时间。承包商设法将虚拟机故障转移到另一个基地的另一台服务器（该服务器无论如何都会进行备份，因此在电池没电之前触发另一个快照并启动另一个基地的虚拟机相对简单）。
无论如何，虽然我很高兴他们能够如此快速地传输它（包括以某种方式面向互联网的主机名），但我们之前并没有真正这样做过，我也不指望它能起作用。
我的问题是，让两个应用程序实例在两个独立的服务器上运行，这两个服务器位于同一个内联网中，但有各自的独立互联网连接，并在主服务器发生故障时将主机名故障转移到备用服务器，最好的方法是什么？如果答案是反向代理，我们把它放在哪里？因为这是一个新的单点故障，不是吗？它必须处理任何一台服务器及其整个基地都瘫痪的可能性，就像我们今天发生的情况一样。
保持主/备用数据库同步是一个很容易解决的问题，我们的员工可以做到这一点。
如果你们都只想大喊“改为在 Azure 中托管”，那没问题，我也很想这么做。我还没有成功说服管理层这是个好主意。他们认为这是关于数据所有权的问题。更不用说他们使用的一堆第三方系统，以及同样机密的数据都托管在云中。
最后，我不是基础设施方面的专家，公司 IT 部门的负责人几个月前就离开了，IT 承包商与高可用性基础设施没有太多关系。我希望利用这次事件来获得一些真正的积极改进。
答案1
您需要根据组织需求定制业务连续性计划。这方面的总体范围远远超出了一个问题，实际上这应该为组织的所有规划提供参考，而不仅仅是 IT。
首先询问组织，您的应用程序服务水平可以容忍多少计划外停机时间。也许这个应用程序非常重要，目标是每年少于 60 分钟，正常运行时间为 99.98%。使用这些服务目标来指导高可用性设计。
审查计划外停机事件并确定每个事件的根本原因。同时集思广益，找出尚未成为问题的合理威胁。这些就是您的风险。网络中断包括您的服务提供商、电源、恶意软件感染、硬件故障、软件故障、人为错误等。
以电力为例。这次险些发生的事故凸显了与电力公司沟通的重要性。为计划中的事件制定更完善的程序。或许可以制定一份包括 IT 承包商、电工和数据中心运营的电子邮件列表。
此外，发电机使得无需电网供电也能运行。提供安装发电机、拥有足够电池切换、维护加油合同以及定期测试启动的选项。或许可以添加具有自己的电网连接、电池、发电机和配电的辅助电源。虽然价格昂贵，但停机时间可能也很昂贵。
另一种有趣的断电模式：电气火灾。假设数据中心内有烟雾触发紧急断电。消防部门让您返回后，您是否有数据中心通电程序？需要多长时间？是否进行过测试？
主数据中心着火是能够在另一个站点运行该程序的一个很好的理由。您计划的切换能够对应用程序进行快照并获取最新状态。但是，如果主数据中心处于离线状态，该如何工作？是否有备份复制到其他位置，并且这些备份是否足够新可以使用？考虑到这还可能涉及备份、VM 主机、数据库、DNS 和其他组件的管理，是否可以在主数据中心处于离线状态的情况下完成迁移？
数据中心中断后很难恢复。您需要在发生中断之前将所有数据复制到异地，并且仍然能够控制一切。
一种设计是复制和隔离每个数据中心的整个基础架构：复制数据库、应用服务器、本地负载平衡器、单独的 VM 主机群集以及其他所有内容。切换通过 DNS 或 IP 路由更改完成。优点：隔离故障域，因为它们彼此之间的依赖性不强。缺点：需要维护单独的系统，切换可能是一个影响很大的过程，需要一段时间才能完成。
云不会从根本上改变业务连续性规划。只不过，你外包了物理数据中心。也许你还有一些额外的托管服务可供选择。
我还没有开始介绍可能的故障模式，更不用说可以帮助快速切换的高可用性技术了。继续规划、改进流程和测试。始终牢记组织对业务连续性的需求。