【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% 的缓存分配给写入缓存。使用带有任何数据库系统的写入缓存磁盘控制器时，确保它们具有适当的电池备份系统十分重要，这样可以防止在中断的情况下数据丢失。