如何避免 VMware 在使用 Veeam 进行映像期间震惊客户端

Question

最近我们的 MySQL 服务器一直在“消失”（即客户端连接断开）。经过数周的尝试不同的事情（例如调整数据包大小），我们发现是我们的 Veeam 映像备份使用 VMWare API 来快照和复制 vmdks 等。

我们将 ESXi 5 与 Centos 6.4 来宾一起使用，运行（几乎）仅 MySQL 5.1.69-log。

似乎引发此问题的更改是将物理磁盘大小从大约 100 GB 增加到 300 GB，并调整来宾文件系统的大小以使用大部分新容量。自从磁盘增加以来，我们在备份期间一直遇到这些问题 - 大概是由于执行快照相关功能所需的时间增加。

新磁盘是 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”。

我相信“stun”意味着虚拟机只是冻结了一段时间（大约 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

所以我的问题有两个可能的解决方案：

1. 有没有办法防止或减少 VMWare 来宾在映像过程中的“震惊”。

2. 有没有办法减少stun对MySQL或虚拟网络或Centos的影响。

Answer 1

这是一款运行 Smart Array RAID 控制器的 HP ProLiant 服务器，没有闪存支持的缓存模块。

因此，您没有写缓存（或读缓存），虚拟机快照等操作将受到影响。你已经体验过这种效果。当前配置不适合大多数工作负载，尤其是虚拟化。

您最好的选择是简单地购买缓存模块和电池/FBWC；HP 部件 631681-B21、631679-B21 或 631069-B21。

这将提高性能并消除您所看到的问题。

另见：

HP DL360p 上的 FBWC 和零内存 (ZM) RAID 控制器

BBWC：理论上是个好主意，但有人保存过你的数据吗？

RAID卡上的内存条有什么用？