当公共云服务级别不足时的选项
所有公共云服务提供商都提供某种形式的可用性保证。 这些可能或不足，取决于每个应用程序的正常运行时间要求。这些保证通常在本月的正常运行时间范围内为95.00％至99.99％。大多数人对服务提供商施加某种类型的“惩罚”，以达不到这些阈值。通常，大多数云服务提供商提供99.00％的正常运行时间阈值。这相当于每月约7小时的停机时间。对于许多应用程序来说，那些两个9可能就足够了。但对于任务关键型应用程序，需要更多9个。特别是考虑到许多常见的停机原因被排除在担保之外。当然，在使用公共云服务的配置中，无论是专有还是作为混合安排的一部分，都可以采用经济高效的方式实现5-9的高可用性和强大的灾难恢复保护。本文重点介绍了公共云中涉及HA和DR规定的限制。它探讨了克服这些限制的三种选择，并描述了故障转移群集的两种常见配置。
在云中注意Emptor
虽然所有云服务提供商（CSP）在某种程度上不同地定义“停机时间”或“不可用”，但这些定义仅包括应用程序级别的所有可能的故障原因的有限集合。通常包括影响区域或区域的故障，或外部连接。所有CSP还提供从10％未满足4到9的正常运行时间到25％左右的信用额度，因为它们未能满足2到9的正常运行时间。可以将冗余资源配置为跨越CSP基础架构内的区域和/或区域。 它将有助于提高应用程序级别的可用性。但即使有这样的冗余，仍然存在一些限制，这些限制对于任务关键型应用程序来说通常是不可接受的。特别是那些需要高事务吞吐量性能的。这些限制包括每个主服务器只能创建一个故障转移副本。它需要使用主数据集进行备份，并使用事件日志来复制数据。这些和其他限制可能会增加故障期间的恢复时间，并且必须至少安排一些计划停机时间。
重大限制
更重要的限制涉及许多排除什么构成停机时间。以下是实际公共云服务级别协议中的一些示例，其中包含导致应用程序级故障导致的“停机时间”或“不可用性”的内容：
- 超出CSP合理控制的因素（换句话说，一些经常发生的事情，例如运营商网络中断和自然灾害）
- 客户的软件或第三方软件或技术，包括应用程序软件
- 错误的输入或指令，或者在需要时没有采取任何行动（换句话说，人为错误造成的不可避免的错误）
- 单个实例或卷的问题不归因于“不可用”的具体情况
- 根据协议规定的任何硬件或软件维护
可以肯定的是，CSP排除某些失败原因是合理的。但是系统管理员以这些为借口是不负责任的。有必要通过其他方式确保应用程序级别的可用性。
哪些公共云服务级别可用？
以不牺牲安全性或性能的方式为高可用性供应资源从未是一项微不足道的努力。在私有云和公共云基础架构可能存在显着差异的混合云环境中，挑战尤其困难。它使配置难以测试和维护。此外，它可能导致故障转移条款在实际需要时失败。对于CSP提供的服务级别不足的应用程序，可根据应用程序本身，操作系统中的功能或使用专用的故障转移群集软件提供三个附加选项。
提高应用程序级可用性的三个选项
HA / DR
可能看起来最容易实现的HA / DR选项是专为每个应用程序设计的选项。一个很好的例子是Microsoft的SQL Server数据库及其运营商级Always On Availability Groups功能。然而，这种方法有两个缺点。在这种情况下，企业版的许可费用较高，可能会使许多需求成本过高。更令人不安的缺点是需要针对不同的应用程序提供不同的HA / DR规定，这使得持续管理成为一个持续（和昂贵）的斗争。
与运行时相关的功能集成到操作系统中
提高公共云服务级别的第二个选项涉及使用集成到操作系统中的与正常运行时间相关的功能。例如，Windows Server Failover Clustering是一个功能强大且经过验证的功能，内置于操作系统中。但就其本身而言，WSFC可能无法提供完整的HA / DR解决方案，因为它缺乏数据复制功能。在私有云中，可以使用某种形式的共享存储（例如存储区域网络）来提供数据复制。但由于共享存储在公共云中不可用，因此实施强大的数据复制需要使用单独的商业或定制开发的软件。对于缺乏WSFC等功能的Linux，需要额外的HA / DR规定和/或定制开发。使用像Pacemaker和Corosync这样的开源软件需要为每个应用程序创建（和测试）自定义脚本。在对所使用的任何软件或硬件进行微小更改后，通常需要更新和重新测试这些脚本。但是因为让完整的HA堆栈适用于每个应用程序都非常困难，只有非常大的组织才有必要的资金来考虑承担这些工作。
专用故障转移群集
理想情况下，HA / DR将采用“通用”方法，能够经济高效地在公共，私有云和混合云上运行在Windows或Linux上的所有应用程序。这种解决方案中功能最多，价格最实惠的是第三种选择：专用故障转移集群。这些HA / DR解决方案完全由软件实现，专门用于创建虚拟或物理服务器和数据存储集群，从活动或主要实例到备用数据库的故障转移，以确保应用程序的高可用性水平。
这些解决方案的好处
这些解决方案至少提供了实时数据复制，连续应用程序监控和可配置故障转移/故障恢复恢复策略的组合。一些更强大的功能提供了额外的高级功能，例如选择块级同步或异步复制，在较便宜的SQL Server标准版中支持故障转移群集实例（FCI），WAN优化以提高性能和最小带宽利用率和主服务器和辅助服务器分配的手动切换，以便于计划维护。虽然这些通用解决方案通常与存储无关，使它们能够与存储区域网络协同工作，但通常优先选择无共享SANless故障转移群集，因为它们能够消除潜在的单点故障。
两种常见的故障转移群集配置
每个故障转移群集都包含两个或更多节点。找到不同数据中心中的至少一个节点对于防止本地灾难是必要的。这里介绍两种流行的配置：一种用于灾难恢复;另一个用于提供关键任务高可用性和灾难恢复。高事务性能通常是高可用性配置的要求。示例应用程序是一个数据库。用于灾难恢复的基本SANless故障转移群集具有两个节点，其中一个主节点和一个辅助或备用服务器或服务器实例。此最小配置还需要第三个节点或实例作为见证，这是实现确定主要分配的法定数量所必需的。对于数据库应用程序，通过WAN复制到备用实例是异步的，以便在主实例中保持高性能。SANless故障转移群集可在主服务器发生故障时快速恢复。导致适用于许多应用程序的基本DR配置。它能够检测几乎所有可能的故障，包括那些未计入公共云服务中的停机时间的故障。因此，它将在私有云，公共云或混合云环境中工作。例如，主服务器可以位于企业数据中心，辅助服务器部署在公共云中。因为公共云实例仅在主计划的计划维护期间或在其失败的情况下才需要 – 可以相当快速地补救 – 上面提到的服务限制和排除对于除了最关键任务之外的所有人都可以接受申请。
三节点SANless故障转移群集
复苏
服务器＃1发生故障后，IT人员会立即开始诊断并修复导致问题的任何问题。一旦修复，服务器＃1可以作为主服务器恢复，并进行手动故障恢复，或者服务器＃2可以继续作为服务器＃1和服务器＃3的主要复制数据。如果服务器＃2在服务器＃1恢复运行之前失败，如图所示，服务器＃3将成为主服务器。由于服务器＃3跨越公共云中的WAN，因此数据复制是异步的，故障转移是手动的，以防止“复制延迟”导致丢失任何数据。SANless故障转移群集软件能够在应用程序级别检测所有可能的故障。它很容易克服上面提到的CSP限制和排除。因此，它使这个三节点配置可以完全部署在公共云中。为了提供基于即时和自动故障转移的相同的5 -9高可用性，服务器＃1和＃2需要位于LAN促进同步复制的单个区域或区域内。为了实现适当的DR保护，服务器＃3应位于不同的数据中心或区域，对于需要高事务吞吐量的应用程序，需要使用异步复制和手动故障转移/故障恢复。三节点集群还可以促进所有三台服务器的计划硬件和软件维护。同时，继续为应用程序及其数据提供连续的DR保护。通过提供多个地理位置分散的数据中心，公共云提供了大量机会来提高可用性并增强灾难恢复条款。SANless故障转移群集软件可有效，高效地使用所有计算，存储和网络资源。它也易于实施和操作。这些专用解决方案可最大限度地降低所有资本和运营支出。最后，导致高可用性比以前更强大，更实惠。###
关于作者
Cassius Rhue是SIOS Technology的工程总监。 他领导位于南卡罗来纳州列克星敦的软件产品开发和工程团队。Cassius拥有超过17年的软件工程，开发和测试经验。他还拥有南卡罗来纳大学的计算机工程学士学位。