注意
本文引用了 CentOS，这是一个生命周期结束 (EOL) 的 Linux 发行版。 请相应地考虑你的使用和规划。 有关详细信息，请参阅 CentOS 生命周期结束指南。
本文介绍解决方案的体系结构和设计注意事项，该解决方案提供了一种优化方法，用于对托管在 Azure Stack Hub 上的虚拟机 (VM) 中运行的工作负荷进行灾难恢复。
体系结构
下载此体系结构的 Visio 文件。
工作流
建议的解决方案的云组件包括以下服务：
托管作为此解决方案一部分的所有云资源的 Azure 订阅。
与 Azure 订阅关联的 Microsoft Entra ID 租户，它提供对 Microsoft Entra 安全主体的身份验证以授权访问 Azure 资源。
Azure 区域中最靠近托管 Azure Stack Hub 部署的本地数据中心的 Azure 恢复服务保管库。
注意
最靠近本地数据中心的 Azure 区域的选择特定于本文中包含的示例方案。 从灾难恢复的角度来看，最好选择远离托管生产环境的位置的 Azure 区域。 但是，此决定可能取决于其他因素，例如需要尽量减少区域数据馈送的延迟或满足数据驻留要求。
将本地数据中心连接到托管 Azure 恢复服务保管库的 Azure 区域的 Azure ExpressRoute 线路，配置了专用对等互连和 Microsoft 对等互连。 前者可确保在故障转移后满足延迟要求。 Azure 区域的目的是尽量减少在本地工作负荷和 Azure 中的故障转移站点之间复制更改所需的时间。
保存 Blob 的 Azure 存储帐户，其中包含通过复制受保护的 Azure Stack Hub VM 的操作系统和数据卷创建的 VHD 文件。 这些 VHD 文件用作故障转移后自动预配的 Azure VM 的托管磁盘的源。
托管灾难恢复环境的 Azure 虚拟网络。 其配置方式与托管生产工作负荷的 Azure Stack Hub 中的虚拟网络环境的配置方式相同，包括负载均衡器和网络安全组等组件。 此虚拟网络通常通过 ExpressRoute 连接来连接到 Azure Stack Hub 虚拟网络，以促进工作负荷级别的恢复。
注意
如果恢复点目标 (RPO) 要求不那么严格，则站点到站点 VPN 连接有时可能就足够了。
用于测试故障转移的隔离 Azure 虚拟网络，其配置方式与托管生产工作负荷的 Azure Stack Hub 中的虚拟网络环境的配置方式相同，包括负载均衡器和网络安全组等组件。
建议的解决方案的本地组件包括以下服务：
已连接的部署模型中的 Azure Stack Hub 集成系统。 该系统运行当前更新（自 9 月 20 日起为版本 2002），并位于客户的本地数据中心内。
Azure Stack Hub 订阅和一个虚拟网络或多个对等互连的虚拟网络，该虚拟网络托管此解决方案的所有本地 VM。
在 Windows Server 2016 或 2012 R2 Azure Hub Stack VM 上运行的 Azure Site Recovery 配置和进程服务器。 这些服务器管理与 Azure 恢复服务保管库的通信以及复制流量的路由、优化和加密。
注意
默认情况下，配置服务器托管单个进程服务器。 可以部署专用的进程服务器以容纳更大量的复制流量。
要保护的 Azure Stack Hub VM。 它们运行受支持的 Windows Server、CentOS 或 Ubuntu 操作系统版本。
在受保护 VM 上运行的 Site Recovery 移动服务（也称为“移动代理”）。 它跟踪对本地磁盘的更改，将这些更改记录到复制日志中，并将日志复制到进程服务器。 进程服务器将日志路由到目标 Azure 存储帐户。 这些日志用于为使用存储在指定 Azure 存储帐户中的 Blob 实现的托管磁盘创建恢复点。
组件
备选方法
本文中所述的建议解决方案并不是为基于 Azure Stack Hub VM 的工作负荷提供灾难恢复功能的唯一方法。 客户还有其他选项，包括：
故障转移到另一个 Azure Stack Hub 标记。 需要防止数据中心或站点服务中断的用户可以使用另一个 Azure Stack Hub 部署来实现灾难恢复预配。 通过主要位置和次要位置，用户可以在两个环境中采用主动/被动配置来部署应用程序。 对于不太关键的工作负荷，不妨使用次要位置中未使用的容量从备份中按需对应用程序进行还原。 还可以在另一个数据中心实现恢复站点，进而使用 Site Recovery 在 Azure 中预配恢复站点的副本。 有几个因素决定了将 Site Recovery 与用作故障转移站点的 Azure 结合使用是否是一个可行的解决方案。 这些因素包括政府法规、公司策略和延迟要求。
注意
从 2020 年 7 月开始，Site Recovery 不支持此方案，这意味着实现必须使用第三方或内部解决方案。
备份和还原。 备份应用程序和数据集后，如果因数据损坏、意外删除或本地服务中断而导致停机，你可以快速恢复。 对于基于 Azure Stack Hub VM 的应用程序，可以使用来宾内代理来保护应用程序数据、操作系统配置以及存储在卷上的数据。 使用来宾 OS 代理备份 VM 通常包括捕获操作系统配置、文件、文件夹、卷、应用程序二进制文件和应用程序数据。 从代理恢复应用程序需要重新创建 VM，然后安装操作系统和来宾代理。 此时，可以将数据还原到来宾 OS 中。
备份磁盘快照。 可以使用快照来捕获 Azure Stack Hub VM 配置和附加到已停止 VM 的磁盘。 此过程需要使用与 Azure Stack Hub API 集成的备份产品来捕获 VM 配置和创建磁盘快照。
注意
从 2020 年 7 月开始，不支持对正在运行的 VM 使用磁盘快照。 创建附加到运行中 VM 的磁盘的快照可能会降低性能，或者会影响 VM 中的操作系统或应用程序的可用性。
在同一数据中心使用外部备份解决方案备份和还原虚拟机，然后将备份复制到另一个位置。 这样，就可以将 Azure Stack Hub VM 还原到相同或不同的 Azure Stack Hub 实例，或者还原到 Azure。
方案详细信息
Azure Stack Hub 包括 self-healing 功能，可在涉及其组件本地故障的一系列场景中提供自动修正。 但是，大规模故障（包括影响服务器机架的服务中断或站点级灾难）需要其他注意事项。 这些注意事项应该是基于 VM 的用户工作负荷的业务连续性和灾难恢复策略的一部分。 此策略还必须考虑到 Azure Stack 基础结构的恢复，该基础结构与工作负荷恢复无关。
传统的本地工作负荷恢复解决方案配置复杂、维护成本高且十分费力，并且难以实现自动化，尤其是在使用另一个本地位置作为故障转移站点时。 Microsoft 建议使用一种替代解决方案，该解决方案依赖于云和本地组件的组合，以提供可复原、基于性能的、高度自动化的简单方式来实现、保护和管理经济高效的灾难恢复策略。 此解决方案的核心要素是 Site Recovery，其故障转移站点驻留在 Azure 中。
可能的用例
使用 Azure 作为故障转移站点的 Site Recovery 消除了上述所有缺点。 可以使用其功能来保护物理和虚拟服务器，包括那些在 Microsoft Hyper-V 或 VMware ESXi 虚拟化平台上运行的服务器。 还可以使用相同的功能来促进对 Azure Stack Hub VM 上运行的工作负荷的恢复。
核心功能
Site Recovery 是一种灾难恢复解决方案，该解决方案通过提供两组功能来帮助保护物理和虚拟计算机：
- 在生产位置和灾难恢复位置之间复制对计算机磁盘的更改
- 在这两个位置之间进行故障转移和故障回复的业务流程
Site Recovery 提供三种类型的故障转移：
- 测试故障转移。 此故障转移使你有机会在隔离的环境中验证 Site Recovery 配置，而不会导致数据丢失或对生产环境产生任何影响。
- 计划内故障转移 通过此故障转移，你可以选择在不丢失数据的情况下启动灾难恢复，这通常作为计划停机的一部分。
- 计划外故障转移 如果计划外服务中断影响主站点的可用性并可能导致数据丢失，则此故障转移是最后的选择。
Site Recovery 支持多种方案，例如在两个本地站点之间进行故障转移和故障回复、在两个 Azure 区域之间进行故障转移和故障回复，以及从第三方提供商的云进行迁移。 但在本文的上下文中，重点内容是将 Azure Stack Hub VM 的本地磁盘复制到 Azure 存储，以及在 Azure Stack Hub 堆栈和 Azure 区域之间进行 VM 故障转移和故障回复。
注意
涉及在基于 VMware 的本地数据中心或物理数据中心之间进行复制的 Site Recovery 方案将于 2020 年 12 月 31 日终止服务。
注意
Azure Stack Hub 的两个部署之间不支持 Site Recovery。
Site Recovery 体系结构及其组件的详细信息取决于许多条件，包括：
- 要保护的计算机类型（物理与虚拟）。
- 对于虚拟化环境，托管要保护的虚拟机的虚拟机监控程序类型（Hyper-V 与 VMware ESXi）。
- 对于 Hyper-V 环境，使用 System Center Virtual Machine Manager (SCVMM) 来管理 Hyper-V 主机。
借助 Azure Stack Hub，该体系结构与适用于物理计算机的体系结构相匹配。 这并不特别奇怪，因为在这两种情况下，Site Recovery 都无法从直接访问虚拟机监控程序中获益。 相反，用于跟踪并复制对本地磁盘的更改的机制是在受保护的操作系统中实现的。
注意
顺便说一句，这也是在 Azure 门户的 Site Recovery 界面中配置 Azure Stack Hub VM 复制时需要选择“物理计算机”作为“计算机类型”的原因。 另一个含义是一种独特的故障回复方法，该方法不提供与 Hyper-V 或基于 ESXi 的场景中可用的自动化程度相同的自动化程度。
为了实现此目标，Site Recovery 依赖于 Site Recovery 移动服务（也称为“移动代理”），当你将各个 VM 注册到基于 Site Recovery 的保护范围内时，该服务将自动部署到各个 VM。 在每个受保护的 VM 上，在本地安装的移动代理实例将持续监视对操作系统和数据磁盘的更改并将其转发到进程服务器。 但是，为了优化和管理源自受保护 VM 的复制流量流，Site Recovery 实现了一组在单独的 VM 上运行的附加组件，该组件被称为配置服务器。
配置服务器协调与 Site Recovery 保管库的通信，并管理数据复制。 此外，配置服务器托管被称为进程服务器的组件，该组件充当网关，用于接收复制数据，通过缓存和压缩对该数据进行优化、加密，最后将其转发到 Azure 存储。 实际上，配置服务器充当 Site Recovery 与在 Azure Stack Hub 上运行的受保护 VM 之间的集成点。 可以通过部署配置服务器并将其注册到 Azure 恢复服务保管库来实现该集成。
作为 Site Recovery 配置的一部分，可以与生产环境相同的方式定义预期的灾难恢复环境，包括虚拟网络、负载均衡器或网络安全组等基础结构组件。 此配置还包括复制策略，该策略用于确定恢复功能并包含以下参数：
RPO 阈值。 此设置表示想要实现的所需恢复点目标，并确定 Site Recovery 生成故障一致性恢复点快照的频率。 其值不影响复制频率，因为复制是连续的。 如果 Site Recovery 提供的当前有效 RPO 超过指定的阈值，Site Recovery 将生成警报和电子邮件通知（可选）。 Site Recovery 每隔 5 分钟生成一次故障一致性恢复点快照。
注意
崩溃一致性快照捕获创建快照时磁盘上的数据。 它不包括内存内容。 实际上，故障一致性快照并不能保证操作系统或在本地安装的应用的数据一致性。
恢复点保留期。 此设置表示每个恢复点快照的保留时段的持续时间（以小时为单位）。 受保护的 VM 可以恢复到保留时段内的任何恢复点。 Site Recovery 支持将复制到具有高级性能层的 Azure 存储帐户的 VM 保留最多 24 小时。 如果使用具有标准性能层的 Azure 存储帐户，则保留期上限为 72 小时。
应用一致性快照频率。 此设置确定 Site Recovery 生成应用程序一致性快照的频率（以小时为单位）。 应用一致性快照表示在受保护 VM 中运行的应用程序的时间点快照。 应用一致性快照数上限为 12 个。 对于运行 Windows Server 的 VM，Site Recovery 将使用卷影复制服务 (VSS)。 Site Recovery 还支持适用于 Linux 的应用一致性快照，但这需要实现自定义脚本。 当应用某个应用一致性快照时，移动代理将使用该脚本。
注意
有关在运行 Linux 的 Azure Stack Hub VM 上实现应用一致性快照的详细信息，请参阅有关 Site Recovery 的一般问题。
对于指定的受保护 Azure Stack Hub VM 的每个磁盘，数据将复制到 Azure 存储中相应的托管磁盘。 磁盘存储源磁盘的副本以及所有恢复点故障一致性和应用一致性快照。 作为故障转移的一部分，可以选择在将托管磁盘附加到 Azure VM 时应使用的恢复点故障一致性快照或应用一致性快照，该快照用作受保护的 Azure Stack Hub VM 的副本。
在常规业务操作过程中，受保护的工作负荷在 Azure Stack Hub VM 上运行，通过移动代理、进程服务器和配置服务器之间的交互，将对其磁盘的更改持续复制到指定的 Azure 存储帐户。 当启动测试、计划内或计划外故障转移时，Site Recovery 将使用相应 Azure Stack Hub VM 的磁盘副本自动预配 Azure VM。
注意
使用 Site Recovery 复制磁盘预配 Azure VM 的过程称为“合成”。
可以选择通过创建包含手动和自动执行步骤的恢复计划来协调故障转移。 要实现后一种方法，可以使用 Azure 自动化 Runbook，其中包含自定义 PowerShell 脚本、PowerShell 工作流或 Python 2 脚本。
在主站点再次变得可用后，Site Recovery 支持反转复制方向，从而允许在不丢失数据的情况下以最短的停机时间执行故障回复。 但是，对于 Azure Stack Hub，此方法不可用。 相反，要进行故障回复，必须下载 Azure VM 磁盘文件，将这些文件上传到 Azure Stack Hub，然后将其附加到现有或新的 VM。
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改善工作负荷质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
可靠性
可靠性可确保应用程序符合你对客户的承诺。 有关详细信息，请参阅可靠性支柱概述。
Azure Stack Hub 通过其基础结构固有的复原能力来帮助提高工作负荷的可用性。 此复原能力可为受 Site Recovery 保护的 Azure Stack Hub VM 和本地 Site Recovery 基础结构的基本组件（包括配置服务器和进程服务器）提供高可用性。
同样，可以选择使用 Site Recovery 基础结构的基于云的组件的复原能力。 默认情况下，Azure 恢复服务是异地冗余的，这意味着其配置将自动复制到属于预定义区域对的 Azure 区域。 如果这足以满足复原能力需求，可以选择将复制设置更改为本地冗余。 请注意，如果保管库包含任何受保护的项，则无法更改此选项。 具有标准性能层的任何 Azure 存储帐户都可以使用相同的复原能力选项，不过可以随时对其进行更改。
注意
有关 Azure 区域对的列表，请参阅业务连续性和灾难恢复 (BCDR)：Azure 配对区域。
通过设计和实现用于扩展工作负荷保护范围的解决方案，可以进一步提高此复原能力。 这就是 Site Recovery 提供的附加价值。 在 Azure Stack Hub 上运行的 Site Recovery 的上下文中，需要更详细地探索工作负荷可用性的两个主要方面：
- 故障转移到 Azure
- 故障回复到 Azure Stack Hub
在开发由恢复点目标 (RPO) 和恢复时间目标 (RTO) 驱动的灾难恢复策略时，需要同时考虑这两个方面。 RTO 和 RPO 表示组织内各个业务功能规定的连续性要求。 RPO 指定一个时间段，该时间段表示在影响数据可用性的事件之后最大可接受的数据丢失。 RTO 指定在影响这些功能可用性的事件后恢复业务功能所需的最长可接受持续时间。
故障转移到 Azure
在 Azure Stack Hub VM 的基于 Site Recovery 的保护上下文中，故障转移到 Azure 是可用性注意事项的核心。 为了最大限度地提高工作负荷的可用性，故障转移策略应同时满足尽量减少潜在数据丢失 (RPO) 和故障转移时间 (RTO) 的需求。
为了尽量减少潜在的数据丢失，可以考虑执行以下操作：
- 通过遵循可伸缩性和性能注意事项，来最大化吞吐量并尽量减少复制流量的延迟。 有关详细信息，请参阅本文的下一部分。
- 增加数据库工作负荷的应用一致性恢复点的频率（每小时最多一个恢复点）。 应用一致性恢复点是基于应用一致性快照创建的。 应用一致性快照捕获磁盘和内存中的应用数据。 虽然此方法可以尽量减少潜在的数据丢失，但它有一个主要缺点。 应用一致性快照需要在 Windows 上使用卷影复制服务或在 Linux 上使用自定义脚本，以静止本地安装的应用。 捕获过程可能会损害性能，尤其是在资源利用率很高的情况下。 我们不建议对非数据库工作负荷的应用一致性快照使用低频率。
尽量减少故障转移时间的主要方法是使用 Site Recovery 恢复计划。 恢复计划协调主站点和辅助站点之间的故障转移，从而定义受保护服务器的故障转移顺序。 可以通过添加手动说明和自动化任务来自定义计划。 其目的是使过程保持一致、准确、可重复和自动化。
当创建恢复计划时，将受保护的服务器分配给恢复组，以进行故障转移。 每个组中的服务器一起进行故障转移。 这有助于将故障转移过程划分为更小、更易于管理的单元，表示可以在不依赖外部依赖项的情况下进行故障转移的服务器集。
要尽量减少故障转移时间，作为创建恢复计划的一部分，你应该：
- 定义应一起故障转移的 Azure Stack Hub VM 组。
- 定义 Azure Stack Hub VM 组之间的依赖项，以确定故障转移的最佳顺序。
- 尽可能自动执行故障转移任务。
- 如果需要，包括自定义手动操作。
注意
单个恢复计划最多可包含 100 台受保护的服务器。
注意
通常，恢复计划可用于故障转移到 Azure 以及从 Azure 进行故障回复。 这不适用于不支持基于 Site Recovery 的故障回复的 Azure Stack Hub。
定义恢复计划并创建恢复组，以捕获特定于应用的属性。 例如，让我们考虑一个具有基于 SQL Server 的后端、中间件组件和 Web 前端的传统三层应用。 当创建恢复计划时，可以控制每层服务器的启动顺序，其中运行 SQL Server 实例的服务器先联机，然后是中间件层中的服务器，最后由托管 Web 前端的服务器联接。 此顺序可确保应用在最后的服务器启动之前一直保持工作。 要实现此顺序，只需创建包含三个恢复组的恢复计划，其中包含相应层中的服务器。
除了控制故障转移和启动顺序之外，还可以选择将操作添加到恢复计划中。 一般来说，有两种类型的操作：
- 自动。 此操作基于 Azure 自动化 runbook，它涉及两种类型的任务之一：
- 预配和配置 Azure 资源，例如，包括创建公共 IP 地址并将其与附加到 Azure VM 的网络接口关联。
- 修改在故障转移后预配的 Azure VM 中运行的操作系统和应用程序的配置。
- 手动。 此操作不支持自动化，并包含在恢复计划中，主要用于文档目的。
注意
要确定恢复计划的故障转移时间，请执行测试故障转移，然后检查相应 Site Recovery 作业的详细信息。
注意
要满足 Azure Stack Hub 工作负荷的 RTO 要求，你应该考虑恢复 Azure Stack 基础结构、用户 VM、应用程序和用户数据。 在本文的上下文中，我们只对这些组件中的最后两个感兴趣，但我们也介绍了有关新式备份存储功能可用性的注意事项。
故障回复到 Azure Stack Hub
在基于 Site Recovery 的方案中，如果实现得当，则故障回复不涉及数据丢失。 这意味着故障转移策略的重点是尽量减少故障回复时间 (RTO)。 但是，如前所述，当故障回复到 Azure Stack Hub 时，不能依赖于恢复计划。 相反，故障回复涉及以下步骤序列：
- 在灾难恢复环境中停止和解除对 Azure VM 的分配。
- 标识附加到要下载的 VM 的每个托管磁盘的 URI 参数。
- 将由在上一步中标识的 URI 参数标识的虚拟硬盘 (VHD) 文件下载到本地环境。
- 将 VHD 文件上传到 Azure Stack Hub。
- 将上传的 VHD 附加到新的或现有的 Azure Stack Hub VM。
- 启动 Azure Stack Hub VM。
尽量减少故障回复时间的最佳方法是自动执行故障回复。
注意
有关自动执行本部分中所述的故障回复过程的详细信息，请参阅在 Azure Stack Hub 中创建 VM 磁盘存储。
注意
有关标识托管磁盘的 URI 参数的详细信息，请参阅从 Azure 下载 Windows VHD。
特定于工作负荷的注意事项
Site Recovery 与基于 Windows Server 的应用和角色集成，包括 SharePoint、Exchange、SQL Server 和 Active Directory 域服务 (AD DS)。 这样，你就可以使用以下功能来实现应用级保护和恢复：
- 与应用级复制技术集成，例如 SQL Server AlwaysOn 可用性组、Exchange 数据库可用性组 (DAG) 和 AD DS 复制
- 针对单层或多层应用程序的应用一致性快照
- 丰富的自动化库，它提供特定于应用程序的生产就绪型脚本，该脚本可供下载并与恢复计划集成
此外，也可以选择使用特定于工作负荷的复制机制来提供站点级复原能力。 这是在针对 AD DS 域控制器、SQL Server 或 Exchange 实现灾难恢复时常用的选项，所有这些对象都以原生方式支持支持复制。 尽管这需要在灾难恢复环境中预配托管这些工作负荷的 Azure VM，这会增加成本，但它提供了以下好处：
- 可减少故障转移和故障回复所需的时间
- 可简化工作负荷级故障转移，并适应不需要站点级故障转移的场景
注意
有关 Site Recovery 特定于工作负荷的注意事项的详细信息，请参阅关于本地应用的灾难恢复。
安全性
在混合方案中管理对基于用户 VM 的工作负荷进行灾难恢复需要额外的安全注意事项。 这些注意事项可分为以下几类：
传输中加密。 其中包括受保护的 Azure Stack Hub VM、本地 Site Recovery 组件和基于云的 Site Recovery 组件之间的通信：
- 安装在受保护的 VM 上的移动代理始终通过传输层安全性 (TLS) 1.2 与进程服务器通信。
- 对于从配置服务器到 Azure 以及从进程服务器到 Azure 的通信，可以使用 TLS 1.1 或 1.0。 要提高混合连接的安全性级别，应该考虑强制使用 TLS 1.2。
注意
有关配置基于 TLS 1.2 的加密的详细信息，请参阅传输层安全性 (TLS) 注册表设置和更新以启用 TLS 1.1 和 TLS 1.2 作为 Windows 中 WinHTTP 中的默认安全协议
静态加密。 其中包括灾难恢复站点中的 Azure 存储和 Azure VM。
- Azure 存储使用 256 位高级加密标准加密对所有存储帐户进行静态加密，并且符合美国联邦信息处理标准 140-2。 加密是自动启用的，无法禁用。 默认情况下，加密使用 Microsoft 管理的密钥，但客户可以选择使用存储在 Azure Key Vault 中的自己的密钥。
- Azure VM 的托管磁盘使用 Azure 托管磁盘的服务器端加密进行自动加密，这也适用于使用平台管理的加密密钥进行加密的托管磁盘快照。
此外，可以强制实施对托管 Site Recovery 复制磁盘内容的 Azure 存储帐户的受限访问。 为此，请为恢复服务保管库启用托管标识，并在 Azure 存储帐户级别为该托管标识分配以下 Azure 基于角色的访问控制 (Azure RBAC) 角色：
- 基于资源管理器的存储帐户（标准性能层）：
- 参与者
- 存储 Blob 数据参与者
- 基于资源管理器的存储帐户（高级性能层）：
- 参与者
- 存储 Blob 数据所有者
Azure 恢复服务保管库提供了进一步保护其内容的机制，包括以下保护：
- Azure RBAC。 这允许根据最小特权原则委派和分离责任。 有三个与 Site Recovery 相关的内置角色，这些角色限制对 Site Recovery 操作的访问：
- Site Recovery 参与者。 此角色拥有在 Azure 恢复服务保管库中管理 Site Recovery 操作所需的所有权限。 但是，拥有此角色的用户既无法创建或删除保管库，也无法将访问权限分配给其他用户。 此角色最适合分配给灾难恢复管理员，这样他们可以为 Azure Stack Hub 租户启用和管理灾难恢复。
- Site Recovery 操作员。 此角色有权执行和管理故障转移及故障回复操作。 拥有此角色的用户无法启用或禁用复制、无法创建或删除保管库，也无法注册新的基础结构或向其他用户分配访问权限。 此角色最适合分配给灾难恢复操作员，这样他们就可以在实际或模拟的灾难场景中，遵循应用程序所有者和 IT 管理员的指示，对 Azure Stack Hub VM 进行故障转移。
- Site Recovery 读取者。 此角色有权跟踪所有 Site Recovery 管理操作。 此角色最适合分配给 IT 人员，这样他们就可以负责监视受保护的 Azure Stack Hub VM 的状态并在需要时提交支持工单。
- Azure 资源锁。 可以选择为 Site Recovery 保管库创建并分配只读锁和删除锁，以缓解保管库被意外和恶意更改或删除的风险。
- 软删除。 软删除的目的是帮助保护保管库及其数据免遭意外或恶意删除。 使用软删除后，任何被删除的内容都将额外保留 14 天，以便允许在此期间对其进行检索。 对保管库内容额外保留 14 天不会产生任何费用。 默认启用软删除。
- 保护安全敏感操作。 Azure 恢复服务保管库允许在尝试执行安全敏感操作（例如禁用保护）时启用额外的身份验证层。 此额外的验证有助于确保授权用户执行此类操作。
- 监视可疑活动并就其发出警报。 Azure 恢复服务提供对与保管库操作相关的安全敏感事件的内置监视和警报。
成本优化
成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息，请参阅成本优化支柱概述。
在考虑本文中所述的基于 Site Recovery 的灾难恢复解决方案的成本时，需要同时考虑本地组件和基于云的组件。 Azure Stack Hub 定价模型决定了本地组件的定价。 与 Azure 一样，Azure Stack Hub 提供即用即付的安排，可通过企业协议和云解决方案提供商计划获得。 此安排包括每个 Windows Server VM 的每月价格。 如果可以选择使用现有的 Windows Server 许可证，则可以显著降低基本 VM 定价的成本。 但是，使用 Site Recovery，每个租户通常只需要一个 Azure Stack Hub VM，这是实现特定于租户的配置服务器所必需的。
Azure 相关费用与以下资源的使用情况相关：
Azure 恢复服务。 定价取决于受保护的实例数。 值得注意的是，每个受保护的实例在前 31 天内不产生任何 Site Recovery 费用。
Azure 存储。 定价反映以下因素的组合：
- 性能层
- 存储的数据量
- 出站数据传输量
- 执行的操作的数量和类型（仅适用于标准性能层）
- 数据冗余（仅适用于标准性能层）
Azure ExpressRoute。 定价基于以下两种模型之一：
- 不限流量。 此模型包括每月费用，其中包含所有入站和出站数据传输。
- 数据流量。 此模型包括每月费用，其中所有入站数据传输免费，出站数据传输按 GB 收费。
注意
此评估不包括由第三方连接提供商提供的物理连接成本。
Azure VM。 Azure VM 的定价反映了两个组成部分的组合：
- 计算成本。 VM 大小、其正常运行时间和操作系统的许可模式决定了成本。
- 托管磁盘成本。 磁盘大小和性能层决定了成本。
注意
值得注意的是，合成消除了在常规业务操作期间运行 Azure VM 的需要，其中工作负荷在 Azure Stack Hub 上运行，这大大降低了基于 Site Recovery 的实现的计算成本，尤其是与传统的灾难恢复解决方案相比。
注意
不同 Azure 区域的资源价格也有所不同。
注意
有关定价的详细信息，请参阅 Azure 定价。
卓越运营
卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息，请参阅卓越运营支柱概述。
关于 Azure Stack Hub VM 的基于 Site Recovery 的灾难恢复的可管理性的主要注意事项包括：
- 在 Azure Stack Hub 上实现 Site Recovery
- 故障转移和故障回复过程
- 角色和职责的委派
- DevOps
在 Azure Stack Hub 上实现 Site Recovery
要在中小型单租户环境中的 Azure Stack Hub 上实现 Site Recovery，可以遵循 Azure 门户中由恢复服务保管库的图形界面驱动的手动预配过程。 对于多租户实现，可能需要考虑自动执行部分实现过程，因为通常需要为每个租户设置单独的配置服务器 VM 和单独的恢复服务保管库。 还可以选择按照准备源计算机以推送安装移动代理中所述的过程来自动部署移动代理。
故障转移和故障回复过程
要简化故障转移的管理，请考虑为所有受保护的工作负荷实现恢复计划。 有关详细信息，请参阅本文前面的可靠性部分。 你还可以找到关于优化故障回复过程管理的建议。
角色和职责的委派
使用 Site Recovery 规划和实现对基于 Azure Stack Hub VM 的工作负荷进行灾难恢复通常涉及利益干系人的交互：
- Azure Stack Hub 操作员管理 Azure Stack Hub 基础结构，确保有足够的计算、存储和网络资源来实现全面的灾难恢复解决方案并使这些资源可供租户使用。 他们还与应用程序和数据所有者协作，帮助确定将其工作负荷部署到 Azure Stack Hub 的最佳方法。
- Azure 管理员管理实现混合灾难恢复解决方案所需的 Azure 资源。
- Microsoft Entra 管理员管理 Microsoft Entra 资源，包括用于预配、配置和管理 Azure 资源的用户和组对象。
- Azure Stack Hub 租户 IT 人员设计、实现和管理 Site Recovery，包括故障转移和故障回复。
- Azure Stack Hub 用户需要提供 RPO 和 RTO 要求并提交请求，以对其工作负荷实现灾难恢复。
确保清楚地了解在保护和恢复过程中应用程序所有者和操作员应具备的角色和责任。 用户负责保护 VM。 操作员对 Azure Stack Hub 基础结构的运行状态负责。
注意
有关 Site Recovery 方案中精细权限委托的指导，请参阅使用 Azure 基于角色的访问控制 (Azure RBAC) 管理 Site Recovery 访问权限。
DevOps
虽然使用 Site Recovery 配置 VM 级恢复主要由 IT 运营人员负责，但应将一些特定于 DevOps 的注意事项纳入全面的灾难恢复策略。 Azure Stack Hub 有助于实现基础结构即代码 (IaC)，后者结合了各种工作负荷（包括基于 VM 的应用程序和服务）的自动部署。 可以使用此功能来简化基于 Site Recovery 的灾难恢复方案的预配，从而简化多租户方案中的初始设置。
例如，可以使用同一 Azure 资源管理器模板在单个协调操作中预配所有必要的网络资源，以在 Azure Stack Hub 标记中为应用程序容纳基于 VM 的工作负荷。 可以使用同一模板在 Azure 中预配一组匹配的资源，以预配灾难恢复站点。 要考虑两个环境之间的任何差异，只需在每种情况下指定不同的模板参数值即可。
性能效率
性能效率是指工作负荷能够以高效的方式扩展以满足用户对它的需求。 有关详细信息，请参阅性能效率要素概述。
当计划在 Azure Stack Hub 上部署 Site Recovery 时，需要考虑分配给配置和进程服务器的处理、存储和网络资源量。 可能需要在部署后调整托管 Site Recovery 组件的 Azure Stack Hub VM 的估计大小，以适应处理或存储要求的更改。 可以通过三个基本选项来调整大小：
实现垂直缩放。 这涉及修改托管配置服务器（包括进程服务器）的 Azure Stack Hub VM 的处理器、内存和磁盘资源的数量和类型。 可使用下表中的信息来估计资源需求：
表 1：配置和进程服务器大小要求
CPU 内存 缓存磁盘 数据更改率 受保护的计算机 8 个 vCPU，2 个插槽 * 4 个核心 @ 2.5 GHz 16GB 300 GB 500 GB 或更少 < 100 台计算机 12 个 vCPU，2 个插槽 * 6 个核心 @ 2.5 GHz 18 GB 600 GB 500 GB-1 TB 100 到 150 台计算机 16 个 vCPU，2 个插槽 * 8 个核心 @ 2.5 GHz 32 GB 1 TB 1-2 TB 150 到 200 台计算机 实现水平缩放。 这涉及预配或取消预配安装了进程服务器的 Azure Stack Hub VM，以满足受保护的 Azure Stack Hub VM 的处理需求。 通常，如果必须将部署扩大到 200 台以上的源计算机，或者每日总改动率超过 2 TB，则需要额外的进程服务器来处理复制流量。 要估计其他进程服务器的数量和配置，请参阅进程服务器的大小建议。
修改复制策略。 这涉及更改复制策略的参数，并重点关注应用一致性快照。
从网络的角度来看，可以通过几种不同的方法来调整可用于复制流量的带宽：
修改 VM 大小。 Azure Stack Hub VM 的大小决定了最大网络带宽。 但是，请务必注意，不保证带宽。 VM 可以改为利用由其大小决定的可用最大带宽量。
替换上行链路交换机。 Azure Stack Hub 系统支持一系列硬件交换机，并提供多种上行链路速度选择。 每个 Azure Stack Hub 群集节点都有两个到机架交换机顶部的上行链路，以便实现容错。 系统为关键基础结构分配了一半的上行链路容量。 其余部分是针对 Azure Stack Hub 服务和所有用户流量的共享容量。 以更快的速度部署的系统具有更多可用于复制流量的带宽。
注意
虽然可以通过将第二个网络适配器附加到服务器来隔离网络流量，但使用 Azure Stack Hub VM，所有到 Internet 的 VM 流量都共享相同的上行链路。 其次，虚拟网络适配器不会在物理传输级别隔离流量。
修改与 Azure 的网络连接的吞吐量。 要容纳更大数量的复制流量，你可以考虑将 Azure ExpressRoute 与 Microsoft 对等互连结合使用，以在 Azure Stack Hub 虚拟网络和 Azure 存储之间建立连接。 Azure ExpressRoute 通过连接提供商提供的专用连接将本地网络扩展到 Microsoft 云。 你可以购买各种带宽的 ExpressRoute 线路，从 50 兆比特每秒 (Mbps) 到 100 千兆比特每秒。
注意
有关在 Azure Stack Hub 方案中实现 Azure ExpressRoute 的详细信息，请参阅使用 Azure ExpressRoute 将 Azure Stack Hub 连接到 Azure。
修改进程服务器上复制流量的限制。 可以通过 Microsoft Azure 恢复服务代理的图形界面来控制将托管进程服务器的 VM 上的复制流量所使用的带宽数量。 受支持的功能包括设置工作和非工作时间的限制，带宽值范围从每秒 512 千比特到 1,023 Mbps。 此外，也可以使用 Set-OBMachineSetting PowerShell cmdlet 应用相同的配置。
修改进程服务器上为每个受保护 VM 分配的网络带宽。 为此，请修改 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\Replication 项中 UploadThreadsPerVM 条目的值。 默认情况下，该值设置为 4，但如果有足够的可用网络带宽，可以将其增加到 32。
部署此方案
先决条件
实现建议的解决方案取决于是否满足以下先决条件：
对 Azure 订阅的访问权限，具有足够的权限来预配和管理 Site Recovery 组件的所有云组件，包括：
- Azure 区域中的 Azure 恢复服务保管库，它被指定为 Azure Stack Hub 生产环境的灾难恢复站点。
- Azure 存储帐户，用于托管 Azure Stack Hub VM 的复制磁盘内容。
- Azure 虚拟网络，它表示在计划内或计划外故障转移后已水合的 Azure VM 将连接到的灾难恢复环境。
- 隔离的 Azure 虚拟网络，它表示在测试故障转移后已水合的 Azure VM 将连接到的测试环境。
- 本地环境、Azure 虚拟网络和 Azure 存储帐户之间的基于 Azure ExpressRoute 的连接，该帐户用于托管 VHD 文件的副本，其中包含从受保护的 Azure Stack Hub VM 的磁盘复制的内容。
Azure Stack Hub 用户订阅。 受单个 Site Recovery 配置服务器保护的所有 Azure Stack Hub VM 必须属于同一个 Azure Stack Hub 用户订阅。
Azure Stack Hub 虚拟网络。 所有受保护的 VM 必须直接连接到托管进程服务器组件的 VM（默认情况下，这是配置服务器 VM）。
将托管配置服务器和进程服务器的 Azure Stack Hub Windows Server VM。 VM 必须与需要保护的 Azure Stack Hub VM 属于同一订阅并附加到同一虚拟网络。 此外，VM 需要：
- 符合 Site Recovery 配置服务器软件和硬件要求
- 满足外部连接网络要求文档。
注意
此体系结构后面部分将更详细地介绍配置和进程服务器的其他存储和性能注意事项。
满足内部连接要求。 具体而言，需要保护的 Azure Stack Hub VM 必须能够与以下对象进行通信：
- 通过 TCP 端口 443 (HTTPS) 入站进行复制管理的配置服务器
- 通过 TCP 端口 9443 传递复制数据的进程服务器。
注意
当运行 Site Recovery 统一安装程序时，作为其配置的一部分，可以更改进程服务器用于外部和内部连接的端口。
要保护的 Azure Stack Hub VM，它运行任何受支持的操作系统。要保护运行 Windows Server 操作系统的 Azure Stack Hub VM，必须：
- 创建具有管理权限的 Windows 帐户。 在这些 VM 上启用 Site Recovery 时，可以指定此帐户。 进程服务器使用此帐户来安装 Site Recovery 移动服务。 在工作组环境中，将 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System 键中的 LocalAccountTokenFilterPolicy DWORD 注册表项的值设置为 1，确保禁用目标 Windows Server 操作系统上的远程用户访问控制。
- 在 Microsoft Defender 防火墙中启用文件和打印机共享以及 Windows Management Instrumentation 规则。
要保护运行 Linux 操作系统的 Azure Stack Hub VM，必须：
- 创建根用户帐户。 在这些 VM 上启用 Site Recovery 时，可以指定此帐户。 进程服务器使用此帐户来安装 Site Recovery 移动服务。
- 安装最新的 openssh、openssh-server 和 openssl 包。
- 启用并运行安全外壳 (SSH) 端口 22。
- 启用安全 FTP 子系统和密码验证。
概要实现步骤
概括而言，在 Azure Stack Hub 上实现基于 Site Recovery 的灾难恢复包括以下阶段：
准备受 Site Recovery 保护的 Azure Stack Hub VM。 确保 VM 满足上一部分中列出的 Site Recovery 先决条件。
创建和配置 Azure 恢复服务保管库。 设置 Azure 恢复服务保管库并指定要复制的内容。 使用保管库配置和管理 Site Recovery 组件和活动。
设置源复制环境。 通过安装 Site Recovery 统一安装程序二进制文件，来预配 Site Recovery 配置服务器和进程服务器，并将其注册到保管库。
注意
可以重新运行 Site Recovery 统一安装程序，以便在 Azure Stack Hub VM 上实现其他进程服务器。
设置目标复制环境。 在 Azure 区域中创建或选择将托管灾难恢复站点的现有 Azure 存储帐户和 Azure 虚拟网络。 在复制过程中，将受保护的 Azure Stack Hub VM 的磁盘内容复制到 Azure 存储帐户。 在故障转移期间，Site Recovery 将自动预配作为受保护的 Azure Stack Hub VM 的副本的 Azure VM，并将其连接到 Azure 虚拟网络。
启用复制。 为 Azure Stack Hub VM 配置复制设置并启用复制。 移动服务将自动安装在已启用复制的每个 Azure Stack Hub VM 上。 Site Recovery 根据定义的策略设置启动每个 Azure Stack Hub VM 的复制。
执行测试故障转移。 建立复制后，通过执行测试故障转移来验证故障转移是否按预期工作。
执行计划内或计划外故障转移。 成功进行测试故障转移后，你就可以对 Azure 执行计划内或计划外故障转移了。 你可以选择指定要包含在故障转移中的 Azure Stack Hub VM。
执行故障回复。 当准备好进行故障回复时，停止与失败的 Azure Stack Hub VM 对应的 Azure VM，将其磁盘文件下载到本地存储，将这些文件上传到 Azure Stack Hub，然后将其附加到现有或新的 VM。
总结
总之，Azure Stack Hub 是一个独特的产品/服务，它在许多方面都与其他虚拟化平台不同。 因此，它需要特别考虑针对其工作负荷的业务连续性策略。 使用 Azure 服务可以简化此策略的设计和实现。 在本体系结构参考文章中，我们已了解如何在已连接的部署模型中使用 Microsoft Site Recovery 保护基于 Azure Stack Hub VM 的工作负荷。 此方法使客户能够从 Azure Stack Hub 的复原能力和可管理性以及 Azure 云的超大规模和全局状态中获益。
请务必注意，此处所述的灾难恢复解决方案专门针对 Azure Stack Hub 的基于 VM 的工作负荷。 这只是总体业务连续性策略的一部分，该策略考虑影响其可用性的其他 Azure Stack Hub 工作负荷类型和方案。
后续步骤
产品文档：
- 关于 Site Recovery
- Azure Stack Hub 概述
- 什么是 Microsoft Entra ID？
- 什么是 Azure Blob 存储？
- 什么是 Azure ExpressRoute？
- 什么是 Azure 虚拟网络？
Microsoft Learn 模块：