VMware ESXi：暂停虚拟机进程（允许NFS存储重启），数据库，AD，特殊情况下的任何副作用？

情况：

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

当然，可以closures所有虚拟机，但这会变得非常耗时，也很乏味（或者必须编写脚本）。将VM移到另一个主机上可能是可能的，但是花费更长的时间，并且在一台机器很多的小型设置中可能无法实现。暂停虚拟机可以工作，但也很慢（有时比关机慢）。

可能的解决scheme…

一个简单而有效的解决scheme似乎是通过CLI停止VM进程与kill -STOP [pid]之后find它ps -c | grep -v grep | grep [vmname] ps -c | grep -v grep | grep [vmname] ps -c | grep -v grep | grep [vmname] ，执行存储虚拟机的升级/重启，然后使用kill -CONT [pid]继续VM进程的执行。
类似的解决scheme可能是快速重新启动 （在Solaris上可用/ illumos通过reboot -f或在Linux上通过kexec-reboot ），这需要几秒钟而不是几分钟，ESXi中的NFS超时（NFS连接丢失所有I / O被暂停，我想120秒，直到它被认为是永久存储下来）。如果重启时间在ESXi NFS窗口内，理论上它应该与由于错误纠正而不响应一分钟的磁盘相当，然后恢复正常操作。

…和问题？

现在，我的问题是：

哪种方法更好，还是同样好/坏？
在数据库，Active Directory控制器，用户运行作业等机器等特殊情况下，什么是非预期的副作用？
在哪里要小心？例如，关于链接博客的评论提到CPU冻结时可能会出现计时问题。

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

在收到前两个答案之后，为了简洁起见，我认为我的问题不够清楚或者没有提供太多的信息。我知道以下几点：

这不是由VMware或任何其他人支持，不要这样做！ ：我没有提到这一点，因为第一个链接已经告诉它，也不会问这台机器是否由VMware支持pipe理。这是一个纯技术性的问题，支持的东西在这里不在范围之内。
如果今天要devise一个新的系统，有些事情可以用其他方式来完成 ：正确的，但是由于系统运行稳定多年，我宁愿不要把婴儿扔出洗澡水，开始全新的工作，引入新的问题。
购买硬件X，你不会有这个问题！ 诚然，我可以购买2或3个具有相似成本的附加服务器，并具有完整的HA设置。我知道这是怎么做的，这并不难。但这不是这里的情况。如果这对我来说是一个可行的解决scheme，那么我就不会问这个问题了。
只要接受延迟closures和重新启动 ：我知道这是一种可能性，因为这是我目前正在做的。我曾经提出这个问题，要么在当前的环境中寻找更好的select，要么学习技术上的原因，所提出的一些方法将会有问题 – “这是不可预知的”，没有任何解释，为什么我的书中没有一个确凿的答案。

因此，重新提出这些问题：

这两种方法中的哪一种在技术上是可取的，为什么假设设置是固定的，目标是减less停机时间，而不会对数据完整性造成任何负面影响？
什么是特殊情况下的意外副作用？
- 主动/闲置/静止数据库与用户和/或应用程序访问它们
- 此计算机上和/或其他计算机上的Active Directory控制器（在同一个域上）
- 一般用途的机器闲置或与用户运行作业或运行自动化维护工作，如备份
- 像networking监视或路由器的设备
- 在此服务器上或在另一台或多台服务器上使用或不使用NTP的networking时间
在哪些特殊情况下不宜这样做，因为缺点大于优势？在哪里要小心？关于博客的评论提到，当CPU被冻结时，计时问题可能会出现，例如，但不提供任何推理，certificate或testing结果。
这两个解决scheme之间的实际技术差异是什么？
1. 由于主机上的CPU过载，导致虚拟机进程停止执行
2. 由于故障磁盘或控制器，磁盘I / O上的等待时间增加（假设它低于NFS阈值）？

我的build议是完全避免这个问题。您提到增加的成本和完整的重新devise是show stoppers，但在这种情况下您可以考虑的是在双节点故障转移群集中的主机上有两个存储VM。这将允许您在不影响群集提供的NFS或iSCSI的可用性的情况下对其中一个进行修补（但不能同时对两个进行修补）。它仍然不是一个受支持的解决scheme，但它至less在维护方面有一定的灵活性，但是会增加资源开销（主要是为第二个存储VM提供大量内存）进行存储。

如果改变架构是完全不可接受的，那么最安全的select就是closures虚拟机。

次最好的解决scheme是在虚拟机中启用hibernate模式。 hibernate将确保所有文件系统处于静止状态，有助于避免可能的损坏。

接下来，您可以使用内存状态拍摄虚拟机的快照，强制终止虚拟机的进程，然后在完成时恢复到快照。这会产生一个可能丢失数据的小窗口，但是我相信你绝对不会在维护时间之外尝试任何数据丢失是不可接受的，所以这应该是相当无足轻重的。这个解决scheme和创build快照一样快，确保虚拟机不会抱怨丢失的磁盘，但会造成潜在的数据丢失。

最后，如果你想暂停进程（并且已经testing过它实际上工作了），那么我强烈build议你首先在客户机中同步所有的磁盘（在Linux中，这将通过/ bin / sync来完成。通过SysInternals for Windows： http ： //technet.microsoft.com/en-us/sysinternals/bb897438.aspx ），并快速执行您的维护，所以时钟不会被设置得太远。

至于潜在的副作用，任何AD连接的机器必须在DC时间的5分钟内（默认）。因此，除了正常关机之外，在VM不能正常使用的任何解决scheme之后，我build议你强制恢复的客户更新其时钟。在数据库服务器上，当服务器忙时不要做这些事情，因为这会增加文件系统损坏的可能性。

除正常关机或高可用性存储之外的所有选项的主要风险是腐败。在缓冲区中可能会有一些I / O，这些应用程序可能会错误地认为已经成功完成。更糟的是，I / O可能已经被较低层重新sorting以获得更优化的写入模式。这可能会导致数据被部分无序地写入。在写入数据库行的数据之前，行计数可能会增加，或者校验和数据在物理更改之前更新校验和。这可以通过仅允许同步写入存储来缓解，但是以性能为代价。

好问题…

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

一体化的devise已经不合理了。当然，作为一个科学实验或小型家庭实验室的情况。但是就像任何解决scheme一样，如果需要的话，希望能够build立停机时间和维护窗口

所以…

设置您的虚拟机启动和关机顺序（好东西已经到位） 。

在这里输入图像说明

您可以select多个虚拟机同时closures或暂停。 （当我这样做时，我曾经暂停虚拟机）

在这里输入图像说明

做任何你需要的NFS虚拟机。
吃停机。

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

哪种方法更好，还是同样好/坏？

都不是。

这是一个可怕的devise的代价，我不会做任何事情，但closures你的虚拟机，工作在存储虚拟机，然后重新启动其他虚拟机，这种情况更糟。我还会让某人重新devise使用受支持的/可支持的架构的设置。

在数据库，Active Directory控制器，用户运行作业等机器等特殊情况下，什么是非预期的副作用？

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

在哪里要小心？例如，关于链接博客的评论提到CPU冻结时可能会出现计时问题。

这是很难回答这个build设性的。