客户管理的计划内故障转移在灾难和恢复规划和测试、预期的大规模灾难的主动补救以及非存储相关中断等场景中很有用。
在计划的故障转移过程中，存储帐户的主要区域和次要区域将会交换。 原来的主要区域被降级后成为新的次要区域，而原来的次要区域被提升后成为新的主要区域。 存储帐户必须同时在主要区域和次要区域中可用，然后才能启动计划的故障转移。
本文介绍在过程中的每个阶段，客户管理的计划的故障转移和故障回复会发生的情况。 要了解由于意外存储终结点中断而进行故障转移的工作原理，请参阅客户管理的（计划外）故障转移的工作原理。
重要
用户反馈正在整合到客户管理的计划故障切换（预览版）中，该功能在所有地区暂时不可用。 完成后，将发布更新的文档，以反映该功能可用的区域。
计划的故障转移和故障回复期间的冗余管理
提示
要详细了解客户管理的故障转移和故障回复过程中的各种冗余状态，请参阅 Azure 存储冗余，以了解每种冗余状态的定义。
在计划内故障转移过程中，主要区域的存储服务终结点将会变为只读，而剩余的更新完成复制到次要区域。 接下来，将切换所有存储服务终结点的域名服务 (DNS) 条目。 存储帐户的辅助终结点将成为新的主终结点，原始主终结点将会成为新的辅助终结点。 尽管切换了主要区域和次要区域，但每个区域中的数据复制将保持不变。
计划的故障回复过程本质上与计划的故障转移过程相同，但有一个例外。 在计划故障回复期间，Azure 会存储存储帐户的原始冗余配置，并在故障回复时将其还原到其原始状态。 例如，如果存储帐户最初配置为 GZRS，则在故障回复后，存储帐户是 GZRS。
注意
与客户管理的（计划外）故障转移不同，在计划内故障转移期间，必须先完成从主要区域到次要区域的复制，然后再将终结点的 DNS 条目更改为新的次要区域。 因此，只要主要区域和次要区域在整个过程中可用，故障转移或故障回复期间就不会丢失数据。
如何启动故障转移
若要了解如何启动故障转移，请参阅启动帐户故障转移。
计划的故障转移和故障回复过程
下图显示了客户管理的计划内存储帐户故障转移和故障回复期间发生的情况。
正常情况下，客户端通过存储服务终结点将数据写入主要区域中的存储帐户 (1)。 然后将数据从主要区域异步复制到次要区域 (2)。 下图显示了配置为 GRS 的存储帐户的正常状态：
计划的故障转移过程 (GRS/RA-GRS)
通过启动向次要区域进行存储帐户故障转移来开始灾难恢复测试。 下面介绍了计划内故障转移过程中的步骤，后续图像提供了说明：
主要区域和次要区域的存储帐户将暂时失去读取和写入访问权限。
完成将主要区域中的所有数据复制到次要区域。
次要区域中存储服务终结点的 DNS 条目将会得到提升，并成为存储帐户的新主要终结点。
故障转移通常需要大约一小时才能完成。
故障转移完成后，原始主要区域将成为新的次要区域 (1)，而原始次要区域将成为新的主要区域 (2)。 Blob、表、队列和文件的存储服务终结点 URI 将保持不变，但其 DNS 条目会更改为指向新的次要区域 (3)。 用户可以继续将数据写入到新主要区域中的存储帐户，然后将数据异步复制到新的次要区域 (4)，如下图所示：
在处于故障转移状态时，请执行灾难恢复测试。
计划的故障回复过程 (GRS/RA-GRS)
测试完成后，执行另一个故障转移以故障回复到原始主要区域。 在如下图所示的故障转移过程中：
主区域和次要区域中的存储帐户将暂时无法进行读取和写入访问。
所有数据完成从当前主要区域到当前次要区域的复制。
存储服务终结点的 DNS 条目将更改为重新指向执行初始故障转移前的主要区域。
故障回复通常需要大约一小时才能完成。
完成故障回复后，存储帐户将还原到其原始冗余配置。 在像故障转移前一样继续向原始次要区域 (2) 复制时，用户可以继续将数据写入原始主要区域 (1) 中的存储帐户：
