Share via


SCOM2012 的拓扑变化

【原文作者Rob Kuehfus】

在这一篇博客里,我将解释SCOM 2012的架构拓扑变化。本文并不是深层次探讨那些新特性是如何工作的,而更多的是对于新特性,以及相应变化的一个综述。在接下来的几个月里,我们(SCOM团队)会写更多文章来探讨相关技术细节。

首要的事情(回顾)

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

RMS 提供了以下服务:

  • 控制台访问
  • 基于角色的访问控制
  • 向代理分发配置
  • 其他管理系统的连接器
  • 报警通知
  • 健康状况聚合
  • 组成员计算
  • 可用性
  • 依赖监视
  • 数据库数据删除和聚合
  • 基于对象的管理模式

RMS也引出了以下问题

  • 性能和规模瓶颈
  • 单点故障(RMS)
  • 依赖集群的高可用性

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

 

目前有两种实现方式

1.  建立根管理服务器集群(如下图所示)

2.  将SCOM管理服务器 (MS) 提升为根管理服务器 (RMS)

不幸的是,以上这两种方式都会产生额外的复杂性并增加IT和执行团队的负担。Windows集群配置复杂,而且需要额外的共享存储。给RMS集群打补丁繁琐且容易导致管理组的不稳定。而提升SCOM管理服务器 (MS) 是手动的过程,需要人为运行某些的命令行工具来改变在报表服务器(Reporting Server), 网页控制台(Web Console),和其他管理服务器上的一些配置文件以及注册表。取决于客户的服务级别协议(SLA)对其商业运行的需要,客户一般会选择这两种实现方式的一种,或者两个,来确保管理组达到某种程序的可用性。

此外,根管理服务器(RMS)的单点故障会产生了一个瓶颈,限制了单个管理组能支持多少Windows 代理,Unix代理和控制台的规模。

在SCOM 2012产品规划阶段,我们意识到这是最该解决的问题。去除单点故障的问题,我们能使客户得到更高的系统可用性,并且花更少的钱去维护SCOM系统。此外,我们还扩大了管理组的规模,以支持其他SCOM 2012的新特性,如网络监控(Network Monitoring) 和应用程序监控(Application Monitoring)

主要变化(去除了RMS

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

  1. Sdk服务 (System Center Access Service) – 确保这一服务在所有管理服务器上运行,并且其他任何SDK的客户端都能连接到它。
  2. 配置服务 (System Center Management Configuration Service) -(负责检测并分发新的配置管理组中的Health服务)联合每个SCOM服务器上的配置服务,让它们一起工作,保证整个工作组的配置是最新的
  3. Health 服务 (System Center Management Service) -

平衡管组中的所有管理服务器之间的工作负载,确保在故障时重新分配。

SDK 服务

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

配置服务

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

Health 服务(资源池)

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

 

为了分散RMS特定的工作负载,我们默认创建三个资源池。

  • All Management Servers Resource Pool - 我们重新将大多数RMS具体实例和工作流放入到这个池中。默认情况下,如果一个实例没有“should manage”关系组的话,配置服务(Configuration Service) 会将该实例指定到这个池中

  • Notifications Resource Pool – 我们将告警订阅服务 (Alert Subscription Service)实例重定位到这个池中。我们不使用“All Management Servers Resource Pool”的原因让您可以从池中轻松删除不应该被通知的管理服务器。例如,您可能有三个管理服务器,但只有一个SMS调制解调器。您会从池中删除其它管理服务器,以便没有调制解调器的服务器的情况下不会运行“Notification”的工作流。
  • AD Assignment Resource Pool – 同样的,我们将AD集成工作流 (workflow)放置于这个池中,因此您可以更容易控制AD指派工作流运行的地方。

注意到上面的截屏中,我们有一列叫做“成员(Membership)”,对于默认池,它设置为自动。这意味着所有管理组中的管理服务器自动成为这些池的成员。为了改变它,您需要打开PowerShell运行一个脚本(如下)

Get-SCOMResourcePool –Name “AD Assignment Resource Pool” | Set-SCOMResourcePool –EnableAutomaticMembership $FALSE

现在我可以右击“AD Assignment Resource Pool”的属性并修改管理服务器的成员。注:管理组新添加的管理服务器将不再自动成为这个资源池的成员。

到这个地方,您可能想知道那些运行在RMS上,非SCOM产品组提供的工作流(如微软不同团队或其它软件提供商管理包)会怎么样。为了使我们不打破向下兼容性,并支持之前老版本的管理包,我们决定保留Root Management Server实例,并在管理组中的管理服务器加了一个特殊的角色,叫做RMS 模拟器。RMS模拟器仅仅是为了传统管理包的向下兼容,绝不是为了使管理组正常工作而必需要的。

打开SCOM控制台,选择到管理->管理服务器,您就可以轻松分辨出哪一个是RMS模拟器,其中有一列就叫做“RMS 模拟器”。默认情况下安装在管理组的第一个管理服务器是RMS模拟器。当升级OM12时之前的RMS成为RMS模拟器。注:当使用UpgradeManagementGroup开关在一个非RMS管理服务器上进行升级时,RMS模拟器就是您运行升级的那台服务器。我们将深入到更详细的安装和升级的变化。

 

我们提供了PowerShell 命令行将RMS模拟器总一个转移到另一个上,以防担任RMS模拟器的管理服务器出故障了。

• 在PowerShell中识别当前 RMS 模拟器

get-SCOMRMSemulator

•移至另一个管理服务器

–首先将一个新的RMS模拟器管理指定为一个变量

$MS = get-scommanagementserver –Name <FQDN of Management Server>

Set-SCOMRMSEmulator $MS

•删除RMS模拟器

Remove-SCOMRMSEmulator

–输入 “Y” 同意

–运行get-SCOMRMSemulator 来验证是否删除. 您应该看到一个消息,说没有发现RMS模拟器角色.

•将RMS模拟器角色加入MG

–首先将一个新的RMS模拟器管理指定为一个变量

$MS = get-scommanagementserver –Name <FQDN of Management Server>

Set-SCOMRMSEmulator $MS

–运行“get-SCOMRMSEmulator” 来验证是否创建。

 

设计考虑因素

 当您规划OM12管理组拓扑结构的变化时,有几件事情要记住。 

  1. 由于引入了资源池的原因,建议所有的管理服务器延迟小于5ms。这意味着,如果您正在使用多个数据中心或站点的服务器,我们建议您将所有管理服务器移至一个数据中心,并在其他站点使用网关服务器。
  2. 产品建议,在任何时候,管理组中始终有两个管理服务器。通过这样做,您的管理组将一直具备高可用性,灾难备份也更简单。

我希望这篇文章提供了足够信息,让能着手设计SCOM2012拓扑。在本系列的下一篇文章将有关安装和升级的变化。

 注:原文作者为微软产品经理Rob Kuehfus发布于https://blogs.technet.com/b/momteam/archive/2011/08/22/topology-changes-in-system-center-2012-operations-manager-overview.aspx