VMware ESXi：暂停 VM 进程（允许 NFS 存储重新启动），对数据库、AD、特殊情况有任何副作用吗？

Question

情况：

在集成的一体化 ESXi/ZFS 存储服务器上，其中存储 VM 使用裸机磁盘并通过 NFS（或 iSCSI）将文件系统导出回 ESXi，后者将其用作其他 VM 的池存储，存在更新存储虚拟机时会出现问题，因为许多正在运行的虚拟机依赖于它，并且会因NFS.AllPathsDown或类似原因而超时，这等于从普通服务器中拉出驱动器而不将其关闭。

当然，可以关闭所有 VM，但这会变得非常耗时且乏味（或必须编写脚本）。将 VM 移动到另一台主机可能是可能的，但需要更长的时间，并且在较小的设置中可能无法实现，其中一台机器就足够了。暂停虚拟机可以工作，但也很慢（有时比关闭慢）。

可能的解决方案...

1. 一个简单而有效的解决方案似乎是通过 CLI 停止 VM 进程，在使用kill -STOP [pid]找到它后ps -c | grep -v grep | grep [vmname]，执行存储 VM 的升级/重新启动，然后使用 继续执行 VM 进程kill -CONT [pid]。
2. 一个类似的解决方案可能是快速重启（在 Solaris/illumos 上可用reboot -f或在 Linux 上可用）的组合，kexec-reboot这需要几秒钟而不是几分钟，以及 ESXi 中的 NFS 超时（在 NFS 连接丢失时，所有 I/O 都被暂停，我认为120 秒，直到假定存储永久关闭）。如果重新引导时间在 ESXi NFS 窗口内，理论上它应该类似于磁盘由于纠错而在一分钟内没有响应，然后恢复正常操作。

……还有问题？

现在，我的问题是：

1. 哪种方法更可取，或者它们同样好/坏？
2. 在数据库、Active Directory 控制器、用户运行作业的机器等特殊情况下，有哪些意想不到的副作用？
3. 应该注意哪里？链接博客上的评论提到，例如，当 CPU 冻结时可能会出现计时问题。

---

编辑：澄清这个问题的范围

收到前两个答案后，我想我的问题措辞不够清楚，或者为了简洁起见遗漏了太多信息。我知道以下几点：

• VMware 或其他任何人都不支持它，不要这样做！：我没有提到这一点，因为第一个链接已经告诉了它，而且我也不会问这台机器是否由 VMware 支持管理。这是一个纯粹的技术问题，支持内容不在此范围内。
• 如果今天设计一个新系统，有些事情可以通过其他方式来完成： 正确，但是由于系统已经稳定运行了几年，我不想把婴儿和洗澡水一起扔掉，重新开始，引入新的问题。
• 买硬件X，你就不会有这个问题了！确实，我可以以类似的成本购买 2 或 3 台额外的服务器，并拥有完整的 HA 设置。我知道这是怎么做到的，这并不难。但这不是这里的情况。如果在我的情况下这是一个可行的解决方案，我一开始就不会问这个问题。
• 只需接受关闭和重新启动的延迟：我知道这是一种可能性，因为这就是我目前正在做的事情。我提出了这个问题，要么在当前设置中找到更好的替代方案，要么了解经过证实的技术原因，其中概述的一些方法会出现问题——“这是不可预测的”，但没有任何解释为什么在我的书中没有得到证实的答案。

---

因此，重新表述这些问题：

1. 这两种方法中哪一种在技术上更可取，为什么，假设设置是固定的，目标是减少停机时间而不会对数据完整性产生任何负面影响？
2. 在特殊情况下有什么意想不到的副作用，例如
   • 具有访问它们的用户和/或应用程序的活动/空闲/静止数据库
   • 此计算机和/或其他计算机（在同一域中）上的 Active Directory 控制器
   • 通用机器空闲或用户运行作业或运行自动维护作业（如备份）
   • 网络监控或路由器等设备
   • 在此服务器或另一台或多台服务器上使用或不使用 NTP 的网络时间
3. 在哪些特殊情况下最好不要这样做，因为弊大于利？应该注意哪里？链接博客上的评论提到，例如，当 CPU 冻结时可能会出现计时问题，但没有提供任何推理、证明或测试结果。
4. 这两种解决方案之间的实际技术差异是什么？
   1. 由于主机上的 CPU 过载，VM 进程的执行停止
   2. 由于磁盘或控制器故障而导致磁盘 I/O 的等待时间增加，假设它低于 NFS 阈值？

Answer 1

好问题...

但是为什么你需要重新启动 NFS 服务器呢？

多合一的设计不再合理。当然，作为科学实验或小型家庭实验室的情况。但与任何解决方案一样，希望在必要时建立停机时间和维护窗口。

所以...

• 设置您的 VM 启动和关闭顺序（好东西）。

• 您可以选择多个虚拟机同时关闭或暂停。（当我这样做时，我曾经暂停虚拟机）

• 对 NFS VM 执行任何您需要的操作。
• 吃掉休息时间。

如果您不能有这种类型的停机时间，您不应该运行多合一的存储和 VM 设置，或者应该考虑传统的 SAN 存储（或低成本版本）和多个 VM 主机。

Answer 2

我的建议是完全避免这个问题。您提到增加的成本和完整的重新架构是阻碍因素，但在这种情况下，您可以考虑在双节点故障转移集群中的主机上安装两个存储虚拟机。这将允许您修补其中之一（但不能同时修补两者），而不会影响集群提供的 NFS 或 iSCSI 的可用性。它仍然不是受支持的解决方案，但它至少允许在维护方面具有一定的灵活性，但代价是增加存储资源开销（主要是您为第二个存储虚拟机提供了多少内存）。

如果改变架构是完全不可接受的，那么最安全的选择是关闭虚拟机。

次佳的解决方案是在您的虚拟机中启用休眠。休眠将确保所有文件系统都处于静止状态，有助于避免可能的损坏。

接下来，您可以使用内存状态拍摄 VM 的快照，强制终止 VM 的进程，然后在完成后恢复到快照。这会导致一小段可能丢失数据的窗口，但我相信您永远不会在维护窗口之外尝试此操作，因为任何数据丢失都是不可接受的，因此这应该是无关紧要的。此解决方案与制作快照一样快，可确保 VM 不会抱怨丢失的磁盘，但会导致潜在的数据丢失。

最后，如果您想暂停进程（并已测试它确实有效），那么我强烈建议您首先同步来宾中的所有磁盘（在 Linux 中，这将使用 /bin/sync 完成。提供的实用程序由 SysInternals for Windows 提供：http : //technet.microsoft.com/en-us/sysinternals/bb897438.aspx），并快速执行维护，以免时钟设置得太远。

至于潜在的副作用，任何连接 AD 的机器都必须（默认）在 DC 时间的 5 分钟内。因此，在除正常关闭之外 VM 无法持续​​可用的任何解决方案之后，我建议您强制恢复的来宾更新其时钟。在数据库服务器上，当服务器繁忙时不要做这些事情，因为这会增加文件系统损坏的机会。

除了正常关闭或高可用性存储之外，所有选项的主要风险是损坏。缓冲区中可能会有一些 I/O 被丢弃，应用程序可能会错误地认为这些 I/O 已成功完成。更糟糕的是，I/O 可能已被下层重新排序以获得更优化的写入模式。这可能允许数据被部分乱序写入。也许在写入 DB 行的数据之前增加了行计数，或者在物理更改校验和数据之前更新了校验和。这可以通过只允许同步写入您的存储来缓解，但以性能为代价。

Answer 3

1. 哪种方法更可取，或者它们同样好/坏？

两者都不。

这是糟糕设计的代价，我不会通过关闭虚拟机、处理存储虚拟机然后重新启动其他虚拟机之外的任何其他方式使这种情况变得更糟。我还会让某人使用受支持/可支持的架构重新设计您的设置。

2. 在数据库、Active Directory 控制器、用户运行作业的机器等特殊情况下，有哪些意想不到的副作用？

它本质上是不可预测的，如果你再次这样做，这次可能发生的事情可能不会发生。这是无法支持的。

3. 应该注意哪里？链接博客上的评论提到，例如，当 CPU 冻结时可能会出现计时问题。

很难建设性地回答这个问题。