客户管理的存储帐户故障转移如何运作
如果主要区域的存储服务终结点不可用，则客户管理的 Azure 存储帐户的故障转移可以将整个异地冗余存储帐户故障转移到次要区域。 在故障转移期间，原始次要区域将成为新的主要区域，blob、表、队列和文件的所有存储服务终结点将重定向到新的主要区域。 解决存储服务终结点中断问题后，可以执行另一个故障转移操作，从而故障回复到原始主要区域。
本文介绍在客户管理的存储帐户故障转移和故障回复过程中每个阶段会发生的情况。
重要
具有分层命名空间 (Azure Data Lake Storage Gen2) 的帐户尚不支持客户管理的帐户故障转移。
故障转移和故障回复期间的冗余管理
提示
若要详细了解存储帐户故障转移和故障回复过程中的各种冗余状态，请参阅 Azure 存储冗余了解每种冗余状态的定义。
当存储帐户配置为 GRS 或 RA-GRS 冗余时，数据会在主要区域和次要区域 (LRS) 内本地复制 3 次。 当存储帐户配置为 GZRS 或 RA-GZRS 复制时，主要区域 (ZRS) 中的数据是区域冗余的，并在次要区域 (LRS) 内本地复制三次。 如果帐户配置为读取访问 (RA)，则只要该区域的存储服务终结点可用，就可以从次要区域读取数据。
在客户管理的故障转移过程中，存储服务终结点的 DNS 条目会更改，使次要区域的终结点成为存储帐户新的主终结点。 故障转移后，将删除原始主要区域中存储帐户的副本，并且存储帐户将继续在原始次要区域（新的主要区域）内本地复制三次。 此时，存储帐户将变为本地冗余 (LRS)。
原始和当前冗余配置存储在存储帐户的属性中，以便在故障回复时最终返回到原始配置。
若要在故障转移后重新获得异地冗余，需要将帐户重新配置为 GRS。 （GZRS 不是故障转移后的选项，因为新的主要区域将在故障转移后成为 LRS）。 为异地冗余重新配置帐户后，Azure 会立即开始将数据从新的主要区域复制到新的次要区域。 如果配置存储帐户以对次要区域进行读取访问 (RA)，则可以进行该访问，但从主要区域进行复制可能需要一些时间才能使次要区域保持最新状态。
警告
为异地冗余重新配置帐户后，可能需要花费大量时间才能将新的主要区域中的现有数据完全复制到新的次要区域。
为了避免大量数据丢失，请在故障回复前检查“上次同步时间”属性的值。 若要评估可能的数据丢失，请比较上次同步时间与数据上次写入新的主要区域时间。
故障回复过程实质上与故障转移过程相同，但 Azure 在故障转移之前将复制配置还原到其原始状态（复制配置，而不是数据）。 因此，如果存储帐户最初配置为 GZRS，故障回复后的主要区域将成为 ZRS。
故障回复后，可以再次将存储帐户配置为异地冗余。 如果原始主要区域配置了 LRS，可以将其配置为 GRS 或 RA-GRS。 如果原始主要区域配置为 ZRS，则可以将其配置为 GZRS 或 RA-GZRS。 有关其他选项，请参阅更改存储帐户的复制方式。
如何启动故障转移
若要了解如何启动故障转移，请参阅启动存储帐户故障转移。
故障转移和故障回复过程
本节总结了客户管理的故障转移的故障转移过程。
故障转移转换摘要
客户管理的故障转移后：
- 次要区域将成为新的主要区域
- 删除原始主要区域中的数据副本
- 存储帐户转换为 LRS
- 异地冗余丢失
下表汇总了客户管理的故障转移和故障回复的每个阶段生成的冗余配置：
| 原始 配置 |
之后 故障转移 |
重新启用后 异地冗余 |
之后 故障回复 |
重新启用后 异地冗余 |
|---|---|---|---|---|
| GRS | LRS | GRS 1 | LRS | GRS 1 |
| GZRS | LRS | GRS 1 | ZRS | GZRS 1 |
1 异地冗余在客户管理的故障转移期间丢失，必须手动重新配置。
故障转移转换详细信息
下图显示了客户管理的故障转移期间以及为异地冗余配置的存储帐户故障回复期间期间发生的情况。 GZRS 和 RA-GZRS 的转换细节与 GRS 和 RA-GRS 略有不同。
正常操作 (GRS/RA-GRS)
正常情况下，客户端通过存储服务端点将数据写入主要区域中的存储帐户 (1)。 然后将数据从主要区域异步复制到次要区域 (2)。 下图显示在主要终结点可用时配置为 GRS 的存储帐户的正常状态：
主要区域中的存储服务终结点不可用 (GRS/RA-GRS)
如果主要存储服务终结点因任何原因而不可用 (1)，则客户端将无法再向存储帐户写入数据。 根据中断的根本原因，可能无法再正常复制到次要区域 (2)，因此预期会丢失一些数据。 下图展示了主要终结点不可用、但尚未执行恢复时的情况：
故障转移过程 (GRS/RA-GRS)
若要还原对数据的写入访问权限，可以启动故障转移。 Blob、表、队列和文件的存储服务终结点 URI 保持不变，但其 DNS 条目更改为指向次要区域 (1)，如下图所示：
客户管理的故障转移通常需要大约一小时才能完成。
故障转移完成后，原始次要副本将成为新的主要副本 (1)，原始主要副本中存储帐户的副本将被删除 (2)。 存储帐户在新的主要区域中配置为 LRS，并且不再具有异地冗余。 用户可以继续将数据写入存储帐户 (3)，如下图所示：
若要继续复制到新的次要区域，请将帐户重新配置为使用异地冗余。
重要
请记住，通过转换本地冗余存储帐户来使用异地冗余会产生成本和时间。 有关详细信息，请参阅故障转移的时间和成本。
将帐户重新配置为 GRS 后，Azure 将开始以异步方式将数据复制到新的次要区域 (1)，如下图所示：
在解决导致原始中断的问题之前，对新次要区域的读取访问权限将不再可用。
故障回复过程 (GRS/RA-GRS)
警告
为异地冗余重新配置帐户后，可能需要花费大量时间才能将新的主要区域中的数据完全复制到新的次要区域。
为了避免大量数据丢失，请在故障回复前检查“上次同步时间”属性的值。 若要评估可能的数据丢失，请比较上次同步时间与数据上次写入新的主要区域时间。
解决导致原始中断的问题后，可以启动另一个故障转移以故障回复到原始主要区域，从而导致以下结果：
- 当前主要区域变为只读。
- 使用客户启动的故障转移和故障回复，将不允许数据在故障回复过程中完成复制到次要区域的操作。 因此，请务必在故障回复前检查“上次同步时间”属性的值。
- 存储服务终结点的 DNS 条目会更改，使次要区域的终结点成为存储帐户新的主要终结点。
故障回复完成后，原始主要区域将重新成为当前主要区域 (1)，原始次要区域中存储帐户的副本将被删除 (2)。 存储帐户在主要区域中配置为本地冗余，并且不再具有异地冗余。 用户可以继续将数据写入存储帐户 (3)，如下图所示：
若要继续复制到新的原始次要区域，请将帐户重新配置为使用异地冗余。
重要
请记住，通过转换本地冗余存储帐户来使用异地冗余会产生成本和时间。 有关详细信息，请参阅故障转移的时间和成本。
将帐户重新配置为 GRS 后，将继续复制到原始次要区域，如下图所示：
