☰

NFS と GFS2 のパフォーマンスが遅い

tag-icon • tag-icon web-server storage nfs gfs2
NFS と GFS2 のパフォーマンスが遅い

最近、大量のファイル処理を実行する Web アプリケーション用に 4 ノード クラスターを設計および構成しました。クラスターは、Web サーバーとストレージという 2 つの主な役割に分かれています。各役割は、アクティブ/パッシブ モードで drbd を使用して 2 番目のサーバーに複製されます。Web サーバーは、ストレージ サーバーのデータ ディレクトリの NFS マウントを実行し、後者では、ブラウザー クライアントにファイルを提供する Web サーバーも実行されています。

ストレージ サーバーに、drbd に接続されたデータを保持するための GFS2 FS を作成しました。GFS2 を選んだのは、主に発表されているパフォーマンスと、かなり大きいボリューム サイズが必要だったためです。

実稼働に入ってから、深く関連していると思われる 2 つの問題に直面しています。まず、Web サーバーの NFS マウントが 1 分ほどハングしたままになり、その後通常の操作を再開します。ログを分析すると、NFS がしばらく応答を停止し、次のログ行を出力していることがわかりました。

Oct 15 18:15:42 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:44 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:46 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:47 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:47 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:47 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:48 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:48 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:51 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:52 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:52 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:55 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:55 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:58 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK

この場合、ハングは 16 秒間続きましたが、通常の操作を再開するには 1 ～ 2 分かかる場合があります。

最初は、NFS マウントの負荷が大きいためにこの問題が発生しているのではないかと考え、RPCNFSDCOUNT値を高くすると安定するだろうと考えました。何度か値を上げてみたところ、しばらくするとログが表示される回数が減ったようです。現在、値は です32。

この問題をさらに調査したところ、NFS メッセージがログにまだ表示されているにもかかわらず、別のハングが発生していることがわかりました。GFS2 FS がハングし、NFS とストレージ Web サーバーの両方がファイルを提供する場合があります。どちらもしばらくハングしたままになり、その後通常の操作を再開します。このハングでは、クライアント側には痕跡が残らず (NFS ... not respondingメッセージも残りません)、ストレージ側では、がrsyslogd実行中であるにもかかわらず、ログ システムが空になっているように見えます。

ノードは 10Gbps の非専用接続を介して接続しますが、アクティブなストレージ サーバーに直接接続すると GFS2 がハングすることが確認されているため、これは問題ではないと思います。

私はしばらくの間この問題を解決しようとしており、さまざまな NFS 構成オプションを試しましたが、GFS2 FS もハングしていることが分かりました。

NFS マウントは次のようにエクスポートされます。

/srv/data/ <ip_address>(rw,async,no_root_squash,no_all_squash,fsid=25)

NFS クライアントは次のようにマウントします:

mount -o "async,hard,intr,wsize=8192,rsize=8192" active.storage.vlan:/srv/data /srv/data

いくつかのテストを行った結果、クラスターのパフォーマンスが向上する構成が判明しました。

クラスターはすでに実稼働モードになっているため、このハングが今後発生しないように修正する必要があり、解決策を必死に探しています。また、何をどのようにベンチマークすればよいのかよくわかりません。以前クラスターをテストしたところ、この問題はまったく発生していなかったため、これは負荷が大きいために発生していると考えられます。

クラスターの構成の詳細を提供する必要がある場合、および投稿する内容を教えてください。

最後の手段として、ファイルを別の FS に移行することもできますが、この時点ではボリューム サイズが非常に大きいため、これで問題が解決するかどうかについて確かな指針が必要です。

サーバーはサードパーティの企業によってホストされており、物理的にアクセスすることはできません。

よろしくお願いします。

編集1: サーバーは物理サーバーであり、仕様は次のとおりです。

  • Webサーバー:

    • インテル Bi Xeon E5606 2x4 2.13GHz
    • 24GB DDR3
    • インテル SSD 320 2 x 120GB Raid 1

  • ストレージ：

    • インテル i5 3550 3.3GHz
    • 16GB DDR3
    • 12 x 2TB SATA

当初、サーバー間に VRack が設定されていましたが、ストレージ サーバーの 1 つをアップグレードして RAM を増やしたため、VRack 内にはありませんでした。サーバー間は共有 10Gbps 接続で接続されています。パブリック アクセスに使用される接続と同じであることに注意してください。サーバー間を接続し、正常なフェイルオーバーを可能にするために、単一の IP (IP フェイルオーバーを使用) を使用します。

したがって、NFS はパブリック接続上にあり、プライベート ネットワーク上にはありません (アップグレード前は問題がまだ存在していました)。

ファイアウォールは徹底的に構成およびテストされましたが、問題がまだ発生するかどうかを確認するためにしばらく無効にしましたが、問題は発生しました。私の知る限り、ホスティング プロバイダーはサーバーとパブリック ドメイン間の接続をブロックまたは制限していません (少なくとも、まだ到達していない特定の帯域幅消費しきい値以下では)。

これが問題解決に役立つことを願っています。

編集2:

関連するソフトウェアバージョン:

CentOS 2.6.32-279.9.1.el6.x86_64  
nfs-utils-1.2.3-26.el6.x86_64  
nfs-utils-lib-1.1.5-4.el6.x86_64  
gfs2-utils-3.0.12.1-32.el6_3.1.x86_64  
kmod-drbd84-8.4.2-1.el6_3.elrepo.x86_64  
drbd84-utils-8.4.2-1.el6.elrepo.x86_64

ストレージ サーバー上の DRBD 構成:

#/etc/drbd.d/storage.res
resource storage {
    protocol C;

    on <server1 fqdn> {
            device /dev/drbd0;
            disk /dev/vg_storage/LV_replicated;
            address <server1 ip>:7788;
            meta-disk internal;
    }

    on <server2 fqdn> {
            device /dev/drbd0;
            disk /dev/vg_storage/LV_replicated;
            address <server2 ip>:7788;
            meta-disk internal;
    }
}

ストレージ サーバーの NFS 構成:

#/etc/sysconfig/nfs
RPCNFSDCOUNT=32
STATD_PORT=10002
STATD_OUTGOING_PORT=10003
MOUNTD_PORT=10004
RQUOTAD_PORT=10005
LOCKD_UDPPORT=30001
LOCKD_TCPPORT=30001

LOCKD_UDPPORT(との両方に同じポートを使用すると競合が発生する可能性はありますかLOCKD_TCPPORT?)

GFS2 構成:

# gfs2_tool gettune <mountpoint>
incore_log_blocks = 1024
log_flush_secs = 60
quota_warn_period = 10
quota_quantum = 60
max_readahead = 262144
complain_secs = 10
statfs_slow = 0
quota_simul_sync = 64
statfs_quantum = 30
quota_scale = 1.0000   (1, 1)
new_files_jdata = 0

ストレージネットワーク環境:

eth0      Link encap:Ethernet  HWaddr <mac address>
          inet addr:<ip address>  Bcast:<bcast address>  Mask:<ip mask>
          inet6 addr: <ip address> Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:957025127 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1473338731 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2630984979622 (2.3 TiB)  TX bytes:1648430431523 (1.4 TiB)

eth0:0    Link encap:Ethernet  HWaddr <mac address>  
          inet addr:<ip failover address>  Bcast:<bcast address>  Mask:<ip mask>
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

IP アドレスは、指定されたネットワーク構成で静的に割り当てられます。

DEVICE="eth0"
BOOTPROTO="static"
HWADDR=<mac address>
ONBOOT="yes"
TYPE="Ethernet"
IPADDR=<ip address>
NETMASK=<net mask>

そして

DEVICE="eth0:0"
BOOTPROTO="static"
HWADDR=<mac address>
IPADDR=<ip failover>
NETMASK=<net mask>
ONBOOT="yes"
BROADCAST=<bcast address>

fsid=25両方のストレージ サーバーで設定されたNFS オプションと組み合わせて、正常な NFS フェイルオーバーを可能にするホスト ファイル:

#/etc/hosts
<storage ip failover address> active.storage.vlan
<webserver ip failover address> active.service.vlan

ご覧のとおり、パケット エラーは 0 に減少しています。また、長時間にわたって ping を実行しましたが、パケット損失はありませんでした。MTU サイズは通常の 1500 です。現時点では VLan がないため、これはサーバー間の通信に使用される MTU です。

Web サーバーのネットワーク環境も同様です。

言及し忘れたことの 1 つは、ストレージ サーバーが NFS 接続を介して毎日約 200 GB の新しいファイルを処理していることです。これは、NFS または GFS2 のいずれかで何らかの高負荷の問題が発生すると考える重要なポイントです。

さらに詳しい設定が必要な場合はお知らせください。

編集3:

本日、ストレージ サーバーで大規模なファイル システム クラッシュが発生しました。サーバーが応答しなくなったため、クラッシュの詳細をすぐには取得できませんでした。再起動後、ファイル システムが非常に遅く、NFS または httpd 経由で 1 つのファイルも提供できないことに気付きました。これは、キャッシュ ウォーミングなどのせいかもしれません。それでも、サーバーを注意深く監視していたところ、 で次のエラーが発生しましたdmesg。問題の原因は明らかに GFS です。GFS は を待機しておりlock、しばらくすると枯渇してしまいます。

INFO: task nfsd:3029 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
nfsd          D 0000000000000000     0  3029      2 0x00000080
 ffff8803814f79e0 0000000000000046 0000000000000000 ffffffff8109213f
 ffff880434c5e148 ffff880624508d88 ffff8803814f7960 ffffffffa037253f
 ffff8803815c1098 ffff8803814f7fd8 000000000000fb88 ffff8803815c1098
Call Trace:
 [<ffffffff8109213f>] ? wake_up_bit+0x2f/0x40
 [<ffffffffa037253f>] ? gfs2_holder_wake+0x1f/0x30 [gfs2]
 [<ffffffff814ff42e>] __mutex_lock_slowpath+0x13e/0x180
 [<ffffffff814ff2cb>] mutex_lock+0x2b/0x50
 [<ffffffffa0379f21>] gfs2_log_reserve+0x51/0x190 [gfs2]
 [<ffffffffa0390da2>] gfs2_trans_begin+0x112/0x1d0 [gfs2]
 [<ffffffffa0369b05>] ? gfs2_dir_check+0x35/0xe0 [gfs2]
 [<ffffffffa0377943>] gfs2_createi+0x1a3/0xaa0 [gfs2]
 [<ffffffff8121aab1>] ? avc_has_perm+0x71/0x90
 [<ffffffffa0383d1e>] gfs2_create+0x7e/0x1a0 [gfs2]
 [<ffffffffa037783f>] ? gfs2_createi+0x9f/0xaa0 [gfs2]
 [<ffffffff81188cf4>] vfs_create+0xb4/0xe0
 [<ffffffffa04217d6>] nfsd_create_v3+0x366/0x4c0 [nfsd]
 [<ffffffffa0429703>] nfsd3_proc_create+0x123/0x1b0 [nfsd]
 [<ffffffffa041a43e>] nfsd_dispatch+0xfe/0x240 [nfsd]
 [<ffffffffa025a5d4>] svc_process_common+0x344/0x640 [sunrpc]
 [<ffffffff810602a0>] ? default_wake_function+0x0/0x20
 [<ffffffffa025ac10>] svc_process+0x110/0x160 [sunrpc]
 [<ffffffffa041ab62>] nfsd+0xc2/0x160 [nfsd]
 [<ffffffffa041aaa0>] ? nfsd+0x0/0x160 [nfsd]
 [<ffffffff81091de6>] kthread+0x96/0xa0
 [<ffffffff8100c14a>] child_rip+0xa/0x20
 [<ffffffff81091d50>] ? kthread+0x0/0xa0
 [<ffffffff8100c140>] ? child_rip+0x0/0x20

編集4:

munin をインストールしたら、新しいデータがいくつか出てきました。今日、またハングアップし、munin は次のように表示しました。inode テーブルのサイズは、ハングアップ直前は 80k と高かったのですが、その後突然 10k に低下しました。メモリと同様に、キャッシュされたデータも 7GB から 500MB に突然低下しました。ハングアップ中に負荷平均も急上昇し、デバイスのデバイス使用率drbdも約 90% の値に急上昇しました。

以前のハングと比較すると、これら 2 つのインジケーターの動作は同じです。これは、ファイル ハンドラーを解放しないアプリケーション側のファイル管理が適切でないことが原因でしょうか、それとも GFS2 または NFS に起因するメモリ管理の問題でしょうか (私は疑っていますが)?

フィードバックをいただければ幸いです。

編集5:

Munin からの Inode テーブルの使用法:

Munin からのメモリ使用量:

答え1

私が提供できるのは、一般的な指針だけです。

まず、いくつかの簡単なベンチマーク メトリックを稼働させます。そうすれば、少なくとも、行った変更が最善のものかどうかがわかります。

  • ムニン
  • サボテン

  • ナギオス

    いくつか良い選択肢があります。

これらのノードは仮想サーバーですか、それとも物理サーバーですか、その仕様は何ですか。

各ノード間のネットワーク接続の種類は何か

NFS はホスティング プロバイダーのプライベート ネットワーク上でセットアップされていますか。

ファイアウォールでパケット/ポートを制限していませんか? ホスティング プロバイダーはこれを行っていますか?

答え2

2 つの問題があると思います。そもそもボトルネックが問題を引き起こしており、さらに重要なのは、GFS による障害処理が不十分であることです。GFS は、正常に動作するまで転送速度を低下させる必要がありますが、それについては私がサポートすることはできません。

クラスターは NFS に約 200 GB の新しいファイルを処理するとのことですが、クラスターから読み取られるデータの量はどれくらいですか?

フロントエンドとバックエンドに 1 つのネットワーク接続しかないと、フロントエンドがバックエンドを「直接」破壊する (データ接続に過負荷をかける) 可能性があるため、常に不安を感じます。

各ボックスに iperf をインストールすると、任意の時点で利用可能なネットワーク スループットをテストできます。これは、ネットワークのボトルネックがあるかどうかを素早く特定する方法です。

ネットワークはどの程度使用されていますか? ストレージサーバーのディスクの速度はどのくらいですか? また、どのような RAID 設定を使用していますか? スループットはどのくらいですか? *nix を実行していて、テストする時間がない場合は、hdparm を使用できます。

$ hdpard -tT /dev/<device>

ネットワークの使用率が高い場合は、GFS をセカンダリの専用ネットワーク接続に配置することをお勧めします。

12 台のディスクをどのように RAID したかによって、パフォーマンスのレベルが異なり、これが 2 番目のボトルネックになる可能性があります。また、ハードウェア RAID を使用しているか、ソフトウェア RAID を使用しているかによっても異なります。

要求されたデータがメモリ全体よりも広い範囲に分散している場合、マシンに搭載されている大量のメモリはほとんど役に立たない可能性があります。その可能性は高いようです。また、メモリは読み取りにのみ役立ちますが、読み取りの多くが同じファイルに対するものである場合がほとんどです (そうでない場合、キャッシュから追い出されます)。

top / htop を実行するときは、iowait を監視します。ここで高い値が表示される場合、CPU が何か (ネットワーク、ディスクなど) を待機しているだけの優れた指標となります。

私の意見では、NFSが原因である可能性は低いです。私たちはNFSについてかなり広範な経験を持っていますが、NFSは調整/最適化できますが、傾向があるかなり確実に動作します。

GFS コンポーネントを安定させてから、NFS の問題が解決するかどうかを確認したいと思います。

最後に、OCFS2 は GFS の代替として検討できるオプションかもしれません。分散ファイルシステムについて調査していたときに、かなりの量の調査を行いましたが、OCFS2 を試すことにした理由は思い出せません。しかし、試してみました。おそらく、OCFS2 が Oracle のデータベース バックエンドに使用されており、非常に高い安定性が求められることと関係があるのでしょう。

Muninはあなたの友達です。しかし、もっと重要なのはtop / htopです。vmstatはいくつかの重要な数値も提供します。

$ vmstat 1

システムが何に時間を費やしているかについて、毎秒更新情報が得られます。

幸運を！

答え3

まず、Varnish または Nginx を使用して、Web サーバーのフロントに HA プロキシを配置します。

次に、Web ファイル システムの場合: NFS、GFS2 の代わりに MooseFS を使用するのはいかがでしょうか。MooseFS はフォールト トレラントで読み取りが高速です。NFS、GFS2 ではローカル ロックが使用できなくなりますが、アプリケーションにそれが必要なのでしょうか。必要でない場合は、MooseFS に切り替えて NFS、GFS2 の問題を回避します。MFS メタデータ サーバーの HA には Ucarp を使用する必要があります。

MFSでレプリケーション目標を3に設定する

# mfssetgoal 3 /フォルダ

//キリスト教徒

答え4

Munin グラフに基づいて、システムはキャッシュを削除しています。これは、次のいずれかを実行することと同等です。

  1. echo 2 > /proc/sys/vm/drop_caches
    1. 空き dentry と inode
  2. echo 3 > /proc/sys/vm/drop_caches
    1. ページキャッシュ、デンティレス、iノードを解放する

疑問は、なぜ cron タスクが残っているのかということです。

01:00 -> 12:00 を除けば、一定の間隔になっているようです。

上記のコマンドのいずれかを実行しても問題が再現するかどうかは、ピークの半分くらいまで確認してみる価値はあるでしょう。いつもsyncそうする前に必ず右折してください。

それができない場合は、strace予想されるパージの時刻の前後からそのパージまでの間に、drbd プロセス (再びこれが原因であると仮定) を調べると、何らかの手がかりが得られるかもしれません。

関連情報