各位读者朋友，有多少人尝试过对Active Directory(简称AD)进行虚拟化?如果答案是肯定的，你又是否了解或阅读过微软公司针对AD虚拟化所提供的指南、清楚哪些事情该做而哪些不该做?这就是我们本文要讨论的内容。根据微软的客户服务及支持说明，AD是整个Windows Server中引发求助请求最多的项目，而AD虚拟化又是AD当中最令人头痛的话题(至少是之一)。
看看，大家的懒惰引发多少麻烦。好消息是Windows Server 2012已经对AD进行了改进，这就让使我们在偷懒的同时保证公司的业务体系更加安全。
除非大家把时间都花在喝茶扯淡上了，否则作为一位IT人，我们都应该会注意到虚拟化技术逐步覆盖数据中心的逼人气势。历史最悠久——因此也最发达——的虚拟化领域正在于服务器层面。另外，由于虚拟化是云计算的基本构成要素之一，它的普及自然也受到云崛起的积极影响。
如果大家本身就是AD管理员，那么这一趋势就意味着虚拟化团队正尝试把我们手中的AD域控制器(简称DC)也拉进虚拟领域。AD管理员从本质上说属于对风险非常敏感且时刻准备回避的人群(如果我们能面对面交流，我会详细讲解自己——当然不光是我一个人——如何在防御层的眼皮底下管理三万个英特尔用户账户的更新工作)，所以我们对虚拟化介入的***反应很可能是拒绝的——你不能让我用我就用。然而搞虚拟化的家伙却非常顽固，他们不接受简单的拒绝，而是希望了解哪些因素阻碍了将整个AD体系纳入虚拟机的步伐。在英特尔的工作经历中，我成功捍卫了自己的观点。那时候我兴趣出了两个至关重要的理由，其中一个直到今天仍然适用，而另一个则已经被时间所化解。
对AD虚拟化持谨慎态度的原因
安全性是首要原因。当我回绝虚拟化团队的建议时，提出了两点安全性方面的关注重点：客户虚拟机隔离与主机管理。我们之所以关注客户机之间的安全问题，是因为我们并不完全相信虚拟机之间无法互相访问及渗透的说法。不过随着服务器虚拟化技术的日益成熟，这个问题如今已经不再是问题。但第二点理由——关注与主机管理相关的操作安全——目前仍然存在，而且将在可以预见的未来始终扮演不容忽视的重要角色。
主机管理的操作安全如今用更平实些的话来解释，是指我们的虚拟化主机服务器管理员不一定了解与虚拟化AD域控制器有关的注意事项与维护方法。在所有现存的Windows Server版本当中，服务器主机或虚拟化管理员都可以轻松搞砸我们所安装的AD——具体方式包括使用基于镜像的恢复、快照回滚或者虚拟域控制器副本等虚拟产品基础功能。
Windows Server 2008 R2及更早版本分布式特性使其无法理解并接纳虚拟化产品给虚拟域控制器带来的状态变更，因为这些在物理域控制器当中是不可能存在的。正是由于缺乏理解，其设计思路也就没有把这些变更作为考虑事项。分布式系统的逻辑架构可能丧失完整性(尤其是在USN回滚方面)，而且一般说来AD数据完整性问题既难于检测、也不易恢复。微软公司曾经发布过一篇题为《在Hyper-V中运行域控制器》的综合性文章，详细讨论了虚拟化域控制器的管理话题——其中还对USN回滚以专门章节加以阐述。
Server 2012如何保障AD虚拟化安全
让AD在虚拟环境中获得可靠的安全性是AD团队追求的首要目标，而他们在Server 2012中也用实际表现回应了我们的呼声。他们提高的不仅仅是安全全，而且让AD有能力享受由虚拟化功能带来的一切优势。从概念上讲，整个实现方式其实并不复杂。首先，我们需要明确回滚操作的发生时间;其次，域控制器必须既保持完整性又能够正常实现功能。
为了实现***项要求，执行变更的层(也就是管理程序)需要标记回滚的发生时间，并通过虚拟化堆栈将其作为通信内容。应用程序随之进行接收。这个过程显然需要开发人员对管理程序、OS以及AD应用程序的设计做出改变。这种标记机制被称为VM-GenerationID。
这套VM-GenerationID(或简称为VM Gen ID)是一个128位的值，其中包含着当前虚拟机的状态，由管理程序保有。当虚拟机随时间推移而不断发生变化，VM Gen ID却始终保持初始状态。一旦虚拟机发生回滚——无论是基于镜像还是快照——该ID才会有所变动。这个ID映射虚拟机内存中的某个地址，因此随时可被虚拟中运行着的应用程序所调用。那么域控制器怎么会知道自己的VM Gen ID有没有发生改变呢?当Server 2012域控制器进行初始化(或更新)时，它会在安装时把VM Gen ID标记的值保存在AD副本中域控制器计算目标的msDS-GenerationID属性当中。这样当域控制器重新启动或处理事务(例如属性更新)时，它就会将内存中的现有VM Gen ID值与保存在AD中的值进行比较。倘若二者不同，则意味着虚拟机已经进行过回滚，而域控制器必须采取相应步骤以保持其完整性。VM Gen ID独立于管理程序之外，而且已经有一些管理程序供应商(例如VMware)开始将这项功能集成到自家产品当中。
一旦检测到虚拟机回滚现象，域控制器会执行两项操作以防止USN回滚：首先，重置AD数据库的invocationID并清空其本地相关标记(简称RID)池。如果标准恢复流程与域控制器有所冲突，那么同时触发invocationID(即本地数据库的版本号)重置以排除其它机制，这就确保了域控制器始终拥有与其它域控制器一致的更新内容(包括它自己创建的新内容)，最终免受回滚操作所影响。RID池是指利用RID主控机制整理的与域控制器相关的数百个RID(域惟一SID的一部分)，旨在针对域控制器所创建的新安全原则生成SID。清空RID池与重新整理RID主控对象确保了域中不存在重复的SID。请注意，上述流程并不会危及我们的定期备份机制。
从技术角度讲AD是能够实现全面虚拟化的，但截至本文发稿时，微软的AD团队还没有最终决定以官方形式公布这一结论。但大家是否愿意对AD进行全面虚拟化?在做出决策之前，大家***从宏观角度审视这一问题。现代化数据中心已经(或者必然将要)在AD服务与不可靠的硬件之间搭建起一个又一个抽象层。大家一定还记得“把鸡蛋放进一个篮子”原则：审视服务之下的每个层，解决各个层在模拟故障时带来的技术问题、弄清楚意外情况对服务造成的影响，并以此为依据制定服务配置方案。
举例来说，大家应该考虑在基础设施中的某些关键部位采用多套虚拟化方案，这样一旦某套方案发生故障(例如VMware ESXi内核驱动程序损坏或者Hyper-V主分区崩溃等)，对于整体服务而言都不属于单点失效。在虚拟机方面也是如此，尽量使用多台不同的主机及不同类型的虚拟化产品，并把它们保存在同一套SAN当中。如果解决某种问题的惟一途径是采用一些物理域控制器，那也不必犹豫，放手大干吧。即使虚拟化团队表示反对，声称(可能属于他们的次级管理范畴)物理设备的存在有可能提高基础设施的运营成本，但相对于突然某一天公司上上下下无法登录账户的巨大风险，这点支出还是非常值得的。
Server 2012的Active Directory域服务(简称AD DS)让我们少了些焦虑心、多了份安全感。但是对于任何一种新功能，我们都需要结合基础设施实际情况加以权衡，最终决定如何使其发挥***效果、实现***价值。
