我想知道是否有人可以推荐一种比我目前配置的更好的方法来为 Windows Server 2008 R2 服务器组配置域时间同步。我有三个域控制器，它们都是 Hyper-V 来宾。对于所有这些 DC，主机的集成服务时间同步功能均已禁用。DC 配置为权威时间服务器，FSMO DC1 服务器使用公共 nist-a 和 nist-b 服务器作为其时间源。DC2、DC3 和此环境中的所有其他服务器（主机和来宾）都是一个域的成员，并向 DC1 寻求时间。对于所有剩余的来宾（即非 DC），集成服务的时间同步功能已启用。我写这篇文章的原因是，我偶尔会看到下一段中的消息，我想让我的所有服务器（主机和来宾）的时间尽可能准确：
时间服务检测到 900 秒内的时间差大于 5000 毫秒。时间差可能是由于与低精度时间源同步或网络条件不佳造成的。时间服务不再同步，无法向其他客户端提供时间或更新系统时钟。当从时间服务提供商收到有效时间戳时，时间服务将自行更正。
如果有人具有类似的虚拟化 DC 设置，并在域中的所有服务器之间实现了高度准确的时间同步，我们将非常感激您的意见。
谢谢。
答案1
在虚拟化域环境中维护时间的最可靠方法是保持 PDC 物理化，增加所有虚拟化 DC 和域成员的同步频率和漂移容忍度，并禁用所有相关 VM 的主机-客户机时间同步。
这是该问题的伪解释（我已经很久没有看过它了）：
当一台机器（工作站、服务器、虚拟机）启动时，它会从 RTC（主板/BIOS 上的电池供电时钟芯片）读取时间，并计算出每个 CPU 滴答的持续时间。然后，操作系统计算自首次读取以来已发生的时钟滴答数，并将该时间添加到启动时读取的原始时间。这样就可以得到当前时间。
问题是，主机会混淆虚拟机发生的真实时钟周期。虚拟机可能看到 100 个时钟周期，而主机上实际上发生了 500 个时钟周期。因此，这种计算时间的方法失效了，虚拟机上的时间会失衡。
通过 vSphere 和 Hyper-V 上安装的虚拟机工具/增强包进行主机-客户机时间同步可以在一定程度上解决此问题，但并不完美（在某些设置中，如果虚拟机时间落后于实时时间，它们可以将其向前拉，但如果虚拟机时间领先于实时时间，它们不会将其向前跳）。
多核设置（计时计数器基本上在每个核心上模拟）和可以动态更改时钟速度的设置（我完全不知道这是如何维护的）的时钟周期计数方式使情况变得更加复杂。考虑到虚拟机可以在一个核心上执行一个时钟周期，然后跳转到另一个核心在不同的 CPU 上下一个周期，情况就会变得非常可怕。
回到最初的观点：默认情况下，域时间从 PDC 开始，然后逐渐流向其他 DC，然后从那里流向成员服务器和工作站。因此，如果您确保您的 PDC 是一个真正可靠的时间源（通过保持其物理状态），并在所有其他域成员上禁用主机-客户机同步，您将确保稳定且相对准确的时间基础结构。
请注意，将 PDC 作为物理服务器运行，然后在该服务器上启用 Hyper-V 并向其中添加一些客户机可能也不是合适的解决方案，因为我相信当您启用 Hyper-V 时，“基本”操作系统实际上也会（悄无声息地）变成虚拟化操作系统。因此，请将一台物理服务器保留为 PDC，并让 Hyper-V 远离机箱。
值得注意的有趣侧重点：即使使用自 XP/2003 以来内置于 Windows 中的兼容 NTP 服务，微软对 Windows 时间同步的官方立场也是 15 秒。实际上，您可以将其降低到 100 毫秒以下，但他们只支持 15 秒内的同步。有点道理，大多数 MS 环境核心中唯一对时间敏感的关键组件是 Kerberos，默认情况下，只要您在 5 分钟的容差范围内，它就会顺利运行。
答案2
是的。除了实际上也是物理域控制器的服务器外，请勿关闭同步。
我有相同的设置，并且我已确保提供时间的机器是物理域控制器 - 小盒子。所有虚拟 DC 的时间都与 hyper-v 同步。
真正的危险是主机和客户端之间的反馈回路，这样回路就会被打破。
顺便说一句，这不是高度准确的 - Windows 从来都不是。它只能同步到非常差的准确度。我有另一台机器收集财务数据，并与外部主机同步（根据统计，每小时平均偏差：37 毫秒）；）这是准确的。