なんちゃって技術者のなまくらです。みなさま、いかがお過ごしでしょうか。
ちょっと前にこんな記事を書きました。
ls結果が遅すぎる！どうなってんだNetApp！？
ことの顛末を書いていなかったのと、現在も結論が出ていない事実があるので書いておこうと思いますまる。
発生事象おさらい
NetApp をFAS3160からFAS2750にリプレース。NFSボリュームはそのまま移行。その中のとあるディレクトリにファイルが26,000弱存在していた。その領域をSolaris9(古っ！)とCentOS6で両方ともマウントし、lsコマンドをたたいたところ、Solaris9は2分半かかり、CentOS6ではその1/5（30秒）ほどでした。マウントオプションの違い
どうしてそんなに大きな差となって表れたのか、わかっている人にとってはえらく単純で、マウント時にnoacのオプションを付けたかどうか、です。このオプションをつけないとOS側でキャッシングをしなくなるので、lsの要求(特にgetattr)はすべてNetApp側に投げることになります。
手元にあるCentOS6.6にてman nfsを叩き、ac/noacオプション部分を抜粋します。
Selects whether the client may cache file attributes. If neither option is specified (or if ac is specified), the client caches file attributes.
クライアントがファイル属性をキャッシュできるかどうかを選択します。どちらのオプションも指定されていない場合（またはacが指定されている場合）、クライアントはファイル属性をキャッシュに入れます。
To improve performance, NFS clients cache file attributes. Every few seconds, an NFS client checks the server's version of each file's attributes for updates.
Changes that occur on the server in those small intervals remain undetected until the client checks the server again. The noac option prevents clients from caching file attributes so that applications can more quickly detect file changes on the server.
パフォーマンスを向上させるために、NFSクライアントはファイル属性をキャッシュします。数秒ごとに、NFSクライアントは更新のために各ファイルの属性のサーバーのバージョンをチェックします。
これらの短い間隔でサーバー上で発生した変更は、クライアントがサーバーを再度チェックするまで検出されません。 noacオプションを指定すると、クライアントはファイル属性をキャッシュできなくなり、アプリケーションはサーバー上のファイルの変更をより迅速に検出できます。
In addition to preventing the client from caching file attributes, the noac option forces application writes to become synchronous so that local changes to a file become visible on the server immediately. That way, other clients can quickly detect recent writes when they check the file's attributes.
クライアントがファイル属性をキャッシュしないようにすることに加えて、noacオプションはアプリケーションの書き込みを強制的に同期化して、ファイルに対するローカルの変更がサーバー上ですぐに見えるようにします。このようにして、他のクライアントはファイルの属性をチェックするときに最近の書き込みを素早く検出できます。
Using the noac option provides greater cache coherence among NFS clients accessing the same files, but it extracts a significant performance penalty. As such, judicious use of file locking is encouraged instead. The DATA AND METADATA COHERENCE section contains a detailed discussion of these trade-offs.
noacオプションを使用すると、同じファイルにアクセスするNFSクライアント間でキャッシュの一貫性が向上しますが、パフォーマンスが大幅に低下します。そのため、代わりにファイルロックを慎重に使用することをお勧めします。データとメタデータのコヒーレンスのセクションでは、これらのトレードオフについて詳しく説明しています。なんだ、manに解答が全部書いてあるじゃんw
なんでnoacオプションを使用しているのか
前のmanから抜粋の最後のほうにも書いてあるんですが、ファイル読み取りの一貫性を保証したかったからです。一貫性というと( ﾟДﾟ)ﾊｧ?？なんのこっちゃと思うかもしれません。今回問題が発生したサーバは負荷分散装置の下に2台構成でぶら下げているサーバで発生したものです。ファイルキャッシュを有効にすると、2台の間のファイルの状態に差が生じてしまうなどの問題が発生することがあるからです。
良いリンク見つけました。
nfs利用時のmountオプションについて
リンク切れ怖いのでここから転載するとキャッシュを効かせると、速度的に大きなアドバンテージが得られる代わりに、以下のデメリット(一貫性、安全性)も生じます。
- マウントしているクライアント側がローカルにキャッシュを持つのでnfsサーバ側と差分が出ることがある(LB配下の場合はクライアント間でも発生する)。
- 同期しないので書き込み完了したつもりでも、DISKに反映されてない事がある
- IOをキャッシュするので突発ダウン時にDISK書き込んでいないデータが消失する
キャッシュのON/OFFについてのトレードオフ関連の話については長くなりそうなのでまたにしましょう。今回は速度面のところにフォーカスあててるのでこの辺で切り上げます。
プラスしての悪条件
で、mountのnoacオプションのことについては理解できましたが、今回の事案ではこの影響に拍車をかけた環境がありました。
それはリプレースしたNetAppをもともとあったところとは別のロケーションに配置したことです。ロケーション間をL2ブリッジで接続していたので、セグメントは同じでしたがPingで確認したところブリッジでのレイテンシーが数ミリ秒単位で存在する状況になりました。
noacオプションでマウントした時に数100ファイルくらいであればこの遅延は体感できないくらいだったと思うのですが、万を超えるファイル数だったので、この数ミリ秒のレイテンシーが積み重なって影響を体感できるくらいになっていました。
レイテンシー発生自体は仕方がないことではあるのですが、ネットワークレイテンシーの積層効果を軽く見ていて（というか気づけなくて）、遅延事象に拍車をかけることになってしまいました。
NetAppも遅くなってる！？
ここまではNFSの仕様とその影響が増幅される場合があるよ、という話をしていましたが、調べを進めていくと、どうやらNetApp側でも若干(これが大きな原因ではないと思うが)性能低下がある可能性が出てきました。
リプレースで新製品にしたのにね(´Д｀)ﾊｧ…
今回NetAppリプレースお願いした業者さんのほうで切り分けのために各ONTAPバージョンでのlsコマンドの結果を計測してもらったところ、以下のような結果に…
lsコマンドの応答速度計測結果
条件:
NetApp社の仮想上の検証環境(LabOndemand)を使用
ファイル数26001個、すべてダミーファイル、サイズは1kb
8.2.1 7-mode 0m21.145s
8.3.2 c-mode 0m24.601s
9.1RC1 c-mode 0m23.817s
9.3RC1 c-mode 0m45.441s
9.5RC1 c-mode 1m1.573s
バージョン新しくなるごとに遅くなってる…
これについてはメーカーサポートおよびメーカーの開発部門でも同様の傾向自体は確認しているらしいです…。
バージョンが新しくなるごとに新機能が追加されていたりして便利になってはいるとは思うのですがそれのかわり基本性能の低下は許容してくれ、ではなくて、せめて基本的な性能はそのままに、プラスアルファとして機能追加等をしていただきたい、と思った次第。
でも計測して傾向が分かったとはいえ、すでに機能をインプリメントした状態で出荷してるし、根本の原因特定とかはなかなか難しいんだろうなぁ。もちろん機能の設計と実装にもよると思うけれど。
それではまた。
0 件のコメント:
コメントを投稿