高可用性和灾难恢复
System Center – Operations Manager 服务器和功能可能会失败，从而影响 Operations Manager 功能。 故障期间丢失的数据量和功能量在每种故障情况下会有所不同。 这取决于失败功能的角色以及恢复失败功能所需的时间长度。
高可用性
通过将冗余构建到 Operations Manager 操作和数据仓库数据库的管理组中、网关和管理服务器以及特定工作负荷，可以解决高可用性需求。 这些工作负载包括网络设备监视、跨平台监视和管理组特定的工作负荷，这些工作负荷以前由根管理服务器管理。
多个服务器、单一管理组配置可以使用 SQL Server Always On 来提供 Operations Manager 数据库的高可用性和服务连续性。 管理服务器容错通过至少具有两个管理服务器，并使用资源池监视 UNIX 服务器、Linux 服务器和网络设备来提供。 如果管理服务器失败，可以使用主管理服务器和辅助管理服务器配置基于代理的 Windows 服务器来重定向代理通信。
如果托管 RMS 模拟器的管理服务器不可用，RMS 模拟器也可以移动到另一个管理服务器。
可以通过为数据访问服务配置高可用性，使操作控制台连接具有高可用性。 这可以通过安装Microsoft网络负载均衡（NLB）或使用基于硬件的负载均衡器或 DNS 别名来完成。 将一个或多个管理服务器添加为 NLB 池的成员，在打开任一控制台时，引用在 DNS 中注册的虚拟名称（负载均衡管理服务器）。
注意
Operations Manager Web 控制台服务器不支持网络负载均衡器。
可以跨信任边界部署多个网关服务器，以为跨信任边界的代理提供冗余路径。 正如代理可以在主要管理服务器与一个或多个辅助管理服务器之间进行故障转移一样，它们也可以在网关服务器之间进行故障转移。 此外，多个网关服务器可用于分担管理无代理管理的计算机以及所管理网络设备的工作负荷。
除了通过代理-网关故障转移来提供冗余之外，还可以将网关服务器配置为在管理组中的管理服务器之间进行故障转移（如果多个管理服务器可用）。
虽然 SQL Server Reporting Services 支持横向扩展部署模型，允许运行多个共享单个报表服务器数据库的报表服务器实例，但 Operations Manager 不支持它。 Operations Manager 报告将自定义安全扩展作为前端组件的设置的一部分进行安装，而前端组件无法跨 Web 场复制。
灾难恢复
灾难恢复是指为确保在发生灾难性故障（例如，托管主基础结构的整个数据中心丢失）时能够恢复操作而采取的措施。 这是在任何部署中都必须考虑的一个重要因素，在规划灾难恢复时做出的决策会影响 Operations Manager 如何继续支持主动监视和报告关键 IT 服务的性能和可用性。 本部分将重点介绍建议的灾难恢复和复原能力策略，以及应采取哪些步骤确保顺利恢复。
虽然 HA 和 DR 解决方案将提供系统故障或系统丢失的保护，但不应依赖它们免受意外、意外或恶意数据丢失或损坏的保护。 在这些情况下，备份复制或滞后复制副本可能必须用于还原操作。 在许多情况下，还原操作是最适当的 DR 形式。 其中一个示例可能是低优先级报告数据库或分析数据。 在许多情况下，在系统或应用程序级别启用多站点 DR 的成本远远超过了数据的价值。 如果数据短期值较低，并且如果故障或站点 DR 过多，则访问数据的需求可能会延迟，而不会造成严重的业务影响，请考虑在节省成本时对 DR 使用简单的备份和还原过程。
了解停机时间的影响和容忍度将有助于推动需要理解的决策，以便正确设计 Operations Manager 的体系结构以及支持灾难恢复所需的复杂性和成本级别。 此外，请考虑 IT 组织可以容忍的监视数据丢失的程度，而不会造成业务后果。 这最好用两个术语进行描述：恢复时间目标（RTO）和恢复点目标（RPO）。
Operations Manager 最常见的两种灾难恢复设计配置是：
- 创建部署到辅助数据中心的重复管理组，该管理组在规模和配置上与主管理组重复。
- 在辅助数据中心部署其他服务器以支持操作和数据仓库数据库，管理服务器部署在冷备用配置中，在需要执行恢复操作之前不参与管理组。
部署重复的管理组是一个选项，当无法容忍停机时：但是，这是最复杂的选项。 两者之间的配置需要一致，以便在切换时，监视、警报或报告的内容没有区别，最终升级。 与其他监视平台或 ITSM 平台（如 System Center - Service Manager、补救措施或 ServiceNow）的集成也需要存在，并且可能配置为主动/被动状态，以避免重复事件、配置项目等。 代理将在两个管理组之间多宿主，因此将重复数据。
下图是此设计方案的示例。
如果 Operations Manager 部署不需要立即恢复，并且想要避免重复管理组的复杂性，则可以在辅助数据中心部署其他管理组组件，以便保留管理组的功能。 至少考虑实现 SQL Server 2014 或 2016 Always On 可用性组，以在两个或更多数据中心之间提供操作和数据仓库数据库的恢复，其中两节点故障转移群集实例（FCI）部署在主数据中心，在辅助数据中心内部署独立 SQL Server 作为单个 Windows Server 故障转移群集（WSFC）的一部分。 AlwaysOn 可用性组的次要副本将位于非 FCI 独立实例上，如下图所示。
在此示例中，需要使用 /Recover 参数部署一个或多个具有相同硬件配置和计算机名称的 Windows Server，并使用 /Recover 参数重新安装管理服务器角色。 下面是一个示例：
Setup.exe /silent /AcceptEndUserLicenseAgreement:1 /recover /InstallPath:<Install Directory> /ManagementGroupName:MGNAME /SqlServerInstance:SQLServerName.domain.com /DatabaseName:OperationsManager /DWSqlServerInstance:SQLServerName.domain.com /DWDatabaseName:OperationsManagerDW /ActionAccountUser:DOMAIN\omaa /ActionAccountPassword:password /DASAccountUser:DOMAIN\omdas /DASAccountPassword:password /DatareaderUser:DOMAIN\omdr /DatareaderPassword:password /DataWriterUser:DOMAIN\omdw /DataWriterPassword:password /EnableErrorReporting:Always /SendCEIPReports:1 /UseMicrosoftUpdate:0
有关详细信息，请参阅 从命令提示符安装 Operations Manager。
在此期间，代理会将收集的数据（警报、事件、性能等）排入队列，直到他们能够恢复与管理组中管理服务器的通信。 此方法可避免安装 SQL Server 的新实例，并从上次已知的良好备份还原数据库。 但是，在此恢复方案中，由于需要部署恢复最低监视功能所需的其他角色，返回可操作状态可能会延迟更长。 如果此方法不能接受，则可以在辅助数据中心部署管理服务器，以便进行备用恢复。 将其删除为三个主要资源池的成员 - 所有管理服务器资源池、通知和 AD 分配。 这还包括任何自定义资源池，这可能包括主数据中心中托管的管理服务器，并且需要继续作为恢复计划的一部分运行。 System Center Data Access、System Center Configuration Management 和 Microsoft Monitoring Agent 服务应停止并设置为手动或禁用，并且仅在灾难恢复方案中启动。
如果管理服务器支持集成（通过直接托管在管理服务器上或从另一个 System Center 产品（如 VMM、Orchestrator 或 Service Manager）托管的连接器），则需要根据集成配置和恢复步骤顺序，计划执行手动或自动恢复步骤。 这可确保捕获管理服务器上的任何其他依赖项，并在需要实施灾难恢复计划时进行计划。
如果一个站点脱机，则代理将故障转移到另一个站点中的管理服务器，前提是代理的故障转移配置允许这样做。 将 Windows 代理重新配置为仅缓存主数据中心的管理服务器，这些服务器应对其进行管理，以防止它们尝试故障转移到辅助数据中心的管理服务器，这只会延迟恢复和报告。 如果使用脚本（例如 VBScript 或更好的 PowerShell）以自动化方式部署代理，则可以在安装期间进行预配置，或者在从控制台推送代理后部署（再次使用通过企业配置管理解决方案管理的脚本方法）再次部署代理时，可以完成此操作。
可将 Operations Manager 部署在 Azure 虚拟机上，作为备用灾难恢复选项，以保持管理组的连续性。 还需要在 Azure 中的虚拟机上部署 SQL Server，而不是在混合配置中部署 SQL Server，因为管理服务器与托管 Operations Manager 数据库的 SQL Server 之间的延迟将对管理组的性能产生负面影响。
请考虑监视范围、网络拓扑和与 Microsoft Azure（即站点到站点 VPN 或 ExpressRoute）的网络连接、集成点（即 ITSM 解决方案、其他 System Center 产品、第三部分加载项等）、控制台访问、法规或相关法律或策略等，以便在 Azure IaaS 或其他公有云提供商中正确架构此方案。