web-dev-qa-db-ja.com

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とストレージウェブサーバーの両方がファイルを提供します。両方ともしばらくハングしたままになり、その後通常の操作を再開します。このハングにより、クライアント側に痕跡が残りません。 （NFS ... not respondingメッセージも残しません）そして、ストレージ側では、rsyslogdが実行されていても、ログシステムは空のように見えます。

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

私はしばらくの間これを解決しようとしていて、GFS2 FSもハングしていることに気付く前に、さまざまなNFS構成オプションを試しました。

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サーバー：

    • Intel Bi Xeon E5606 2x4 2.13GHz
    • 24GB DDR3
    • Intel SSD 320 2 x120GBレイド1

  • ストレージ：

    • Intel 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>

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

#/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接続を介して毎日最大200GBの新しいファイルを処理することです。これは、これがNFSまたはGFS2のいずれかのある種の高負荷の問題であると考えるための重要なポイントです。

さらに構成の詳細が必要な場合は、教えてください。

編集3：

今日の初めに、ストレージサーバーでファイルシステムがクラッシュしました。サーバーが応答を停止したため、クラッシュの詳細をすぐに取得できませんでした。再起動後、ファイルシステムが非常に遅いことに気付きました。おそらくキャッシュのウォーミングアップなどが原因で、NFSまたはhttpdを介して単一のファイルを提供できませんでした。それにもかかわらず、私はサーバーを注意深く監視していて、次のエラーがdmesgで発生しました。問題の原因は明らかに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は次のことを示しています。iノードテーブルのサイズは、ハングの直前に80kと高く、その後突然10kに低下します。メモリと同様に、キャッシュされたデータも7GBから500MBに突然低下します。ハング中に負荷平均も急上昇し、drbdデバイスのデバイス使用量も約90％の値に急上昇します。

以前のハングと比較すると、これら2つのインジケーターは同じように動作します。これは、ファイルハンドラーをリリースしないアプリケーション側の不適切なファイル管理、またはGFS2またはNFSからのメモリ管理の問題（疑わしい）が原因である可能性がありますか？

フィードバックをお寄せいただきありがとうございます。

編集5：

Muninのiノードテーブルの使用法： 

Muninのメモリ使用量： 

web-serverstoragenfsgfs2
4
Tiago

2つの問題があると思います。そもそも問題を引き起こしているボトルネック、そしてさらに重要なことに、GFSによる不十分な障害処理。 GFSは、それが機能するまで転送を実際に遅くしているはずですが、私はそれを支援することができません。

あなたは、クラスターが最大200GBの新しいファイルをNFSに処理すると言います。クラスターから読み取られているデータの量は？

フロントエンドが（データ接続を過負荷にすることによって）バックエンドを「直接」切断できるため、フロントエンドとバックエンドに1つのネットワーク接続があると常に緊張します。

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

ネットワークはどのくらい利用されていますか？ストレージサーバー上のディスクの速度と、使用しているRAIDセットアップはどれくらいですか？どのスループットが得られますか？ * nixが実行されていて、静かにテストできると仮定すると、hdparmを使用できます。

$ hdpard -tT /dev/<device>

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

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

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

Top/htopを実行するときは、iowaitを監視してください。ここでの高い値は、CPUが何か（ネットワーク、ディスクなど）を待って親指をいじっているだけであることを示す優れた指標です。

私の意見では、NFSが原因である可能性は低いです。私たちはNFSについてかなり豊富な経験を持っており、調整/最適化することはできますが、かなり確実に機能するように傾向です。

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

最後に、OCFS2はGFSの代わりとして検討するオプションかもしれません。分散ファイルシステムの調査を行っている間、かなりの量の調査を行い、OCFS2を試してみた理由を思い出せませんが、実際に調査しました。おそらく、Oracleがデータベースバックエンドに使用しているOCFS2と関係があり、かなり高い安定性要件を意味します。

ムニンはあなたの友達です。しかし、はるかに重要なのはtop/htopです。 vmstatはあなたにいくつかのキー番号を与えることもできます

$ vmstat 1

そして、システムが何をしているのかを正確に毎秒更新します。

幸運を！

1
drone.ah

私はいくつかの一般的なポインタしか提供できません。

まず、いくつかの簡単なベンチマーク指標を稼働させます。少なくとも、あなたが行った変更が最善であるかどうかがわかります。

  • ムニン
  • サボテン

  • Nagios

    いくつかの良い選択です。

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

各ノード間のネットワーク接続はどのようなものですか

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

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

1
daxroc

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

  1. echo 2 > /proc/sys/vm/drop_caches
    1. 無料の歯科およびiノード
  2. echo 3 > /proc/sys/vm/drop_caches
    1. 無料のpagescache、dentires、inode

問題はなぜですか、おそらく長引くcronタスクがありますか？

01：00-> 12:00を除いて、それらは一定の間隔であるように見えます。

上記のコマンドのいずれかを実行すると問題が再現される場合は、ピークの約1/2を確認する価値もありますが、常に実行する直前にsyncを実行するようにしてください。

Drbdプロセスのstraceが（これが原因であると仮定して）予想されるパージの前後に失敗すると、ある程度の光が当たる可能性があります。

0
Oneiroi

最初のHAプロキシは、VarnishまたはNginxのいずれかを使用してWebサーバーの前に配置します。

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

MFSで、レプリケーションの目標を3に設定します

＃mfssetgoal 3/folder

//キリスト教徒

0
Christian