Failed to complete any SCSI IO requests within 200ms.

 
VMwareのVCBバックアップで、vcbmounterの実行出力に以下の警告メッセージが出力されることがある
*[2010-01-01 00:00:00.000 'App' 596 warning] SanMpAIOMgrRWv: Failed to complete any SCSI IO requests within 200ms.

このメッセージは、VMwareで使用しているvmfsファイルシステムのストレージの負荷状況が高いことを示しています。
この警告メッセージが多いと、VCBバックアップが失敗する可能性を秘めています。
ストレージの負荷を減らしたり、VMware VCBバックアップのエラーを減らすのに以下のような手段があります。

VMware VMFSファイルシステム(LUN)ロック。VCBバックアップ設計時に注意

VMware では、vmfsのファイルシステムに対しファイルサイズの増減を必要とする時にvmfsファイルシステムに対し書き込みロックをかけます。
「1つのvmfsファイルシステム=1つのLUN」と言えるかと思います。
1つのvmfsファイルシステム(1つのLUN)に対し、複数の仮想マシンが存在し、同時に複数の仮想マシンにたいしVMwareのVCBバックアップ(スナップショット作成処理)を行いますと、このファイルシステムロックが競合し、上記の「200ms以内にSCSI I/O要求が・・・」という警告メッセージが出力されることがあります。

1つのvmfsファイルシステム(1つのLUN)に複数の仮想マシンを配置し、その複数仮想マシンにたいし同時にVMwareのVCBバックアップ(スナップショット処理)を行うシステム設計は避けたほうが良いです。
逆を言えば、ストレージのパフォーマンス性能が許す限り異なるvmfsファイルシステム(異なるLUN)に配置された仮想マシンに対し同時VCBバックアップ(スナップショット処理)は可能になります。

1つの仮想マシンに仮想ハードディスク数(vmdkファイル数)を多数配置しても問題ない?

1つのvmfsファイルシステム(1つのLUN)に1つの仮想マシンを配置し、他の仮想マシンと同時VCBバックアップではない状態を想定します。
このバックアップ対象の1つの仮想マシンが複数の仮想ハードディス(複数vmdkファイル)をもって構成されている場合、VCBバックアップ(スナップショット命令)時にこの複数の仮想ハードディスク(複数vmdkファイル)がファイルシステムロックで競合する可能性もあります。
10以上の仮想ハードディスク(複数vmdkファイル)を持つような仮想マシンのVCBバックアップを行うと、VCBバックアップがエラーで失敗したり、スナップショット作成時・スナップショット削除時にファイルシステムロックにより対象の仮想マシンが15分程度ハングした状態で動作しなくなったりすることがあります。
1仮想マシンの仮想ハードディスク数(vmdkファイル数)も少ない方が無難と言えます。

スナップショットを削除する(コミットする)際に時間がかかる

VMwareで仮想マシンオンラインスナップショット作成時に時間がかかることはまだ納得がいきます。
仮想マシンのメモリキャッシュ(ntfsキャッシュ)フラッシュ行為や、静止点の作成に時間がかかっても不思議ではありません。
VMwareのsyncドライバを使用した場合は、上記の動作やvmfsファイルシステムのロックのためスナップショット作成時にオンライン仮想マシンがハングしたような状態になりサービスが正常動作しない時間が出来たりすることがあります。

スナップショット作成時ではなく、静止点の作成では説明出来ないオンライン仮想マシンのハングが起きる場合があります。
仮想マシンで仮想ハードディス数(vmdkファイル数)を多く使用した場合に発生しました。
スナップショット削除時にも時間がかかり、オンライン仮想マシンがハングした状態が発生しました。


要約しますと、delta(増分)ファイルを flat ファイル(仮想ディスク本体)にマージ(コミット)するには時間がかかるため、マージしている間の Disk I/O をカバーすべく「2 つめの delta ファイル」が作成されます。
そして、この「2 つめの delta ファイル」を flat ファイルにマージするタイミングで、ディスクの整合性を保つため、仮想マシンは(一瞬)活動を停止する、という動きとなります。

* では、本来「一瞬」で終わるはずの 2nd delta ファイルの削除に時間がかかるのは何故か?ということになります。

VMFS というファイルシステムは分散ファイルロックの機能があります。
1 つのボリュームに対して複数の VMware ESX がアクセスを行っても、ファイルレベルでロックがかかるため、ファイルが破損することはありません。
但し、ファイルの作成やリサイズ(拡大)・削除といった、ファイルシステムに変更を加える動作を行う場合は、対象ボリュームのファイルシステム全体にロックをかけることで、ファイルシステムの整合性を保つ仕様となっています。

スナップショットのマージを行う際には、delta ファイルを削除する前後で、2nd delta ファイルの作成と削除が行われます。
前述の通り、ファイルの作成や削除はファイルシステムのロックが必要となりますが、同一のボリュームに対して並行してファイルシステムの操作を試みた場合は、稀に失敗する(時間を要する)ことがあると言われています。

* バックアップ ジョブを VMFS ボリュームレベルで並列実行させないほうがいい、というのと同じ理屈です。

この問題の本質的な回答ではありませんが、仮想ディスクの数を減らすことで、問題が発生する頻度を抑えられる可能性があります
(例えば、10 個の仮想ディスクを、1 つの仮想ディスクと 10 の論理パーティションに変更するような形です)。
なお、「仮想ディスクの数は最大いくつにすべき」という点につきましては、公式なアナウンスは出ておりません。

今回の問題の場合、仮想ディスク数を減らすことにより改善が見られました。

サブページ リスト

更新日:2010/02/15
Comments