微软System Center瞄准云计算和虚拟化

虽然安装仍然很麻烦，但比以前好多了，同时，这也是近年来第一次，SystemCenter的所有模型都进行了同步修改，并且其覆盖面也有所提高。

在SystemCenter2012中，包含了对私有云的控制，虽然其重点更倾向于WindowsAzure—微软的公共云平台;同时，它也支持对虚拟化的控制，尽管其倾向于微软的Hyper-V管理程序，此外，SystemCenter2012还支持CitrixXenServer和VMwareESXi/vSphere中被大量使用(但不是所有)的功能。

SystemsCenter2012的覆盖面还包括大量的其他非Windows设备，例如，你不仅可以使用WindowsPhone，还可以使用苹果的iPad/iPhone的iOS5，或者Android手机(如果它能链接到MicrosoftExchange服务器控制的话)。微软正在试图改变其仅支持Windows的局面，这是我们看到过的微软提供的最平等的覆盖面。虽然扩大覆盖面是好事，但同时，它增加了复杂程度。

我们的评论将分为两部分，第一部分主要关于SC2012的Orchestrator编排器以及SC2012:ConfigurationManager配置管理器。

第二部分则是关于SC2012:ServiceManager服务管理器、AppController、VirtualMachineManager虚拟机管理器和DataProtectionManager数据保护管理器。微软端点保护管理器被排除在外，因为我们没有足够的资源来分析它。

需要什么基础设施

我们需要很多虚拟机形式的硬件，来实现所有模型的完整安装。每个模型至少都需要一个具有40G磁盘和合理内存的服务器/虚拟机实例。在SC2012的模型中，通常是SQLServer2008R2作为引擎。此外，很多模型可能还需要必要的繁重的硬件。

我们不建议在ActiveDirectoryDomain控制器中运行任何模型，因此需要额外的虚拟机实例。

微软想要在企业中发挥主导作用，而我们认为，对于很多以微软为中心的企业而言，SystemCenter如果不那么繁琐的话，可以算是一个很好的选择。

每个模型在安装之前都需要进行规划，如果没有UnifiedInstaller，模型将无法进行安装，这也意味着你需要做一些功课。你要做的功课包括了解每个模型的先决条件(它们都略有不同)，然后部署这些先决条件，例如上述SQLServer，以及在大多数情况下，部署具有不同设置的IIS等。我们发现这是很麻烦的工作。

在完成这些功课后，你就可以使用UnifiedInstaller来安装模型了。

尽管SystemCenter2012组件存在异构性，想都不用想，微软肯定会优先其自己的产品。更有趣的是，它还新增了功能与其竞争对手的高级功能相竞争，同时管理具有竞争性的虚拟化和云基础设施。例如，SystemCenter2012突出了微软Hyper-V基础设施的优势，而SC2012:VirtualMachineManager虚拟机管理器提供对私有云和公共云中的虚拟化实例的管理功能，这个公共云通常意味着，微软的Azure云资源。

通过Hyper-V，VirtualMachineManager虚拟机管理器可以进行裸机安装，这使Windows或者Linux实例(SuSE实例)的管理程序化裸机开始流行。

VirtualMachineManager还可以控制VMwareESX/ESXi实例，但很多VMwarevSphere5中的Vmware功能仍然需要vSphere5。这里的优势在于可以对管理基于Vmware实例中使用的共同任务进行关联控制。XenCenter和Citrix的XenCenter管理同样也是这个道理。

编排器Orchestrator

微软公司于2009年收购了Opalis—IT流程自动化工具，作为Opalis的升级版，Orchestrator可以算得上是最引人注目的模型了。通过RunbookDesigner，Orchestrator可以让Runbook完成复杂的工作，这些Runbook构成的定制脚本生成器可以深入基础设施内部。

Orchestrator模型必须至少有一台服务器，专门用于构建、管理和部署Runbook，Runbook是指令对象，其包含的指令可以用于资源的广泛分配。

Runbook是工作流指令，现在网上已经有一些runbook可用资源，可以添加到Orchestrator中。Runbook也是脚本，脚本可以进行编辑，以及使用与runbook活动(runbook/脚本将要执行的指令)相符的本地具体变量进行替换。

这些脚本还可以被存储，或者放置到工作流程时间表中，然后它们将被事件触发，例如某个应用程序的逐步安装等。

我们发现我们可以使用Orchestrator来安装SQLServer、建立IIS角色和做出必要修改以让Orchestrator运作，但我们发现时已经为时已晚。

我们可以导入runbook，或者使用RunbookDesigner，来获取对脚本的wysiwyg视图。我们还可以在流程中加入依存性以及资产和资源的具体名称，以让Orchestrator制定和执行一些相当复杂的工作。然后RunbookServer会开始运作，RunbookServer第一个添加的是PrimaryRunbookServer，后续服务器在很大程度上将自主运行。这可以让分支机构或者云环境为安装、升级和其他工作流执行自主运行脚本。

我们对在实验室和网络运营中心的服务器之间执行应用程序安装的几个runbook进行了测试。首先，我们根据简单的用户批量点击数据来对它们进行排列。随后，这些事件将被日志记录(微软警告说日志记录数据库将会变得非常巨大，我们纳闷，他们为什么不使用syslog?)。我们可以通过很多方法来控制runbook执行，这取决于被允许的并行工作数量、执行各部分工作时使用的权限以及可以执行的活动类型(包括定制活动等)。

Orchestrator还包含IntegrationPacks(集成包)，这些集成包是让runbook控制ActiveDirectory以及第三方软件的连接点。目前Orchestrator提供针对惠普iLO/OA服务器管理、惠普OperationsManager软件、惠普服务管理器、IBM的TivoliNetcool/OMNIbus基础设施管理套件以及VmwarevSphere的集成包。由于条件所限，我们并没有对这些进行测试。不过我们对我们非常熟悉的Vmware集成包进行了分析。

Orchestrator模型并没有取代vSphere，但它知道如何自动化很多日常任务。在映射很多vSphere信息(地址、机器名、主机平台信息以及管理程序数据存储信息)后，我们能够将ESXi虚拟机从一台机器转移到另一台，但这需要花费很多功夫。

在Vmware环境，对Orchestrator集成包的控制具有限制，特别是当能够使用vSphere5的决策情报来选择存储和资源管理时。

在Orchestrator能够获取一个API，来悄悄地攫取更多基础设施情报信息来移动虚拟机，从而使ESXi服务器实现负载/存储平衡之前，Orchestrator都无法“享受”vSphere控制机制的重要组成部分---这也是Vmware的秘密武器。尽管如此，Orchestrator对Vmware的集成控制仍然非常具有吸引力。

在一般情况下，Orchestrator部分事件用于执行“正常”事件，而其他时候则在监控日志。在运行Orchestrator之前，我们需要进行很多初步规划。然后，在前期阶段，我们需要“操练”runbook，让runbook完成各种各样的工作，其中某些工作可能并不需要自动化。(责任编辑：admin)