通过

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

Azure 存储冗余

  • 项目

Azure 存储会始终存储数据的多个副本，以保护它免受计划内和计划外事件的影响。 这些事件的示例包括暂时性硬件故障、网络中断或断电，以及大范围的自然灾害。 冗余可确保即使遇到故障，存储帐户也能达到其可用性和持久性目标。

在确定最适合自己方案的冗余选项时，请考虑如何在较低成本与较高可用性之间做出取舍。 可帮助你确定应选择哪种冗余选项的因素包括：

  • 如何在主要区域中复制数据。
  • 你的数据是否从一个主要区域复制到地理上较远的另一个区域，以防范区域性灾难（异地复制）。
  • 在主要区域的中断期间，你的应用程序是否要求对次要区域中复制的数据具有读取访问权限（使用读取访问权限进行异地复制）。

注意

本文所述的功能和区域可用性现在也可用于具有分层命名空间的帐户（Azure Blob 存储）。

构成 Azure 存储的服务通过称作“存储帐户”的通用 Azure 资源进行管理。 存储帐户表示一个共享存储池，可用于部署 Blob 容器（Blob 存储）、文件共享（Azure 文件存储）、表（表存储）或队列（队列存储）等存储资源。 有关 Azure 存储帐户的详细信息，请参阅存储帐户概述。

存储帐户的冗余设置由该帐户公开的所有存储服务共享。 部署在同一存储帐户中的所有存储资源具有相同的冗余设置。 如果不同类型的资源具有不同的冗余要求，可考虑将这些资源隔离在单独的存储帐户中。

主要区域中的冗余

Azure 存储帐户中的数据在主要区域中始终复制三次。 Azure 存储提供了两个有关如何在主要区域中复制数据的选项：

  • 本地冗余存储 (LRS) 在主要区域中的单个物理位置同步复制数据三次。 LRS 是成本最低的复制选项，但不建议对需要高可用性或持续性的应用程序使用此选项。
  • 区域冗余存储 (ZRS) 跨主要区域中的三个 Azure 可用性区域同步复制数据。 对于需要高可用性的应用程序，Microsoft 建议在主要区域中使用 ZRS，并复制到次要区域。

注意

Microsoft 建议在 Azure Data Lake Storage 的主要区域中使用 ZRS。

本地冗余存储

本地冗余存储 (LRS) 在主要区域中的单个数据中心内复制存储帐户三次。 LRS 可在一年中提供至少 99.999999999%（11 个 9）的对象持久性。

与其他选项相比，LRS 是成本最低的冗余选项，但提供的持久性也最低。 LRS 可以保护数据，使其不受服务器机架和驱动器故障影响。 但如果数据中心内发生火灾或洪水等灾难，则使用 LRS 的存储帐户的所有副本可能会丢失或无法恢复。 若要缓解此风险，Microsoft 建议使用区域冗余存储 (ZRS)、异地冗余存储 (GRS) 或异地区域冗余存储 (GZRS)。

对使用 LRS 的存储帐户的写入请求是同步发生的。 只有将数据写入到所有三个副本后，写入操作才会成功返回。

下图显示了如何使用 LRS 在单个数据中心内复制数据：

此图显示了如何使用 LRS 在单个数据中心内复制数据

对于以下场景，LRS 是不错的选项：

  • 如果应用程序存储了发生数据丢失时可轻松重构的数据，则可以选择 LRS。
  • 如果由于数据治理要求，你的应用程序被限制为只能在一个区域内复制数据，请考虑选择 LRS。 在某些情况下，要在其中异地复制数据的配对区域可位于另一个区域。 有关配对区域的详细信息，请参阅 Azure 区域。
  • 如果方案使用的是 Azure 非托管磁盘，请考虑使用 LRS。 虽然可以为使用 GRS 的 Azure 非托管磁盘创建存储帐户，但由于异步异地复制可能存在一致性问题，因此我们不建议这样做。

区域冗余存储

区域冗余存储 (ZRS) 在主要区域中的三个 Azure 可用性区域同步复制存储帐户。 每个可用性区域都是一个独立的物理位置，具有独立的电源、冷却系统和网络。 ZRS 在一年中提供至少 99.9999999999%（12 个 9）的存储资源持久性。

使用 ZRS 时，即使某个区域变得不可用，你的数据仍然可供读写操作访问。 如果某个区域变得不可用，则 Azure 会执行网络更新，例如域名系统 (DNS) 重新指向。 如果在完成更新之前访问数据，则这些更新可能会影响应用程序。 在设计用于 ZRS 的应用程序时，遵循暂时性故障的处理做法，包括结合指数退让实施重试策略。

会同步发生一个针对使用 ZRS 的存储帐户的写入请求。 写入操作仅在将数据写入三个可用性区域中的所有副本后才能成功返回。 如果某个可用性区暂时不可用，则将数据写入所有可用区域后操作会成功返回。

对于需要高可用性的方案，Microsoft 建议在主要区域中使用 ZRS。 还建议使用 ZRS 来限制将数据复制到特定的区域，以满足数据治理要求。

Microsoft 建议为 Azure 文件存储工作负载使用 ZRS。 如果某个区域不可用，不需要从连接的客户端重新装载 Azure 文件共享。

下图显示如何使用 ZRS 在主要区域中的可用性区域之间复制数据：

显示如何使用 ZRS 在主要区域中复制数据的关系图

如果数据变为暂时不可用，ZRS 可提供出色的性能、低延迟和数据复原能力。 但如果发生对多个区域产生永久影响的区域性灾难，ZRS 本身可能无法充分保护数据。 异地区域冗余存储 (GZRS) 会在主要区域中使用 ZRS，并将数据异地复制到次要区域。 GZRS 在许多区域中都可以使用，并被推荐用于防范区域灾难。

ZRS、GZRS 或 RA-GZRS 帐户目前不支持 Blob 存储的存档层。 非托管磁盘不支持 ZRS 或 GZRS。

有关哪些区域支持 ZRS 的详细信息，请参阅具有可用性区域的 Azure 区域。

标准存储帐户

所有 Azure 存储服务通过标准常规用途 v2 存储帐户支持 ZRS，这些服务包括：

  • Azure Blob 存储（热块 blob、冷块 blob、追加 blob、非磁盘页 blob）
  • Azure 文件存储（所有标准层：事务优化层、热层和冷层）
  • Azure 表存储
  • Azure 队列存储

有关支持标准帐户的区域冗余存储 (ZRS) 的区域列表，请参阅支持标准存储帐户的区域冗余存储 (ZRS) 的 Azure 区域。

高级块 blob 帐户

高级块 Blob 帐户支持 ZRS。 有关高级块 Blob 的详细信息，请参阅高级块 Blob 存储帐户。

有关支持高级块 Blob 帐户区域冗余存储 (ZRS) 的区域列表，请参阅支持高级块 Blob 帐户区域冗余存储 (ZRS) 的 Azure 区域。

高级文件共享帐户

高级文件共享（Azure 文件存储）通过 FileStorage 存储帐户类型支持 ZRS。

有关支持高级文件共享帐户区域冗余存储 (ZRS) 的区域列表，请参阅高级文件共享的 Azure 文件存储区域冗余存储。

托管磁盘

托管磁盘支持 ZRS，但存在以下限制。

有关支持托管磁盘区域冗余存储 (ZRS) 的区域的列表，请参阅区域可用性。

次要区域中的冗余

冗余选项有助于为应用程序提供高持久性。 在许多区域中，可以将存储帐户中的数据复制到距离主要区域数百英里的次要区域。 将存储帐户复制到次要区域可确保数据在完全区域中断或主要区域不可恢复的灾难期间能够持久保存。

创建存储帐户时，可以为帐户选择主要区域。 配对的次要区域是根据主要区域确定的且无法更改。 有关 Azure 支持的区域的详细信息，请参阅 Azure 区域。

Azure 存储提供了两种将数据复制到次要区域的选项：

  • 异地冗余存储 (GRS) 使用 LRS 在主区域中的单个物理位置同步复制数据三次。 然后，它将数据异步复制到次要区域中的单个物理位置。 在次要区域内，数据使用 LRS 同步复制了 3 次。
  • 异地区域冗余存储 (GZRS) 使用 ZRS 在主区域中的三个 Azure 可用性区域同步复制数据。 然后，它将数据异步复制到次要区域中的单个物理位置。 在次要区域内，数据使用 LRS 同步复制了 3 次。

注意

GRS 和 GZRS 之间的主要区别是在主要区域中复制数据的方式。 在次要区域内，始终使用 LRS 同步复制数据三次。 次要区域中的 LRS 保护你的数据免受硬件故障的影响。

使用 GRS 或 GZRS 时，无法对次要区域中的数据执行读取或写入访问，除非执行了到主要区域的故障转移。 若要对次要区域进行读取访问，请将存储帐户配置为使用读取访问异地冗余存储 (RA-GRS) 或读取访问异地区域冗余存储 (RA-GZRS)。 有关详细信息，请参阅对次要区域中数据的读取访问权限。

如果主要区域变得不可用，则可以选择故障转移到次要区域。 故障转移操作完成后，次要区域将成为主要区域，并且你可以读取和写入数据。 有关灾难恢复以及如何故障转移到次要区域的详细信息，请参阅灾难恢复和存储帐户故障转移。

重要

由于数据以异步方式复制到次要区域，因此如果无法恢复主要区域，则影响主要区域的故障可能会导致数据丢失。 最近对主要区域的写入与最近对次要区域的写入之间的时间间隔称为恢复点目标 (RPO)。 RPO 指示可以将数据恢复到的时间点。 Azure 存储平台的 RPO 通常小于 15 分钟，但目前没有有关将数据复制到次要区域所用的时长的 SLA。

异地冗余存储

异地冗余存储 (GRS) 使用 LRS 在主要区域中的单个物理位置内同步复制数据三次。 然后，它将数据异步复制到距离主要区域数百英里以外的次要区域中的单个物理位置。 GRS 在一年中提供至少 99.99999999999999%（16 个 9）的存储资源持久性。

首先会将写入操作提交到主要位置，并使用 LRS 复制该操作。 然后会以异步方式将更新复制到次要区域。 数据被写入次要位置后，它还会使用 LRS 在该位置内进行复制。

下图显示了如何使用 GRS 或 RA-GRS 复制数据：

此图显示了如何使用 GRS 或 RA-GRS 复制数据

异地区域冗余存储

地域区域冗余存储 (GZRS) 将冗余跨可用性区域提供的高可用性与异地复制提供的区域中断保护相结合。 跨主要区域中的 3 个 Azure 可用性区域复制 GZRS 帐户中的数据。 此外，数据还会复制到次要地理区域，以防范区域性灾难。 Microsoft 建议对需要最大程度的一致性、耐用性和可用性、卓越性能和灾难恢复复原能力的应用程序使用 GZRS。

如果使用 GZRS 帐户，在可用性区域不可用或无法恢复的情况下，可以继续读取和写入数据。 另外，即使遇到完全区域中断或主要区域不可恢复的灾难，数据也能持久保存。 GZRS 在设计上可在一年内提供至少 99.99999999999999%（16 个 9）的对象持久性。

下图显示了如何使用 GZRS 或 RA-GZRS 复制数据：

此图显示了如何使用 GZRS 或 RA-GZRS 复制数据

只有标准常规用途 v2 存储帐户支持 GZRS。 所有 Azure 存储服务将支持 GZRS，包括：

  • Azure Blob 存储（热块 Blob 和冷块 Blob、非磁盘页 Blob）
  • Azure 文件存储（所有标准层：事务优化层、热层和冷层）
  • Azure 表存储
  • Azure 队列存储

有关支持异地区域冗余存储 (GZRS) 的区域列表，请参阅支持异地区域冗余存储 (GZRS) 的 Azure 区域。

对次要区域中数据的读取访问权限

异地冗余存储（使用 GRS 或 GZRS）将数据复制到次要区域中的另一个物理位置，以防止区域中断。 如果为 GRS 或 GZRS 配置了帐户，则除非发生故障转移，否则在主要区域中发生中断时，用户或应用程序将无法直接访问次要区域中的数据。 故障转移过程会更新 Azure 存储提供的 DNS 条目，以便次要区域中的存储服务终结点成为存储帐户的新主要终结点。 在故障转移过程中，数据不可访问。 在故障转移完成后，你便可以将数据读取和写入到新的主要区域。 有关详细信息，请参阅客户管理的存储帐户故障转移从中断中恢复的工作原理。

如果应用程序需要高可用性，则可配置存储帐户，以便对次要区域进行读取访问。 启用对次要区域的读取访问时，数据始终可供从次要区域读取（包括主要区域不可用的情况）。 读取访问异地冗余存储 (RA-GRS) 或读取访问异地区域冗余存储 (RA-GZRS) 配置允许对次要区域进行读取访问。

注意

Azure 文件存储不支持读取访问异地冗余存储 (RA-GRS) 或读取访问异地区域冗余存储 (RA-GZRS)。

设计应用程序以便能够对次要区域进行读取访问

如果存储帐户已配置为对次要区域进行读取访问，则你可以设计自己的应用程序，以便在主要区域出于任何原因而不可用时，能够无缝转换为从次要区域读取数据。

启用 RA-GRS 或 RA-GZRS 后，可以对次要区域进行读取访问。 通过此可用性，可以提前测试应用程序，以确保它在服务中断期间可以正确读取次要区域。 若要详细了解如何设计应用程序以利用异地冗余，请参阅使用异地冗余设计高度可用的应用程序。

启用对辅助数据库的读取访问权限后，可以从辅助终结点和主终结点读取应用程序。 次要终结点在帐户名的后面追加了后缀 -secondary。 例如，如果 Blob 存储的主要终结点是 myaccount.blob.core.windows.net，则次要终结点是 myaccount-secondary.blob.core.windows.net。 存储帐户的帐户访问密钥对于主要终结点和次要终结点是相同的。

制定数据丢失计划

由于数据是从主要区域异步复制到次要区域，因此，就写入操作来说，次要区域通常位于主要区域后面。 如果主要区域发生灾难，可能会丢失一些数据，并且目录或容器中的文件会不一致。 若要详细了解如何为潜在数据丢失做好计划，请参阅数据丢失和不一致。

冗余选项摘要

以下部分中的表格汇总了可用于 Azure 存储的冗余选项。

持久性和可用性参数

下表描述了每个冗余选项的关键参数：

参数 LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
给定一年内的对象持久性百分比 至少 99.999999999%（11 个 9） 至少 99.9999999999%（12 个 9） 至少 99.99999999999999%（16 个 9） 至少 99.99999999999999%（16 个 9）
读取请求的可用性 至少为 99.9%（冷访问层或存档访问层为 99%） 至少为 99.9%（冷访问层为 99%） 对于 GRS，至少为 99.9%（冷访问层或存档访问层为 99%）

对于 RA-GRS，至少为 99.99%（冷访问层或存档访问层为 99.9%）		 对于 GZRS，至少为 99.9%（冷访问层为 99%）

对于 RA-GZRS，至少为 99.99%（冷访问层为 99.9%）
写入请求的可用性 至少为 99.9%（冷访问层或存档访问层为 99%） 至少为 99.9%（冷访问层为 99%） 至少为 99.9%（冷访问层或存档访问层为 99%） 至少为 99.9%（冷访问层为 99%）
在单独的节点上维护的数据副本数 单个区域内的三个副本 跨单个区域内的不同可用性区域的三个副本 共六个副本，包括主要区域中的三个副本和次要区域中的三个副本 共六个副本，包括跨主要区域内的不同可用性区域的三个副本和次要区域中的三个本地冗余副本

有关详细信息，请参阅存储帐户的服务级别协议。

持久性和可用性（按中断方案）

下表指示数据是否持久且在给定方案中可用，具体取决于对存储帐户启用的冗余类型：

中断方案 LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
数据中心内的节点变为不可用 是 是 是 是
整个数据中心（区域性或非区域性）会不可用 否 是 是1 是
主要区域发生区域范围的服务中断 否 否 是1 是1
如果主区域变得不可用，可对次要区域进行读取访问 否 否 是（通过 RA-GRS） 是（通过 RA-GZRS）

1 如果主要区域变为不可用，则需要执行帐户故障转移来恢复写入可用性。 有关详细信息，请参阅灾难恢复和存储帐户故障转移。

支持的 Azure 存储服务

下表显示了每项 Azure 存储服务都支持的冗余选项。

服务 LRS ZRS GRS RA-GRS GZRS RA-GZRS
Blob 存储
（包括 Data Lake Storage）		 ✅ ✅ ✅ ✅ ✅ ✅
队列存储 ✅ ✅ ✅ ✅ ✅ ✅
表存储 ✅ ✅ ✅ ✅ ✅ ✅
Azure 文件 ✅1,2 ✅1,2 ✅1 ✅1
Azure 托管磁盘 ✅ ✅3
Azure 弹性 SAN ✅ ✅

1 LRS 和 ZRS 支持标准文件共享。 GRS 和 GZRS 支持标准文件共享，前提是其大小小于或等于 5 TiB。
2 LRS 和 ZRS 支持高级文件共享。
3 ZRS 托管磁盘存在某些限制。 有关详细信息，请参阅“托管磁盘的冗余选项”一文的限制部分。

支持的存储帐户类型

下表显示了每种类型的存储帐户支持的冗余选项。 有关存储帐户类型，请参阅存储帐户概述。

存储帐户类型 LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
推荐 标准常规用途 v2 (StorageV2)1

高级块 Blob (BlockBlobStorage)1

高级文件共享 (FileStorage)

高级页 Blob (StorageV2)		 标准常规用途 v2 (StorageV2)1

高级块 Blob (BlockBlobStorage)1

高级文件共享 (FileStorage)		 标准常规用途 v2 (StorageV2)1 标准常规用途 v2 (StorageV2)1
旧的 标准常规用途 v1 (Storage)

旧版 Blob (BlobStorage)		 空值 标准常规用途 v1 (Storage)

旧版 Blob (BlobStorage)		 空值

1 启用了分层命名空间的此类型的帐户还支持指定的冗余选项。

根据存储帐户的冗余选项，所有存储帐户的所有数据都从主帐户复制到辅助帐户。 复制的对象包括块 Blob、追加 Blob、页 Blob、队列、表和文件。

在异地复制期间，所有层（包括存档层）中的数据始终从主层复制到辅助层。 LRS、GRS 和 RA-GRS 帐户目前支持 Blob 存储的存档层，ZRS、GZRS 或 RA-GZRS 帐户不支持。 有关 Blob 层的详细信息，请参阅 Blob 数据的访问层。

非托管磁盘不支持 ZRS 或 GZRS。

有关每个冗余选项的定价信息，请参阅 Azure 存储定价。

注意

块 Blob 存储帐户在本地支持特定区域中的本地冗余存储 (LRS) 和区域冗余存储 (ZRS)。

数据完整性

Azure 存储使用循环冗余检查 (CRC) 定期验证存储的数据的完整性。 检测到的数据损坏会通过冗余数据进行修复。 Azure 存储还对所有网络流量计算校验和，以检测存储或检索数据时数据包损坏的情况。

另请参阅