Azure 存储灾难恢复计划和故障转移

项目
04/12/2024

我们努力确保 Azure 服务始终可用。不过，可能会发生计划外服务中断。良好的灾难恢复计划的关键组成部分包括：

本文重点介绍全局冗余存储帐户（GRS、GZRS 和 RA-GZRS）的故障转移，以及如何将应用程序设计为在发生中断和后续故障转移时高度可用。

选择正确的冗余选项

Azure 存储将维护存储帐户的多个副本，以确保持续性和高可用性。为帐户选择的冗余选项取决于应用程序所需的复原程度。

使用本地冗余存储 (LRS)，存储帐户的三个副本会自动存储在单个数据中心内并复制。使用区域冗余存储 (ZRS)，副本将存储在同一区域中三个单独的可用性区域中并复制。有关可用性区域的详细信息，请参阅 Azure 可用性区域。

使用 LRS 和 ZRS 自动恢复存储帐户的单个副本。

全局冗余存储和故障转移

使用全局冗余存储（GRS、GZRS 和 RA-GZRS）时，Azure 可将数据异步复制到至少数百英里外的次要地理区域。这允许在主要区域中发生中断时恢复数据。将全局冗余存储与 LRS 及 ZRS 区分开来的功能是在主要区域中发生中断时能够故障转移到次要区域。故障转移过程会更新存储帐户服务终结点的 DNS 条目，使次要区域的终结点成为存储帐户新的主终结点。在故障转移完成后，客户端便可以开始对新的主终结点执行写入操作。

RA-GRS 和 RA-GZRS 冗余配置提供异地冗余存储，增加了在主要区域发生中断读取辅助终结点的优点。如果主终结点发生中断，配置为读取辅助终结点并设计为高可用性的应用程序可以继续从辅助终结点读取数据。 Azure 建议使用 RA-GZRS 实现存储帐户的最大可用性和持久性。

有关 Azure 存储中冗余的详细信息，请参阅 Azure 存储冗余。

规划存储帐户故障转移

Azure 存储帐户支持两种类型的故障转移：

客户管理的故障转移 - 客户可以管理发生意外服务中断时的存储帐户故障转移。
Azure 托管的故障转移 - 仅当主要区域中发生严重灾难时才可能被 Azure 启动。 1,2

¹无法为单个存储帐户、订阅或租户启动 Azure 托管的故障转移。有关详细信息，请参阅 Azure 托管的故障转移。
² 灾难恢复计划应基于客户管理的故障转移。不要依赖于 Azure 托管的故障转移，它仅用于极端情况。

每种类型的故障转移都有一组唯一的用例、相应的数据丢失预期，并支持启用了分层命名空间的帐户 (Azure Data Lake Storage Gen2)。下表总结了每种故障转移类型的这些方面：

类型	故障转移范围	用例	预期数据丢失	支持 HNS
由客户管理	存储帐户	主要区域的存储服务终结点变得不可用，但次要区域可用。你收到了一份 Azure 公告，其中 Azure 建议你执行可能受中断影响的存储帐户的故障转移操作。	是	是（预览版）
Azure 托管	整个区域或缩放单元	由于发生重大灾难，主要区域完全不可用，但次要区域可用。	是	是

客户管理的故障转移

如果存储帐户中存储服务的数据终结点在主要区域中不可用，则可以故障转移到次要区域。故障转移完成后，次要区域将成为新的主要区域，用户可以继续访问新主要区域中的数据。

为充分了解客户管理的帐户故障转移对用户和应用程序的影响，了解故障转移和故障回复过程的每个步骤会发生什么很有帮助。有关该过程如何运作的详细信息，请参阅客户管理的存储帐户故障转移如何运作。

Azure 托管的故障转移

在极端情况下，如果原始主要区域因发生重大灾难而被认为在合理的时间内无法恢复，Azure 可能会启动区域故障转移。在此情况下，不需要采取任何操作。在 Azure 托管的故障转移完成之前，你对存储帐户不拥有写入访问权限。如果存储帐户已配置 RA-GRS 或 RA-GZRS，应用程序可以从次要区域读取数据。

重要

灾难恢复计划应基于客户管理的故障转移。不要依赖于 Azure 托管的故障转移，它可能仅适用于极端情况。将为整个物理单元（例如区域或缩放单元）启动 Azure 托管的故障转移。它无法为单个存储帐户、订阅或租户启动。若要选择性故障转移单个存储帐户，请使用客户管理的帐户故障转移。

预计数据丢失和不一致

注意

存储帐户故障转移通常涉及一些数据丢失，并且可能存在文件和数据不一致。在灾难恢复计划中，请务必在启动数据之前考虑帐户故障转移对数据的影响。

因为数据是从主要区域异步写入次要区域，所以在写入主要区域的数据复制到次要区域前始终存在延迟。如果主要区域不可用，最新写入数据可能尚未复制到次要区域。

如果发生故障转移，主要区域中的所有数据就会在次要区域成为新的主要区域时丢失。当故障转移发生时，将保留已复制到次要区域的所有数据。不过，任何写入主要区域、但尚未复制到次要区域的数据会永久丢失。

新的主要区域在故障转移后配置为本地冗余 (LRS)。

如果存储帐户启用了以下一个或多个功能，则也可能遇到文件或数据不一致：

分层命名空间 (Azure Data Lake Storage Gen2)
更改源
块 blob 的时间点还原

上次同步时间

“上次同步时间”属性表示，最近一次保证已将主要区域中的数据写入次要区域的时间。对于具有分层命名空间的帐户，相同的“上次同步时间”属性也适用于由分层命名空间（包括 ACL）管理的元数据。上次同步时间之前写入的所有数据和元数据都已复制到次要区域中，而在上次同步时间之后写入的数据和元数据则可能尚未写入次要区域并发生丢失。如果发生服务中断，使用此属性可估计启动帐户故障转移可能会造成的数据丢失量。

最佳做法是，将应用程序设计为，可以使用上次同步时间来评估预期数据丢失。例如，若要记录所有写入操作，可以比较上次写入操作时间与上次同步时间，以确定哪些写入操作尚未同步到次要区域。

如需详细了解如何检查“上次同步时间”属性，请参阅检查存储帐户的“上次同步时间”属性。

Azure Data Lake Storage Gen2 的文件一致性

启用了分层命名空间 (Azure Data Lake Storage Gen2) 的存储帐户复制在文件级别进行。这意味着，如果主要区域中发生中断，则只有容器或目录中的某些文件可能已成功复制到次要区域。无法保证在存储帐户故障转移后容器或目录中的所有文件的一致性。

更改源和 blob 数据不一致

启用了更改源的异地冗余存储帐户的存储帐户故障转移，可能会导致更改源日志与 blob 数据和/或元数据之间不一致。这种不一致可能是由于更新到更改日志以及 blob 数据从主要区域复制到次要区域这两项的异步性质造成的。唯一不应发不一致的情况是，所有当前日志记录都已成功刷新到日志文件，并且所有存储数据都已成功从主区域复制到次要区域。

有关更改源工作原理的信息，请参阅更改源的工作原理。

请记住，其他存储帐户功能需要启用更改源，例如 Azure Blob 存储的操作备份、对象复制和块 blob 的时间点还原。

时间点还原不一致

包含块 blob 的常规用途 v2 标准层存储帐户支持客户管理的故障转移。然而，对存储帐户执行客户管理的故障转移会为该帐户重置尽可能早的还原点。块 blob 的时间点还原数据仅在故障转移完成时间之前保持一致。因此，只能将块 blob 还原到不早于故障转移完成时间的时间点。可以在 Azure 门户中存储帐户的“冗余”选项卡中检查故障转移完成时间。

例如，假设你已将保持期设置为 30 天。如果故障转移后已超过 30 天，可以还原到这 30 天内的任何点。但是，如果故障转移后过去的时间不到 30 天，则无论保持期是多长时间，都无法还原到故障转移之前的时间点。例如，如果故障转移后已过去 10 天，则可能的最早还原点是过去 10 天，而不是过去 30 天。

故障转移的时间和成本

故障转移在启动后完成所用的时间可能会有所不同，但通常不到一小时。

客户管理的故障转移在故障转移（和故障回复）后失去其异地冗余。故障转移期间，存储帐户会自动转换为新主要区域中的本地冗余存储 (LRS)，并删除原始主要区域中的存储帐户。

可以为帐户重新启用异地冗余存储 (GRS) 或读取访问异地冗余存储 (RA-GRS)，但请注意，从 LRS 转换为 GRS 或 RA-GRS 会产生额外的费用。产生该费用是因为将数据重新复制到新的次要区域需要支付网络流出量费用。故障转移完成后，需要先将所有已存档 Blob 都解除冻结到联机层，然后才能将帐户配置为使用异地冗余。有关定价的详细信息，请参阅：

在你为存储帐户重新启用 GRS 后，Azure 便会开始将帐户中的数据复制到新的次要区域。复制时间取决于许多因素，其中包括：

存储帐户中对象的数量和大小。复制许多小型对象所需的时间可能比复制较少的大对象要长。
可用于后台复制的资源，例如 CPU、内存、磁盘和 WAN 容量。实时流量优先于异地复制。
如果存储帐户包含 Blob，则要复制每个 Blob 的快照数。
如果存储帐户包含表，则要复制数据分区策略。复制过程不能扩展到超过所用分区键数量的地步。

支持的存储帐户类型

所有异地冗余套餐都支持 Azure 托管的故障转移。此外，某些帐户类型支持客户管理的帐户故障转移，如下表所示：

故障转移类型	GRS/RA-GRS	GZRS/RA-GZRS
客户管理的故障转移	常规用途 v2 帐户常规用途 v1 帐户旧 Blob 存储帐户	常规用途 v2 帐户
Azure 托管的故障转移	所有帐户类型	常规用途 v2 帐户

经典存储帐户

重要

只有使用 Azure 资源管理器 (ARM) 部署模型部署的存储帐户才支持客户管理的帐户故障转移。不支持 Azure Service Manager (ASM) 部署模型（也称为经典）。若要使经典存储帐户符合客户管理的帐户故障转移的条件，必须先将其迁移到 ARM 模型。必须可以访问存储帐户来执行升级，因此主要区域当前不能处于失败状态。

如果发生影响主要区域的灾难，Azure 将管理经典存储帐户的故障转移。有关详细信息，请参阅 Azure 托管的故障转移。

Azure Data Lake Storage Gen2

启用了分层命名空间 (Azure Data Lake Storage Gen2) 的帐户尚不支持客户管理的帐户故障转移。若要了解详细信息，请参阅 Azure Data Lake Storage Gen2 中提供的 Blob 存储功能。

不支持的功能和服务

帐户故障转移不支持以下功能或服务：

Azure 文件同步不支持客户发起的存储帐户故障转移。不得对包含 Azure 文件共享且用作 Azure 文件同步中云终结点的存储帐户执行故障转移。否则，将会导致同步停止，并且可能还会在有新分层文件的情况下导致意外数据丢失。有关详细信息，请参阅使用 Azure 文件同步进行灾难恢复的最佳做法。
无法对包含高级块 Blob 的存储帐户执行故障转移。支持高级块 Blob 的存储帐户暂不支持异地冗余。
对象复制策略中的源帐户或目标帐户均不支持客户管理的故障转移。
若要对启用了 SSH 文件传输协议 (SFTP) 的帐户执行故障转移，必须先禁用该帐户的 SFTP。如果要在故障转移完成后恢复使用 SFTP，只需重新启用它。
存储帐户故障转移不支持网络文件系统 (NFS) 3.0 (NFSv3)。无法创建为启用了 NFSv3 的全局冗余配置的存储帐户。

故障转移不适用于帐户迁移

不应将存储帐户故障转移用作数据迁移策略的一部分。故障转移是服务中断的临时解决方案。有关如何迁移存储帐户的信息，请参阅 Azure 存储迁移概述。

包含存档 Blob 的存储帐户

包含已存档 blob 的存储帐户支持帐户故障转移。但在客户管理的故障转移完成后，需要先将所有已存档 Blob 都解除冻结到联机层，然后才能将帐户配置为使用异地冗余。

存储资源提供程序

Microsoft 提供两个 REST API 用于处理 Azure 存储资源。这些 API 构成了可对 Azure 存储执行的所有操作的基础。使用 Azure 存储 REST API 可以处理存储帐户中的数据，包括 Blob、队列、文件和表数据。利用 Azure 存储资源提供程序 REST API，可以管理存储帐户和相关的资源。

故障转移完成后，客户端可再次读取并写入新的主要区域中的 Azure 存储数据。但是，Azure 存储资源提供程序不会进行故障转移，因此资源管理操作仍必须在主要区域中进行。如果主要区域不可用，将无法对存储帐户执行管理操作。

由于 Azure 存储资源提供程序不会进行故障转移，因此在故障转移完成后，Location 属性将返回原始主位置。

Azure 虚拟机

在帐户故障转移过程中 Azure 虚拟机 (VM) 不故障转移。如果主要区域不可用且你故障转移到次要区域，那么就需要在故障转移完成后重新创建所有 VM。此外，还可能会丢失与帐户故障转移相关联的数据。 Azure 建议使用以下特定于 Azure 中虚拟机的高可用性和灾难恢复指南。

请注意，当 VM 关闭时，临时磁盘中存储的任何数据都会丢失。

Azure 非托管磁盘

根据最佳做法，Azure 建议将非托管磁盘转换为托管磁盘。不过，如果需要对包含附加到 Azure VM 的非托管磁盘的帐户进行故障转移，必须在启动故障转移前关闭 VM。

非托管磁盘在 Azure 存储中存储为页 blob。如果 VM 在 Azure 中运行，任何附加到 VM 的非托管磁盘都会被租用。如果 Blob 上有租用，便无法继续帐户故障转移。若要执行故障转移，请按照以下步骤操作：

开始前，先记下所有非托管磁盘的名称、逻辑单元号 (LUN) 和附加到的 VM。此操作可便于在故障转移完成后更轻松地重新附加磁盘。
关闭 VM。
删除 VM，但保留非托管磁盘的 VHD 文件。记下 VM 删除时间。
等到“上次同步时间”已更新且晚于 VM 删除时间。这一步很重要，因为如果在故障转移发生时辅助终结点尚未使用 VHD 文件完全更新，那么 VM 可能无法在新的主要区域中正常运行。
启动帐户故障转移。
等到帐户故障转移完成，且次要区域已成为新的主要区域。
在新的主要区域中创建 VM，并重新附加 VHD。
启动新 VM。