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

Microsoft 致力于确保 Azure 服务一直可用。 但偶尔可能发生计划外服务中断。 良好的灾难恢复计划的关键组成部分包括：

• 数据保护
• 备份和还原
• 数据冗余
• 故障转移
• 设计应用程序以实现高可用性

本文介绍可用于全局冗余存储帐户的选项，并提供有关开发高度可用应用程序和测试灾难恢复计划的建议。

选择正确的冗余选项

Azure 存储可维护存储帐户的多个副本，以确保即使遇到故障也能满足可用性和持久性目标。 复制数据的方式提供了不同的保护级别。 每个选项都有其自己的优势，因此选择的选项取决于应用程序所需的复原能力级别。

本地冗余存储 (LRS) 是成本最低的冗余选项，可在单个数据中心内自动存储和复制存储帐户的三个副本。 尽管 LRS 可保护数据免受服务器机架和驱动器故障的影响，但它不会考虑数据中心内的火灾或洪水等灾难。 如果发生此类灾难，配置为使用 LRS 的存储帐户的所有副本可能会丢失或无法恢复。

相比之下，区域冗余存储 (ZRS) 将保留存储帐户的副本，并将其复制到同一区域中三个单独的可用性区域中的每一个。 有关可用性区域的详细信息，请参阅 Azure 可用性区域。

异地冗余存储和故障转移

异地冗余存储 (GRS)、异地区域冗余存储 (GZRS) 和读取访问异地区域冗余存储 (RA-GZRS) 是全局冗余存储选项的示例。 配置为使用全局冗余存储（GRS、GZRS 和 RA-GZRS）时，Azure 可将数据异步复制到次要地理区域。 这些地区位于数百英里甚至数千英里之外。 借助此级别的冗余助，可以在整个主要区域发生中断时恢复数据。

与 LRS 和 ZRS 不同，如果主要区域中发生中断，全局冗余存储还提供对计划外故障转移到次要区域的支持。 在故障转移过程中，存储帐户服务终结点的 DNS（域名系统）条目会自动更新，以便次要区域的终结点成为新的主终结点。 在计划外故障转移完成后，客户端便可以开始对新的主终结点执行写入操作。

读取访问异地冗余存储 (RA-GRS) 或读取访问异地区域冗余存储 (RA-GZRS) 也会提供异地冗余存储，但提供了对次要终结点进行读取访问的额外优点。 这些选项非常适合为高可用性业务关键型应用程序设计的应用程序。 如果主终结点遇到服务中断，则配置为对次要区域进行读取访问的应用程序可以继续运行。 Microsoft 建议使用 RA-GZRS 实现存储帐户的最大可用性和持久性。

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

规划故障转移

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

• 客户管理的计划的故障转移（预览版） - 客户可以管理存储帐户故障转移来测试其灾难恢复计划。
• 客户管理的（计划外）故障转移 - 客户可以管理发生意外服务中断时的存储帐户故障转移。
• Microsoft 托管的故障转移 - 仅当主要区域中发生严重灾难时才可能由 Microsoft 启动。 1,2

¹ 无法为单个存储帐户、订阅或租户启动 Microsoft 托管的故障转移。 有关详细信息，请参阅 Microsoft 托管的故障转移。
² 使用客户管理的故障转移选项来开发、测试和实现灾难恢复计划。 不要依赖于 Microsoft 托管的故障转移，它仅用于极端情况。

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

下表比较了每种故障转移类型后存储帐户的冗余状态：

下表总结了每种类型故障转移和故障回复过程的每个阶段生成的冗余配置：

¹ 在计划的故障转移期间会保留异地冗余，无需手动重新配置。

客户管理的计划的故障转移（预览版）

计划的故障转移可用于多种场景，包括计划灾难恢复测试、应对大规模灾难的主动方法或从非存储相关中断中恢复。

在计划的故障转移过程中，将交换主要区域和次要区域。 原始主要区域将降级，成为新的次要区域。 同时，原始次要区域将升级，成为新的主要区域。 故障转移完成后，用户可以继续访问新主要区域中的数据，管理员可以验证其灾难恢复计划。 存储帐户必须同时在主要区域和次要区域中可用，然后才能启动计划的故障转移。

只要主要区域和次要区域在整个过程中可用，计划的故障转移和故障回复过程中应不会丢失数据。 有关详细信息，请参阅预测数据丢失和不一致部分。

要了解这种类型的故障转移对用户和应用程序的影响，了解计划的故障转移和故障回复过程每个步骤中发生的情况会很有帮助。 有关此过程工作原理的详细信息，请参阅客户管理的（计划的）故障转移的工作原理。

客户管理的（计划外）故障转移

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

要了解这种类型的故障转移对用户和应用程序的影响，了解计划外故障转移和故障回复过程每个步骤中发生的情况会很有帮助。 有关此过程工作原理的详细信息，请参阅客户管理的（计划外）故障转移的工作原理。

Microsoft 托管的故障转移

Microsoft 可能会在极端情况下启动区域故障转移，例如影响整个地理区域的灾难性灾害。 在这些事件期间，无需执行任何操作。 如果存储帐户配置为 RA-GRS 或 RA-GZRS，则应用程序可以在 Microsoft 管理的故障转移期间从次要区域读取。 但在故障转移过程完成之前，你没有对存储帐户的写入访问权限。

预计数据丢失和不一致

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

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

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

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

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

上次同步时间

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

最佳做法是将应用程序设计为可以使用“上次同步时间”来评估预期数据丢失。 例如，通过记录所有写入操作，可以将上次写入操作的时间与上次同步时间进行比较。 使用此方法，你能够确定哪些写入尚未同步到辅助区域，并且存在丢失的危险。

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

Azure Data Lake Storage Gen2 的文件一致性

启用了分层命名空间 (Azure Data Lake Storage Gen2) 的存储帐户复制在文件级别进行。 由于复制在此级别发生，因此主要区域中的中断可能会阻止容器或目录中的一些文件成功复制到次要区域。 无法保证在存储帐户故障转移后容器或目录中所有文件的一致性。

更改源和 blob 数据不一致

对启用了更改源的存储帐户进行客户管理的（计划外）故障转移可能会导致更改源日志与 blob 数据和/或元数据之间不一致。 这种不一致可能是主要区域和次要区域之间更改日志更新和数据复制的异步性质造成的。 可以通过采取以下预防措施来避免不一致：

• 确保所有日志记录都刷新到日志文件。
• 确保所有存储数据都从主区域复制到了次要区域。

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

请记住，其他存储帐户功能也需要启用更改源。 这些功能包括 Azure Blob 存储的运行备份、对象复制和块 Blob 的时间点还原。

时间点还原不一致

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

故障转移的时间和成本

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

客户管理的计划的故障转移不会在故障转移和后续故障回复后丢失其异地冗余，但客户管理的计划外故障转移会。

启动客户管理的计划外故障转移会自动将存储帐户转换为新主要区域中的本地冗余存储 (LRS)，并删除原始主要区域中的存储帐户。

可以为帐户重新启用异地冗余存储 (GRS) 或读取访问异地冗余存储 (RA-GRS)，但将数据重新复制到新的次要区域会产生费用。 此外外，需要先将任何已存档 blob 解除冻结到联机层，然后才能将帐户配置为使用异地冗余。 这种解除冻结也会产生额外的费用。 有关定价的详细信息，请参阅：

• 带宽定价详细信息
• Azure 存储定价

在你为存储帐户重新启用 GRS 后，Microsoft 便会开始将帐户中的数据复制到新的次要区域。 完成复制所需的时间取决于多个因素。 这些因素包括：

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

支持的存储帐户类型

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

经典存储帐户

分层命名空间 (HNS)

不支持的功能和服务

客户管理的故障转移不支持以下功能和服务：

• Azure 文件同步不支持客户管理的帐户故障转移。 不应对用作 Azure 文件同步云终结点的存储帐户进行故障转移。 故障转移会中断文件同步，并可能导致新分层文件意外数据丢失。 有关详细信息，请参阅使用 Azure 文件同步进行灾难恢复的最佳做法。
• 无法对包含高级块 Blob 的存储帐户执行故障转移。 支持高级块 Blob 的存储帐户暂不支持异地冗余。
• 对象复制策略中的源帐户或目标帐户均不支持客户管理的故障转移。
• 存储帐户故障转移不支持网络文件系统 (NFS) 3.0 (NFSv3)。 无法创建为启用了 NFSv3 的全局冗余配置的存储帐户。

下表可用于参考功能支持。

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

存储帐户故障转移是一种临时解决方案，可用于帮助规划和测试 DR 计划，或从服务中断中恢复。 不应将故障转移用作数据迁移策略的一部分。 有关如何迁移存储帐户的信息，请参阅 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。 帐户故障转移可能会导致虚拟机 (VM) 关闭时临时磁盘中存储的数据丢失。 Microsoft 建议使用以下特定于 Azure 中虚拟机的高可用性和灾难恢复指南。

Azure 非托管磁盘

非托管磁盘在 Azure 存储中存储为页 blob。 如果 VM 在 Azure 中运行，任何附加到 VM 的非托管磁盘都会被租用。 如果 Blob 上有租用，便无法继续帐户故障转移。 必须先关闭磁盘盘，然后才能在包含附加到 Azure VM 的非托管磁盘的帐户上启动故障转移。 因此，Microsoft 建议的最佳做法包括将任何非托管磁盘转换为托管磁盘。

要对包含非托管磁盘的帐户执行故障转移，请执行以下步骤：

1. 开始前，先记下任何非托管磁盘的名称、逻辑单元号 (LUN) 和要将其附加到的 VM。 此操作可便于在故障转移完成后更轻松地重新附加磁盘。
2. 关闭 VM。
3. 删除 VM，但保留非托管磁盘的虚拟硬盘 (VHD) 文件。 记下 VM 删除时间。
4. 等待上次同步时间更新，并确保它晚于删除 VM 的时间。 此步骤可确保在发生故障转移时使用 VHD 文件完全更新次要终结点，并且 VM 可在新的主要区域中正常运行。
5. 启动帐户故障转移。
6. 等到帐户故障转移完成，且次要区域成为新的主要区域。
7. 在新的主要区域中创建 VM，并重新附加 VHD。
8. 启动新 VM。

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

将数据复制为故障转移替代方法

如前所述，可以通过将应用程序配置为使用配置为具有次要区域读取访问权限的存储帐户来保持高可用性。 但如果不希望在主要区域中的中断期间进行故障转移，则可以手动复制数据作为替代方法。 使用 AzCopy 和 Azure PowerShell 等工具，可以将受影响区域存储帐户中的数据复制到不受影响区域中的另一个存储帐户。 复制操作完成后，可以将应用程序重新配置为在未受影响的区域中使用存储帐户，以实现读取和写入可用性。

旨在实现高可用性

请务必从一开始就设计高可用性应用程序。 有关设计应用程序和规划灾难恢复方面的指导，请参阅以下 Azure 资源：

• 设计适用于 Azure 的可复原应用程序：概述了在 Azure 中生成高可用性应用程序的关键概念。
• 复原能力清单：用于验证应用程序是否实现高可用性最佳设计做法的清单。
• 使用异地冗余设计高度可用的应用程序：有关如何生成可利用异地冗余存储的应用程序的设计指南。
• 教程：生成使用 Blob 存储的高可用性应用程序：介绍了如何生成在模拟故障和恢复时自动切换终结点的高可用性应用程序的教程。

请参阅以下最佳做法来维护 Azure 存储数据的高可用性：

• 磁盘： 利用 Azure 备份备份 Azure 虚拟机使用的 VM 磁盘。 还应考虑在发生区域灾难时使用 Azure Site Recovery 来保护 VM。
• 块 blob： 启用软删除以防发生对象级删除和覆盖，或使用 AzCopy、Azure PowerShell 或 Azure 数据移动库将块 blob 复制到其他区域中的另一个存储帐户内。
• 文件：使用 Azure 备份来备份文件共享。 同时启用软删除，以防止意外删除文件共享。 对于 GRS 不可用时的异地冗余，请使用 AzCopy 或 Azure PowerShell 将文件复制到不同区域中的另一个存储帐户。
• 表：使用 AzCopy 将表数据导出到其他区域中的另一个存储帐户内。

跟踪服务中断

客户可以订阅 Azure 服务运行状况仪表板，以跟踪 Azure 存储和其他 Azure 服务的运行状况及状态。

Microsoft 还建议将应用程序设计为，可以应对可能出现的写入故障。 应用程序应公开写入故障，以提醒你主要区域可能存在服务中断。

另请参阅

• 使用异地冗余设计高度可用的应用程序
• 教程：生成使用 Blob 存储的高可用性应用程序
• Azure 存储冗余
• 客户管理的计划的故障转移（预览版）的工作原理
• 客户管理的（计划外）故障转移的工作原理