Exchange VM 碎片整理或 ESEUTIL？我是否采取了正确的方法来对我的 Exchange VM 服务器进行碎片整理/错误检查？

Question

设想：

1. 在 VMWare 上运行的 Exchange 2010 VM
2. 120GB 数据
3. 周六凌晨 12 点至早上 8 点的运行时间（如有需要，可以稍微延长）

两个充满行动的问题：

1. 我想卸载我的数据存储，拍摄我的 Exchange VM 的快照，运行 C 和 D（数据库）驱动器的驱动器级别碎片整理，重新安装数据存储并删除快照（如果一切正常）。

2. 我的另一个选择是：拍摄我的 Exchange VM 的快照，卸载数据存储，离线运行 ESEUTIL 并对 C 盘（不是 D 盘？）进行碎片整理，重新挂载数据存储并删除快照（如果一切正常）。

您的想法是什么？我是否采取了正确的方法来对我的 Exchange 服务器进行碎片整理/错误检查？

Answer 1

在我为了满足一般警告信息而花大力气对驱动器+数据库进行碎片整理之前，我会做几件事：

1. 您希望从中得到什么？如果您的用户都使用 Outlook 缓存模式，那么 Exchange Server 碎片化对他们来说基本上无关紧要。如果 Exchange 有足够的 RAM，它会将每个邮箱的块存储在 RAM 中，因此您的磁盘变得不那么重要。现代 Exchange 实际上设计为在慢点然后是旧 Exchange (2000/2003)。

2. VM 内部的碎片整理并不是您想象的那样。物理磁盘和交换数据库之间存在多个抽象级别。您有一个 RAID 集，它为一组共享的 iSCSI 磁盘上的 LUN 提供服务，您如何知道该 LUN 在实际磁盘上是否连续？我对此表示怀疑，特别是如果它是精简配置的。然后，您有一个在 VMWare 中创建的 .vmdk 文件，它本身可能就是碎片。您是否对其进行了精简配置，或者在初始创建后是否更改过 .vmdk 大小？如果您经历了所有这些不同的级别，从 iSCSI 开始，然后到 vmdk，然后到客户操作系统，然后到 Exchange... 会产生什么结果？也许是更快的 OWA，如果那样的话...

最重要的是，我从未见过虚拟生产系统经过碎片整理后，用户体验得到改善。我不是说这不可能做到……我只是说这不太可能。

有关 VMWare VM 和碎片整理的提示： http://blogs.vmware.com/vsphere/2011/09/should-i-defrag-my-guest-os.html

该链接中有一段有趣的引言：

“我应该指出，我读到过，在 VMware 内部，在对位于 SAN 或基于 NAS 的数据存储上的客户操作系统进行碎片整理后，我们并未观察到性能有任何明显的改善。”