采用云计算的注意事项是一种很好的建议。云计算服务提供商(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)。
5个9的故障转移集群配置
上图显示了一个三节点SANless故障转移集群，可在混合云中提供5个9的高可用性以及强大的灾难恢复保护。该应用程序是一个使用SQL Server标准版中的故障转移集群实例(FCI)的数据库。SQL1和SQL2位于公共云中具有SQL3的企业数据中心。在数据中心内，跨LAN的数据复制是同步的，以大限度地缩短完成故障转移所需的时间，从而大限度地提高可用性。
这个三节点SANless故障转移集群能够以最小的停机时间和无数据丢失处理两个并发故障。
在这个示例中，SQL1最初是主要活动实例，它将数据连续复制到SQL2和SQL3。如果SQL1失败，应用程序将自动将故障转移到SQL2，然后SQL2将成为SQL3的主要复制数据。
一旦问题得到解决，SQL1可以恢复成主要节点，或者SQL2可以继续在该容量中将数据复制到SQL1和SQL3。如果SQL2在SQL1返回操作之前失败，SQL3将成为主要的节点。此外建议使用人工故障转移，以防止由于到公共云的WAN链路中固有的较高延迟而导致数据丢失。
像这样的三节点集群还有助于为所有三台服务器进行计划的硬件和软件维护，同时为应用程序及其数据提供持续的灾难恢复保护。通过易于实施和操作的方式有效和高效地使用所有资源，故障转移集群软件使得5个9的高可用性更加经济实惠，其中包括混合云。
相关阅读
热门专题
