即使在Server 2012之后,我是否仍应具有物理DC?


30

在Windows Server 2012之前的日子里,建议似乎是在虚拟化DC旁边至少安装一个物理域控制器。

这样做的一个理由是,如果您的Hyper-V主机是群集的,则它们在启动过程中需要DC可以联系。这对我完全有意义。

但是,我经常听到人们说,即使您没有集群设置,拥有物理DC仍然很重要(例如,在一个简单的设置中,单个Hyper-V服务器运行几个VM,一个其中是DC)。这样做的理由似乎(而且我永远无法确定),从某种意义上来说,在Hyper-V主机首次启动时,网络上没有DC,您仍然会遇到问题。缓存的凭据意味着您仍然可以登录,但是在启动过程中发生的所有这些比特又意味着DC周围是有益的呢?这实际上是一个问题吗?实际上是否有任何可能运行的操作在启动时会引起问题吗?例如任何组策略?我基本上要问的是,物理DC参数是否仅在涉及集群时才真正成立,或者(2012年前)有一个重要的技术案例却没有集群? Altaro的这篇文章(请参阅“鸡和蛋的神话”部分)建议没有必要,但我仍然不确定。

现在到我的问题的第二部分(也是主要部分):

Windows Server 2012引入了一些旨在解决虚拟化域控制器问题的功能,包括:

  1. VM生成ID-解决了USN回滚问题,这意味着不支持快照(或更具体地说,回滚到快照)/的确不是一个好主意
  2. 群集引导 -解决了我上面提到的有关故障转移群集的“鸡和蛋”问题。故障转移群集不再需要在启动过程中存在DC。

所以我的第二个问题类似于第一个问题,但是这次是2012年+。假设vDC和主机均为2012+,并且您不考虑群集问题,是否还有上述其他问题,这意味着我仍应考虑物理DC?我是否仍应考虑在其具有单个虚拟化DC的单个非群集2012 / 2012R2 Hyper-V主机旁安装物理DC?我听到有人建议将AD放在Hyper-V主机上,但是由于种种原因我不喜欢这个主意(WB缓存一开始就被禁用了)。

附带说明一下,我的问题隐含地假定将Hyper-V主机加入域以提高可管理性是有意义的。这个主张是否值得审查?

更新:

在阅读了一些答案之后,我发现我可以用稍微不同的措辞来表达我所要问的内容:

即使在2012年及以后进行了改进,事实仍然是,另一台主机上没有任何物理DC或虚拟DC,当没有可用DC时,该主机仍会启动。这实际上是一个问题吗?从某种意义上说,我想如果您完全从图片中去除虚拟化,则是相同(或非常相似)的问题。如果您在任何DC之前定期启动成员服务器,这有问题吗?


4
就个人而言,我永远不会在您的Hyper-V主机上安装AD。暂时将所有与群集相关的问题排除在外。您失去了唯一的虚拟DC-您失去了唯一的DNS来源。
PnP 2015年

Answers:


11

我也不会将Hyper-V主机设置为DC。

至于您是否应该拥有物理DC,我的看法是,随着Microsoft对虚拟化域控制器进行的更改(特别是无DC群集自举),我个人认为没有必要,我也不主张具有物理DC。维护物理DC似乎与将基础架构迁移到虚拟化平台的本质背道而驰。虚拟化我的整个基础架构,但都取决于一个可用的物理DC?这有什么意义?

有几种方法可以在虚拟化域控制器的同时限制您的“暴露”。一种方法是在群集中的不同主机上部署多个DC,并在主机发生故障时使用反亲和力将它们分开(取决于群集中有多少个主机)。

虽然Greg的答案包括一些MS建议的链接,但该文章已有两年历史,涉及Windows Server 2008和2008 R2。我认为该文章不是Windows Server 2012和2012 R2的当前最佳实践。我找不到正式的MS文档,但是此人被认为是Hyper-V的主要权威-http://www.aidanfinn.com/?p =13171


谢谢乔。实际上,我前段时间阅读了Aidan的文章,部分地回答了我的问题。令我印象深刻的是,从逻辑上讲,除非您运行集群环境(否则可能会使设置“集群就绪”),否则2012年之前的物理DC确实不存在这种情况。这就是为什么我添加了一些关于即使没有集群也仍然需要pDC的人的理由,2012
。– dbr 2015年

您是否同意我的上述评论,即如果解决集群问题,则情况在2008年至2012年之间并没有真正改变?
dbr 2015年

@dbr我只会在joe的答案中添加一个关于hyper-v(而不是xen或esx)的信息,我之前会测试过hyper-v mmc。发生在我身上的是一个死主机,上面挂有DC,hyperv mmc需要一个活动的AD才能打开。即使使用缓存的凭据以域管理员身份登录,我也被困住了。可以通过最新更新进行修复,但这是一个重要的事实。(与可以使用内置用户的esx不同,因为您仍然可以打开vsphere或
vcenter

只是想添加其他方法来提高弹性:拥有多个虚拟化主机群集(位于同一位置或其他位置)和/或构建到Azure的VPN(或AWS-Azure对于MS商店有一些好处),一两个DC。
Todd Wilcox

18

每个域保留一个物理DC的一个基本原理是,如果发生重大事件影响主机或破坏虚拟化DC的帧存储,则您将至少拥有一个具有本地存储的物理DC来执行恢复并保持连续性。Microsoft将继续执行此检查,并在Active Directory RAP(风险评估和规划)期间提出此建议。

https://technet.microsoft.com/zh-cn/library/virtual_active_directory_domain_controller_virtualization_hyperv%28v=ws.10%29.aspx

“在您的每个域中维护物理域控制器。这减轻了虚拟化平台故障的风险,该故障会影响使用该平台的所有主机系统。”


2
但是,不确定这是否有意义-例如,我知道一家公司100%虚拟化了DC,他们定期进行备份,并在2大洲拥有3个DC(在欧洲2个,在美国1个)。...很难想像一下这里发生的任何事情,使事情无法恢复。
TomTom

我想他们要说的是,如果有某种问题会影响整个Hyper-V,那么您(暂时)会陷入困境,直到可以恢复DC,而拥有pDC则意味着减少干扰。不确定我是否会同意,因为如果存在Hyper-V范围的停电问题,无论如何您都会被搞砸!
dbr 2015年

1
不错,但又完全无关紧要,除非您当时在Hyper-V中拥有很大一部分基础架构。DC可以正常工作,但是文件共享,共享点,交换,打印和其他所有功能都下降了–意味着我宁愿不在乎DC再次启动;)它主要是为了“拥有多个DC并进行备份”而运行的,这就是这种情况。两侧(Hyper-V和物理)。
TomTom

@TomTom这就是我对“无论如何都会被搞砸”的评论所不愿看到的:)我以为几乎所有其他内容都会被虚拟化。完全同意,它归结为“具有多个DC并进行备份”
dbr 2015年

我工作的@TomTom公司对于AD基础架构也是完全虚拟的。自W2K3以来一直如此。但是,我们不会一直使用HyperV:ESX。每个大陆上有2套独立的ESX集群基础结构。每个域(至少)具有3个DC:在另一个大陆上有1个DC,在“本国”大陆上的2个ESX环境中每个都有1个DC。
Tonny 2015年

10

我觉得您正在寻找一个答案,所以这里是:

如果您不信任虚拟环境的承受故障能力,则应该拥有物理DC。

我们可以对每种情况的特殊性和例外情况进行讨论,但是我认为这是问题的根源。


3

让我们将等式聚类出来,集中在您的问题中使我发抖的那一行。

我是否仍应考虑在其具有单个虚拟化DC的单个非群集2012 / 2012R2 Hyper-V主机旁安装物理DC ?

为什么,为什么,为什么要一个DC?在任何给定的环境中,我们都试图避免任何给定的基础架构出现单点故障。DC是您的食粮-它们提供DNS(Active Directory的骨干)。认真地,在2008R2上重建Windows 7台式机并进行升级。有始终是一个强大的情况下为物理直流。

Hyper-V与AD DS?不就是不。首先,Microsoft不支持此功能。其次,正如您提到的,处理备份将变得很麻烦,具体取决于您的磁盘配置。更不用说-虚拟化的好处在于能够尽快撤消物理主机,我们可以构建它们(我很欣赏dcpromo并不重要(取决于您的环境大小)),并且托管AD DS只会使情况复杂化很重要。您还介绍了Windows Time的另一种复杂性。

就我个人而言,我将独立的Hyper-V主机置于域之外,但实际上,我对这两种配置都没有真正的争论。


3
提出的观点完全正确,但与问题无关,因此大多数答案都是不必要的。当然,多个DC几乎总是必须的-引用的部分用于说明一个点/问题。HV + AD组合确实只是一个旁注,我想我很清楚我也不是该组合的爱好者。
dbr 2015年

2
如果“总是存在物理DC的强烈理由”。[vs. 例如第二个vDC]-您能解释这种情况吗?那真的是我的问题。
dbr 2015年

1

要回答有关这是否真的是一个问题的最后一个问题:我注意到我的Hyper-V主机启用了RDP,但是需要NLA,除非没有重启,否则直到我重新启动Network Location Awareness服务后才允许RDP。开机时DC上升。在这些点上,偶尔也会出现远程连接到VMMS的问题,但是只有在其他问题也被打破的情况下。当您无法进入RDP或无法远程连接到Hyper-V管理器时,很难找出问题所在并加以修复。保持物理DC可以防止在任何时候发生这种情况。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.