虚拟机中的活动目录：可能被忽视很久的问题和答案 （1） 推荐

写在题外
很多人在今天把虚拟化及云计算的概念混淆掉了，但其实不容忽视的是虚拟机已经渗透到了大大小小的数据中心中，成为各种业务的“基石”，可能小到一个测试系统，大到一个完整的Hadoop集群负载。因此不管怎样理解，个人认为对虚拟化做深入的实践在今天以至于可期待的将来都是非常有必要的。

今天想较为深入的讨论一下虚拟机中的活动目录需要注意的问题，以及如何通过Windows Server 2012中提供的守护者服务解决的。
下一篇博客将继续完成对虚拟机环境下的域控制器克隆和快速复制的方法。

实际上，活动目录与域控制器已经存在于虚拟化世界多年了，因此也积累了很多最佳实践的方法，例如这篇详细如何将域控制器部署于Hyper-V之上的技术文章。
那么其中较为明确需要谨慎设计和考虑的地方主要集中于：
1. 对于虚拟机环境下的域控制器如何应用快照
2. 对于运行域控制器的虚拟机进行导出
3. 拷贝域控制器虚拟磁盘文件如VHD等
不知道，各位看官是否注意过上述问题和最佳实践的提示，反正作为在从事的工作中搭建包括域控制器在内的环境时的确从来没有注意过这个问题；我推测可能很多虚拟化环境的管理员也很可能忽视了这个潜在的问题。

在展开讨论和回答之前，我们先阐述一下为什么会有上述问题呢？快照难道不是虚拟机特有的备份方式吗？
对于活动目录这种特殊的应用，存在活动目录的复制关系，而这种复制关系是通过逻辑时钟进行感知和控制的更新的，在活动目录中逻辑时钟叫做USN (update sequence number)，通过USN来记录每个域控制器上的更新序列，每个域控制器都有自己独有的标识改变来源，被叫做InvocationID。




因此，快照的恢复和容易造成USN漂移不正确，如果不能感知这种变化就很可能会造成通常被称为”USN气泡“的问题，并产生诸如：

残留对象

不一致密码

不一致的属性值

Schema FSMO回滚时Schema不一致

更严重的问题，甚至会造成安全主题SID重复或失效，在一段时间内的非授权的资源访问或最终受影响的用户无法正常登录域等。

看看下面这种情况，域中存在两个域控制器（DC1和DC2），
1. 在时间T1，我们在DC1的虚拟机上创建了一个快照，此时的USN是100，DC的InvocationID是A，安全主体SID池为 （域中唯一ID）RID 500到1000。




2. 在时间T2，管理创建了了100个新用户，此时USN为200，DC的InvocationID是A，安全主体SID池为 （域中唯一ID）RID 600到1000，DC2收到DC1的更新并复制USN大于100的更新到USN200。




3. 在时间T2到T3之间，DC1出现故障，管理员在时间T3通过虚拟机快照回滚DC1的虚拟机，此时DC1的USN恢复至100，DC的InvocationID是A，安全主体SID池仍然回到 （域中唯一ID）RID 500到1000。请注意此时DC2已经复制了最新的DC1（A）的USN200的更新。




4. 在时间T4，管理员在DC1控制器添加了150个用户，USN是250，DC的InvocationID是A，安全主体SID池为 （域中唯一ID）RID 650到1000；可是请注意DC2已经收到了来自DC1到USN200的更新，而并不知道DC1已经在T3时间通过虚拟机快照回滚了！因此目前DC2只会接受来自DC1从USN200-250的更新；最终造成问题是汇聚后只有50个用户到了DC2，其他的用户在DC1和DC2中各有100个用户，这部分用户的安全主体SID是冲突的！这就是USN气泡问题产生了。




那么上述可能被忽视的活动目录存在于虚拟化环境的问题，在新的Windows Server 2012中得到了解决，Windows Server 2012中引入了针对虚拟化环境活动目录安全性的设计。
一种叫做虚拟机生成ID(VM-Generation ID或VMGID)的机制被Hypervisor虚拟机平台层所采用，来宾虚拟机操作系统和应用可以通过Windows Server 2012驱动提供的一个128位的特殊标识符来区分；而虚拟机中的Windows Server 2012的域控制器可以跟踪VMGID的改变来检测和保护活动目录。
VMGID存储在活动目录数据库（DIT）中，非复制属性存储在域控制器的计算机对象中，因此在提交本地DIT的更新前，域控制器会执行：
对比存储在DIT中的VMGID于运行时环境的VMGID，如果两者不同，则域控制器将在提交更新前重置域控制器的invocation ID以及失效的RID池。
上述过程也会发生在每次域控制器启动的过程中。
对于具有FSMO操作主机角色的域控制器快照回滚这样的操作，在复制周期完成之前FSMO角色和功能将不会打开。
VMGID的功能对于虚拟化环境至关重要，通过这个功能可以确保在虚拟化操作中导致活动目录执行上下文 （从一个以前时间点回滚的元数据） 需要重新执行或重用的操作，必须提供一个新的VMGID!

好了，结束了抽象的描述，我们回到上面的例子再看一下：
域中的两个域控制器（DC1和DC2），
1. 在时间T1，我们在DC1的虚拟机上创建了一个快照，此时的USN是100，DC的InvocationID是A，保存在DC1的DIT中的VMGID是G1，而从Hypervisor驱动运行时的VMGID也是G1。




2. 在时间T2，管理创建了了100个新用户，此时USN为200，DC的InvocationID是A，保存在DC1的DIT中的VMGID是G1，而从Hypervisor驱动运行时的VMGID也是G1，DC2收到DC1的更新并复制USN大于100的更新到USN200。




3. 在时间T2到T3之间，DC1出现故障，管理员在时间T3通过虚拟机快照回滚DC1的虚拟机，此时DC1的USN恢复至100，DC的InvocationID是A，保存在DC1的DIT中的VMGID是G1，而从Hypervisor驱动感知回滚操作，运行时的VMGID更新为G2。（此时DC2已经复制了最新的DC1到USN200的更新。）




4. 在时间T4，管理员在DC1控制器添加了150个用户，由于VMGID检测到了差异，因此开始使用安全机制，新的USN101-250，DC的InvocationID改为B，并且重置VMGID为新的G2。



5. DC2将重新接受DC1(B) USN>100的更新，因此接受更新USN到250，之前复制到DC2的USN100-200的更新则可以反向更新到恢复快照后丢失这部分信息的DC1上，因此USN 重用机制确保了USN回滚后的保护工作 ，最终汇聚后所有的用户在所有的域控制器中都正常了：-）




目前可以支持虚拟化域控制器和VMGID的虚拟化产品见下表：

虚拟化产品	支持虚拟化域控制器及VMGID
Microsoft Windows Server 2012 server with Hyper-V Feature	是
Microsoft Windows Server 2012 Hyper-V Server	是
Microsoft Windows 8 with Hyper-V Client Feature	是
Windows Server 2008 R2 and Windows Server 2008	否
非微软虚拟化解决方案	N/A

*对于第三方的虚拟化产品是否支持虚拟化域控制器及VMGID功能，需要查看第三方的产品说明。
另外虚拟化运行的是微软的 Hyper-V的Hypervisor必须是Windows Server 2012。
验证是否支持可以通过设备管理器界面，可以通过打开虚拟机域控制器操作系统的设备管理器 Devmgmt.msc检查系统设备下已安装的Microsoft Hyper-V 设备和驱动，看是否包含Hyper-V生成计数器驱动 (vmgencounter.sys)。




关于在虚拟环境中的活动目录就先讨论这么多，下一篇博客将分享一下怎样利用守护者服务来完成虚拟化环境中的域控制器的快速克隆和复制。