在SCOM 2007 SP1,R2这些之前的版本，是父子拓扑的，这意味着在管理组中，根管理服务器（RMS）作为一个或多个管理服务器（MS）或网关服务器(Gateway)的父节点。RMS在管理组中有许多独特的职责。

RMS 提供了以下服务：

1.控制台访问

2.基于角色的访问控制

3.向代理分发配置

4.其他管理系统的连接器

5.报警通知

6.健康状况聚合

7.组成员计算

8.可用性

9.依赖监视

10.数据库数据删除和聚合

11.基于对象的管理模式


RMS也引出了以下问题:

1.性能和规模瓶颈

2.单点故障（RMS）

3.依赖集群的高可用性


以上这些挑战对于大多数IT和执行团队很重要的一点就是，需要确保RMS高可用和灾难易恢复。


在SCOM2012中主要变化——去除RMS

在一些深入的调查后，我们决定从SCOM的拓扑结构中去除RMS。这意味着我们需要一个方法去分散RMS承担的工作负载。这就产生了以下三点：

1.Sdk服务(SystemCenter Access Service)–确保这一服务在所有管理服

务器上运行，并且其他任何SDK的客户端都能连接到它。

2.配置服务(SystemCenter Management Configuration Service)-（负责检

测并分发新的配置管理组中的Health服务）联合每个SCOM服务器上的配置服

务，让它们一起工作，保证整个工作组的配置是最新的。

3.Health 服务 (System Center Management Service)- 平衡管组中的所有管

理服务器之间的工作负载，确保在故障时重新分配。


详解以上3个服务：

SDK 服务

在SCOM2012中，这一服务在每个管理服务器安装时都会自动运行。我们支持任何SDK客户端连接到任意的管理服务器。在Beta版中，您需要在SDK服务中配置NLB来实现自动故障转移。


配置服务

为了联合配置服务，我们需要完全重写配置服务。您应该还记得在SCOM2007版本的RMS始终需要大量的内存维持正常工作。其中一个主要原因就是配置服务。每次配置服务启动时，它会读取操作数据库，并将对象实例加载到内存中的XML中。在更大的管理组，这个档会很容易地增长到超过6GB。配置服务使用此文件，对操作数据库进行比较，检测变化并分发新的配置给客户端的Health服务。现在每个管理服务器都会运行配置服务，再也没有理由在内存中存储这一档了。配置服务会将这一文件存储在中央数据库中（操作数据库），所有管理组中的配置服务会实时更新并用来检测配置变化。这一设计的一大优势是，启动配合服务更快速了。一旦数据库被最初创建，在随后的启动配置服务并不需要从头开始重新构建这个数据库，而只是维护它。因此，在重启后分发配置更快。这是针对SCOM2007版本中对一个大型管理组会占用一个小时来启动向代理商分发配置这一问题的一个重大改进。


Health 服务（资源池）

为了将RMS的工作负载分发到所有管理服务器上，我们需要开发一种机制，使得管理服务器上的每个Health服务能独立的工作，同时，能意识到其他管理服务器上运行的工作负载。这一机制帮助我们确保没有重复的工作流或丢失工作流。为了做到这个，我们在SCOM2012中加入了新的特性，叫做资源池。资源池是一个Health服务的集合，用于共同管理池中实例。针对实例的工作流被资源池中的Health服务加载和管理。如果资源池中的Health服务故障了，池中其他的Health服务会继续它的工作。我们也用资源池来提高其他产品特性的可行性，例如Networking和Unix monitoring。


原文参见：

http://blogs.technet.com/b/momteam/archive/2011/08/22/topology-changes-in-system-center-2012-operations-manager-overview.aspx