主页 / server / 问题 / 800688
Accepted
user121391
Asked: 2016-09-03 01:29:56 +0800 CST

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

  • 772

情况：

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

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

可能的解决方案...

  1. 一个简单而有效的解决方案似乎是通过 CLI 停止 VM 进程，在使用kill -STOP [pid]找到它之后ps -c | grep -v grep | grep [vmname]，执行存储 VM 的升级/重新启动，然后使用 继续执行 VM 进程kill -CONT [pid]。
  2. 类似的解决方案可能是快速重启（在 Solaris/illumos viareboot -f或 Linux via 上可用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 阈值？
nfs active-directory database zfs vmware-esxi

3 个回答

  1. 好问题...

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

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

    所以...

    • 设置您的 VM 启动和关闭顺序（准备就绪）。

    在此处输入图像描述

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

    在此处输入图像描述

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

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

    • 7
  2. Best Answer

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

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

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

    接下来，您可以使用内存状态拍摄 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 可能已由较低层重新排序以获得更优化的写入模式。这可能会导致部分数据被乱序写入。也许在写入数据库行的数据之前行计数增加了，或者在校验和数据物理更改之前更新了校验和。这可以通过只允许同步写入存储来缓解，但会以性能为代价。

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

    两者都不。

    这是糟糕设计的代价，除了关闭您的虚拟机、在存储虚拟机上工作然后重新启动其他虚拟机之外，我不会做任何事情来使这种情况变得更糟。我还会让某人使用受支持/可支持的架构重新设计您的设置。

    1. 在数据库、Active Directory 控制器、用户运行作业的机器等特殊情况下会有哪些意外副作用？

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

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

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

    • 5

相关问题