将域控制器虚拟化

人们或许会认为，将 Active Directory 域控制器虚拟化这一想法根本不是一个需要讨论的话题，然而我却发现，关于 AD DC 是否应当虚拟化的问题经常被提出。从理论上讲，根本没有必要提出这个问题，因为业界已有大量更为普遍的指导原则告诉我们，所有可能的工作负载都应当被虚拟化，而 AD 当然也不存在任何足以为这条长期存在的普遍规则创设例外的特殊情形。

然而奇怪的是，人们似乎经常专门就这一项工作负载去寻求澄清；而如果你去寻求糟糕的建议，总会有人乐于提供。大量的人发帖建议为 Active Directory 使用物理服务器，但他们几乎从不（如果有的话）解释为什么会建议违背最佳实践，更何况是针对这样一个平淡无奇且众所周知的工作负载。

至于为什么实施 AD DC 的人会认为它值得专门就虚拟化问题进行调查，而其他任何工作负载都不会如此，我无法回答。但经过多年对这一现象的研究，我对围绕物理部署的这些轻率建议的根源确实有了一些洞见。

第一个错误源于人们对虚拟化究竟是什么这件事的普遍误解。遗憾的是，这种情况极为常见，人们常常认为虚拟化意味着整合，而事实当然并非如此。于是他们带着这个错误，进而套用了一个错误的逻辑：整合就意味着把两个 AD DC 整合到同一台物理主机上。这还需要一个跳跃式的假设，即总会存在两个或更多的 AD DC，但这同样是一种常见的误信。于是三个重大的逻辑错误汇集在一起，产生了一些非常糟糕的建议——如果你深入剖析这些建议，通常都能追溯到这一根源。这似乎正是大多数糟糕建议的根本所在。

其他原因有时是对实际最佳实践的误解，比如这句话：“如果你有两个 AD DC，每一个都需要部署在单独的物理主机上。”这句话告诉我们的是，在这种情形下需要使用两台物理上彼此独立的机器，这绝对是正确的。但它并不意味着其中任何一台不应当运行虚拟机监控程序，而只是说需要两台不同的主机。这类建议所使用的措辞往往难以理解，除非你事先就已明白：在任何情况下，非虚拟化的工作负载都是不可接受的。如果你带着这种理解去读这条建议，它的含义就清晰、并且但愿是显而易见的。遗憾的是，这条建议常常被脱离上下文地反复转述，以致其背后的含义很容易丢失。

很久以前，大约十年前，某些虚拟化平台在计时和系统时钟方面存在一些问题，可能会对像 Active Directory 这样的集群化数据库系统造成严重干扰。这在很久以前确实是一个真实存在的问题，但早已得到解决，因为许多不同的工作负载都需要解决它。然而，由此产生了一种 AD 可能需要特殊对待的看法，并且尽管按 IT 的时间标准来说这已经是一两代之前的事、本应早已被遗忘，这种看法似乎仍然挥之不去。

另一个导致糟糕建议的误区，其根源在于这样一个事实：AD DC 和其他集群化数据库一样，在以集群模式使用时不应被快照，因为如果以这种方式只恢复集群中的一个节点，很容易造成数据库损坏。然而，这是存储和数据库的一个普遍特性，与虚拟化根本无关。对于物理 AD DC 同样需要了解这一信息。把快照与虚拟化联系在一起则是另一个误区；虚拟化并不意味着任何此类存储产物。

还有一些误区源于这样一种信念：虚拟化必须依赖 Active Directory 本身才能运作，因此 AD 必须在没有虚拟化的情况下运行。这完全是一个误区，而且毫无道理。根本不存在这样一种循环依赖的要求。

遗憾的是，技术的某些领域催生了大规模的误区——而且往往是许多个误区——围绕着它们，使人很难厘清真相。虚拟化恰好复杂到这样一种程度：许多人试图通过死记硬背去学习它，不仅是怎么使用它，还有它在概念上究竟是什么，从而有时产生一些荒诞不经的误解，这些误解偏离真相如此之远，以致很难辨认出我们看到的究竟是什么。而在这样一个案例中，围绕虚拟化、历史、集群化数据库、高可用技术、存储等等的种种误解层层叠加，使人很难理解为何会有这么多东西围绕着一个部署问题汇聚在一起。

归根结底，很少有工作负载像 Active Directory 域控制器那样理想地适合虚拟化。绝不存在任何情形应当考虑为 DC 使用物理裸机操作系统部署——每一次都应当虚拟化。