ESXi NFSデータストアのレイテンシスパイクのトラブルシューティング

特定のVMによってトリガーされる、ESXiのNFSデータストアで約5秒の fsyncレイテンシが発生しています。これは、仮想IDEドライブでは発生しないため、NCQ / TCQを使用するVMが原因である可能性があります。

これは、fsync -tester（Ted Ts'oによる）およびiopingを使用して再現できます。たとえば、8GBディスクでGrmlライブシステムを使用する場合：

Linux 2.6.33-grml64:
root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 5.0391
fsync time: 5.0438
fsync time: 5.0300
fsync time: 0.0231
fsync time: 0.0243
fsync time: 5.0382
fsync time: 5.0400
[... goes on like this ...]

これはミリ秒ではなく5秒です。これは、同じホストとデータストアで実行されている異なるVMでIOレイテンシを作成することです。

root@grml /mnt/sda/ioping-0.5 # ./ioping -i 0.3 -p 20 .
4096 bytes from . (reiserfs /dev/sda): request=1 time=7.2 ms
4096 bytes from . (reiserfs /dev/sda): request=2 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=3 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=4 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=5 time=4809.0 ms
4096 bytes from . (reiserfs /dev/sda): request=6 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=7 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=8 time=1.1 ms
4096 bytes from . (reiserfs /dev/sda): request=9 time=1.3 ms
4096 bytes from . (reiserfs /dev/sda): request=10 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=11 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=12 time=4950.0 ms

最初のVMをローカルストレージに移動すると、まったく正常に見えます。

root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 0.0191
fsync time: 0.0201
fsync time: 0.0203
fsync time: 0.0206
fsync time: 0.0192
fsync time: 0.0231
fsync time: 0.0201
[... tried that for one hour: no spike ...]

私が試したことで違いはありませんでした：

• いくつかのESXiビルドのテスト：381591、348481、260247
• さまざまなハードウェア、さまざまなIntelおよびAMDボックスでテスト済み
• 異なるNFSサーバーでテストされ、すべて同じ動作を示します。
  • OpenIndiana b147（ZFS同期は常にまたは無効：違いなし）
  • OpenIndiana b148（ZFS同期は常にまたは無効：違いなし）
  • Linux 2.6.32（同期または非同期：違いなし）
  • NFSサーバーが（仮想ストレージアプライアンスとして）同じマシン上にあるか、異なるホスト上にある場合でも違いはありません。

ゲストOSのテスト、問題の表示：

• Windows 7 64ビット（CrystalDiskMarkを使用すると、待機時間のスパイクはほとんど準備段階で発生します）
• Linux 2.6.32（fsync-tester + ioping）
• Linux 2.6.38（fsync-tester + ioping）

Linux 2.6.18 VMではこの問題を再現できませんでした。

もう1つの回避策は、仮想IDEディスク（vs SCSI / SAS）を使用することですが、これにより、パフォーマンスとVMごとのドライブ数が制限されます。

更新2011-06-30：

アプリケーションがfsyncの前に複数の小さなブロックに書き込む場合、レイテンシスパイクがより頻繁に発生するようです。たとえば、fsync-testerはこれを行います（strace出力）：

pwrite(3, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 1048576, 0) = 1048576
fsync(3)                                = 0

iopingはファイルの準備中にこれを行います：

[lots of pwrites]
pwrite(3, "********************************"..., 4096, 1036288) = 4096
pwrite(3, "********************************"..., 4096, 1040384) = 4096
pwrite(3, "********************************"..., 4096, 1044480) = 4096
fsync(3)                                = 0

isyncのセットアップフェーズはほとんど常にハングしますが、fsync-testerは正常に動作する場合があります。誰かがfsync-testerを更新して複数の小さなブロックを書き込むことができますか？私のCスキルは吸う;）

更新2011-07-02：

この問題は、iSCSIでは発生しません。OpenIndiana COMSTAR iSCSIサーバーでこれを試しました。ただし、iSCSIではVMDKファイルに簡単にアクセスできないため、スナップショットとrsyncを使用してホスト間でファイルを移動できます。

更新2011-07-06：

これは、同じvSwitch上の3番目のVMによってキャプチャされるWiresharkキャプチャの一部です。これはすべて同じホストで発生し、物理ネットワークは関係しません。

私は20時頃にiopingを開始しました。5秒の遅延が終わるまでパケットは送信されませんでした。

No.  Time        Source                Destination           Protocol Info
1082 16.164096   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1085), FH:0x3eb56466 Offset:0 Len:84 FILE_SYNC
1083 16.164112   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1086), FH:0x3eb56f66 Offset:0 Len:84 FILE_SYNC
1084 16.166060   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet-locate [ACK] Seq=445 Ack=1057 Win=32806 Len=0 TSV=432016 TSER=769110
1085 16.167678   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1082) Len:84 FILE_SYNC
1086 16.168280   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1083) Len:84 FILE_SYNC
1087 16.168417   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1057 Ack=773 Win=4163 Len=0 TSV=769110 TSER=432016
1088 23.163028   192.168.250.10        192.168.250.20        NFS      V3 GETATTR Call (Reply In 1089), FH:0x0bb04963
1089 23.164541   192.168.250.20        192.168.250.10        NFS      V3 GETATTR Reply (Call In 1088)  Directory mode:0777 uid:0 gid:0
1090 23.274252   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1185 Ack=889 Win=4163 Len=0 TSV=769821 TSER=432716
1091 24.924188   192.168.250.10        192.168.250.20        RPC      Continuation
1092 24.924210   192.168.250.10        192.168.250.20        RPC      Continuation
1093 24.924216   192.168.250.10        192.168.250.20        RPC      Continuation
1094 24.924225   192.168.250.10        192.168.250.20        RPC      Continuation
1095 24.924555   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet_svinfo [ACK] Seq=6893 Ack=1118613 Win=32625 Len=0 TSV=432892 TSER=769986
1096 24.924626   192.168.250.10        192.168.250.20        RPC      Continuation
1097 24.924635   192.168.250.10        192.168.250.20        RPC      Continuation
1098 24.924643   192.168.250.10        192.168.250.20        RPC      Continuation
1099 24.924649   192.168.250.10        192.168.250.20        RPC      Continuation
1100 24.924653   192.168.250.10        192.168.250.20        RPC      Continuation

2回目の更新2011-07-06：

TCPウィンドウサイズの影響があるようです。FreeNAS（FreeBSDベース）をNFSサーバーとして使用してこの問題を再現することはできませんでした。Wiresharkのキャプチャでは、TCPウィンドウが定期的に29127バイトに更新されています。デフォルトではより大きなウィンドウサイズを使用するOpenIndianaではそれらを見ませんでした。

OpenIndianaで次のオプションを設定し、NFSサーバーを再起動すると、この問題を再現できなくなります。

ndd -set /dev/tcp tcp_recv_hiwat 8192 # default is 128000
ndd -set /dev/tcp tcp_max_buf 1048575 # default is 1048576

ただし、これによりパフォーマンスが低下します。dd_rescueを使用して/ dev / zeroからファイルに書き込むと、170MB / sから80MB / sになります。

更新2011-07-07：

このtcpdumpキャプチャをアップロードしました（wiresharkで分析できます）。この場合、192.168.250.2はNFSサーバー（OpenIndiana b148）であり、192.168.250.10はESXiホストです。

このキャプチャ中にテストしたもの：

「ioping -w 5 -i 0.2」を開始しました。時間30で、セットアップで5秒ハングし、時間40で完了します。

「ioping -w 5 -i 0.2」を開始しました。時間60で、セットアップで5秒ハングし、時間70で完了しました。

時間90で「fsync-tester」を開始し、次の出力で時間120で停止しました。

fsync time: 0.0248
fsync time: 5.0197
fsync time: 5.0287
fsync time: 5.0242
fsync time: 5.0225
fsync time: 0.0209

2回目の更新2011-07-07：

別のNFSサーバーVMをテストしました。今回はNexentaStor 3.0.5コミュニティエディション：同じ問題を示しています。

更新2011-07-31：

この問題は、新しいESXiビルド4.1.0.433742でも再現できます。

この問題は、ESXi 5で修正されたようです。ビルド469512をテストし、成功しました。

おかげで、nfsstatはよさそうだ。キャプチャを確認しました。決定的なものは見つかりませんでしたが、興味深いものを見つけました。tcp.time_delta> 5でフィルタリングしました。すべての遅延インスタンスで見つかったのは、RPC呼び出しの正確な開始でした。すべての新しいRPCコールが遅いわけではありませんが、すべてのスローダウンはRPCコールの正確な開始時に発生しました。また、キャプチャから、192.168.250.10にすべての遅延が含まれているように見えます。192.168.250.2はすべての要求にすぐに応答します。

調査結果：

• 遅延は常にRPC呼び出しの最初のパケットで発生します
• NFSコマンドタイプは遅延インスタンスと相関していませんでした
• フラグメンテーション=最初のパケットのみを遅延させる

大規模な書き込み呼び出しは300個の個別のTCPパケットに分割でき、最初のパケットのみが遅延しますが、残りはすべて通過します。遅延が途中で発生することはありません。ウィンドウサイズが接続の開始にどの程度影響するかはわかりません。

次のステップ：TCPウィンドウではなく、NFSSVC_MAXBLKSIZEなどのNFSオプションを下方に調整し始めます。また、2.6.18は機能しますが、2.6.38は機能しません。その期間中にVMXnet3ドライバーのサポートが追加されたことを知っています。ホストでどのNICドライバーを使用していますか？TCPオフロードはい/いいえ？95秒のマークの前後に、単一のNFS書き込み呼び出しに対して500を超えるTCPパケットがあります。TCPを担当し、大きなPDUを分割することが、ブロッキングの原因になる可能性があります。

ESXi4.1U1とCentOS VMを使用すると、同じ問題のように見えます。ホストはDell R610、ストレージはEMC2 Isilonクラスターです。

VLANSを使用していましたか？ストレージ用にVMkernelポートでVLANを使用すると、VMHost上のすべてのストレージトラフィックで4000〜5000ミリ秒の「ハング」が発生することがわかりました。ただし、タグなしパケットを受信するようにVMkernelポートをVLANから移動しても、問題は発生しません。

以下の簡単なセットアップは、私のネットワークで問題を引き起こします：

1）サーバーまたはワークステーションにESXi 4.1U1をインストールします（両方とも私が試したときに問題を示しました）

2）VMkernelポートをVLANに追加します。

3）NFSデータストアを追加します（私のVLANは同じVLAN上にあります。つまり、Isilonはタグ付きパケットを受信します）

4）2つのCentOS 5.5 VM、1つはiopingをインストールします。

5）VMをシングルユーザーモードで起動します（つまり、ネットワークなし、最小限のサービス）。

6）1台のマシンでiopingを実行して、仮想ディスクに書き込みます

7）他のマシンでddなどを実行して、100MBのデータを/ tmpなどに書き込みます。

多くの場合、両方のVMが4〜5秒間フリーズします。

他の誰かが同じようなものを見ているかどうか、本当に興味があります。

2週間前にまったく同じ問題が発生しました。ESX41 U1およびNetapp FAS3170 + NFSデータストア。RHEL5 VMが2〜4秒ハングし、Virtual Centerパフォーマンスコンソールから非常に高いスパイクが見られました。

ネットワークガイに設定を確認してもらい、問題はCiscoスイッチにありました。Cisco側ではなく、Netapp側のEtherchannelに設定された2つのイーサネットリンクがあります。彼はcisco上に静的なEthechannelを作成し、現在は正常に機能しています。この種の問題を特定するには、ファイラーとスイッチの間のポートを除くすべてのポートをシャットダウンします。ポートを1つだけ残して、状況がどのように進行するかを確認します。

2番目に行うことは、switcjとファイラーのフロー制御を削除することでした。これは、一時停止フレームを送信すると思われるためです。

DNSはどのように見えますか？あなたのある/etc/resolv.conf正しいですか？デフォルトのタイムアウトは5秒です。

から man resolv.conf

timeout:n
                 sets the amount of time the  resolver  will  wait  for  a
                 response  from  a  remote name server before retrying the
                 query via a different name server.  Measured in  seconds,
                 the default is RES_TIMEOUT (currently 5, see <resolv.h>).

に追加timeout:3して/etc/resolv.confから、fsyncテストを再度実行してください。

ここではストローを把握していますが、これらのサーバーで使用しているNICは何ですか？Stack Overflowのシステム管理者は、Intel NICに切り替えたときに消えたBroadcom NICの奇妙なネットワーク問題を抱えています：http : //blog.serverfault.com/post/broadcom-die-mutha/

別の推測があります...あなたのIPv6はEXSホストで有効になっていますか？はいの場合は、オフにしますか？私の経験では、ネットワーク全体がIPv6（RADV、DHCP6、DNS、逆引きDNS）に適切に構成されていない場合、一部のサービスで問題になる可能性があります。また、NFSサーバーでオフになっていることを確認してください。