规划管理组设计

概述

管理组由单个操作数据库、一个或多个管理服务器以及一个或多个受监视的代理和设备标识。 连接管理组允许从单个控制台查看和编辑警报和其他监视数据。 还可以从本地管理组启动任务，以在连接的管理组的托管对象上运行。

最简单的 Operations Manager 实现是单个管理组。 每个附加组至少需要自己的操作数据库和管理服务器。 每个组还必须单独使用自己的配置设置、管理包以及与其他监视和 ITSM 解决方案集成进行维护。

分布式管理组实现将形成 99% 的 Operations Manager 部署的基础。 它允许跨多个服务器分配功能和服务，以便为其中一些功能实现可伸缩性和冗余。 它可以包括所有 Operations Manager 服务器角色，并支持使用网关服务器跨信任边界监视设备。

下图显示分布式管理组拓扑的一个可能选项。

注意

操作控制台与数据库之间没有直接通信。 所有通信都通过端口 TCP 5724 定向到特定的管理服务器，然后在安装 SQL Server 数据库引擎实例期间使用 TCP 1433 上的 OLE DB 或 SQL 管理员指定的用户定义的端口。 但是，应用程序诊断控制台（与 Web 控制台并置）与托管操作数据库和数据仓库数据库的 SQL Server 之间存在直接通信。

已在环境中部署的管理组可以与 Microsoft Operations Management Suite （OMS）集成，并且通过使用 Log Analytics，可以进一步关联、可视化和处理性能、事件和警报。 这样，便可以在整个数据集中执行自定义搜索，以便关联系统与应用程序、本地或云中托管的数据，从而增加可见性。

与 Operations Manager 的集成扩展到其他产品，例如 BMC 补救措施、IBM、Netcool 或其他组织使用的企业管理解决方案。 有关规划与这些解决方案的互操作性的详细信息，请查看 与其他管理解决方案的集成。

管理组组件

Management 服务器

在 Operations Manager 2007 中，根管理服务器（RMS）是管理组中的专用管理服务器类型，也是管理组中安装的第一台管理服务器。 RMS 是管理管理组配置、管理和与代理通信以及与管理组中的操作数据库和其他数据库通信的焦点。 RMS 还充当操作控制台的目标和 Web 控制台的首选目标。 在 System Center 2012 R2 – Operations Manager 中，已删除根管理服务器角色，所有管理服务器现在都是对等服务器。 System Center 2016 及更高版本中仍然存在此配置 - Operations Manager。

RMS 不再是单一故障点，因为所有管理服务器都托管以前仅由 RMS 托管的服务。 角色会分配给所有管理服务器。 如果一台管理服务器变为不可用，则会自动重新分配其职责。 RMS 仿真器角色为针对 RMS 的管理包提供向后兼容性。 如果没有以前面向 RMS 的任何管理包，则无需使用 RMS 模拟器。

管理组可以包含多台管理服务器以提供其他功能和连续的可用性。 将两个或多个管理服务器添加到管理组时，管理服务器会自动成为三个默认资源池的一部分，工作分布在池的成员中。 对于自定义的资源池，将手动添加成员。 如果资源池的一个成员出现故障，则资源池中的其他成员将获取该成员的工作负荷。 添加新的管理服务器时，新管理服务器会自动从资源池中的现有成员获取部分工作。 查看 资源池设计注意事项 ，详细了解其功能方式以及影响设计计划的建议。

如果管理服务器因任何原因而不可用，则依赖它的代理会自动故障转移到另一个管理服务器。 选择管理服务器的数量和位置时，如果要求高可用性，应考虑此故障转移能力。

代理连接到管理服务器，以便与所有其他 Operations Manager 组件通信。 管理服务器执行的一些工作是采用代理发送的操作数据并将其插入操作数据库和数据仓库的过程。

典型的管理服务器将处理大约 3,000 个代理。 实际服务器性能因收集的操作数据量而异;但是，管理服务器通常可以支持 3,000 个代理，即使操作数据量相对较高。

每个管理组的最大管理服务器数没有限制。 但是，在解决可伸缩性、高可用性和灾难恢复约束后，最佳做法是尽可能少地使用管理服务器。

管理服务器应与 Operations Manager 数据库和数据仓库建立良好的网络连接，因为它们经常向这些存储发送大量数据。 通常，这些 SQL Server 连接消耗更多的带宽，并且对网络延迟更敏感。 因此，所有管理服务器应与操作数据库和数据仓库数据库位于同一局域网上，并且从未跨广域网部署。 托管 Operations Manager 数据库的管理服务器和 SQL Server 实例之间的延迟应小于 10 毫秒。

网关服务器

Operations Manager 需要在代理和管理服务器之间执行相互身份验证，然后才能在代理与管理服务器之间交换信息。 为了保护它们之间的身份验证进程，对此进程进行了加密。 当代理和管理服务器位于相同的 Active Directory 域中或位于已经建立了信任关系的 Active Directory 域中时，它们使用 Active Directory 提供的 Kerberos V5 身份验证机制。 当代理和管理服务器不位于同一信任边界内时，必须使用其他机制来满足安全相互身份验证要求。

当防火墙将代理与管理服务器分离或代理位于单独的不受信任的域中时，将使用网关服务器。 网关服务器充当代理与管理服务器之间的代理。 如果没有网关服务器，代理仍可以通过管理服务器执行证书身份验证，但需要使用 MOMCertImport.exe 工具在每个代理上颁发并安装 X.509 证书，并且每个证书都需要通过防火墙访问管理服务器。 如果代理与网关服务器位于同一域中，或者它们位于受信任的域中，则它们可以使用 Kerberos 身份验证。 在这种情况下，只有网关服务器和连接的管理服务器需要证书。 这包括监视在 Microsoft Azure 基础结构即服务（IaaS）中运行的虚拟机，以及 Operations Manager（即混合云监视），这些虚拟机未加入支持 Operations Manager 管理组的角色，或者已在 Azure IaaS 中部署 Operations Manager（具有托管操作数据库的虚拟机和托管管理服务器角色的一个或多个虚拟机）并监视不受信任的本地工作负荷。

下面提供了一个监视 Azure IaaS 资源的示例 Operations Manager 部署。

下面是 Azure IaaS 中托管的示例 Operations Manager 部署。

通常，网关服务器不用于管理带宽利用率，因为从代理发送到管理服务器的总数据量与是否使用网关服务器类似。 网关服务器的预期用途是减少管理不受信任的域中代理的证书所需的工作量，并减少必须通过防火墙允许的通信路径数。

• 每个网关服务器具有 2,000 个以上的代理可能会对在持续中断导致网关服务器无法与管理服务器通信的情况下恢复能力产生不利影响。 如果需要 2,000 多个代理，建议使用多个网关服务器。 如果网关服务器恢复时间令人担忧，则替代方法是测试系统，以确保网关服务器能够在网关服务器与管理服务器之间持续中断后快速清空其队列。 此外，在网关服务器上的传入队列填充后，队列中的数据会根据其优先级删除，这意味着此方案中的持续网关服务器中断可能会导致数据丢失。
• 如果通过网关服务器连接了大量代理，请考虑为所有网关服务器使用专用管理服务器。 如果所有网关服务器都连接到单个管理服务器，而没有连接到该服务器的其他代理，在持续中断时可以加快恢复时间。 管理服务器上的有效负载是直接或通过网关服务器向它报告的代理总数。
• 为了防止网关服务器启动与管理服务器的通信，包括配置为在多个管理服务器之间故障转移以实现高可用性时，网关审批工具包括 /ManagementServerInitiatesConnection 命令行参数。 这允许 Operations Manager 在外围网络或其他网络环境中部署系统并且只能从 Intranet 启动通信时符合客户的安全策略。

Web 控制台服务器

Web 控制台提供可通过 Web 浏览器访问的管理组的接口。 它没有操作控制台的完整功能，并且仅提供对“监视”和“我的工作区”视图的访问权限。 Web 控制台提供对所有监视数据和任务的访问权限，这些监视数据和任务是可从操作控制台针对受监视的计算机运行的操作。 访问 Web 控制台中的数据的限制与访问操作控制台中的内容的限制相同。

报表服务器

System Center - Operations Manager 的报表安装在 SQL Server Reporting Services 上（由正在使用的 Operations Manager 版本支持），Operations Manager Reporting 支持的唯一有效配置是本机模式。

注意

安装 System Center – Operations Manager Reporting Services 可将 SQL 报告 Services 实例的安全性与 Operations Manager 基于角色的安全性相集成。 请勿在此 SQL Server 的同一实例中安装任何其他 Reporting Services 应用程序。

Operations Manager 报表服务器组件可以安装在运行 SQL Server 2014 或 2016 Reporting Services 或不同计算机上的同一台服务器上。 为了获得最佳性能，尤其是在具有大量并行报表生成的企业环境中，而交互式报表或计划报表同时处理时，需要纵向扩展以处理更多并发用户和更大的报表执行负载。 建议 Operations Manager Reporting Service 不与托管数据仓库数据库的同一 SQL Server 并安装在专用系统上。

操作数据库

操作数据库是一个 SQL Server 数据库，用于保存管理组的所有操作数据、配置信息和监视规则。 Operations Manager 数据库是管理组的单个故障源，因此可以使用支持的群集配置实现高可用性。

若要使此数据库的大小保持一致，Operations Manager 中的整理设置指定数据可能保留在其中的时间长度。 默认情况下，此持续时间为 7（7） 天。

报告数据仓库数据库

报告数据仓库是一个 SQL Server 数据库，用于收集和存储用于长期报告的操作数据。 此数据直接从从规则写入，这些规则从操作数据库中收集数据以报告和从数据同步进程进行报告。 Operations Manager 会自动执行数据仓库的维护，包括聚合、整理和优化。

下表突出显示了数据仓库数据库初始设置后的默认数据类型和保留期。

数据集	聚合类型	保留期(天)
Alert	原始	400
客户端监视	原始	30
客户端监视	每日	400
事件	原始	100
性能	原始	10
性能	每小时	400
性能	每日	400
State	原始	180
State	每小时	400
State	每日	400

数据仓库可以为多个管理组提供服务。 这样，单个报表就可以合并整个组织内所有计算机中的数据。

与 Operations Manager 数据库一样，数据仓库数据库可以聚集以实现高可用性。 如果未群集化，应仔细监视它，以便可以快速解决任何问题。

ACS 收集器

ACS 收集器接收并处理来自 ACS 转发器的事件，并将此数据发送至 ACS 数据库。 此处理包括反汇编数据，以便它可以分散到 ACS 数据库中的多个表，最大限度地减少数据冗余并应用筛选器，以便不会将不必要的事件添加到 ACS 数据库。

ACS 数据库

ACS 数据库是 ACS 部署内审核策略生成的事件的中心库。 可以在 ACS 收集器所在的计算机上找到 ACS 数据库，但是为了获得最佳性能，每个 ACS 数据库应该安装在专用的服务器上。 默认情况下，数据将保留 14 天（14 天）。

ACS 转发器

Operations Manager 代理中包括 ACS 转发器上运行的服务。 默认情况下，安装 Operations Manager 代理时会安装此服务，但不启用此服务。 可以使用“启用审核收集”任务或使用 PowerShell 一次性为多个代理计算机启用此服务。 启用此服务之后，所有安全事件除被发送到本地安全日志之外，还会被发送到 ACS 收集器。

设计注意事项

在决定实现单个或多个管理组时，应考虑以下因素：

• 增加容量。 Operations Manager 对单个管理组可以支持的代理数没有内置限制。 根据你使用的硬件以及监视负载（部署的更多管理包意味着管理组更高的监视负载），可能需要多个管理组才能保持可接受的性能。
• 合并视图。 当多个管理组用于监视环境时，需要一种机制来提供监视和警报数据的合并视图。 这可以通过部署其他管理组（可能或可能没有任何监视责任）来实现，这些管理组有权访问所有其他管理组中的所有数据。 然后，这些管理组据说是相连的。 用于提供数据的合并视图的管理组称为“本地管理组”，其他提供数据的管理组称为“连接的管理组”。
• 安全性和管理。 出于安全和管理原因对管理组进行分区的概念与将管理权限委派到不同的管理组的概念类似。 你的公司可能包含多个 IT 组，每个组都有其自己的责任区域。 该区域可能是特定的地理区域或业务部门。 例如，在控股公司的情况下，它可以是子公司之一。 如果存在这种从集中式 IT 组授予管理权限的完全委派，则在每个区域中实现管理组结构可能很有用。 然后，可以将它们配置为连接管理组，并将其配置为驻留在集中式 IT 数据中心的本地管理组。
• 已安装的语言。 安装了 Operations Manager 服务器角色的所有服务器必须使用相同的语言进行安装。 也就是说，无法使用英语版本的 Operations Manager 2012 R2 安装管理服务器，然后使用日语版本部署操作控制台。 如果监视需要跨越多种语言，则操作员的每种语言都需要一个额外的管理组。
• 生产和预生产功能。 在 Operations Manager 中，建议使用生产实现来监视生产应用程序和预生产实现，该实现与生产环境交互最少。 预生产管理组在迁移到生产环境之前用于测试和优化管理包功能。 此外，一些公司为新生成的服务器采用过渡环境，以便在投入生产之前将新生成的服务器置于燃烧期。 预生产管理组可用于监视过渡环境，以确保在生产推出之前服务器的运行状况。
• 专用 ACS 功能。 如果你的要求包括需要收集 Windows 审核安全日志事件或 UNIX/Linux 安全事件，你将实现审核收集服务（ACS）。 如果公司的安全要求要求要求管理 ACS 函数由管理生产环境的管理组以外的管理组控制和管理 ACS 函数，则实施支持 ACS 函数的管理组可能很有用。
• 灾难恢复功能。 在 Operations Manager 中，与 Operations Manager 数据库的所有交互在提交到数据库之前记录在事务日志中。 可以将这些事务日志发送到运行Microsoft SQL Server 的另一台服务器，并将其提交到 Operations Manager 数据库的副本。 此功能是在同一管理组中两个 SQL Server 之间提供 Operations Manager 操作数据库的冗余的选项。 需要执行受控故障转移时，管理组中的管理服务器需要注册表更改才能引用和与辅助 SQL Server 通信。 可以部署故障转移管理组，该组与主管理组（管理包、替代、通知订阅、安全性等）的确切配置相匹配，代理配置为向这两个管理组报告。 如果整个主管理组因任何原因变得不可用，则监视环境不会停机。 此解决方案可确保管理组的服务连续性，以及操作监视的零损失。

在生产环境中部署 System Center Operations Manager 之前，请规划管理组的设计。 在规划阶段，了解 IT 服务组件（即基础结构和应用程序级别），以及支持它们的系统和设备数量、如何集成和支持事件和问题管理流程，以及如何可视化不同事件升级支持层、工程、服务使用者和管理的数据。

连接的管理组

许多具有多个地理位置的服务器的企业需要对这些服务器进行集中监视。 下图所示的连接管理组配置是一组旨在创建分层系统管理基础结构的工作流过程。

此配置可用于实现集中监视。 它旨在支持查看警报和监视数据，并针对连接的管理组的托管对象启动任务。

通过连接 Operations Manager 管理组，可以维护集中式监视功能，同时启用：

• 监视比单个管理组可以监视的更多管理对象。
• 根据逻辑业务部门（如“营销”或物理位置（如罗马）隔离监视活动。

连接管理组时不会部署任何新服务器，而是允许本地管理组访问连接管理组中的警报和发现信息。 这样，你可以在一个操作控制台中查看多个管理组中的所有警报和其他监视数据并与其交互。 此外，你可以在连接的管理组的监视计算机上运行任务。 若要了解如何连接管理组，请参阅 Operations Manager 中的连接管理组。

已安装的语言

Operations Manager 管理组仅支持一种已安装的语言。 如果你要监视的整个 IT 环境由多种已安装的语言，则需要为每种语言创建单独的管理组。