摘要：许多管理自己的基础架构的组织都尝试通过使用配置为故障转移集群的多台服务器或虚拟机(VM)来创建高可用性(HA)应用程序环境，在该环境中应用程序的访问率不少于99.99%。例如，如果运行关键任务应用程序的集群节点出现故障，故障转移集群中的辅助节点可以立即接管并从其他节点停止的地方继续工作。

通过正确的策略和架构，可以在云中运行关键任务应用程序。
　　
　　许多管理自己的基础架构的组织都尝试通过使用配置为故障转移集群的多台服务器或虚拟机(VM)来创建高可用性(HA)应用程序环境，在该环境中应用程序的访问率不少于99.99%。例如，如果运行关键任务应用程序的集群节点出现故障，故障转移集群中的辅助节点可以立即接管并从其他节点停止的地方继续工作。
　　
　　这种故障转移集群通常依赖存储区域网络(SAN)来进行共享数据存储。但共享SAN本身会构成单点故障，可能会影响高可用性。如果SAN出现故障，支持您的关键任务系统的SQLServer或Oracle数据库将不可用，并且故障转移集群中有多少节点可能准备与之交互都无关紧要。
　　
　　对于考虑将云用于高可用性(HA)应用程序环境的组织，还有一个更紧迫的问题：虽然一些云供应商确实提供了共享存储选项，但并非所有选项都能保证99.99%的可用性。
　　
　　这是否意味着您需要放弃将云作为高可用性(HA)应用程序环境的选项？否：这只是意味着您需要重新考虑如何配置故障转移集群。
　　
　　了解云中的高可用性
　　
　　关于云，首先要了解的是，启动和配置新的虚拟机非常容易。事实上，Azure、AWS和Google都可以轻松创建由在不同数据中心运行的多个虚拟机组成的高可用性集群——也称为区域或可用性区域。通过在多个区域中配置虚拟机，您可以消除区域范围的灾难可能导致您所有关键基础设施瘫痪的风险。
　　
　　但是，如果阅读主要云提供商的服务水平协议(SLA)，您会注意到一个关键警告：如果您使用多个区域中的虚拟机配置高可用性(HA)集群，则服务水平协议(SLA)保证您至少能够访问至少99.99%的时间是这些节点之一。它不能保证您的应用程序可以运行，只保证您可以访问其中一个虚拟机。
　　
　　这是一个关键的区别，可以追溯到SAN的问题：如果您的应用程序无法访问您的数据，那么您可以访问多少虚拟机并不重要。
　　
　　共享数据，而不是存储
　　
　　这让我们回到了重新思考如何在云中配置故障转移集群的问题。
　　
　　如果您希望基于云的故障转移集群中的任何虚拟机(VM)能够在发生故障时接管您的生产工作负载（这就是您开始部署HA解决方案的原因），需要将每个虚拟机(VM)配置为您的故障转移集群拥有自己的存储。此外，需要一种将活动集群节点上存储中的数据主动复制到辅助节点的机制。这样，如果活动虚拟机因任何原因离线，集群可以故障转移到辅助虚拟机，该虚拟机拥有使您的应用程序在几秒钟内恢复在线所需的所有数据。
　　
　　有多种数据复制解决方案可以提供您的组织所需的服务，以确保在基于云的部署中实现真正的应用程序高可用性。寻找同步的、块级的复制服务来启动。同步服务将确保在事务被认为完成之前，写入主系统上存储的任何事务也将写入辅助系统上的存储。块级复制服务也很重要，因为它们将确保写入主存储的任何数据都将复制到辅助存储。如果您的主要云基础架构支持多个应用程序，或者您将该存储用作多个应用程序的存储库，则所有这些数据（不仅仅是与您的Oracle或SQLServer数据库关联的数据）都将被复制到辅助基础架构中，如果二级基础设施意外投入使用，任何应用程序或用户都可以使用。
　　
　　编辑：Harris