高可用性和灾难恢复

重要

此版本的 Operations Manager 已终止支持。 建议 升级到 Operations Manager 2022。

System Center – Operations Manager 服务器和功能可能会失败，从而影响 Operations Manager 功能。 故障期间丢失的数据量和功能量在每种故障情况下会有所不同。 这取决于故障功能的角色以及恢复失败功能所需的时间长度。

高可用性

通过在 Operations Manager 操作和数据仓库数据库的管理组、网关和管理服务器以及特定工作负荷中构建冗余，可满足高可用性需求。 这些工作负荷包括网络设备监视、跨平台监视和管理组特定工作负荷（以前由根管理服务器管理）。

多服务器、单管理组配置可使用 SQL Server Always On 实现 Operations Manager 数据库的高可用性和服务连续性。 通过具有至少两个管理服务器并使用资源池来监视 UNIX 服务器、Linux 服务器和网络设备，可实现管理服务器容错性。 基于代理的 Windows 服务器可以配置为使用主管理服务器和辅助管理服务器以重定向代理通信以防某个管理服务器失败。

RMS 仿真器也可以移动到另一台管理服务器，以防托管 RMS 仿真器的管理服务器变得不可用。

可通过为 Data Access Services 配置高可用性，使操作控制台连接具有高可用性。 这可以通过安装 Microsoft 网络负载平衡 (NLB) 或使用基于硬件的负载均衡器或 DNS 别名来完成。 将一个或多个管理服务器添加为 NLB 池的成员，并且在打开其中一个控制台时，引用负载平衡管理服务器在 DNS 中注册的虚拟名称。

注意

Operations Manager Web 控制台服务器不支持网络负载均衡器。

可以跨信任边界部署多个网关服务器，以为跨信任边界的代理提供冗余路径。 正如代理可以在主要管理服务器与一个或多个辅助管理服务器之间进行故障转移一样，它们也可以在网关服务器之间进行故障转移。 此外，多个网关服务器可用于分担管理无代理管理的计算机以及所管理网络设备的工作负荷。

除了通过代理-网关故障转移来提供冗余之外，还可以将网关服务器配置为在管理组中的管理服务器之间进行故障转移（如果多个管理服务器可用）。

虽然 SQL Server Reporting Services 支持横向扩展部署模型，该模型允许运行共享单个报表服务器数据库的多个报表服务器实例，但 Operations Manager 不支持该模型。 Operations Manager Reporting 在设置前端组件过程中安装自定义安全扩展插件，该扩展插件不能在 Web 场中复制。

灾难恢复

灾难恢复与用于用于确保在出现灾难性故障（例如，托管主基础结构的整个数据中心丢失）时操作可恢复的措施有关。 这是任何部署中必须考虑的一个重要因素，在规划灾难恢复时做出的决策会影响 Operations Manager 如何继续支持主动监视和报告关键 IT 服务的性能和可用性。 本部分将重点介绍灾难恢复和复原能力的建议策略以及为确保顺利恢复而要执行的步骤。

虽然 HA 和 DR 解决方案可防范系统故障或系统丢失，但不应依赖它们来防止意外、意外或恶意的数据丢失或损坏。 在这些情况下，备份复制或滞后的复制副本可能必须用于还原操作。 在许多情况下，还原操作是 DR 的最合适形式。 其中一个示例是低优先级报表数据库或分析数据。 在许多情况下，在系统或应用程序级别启用多站点 DR 的开销远远超过了数据的价值。 如果数据的近期价值较低且访问数据的需求可能延迟，而在发生故障或站点 DR 过多时也不会带来严重的业务影响，则考虑使用简单的备份和还原过程进行 DR（如果成本节省的同时能够保证它顺利完成）。

了解停机时间的影响和容限将有助于制定决策，需要了解这些决策才能正确设计 Operations Manager 的体系结构以及支持灾难恢复所需的复杂程度和成本。 此外，请考虑 IT 组织可以承受且不会造成业务后果的数据丢失的监视程度。 以下两个词对此做出了最佳描述：恢复时间目标 (RTO) 和恢复点目标 (RPO)。

对于 Operations Manager，有两个最常见的灾难恢复设计配置：

• 创建部署到辅助数据中心的重复管理组，该管理组在规模和配置主管理组时重复。
• 在辅助数据中心部署其他服务器以支持操作和数据仓库数据库，其中管理服务器部署在冷备用配置中，在需要执行恢复操作之前不参与管理组。

如果无法容忍停机，则部署重复的管理组是一个选项;但是，这是最复杂的选项。 两者之间的配置需要保持一致，以便在切换时，在监视、警报或报告、呈现和最终升级方面没有区别。 与其他监视平台或 ITSM 平台（如 System Center - Service Manager、Remedy 或 ServiceNow）集成也需要存在，并且可能配置为主动/被动状态，以避免重复事件、配置项目等。 代理将在两个管理组之间进行多宿主管理，因此将存在重复数据。

下图是此设计方案的示例。

如果 Operations Manager 部署不需要立即恢复，并且想要避免重复管理组的复杂性，则还可以在辅助数据中心部署其他管理组组件，以保留管理组的功能。 在最低限度上，考虑实施 SQL Server 2014 或 2016 AlwaysOn 可用性组以在两个或多个数据中心之间实现操作和数据仓库数据库的恢复，其中双节点故障转移群集实例 (FCI) 部署在主数据中心，辅助数据中心中的独立 SQL Server 属于单个 Windows Server 故障转移群集 (WSFC)。 AlwaysOn 可用性组的辅助副本将位于非 FCI 独立实例上，如下图所示。

在此示例中，你将需要部署一个或多个 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，而不是在混合配置中，因为管理服务器与托管 Operations Manager 数据库的SQL Server之间的延迟将对管理组的性能产生负面影响。

请考虑监视范围、网络拓扑和与 Microsoft Azure (的网络连接，即站点到站点 VPN 或 ExpressRoute) 、集成点 (，即 ITSM 解决方案、其他 System Center 产品、第三部分加载项等) 、控制台访问、法规或相关法律或策略等，以便在 Azure IaaS 或其他公有云提供商中正确构建此方案。