高可用性与灾难恢复

术语高可用性和灾难恢复通常可以互换使用。但是，它们是两个截然不同的概念：

高可用性（HA）描述了应用程序抵御所有计划内和计划外中断的能力（计划中断可能正在执行系统升级）并为业务关键型应用程序提供连续处理。
灾难恢复（DR）涉及一系列策略，工具和过程，用于在灾难性中断后将系统，应用程序或整个数据中心返回到完全运行状态。它包括将已安装系统的基本数据复制和存储在安全位置，以及恢复该数据以恢复操作正常的过程。

高可用性是关于避免单点故障并确保应用程序将继续处理请求。灾难恢复是指在系统或应用程序遭受灾难性故障或整个数据中心可用性丧失后将系统或应用程序恢复到正常运行状态的策略和过程。

开发您的HADR解决方案

要为您的本地应用程序指导高可用性灾难恢复（HADR）解决方案的开发，您应该考虑业务挑战，功能要求和架构原则。

您的HADR解决方案面临的业务挑战

您的HADR解决方案应该解决这些挑战：

对于业务连续性，应用程序及其支持的业务流程应保持可用且无任何中断，尽管存在人为或自然灾害。它应无缝地服务于其预期的功能。
为了实现持续可用性，精心设计的HA解决方案可通过快速的系统响应时间和实时交易执行来保持最佳的客户体验。
该架构必须能够处理因业务交易激增而产生的额外工作量，并降低收入机会损失的风险。
为了提高操作灵活性，您应该拥有一个设计良好的HA拓扑，在辅助站点中复制代码和数据，并以足够的地理距离隔开。应用程序可以在另一个位置重新构建和/或激活，在主站点发生意外灾难性故障后处理工作。

HADR解决方案的功能要求

您应该考虑HADR解决方案的以下功能要求：

最大限度地减少应用程序正常操作的中断。如果任何应用程序组件存在可用性问题，请确保将应用程序组件平稳快速地恢复到正常操作。
恢复任何应用程序组件的服务必须完全自动化，或者必须由人员通过单一操作激活。
监视应用程序的每个应用程序组件的可用性。在服务级别问题的情况下发出警报，例如响应时间慢或任何应用程序组件没有响应。通过自动化或由负责应用程序高可用性的人工专家执行的单个操作激活快速恢复。

影响HADR解决方案的架构原则

可能导致软件应用程序无法处理用户或其他系统请求的事件可分为三类。每种方法都需要不同的技术来缓解。

涉及系统中仅一个组件意外故障的事件，例如操作系统进程，物理机器或连接系统成员的网络链接。
涉及系统许多组件同时发生意外故障的事件。这些事件可能由自然灾害，人为错误或两者的组合触发。
由人为错误引起的事件，涉及通过将不正确或不连贯的内容持久保存到主数据存储区的逻辑损坏。

示例：本地B2B订单应用程序

在此示例中，组织开发内部部署应用程序以处理来自其B2B客户的在线订单。 B2B订单应用程序使用多个组件提供特定服务，例如用户界面，产品目录，订单创建，工作流，决策和集成服务以及分析。 ERP应用程序存储产品数据，例如价格和库存以及订单。目录应用程序管理与产品相关的非结构化数据，例如图像。在线订单应用程序使用NoSQL数据库存储其产品目录和传统的RDBMS用于其分析和ERP后端应用程序。

这是内部部署订单应用程序中涉及的组件的高级说明。

HADR的数据中心拓扑选项

要实现高可用性，您可以从两个部署拓扑选项中选择 - 两个数据中心体系结构和三个数据中心体系结构。您可以在主数据中心和辅助数据中心的高可用性群集配置中以相同的方式设置B2B订单应用程序。

两个数据中心拓扑

您可以在活动 - 备用模式或主动 - 主动模式下配置两个数据中心拓扑。最简单的配置是活动 - 备用拓扑，其中辅助数据中心中的B2B订单应用程序处于冷备用模式。在主动 - 主动拓扑中，应用程序及其使用的服务在两个数据中心都处于活动状态。

三个数据中心拓扑

三个数据中心的配置有两种变体，主动 - 主动 - 主动和主动 - 主动 - 备用。在主动 - 主动 - 备用配置中，应用程序和服务在主数据中心和辅助数据中心处于活动模式，而应用程序在第三个数据中心处于待机模式。

灾难恢复方案

当灾难发生时，您所做的拓扑和配置选择将决定您的应用程序如何恢复。您需要了解与每个相关的成本和收益，以确定满足您需求的最佳成本和收益。

使用两个数据中心拓扑进行灾难恢复

主动 - 主动或主动 - 备用是此方案的两种可能配置。在这两种情况下，您必须在两个数据中心之间连续复制数据。

主动 - 主动配置

与主用 - 备用配置相比，此配置提供了更高的可用性，最少的人为参与。两个数据中心都提供请求。您应该使用适当的超时配置边缘服务（负载平衡器）并重试逻辑，以便在第一个数据中心环境中发生故障时自动将请求路由到第二个数据中心。

此配置的好处是减少恢复时间目标（RTO）和恢复点目标（RPO）。对于RPO要求，两个活动数据中心之间的数据同步必须非常及时，以允许无缝请求流。

主动 - 备用配置

请求从活动站点提供。在发生中断或应用程序故障的情况下，执行预应用程序工作以使备用数据中心准备好为请求提供服务。从活动数据中心切换到备用数据中心是一项耗时的操作。与主动 - 主动配置相比，恢复时间目标（RTO）和恢复点目标（RPO）都更高。

备用数据中心可以是热备用环境，也可以是冷备用环境。在热备用选项中，订单应用程序和相关服务部署到两个数据中心，但负载均衡器仅将流量定向到活动数据中心中的应用程序。此配置的好处是，当活动数据中心遇到灾难时，可以激活热备用数据中心。 DR过程仅需要重新配置负载平衡器以将流量重定向到新激活的数据中心。热备用的缺点是第二个数据中心保持活动状态，应用程序保持最新，但不用于处理客户请求。软件许可证适用于两个数据中心，但只有一个正在使用中。

在冷备用选项中，订单应用程序和相关服务部署到两个数据中心，但不在备用数据中心中启动。如果活动数据中心遇到灾难，则DR过程包括启动应用程序和服务，以及重新配置负载平衡器以重定向流量。就软件许可证成本和数据中心运营成本（包括人员）而言，此选项具有成本效益。但是，应用程序可用性可能会受到影响，具体取决于冷备用数据中心和订单应用程序启动和激活以处理请求的速度。

在中断后恢复主数据中心中的应用程序时，您可以修改边缘服务DNS以将用户请求路由到主数据中心中的现在活动的应用程序。辅助数据中心中的应用程序可以切换回待机模式。

使用三个数据中心拓扑进行灾难恢复

在这个Always On服务时代，对停机时间零容忍，客户希望每个商业服务都能在世界任何地方随时随地访问。对企业而言，一种经济高效的策略包括构建基础架构以实现持续可用性，而不是构建灾难恢复基础架构。

三个数据中心拓扑比两个数据中心提供更高的弹性和可用性。它可以通过在数据中心内更均匀地分布负载来提供更好的性能。如果企业只有两个数据中心，则可以在一个数据中心部署两个应用程序，在第二个数据中心部署第三个应用程序。或者，您可以在3活动拓扑中部署业务逻辑和表示层，并在2活动拓扑中部署数据层。

此方案考虑了两种可能的配置，即主动 - 主动 - 主动（3主动）和主动 - 主动 - 备用配置。在这两种情况下，数据中心之间都需要连续复制数据。

主动 - 主动 - 主动（3主动）配置

请求由在三个活动数据中心中的任何一个中运行的应用程序提供。 IBM.com网站上的一个案例研究表明，3-active只需要每个群集50％的计算，内存和网络容量，但2-active需要每个群集100％。数据层是成本差异突出的地方。有关更多详细信息，请阅读“始终开启：评估，设计，实施和管理连续可用性”。