Azure 致力于确保 Azure 服务一直可用。 意外服务中断仍可能会发生，因此应制定灾难恢复 (DR) 计划来处理区域服务中断。 灾难恢复计划的一个重要部分是准备在主终结点不可用时切换到辅助终结点。 本文介绍灾难恢复 (DR) 和存储帐户故障转移所涉及的概念和过程。
Azure 文件同步故障转移
如果使用的是Azure 文件同步，请先阅读本部分。 如果不使用Azure 文件同步，则此部分不适用。
如果存储同步服务也进行故障转移，则 Azure 文件同步仅支持存储帐户故障转移。 这是因为 Azure 文件同步要求存储帐户和存储同步服务位于同一 Azure 区域。 如果仅对存储帐户进行故障转移，则在将存储同步服务故障转移到次要区域之前，同步和云分层操作将失败。
如果要故障转移包含 Azure 文件同步中用作云终结点的 Azure 文件共享的存储帐户，请参阅 Azure 文件同步灾难恢复最佳做法 和 Azure 文件同步服务器恢复。
存储帐户故障转移完成后（例如，从中国东部 2 到中国北部 2），Azure 文件同步不会自动识别新的存储帐户位置。 控制平面保留在原始 ARM 区域中注册，而只有数据平面迁移到新区域。
按照下列步骤完成 Azure 文件同步故障转移过程：
- 请联系Azure支持，请求Azure 文件同步使用新的存储帐户位置。
- Azure 文件同步 更新后，它会将服务器流量（数据平面）路由到新区域。 存储同步服务控制平面可能仍反映Azure门户中的原始区域。
Azure门户仅显示存储同步的控制平面位置。它不公开数据平面终结点。 可以通过使用 Azure 支持来验证服务器是否指向正确的区域。
由客户管理的计划故障转移
您可以在多种场景中使用客户管理的计划故障切换，包括计划中的灾难恢复测试、对大规模灾难的主动处理，或从非存储相关故障中恢复。
在计划的故障转移过程中，将交换主要区域和次要区域。 原始主要区域将降级，成为新的次要区域。 同时，原始次要区域将升级，成为新的主要区域。 故障转移完成后，用户可以继续访问新主要区域中的数据，管理员可以验证其灾难恢复计划。 存储帐户必须同时在主要区域和次要区域中可用，然后才能启动计划的故障转移。
只要主要区域和次要区域在整个过程中可用，计划的故障转移和故障回复过程中应不会丢失数据。 有关详细信息，请参阅预测数据丢失和不一致部分。
要了解这种类型的故障转移对用户和应用程序的影响，了解计划的故障转移和故障回复过程每个步骤中发生的情况会很有帮助。 有关此过程工作原理的详细信息，请参阅客户管理的（计划的）故障转移的工作原理。
重要
支持 GRS/GZRS 的所有公共区域都提供由客户管理的计划性故障转移。
若要确定某个区域是否支持 GZRS，请参阅 Azure 区域列表。 为了支持 GZRS，区域必须支持可用性区域并具有配对区域。
恢复指标和成本
若要制定有效的灾难恢复策略，组织必须了解：
- 为中断设定的可接受数据丢失量（恢复点目标 或 RPO）
- 需要多长时间才能恢复业务功能和数据（恢复时间目标 (RTO)）
DR 的成本通常会随着 RPO/RTO 降低或为零而增加。 需要在灾难发生后几秒钟内启动并运行且无法承受任何数据丢失的公司将支付较高的灾难恢复费用，而 RPO/RTO 数值较高的公司将支付较少的费用。 Azure 提供的解决方案可以符合各种 RPO 和 RTO 要求。
选择正确的冗余选项
Azure 文件存储提供了不同的冗余选项，以保护数据免受计划内和计划外事件的影响，这些事件包括暂时性硬件故障、网络和停电以及自然灾害。 所有 Azure 文件共享都可以使用本地冗余 (LRS) 或区域冗余存储 (ZRS)。 有关详细信息，请参阅 Azure 文件存储冗余。
Azure 文件存储支持配置了异地冗余存储 (GRS) 和异地区域冗余存储 (GZRS) 的 HDD 文件共享进行帐户故障转移，以防止区域性服务中断。 通过帐户故障转移，可以在主终结点不可用时为存储帐户启动故障转移过程。 故障转移将辅助终结点更新为，存储帐户的主终结点。 故障切换完成后，客户端可以开始写入新的主端点。
GRS 和 GZRS 仍存在数据丢失的风险，因为数据以异步方式复制到次要区域，这意味着在将写入主要区域的操作复制到次要区域之前存在延迟。 在服务中断的情况下，对主终结点执行、但尚未复制到辅助终结点的写入操作将会丢失。 这意味着如果主要区域不可恢复，影响主要区域的故障可能会导致数据丢失。 最近写入主要区域与上次写入次要区域之间的间隔是 RPO。 Azure 文件存储的 RPO 通常为 15 分钟或更短，但目前没有 SLA 规定将数据复制到次要区域所需的时间。
重要
SSD 文件共享不支持 GRS/GZRS。 但是，可以在两个 Azure 文件共享之间同步以实现地理冗余。
旨在实现高可用性
从一开始就设计高可用性应用。 请参阅这些 Azure 资源，了解如何设计应用和灾难恢复规划：
- 设计适用于 Azure 的可复原应用程序：概述了在 Azure 中生成高可用性应用程序的关键概念。
- 复原能力清单：用于验证应用程序是否实现高可用性最佳设计做法的清单。
- 使用异地冗余设计高可用性应用程序：利用 SMB 文件共享的地理冗余存储优势构建应用程序的设计指南。
同时，设计你的应用程序时要为写入失败的可能性做好准备。 应用程序应公开写入故障，以提醒你主要区域可能存在服务中断。
最佳做法是，将应用程序设计为通过检查上次同步时间属性来评估预期数据丢失。 例如，若要记录所有写入操作，可以比较上次写入操作时间与上次同步时间，以确定哪些写入操作尚未同步到次要区域。
跟踪服务中断
你可以订阅 Azure 服务运行状况仪表板，以跟踪 Azure 文件存储和其他 Azure 服务的运行状况和状态。
了解帐户故障转移过程
当你使用客户管理的账户故障切换时，如果主区域因任何原因不可用，你可以将整个存储账户切换到备用区域。 如果你强制故障转移到次要区域，客户端可以在故障转移完成后开始向辅助终结点写入数据。 故障转移通常需要大约一小时才能完成。 在启动账户故障转移前，尽量暂停你的工作负载。
若要详细了解如何启动帐户故障转移，请参阅启动帐户故障转移。
帐户故障转移的工作原理
在正常情况下，客户端将数据写入主区域的存储账户，系统异步将数据复制到次区域。
如果主端点因任何原因变得不可用，客户端就无法写入存储账户。 然后你可以启动账户切换。 此操作更新 Azure 存储 提供的 DNS 条目，使二级端点成为你存储账户的新主端点。
在 DNS 条目更新并将请求定向到新的主端点后，地理冗余账户的写权限会恢复。 现有的存储服务端点在故障转移后保持不变。 故障转移时不会保留文件句柄和租用，因此客户端必须卸载并重新装载文件共享。
重要
故障切换完成后，存储帐户将配置为在新的主区域中实现本地冗余。 若要继续复制到新的辅助终结点，请将帐户重新配置为使用异地冗余。
请记住，通过转换本地冗余存储帐户来使用异地冗余会产生成本和时间。 有关详细信息，请参阅故障转移的时间和成本。
预判故障切换期间的数据丢失
注意
帐户故障转移通常涉及一些数据丢失。 请务必了解启动帐户故障转移的影响。
由于数据从主要区域异步写入到次要区域，因此，如果主要区域不可用，则最近的写入可能尚未复制到次要区域。
如果强制执行故障转移，主要区域中的所有数据就会在次要区域成为新的主要区域时丢失。 故障转移后，新的主要区域配置为本地冗余。
故障切换过程会保留所有已复制到辅助端的数据。 然而，任何写入主副本但未同时复制到次副本的数据都会永久丢失。
检查“上次同步时间”属性
“上次同步时间 (LST)”属性表示，最近一次保证已将主要区域中的数据写入次要区域的时间。 上次同步时间之前写入的所有数据都已复制到次要区域中，而在上次同步时间之后写入的数据则可能尚未写入次要区域并发生丢失。 在发生服务中断时，使用此属性可估计启动帐户故障转移可能会造成的数据丢失量。
为了确保文件共享在故障切换发生时处于一致状态，主区域每15分钟创建一个系统快照并复制到次要区域。 当次要区域发生故障转移时，共享状态将基于次要区域中的最新系统快照。 如果主区域发生故障，次级区域很可能落后于主区域，因为所有写入主区域的记录尚未复制到次级区域。 由于地理延迟（区域间复制延迟）或其他问题，次级区域的最新系统快照可能超过15分钟。
在 LST 之前写入到主要区域的所有写入操作已成功复制到次要区域，这意味着，可以从次要区域读取这些操作。 在上次同步时间之后写入主要区域的任何写入操作可能已复制到次要区域，也可能未复制到次要区域，这意味着可能不适合对它们执行读取操作。
你可以使用 Azure PowerShell、Azure CLI 或客户端库查询“上次同步时间”属性的值。 “上次同步时间”属性是一个 GMT 日期/时间值。 有关详细信息，请参阅检查存储帐户的“上次同步时间”属性。
谨慎故障回复到原始主要区域
如前所述，从主要区域故障转移到次要区域后，存储帐户被配置为在新的主要区域中本地冗余。 然后，可以在新的主要区域配置帐户以实现异地冗余。 如果帐户在故障转移完成后配置为使用异地冗余，新的主要区域就会立即开始将数据复制到新的次要区域（在原始故障转移发生前为主要区域）。 但是，将新的主要区域中的现有数据完全复制到新的次要区域可能需要一段时间才能完成。
为存储帐户重新配置异地冗余后，可以启动从新的主要区域故障回复到新的次要区域。 在这种情况下，故障转移前的原始主要区域再次成为主要区域，并根据原始主要配置是 GRS 还是 GZRS 配置为本地冗余或区域冗余。 在故障恢复期间，故障转移后主要区域（原始次要区域）中的所有数据都将丢失。 如果在故障回复前存储帐户中的大部分数据都尚未复制到新的次要区域，可能会丢失大量数据。
为了避免重大数据丢失，请在恢复到原状态前检查“上次同步时间”属性的值。 若要评估预期的数据丢失，请比较上次同步时间与数据上次写入新的主节点的时间。
故障回复操作后，可再次将新的主要区域配置为异地冗余。 如果原始主要区域配置了 LRS，可以将其配置为 GRS。 如果原始主要区域配置为 ZRS，则可以将其配置为 GZRS。 有关其他选项，请参阅 更改存储帐户的复制方式。
启动帐户故障转移
可以从 Azure 门户、PowerShell、Azure CLI 或 Azure 存储资源提供程序 API 启动帐户故障转移。 若要详细了解如何启动故障转移，请参阅启动帐户故障转移。
计划内异地故障转移的最佳做法
在启动计划内故障转移之前，请确保完全停止针对 Azure 文件共享的所有应用程序和客户端活动。 故障转移期间的活动读取或写入操作可能会导致文件共享在故障转移完成后进入不一致的状态。
在开始故障转移之前：
- 关闭访问 Azure 文件共享的所有应用程序和客户端。
- 确保存储帐户中的任何文件共享上没有活动 I/O（读取或写入）。
- 验证是否有打开的文件句柄存在于文件共享上。
- 使用 Get-AzStorageFileHandle Azure PowerShell cmdlet 列出活动文件句柄和连接的客户端 IP 地址。
- 在启动存储帐户的故障转移操作之前，请关闭结果中显示的所有客户端 IP 地址。
仅在所有文件共享处于空闲状态且没有活动客户端连接后继续执行计划内故障转移。
Azure 托管的故障转移
在由于重大灾难而导致区域丢失的极端情况下，Azure 可能会启动区域故障转移。 在此情况下，你不需要采取任何操作。 在 Azure 托管的故障转移完成之前，你对存储帐户不拥有写入访问权限。