【IT168 虚拟化频道】Operations Manager 2007是微软System Center的一款重要组件。System Center Operations Manager 2007 为企业 IT 环境提供端对端监视。Operations Manager 可以监视数千个服务器、应用程序和客户端，并为其运行状况状态提供全面视图。这些视图是快速敏捷响应可能影响 IT 部门提供给客户的服务可用性的事件的关键。
规划各个 Operations Manager 服务器组件时有其它注意事项和非常好的做法。
根管理服务器准则和非常好的做法
在 RMS 上，最关键的资源是 RAM 和 CPU，因为 RMS 执行的很多操作都占用大量内存，因此产生过度分页。影响 RMS 负荷的因素包括：
管理组中的代理数 - 因为 RMS 必须计算管理组中所有代理的配置，所以无论代理发送的操作数据卷如何，增加代理数就增加了 RMS 上所需的内存量。
实例空间更改的速率 - 实例空间是 Operations Manager 维护的数据，用于描述管理组中所有被监视的计算机、服务和应用程序。此数据频繁更改时，RMS 上需要更多资源来计算受影响代理的配置更新。将附加管理包导入管理组时，实例空间更改的速率增大。添加新代理至管理组也会暂时增大实例空间更改的速率。
并发操作控制台和其他 SDK 客户端的数量 - 其他 SDK 客户端的示例包括 Web 控制台和许多与 Operations Manager 连接的第三方工具。因为在 RMS 上主持 SDK 服务，所以每个附加连接都使用内存和 CPU。
调整 RMS 大小的一些非常好的做法包括：
使用 64 位硬件和操作系统 - 使用 64 位硬件使您能够轻松增加内存到 4 GB 以上。即使当前的部署不需要大于 4 GB 的 RAM，使用 64 位硬件仍为以后如果需求变化提供了增长空间。
限制 RMS 管理的代理数或消除 RMS 管理的代理 - 在具有较小代理计数的管理组中，通常可以使 RMS 直接管理代理。这样降低了安装所需硬件的总成本。但是，代理数增加时，应考虑限制 RMS 直接管理代理。将代理工作负荷移动到其他管理服务器减小了对 RMS 的硬件需求，通常使得管理服务器性能更好，可靠性更高。
确保至 OperationsManager 数据库和数据仓库的高带宽网络连接 - RMS 与操作数据库和数据仓库频繁通信。一般情况下，这些 SQL 连接比代理和 RMS 之间的连接消耗更多带宽且对网络延迟更敏感。因此，通常应确保 RMS、OperationsManager 数据库和数据仓库数据库位于同一局域网上。
操作数据库准则和非常好的做法
如同所有数据库应用程序一样，操作数据库性能受磁盘子系统性能的影响最大。因为所有 Operations Manager 数据必须流过 OperationsManager 数据库，所以磁盘越快，性能越好。CPU 和内存也影响性能。影响 OperationsManager 数据库上负荷的因素包括：
数据收集的速率 - RMS 与操作数据库和数据仓库频繁通信。一般情况下，这些 SQL 连接比代理和 RMS 之间的连接消耗更多带宽且对网络延迟更敏感。因此，通常应确保 RMS、OperationsManager 数据库和数据仓库数据库位于同一局域网上。
实例空间更改的速率 - 实例空间是 Operations Manager 维护的数据，用于描述管理组中所有被监视的计算机、服务和应用程序。相对于在数据库中写入新的操作数据，在 OperationsManager 数据库中更新此数据成本更高。此外，实例空间数据更改时，RMS 对 Operations Manager 进行更多查询来计算配置和组更改。将附加管理包导入管理组时，实例空间更改的速率增大。添加新代理至管理组也会暂时增大实例空间更改的速率。
并发操作控制台和其他 SDK 客户端 - 操作控制台的每个公开实例从 OperationsManager 数据库读取数据。查询此数据可能占用大量磁盘活动以及 CPU 和 RAM。控制台在事件视图、状态视图、警报视图和性能数据视图中显示大量操作数据，易于将最大负荷置于数据库上。为获得最大可伸缩性，请考虑指定视图作用域，使其仅包括必需的数据。
以下是调整 OperationsManager 数据库服务器大小的一些非常好的做法：
选择合适的磁盘子系统 - OperationsManager 数据库的磁盘子系统是对管理组的总体可伸缩性和性能最关键的组件。数据库的磁盘卷通常应为具有合适轴数的 RAID 0+1。对于此组件，RAID 5 通常是不合适的选择，因为它以性能为代价来优化存储空间。因为在为 OperationsManager 数据库选择磁盘子系统时，主要因素是性能而不是总存储空间，所以 RAID 0+1 更合适。可伸缩性需要不超过单一驱动器的吞吐量时，RAID 1 通常是合适的选择，因为它提供容错能力而没有性能损失。
数据文件和事务日志的放置 - 对于较小型部署，将 SQL 数据文件和事务日志组合到单一物理卷上通常最低本高效，因为事务日志生成的活动量不是很大。但是，代理数增加时，应考虑将 SQL 数据文件和事务日志放置在分开的物理卷上。这就允许事务日志卷更有效地执行读取和写入。这是因为工作负荷将大多由顺序写入组成。单个双轴 RAID 1 卷能够处理大量的顺序写入，应足够用于几乎所有部署，甚至是极大型部署。
使用 64 位硬件和操作系统 - 大量的 RAM 通常对 OperationsManager 数据库有利，这也是一种低成本高效率地减少在此服务器上执行的磁盘活动量的方式。使用 64 位硬件使您能够轻松增加内存到 4 GB 以上。即使当前的部署不需要大于 4 GB 的 RAM，使用 64 位硬件仍为以后如果需求变化提供了增长空间。
使用电池备份写入缓存磁盘控制器 - 测试显示，磁盘控制器上的写入缓存对 OperationsManager 数据库上的工作负荷有利。在磁盘控制器上配置读取缓存与写入缓存比时，建议将 100% 的缓存分配给写入缓存。使用带有任何数据库系统的写入缓存磁盘控制器时，确保它们具有适当的电池备份系统十分重要，这样可以防止在中断的情况下数据丢失。
数据仓库准则和非常好的做法
在 Operations Manager 2007 中，数据几乎实时写入数据仓库中。这使得数据仓库上的负荷类似于 OperationsManager 数据库计算机上的负荷。因为是个 SQL 服务器，所以磁盘子系统对总体性能最为关键，内存和 CPU 紧随其次。Operations Manager Reporting Services 也在数据仓库服务器上放置了稍微不同的负荷。影响数据仓库上负荷的因素包括：
数据插入的速率 - 为允许更有效的报表，除了有限数量的原始数据之外，数据仓库还计算并存储聚合数据。做此额外工作表示，与将操作数据集合到 OperationsManager 数据库相比，将操作数据集合到数据仓库成本可能稍高。该附加成本通常被在数据仓库上处理发现数据减少的成本抵消（与在 OperationsManager 数据库上处理数据相反）。
并发报表用户数 - 因为报表通常汇总大量数据，所以每个报表用户可以在系统上施加很大的负荷。同时运行的报表数量和运行报表的类型影响总体容量需求。通常，查询大日期范围或大量对象的报表需要更多系统资源。
以下是调整数据仓库服务器大小的一些非常好的做法：
选择合适的磁盘子系统 - 因为数据仓库现在是整体数据流过管理组必不可少的一部分，所以为数据仓库选择合适的磁盘子系统非常重要。如同 OperationsManager 数据库一样，RAID 0+1 通常是非常好的选择。一般情况下，数据仓库的磁盘子系统应类似于 OperationsManager 数据库的磁盘子系统。
数据文件和事务日志的放置 - 如同 OperationsManager 数据库一样，代理数增加时，分开 SQL 数据和事务日志通常是合适的选择。如果 OperationsManager 数据库和数据仓库位于同一物理机上，而您想要分开数据和事务日志，必须将 OperationsManager 数据库的事务日志放置于与数据仓库分开的物理卷上。只要大小合适，OperationsManager 数据库和数据仓库的数据文件可以共享同一个物理卷。
使用 64 位硬件和操作系统 - 大量的 RAM 通常对数据仓库有利，这也是一种低成本高效率地减少在此服务器上执行的磁盘活动量的方式。使用 64 位硬件使您能够轻松增加内存到 4 GB 以上。即使当前的部署不需要大于 4 GB 的 RAM，使用 64 位硬件仍为以后如果需求变化提供了增长空间。
对数据仓库使用专用的服务器硬件 - 尽管较小型部署通常可以将 OperationsManager 数据库和数据仓库合并到同一物理机上，但是代理数增加且传入操作数据量也因此增加时，最好将它们分开。如果数据仓库与报表服务器分开，报表性能也会更好。
使用电池备份写入缓存磁盘控制器 - 测试显示，磁盘控制器上的写入缓存对数据仓库上的工作负荷有利。在磁盘控制器上配置读取缓存与写入缓存比时，建议将 100% 的缓存分配给写入缓存。使用带有任何数据库系统的写入缓存磁盘控制器时，确保它们具有适当的电池备份系统十分重要，这样可以防止在中断的情况下数据丢失。
管理服务器准则和非常好的做法
管理服务器上最大部分负荷来自于收集操作数据并将该数据插入 OperationsManager 和数据仓库数据库。值得注意的是，管理服务器直接执行这些操作而不依赖 RMS。管理服务器在内存中执行大多数据队列而不是依赖于速度较慢的磁盘，因此增强了性能。管理服务器最重要的资源是 CPU，但是测试已显示它们通常不需要高端硬件。影响管理服务器上负荷的因素包括：
操作数据收集的速率 - 因为收集操作数据是管理服务器执行的主要活动，所以此速率对服务器总体使用率具有最大影响。但是，测试已显示，管理服务器通常可以用低至中等使用率维持高速率的操作数据处理。影响操作数据收集速率的主要因素是管理组中部署了哪些管理包。
以下是调整管理服务器大小的一些非常好的做法：
不要使用超大管理服务器硬件 - 大多数情况下，使用标准的实用程序服务器就足够于管理服务器执行的工作。遵守本文档中的硬件准则对大多数工作负荷来说都应足够。
代理与管理服务器之比不要超过 3,000:1 - 服务器实际性能将基于所收集的操作数据量变化，但是测试已显示，管理服务器支持 2000 个代理（每个代理有相对大量的操作数据传入）通常没有问题。每个管理服务器管理 2000 个代理是基于测试体验的准则，而不是硬限制。您可能发现，您的环境中的管理服务器能够支持更多或更少的代理。
要最大化 UNIX 或 Linux 计算机与管理服务器之比 (500:1)，请使用专用的管理服务器进行跨平台监视。
每个管理组使用最少量的管理服务器来满足冗余需求 - 部署多个管理服务器的主要原因应是提供冗余和灾难恢复而不是可伸缩性。基于测试，大多数部署将需要三到五个以上的管理服务器来满足这些需求。
网关服务器准则和非常好的做法
网关服务器中继彼此位于 Kerberos 信任边界相反侧的管理服务器和代理之间的通信。网关服务器使用基于证书的身份验证执行与管理服务器的相互身份验证。它使用单个连接进行此操作而不是如代理和管理服务器之间所需的多个连接。这使得对不受信任的域管理基于证书的身份验证更容易且更可管理。影响网关服务器上负荷的因素包括：
操作数据收集的速率 - 影响网关上负荷的主要因素是收集操作数据的速率。此速率是网关所管理的代理数量和管理组内部署的管理包数量的函数
以下是调整网关服务器大小的一些非常好的做法：
网关服务器可能对管理带宽使用率十分有益 - 从性能角度看，建议将网关作为优化低带宽环境中带宽使用率的工具。因为它在所有与管理服务器的所有通信上执行一级压缩。
代理与网关服务器之比不要超过 1,500:1 - 测试已显示，如果每个网关具有 1000 个以上的代理，在持续（多小时）中断造成网关无法与管理服务器通信时，恢复能力可能受到不利影响。如果您需要网关管理比这更多的代理，请考虑使用多个网关服务器。如果注网关恢复时间在您的环境关系重大，而您想要每网关超过 1,500 个代理，强烈建议您测试系统，确保网关和管理服务器之间持续中断后，网关能够快速清空其队列。
对于大量网关和连接至网关的代理，使用专用管理服务器 - 如果将所有网关连接至单个管理服务器而不让其它代理连接至该服务器，则可以加快在持续中断情况下的恢复时间。
应用程序错误监视准则和非常好的做法
用于 AEM 的管理服务器接收来自错误报告客户端数据并将其存储到文件共享中。如果该文件共享为本地共享，这将影响管理服务器。
以下是规划 AEM 的一些非常好的做法：
文件共享磁盘存储可以为本地存储，或在网络连接存储 (NAS) 或存储区域网络 (SAN) 设备上。
用于 AEM 的磁盘应与用于数据仓库或 OperationsManager 数据库的磁盘分开。
如果在分布式文件系统 (DFS) 上设置存储，应禁用 DFS 复制。
网关服务器不应用作 AEM 收集器。
集体客户端监视准则和非常好的做法
通过从多台计算机收集事件和性能数据，并基于系统组聚合数据获得报表和分析来执行集体运行状况监视。例如，从不同类型硬件上的 Windows XP 和 Windows Vista 客户端收集各个内存性能数据。集体运行状况监视聚合此数据并基于特定系统组的内存性能提供报表，例如通过操作系统或硬件供应商。这使得分析总体性能比挖掘长列的各个系统性能报表更容易。集体监视模式还启用了集体级别（而不是各个级别）的警报和监视。
集体客户端监视管理包包括：Information Worker、Windows 客户端、Windows XP、Windows Vista、网络地址协议和其他以客户为本的管理包。
每个客户端由一个通常定期生成摘要事件的代理监视，这些事件用于计算客户端填充的集体运行状况。各个代理上的警报被禁用，因此在客户端上运行的代理不会生成任何警报数据。
根据部署的管理包数量和代理流量，每个管理服务器最多可以管理 3,000 到 4,000 个代理管理的客户端。
规划集体监视客户端的首展时，应以一次不超过 1,000 的批量批准代理，从而允许代理与最新的配置同步。
审核收集服务准则和非常好的做法
ACS 系统的总体性能受 ACS 数据库及其磁盘子系统性能的影响最大。鉴于每秒将有成千上万个事件连续插入，每秒可能有几万个高峰，这一点是显而易见的。在 14 天时间内，大量被监视的设备（包括域控制器）在 ACS 数据库中堆积千吉字节以上的数据并不罕见。以下是用于 ACS 的一些非常好的做法：
对收集器和 SQL Server 使用 64 位硬件和操作系统以及高性能 SAN 解决方案。
将数据库文件与事务日志分开。
如果允许，请使用专用硬件主持 ACS。
使用紧密的筛选器来减少插入数据库中的噪音安全事件数。
仔细规划您的 Windows 审核策略，确保只有相关事件登录到被监视系统。
仅在必要的系统上启用 ACS 转发器。
用足够的空间配置安全事件日志，确保如果与 ACS 收集器的通信丢失，安全事件日志文件不会自行换行并覆盖以前的事件而导致事件数据丢失。
