你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

什么是冗余、复制和备份?

我们经常将云视为全球分布式、无处不在的系统。 但是,实际上,云由数据中心内运行的硬件组成。 复原要求考虑与云托管组件运行的物理位置相关的一些风险。

本文提供了冗余、复制和备份的一般简介,这些方法用于创建能抵抗物理风险的工作负荷,以应对导致服务中断、停机或数据丢失的物理风险。

冗余是维护服务组件的多个相同副本,并且以阻止任何一个组件成为单一故障点的方式使用这些副本的能力。

复制或数据冗余 是维护多个数据副本(称为副本)的功能。

备份能够维护可用于还原丢失的数据的时间戳副本。

从可靠性的角度来看,缓解许多风险的一个重要方法是在 业务连续性规划中包括某种形式的冗余、复制或备份。

注释

本文不提供有关单个 Azure 服务的设计指南或详细信息。 有关特定的 Azure 服务如何可靠工作的信息,请参阅每个服务的可靠性指南

冗余

冗余包括部署组件的多个实例。 尽管冗余很容易理解,但在某些情况下,实现起来可能变得复杂。

开始了解冗余时,最容易考虑与无状态组件(即不存储任何数据的组件)相关的冗余。 尽管大多数实际解决方案确实需要管理状态,但在本节中,我们将讨论无状态应用程序编程接口(API)的示例冗余。 示例 API 接受输入,可处理该输入,然后返回输出,而无需存储任何数据。 在接下来的部分中,复制:数据的冗余,我们将添加关于有状态冗余的考虑因素。

方案:无状态冗余

在此示例中,无状态 API 组件部署到虚拟机。 为避免在物理主机上出现硬件故障而使 API 组件停机,该示例实现冗余解决方案:

  • 部署 API 实例的多个副本。
  • 实现 负载均衡器 以在 API 实例之间分配请求。

显示组件三个实例的关系图,其中负载均衡器在组件之间分配流量。

负载均衡器监视每个实例的运行状况,以仅将请求发送到正常实例。

显示三个组件实例的图表,其中一个实例已失效,而其余两个实例仍在运行。

冗余注意事项

实现冗余解决方案(如在上述方案中)时,请务必考虑以下事项:

  • 资源成本。 根据定义,冗余涉及具有多个内容副本,这会增加托管解决方案的总成本。

  • 性能。 分发内容副本的地理区域越广泛,可以帮助缓解的风险就越多。 但是,来自客户端的请求需要更长的时间才能经过更长的距离,因为它们必须遍历更多的网络基础结构,这会增加 网络延迟

    在大多数实际情况下,网络延迟对于短距离而言是无关紧要的,例如在数据中心内,甚至跨城市之间的数据中心之间传输。 但是,如果跨长距离分发副本,则网络延迟可能会变得更加严重。

  • 实例的一致性。 请务必使实例彼此保持一致,并避免单独配置实例,因为可能会意外地引入实例之间的差异。 如果实例之间存在差异,则请求可能会根据哪个实例提供服务以不同的方式进行处理。 这可能会导致难以诊断的错误和行为。

  • 工作分布。 如果组件有多个实例,则需要在组件之间分配工作。 可以将工作分散到所有实例上,也可以将请求发送到单个 实例,并且仅当主实例不可用时才使用辅助实例。

    对于接收传入请求的组件,负载均衡器通常用于将这些请求发送到实例。 但是,有时组件独立工作,并且不会接收来自客户端的请求,因此在这些情况下,实例可能需要相互协调其工作。

  • 健康监测。 每个实例的运行状况确定该实例是否可以执行其工作,如果出现问题,则运行状况监视对于启用快速恢复非常重要。

    负载均衡器通常会执行运行状况监视。 对于不包含负载均衡器的组件,可能有一个外部组件监视所有实例的运行状况,或者每个实例可能会监视其他实例的运行状况。

云中的物理位置

当你明白,即使在云环境中,实例或一段数据存储在特定物理位置时,冗余的需求也很明显。

例如:

  • 虚拟机随时在单个物理位置运行。
  • 数据存储在特定物理位置,例如固态硬盘(SSD)或连接到服务器的硬盘上。

即使组件的一段数据或实例有多个副本,每个副本也会绑定到它所存储的物理硬件。

可将云环境的物理位置组织为整个物理范围。 在每个物理范围内,存在可能危及该范围内组件或数据的潜在风险。 下面是可按物理范围定义的非穷尽列表风险:

物理范围 可能的风险
特定硬件(如磁盘或服务器) 硬件故障
数据中心中的机架 架顶网络交换机中断
数据中心 建筑物冷却系统的问题
Azure 中的一组数据中心称为 可用性区域 全市范围的雷暴
数据中心所在的更广的地理区域,例如城市,它是一个 Azure 区域 广泛的自然灾害

从可靠性的角度来看,缓解与物理范围相关的风险的重要方法是将组件实例分散到不同的物理范围。 具有内置冗余的 Azure 服务可提供以下三种部署冗余实例的一种或多种方法:

  • 本地冗余 将实例置于单个 Azure 数据中心的多个部分,并防范可能影响单个实例的硬件故障。 本地冗余通常提供最低的成本和延迟。 但是,数据中心故障可能意味着所有实例都不可用。

  • 区域冗余 将实例分散到单个 Azure 区域中的多个可用性区域。 除了硬件故障外,区域冗余还可防止数据中心故障。

  • 异地冗余 将实例置于多个 Azure 区域,并提供针对大规模区域中断的保护。 异地冗余的成本更高,需要考虑更广泛的解决方案设计,以及如何在每个区域中的组件实例之间切换。 还需要考虑延迟,这在 同步复制和异步复制中介绍。

冗余在 Azure 中的工作原理:计算服务

几乎在 Azure 的每个部分都采用冗余。 作为 Azure 如何实现冗余的示例,请考虑运行计算工作负荷的服务。

在 Azure 中,单个虚拟机(VM)在 Azure 数据中心的单个物理主机上运行。 可以向 Azure 提供说明,以确保 VM 在所需的位置(例如区域和可用性区域)运行,在某些情况下,你甚至可能想要 将其放置在专用于你的主机上

通常运行虚拟机的多个实例。 在这种情况下,可以选择单独管理它们,也可以使用 虚拟机规模集进行管理。 使用规模集时,仍可以看到支撑它的单个 VM,但规模集提供了一系列功能来帮助管理冗余 VM。 这些功能包括根据指定的规则自动放置 VM,例如,通过跨区域或可用性区域中的容错域分散它们。

其他许多 Azure 计算服务依赖于虚拟机来执行计算任务。 计算服务通常提供各种冗余设置,用于确定虚拟机的分布方式。 例如,服务可能提供区域冗余设置,你可以启用此设置,以便自动跨可用性区域分配虚拟机并配置负载均衡。

复制:数据的冗余

当冗余应用于状态(数据)时,称为复制。 使用复制,可以维护多个实时或准实时的实时数据副本,称为 副本。 为了提高风险的复原能力,可以将副本分发到不同的位置。 如果一个副本不可用,系统可能会进行故障转移,以便另一个副本接管其职能。

有不同类型的复制,每个复制都对数据一致性、性能和成本有不同的优先级。 每个复制类型都会影响在讨论业务连续性时使用的两个关键指标: 恢复时间目标 (RTO),这是在灾难方案中可以容忍的最大停机时间量,恢复 点目标 (RPO),这是在灾难方案中可以容忍的最大数据丢失量。 若要详细了解这些指标及其与业务连续性的关系,请参阅什么是业务连续性、高可用性和灾难恢复?

由于复制在满足功能和性能要求方面的重要性,大多数数据库系统和其他数据存储产品和服务都包括某种复制作为紧密集成的功能。 它们提供的复制类型通常基于其体系结构及其使用方式。 若要了解 Azure 服务支持的复制类型,请参阅 Azure 服务可靠性指南

重要

复制与备份不同。 复制会同步多个副本之间的所有更改,并且不维护旧数据副本。

假设你意外删除了一些数据。 删除操作将复制到每个副本,您的数据将在所有地方被删除。 在这种情况下,可能需要从备份还原已删除的数据。 本文稍后将介绍备份。

同步和异步复制

复制数据时,对该数据所做的任何更改都必须在副本之间保持同步。 尝试在数据更改时保持一致性时,有几个主要挑战:

  • 延迟。 更新副本需要时间,副本之间的距离越远,传输数据和接收确认所需的时间就越长。

  • 变更管理。 在同步副本时数据可能会更改,因此管理数据的一致性可能会变得复杂。

为了应对这些挑战,可以通过两种主要方法复制数据更改和管理数据一致性:

  • 同步复制 要求在将更新视为完成之前对多个副本进行更新。 下图说明了同步复制的工作原理:

    显示两个副本之间的同步复制的关系图。

    在此示例中,将执行以下步骤序列:

    1. 客户端更改数据,并将请求发送到副本 1,该副本处理请求并存储更改的数据。
    2. 副本 1 将更改发送到副本 2,该副本处理请求并存储已更改的数据。
    3. 副本 2 确认更改回副本 1。
    4. 副本 1 确认更改回客户端。

    同步复制可以保证一致性,这意味着它可以支持 0 的 RPO。 但是,这以性能为代价。 当您的副本在地理上的距离越远,且需要遍历的网络跃点越多时,复制过程会引入更多的延迟。

  • 异步复制 发生在后台。 下图演示了异步复制的工作原理:

    显示两个副本之间异步复制的关系图。

    在此示例中,将执行以下步骤序列:

    1. 客户端更改数据,并将请求发送到副本 1。
    2. 副本1处理请求、存储已更改的数据,并立即向客户端确认该更改。
    3. 稍后某个时间点,副本 1 会将更改同步到副本 2。

    由于异步复制发生在事务流之外,因此它会删除复制作为应用程序性能的约束。 但是,如果需要故障转移到另一个副本,它可能没有最新数据,因此 RPO 必须大于零。 异步复制支持的确切 RPO 取决于复制频率。

副本角色

在许多复制系统中,副本可以承担不同的角色,这有助于协调数据更改并减少冲突的可能性。 有两种主要类型的角色: 主动被动。 可通过以下两种常见方式分发具有这些角色的副本:

  • 主动-被动复制意味着你有一个主动副本,该副本负责充当事实来源。 对数据所做的任何更改都必须应用于该副本。 任何其他副本都充当 被动 角色,这意味着它们从活动副本接收对数据的更新,但它们不会直接从客户端处理更改。 除非发生故障转移并且副本的角色发生更改,否则被动副本不会用于实时流量。 下图显示了一个具有一个被动副本的主动-被动系统:

    显示两个副本之间的主动-被动复制的关系图。

    在主动-被动系统中,执行故障转移所用的时长决定了 RTO。 通常,主动-被动系统的 RTO 以分钟为单位进行度量。

    某些复制解决方案还支持 只读副本,这使你可以从被动副本读取(但不写入)数据。 此方法可用于从副本获取更多利用率,例如,需要对数据执行分析或报告,而不会影响用于应用程序事务工作的主要副本。 多个 Azure 服务支持只读副本,包括 具有读取访问权限 GRS(RA-GRS) 复制类型的 Azure 存储,以及 Azure SQL 数据库活动异地复制

  • 借助主动-主动复制,可以同时对实时流量使用多个活动副本,并且任何副本都可以处理请求:

    显示两个副本之间的主动-主动复制的关系图。

    主动-主动复制可实现高性能,因为系统可以使用所有副本上的资源。 在某些情况下,主动-主动复制可支持零 RTO。 但是,这些优势是以增加数据一致性的复杂性为代价的,因为同时在多个副本上进行的竞争性更改可能需要异步进行调和。

复杂的数据服务可以合并主动-主动和主动-被动复制。 例如,它们可能会在一个 Azure 区域中部署一组副本,另一组副本在另一个区域中部署。 在每个区域中,单个活动副本负责处理请求,而一个或多个被动副本则处于故障转移待命状态。 同时,这两个区域都在主动-主动模型中运行,允许流量分布在它们之间。

复制在 Azure 数据服务中的工作原理

存储数据的每个 Azure 服务都提供某种形式的复制。 但是,每个服务可以使用特定于服务的体系结构和预期用途的不同方法。

例如,Azure 存储可以通过一组功能提供同步复制和异步复制:

  • 在您的主要地区内,您的数据的多个副本会被同步复制。 可以选择是将副本放置在本地冗余存储(LRS)中的单个数据中心的不同物理硬件上,还是将它们分散到多个可用性区域进行区域冗余存储(ZRS)。
  • 如果主要区域已配对并启用异地冗余存储(GRS),则数据也会复制到配对区域。 由于配对区域在地理上相距遥远,因此此复制以异步方式进行,以减少对应用程序吞吐量的影响。
  • 可以通过使用异地区域冗余存储层(GZRS),同时选择使用区域冗余存储和异地冗余存储。 区域中的数据同步复制,跨区域的数据以异步方式复制。

有关详细信息,请参阅 Azure 存储冗余

另一个示例是 Azure Cosmos DB,后者还提供复制。 所有 Azure Cosmos DB 数据库都具有多个副本。 全局分发副本时,它支持多区域写入,客户端可以在使用的任何区域中写入副本。 这些写操作在区域内同步复制,然后跨其他区域异步复制。 Azure Cosmos DB 提供冲突解决机制,以防不同副本发生写入冲突。 若要了解详细信息,请参阅 Azure Cosmos DB 的全局数据分布 - 幕后。

如果使用虚拟机,可以使用 Azure Site Recovery 在可用性区域或另一个 Azure 区域之间复制虚拟机及其磁盘。

设计 Azure 解决方案时,请参阅 每个服务的可靠性指南 ,以了解该服务如何提供冗余和复制,包括跨不同位置。

备份

备份会在特定时间点复制数据。 如果出现问题,可以稍后 还原 备份。 但是,对在创建备份后发生的数据所做的任何更改都不会在备份中,并且可能会丢失。

通过使用备份,您可以提供解决方案来在 Microsoft Azure 云中备份和恢复您的数据。 备份可以保护你免受各种风险的影响,包括:

  • 硬件或其他基础结构的灾难性损失。
  • 数据损坏和删除。
  • 网络攻击,例如勒索软件。

重要

测试并定期验证备份和还原过程以及其他恢复步骤至关重要。 测试可确保备份全面且无错误,并确保你的流程会正确还原它们。 测试对于确保团队了解要遵循的过程也很重要。 若要了解详细信息,请参阅 测试和演练

备份如何影响你的要求

如果用作灾难恢复策略的一部分,备份通常支持按小时度量的 RTO 和 RPO:

  • RTO 受启动和完成恢复过程所需的时间的影响,包括还原备份并验证还原成功完成。 根据备份的大小以及需要从中读取多少个备份文件,通常需要几个小时甚至更长时间才能完全还原备份。

  • RPO 受备份过程的频率影响。 如果更频繁地进行备份,则意味着如果必须从备份还原,则丢失的数据更少。 但是,备份需要存储,在某些情况下,它们可能会影响执行备份时服务的性能。 出于此原因,需要考虑备份频率,并找到组织要求的正确平衡。 备份频率应该是业务连续性规划中的一个考虑因素。

某些备份系统支持更复杂的备份需求,包括具有不同保留期的多个备份层,以及速度更快且占用存储更少的差异备份或增量备份。

Azure 服务中的备份

许多 Azure 服务为数据提供备份功能。

Azure 备份 是多个关键 Azure 服务的专用备份解决方案,包括虚拟机、Azure 存储和 Azure Kubernetes 服务(AKS)。

此外,许多托管数据库作为服务的一部分提供自己的备份功能,例如:

备份与复制

备份和复制可保护你免受不同风险的影响,这两种方法相互补充。

复制支持日常复原能力,通常用于高可用性策略。 某些复制方法几乎不需要停机或数据丢失,并支持较低的 RTO 和 RPO。 但是,复制不会保护你免受导致数据丢失或损坏的风险。

相比之下,备份通常是针对灾难性风险的最后一道防线。 备份通常需要相对较高的 RTO 和 RPO,但配置备份的方式会影响备份的确切程度。 从备份进行总还原通常是灾难恢复计划的一部分。

准备组件以备冗余

设计使用冗余作为体系结构的一部分的系统时,请务必考虑如何:

  • 重复的资源配置以确保一致性。
  • 通过过度预配在实例故障期间管理容量。

重复的资源配置

在云环境中,每个资源的配置至关重要。 例如,创建网络负载均衡器时,可以配置影响其工作原理的各种设置;使用 Azure Functions 部署函数时,可以配置与安全性、性能和应用程序配置设置相关的设置。 Azure 中的每个资源都有某种配置来驱动其行为。

在不同位置管理资源的冗余副本时,请务必控制其配置。 为了使资源以相同方式运行,需要在每个副本中以相同的方式进行设置。 但是,每个副本之间的某些设置可能有所不同,例如对特定区域的虚拟网络的引用。

在资源中保持一致性的常见方法是使用基础结构即代码 (IaC),例如 Bicep 或 Terraform。 借助这些工具,可以创建定义资源的文件,并且可以对资源的每个实例重复使用这些定义。 通过使用 IaC,可以减轻为复原目的创建和管理多个资源实例的负担,而且还有其他许多好处。 若要了解详细信息,请参阅 什么是基础结构即代码(IaC)? 以及 有关使用基础结构即代码的建议

使用过度预配的方法来管理容量

实例发生故障时,整个系统的容量可能会与正常运营时所需的容量不同。 例如,假设 Web 服务器通常有六个实例来处理传入的 Web 流量,并且这些实例在区域中的三个 Azure 可用性区域之间平均分布:

图表显示三个可用区,每个可用区有两个 Web 服务器实例,总共六个实例。

如果可用性区域遇到中断,可能会暂时丢失两个实例,并且只剩下四个 Web 服务器实例。 如果应用程序通常很繁忙,并且需要所有六个实例跟上正常流量,则以更低的容量运行可能会影响解决方案的性能。

若要为故障做好准备,可以 过度预配 服务的容量。 超额预配使解决方案能够容忍一定程度的容量损失,并且仍然可以继续运行而不会降低性能。

若要预先超额配置 Web 服务器的实例以应对某个可用区的故障,请执行以下步骤:

  1. 确定高峰工作负载所需的实例数。
  2. 通过将峰值工作负载实例计数乘以系数 [(区域数/(区域数-1)] 来检索超额预配实例计数。
  3. 将结果向上舍入为最接近的整数。

注释

下表假定你使用的是三个可用性区域,并且你希望考虑到其中一个区域的容量损失。 如果要求不同,请相应地调整公式。

峰值工作负载实例计数 [(zones/(zones-1)] 的因子 公式 要预配的实例(已舍入)
3 3/2 或 1.5 (3 x 1.5 = 4.5) 5 个实例
4 3/2 或 1.5 (4 x 1.5 = 6) 6 个实例
5 3/2 或 1.5 (5 x 1.5 = 7.5) 8 个实例
6 3/2 或 1.5 (6 x 1.5 = 9) 9 个实例
7 3/2 或 1.5 (7 x 1.5 = 10.5) 11 个实例
8 3/2 或 1.5 (8 x 1.5 = 12) 12 个实例
9 3/2 或 1.5 (9 x 1.5 = 13.5) 14 个实例
10 3/2 或 1.5 (10 x 1.5 = 15) 15 个实例

在前面的示例中,峰值工作负荷需要 Web 服务器的六个实例,因此过度预配总共需要 9 个实例:

显示过度预配 Web 服务器的关系图,总计为 9 个实例的容量。

后续步骤

了解故障转移和故障回复