在之前的一系列评测中，我们已经对Orchestrator与配置管理器两大SystemCenter2012模块进行了一番探讨。但在今天的议题中，我们的研究对象则是应用控制器、虚拟机管理器以及数据保护管理器——它们更为精致，在某些情况下功能也更加强大。

　　其中最有趣的组合当数新的应用控制器与虚拟机管理器(简称VMM)这对搭档。两款模块可谓相得益彰、水乳交融。应用控制器的作用是在设施中部署虚拟机，其应用范围涵盖私有云、旧式本地管理环境或者公共云，当然WindowsAzure也包括在内。

　　尽管VMM本身在控制能力上不像Citrix及VMware等工具在自家平台上表现得那么深入，但用户可以通过这些微软管理工具将微软Hyper-V、CitrixXenServer以及VMwarevSphere等来自不同厂商的平台杂糅成混合型业务环境，从这个角度来看VMM同样具备很强的存在感。

　　最后也是最“无聊”的模块就是数据保护管理器了，之所以说它无聊，是因为数据保护机制是任何一款系统都必不可少的组成部分——但这绝不代表它在功能上马马虎虎。数据保护管理器由一系列监控备份组件构成，专为微软应用及服务器提供保护。尽管缺乏惊喜，但我们仍然高兴地发现其中包含的一项新功能：裸机还原。这项功能不仅能帮设备回到初始状态，更可以帮助用户在紧急时刻有效减少损失。

　　上述组件都要通过UnifiedInstaller进行安装；安装向导会提醒用户最好不要单独安装这些模块。与其它SystemCenter2012应用一样，它们的运行也需要微软SQLServer2008Review或其它SQLServer的支持(后者作为后备方案)。

　　在我们的测试中，最具吸引力也最具全局特性的功能要数VMM对CitrixXenServer及VMwarevSphereESXi基础设施的综合控制能力。虽然我们已经有Hyper-V，鉴于测试对象是Hyper-V的两大主要竞争对手，且运行的服务器实例负载相当之高，因此我们还是决定看看VMM的表现。我们还从微软那里搞来了Azure账户，专门用于此次云控制测试。

　　在准备过程中，我们不得不根据实际情况做出数项调整。举例来说，我们在戴尔CompellentSAN中托管的大型存储池采用的是网络文件系统(简称NFS)，但要使用这些资源池，VMM要求我们将资源属性变更为“可读写”——这么干会给我们的工作流带来安全隐患。然而为了弄清楚VMM2012的真实水平(并通过应用控制器实现进一步管理)，我们权衡再三还是决定进行修改。

　　接下来，我们按名称引导VMM找到我们的Citrix与ESXi管理程序设备；VMM反应神速，很快找到了各种服务器类型下的活跃虚拟机及已经关闭的虚拟机合集。XenServer与VMware所对应的每种资源类型都被启用，逐步安装各种相关工具，并针对交互结构调整了虚拟机布局。将活跃虚拟机从一个平台迁移到另一个并不现实，但在特定情况下将其从一种结构类型中迁移到另一种同类管理程序下则可以实现。

　　经过我们对概念可行性的验证，XenServer到XenServer与vSphere到vSphere两种迁移均获得了成功。这并不代表像资源匹配及高级存储池优化等高级管理程序基础设施功能也行得通，事实证明它们无法正常工作。但我们发现某些简单功能还是能够实现的，例如微软公布的“单窗口面板”控制，它在三套托管着Windows2008R2服务器实例的不同管理程序中都能顺利起效。

　　总体来说，概念还是能够实现的——尽管某些高级功能(尤其是在VMwarevSphere方面)仍然无法执行。

　　VMM2012还有另一种安装方案，即通过IIS访问一套自助门户。选择这种安装方案会给配置工作带来新的难题，新管理层的介入使我们不得不定义更多角色、配置更多资源。但如此一来我们就实现了通过Web进行虚拟机配置，同时获得了类似于接入装置的服务角色，也算是物有所值。

　　VMM2012中用于定位虚拟机的内部基础设施通路大部分处于隐藏状态，从而实现了对类装置及应用实例部署的进一步支持。服务通过特定的提供方式帮助用户自主检测已经部署完成的装置或虚拟机合集，但ActiveDirectory用户角色则必须通过相当复杂的组策略对象登记来接受控制，这就要求我们对自助门户进行严格管理以避免滥用情况的发生。

　　应用控制器则将资源(包括公共或者私有托管下的资源)分割后分配到设施内部。我们通过微软提供的Azure账户进行了虚拟机实例由私有网络向Azure实例迁移的测试，结果发现只要完成初始设定(包括Azure证书、密钥以及网络连接)，就可以通过拖拽的方式轻松把虚拟机实例资源从本地迁移到Azure资源端。这种做法的缺点在于需要占用大量网络流量，由此带来的成本要高于在Azure尤其是SQLServer中直接建立实例。

　　应用控制器还能够将虚拟机群组打包成一个对象，以实现对多个虚拟机实例的管理目的，例如由几台网络服务器及一套数据库或服务应用后端所构成的完整环境。应用控制器与PowerShell命令也能够顺利协作，通过脚本的方式将多种管理指令整合在一起，实现添加及删除用户角色等过程的自动化全局操作。

　　Shell脚本可以无限次重复使用，使频繁点击UI的操作实现自动化。但缺点在于不同PowerShell脚本多少有些自文档化，其代码可能并不符合标准化最佳实践，进而导致应用控制器对这些脚本产生依赖性。

　　除此之外，我们还可以通过Windows部署服务(简称WDS)在裸机中部署虚拟机。该功能借助PXE(即预启动执行环境)从根本上实现了虚拟机通过本地网络的全面部署。依照程序，一套虚拟机在被激活后会向DHCP服务器发出PXE信号，而服务器则反过来根据设置将事先选定的镜像加载到虚拟机当中。这项功能必须在本地网络中实现(而且据我们得到的消息，仅支持IPv4)；当然，大家也可以对路由器进行编程来将初始PXE流量发送至其它目的地，进而完成虚拟机的网络启动请求。初始化完成后，服务器即可通过各种途径访问并加载其它应用程序或者资源本身。

　　总体而言，我们经常通过修改虚拟硬盘(简称VHD)将虚拟机镜像迁移至PXE启动服务器(简称WDS)——但就喜好来说，我们更倾向于利用实验室中的NFS，它对于各种操作系统的良好支持让裸机有了更多选择。

　　应用控制器2012与VMM2012的组合相当强大，而且能够以非常简洁的方式将所有受控制资源合并到SystemCenter2012当中。我们并不认为该组合会替代现有产品中的同类功能，而且WindowsServer2012各版本的推出与SystemCenter2012服务包的发布也会让这两款功能性模块迎来新的改变。很多原本费时费力的虚拟机及其管理成本问题都会随着新版本的出炉而得到解决。

　　SystemCenter2012数据保护管理器(简称DPM)

　　DPM的此次升级版本更专注于对微软应用的处理，例如SharePoint服务、SQLServer以及Exchange等。随着磁带这一分级存储方案的逐渐落伍，我们终于能够摆脱令人头痛的磁带存储测试，进而更轻松地在实验室中研究SAN存储。

　　合规性、监管机制及诉讼支持已经成为企业在面对在线联机检索事务时的首要诉求。DPM在对应用程序的“行为”记录方面表现出色，当然仅限于微软应用。DPM目前还无法扩展到其它操作系统或文件系统当中。

　　根据流程，DPM会首先分配保护组，然后分配存储池。DPM存储池也可以采用自定义分卷分配。微软公司建议用户将存储池的大小设定为需要“保护”的数据量的两倍。我们可以建立数据恢复点，但每个对象的总恢复点数量不能超过64个——这一限制不针对应用数据，仅仅约束快照恢复点的最大数量。根据系统规划指南上的说明，我们每一天可以为每个保护组设定八个计划恢复点，这个数量还是比较合理的。

　　微软建议每台DPM服务器的最大数据快照存储数量不要超过9000个，这些快照可以来自客户端、服务器或者基于服务器的各类应用程序。官方推荐用户根据变量公式计算需要保留的磁盘空间，具体情况要看企业数据的变动频率以及网络结构中检索活动跨越所带来的速度限制。我们还发现，微软针对各类用户在备份、检索、恢复等方面的需要给出了一系列建议，大家需要以实际情况为基础决定使用什么样的组合、存储、网络及频率以满足可用性及数据恢复方面的要求。

　　我们强烈建议大家利用UnifiedInstaller进行DPM及其它SystemCenter2012模块的安装，SQLServer2008R2同样不可或缺。事实上，我们尝试的第一个备份项目就是SQLServer数据库。尽管数据库及表单的体积并不大，但设置过程还是要比单纯拷贝慢得多。

　　我们在CompellentSAN中单独划分出一部分作为SQLServerR2的iSCSI目标，以作为测试之用。在五天的检测过程中，我们发现DPM2012的保护政策会自动保留五个快照文件。如果需要，这些快照的生成时间可以设定在业务不太繁忙的时段，但我们根据建议花了15分钟进行增量同步。

　　由于我们的测试环境并不繁忙，因此流量测试在最低强度下逐步执行。为了充分利用本地网络流量优势，企业用户可以根据需要添加额外的DPM服务器；但在SQLServer流量过大或者连接到DPM服务器的存储类型过多时，大家恐怕也得再加几台设备。

　　某些企业能够容忍同线路传输及网络iSCSI流量，但对于其它一些希望SAN设施专物专用或者对DPM存储连接速度要求极高的企业而言，似乎还需要更好的解决方案。微软公司建议用户在通过广域网连接使用DPM时保持至少512Kbps的带宽，但除非这条链接专门用于DPM传输或者数据传输量极小，否则必然会面临严重的数据堵塞。

　　在实验室中，我们利用3Mbps的网络连接通过DPM实例对一套Windows7虚拟机及一台笔记本中的数据进行备份，传输目标则是位于70英里之外的网络运营中心。两套备份内容的数据量都在21GB上下。运营中心里使用的主机是惠普DL580、16核心处理器、两套虚拟机实例并与另一套SQLServer和闲置SystemCenter2012模块相连通。而在实验室中，我们使用的是戴尔CompellentSAN——前面已经提到过了。

　　在单独运行的情况下，DPM在完整备份Windows7实例工作上花费了94分钟。接着是对两套内容的同时备份，耗时为109分钟。同时进行三个备份任务的成绩为126分钟。最后，我们同时开启四个备份任务的总计耗时为177分钟，这时候实验室里几乎所有有用的信息都被备份了一遍。

　　大家也可以把网卡整合起来为DPM服务，不过因为带宽有限，这样做对于我们的广域网连接性能并不会带来什么提升。但在其它比较强力的千兆以太网LAN环境中或者DPM所在的服务器场附近，把网卡“组队”的主意还是很有价值的。

　　数据保护管理器2012的运作方式比其它SystemCenter2012模块更加自主，不过它的存在就是一种额外的负担，所以独立出来也很正常。当然，对于大多数管理员来说，独立存在的备份机制令人头痛而且极为无聊——但也没有办法。

　　这种与其它模块间的集成化欠缺使得数据保护管理器的使用方式也与应用控制器加VMM的组合有所不同。我们无法针对任何模块直接理解其备份机制、需要注意的恢复点以及其存在的理由。然而抛开集成不谈，DPM在微软自家的系统结构中所承担的工作确实枯燥而繁重。正如其它模块一样，DPM要求管理员根据各类Windows系统流程及自身需求做出规则，进而将恢复、存储池、网络流量、虚拟机池以及流程对象等全部内容涵盖在保护之下。

　　裸机恢复早在Windows2008系列版本中也得到了支持，但支持系统状态保护快照的WindowsXP到2003则不具备此功能(我们仍在检测2003R2的支持能力)。为了实现裸机恢复，我们利用新保护组创建向导在受保护服务器组中添加了一台额外的测试服务器。

　　复制/备份分卷拥有额外的存储空间，默认为30GB，并可根据需要进一步添加。参照官方的说明，已经设定好的额外空间也可以随时变更，但我们的测试很简单：拿出准备好的Windows2008R2服务器实例并通过裸机恢复将其安装到新设备当中。这时会出现向导程序，允许我们选择需要的备份文件，几下点击、一杯咖啡，恢复工作就结束了。

　　总结

　　在本次测试中，我们只在PowerShell版本中使用了独立的命令操作，而没有将其整合到脚本当中。之所以回避脚本，是因为我们害怕搞错标签或者把它们弄丢。脚本命令在带来强大操作便捷性的同时，也需要管理员进行更严格的控制。也许脚本生成器会把它们放在元数据中以便于调用，但这无疑会给测试带来难以预估的影响。

　　SystemCenter2012虽然可以进行最小化部署，但每位用户都不应该与其卓越的功能模块失之交臂，更何况最小化方案还会给重复安装带来其它麻烦。在微软基础设施(尤其是Hyper-V云)上砸下大笔资金的中型乃至大型企业会很快发现应用控制器与VMM2012这一组合将成为业务流程中不可或缺的至宝。

　　SystemCenter2012软件包囊括了非常全面的控制机制(包括Orchestrator与配置管理器组件，二者都能被数据保护管理器的备份功能所覆盖)，用户根本不可能在缺乏详细规划及培训顺利适应其强大功能。根据官方的建议，服务器的最低数量为九台；不过我们完全可以将它们通通纳入同一套虚拟服务器当中(需要DPM实例)。而且还要再次强调，虽然这是一套专为Windows量身订做的控制方案，但在其它各系统平台上的表现同样可圈可点。