シナリオ：
- VMWare 上で実行される Exchange 2010 VM
- 120GBのデータ
- 土曜日の午前 12 時から午前 8 時までの実行時間 (必要に応じて少し延長できます)
アクション満載の 2 つの質問:
データストアをアンマウントし、Exchange VM のスナップショットを作成し、C ドライブと D ドライブ (データベース) のドライブ レベルのデフラグを実行し、データストアを再マウントしてスナップショットを削除します (すべて正常であれば)。
他のオプションとしては、Exchange VM のスナップショットを作成し、データ ストアをマウント解除し、ESEUTIL をオフラインで実行して C ドライブ (D ドライブではない) をデフラグし、データストアを再マウントしてスナップショットを削除する (すべてが正常であれば) というものがあります。
皆さんはどう思いますか? Exchange サーバーのデフラグ/エラー チェックに正しいアプローチを取っていますか?
答え1
一般的な警告メッセージを満たすためだけにドライブと DB をデフラグする作業を行う前に、次のことを行います。
何を期待しますか? Exchange Serverの断片化は、Outlookのキャッシュモードを使用している場合、ユーザーにとってほとんど無関係です。Exchangeに十分なRAMが与えられている場合、各メールボックスのチャンクがRAMに保存されるため、ディスクの重要性は低くなります。現代のExchangeは実際にはもっとゆっくりディスクは古い Exchange (2000/2003) です。
VM 内のデフラグは、皆さんが考えているようなものではありません。物理ディスクと Exchange DB の間には、複数のレベルの抽象化があります。共有 iSCSI ディスク セットから LUN を提供する RAID セットがありますが、その LUN が実際のディスク上で連続しているかどうかは、どうすればわかりますか? 特にシン プロビジョニングされている場合は、そうではないと思います。次に、VMWare で作成した .vmdk ファイルがありますが、これはおそらくそれ自体が断片化されています。シン プロビジョニングしましたか、または最初の作成後に .vmdk のサイズを変更しましたか? iSCSI から始めて、vmdk、ゲスト OS、Exchange と、これらすべての異なるレベルを通過した場合、どのような結果になりますか? おそらく、OWA が高速化されるでしょう...
要するに、仮想化された実稼働システムをデフラグして、実際にユーザー エクスペリエンスが向上した例を私は見たことがありません。不可能だと言っているわけではありません。可能性が低いと言っているだけです。
VMWare VM とデフラグに関するヒント: http://blogs.vmware.com/vsphere/2011/09/should-i-defrag-my-guest-os.html
そのリンクからの興味深い引用文を一つ紹介します。
「VMware 社内では、SAN または NAS ベースのデータストアにあるゲスト OS のデフラグ後にパフォーマンスに目立った改善が見られなかったと読んだことを指摘しておきます。」