web-dev-qa-db-ja.com

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

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

これは fsync-tester （Ted Ts'oによる）および ioping を使用して再現できます。たとえば、8 GBのディスクで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年6月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

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

更新2011-07-02：

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

2011年7月6日更新：

これは、同じ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

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

2011年7月7日更新：

これをアップロードしました tcpdump capture （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で完了しました。

時間f90に「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年7月31日更新：

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

vmware-esxinfslatency
44
exo_cw

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

5
exo_cw

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

調査結果：

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

大きな書き込み呼び出しは300個の個別のパケットに分割される可能性がありますTCP=パケットであり、最初のパケットのみが遅延しますが、残りはすべて通過します。遅延が中央で発生することはありません。よくわかりません。ウィンドウサイズが接続のbeginningにどのように影響するか。

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

3
Ryan

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

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

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

2
Laurent

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

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

以下の簡単な設定で、ネットワークで問題が発生します。

1）サーバーまたはワークステーションにESXi 4.1U1をインストールします（どちらも試したときに問題が発生しました）

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

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

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

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

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

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

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

他の誰かが同様のことを見ていないかどうか、本当に興味を持ってください。

2
Nick

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テストを再度実行してください。

1
Joseph Kern

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

1
zippy

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

1
dtoubelis