如何确保应用程序在公共云中的可用性

采用云计算的注意事项是一种很好的建议。云计算服务提供商(CSP)都会承诺在其基础设施中提供“高可用性”，其服务水平协议(SLA)通常提供95%至99.99%的正常运行时间，而每月服务费退款率将达到10%到50%不等。但通常没有达到这样的门槛，正如IT的许多方面一样，重要的在于细节。

而采用正确的方法，在Amazon Web Services、谷歌云平台和微软Azure公共云和混合云环境中可以实现5个9的高可用性(HA)。这需要了解服务等级协议(SLA)中的限制，以及创建高可用配置的选项。

高可用性限制

大多数云计算服务提供商都提供具有99.99%正常运行时间保证的服务等级协议(SLA)，而跨越云计算服务提供商(CSP)区域和/或区域的冗余配置增加了企业获得满意可用性的信心。但是这种安排存在一些严重问题，因为服务等级协议(SLA)中“停机时间”和“不可用”是导致应用程序失败的原因。

不计入停机的潜在原因包括客户的软件，任何第三方软件或技术，计划的硬件和软件维护，以及个别实例或卷的某些问题，这些问题不能归因于某些不可用的情况。还排除了错误的输入或指令，或在需要时缺乏行动，这似乎涵盖了“人为错误”可能的原因。

云计算服务提供商(CSP)排除某些失败原因是合理的，但系统管理员将这些作为借口是不负责任的。这使得有必要通过其他方式确保应用程序的更高可用性。

实现更高可靠性的选项

通常，有三种基本选项可用于提高云计算的可用性：应用程序软件中的规定，操作系统中内置的功能，以及专用的故障转移集群。

许多应用程序提供自己的高可用性(HA)规定。一个很好的例子是Microsoft SQL Server企业版中的运营商级在可用性组上始终使用的功能。这种方法的问题在于需要针对不同的应用程序提供不同的高可用性(HA)规定，这使得持续管理成为一项持续且成本高昂的工作。

第二个选项涉及使用集成到操作系统中的高可用性(HA)功能。 Windows Server具有故障转移集群的本机功能，但其缺乏数据复制功能。私有云中的复制通常通过某种形式的共享存储提供，例如存储区域网络(SAN)。但是，在公共云中，共享存储不可用，因此需要单独的数据复制解决方案。

在Linux操作系统上，由于缺少像故障转移集群这样的本机功能，因此需要单独的高可用性(HA)规定。因此，实施高可用性(HA)需要使用像Pacemaker和Corosync这样的开源软件为每个应用程序创建(然后维护)自定义脚本，并且只有规模非常大的组织才有能力承担所涉及的巨大而持续努力。

第三种选择是采用第三方故障转移集群软件，这是专门用于为公共云、私有云和混合云上的Windows操作系统或Linux操作系统上运行的应用程序提供完整的高可用性和灾难恢复解决方案。

这些解决方案至少结合了数据复制、连续应用程序级监控、可配置的故障转移/故障恢复恢复策略。这种集成使软件能够检测应用程序级别的任何和所有停机时间，无论其原因如何，其中包括各种云计算服务等级协议(SLA)未涵盖的原因。许多解决方案还提供高级功能，例如支持WAN优化以提高性能，以及人工切换主服务器和辅助服务器分配以促进计划维护。

虽然这些解决方案可以在私有云中与SAN配合使用，但大多数管理员更喜欢部署无共享SANless故障转移群集。其原因包括：消除潜在的单点故障、获得在公共云中工作的能力、并最小化恢复点对象(RPO)、恢复时间对象(RTO)和最短恢复时间(MTTR)。