最近我们的 MySQL 服务器“出问题了”（即客户端连接断开）。经过数周尝试各种方法（例如调整数据包大小），我们发现是我们的 Veeam 映像备份使用 VMWare API 来快照和复制 vmdk 等。
我们正在使用带有 Centos 6.4 客户机的 ESXi 5，（几乎）仅运行 MySQL 5.1.69-log。
导致此问题发生的更改似乎是将物理磁盘大小从大约 100GB 增加到 300GB，并调整客户文件系统的大小以使用大部分新容量。自从增加磁盘容量以来，我们在备份过程中一直遇到这些问题 - 大概是因为执行快照相关功能所需的时间增加。
新磁盘是 RAID1 中的 2x300GB Gen8 15k SAS。旧磁盘应该类似，只是尺寸更小。Veeam 流程的目标是通过 1Gb 专用以太网（即与一般办公室流量分开）的 ReadyNAS。
主机是HP DL380P塔式机：
==server spec (BASE CHASSIS)==
SERIES DL380P GEN8
PROCESSOR TYPE Intel Xeon E5-2609 v2 (2.5GHz/4-core/10MB/6.4GT-s QPI/80W)
NUMBER OF PROCESSORS 2
MEMORY 80GB
INTERNAL DRIVE BAYS 8 SFF HDD Bays
COMPATIBLE HDD SFF SAS/SATA
HARD DISK CONTROLLER SMART ARRAY P420I/ZERO MEMORY CONTROLLER (RAID 0/1/1+0)
我的“IT 人员”对 Veeam 配置做了一些调整，包括跳过空块（新磁盘的大部分是空的），但这似乎没有任何帮助。
Veeam 也没有提供太多帮助，只是说“重新启动目标”或“我们只使用 VMWare API”。
我相信“震惊”意味着虚拟机只是冻结一段时间（大约 30 秒）然后继续正常运行。
VMWare.log 示例：
Line 7411: 2016-06-08T17:11:44.910Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 21068381 us
Line 7556: 2016-06-08T17:22:24.608Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 19819322 us
Line 7700: 2016-06-08T17:22:30.140Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 1130044 us
Line 7929: 2016-06-08T17:23:08.616Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 30197618 us
所以我的问题有两个可能的解决方案：
有没有办法可以防止或减少 VMWare 客户机在成像过程中的“震惊”。
有没有办法减少 Stun 对 MySQL 或虚拟网络或 Centos 的影响。
答案1
这是一台运行智能阵列 RAID 控制器且不带 Flash 支持缓存模块的 HP ProLiant 服务器。
因此，您没有写入缓存（或读取缓存)，虚拟机快照等操作将受到影响。您已经体验过这种影响。当前配置不适合大多数工作负载，尤其是虚拟化。
最好的选择是直接购买缓存模块和电池/FBWC；HP 部件 631681-B21、631679-B21 或 631069-B21。
这将加速性能并消除您所看到的问题。
另请参阅：
答案2
通过研究回答我自己的问题。（如果其中一种方法确实有效，并且是在别人提出建议之前，我才会接受我自己的答案。）
这篇（较旧的）文章快照有哪些危险？如何避免？提到了一些可能的原因和三种预防措施。有趣的是，它提到了该问题如何同样影响 MS SQL Server 和其他服务器产品。
如果您不想关闭/暂停虚拟机，可以将快照.maxIterations 设置为 20（或更高）。这意味着 vSphere 将进行更多尝试（迭代）来提交快照文件。更多信息请参阅此知识库文章。
然后继续描述这种方法的风险和缺点。
其次建议：
或者，您可以将快照.maxConsolidateTime 设置为 60 秒。这意味着您可以接受虚拟机暂停 60 秒以进行同步整合。这通常是比等待快照文件变得太大而虚拟机需要更长时间暂停更好的选择。
但我不知道“眩晕”和“暂停”之间的区别。
最后：
ESXi 4.1 有一个更新，添加了参数 snapper.asyncConsolidate.forceSync = “FALSE”，需要将其添加到 VMX 文件中。此设置禁用同步整合，虚拟机将永远不会被关闭。更多信息请参阅此知识库。
它没有描述这些解决方案的潜在缺点，但我认为它们存在一些，否则它们将是默认的。
我还没有检查这些参数或解决方案在 v5 中是否仍然相关。
更新：Veeam 建议我们进行此 KB 中列出的与 ESXi v4 和 v5 相关的上述更改。删除快照时虚拟机超过 30 分钟无响应 (2039754)
更新 2：我们今晚将进行这些配置更改并重新启动主机，因为这比等待缓存更便宜、更快捷。然后我们将监控几天，看看仅此一项是否能为我们解决问题。