Azure 存储灾难恢复计划和故障转移
我们努力确保 Azure 服务始终可用。 但偶尔可能发生计划外服务中断。 良好的灾难恢复计划的关键组成部分包括：
本文介绍可用于异地冗余存储帐户的选项，并提供有关开发高度可用应用程序和测试灾难恢复计划的建议。
选择正确的冗余选项
Azure 存储可维护存储帐户的多个副本，以确保即使遇到故障也能满足可用性和持久性目标。 复制数据的方式提供了不同的保护级别。 每个选项都有其自己的优势，因此选择的选项取决于应用程序所需的复原能力级别。
本地冗余存储 (LRS) 是成本最低的冗余选项，可在单个数据中心内自动存储和复制存储帐户的三个副本。 尽管 LRS 可保护数据免受服务器机架和驱动器故障的影响，但它不会考虑数据中心内的火灾或洪水等灾难。 如果发生此类灾难，配置为使用 LRS 的存储帐户的所有副本可能会丢失或无法恢复。
相比之下，区域冗余存储 (ZRS) 将保留存储帐户的副本，并将其复制到同一区域中三个单独的可用性区域中的每一个。 有关可用性区域的详细信息，请参阅 Azure 可用性区域。
异地冗余存储和故障转移
异地冗余存储 (GRS)、异地区域冗余存储 (GZRS) 和读取访问异地区域冗余存储 (RA-GZRS) 都是异地冗余存储选项的示例。 配置为使用异地冗余存储（GRS、GZRS 和 RA-GZRS）时，Azure 会将数据异步复制到次要地理区域。 这些地区位于数百英里甚至数千英里之外。 借助此级别的冗余助，可以在整个主要区域发生中断时恢复数据。
与 LRS 和 ZRS 不同，异地冗余存储还支持在主要区域发生中断时向次要区域进行计划外故障转移。 在故障转移过程中，存储帐户服务终结点的 DNS（域名系统）条目会自动更新，以便次要区域的终结点成为新的主终结点。 在计划外故障转移完成后，客户端便可以开始对新的主终结点执行写入操作。
读取访问异地冗余存储 (RA-GRS) 或读取访问异地区域冗余存储 (RA-GZRS) 也会提供异地冗余存储，但提供了对次要终结点进行读取访问的额外优点。 这些选项非常适合为高可用性业务关键型应用程序设计的应用程序。 如果主终结点遇到服务中断，则配置为对次要区域进行读取访问的应用程序可以继续运行。 Azure 建议使用 RA-GZRS 实现存储帐户的最大可用性和持久性。
有关 Azure 存储的冗余的详细信息，请参阅 Azure 存储冗余。
规划故障转移
Azure 存储帐户支持两种类型的故障转移：
- 客户管理的（计划外）故障转移 - 客户可以管理发生意外服务中断时的存储帐户故障转移。
- Azure 托管故障转移 - Azure 可能会因主要区域中的严重灾难而启动。 1,2
1无法为单个存储帐户、订阅或租户启动 Azure 托管的故障转移。 有关详细信息，请参阅 Azure 托管的故障转移。
2 使用客户管理的故障转移选项来开发、测试和实现灾难恢复计划。 不要依赖于 Azure 托管的故障转移，它仅用于极端情况。
每种类型的故障转移都有一组唯一的用例、相应的数据丢失预期，并支持启用了分层命名空间的帐户 (Azure Data Lake Storage)。 下表总结了每种故障转移类型的这些方面：
| 类型 | 故障转移范围 | 用例 | 预期数据丢失 | 支持分层命名空间 (HNS)。 |
|---|---|---|---|---|
| 客户管理的（计划外）故障转移 | 存储帐户 | 主要区域的存储服务终结点变得不可用，但次要区域可用。 你收到了一份 Azure 公告，其中 Azure 建议你执行可能受中断影响的存储帐户的故障转移操作。 |
是 | 否 |
| Azure 托管 | 整个区域 | 由于发生重大灾难，主要区域不可用，但次要区域可用。 | 是 | 是 |
客户管理的（计划外）故障转移
如果存储帐户中存储服务的数据终结点在主要区域中不可用，则可以发起计划外故障转移到次要区域。 故障转移完成后，次要区域将成为新的主要区域，用户可以继续在那里访问数据。
要了解这种类型的故障转移对用户和应用程序的影响，了解计划外故障转移和故障回复过程每个步骤中发生的情况会很有帮助。 有关此过程工作原理的详细信息，请参阅客户管理的（计划外）故障转移的工作原理。
Azure 托管的故障转移
Azure 可能会在极端情况下启动区域故障转移，例如影响整个地理区域的毁灭性灾难。 在这些事件期间，无需执行任何操作。 如果为存储帐户配置了 RA-GRS 或 RA-GZRS，则应用程序可以在 Azure 托管故障转移期间从次要区域读取数据。 但在故障转移过程完成之前，你没有对存储帐户的写入访问权限。
重要
使用客户管理的故障转移选项来开发、测试和实现灾难恢复计划。 不要依赖于 Azure 托管的故障转移，它可能仅适用于极端情况。 将为整个物理单元（例如区域或数据中心）启动 Azure 托管故障转移。 它无法为单个存储帐户、订阅或租户启动。 如果需要能够有选择地故障转移单个存储帐户，请使用客户管理的（计划外）故障转移。
预计数据丢失和不一致
注意
客户管理的（计划外）故障转移通常涉及一定数量的数据丢失，还可能导致文件和数据不一致。 在灾难恢复计划中，请务必在启动数据之前考虑帐户故障转移对数据的影响。
因为数据是从主要区域异步写入次要区域，所以在写入主要区域的数据复制到次要区域前始终存在延迟。 如果主要区域不可用，则可能尚未将最近的写入复制到次要区域。
如果发生计划外故障转移，主要区域中的所有数据就会在次要区域成为新的主要区域时丢失。 当故障转移发生时，将保留已复制到次要区域的所有数据。 但写入到次要区域中尚不存在的主数据库的任何数据将会永久丢失。
新的主要区域在故障转移后配置为本地冗余 (LRS)。
如果存储帐户启用了以下一个或多个功能，则也可能遇到文件或数据不一致：
上次同步时间
“上次同步时间”属性指示最近一次将主要区域中的数据写入次要区域的时间。 对于具有分层命名空间的帐户，相同的“上次同步时间”属性也适用于由分层命名空间（包括访问控制列表 ACL）管理的元数据。 在上次同步时间之前写入的所有数据和元数据可用于辅助区域。 相比之下，上次同步时间之后写入的数据和元数据可能尚未复制到辅助区域，并且可能会丢失。 在服务中断期间，使用此属性可估计启动帐户故障转移时可能会造成的数据丢失量。
最佳做法是将应用程序设计为可以使用“上次同步时间”来评估预期数据丢失。 例如，通过记录所有写入操作，可以将上次写入操作的时间与上次同步时间进行比较。 使用此方法，你能够确定哪些写入尚未同步到辅助区域，并且存在丢失的危险。
如需详细了解如何检查“上次同步时间”属性，请参阅检查存储帐户的“上次同步时间”属性。
Azure Data Lake Storage 的文件一致性
启用了分层命名空间 (Azure Data Lake Storage) 的存储帐户复制在文件级别进行。 由于复制在此级别发生，因此主要区域中的中断可能会阻止容器或目录中的一些文件成功复制到次要区域。 无法保证在存储帐户故障转移后容器或目录中所有文件的一致性。
更改源和 blob 数据不一致
对启用了更改源的存储帐户进行客户管理的（计划外）故障转移可能会导致更改源日志与 blob 数据和/或元数据之间不一致。 这种不一致可能是主要区域和次要区域之间更改日志更新和数据复制的异步性质造成的。 可以通过采取以下预防措施来避免不一致：
- 确保所有日志记录都刷新到日志文件。
- 确保所有存储数据都从主区域复制到了次要区域。
有关更改源的详细信息，请参阅更改源的工作原理。
请记住，其他存储帐户功能也需要启用更改源。 这些功能包括 Azure Blob 存储的运行备份、对象复制和块 Blob 的时间点还原。
时间点还原不一致
包含块 blob 的常规用途 v2 标准层存储帐户支持客户管理的故障转移。 然而，对存储帐户执行客户管理的故障转移会为该帐户重置尽可能早的还原点。 块 blob 的时间点还原数据仅在故障转移完成时间之前保持一致。 因此，只能将块 blob 还原到不早于故障转移完成时间的时间点。 可以在 Azure 门户中存储帐户的“冗余”选项卡中查看故障转移完成时间。
故障转移的时间和成本
客户管理的故障转移在启动后完成所用的时间可能会有所不同，但通常不到一小时。
启动客户管理的计划外故障转移会自动将存储帐户转换为新主要区域中的本地冗余存储 (LRS)，并删除原始主要区域中的存储帐户。
可以为帐户重新启用异地冗余存储 (GRS) 或读取访问异地冗余存储 (RA-GRS)，但将数据重新复制到新的次要区域会产生费用。 此外外，需要先将任何已存档 blob 解除冻结到联机层，然后才能将帐户配置为使用异地冗余。 这种解除冻结也会产生额外的费用。 有关定价的详细信息，请参阅：
在你为存储帐户重新启用 GRS 后，Azure 便会开始将帐户中的数据复制到新的次要区域。 完成复制所需的时间取决于多个因素。 这些因素包括：
- 存储帐户中对象的数量和大小。 复制许多小型对象所需的时间可能比复制较少的大对象要长。
- 可用于后台复制的资源，例如 CPU、内存、磁盘和 WAN 容量。 实时流量优先于异地复制。
- 每个 Blob 的快照数（如果适用）。
- 如果存储帐户包含表，则需要数据分区策略。 复制过程不能扩展到超过所用分区键数量的地步。
支持的存储帐户类型
所有异地冗余套餐都支持 Azure 托管的故障转移。 此外，某些帐户类型支持客户管理的帐户故障转移，如下表所示：
| 故障转移类型 | GRS/RA-GRS | GZRS/RA-GZRS |
|---|---|---|
| 客户管理的（计划外）故障转移 | 常规用途 v2 帐户 常规用途 v1 帐户 旧 Blob 存储帐户 |
常规用途 v2 帐户 |
| Azure 托管的故障转移 | 所有帐户类型 | 常规用途 v2 帐户 |
经典存储帐户
重要
只有使用 Azure 资源管理器 (ARM) 部署模型部署的存储账户才支持客户管理的故障转移。 不支持 Azure Service Manager (ASM) 部署模型（也称为经典）。 若要使经典存储帐户符合客户管理的帐户故障转移的条件，必须先将其迁移到 ARM 模型。 必须可以访问存储帐户来执行升级，因此主要区域当前不能处于失败状态。
在影响主要区域的灾难期间，Azure 将管理经典存储帐户的故障转移。 有关详细信息，请参阅 Azure 托管的故障转移。
分层命名空间 (HNS)
启用了分层命名空间 (Azure Data Lake Storage Gen2) 的帐户尚不支持客户管理的帐户故障转移。 若要了解详细信息，请参阅 Azure Data Lake Storage Gen2 中提供的 Blob 存储功能。
不支持的功能和服务
客户管理的故障转移不支持以下功能和服务：
- Azure 文件同步不支持客户管理的帐户故障转移。 不应对用作 Azure 文件同步云终结点的存储帐户进行故障转移。 故障转移会中断文件同步，并可能导致新分层文件意外数据丢失。 有关详细信息，请参阅使用 Azure 文件同步进行灾难恢复的最佳做法。
- 无法对包含高级块 Blob 的存储帐户执行故障转移。 支持高级块 Blob 的存储帐户暂不支持异地冗余。
- 对象复制策略中的源帐户或目标帐户均不支持客户管理的故障转移。
- 若要对启用了 SSH 文件传输协议 (SFTP) 的帐户执行故障转移，必须先禁用该帐户的 SFTP。 如果要在故障转移完成后恢复使用 SFTP，只需重新启用它。
- 存储帐户故障转移不支持网络文件系统 (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) 关闭时临时磁盘中存储的数据丢失。 Azure 建议使用以下特定于 Azure 中虚拟机的高可用性和灾难恢复指南。
Azure 非托管磁盘
非托管磁盘在 Azure 存储中存储为页 blob。 如果 VM 在 Azure 中运行，任何附加到 VM 的非托管磁盘都会被租用。 如果 Blob 上有租用，便无法继续帐户故障转移。 必须先关闭磁盘盘，然后才能在包含附加到 Azure VM 的非托管磁盘的帐户上启动故障转移。 因此，Azure 建议的最佳做法包括将任何非托管磁盘转换为托管磁盘。
要对包含非托管磁盘的帐户执行故障转移，请执行以下步骤：
- 开始前，先记下任何非托管磁盘的名称、逻辑单元号 (LUN) 和要将其附加到的 VM。 此操作可便于在故障转移完成后更轻松地重新附加磁盘。
- 关闭 VM。
- 删除 VM，但保留非托管磁盘的虚拟硬盘 (VHD) 文件。 记下 VM 删除时间。
- 等待上次同步时间更新，并确保它晚于删除 VM 的时间。 此步骤可确保在发生故障转移时使用 VHD 文件完全更新次要终结点，并且 VM 可在新的主要区域中正常运行。
- 启动帐户故障转移。
- 等到帐户故障转移完成，且次要区域成为新的主要区域。
- 在新的主要区域中创建 VM，并重新附加 VHD。
- 启动新 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 服务的运行状况及状态。
Azure 还建议将应用程序设计为可以应对可能出现的写入故障。 应用程序应公开写入故障，以提醒你主要区域可能存在服务中断。