Compartilhar via

SCOM2012 的拓扑变化

  • Artigo

【原文作者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